Some data can be retained across containers and across the private browsing mode barrier.
See https://bugzilla.mozilla.org/show_bug.cgi?id=906448
You may want to vote for that bug or comment on it.
I don't think any settings can get around this unfortunate bug, but if you find something, please let me know.
You can mitigate with one of the two methods:
Choose whichever you find best for you.
That ticket is old AF. And it uses the lucible PoC which has issues / limitations you need to be aware of. That said, the PoC can still demonstrate that ETags can be used to track.
So someone would need to confirm that containers do not clean etags (if they clean the cache for all data with that contextid then it should not be at risk), and that PB mode does not clean etags (but PB mode clears the cache AFAIK), so I'm calling this BS until someone proves otherwise. That said, do containers use existing cache? Does PB mode? IDK exactly. FPI isolates cache. I would assume the other two OA's do as well, but unless cache is tagged with OAs, then how would it clean it.
According to https://bugzilla.mozilla.org/show_bug.cgi?id=1474235 the issue is current, but it's not actually ETAG related.
There's definitely something amiss. Hopefully it will get assigned to someone to get fixed... the presence of current activity is encouraging.
No, its etag AFAICT .. someone erroneously said it was about formfill. Anyway, I'm calling it BS for now
BTW, what is OA?
Origin Attributes - eg PB Mode, Container, First Party Origin
No, its etag AFAICT .. someone erroneously said it was about formfill.
Seems like they didn't take into account the fact that the PoC doesn't show updated results immediately. We've been there. It feels almost like playing sudoku or some such shit once you realize that.
do containers use existing cache?
Would explain why Stoically recommended clearing the cache, etc before using his TC extension.
Clearing your cookies and cache to get a clean-start, logging into your social-media accounts only within a container and do the rest of your browsing outside that container already enhances your privacy by a great deal.
... or maybe it would only be useful in that specific scenario. This got me wondering...
Seems like they didn't take into account the fact that the PoC doesn't show updated results immediately.
In fact.. after re-reading the original STR in that bugzilla ticket, I'm thinking the same happened to that guy too.
Really, that PoC is almost nightmare-inducing. I said it's like sudoku once you realize how it works, but before that it's like a plausible creepypasta. Paranoia-fueling
When I flipped on FPI, I cleared everything under ctrl-alt-del (and i had no IDB, this was back when IDB didn't get cleared) and I even checked sql files. I even told everyone here to do that (https://github.com/ghacksuserjs/ghacks-user.js/issues/199 ). No point hanging onto old data that should not be called/used. So I can totally understand Cookie-AutoDelete and TC with the same instructions
FPI is coming to permissions - I guess I'll have to do that as well - wipe permissions and start from scratch (maybe export the data first - probably not much in there). i.e (imaginary fields)
^^ this info about clearing all persistent data when moving to FPI is now actually in the wiki - https://github.com/ghacksuserjs/ghacks-user.js/wiki/1.3-Implementation
- First Party Isolation (4001) is enabled by default
- It is recommended that you clear (Ctrl-Shift-Del) everything (except passwords and site preferences) when first enabling this, so non-Origin Attribute data is wiped
So that's cool :hi-five myself:
Closing this: its not a bug IMO. If you care about it, follow the bugzilla