(In reply to Johann Hofmann [:johannh] from comment #4)
Thanks for clarifying, and you're right, this is exposing two interesting flaws and is definitely blocking turning on purging on Nightly:
Visiting https://www.amazon.com it's setting cookies for www.amazon.com and .amazon.com, but we only set the user interaction permission for https://www.amazon.com. When the purging code tries to do the permission check we test by origin, meaning that cookies for .amazon.com are deleted. Unfortunately telling the permission manager to not use exactHostMatch doesn't work because we're trying to match a non-subdomain entry against a subdomain entry instead of the other way around, which doesn't work.
This is bad and we should probably fix it. We have a few options, I guess:
- We could iterate through all permissions and test with
hasRootDomain, but that sounds a bit slow if the user has lots of permissions (which isn't unlikely).
I think this may not be too bad. Firstly I don't think performance should be a major goal here, since this whole task is running in the background in an iterative way. If we find that something here is taking too much time we can break down the work into more granular chunks. But more importantly I think we'd need to iterate through the permissions only once to collect the corresponding host names into an array or something an then iterate through that array to perform our
Is there any reason not to go with this option?
- We could update the nsPermissionManager exactHostMatch check to include a way to check for subdomain permissions when being passed the base principal, but it probably can't be the default behavior of exactHostMatch so that could get complicated.
Hmm, not sure how we would do this... Do you mean by enumerating all permissions or something like that? For example if you asked for https://amazon.com we could have permissions store for https://www.amazon.com, https://foo.amazon.com, https://really.long.origin.name.amazon.com, etc.
- We could always store storageAccessAPI permissions on the base domain, i.e. strip sub-domains at creation time, which to me feels like it wouldn't break any existing consumers if we make sure to pass the exactHostMatch flag, but it's a bit of a risk of course and we would close avenues for more fine-grained checks of this permission in the future.
That would make us forget which host the user has actually interacted with, no? But more importantly, users already have these permissions in their profiles, even if we want to go this way we still need a solution to correctly deal with old data found in profiles.
- We could invent a new permission type
storageAccessAPIBaseDomain or something like that, which explicitly only stores base domains.
Ugh, that would be unfortunate...
I'm not particularly excited about any of these. Ehsan, do you have any thoughts?
Oh, I forgot: Why is the cookie for www.amazon.com also deleted even though there's an interaction permission for it? That's because the clear data service uses option 1) and clears permissions by base domain, causing subsequent permission checks for www.amazon.com to fail if .amazon.com was cleared first 🤦♀️
Hmm, that actually looks like a bug to me. I'm not quite sure why we delete permissions from non-exact hosts in
deleteByHost whereas for other data which we delete by host it seems like we delete it from exact hosts (e.g. cookies). So it seems to me that we should probably switch that code to delete permissions from exact hosts only?