Confirmed users
632
edits
Loop/Architecture/Context: Difference between revisions
→Information Privacy
| Line 18: | Line 18: | ||
Standalone clients receive the room metadata key '''kRm''' in the fragment portion of the URL that was provided to them as the means of joining the room. Upon retrieving the encrypted room context information from the server, they use this '''kRm''' to decode the room context information and display it to the user. | Standalone clients receive the room metadata key '''kRm''' in the fragment portion of the URL that was provided to them as the means of joining the room. Upon retrieving the encrypted room context information from the server, they use this '''kRm''' to decode the room context information and display it to the user. | ||
[[File:Loop-keys.png|Information flow in Loop key handling]] | <center>[[File:Loop-keys.png|Information flow in Loop key handling]]</center> | ||
'''''Note: The preceding design is predicated on having the ability to retrieve kB from FxA in time for the initial feature landing. This ability is being tracked [https://github.com/mozilla/fxa-content-server/issues/2088 on the FxA github repo]. If this cannot be done in time, we will need to store room-keys client-side. This is sub-optimal, as it makes it impossible to create a room on one client and view or manipulate information on another.''''' | '''''Note: The preceding design is predicated on having the ability to retrieve kB from FxA in time for the initial feature landing. This ability is being tracked [https://github.com/mozilla/fxa-content-server/issues/2088 on the FxA github repo]. If this cannot be done in time, we will need to store room-keys client-side. This is sub-optimal, as it makes it impossible to create a room on one client and view or manipulate information on another.''''' | ||