Resources/Views/metadata.leaf

@@ -14,7 +14,7 @@
     <ul>
       <li>The server keeps <strong>who a message is for and when it arrived</strong>, because it cannot deliver it otherwise.</li>
       <li>It keeps <strong>the message itself, still locked</strong>, until your app collects it, and it holds nothing that would open it.</li>
-      <li>It keeps <strong>your account details</strong>: username, email, password (stored scrambled), and the public half of your keys.</li>
+      <li>It keeps <strong>your account details</strong>: username and the public half of your keys. On this server your password check and any recovery code live with the shared account service, and there is no email. A server with its own accounts also keeps your email and your password, stored scrambled.</li>
       <li>It does <strong>not</strong> keep a record of when you added a friend, blocked someone, or joined a group. Those were removed on purpose.</li>
       <li>Its own logs contain <strong>no account, device or address</strong> unless an operator deliberately turns on detailed logging.</li>
     </ul>
@@ -43,7 +43,7 @@
     <table>
       <thead><tr><th>Kept</th><th>Why</th></tr></thead>
       <tbody>
-        <tr><td>Username, email, password hash, display name</td><td>It is an account</td></tr>
+        <tr><td>Username, display name; email and password hash only on a server with its own accounts</td><td>It is an account</td></tr>
         <tr><td>Public keys per device</td><td>They are published on purpose, that is what a prekey bundle is</td></tr>
         <tr><td>Buddy list, <strong>until you take it off</strong></td><td>Presence is shown only to people on your list, so the server holds it to enforce that. Settings offers "Take my contact list off the server": the list then lives only in your devices' encrypted stores (and rides your encrypted history export), and the honest cost is that buddies see you as offline, a presence design that needs no stored graph is the planned replacement. One more limit, because it is a limit and not a detail: removing your list also clears the per-conversation rows that name the same people, in both directions, <em>except</em> where such a row is also carrying a read position or a per-conversation setting. Those stay, with the acceptance cleared, because deleting them would lose state you never asked to lose and bring threads back unread on your other devices. So where you have read a conversation, the fact that it exists survives the removal.</td></tr>
         <tr><td>Blocks</td><td>The server enforces them, so it has to know them. It cannot enforce one against a message that does not name its sender, blocking someone also cancels the passes you gave them, which is the part that can be aimed at one person.</td></tr>

Resources/Views/privacy.leaf

@@ -55,8 +55,12 @@
 
     <h2>Account information</h2>
     <p>
-      An account holds a username, an email address, and a password hash. Each device you
-      register publishes its public keys. Private keys are generated on your device and
+      On a server that uses the shared FlameNet account service, as this one does, your
+      account holds a username and a value your phone derives from your password, which
+      cannot be turned back into it, plus a hashed recovery code if you set one up. There
+      is no email address, and your password never leaves your phone. A server that keeps
+      its own accounts holds a username, an email address and a password hash. Each device
+      you register publishes its public keys. Private keys are generated on your device and
       are never transmitted.
     </p>