Hi J.C., Dana,
We would like to consult you about our plan to hide origin names from content processes(the scope is limited to origins used by anti-tracking).
Currently in anti-tracking, when a third-party site tries to access the storage, we use top-level window’s origin as the key to lookup permission tables to see whether a third-party site has the permission.
But to achieve site isolation(project Fission), we intend to remove the access of top-level origin in 3rd-party sites.
Our idea is:
Generate a per-profile unique identifier(UUID) in the parent. The UUID should NOT be exposed to child processes.
For every document, we generate a “hashed origin” in the parent by using :
HMAC-SHA1(per-profile UUID(as key), document’s origin(as data))
The hashed origin will be propagated to the child process that owns the document.
Note. HMAC-SHA1 is just an example here, please let us know if you have any comment on that.
- When a top-level grants permission to a site, We create a corresponding permission entry in the parent, and the entry will be propagated to child processes that are under the top-level document.
For example, if we grant storage permission to tracker.com and example.com when their top-level is top-level.com
The following entries will be sent to tracker.com & example.com’s process, and are stored in the top-level's
- Testing whether a site has the storage permission in the child:
A site should be able to retrieve its origin’s hash(
HMAC-SHA1(UniqueUUID, site's origin)) and the permission list from top-level window's
Then we use the hash to match against entries in the permission list. If a match is found, we grant the permission.
Do you think this makes sense?