-
Notifications
You must be signed in to change notification settings - Fork 9
System Hierarchy
(Additional details are covered on Priv.ly)
Building secure applications on top of web browsers requires significant "separation of concerns." Privly is working with several layers of permissions in building the system. The ordering of "trust," from lowest to highest is:
- Host pages, like Gmail and Facebook. We modify host pages through Content Scripts, which are assumed to be as trustworthy as the pages in which they run.
- Content servers, which host the content.
- Injectable Applications, which are the applications we inject into web pages. Think of these as our "little world" inside host pages. The Same Origin Policy protects these applications from the scripting environment of host web pages.
- The extension, which has access to all the host pages and injectable applications via message passing, but they don't operate in the same scripting environment as either.
The host page could be any web application on the internet. Consequently, the host page is not given any trust. All messages and events from the host pages are ignored by the extension. The primary point of interaction with the host page is to inject the Content Scripts privly.js. The content script handles searching host pages for the injectable URL, and then creates the iframe for the injectable application. The injectable application will then ask the host page to resize the iframe to match the height of its content.
The content servers contain content intended for injectable applications. In general they should present data-only endpoints, but in cases where users do not have the extension installed, they should present a fallback web application.
Any server could potentially host Privly content, but we have a reference implementation.
The Injectable Applications are trusted and studied applications with known security and privacy guarantees. By limiting the operations the applications can perform, we can provide security guarantees for user data and cryptographic identities.
The only element of interaction between the Injected Application and the host page is a message from the injected application to the host page containing the height of the content. The content script found in the host page will then resize the iframe so that its height matches the message sent by the application. Future versions may allow the host page to send formatting instructions, but this is not currently in the scope of development.
A second use case of the injected applications is to generate a new link for injection into the host page. These "posting" applications will typically not be viewed in host pages. The preferred method of viewing these applications is to open them in an element of the UI that is only accessible to pages opened by the extension.
Browser extensions typically have permissions to message any web page opened in the browser, and they are (or must be) protected from the potentially malevolent code of host pages and untrusted Injectable Applications. The extension handles injections of the content scripts, and the posting process. Once the injected application is running in a host page, it may make requests to the extension using the message passing interface of the browser.
The following diagrams show the general activities carried out in the reading and posting processes. Many of these processes are hackable and are considered guidance for a standard application. For specific examples, look at the injectable applications.
Encountering Content
This process is for injecting content directly into host pages.
- The extension injects a content script into the host page.
- The content script finds a Privly-type link and injects it into the host page.
- The injectable application requests the content from the content server.
- The content server returns the content to the injectable application.
- The injectable application performs any cryptographic operations on the content that are required.
- The injectable application tells the host page the height of the application's content
________________________ Inject Content Script ______________________ \/ |
____________ ___________ | | | >--Inject App --> | | | | | Host Page | | Inj.App | | Extension | | | <--iframe size--< | | | | || || || | /\
Content Req. Ciphertext
/ |
____________
| |
| Content |
| Server |
|__|
Posting New Content
This process is for generating a new Privly-type link directly from the extension.
- The user initiates the posting process and types content into the injectable application.
- The injectable application performs any required cryptographic operations.
- The injectable application sends the ciphertext to the content server.
- The content server returns the content URL to the injectable application.
- The injectable application passes the content URL onto the extension.
- The extension places the content URL into the host page.
____________ ____________________________________________ | | | | | Host Page | | Extension | | | <---Content URL---< | | |____________| |__________________________________________| /\ Content URL | ____________ ____________________________________________ | | | | | User | >---Plaintext-----> | Injectable App | | | | | |____________| |___________________________________________| | /\ Ciphertext Content URL \/ | ____________________________________________ | | | Content Server | | | |___________________________________________|
Foundation Home
Repository List
Development Mailing List
Testing Mailing List
Announcement Mailing List
Central Wiki
Submit a Bug
IRC
Download Extension
These documents are under active development and discussion.
Credit: This Google Summer of Code content is licensed under the CC Attribution-Noncommercial-Share Alike 3.0 Unported license furnished by the Sahana Software Foundation.