Closed
Bug 962326
Opened 11 years ago
Closed 9 years ago
Create API for getting nsILoadInfo and HostStringForSeparation
Categories
(Core :: Networking: Cookies, defect)
Core
Networking: Cookies
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: mikeperry, Assigned: huseby)
References
Details
(Whiteboard: [tor])
Attachments
(1 file)
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•11 years ago
|
||
I think bug 513560 removed this originally?
Component: General → Networking: Cookies
Product: Firefox → Core
Comment 2•11 years ago
|
||
Not sure who's an appropriate reviewer/feedbacker for this. bz, suggestions?
Flags: needinfo?(bzbarsky)
![]() |
||
Comment 3•11 years ago
|
||
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?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(honzab.moz)
Flags: needinfo?(ehsan)
Flags: needinfo?(bzbarsky)
![]() |
||
Comment 4•11 years ago
|
||
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.
Flags: needinfo?(honzab.moz)
Reporter | ||
Comment 5•11 years ago
|
||
(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).
Reporter | ||
Comment 6•11 years ago
|
||
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•11 years ago
|
||
(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.
Flags: needinfo?(ehsan)
Comment 8•11 years ago
|
||
(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.
Updated•11 years ago
|
OS: Windows 7 → All
Hardware: x86 → All
Reporter | ||
Updated•11 years ago
|
Whiteboard: [tor]
Starring this because it would be highly useful for EFF's Privacy Badger (https://www.eff.org/privacybadger).
Comment 10•10 years ago
|
||
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•10 years ago
|
||
(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•10 years ago
|
||
(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
Assignee | ||
Updated•9 years ago
|
Assignee: nobody → huseby
Comment 14•9 years ago
|
||
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
Assignee | ||
Updated•9 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 15•9 years ago
|
||
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.
Assignee | ||
Updated•9 years ago
|
Summary: Create APIs to obtain the first party (urlbar) URL for a channel or document → Create API for getting nsILoadInfo and HostStringForSeparation
Comment 16•9 years ago
|
||
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
Assignee | ||
Comment 17•9 years ago
|
||
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.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•