search

Lusito / forget-me-not

Make the browser forget website data, except for the data you want to keep.
zlib License
227 stars 25 forks source link

Request : Be able to define rule for Local Storage #235

Open LaurentGrenet opened 4 years ago

LaurentGrenet commented 4 years ago

With ForgetMeNot, it is possible to say globally that Local Storage is, or is NOT, deleted when processing data of domains.

And for each domain, it is possible to say what to do globally with its "data" (with "default" action for non listed domains).

But it is also possible (and this is VERY useful) to go in the details of cookies of a given domain, and say that

It would be VERY GREAT (and useful !) to have the same capability about Local Storage, domain per domain and for example be able to ask that Local Storage of domain Z is NEVER deleted or at the contrary as soon as leaving the domain, or etc...

Nota : I'm NOT talking here about to be able to "make detail" inside Local storage of a domain : it would be also useful, but I know that Firefox APIs do not allow it.

For GUI, we could imagine to create rules exactly similar to those relative to identified cookies : We currently may craete rule like MyCookie@*.google.com NEVER OtherCookie@*.google.com EXITING

I'd like to be able to create rule like LocalStorage@*.google.com NEVER LocalStorage@www.mydomain.com EXITING

With this enhancement, ForgetMeNot woud be very close to be perfect !

Lusito commented 4 years ago

I can't really use the @ syntax. How would I know if the user wants to remove the cookie with the name LocalStorage or just clean LocalStorage? Aside from that, this would be very confusing to the user as well.

I'm not against it, but I have currently no idea how this would be done from a user perspective without making things more difficult to understand. If this would be done, other cleanup types should be done as well.

Maybe by expanding a section "specify cleanup types manually", which contains a checkbox list.

In any way, there are currently more important things to work on and as long as I'm alone on this project (aside from translators), this is nothing I can start in the near future.

geeknik commented 4 years ago

Hi @Lusito, not sure if you've been following Mozilla's progress, but here's a few things of note.

Firefox 77 will support clearing IndexDB by hostname: https://bugzilla.mozilla.org/show_bug.cgi?id=1551301.

Firefox 77 will also support clearing ServiceWorkers by hostname: https://bugzilla.mozilla.org/show_bug.cgi?id=1632990.

After that, Firefox 78 will support clearing cache and pluginData by hostname: https://bugzilla.mozilla.org/show_bug.cgi?id=1636784.

These options are available now for testing in Firefox Nightly.

Lusito commented 4 years ago

Thanks. I know, I've already added them to version 3: https://github.com/Lusito/forget-me-not/commits/version-3b

LaurentGrenet commented 4 years ago

Hi @Lusito Thank you for answering... but I'm very disapointed by the answer ....

Actually, I insist it would be really very useful to be able to delete all cookies of a given Website while NOT deleting its "Local storage".

I understand from your answer that your main problem is that you do not have time to define a new GUI to define such a rule. And I agree that define a GUI is always very time consuming. It's the reason why I proposed you a solution, not perfect at all, I agree, but that could help at "low development cost" to implement such a new feature. Nevertheless I may understand your reaction (even if I'm not convinced, since the risk to have a real cookie named "LocalStorage" is very low...)

Since I would really like to have this capability to delete all cookies, while NOT deleting LocalStorage, let me make a 2nd proposal : Currently, I'm reaching this goal with

This works, but it's very tricky to implement, and moreover has to be re-examined from time to time, to verify that the website is not creating new cookies (and if it's the case, add the new corresponding rule)

So my suggestion would be to allow wildcards in cookie's name in rules of the type cookie@website. This would allow to create a unique rule for *@website to manage any cookie of website (or even Abc*@website to manage in one rule all cookies that name begins with Abc, eg. Abcdef, Abc1 and Abc2) Once again, it is not perfect, but it would help a lot.... at a minimum cost of development.

Hoping this 2nd try can more convince you....

Lusito commented 4 years ago

No, you misunderstand. The GUI is not the problem here.. actually, it's one of the less time consuming parts of the whole extension (GUI is ~25% of the code and changes very rarely).

The Problem is, that the @ separator is used for cookies and using it for something else makes things very ugly both from the perspective of code and users. What will also take time is answering questions later because things are not as clear as they seem.

When you say "low development cost", what it actually means is "adding a hack and gaining high maintenance cost along with confusion in the user base".

It would be possible to allow wildcards in cookie rules and there is already a ticket for this. See #137. Give it a vote to show your interest in that ticket.