Question about "flush-site-data"

[DeadSix27]

Is there a way to only flush the site data for the ACTIVE tab? Currently I'm doing it manually by opening the dev console and going to the indexed/cookies etc tabs and delete it there..

[mk-fg]

Hi,

Not in the current version, but the actual things that it does is:

  browser.browsingData.remove( {},
      {cache: true, cookies: true, indexedDB: true, localStorage: true, serviceWorkers: true} )
    .then(res => browser.tabs.query({}))
    .then(tabs => tabs.forEach(
      tab => browser.tabs.executeScript(tab.id, {code: 'sessionStorage.clear()'}) ))

Where tabs.query({}) can use {active: true} instead of empty queryObj, and also to get a URL from that tab. And then that hostname from that URL can be passed to browsingData.remove(...) in hostnames key of RemovalOptions instead of empty object too.

Would be a good idea to add this on the right click on the button and a separate hotkey, which I also wanted to use occasionally but didn't think of adding, thanks for mentioning it. Will probably test and add soon-ish.

[mk-fg]

Although one potential issue I can forsee is that it's not just one hostname with cookies (and other data) that gets loaded in the tab, but potentially dozens or even hundreds (on a really ad-ridden places if you don't use uBlock/uMatrix) of third-party content from all over the place, so might actually be impossible to query in this kind of simple extension, and require some dedicated cookie-tracking one (many of which I think already exist).

[DeadSix27]

that is true, but this could be mentioned in the button as limitation, deleting all the main Domains data is still useful tho

[mk-fg]

Looking into this, found that State Partitioning in Firefox is rather complex these days, and there are some other issues.

• "cookies" API can be used to get and cleanup all cookies in tab's "cookieStoreId", for both "topLevelSite" partition key and "firstPartyDomain" (if first-party-isolation is enabled), which I think should include cookies set by all third-party requests.

• Data not set by HTTP requests (via cookie headers) and accessible from main document's JS - like localStorage - can be flushed using hostname from the URL (can't be changed from JS on the page, should be accurate).

• "cache" and maybe "pluginData" for third-party content on the page can't be removed without knowing which third-party domains it might be stored for.

• Sites can/do load iframes with different URLs and separate JS running in them, with its separate localStorage/indexedDB, that can interact with main document's JS.

  These iframes can load, redirect/change their URLs, send/store/exchange data with main JS and get removed, so enumerating them at one specific moment (when pressing button) shouldn't be useful. Without knowing URLs of these iframes, there seem to be no way to remove this data (unlike cookies, which have "topLevelSite" and "firstPartyDomain").

• As far as I can tell, there's no good way to tell "what third-party content was ever loaded in this tab", without going to WebRequest API and literally tracking everything that is loaded, as it is being loaded, like uBlock/uMatrix extensions do it.

So I think implementation will either have to be complex and actually track/store all requests, or will have to be quite leaky and unreliable due to some of the issues above, unfortunately.

But State Partitioning should actually key everything internally - including all cookies, JS data, caches, network connections, etc - by the URL opened in the tab, so I think MAYBE "Ctrl-I -> Security -> Clear Cookies and Site Data" does the right thing and nukes all data related to this tab. Devtools should also track all these third-party domains I think, and seem to be indeed a more reliable way to do it, without big "MAYBE". Another way to get "tab clean of any data" seem to be opening Private Window/Tab, if that's what this cleanup is needed for.

I don't use browser with many tabs/services (so flusing it fully isn't a big issue), don't need this often, so will probably stick with Ctrl-I or DevTools options myself (if I'll remember about them), as they seem to be way more reliable than a simple addon implementation, and complex implementation with tracking all requests, for just such rare occasions, doesn't seem to make sense to have/maintain with my use-case.

If you need such button much more often, and workarounds above (like the devtools cleanup you already using) aren't good enough, I'd suggest checking if maybe some extension doing what I've described above as "complex" way to do it exists (tracking all requests for potential cleanup after them), or if not, it'd probably best be implemented as an entirely separate button/thing, as it'd be quite different and more complex code than a simple oneshot script here.

So alas, no easy and simple solution to quickly implement on top of this button, it appears.

Still, thanks again for bringing up the issue, made me look into how this data is tracked and partitioned, and the pitfalls of selective cleanup to watch-out for.

[DeadSix27]

Thanks for the in-depth look at it! I'll see what I can find otherwise yeah, sticking to dev tools.