In bug 1364852, it became apparent that it is possible for some APIs (like quota storage / indexeddb, and maybe others - I have *not* audited our codebase for problems of this kind...) to return data for domains that the PSL currently labels as toplevel. This could potentially lead to data (be it storage or cookies or something else) and/or permissions to no longer be properly segregated according to the PSL. I believe this is a problem. Once example.com is in the PSL, it is not possible for a site to set a cookie, store data in indexeddb, or ask for permissions, that apply to all of example.com . The fact that we retain such data / permissions if they were created prior to example.com being added to the PSL is potentially problematic. That we return it when asked for it /might/ equally be problematic - it depends where these checks are supposed to happen. In bug 1364852, we're enumerating all of storage. In a certain sense, it makes sense that this returns everything we have on disk, even things that no longer make sense given the current PSL. But I'm wondering: - if we shouldn't just delete all of it once the PSL changes - if there are other places where we provide access to this data where that *is* problematic. Jan, at least for indexeddb I guess you're the right person to ask about this, but if you (or anyone else on the CC list) has ideas about what we do for cookies or permissions, that would be helpful. Gerv, who else could help look into this? I don't know who works on the engineering side of the PSL and how various bits of Gecko/Necko use it...

A lot of the APIs you cite are origin-bound. If example.com became a public suffix, it could no longer become an origin of sorts either meaning the data cannot be accessed. (This is an argument for removing the data.) For cookies however that is not the case. We'd end up sending old example.com cookies to any subdomain. So we should probably make sure to remove those too.

The PSL changes regularly. I don't know about the performance consequences of checking all our data against the PSL every time someone upgrades Firefox... The other option is every call site re-checking at time of use but that might have performance issues too. I don't think there's a specific person who works on the PSL for Firefox, and I don't really track how Firefox uses it carefully. Gerv

Jason, please find somebody to look at this bug.

Bulk priority update: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Removing old NI