Use separate connections for isolated third-party trackers

RESOLVED FIXED in Firefox 68

Status

()

enhancement
P2
normal
RESOLVED FIXED
4 months ago
13 days ago

People

(Reporter: Ehsan, Assigned: Ehsan)

Tracking

(Depends on 1 bug, Blocks 1 bug)

unspecified
mozilla68
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox68 fixed)

Details

(Whiteboard: [anti-tracking][necko-triaged])

Attachments

(7 attachments)

Right now with Enhanced Tracking Protection enabled, two third-party tracking connections from two separate tabs for example (or a third-party tracking connection from a tab and a first-party tracking connection from another tab) may end up sharing the same connection together, which would allow the tracker to tie the user's browsing across multiple tabs together on the server side (similar to bug 1283319.)

We need to add the top-level page's origin to the nsHttpConnectionInfo's hash key for third-party tracking channels in order to prevent this from happening.

Whiteboard: [anti-tracking]

Gary said he would be interested to take this. Here is some info on how a possible for this could work.

The core of the fix would be in nsHttpConnectionInfo::BuildHashKey(), through ensuring that we mix in the origin of the top-level document if our channel is an third-party tracking resource. In order to do this, we need to know two things: whether the channel is an isolated third-party tracking resource, and the origin of the top-level document.

You can determine whether the channel is an isolated third-party tracking resource using:

mIsThirdPartyTrackingResource &&
      !AntiTrackingCommon::IsFirstPartyStorageAccessGrantedFor(this, mURI,
                                                               nullptr)

We already compute this once when connecting to the network here: https://searchfox.org/mozilla-central/rev/f1c7ba91fad60bfea184006f3728dd6ac48c8e56/netwerk/protocol/http/nsHttpChannel.cpp#3911. You'd want to compute this a bit earlier in BeginConnect() around https://searchfox.org/mozilla-central/rev/f1c7ba91fad60bfea184006f3728dd6ac48c8e56/netwerk/protocol/http/nsHttpChannel.cpp#6430. You should probably call the same code in a helper function or something and assign the result to a boolean member and use it in both places to avoid calling IsFirstPartyStorageAccessGrantedFor() twice.

The origin of the top-level document can be obtained from the load info object: https://searchfox.org/mozilla-central/rev/f1c7ba91fad60bfea184006f3728dd6ac48c8e56/netwerk/base/nsILoadInfo.idl#900

Testing this isn't as simple as testing bug 1283319. I think you'd want to add a mochitest which sets up test trackers, then loads a third-party tracking iframe, and then looks at the document's channel and reads the connectionInfoHashKey attribute from it.

Assignee: nobody → xeonchen
Priority: -- → P2
Whiteboard: [anti-tracking] → [anti-tracking][necko-triaged]

The patch in bug 1500533 makes us call SetPrivate(true) on the nsHttpConnectionInfo object belonging to an isolated third-party tracking channel, which is part of what we needed to do here. So the patch needed here can probably be built on top of what we have there.

See Also: → 1500533

Tanvi, do we have a timeline for this bug? (Gary and I need to sort out his priority.)

Flags: needinfo?(tanvi)

From Anti-tracking Engineering meeting:

  1. We are targeting 68 Nightly.
  2. Ehsan will ping Gary when bug 1500533 is done.
Flags: needinfo?(tanvi)
Flags: needinfo?(senglehardt)
Keywords: dev-doc-needed

I'm picking this one since it's the continuation of bug 1500533.

Assignee: xeonchen → ehsan

Building the hashkey for these objects will soon depend on the isolated flag,
therefore we need to ensure that it is available when cloning the objects
inside the constructor. This patch refactors the clone method to avoid using
SetIsolated().

I'll wait until this lands to document (keeping ni). Thanks for flagging me -- I'm excited to see progress here :).

(In reply to Steven Englehardt [:englehardt] from comment #16)

I'll wait until this lands to document (keeping ni).

Sounds good!

Pushed by eakhgari@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/9191d987a9e1
Part 1: Avoid calling AntiTrackingCommon::IsFirstPartyStorageAccessGrantedFor() more than once per channel; r=michal
https://hg.mozilla.org/integration/autoland/rev/4a5475f6aa49
Part 2: Represent whether the channel is isolated by anti-tracking as a separate axis on the connection info hash key; r=michal
https://hg.mozilla.org/integration/autoland/rev/c316d49df8c4
Part 3: Only consider third-party tracking resources as isolated channels; r=michal
https://hg.mozilla.org/integration/autoland/rev/5cbdeb635a3e
Part 4: Refactor the code for computing the origin of the top window for a channel and remember its result on the channel object; r=michal
https://hg.mozilla.org/integration/autoland/rev/969945148b3d
Part 5: Pass the top window origin to nsHttpConnectionInfo objects when constructing them; r=michal
https://hg.mozilla.org/integration/autoland/rev/ebad998aae7a
Part 6: Use separate network connections for isolated third-party trackers; r=michal
https://hg.mozilla.org/integration/autoland/rev/037390836504
Part 7: Pass the isolated flag to the nsHttpConnectionInfo constructor when cloning the object; r=michal
Regressions: 1547596
Status: RESOLVED → REOPENED
Flags: needinfo?(ehsan)
Resolution: FIXED → ---
Target Milestone: mozilla68 → ---

Bug 1547596 was caused because of https://hg.mozilla.org/mozilla-central/rev/969945148b3d#l1.164. Here we would be trying to deserialize a string saved by an older build of Firefox which doesn't include mTopWindowOrigin. The fix is to move the code to serialize/deserialize this new member to the very end obviously.

I also added some comments about this subtle semantics for the next person to add a new member to AltSvcMapping.

Flags: needinfo?(ehsan)
Pushed by eakhgari@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/47c353bd446d
Part 1: Avoid calling AntiTrackingCommon::IsFirstPartyStorageAccessGrantedFor() more than once per channel; r=michal
https://hg.mozilla.org/integration/autoland/rev/6b122a9ce1a4
Part 2: Represent whether the channel is isolated by anti-tracking as a separate axis on the connection info hash key; r=michal
https://hg.mozilla.org/integration/autoland/rev/c79109688f29
Part 3: Only consider third-party tracking resources as isolated channels; r=michal
https://hg.mozilla.org/integration/autoland/rev/c22a48c48548
Part 4: Refactor the code for computing the origin of the top window for a channel and remember its result on the channel object; r=michal
https://hg.mozilla.org/integration/autoland/rev/86be6123ca53
Part 5: Pass the top window origin to nsHttpConnectionInfo objects when constructing them; r=michal
https://hg.mozilla.org/integration/autoland/rev/3e02969bf413
Part 6: Use separate network connections for isolated third-party trackers; r=michal
https://hg.mozilla.org/integration/autoland/rev/251ef3905140
Part 7: Pass the isolated flag to the nsHttpConnectionInfo constructor when cloning the object; r=michal
Depends on: 1557178
Regressions: 1562837
You need to log in before you can comment on or make changes to this bug.