search

gorhill / httpswitchboard

Point & click to forbid/allow any class of requests made by your browser. Use it to block scripts, iframes, ads, facebook, etc.
GNU General Public License v3.0
1.33k stars 84 forks source link

Local storage management in HTTPSB #350

Closed ghost closed 10 years ago

ghost commented 10 years ago

We had been discussing local storage in issue #66. There is a need to reliably remove the (content of) local storage (also known as "super-cookies"). This is particularly important if we select "Allow local data to be set" in the Chrome cookie settings as a precondition for the new option discussed in above issue.

I've been pondering on local storage in general and must admit that I'm unsure how HTTPSB handles it:

  1. In this comment I had asked: "I'm not quite sure how HTTPSB handles local storage right now. The settings says: "Delete contents of local storage of blocked hostnames". But what are blocked hostnames? The ones in the blacklists or the ones for which cookies are blocked?" Your answer was: "Good point, it is more accurately blocked cookies, not blocked hostnames (blocked = dark or light red, blacklisted = dark red)."
  2. On the other hand, web storage falls exclusively under the purview of client-side scripting. Doesn't contradict this your reference to cookies above?
  3. In this comment you said:"...there is no way to specifically delete all local data by origin, i.e. once you call the API to delete local data, its the local data of all web sites which will be removed,...". But what's the sense and purpose of the "Delete contents of local storage of blocked hostnames" switch then (regardless if "blocked" means "blocked cookies" or "blocked javascript") ?

You see, I'm completely confused about how HTTPSB treats local storage.

gorhill commented 10 years ago

When I say "local storage", I mean window.localStorage, and nothing else. Confusion I guess is because when you say "local storage", you have ni mind all sort of local storages, while I refer specifically to one type, the one I could do something about in HTTPSB. For that particular one, I do evaluate whether cookies are red in the matrix, for the specific hostname, and if so, I tell the content script to empty the content of window.localStorage. But to clear all kind of local storages (lets use plural to end the confusion), there is no API than the browsingData API, which works based on time, not origin.

gorhill commented 10 years ago

Ok, forget what I say above, I am re-reading your comment line by line, and I really don't understand what is the confusion. Let's go one line at a time before moving to the next.

On the other hand, web storage falls exclusively under the purview of client-side scripting. Doesn't contradict this your reference to cookies above?

I don't understand what contradicts what. I will spell out the technical details:

  1. HTTPSB injects content script into web page.
  2. Content script checks if there is a non-empty window.localStorage present
  3. If so, content script reports to HTTPSB, asking "do I empty this thing?"
  4. HTTPSB checks the block/allow status of the cookie cell for the hostname of the page (the one owning the window.localStorage
  5. HTTPSB reports back to the content script whether it must be cleared or not
  6. Content script received the answer, and if it is "delete this thing", it empties the window.localStorage store

That's it. In few words, HTTPSB checks whether cookies are blocked as per matrix, and if so empties the localStorage container.

ghost commented 10 years ago

Thanks - now I understand. Confusion eliminated.

This issue should nevertheless remain open with regard to what we discussed in #66, shouldn't it?

gorhill commented 10 years ago

After I commented above, I thought maybe you worried that since blocked cookies would be allowed to go through with the setting we talked about in #66, than localStorage might also be affected. To clarify, internally, the matrix would still report cookies as blocked, it's just that the setting would tell the outgoing headers handler to let them pass even if they are marked as generically blocked in the matrix. So in short, the special setting in #66 would have absolutely no effect on existing localStorage code.

ghost commented 10 years ago

Ah, I see - very good! So if I understand this correctly we can close this issue, can't we? Unless the "sledgehammer" which you mentioned should also be covered by this issue. Are you still planning to implement it somehow?