Add a pref to control if Blob URL is always consider as first-party.
Categories
(Core :: Privacy: Anti-Tracking, task)
Tracking
()
People
(Reporter: timhuang, Unassigned)
References
Details
We make Blob URL always first-party in Bug 1634664. This might affect Tor browser. So, It would be good if we can put this behind a pref. Then, Tor browser can control this behavior if they want.
|
||
Comment 1•5 years ago
|
||
I think ideally the pref we use here is FPI as this regressed FPI. Unless Tor confirms they want the same behavior, but from https://trac.torproject.org/projects/tor/ticket/15502 I think that's not true.
|
||
Comment 2•5 years ago
|
||
Tagging Tor. I do not have a guess at preference at this time.
|
||
Comment 3•5 years ago
|
||
(In reply to Anne (:annevk) from comment #1)
I think ideally the pref we use here is FPI as this regressed FPI. Unless Tor confirms they want the same behavior, but from https://trac.torproject.org/projects/tor/ticket/15502 I think that's not true.
No, I think we don't want that but it's a bit hard to tell given that bug 1634664 is not really providing much context. I see it's in the Privacy:Anti-Tracking component. So, could someone elaborate on how just declaring blob URLs generally to be first party helps privacy here? I seem to be missing some bits. Maybe Tim knows so ni.
That said, yes, please use the FPI pref as Anne suggested.
|
Reporter | |
Comment 4•5 years ago
|
||
Baku should be the best person to answer this. Redirect ni to him.
|
||
Comment 5•5 years ago
|
||
Bug 1634664 was filed because dFPI and FPI are incompatible with the web and with web-platform-tests. But more than talking about why we have these incompatibilities, I would like to talk about why there were treated as 3rd party.
BlobURLs are same-site because they can be used only by the origin who created them. Internally they use the same nsIPrincipal and they contain data generated or already known by their origin.
The main reason why we used to treat them as 3rd parties is that they can be used as a tracking vector between same-origin contexts in different user-agent clusters (different tabs, without opener/parent relationships, for instance). This is the thing we should fix. We should remove the tracking vector.
Anne and I spoke about restricting blobURLs to the same agent-cluster for this reason. See: https://github.com/w3c/FileAPI/issues/153
As soon as we receive a spec feedback, I'm ready to submit a fix.
|
|
||
Comment 6•4 years ago
|
||
(In reply to Andrea Marchesini [:baku] from comment #5)
Bug 1634664 was filed because dFPI and FPI are incompatible with the web and with web-platform-tests. But more than talking about why we have these incompatibilities, I would like to talk about why there were treated as 3rd party.
BlobURLs are same-site because they can be used only by the origin who created them. Internally they use the same nsIPrincipal and they contain data generated or already known by their origin.
So this means if a blobURL is created by origin A and origin B embeds origin A in an iframe which is trying to use that blobURL, that is failing? I remember when dealing with that issue years ago we saw that such calls were succeeding, which in the first place made us isolating blob URLs to the first-party domain. Or maybe you mean only origin A can use those formerly created blobURLs regardless where it is embedded? That's indeed the scenario we want to avoid.
The main reason why we used to treat them as 3rd parties is that they can be used as a tracking vector between same-origin contexts in different user-agent clusters (different tabs, without opener/parent relationships, for instance). This is the thing we should fix. We should remove the tracking vector.
I see.
|
|
||
Comment 7•4 years ago
|
||
So this means if a blobURL is created by origin A and origin B embeds origin A in an iframe which is trying to use that blobURL, that is failing?
No it doesn't not. 'A' will be able to use the blobURL.
I see.
Would the user-agent cluster isolation be enough to reduce the blobURL fingerprinting attack?
|
|
||
Comment 8•4 years ago
|
||
I don't think that helps Tor as FPI does not isolate agent clusters, see bug 1628783. I still think our best course of action is to not touch FPI at all (apart from fixing crashes) and get back to possible dFPI and FPI convergence at a later point, once we have a clearer understanding of things. I.e., I recommend we revert the change made to blob URLs.
|
|
||
Comment 9•4 years ago
|
||
(In reply to Anne (:annevk) from comment #8)
I don't think that helps Tor as FPI does not isolate agent clusters, see bug 1628783. I still think our best course of action is to not touch FPI at all (apart from fixing crashes) and get back to possible dFPI and FPI convergence at a later point, once we have a clearer understanding of things. I.e., I recommend we revert the change made to blob URLs.
I actually meant to reply to this comment but forgot about that, sorry. Yeah, that plan sounds to me like a good one. We have evaluating dFPI vs. FPI on our plate after we finally made the switch to ESR 78 and get Fenix based mobile builds out, which should happen rather soon. So, we should have a clearer picture and better understanding what we want + what the trade-offs look like by the end of this year/early 2021.
Description
•