Closed Bug 1616784 Opened 2 months ago Closed 1 month ago

Support generating a hashed origin

Categories

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

task

Tracking

()

RESOLVED WONTFIX

People

(Reporter: dimi, Unassigned)

References

(Blocks 1 open bug)

Details

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.

Blocks: 1612373

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!

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

Summary: Support generating a hashed principal → Support generating a hashed origin

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.

  1. 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”),
]
  1. 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?

Flags: needinfo?(jjones)
Flags: needinfo?(dkeeler)
Flags: needinfo?(jjones) → needinfo?(tvandermerwe)

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

Flags: needinfo?(dkeeler)

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

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.

Status: NEW → RESOLVED
Closed: 1 month ago
Flags: needinfo?(tvandermerwe)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.