962326 - Create API for getting nsILoadInfo and HostStringForSeparation

Status: RESOLVED WONTFIX

(Core :: Networking: Cookies, defect)

Description

[Mike Perry]

Attachment: Add a mozIThirdPartyUtil.getFirstPartyURI api. Draft/WIP patch.

In order to more easily implement first party identifier, cache, and dom storage isolation, it is useful to have an API that allows you to quickly obtain the first party URI for a given channel or document.

We've implemented this for Tor Browser based on the original mozIThirdPartyUril.getOriginatingURI API that was removed. It has been included back into this patch.

This may need some refinement in terms of arguments. We found it more expedient to make one API take both arguments, and try the channel codepath first and the document if that failed. This simplified our other first party isolation patches, but I suppose it may not be the cleanest approach in terms of immediately obvious semantics.

The patch is against FF24ESR. It would be great to get some comments first before we attempt to rebase this or write test cases.

Comment 1

[Justin Dolske [:Dolske]]

I think bug 513560 removed this originally?

Comment 2

[Justin Dolske [:Dolske]]

Not sure who's an appropriate reviewer/feedbacker for this. bz, suggestions?

Comment 3

[Boris Zbarsky [:bzbarsky]]

Hrm.  Ignoring that it's all sorts of broken with out-of-process iframes, if we ever do those... 

dwitte isn't active anymore, right?  Ehsan, Honza is this something one of you'd be willing to review?

Comment 4

[Honza Bambas (:mayhemer)]

Not 100% my area, but I could do that.  And I need some background what this is purposed for exactly.  The "isolation" is not quite clear to me.

Comment 5

[Mike Perry]

(In reply to Honza Bambas (:mayhemer) from comment #4)
> Not 100% my area, but I could do that.  And I need some background what this
> is purposed for exactly.  The "isolation" is not quite clear to me.

We aim to prevent all of the ways that third party content elements can track a user across different first party domains, with as minimal impact to the function of those features as possible (this means we'd prefer to "double-key" third party cookies rather than disable them, to use a basic example).

This idea is explained more formally in the first privacy requirement for Tor Browser ("Cross-Origin Identifier Unlinkability"):
https://www.torproject.org/projects/torbrowser/design/#privacy

To see what we currently do:
https://www.torproject.org/projects/torbrowser/design/#identifier-linkability

If either of these explainations (especially the ones in the design doc) could use more canonical terms or better wording, that would be helpful. I've found this to be a very difficult idea to get across to people who have already deeply internalized the existing way third parties behave on the web. Paradoxically, from personal experience, I've also found exactly the type of first party information independence we're aiming for in Tor Browser is what naive web users assume is true (until informed otherwise by the rather extensive media coverage of the issue).

Comment 6

[Mike Perry]

Honza: Specifically, see the meta bug this ticket links to, and its child tickets for stuff we need this type of API for: https://bugzilla.mozilla.org/show_bug.cgi?id=939354

Like I said, I am not 100% sure this API is the cleanest way to provide this information, but it was expedient to us to have it behave in this way. Open to suggestions.

Comment 7

[(no longer active)]

(In reply to Justin Dolske [:Dolske] from comment #1)
> I think bug 513560 removed this originally?

I don't think that's the right bug number.  Looking through our commit logs, I can't find any reference to a formerly existing getFirstPartyURI API at all.

Comment 8

[Georg Koppen]

(In reply to :Ehsan Akhgari (needinfo? me!) from comment #7)
> (In reply to Justin Dolske [:Dolske] from comment #1)
> > I think bug 513560 removed this originally?
> 
> I don't think that's the right bug number.  Looking through our commit logs,
> I can't find any reference to a formerly existing getFirstPartyURI API at
> all.

What you are probably looking for is bug 769589.

Comment 9

[yan]

Starring this because it would be highly useful for EFF's Privacy Badger (https://www.eff.org/privacybadger).

Comment 10

[Tanvi Vyas[:tanvi]]

Almost all gecko created channels now have a loadInfo object that contains a loadingPrincipal.  Would that help here? 

https://mxr.mozilla.org/mozilla-central/source/netwerk/base/nsNetUtil.h#223
https://mxr.mozilla.org/mozilla-central/source/docshell/base/LoadInfo.h

Comment 11

[Tanvi Vyas[:tanvi]]

(In reply to Tanvi Vyas [:tanvi] from comment #10)
> https://mxr.mozilla.org/mozilla-central/source/netwerk/base/nsNetUtil.h#223
> https://mxr.mozilla.org/mozilla-central/source/docshell/base/LoadInfo.h

Should have linked here instead:
https://mxr.mozilla.org/mozilla-central/source/docshell/base/nsILoadInfo.idl#57
https://mxr.mozilla.org/mozilla-central/source/docshell/base/nsILoadInfo.idl#95

Comment 13

[MSvB]

(In reply to Tanvi Vyas [:tanvi] from comment #11)
> Should have linked here instead:
> https://mxr.mozilla.org/mozilla-central/source/docshell/base/nsILoadInfo.idl#57
> https://mxr.mozilla.org/mozilla-central/source/docshell/base/nsILoadInfo.idl#95
>
MXR (HG gateway): 'This file does not exist.' Moved from docshell to netwerk it seems:

https://mxr.mozilla.org/mozilla-central/source/netwerk/base/nsILoadInfo.idl

...with identical line numbers. Or on beta and release (rathern than trunk) at the same path:

https://mxr.mozilla.org/mozilla-(beta|release)/source/docshell/base/nsILoadInfo.idl

Comment 14

[Tanvi Vyas[:tanvi]]

relinking with new line numbers - 
Using the loadingDocument, loadingPrincipal, or triggeringPrincipal from a channel's loadinfo should take care of this for you: https://mxr.mozilla.org/mozilla-central/source/netwerk/base/nsILoadInfo.idl#125

Comment 15

[Dave Huseby [:huseby]]

After this morning's Tor Standup, the decision is to rewrite the ThirdPartyUtil class member functions to use the nsILoadInfo struct to get the information needed.  If the functions just become simple wrappers around nsILoadInfo, then we'll change all of the ThirdPartyUtil call sites to use nsILoadInfo instead.  If not, then we'll keep the new ThirdPartyUtil that uses nsILoadInfo.

Comment 16

[Arthur Edelstein [:arthur]]

For reference, here are links to the latest Tor Browser patches that make changes to ThirdPartyUtil.cpp, ThirdPartyUtil.h, and mozIThirdPartyUtil.idl:

​* https://torpat.ch/5742
​* https://torpat.ch/10819
* ​https://torpat.ch/13900
* ​https://torpat.ch/13670
* ​https://torpat.ch/15502

Comment 17

[Dave Huseby [:huseby]]

Because of origin attributes, we will no longer need to customize the ThirdPartyUtil changes and we won't need to look at the loadInfo data at all.  Closing.