1616784 - Support generating a hashed origin

Status: RESOLVED WONTFIX

(Core :: Privacy: Anti-Tracking, task, P1)

Description

[Dimi Lee [:dimi][:dlee]]

The idea here is to create a per-profile unique identifier(UniqueUUID), and use that to generate a hashed origin(For example, SHA1(UniqueUUID + origin)).

This allows us to put the hashed value to WindowContext/BrowsingContext as a key to lookup permission without leaking 3rd party origin to content processes.

The per-profile unique identifier should only be accessible in the parent.

Comment 1

[(no longer active)]

I'd appreciate if you can circle your plans here with the crypto engineering team to make sure what we're doing would make sense from the perspective of protecting the names of the origins the content process shouldn't be allowed to see. Thanks!

Comment 2

[Dimi Lee [:dimi][:dlee]]

(In reply to :ehsan akhgari from comment #1)

I'd appreciate if you can circle your plans here with the crypto engineering team to make sure what we're doing would make sense from the perspective of protecting the names of the origins the content process shouldn't be allowed to see. Thanks!

Sure, I'll do it.

Comment 3

[Dimi Lee [:dimi][:dlee]]

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:

1. Generate a per-profile unique identifier(UUID) in the parent. The UUID should NOT be exposed to child processes.

2. 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.

3. 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 WindowContext(top-level.com)

[
  HMAC-SHA1(UniqueUUID, “tracker.com”),
  HMAC-SHA1(UniqueUUID, “example.com”),
]

4. 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 WindowContext
   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?

Comment 4

[Dana Keeler (she/her) (use needinfo) (:keeler for reviews)]

Can you be more specific about what information is in which process?

Comment 5

[Dimi Lee [:dimi][:dlee]]

In the case of tracker.com, fb.com and iframe.com are all under the top-level example.com, and we grant permission to tracker.com & fb.com when their top-level is example.com

• In parent process, it has:

  • A unique per-profile UUID
  • A permission table which records “tracker.com can access storage when top-level is example.com” & “fb.com can access storage when top-level is example.com”
  • Permission entries granted for 3rd-party sites when the top-level is example.com. This is calculated in the parent by using the UUID and the permission table above.
    • [HMAC-SHA1(UUID, “tracker.com”), HMAC-SHA1(UUID, “fb.com”)]

• In tracker.com’s process, it can see:

  • Its hashed origin : HMAC-SHA1(UUID, “tracker.com”)
  • Permission entries : [HMAC-SHA1(UUID, “tracker.com”), HMAC-SHA1(UUID, “fb.com”)]

• In fb.com’s process, it can see:

  • Its hashed origin : HMAC-SHA1(UUID, “fb.com”)
  • Permission entries : [HMAC-SHA1(UUID, “tracker.com”), HMAC-SHA1(UUID, “fb.com”)]

• In iframe.com’s process, it can see:

  • Its hashed origin : HMAC-SHA1(UUID, “iframe.com”)
  • Permission entries : [HMAC-SHA1(UUID, “tracker.com”), HMAC-SHA1(UUID, “fb.com”)]

• In example.com’s process, it can see:

  • Its hashed origin : HMAC-SHA1(UUID, “example.com”)
  • Permission entries : [HMAC-SHA1(UUID, “tracker.com”), HMAC-SHA1(UUID, “fb.com”)]

In short, every child process can see its own “hashed origin” and a list of “hashed origin” containing entries we grant permission for its top-levels(there might be more than one top-level).

If there is another tab, second-tab.com, which embeds tracker.com and second-tab.tracker.com, and we grant permission to tracker.com & second-tab.tracker.com when their top-level is second-tab.com

• In tracker.com’s process, now it can see:
  • Its hashed origin : HMAC-SHA1(UniqueUUID, “tracker.com”)
  • Permission entries for example.com : [HMAC-SHA1(UUID, “tracker.com”), HMAC-SHA1(UUID, “fb.com”)]
  • Permission entries for second-tab.com : [HMAC-SHA1(UUID, “tracker.com”), HMAC-SHA1(UUID, “second-tab.tracker.com”)]

Let me know if there is anything unclear and needs more explanations, thanks

Comment 6

[Dimi Lee [:dimi][:dlee]]

We just had a meeting with Fission team, they suggested an alternative solution, which is looking up the permission during channel creation in the parent process and then pass the result back to the child.

In the idea, we don't need hash at all :)
We will use another bug to implement the new plan, close this one.