Make Permission Manager support legacy settings without first party domain
Categories
(Core :: Permission Manager, enhancement, P2)
Tracking
()
People
(Reporter: xeonchen, Assigned: xeonchen)
References
Details
In bug 1330467, permissions stored in Permission Manager contains first party domain information, this makes existing settings incompatible with newer version.
This doesn't affect many Firefox user since the pref of first party isolation is disabled by default.
However, Tor Browser users will be affected.
To minimize the effect, we should make it compatible with existing data and let legacy settings also covered in the new architecture.
|
||
Comment 1•5 years ago
|
||
Is it really such a big deal for Tor Browser users to lose their permission settings for the sake of gaining a better model? It sounds like a trade-off we should at least consider vs. complicating the permission manager forever.
|
||
Comment 2•5 years ago
|
||
Related to comment 1, is this something that Tor Browser could perhaps do itself in JS higher up the stack? (Not really familiar with their tooling/upgrade process)? It would be nice to at least check with them to see if there are other options available.
|
||
Comment 3•5 years ago
|
||
This seems related to our discussion today about legacy principals. Just looping you in in-case you haven't seen it.
|
|
||
Comment 4•5 years ago
|
||
(In reply to Ehsan Akhgari (:ehsan) from comment #2)
Related to comment 1, is this something that Tor Browser could perhaps do itself in JS higher up the stack? (Not really familiar with their tooling/upgrade process)? It would be nice to at least check with them to see if there are other options available.
Yeah, that might not be a bad idea. Talking to Gary it seems like the migration step would need to transform https://foo.example.com to https://foo.example.com^firstPartyDomain=example.com. We could do this in the "UI" migration code here: https://searchfox.org/mozilla-central/rev/99a2a5a955960b0e58ceade1db1f7652d9db4ba1/browser/components/BrowserGlue.jsm#2580, but maybe there's also a more appropriate place for it.
I feel like it's pretty safe to just assume that we can turn all existing permissions into first-party only permissions (so that third parties would need to request permission again). First-party-only permissions is the model we plan to use with Feature Policy anyway.
|
||
Comment 5•5 years ago
|
||
(In reply to Johann Hofmann [:johannh] from comment #1)
Is it really such a big deal for Tor Browser users to lose their permission settings for the sake of gaining a better model? It sounds like a trade-off we should at least consider vs. complicating the permission manager forever.
It is not a supported configuration for Tor Browser to retain history. So there are no saved permissions.
Firefox users who have enabled FPI will lose the data however. I am not very concerned about losing that data; but I am concerned about orphaning it on disk where it is never cleaned up.
|
|
||
Comment 6•5 years ago
|
||
It is not a supported configuration for Tor Browser to retain history. So there are no saved permissions.
Ok, right, this is probably the 10th time I have forgotten about this. So the premise of this bug is sort of invalid, right? The question is: Is the FPD attribute added to origins even when FPI is turned off? Then we would need to perform a migration step for all Firefox users. Otherwise it seems like we can just WONTFIX this bug for the few Firefox users who have FPI turned on. Their permissions will be cleared sooner or later along with history and they can still inspect and delete them in the permission management UI (because they would still be listed there).
|
||
Comment 7•5 years ago
|
||
As a general note, I think we should start to always set all kinds of OA all the time and only ever compare them if specific prefs (like eg. FPI) are flipped.
Consider the following example: We serialize Principals to disk and then restart Firefox in a different mode. In this sceneario the serialized Principals will not have the right OA set which will lead to subtle corner cases and bugs.
:jkt is improving principal serialization and principals in general at the moment - so fixing that problem is something we might do during that project as well.
Just as a side note, not directly appicable to the bug here though.
|
|
||
Comment 8•5 years ago
|
||
(In reply to Johann Hofmann [:johannh] from comment #6)
It is not a supported configuration for Tor Browser to retain history. So there are no saved permissions.
Ok, right, this is probably the 10th time I have forgotten about this. So the premise of this bug is sort of invalid, right? The question is: Is the FPD attribute added to origins even when FPI is turned off?
We add it in a couple of cases (e.g. when querying various services in the background in order to segregate their cookie jar away from the user's) but we don't save permission on their behalf.
Then we would need to perform a migration step for all Firefox users. Otherwise it seems like we can just WONTFIX this bug for the few Firefox users who have FPI turned on. Their permissions will be cleared sooner or later along with history and they can still inspect and delete them in the permission management UI (because they would still be listed there).
Looks like this is the course of action here.
(In reply to Christoph Kerschbaumer [:ckerschb] from comment #7)
As a general note, I think we should start to always set all kinds of OA all the time and only ever compare them if specific prefs (like eg. FPI) are flipped.
I am unsure how to parse this... That's definitely not how our OA comparisons work. Plus, we don't persist what prefs were in effect when a given OA was serialized, so I'm not sure how this could even work over time (how would we know what OA attributes to use for comparison based on current prefs when we don't know what prefs caused us to serialize them?)
Consider the following example: We serialize Principals to disk and then restart Firefox in a different mode. In this sceneario the serialized Principals will not have the right OA set which will lead to subtle corner cases and bugs.
Well, shouldn't we take care to not put users into such paths in the first place? In cases for example where we've removed attributes from OA we've done so...
Just as a side note, not directly appicable to the bug here though.
Yep, don't think so! :-)
|
Assignee | |
Comment 9•5 years ago
|
||
Based on the discussion we had above, I'm going to close this as WONTFIX. Thank you everyone.
Description
•