Loop/Architecture/Context: Difference between revisions
(Created page with "The rooms (conversations) in Loop are planned to include additional room context information, such as a URL that will be the topic of the conversation, a thumbnail of that URL...") |
No edit summary |
||
| Line 1: | Line 1: | ||
The rooms (conversations) in Loop are planned to include additional room context information, such as a URL that will be the topic of the conversation, a thumbnail of that URL, and a long-form description of the conversation purpose. | The rooms (conversations) in Loop are planned to include additional room context information, such as a URL that will be the topic of the conversation, a thumbnail of that URL, and a long-form description of the conversation purpose. Note that this is list is an initial proposal; it is probable that the context information associated with a room will evolve over time. The initial version of this feature is tracked in {{Bug|1115340}}. | ||
== Information Privacy == | |||
The context information is user-supplied, so we need to carefully consider privacy handling. The design below serves this purpose by storing the information on the Loop server in an encrypted form. Each room will have its own symmetric key, which will be available to the room owner and anyone to whom he provides the room URL. These room keys will never be available to any server. | |||
This section explains the means by which this achieved at the level of information flow. Details are provided in the [[#Loop Server API Changes]] section below. | |||
When a Loop client logs into the FxA server, it will obtain a user-specific symmetric key, '''kB''', and an OAuth application identifier. The key '''kB''' is wrapped with the user's account login password. Upon obtaining the key, the user unwraps '''kB''', combines it with the application identifier, and applies HKDF to obtain a new key, '''kBr'''. | |||
When a client creates a new room, it first generates a new symmetric room key, '''kR'''. The room context information is serialized as a JSON object, and encrypted using '''kR'''. The client also wraps '''kR''' with '''kB'''. The encrypted context information and the wrapped room key '''kR''' are sent to the Loop server as part of the room creation request; these are stored as part of the room's information. | |||
Upon receipt of the resulting room URL from the server, the client appends the room key '''kR''' to the URL as a URL fragment before storing it locally. | |||
Because all desktop clients can constitute their '''kBr''' upon logging in to FxA, any room context retrieved from the Loop server can be decoded by unwrapping the '''kR''' received as part of the room information, and using it to decrypt the context. | |||
Standalone clients receive the unwrapped '''kR''' 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 '''kR''' to decode the room context information and display it to the user. | |||
== Loop Server API Changes == | |||
=== POST /rooms === | |||
=== PATCH /rooms/{token} === | |||
=== GET /rooms/{token} === | |||
=== GET /rooms === | |||
Revision as of 19:41, 30 January 2015
The rooms (conversations) in Loop are planned to include additional room context information, such as a URL that will be the topic of the conversation, a thumbnail of that URL, and a long-form description of the conversation purpose. Note that this is list is an initial proposal; it is probable that the context information associated with a room will evolve over time. The initial version of this feature is tracked in bug 1115340.
Information Privacy
The context information is user-supplied, so we need to carefully consider privacy handling. The design below serves this purpose by storing the information on the Loop server in an encrypted form. Each room will have its own symmetric key, which will be available to the room owner and anyone to whom he provides the room URL. These room keys will never be available to any server.
This section explains the means by which this achieved at the level of information flow. Details are provided in the #Loop Server API Changes section below.
When a Loop client logs into the FxA server, it will obtain a user-specific symmetric key, kB, and an OAuth application identifier. The key kB is wrapped with the user's account login password. Upon obtaining the key, the user unwraps kB, combines it with the application identifier, and applies HKDF to obtain a new key, kBr.
When a client creates a new room, it first generates a new symmetric room key, kR. The room context information is serialized as a JSON object, and encrypted using kR. The client also wraps kR with kB. The encrypted context information and the wrapped room key kR are sent to the Loop server as part of the room creation request; these are stored as part of the room's information.
Upon receipt of the resulting room URL from the server, the client appends the room key kR to the URL as a URL fragment before storing it locally.
Because all desktop clients can constitute their kBr upon logging in to FxA, any room context retrieved from the Loop server can be decoded by unwrapping the kR received as part of the room information, and using it to decrypt the context.
Standalone clients receive the unwrapped kR 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 kR to decode the room context information and display it to the user.