Closed publicsite closed 1 year ago
Donations are not mandatory. :P This is an easy request. It will require a new option.
Never mind, it's impossible. Cookies are delivered asynchronously and without information pertaining to a page view. Suppose I have two tabs and both are accessing mit.edu. I will have received cookies from mit.edu and possibly other sites (third-party cookies). If I close mit.edu, I will have to inspect all other views for mit.edu as well as their active histories. For example, one page may be at google.com while the page also has mit.edu in its history. If I delete all mit.edu cookies, the page at google.com will have its mit.edu cookies purged. I will not know the true origins of the third-party cookies so I cannot delete those when a tab is closed.
Hmm that's a shame ... At the moment I'm using "Cookie Autodelete" plugin with Ungoogled Chromium but would like to switch back to dooble as having to install the plugins for privacy is not ideal ... I don't know how Cookie Autodelete deal with the third party issue, but I guess the code varies across web browsers and may not be portable idk. :/
In Qt, cookies exist for a profile. The main profile being the session profile. There are cookie filters. I don't know of a method to isolate cookies to a URL. For example, https://doc.qt.io/qt-6/qwebenginecookiestore.html#deleteCookie requires a cookie object. It also allows for an optional URL. However, I would have to know which cookies are associated with a URL and iterate over them. Cookies don't really belong to tabs because several tabs may utilize the same cookies.
Could you get it working with a 'disable third party cookies' option enabled? Reading this https://github.com/Cookie-AutoDelete/Cookie-AutoDelete/issues/235 and looking at my browser settings suggest I'm simply blocking third party cookies. I know blocking third party cookies may not be the ideal, but it works OK for me re. browsing experience, generally speaking.
See Settings -> Privacy -> Block Third-Party Cookies.
I'm not understanding your last request. The ability to block 3rd-party cookies exists in Dooble.
Ok. I can't find the code for it on github.
Basically, if "Settings -> Privacy -> Block Third-Party Cookies" is turned on. Then the problem you said about here:
Suppose I have two tabs and both are accessing mit.edu. I will have received cookies from mit.edu and possibly other sites (third-party cookies). If I close mit.edu, I will have to inspect all other views for mit.edu as well as their active histories. For example, one page may be at google.com while the page also has mit.edu in its history. If I delete all mit.edu cookies, the page at google.com will have its mit.edu cookies purged. I will not know the true origins of the third-party cookies so I cannot delete those when a tab is closed.
Is no longer as much of an issue when implementing "Make it so cookie crusher does NOT delete cookies from open tabs!".
You see what I mean?
Ie. you can do that on a domain basis if the option is ticked.
Oh, that's not completely true.
Suppose a tab's history stack is: github.com, mit.edu, codeberg.org. Suppose another tab includes codeberg.org in its history stack. If I close the first tab, I have to delete all github, mit, and codeberg cookies. Meanwhile the other tab is kind of broken. If I don't want to delete codeberg.org because other tabs are accessing it, than I have to inspect many things. There's also the thing with clearing history. If you clear your page histories, cookies remain.
It gets ugly.
Suppose a tab's history stack is: github.com, mit.edu, codeberg.org. Suppose another tab includes codeberg.org in its history stack. If I close the first tab, I have to delete all github, mit, and codeberg cookies.
In this instance, you would NOT delete codeberg.org cookie as a tab would still be open.
But yes, it gets a bit ugly. Sorry if I sound too demanding.
If there was a direct relationship between cookies and pages, it would be easy. I suggest private windows.
If there was a direct relationship between cookies and pages, it would be easy. I suggest private windows.
I didn't know about private windows. They look like they might be a possible option if they work similar to firefox describes here https://support.mozilla.org/en-US/kb/private-browsing-use-firefox-without-history idk. Incognito mode doesn't work for some reason logging into quite a few sites in ungoogled-chromium, this is why I use the plugins at the moment instead. I will have to test sometime.
Everything in a private window is discarded after the window is closed. Data are not written to disk during the existence of the window.
void dooble::prepare_private_web_engine_profile_settings(void) in dooble.cc is important.
As you can view and modify settings in a private window, settings are separate.
Cookies, favicons, visited sites, histories, caches, downloads, etc. are not recorded on the disk.
You will not see files being changed in .dooble. If you modify settings, you will see the settings database with a new date.
OK, the solution almost works, but not quite. Here's what I did.
1) Open Dooble, Normal Window 2) Turn Cookie Crusher On in Normal Window 3) Open Private Window 4) Turn Cookie Crusher Off in Private Window 5) Close Dooble (Private and Normal Window) 6) Open Dooble (Normal Window) 7) Check cookie crusher settings in Normal window.
Unfortunately turning cookie crusher off in Private Window, turns it off in Normal window upon going through the steps and checking at step 7.
Expected behaviour I think is to save normal window and private window cookie crusher settings seperately.
... A bit unfortunate the solution wasn't quite there. Possible you could get this route fixed?
A cookie window accessed from a private window will be denoted by a "privacy" icon in the cookie window's status bar. Changing settings in that private cookie window will not be retained because the window is considered temporary. These steps you list perhaps create a glitch. Anyway, the intent is that private cookie windows are private, including their settings.
Sometimes I introduce settings and forget about private windows. There are many complex interactions in Doovle and I don't review them all. Not that anyone else does. :P
Ha, ok, but can you fix my glitch? :--)
Someday.
bows hat
Perhaps tonight or tomorrow. Being a melancholy day.
well that would be looovely. [but] don't be too harsh on yourself ... make sure you take it easy
Interesting are the discoveries of concepts when things are unrelated but become related through discussions.
Committed some corrections. Night!
Thanks, I will recompile and test soon. Night.
:)
Hrr. I tested. Unfortunately this is introducing a new glitch ...
Dooble is not saving the state (either at runtime, or in .dooble) of cookie crusher in the private window.
Appreciate your efforts,
Josh
That's the correct behavior. Private windows and related private objects are are temporary.
A private cookie window is associated with a private Dooble window. Saving the contents of any private support window would require that the private window have some identifier and they do not. And if they did, which private window would you designate as a previous private window in a future session?
Ok ... I guess I'm asking now why cookie crusher settings in private windows are tempoary, and why there isn't a seperate save state, one for 'cookie crusher in private window' and 'one for cookie crusher in normal window'.
Usually when I want to open a private window to log into some site, I don't want cookie crusher on at that time (The cookies in a private window are destroyed after closing the private window.). However when I am 'just browsing normally' I want cookie crusher to be on to make sure CIA can't snoop on me.
You understand why I think what I'm suggesting makes sense?
I want cookies turned off (via cookie crusher), until I have to log into some site, and then I want them tempoarily on (via private windows).
One private window has its private profile but otherwise cannot be distinguished from another private window.
Each private window you create is a private window. Firefox may have but one private window.
Yes so two profiles for cookie crusher ... one for 'cookie crusher for private window' one for 'cookie crusher for normal window'.
I don't mean lots of seperate profiles for each individual private window. That would be mad.
Private window A and private window B are ephemeral. If you modify private cookie window A, private cookie window B cannot be modified because it's unrelated to the other cookie window.
Private cookie windows do not have settings.
You could have it as a global setting; 'cookie crusher for private windows'
The amount of work does not produce the effects that you can produce by a simple click.
Dooble is complete and this request is not interesting. More options are not interesting. :P
Well you see what I am aiming for:
A way to delete cookies until I am forced to login to a site, and then delete them afterwards if I have to login.
Private windows almost does that. Not deleting cookies from open tabs would do that.
Open a private window and enable the cookie crusher. Private cookies will be purged periodically. If you need to log into a site from a private window, set the site's cookies as temporary favorites.
That's a lot of work for wanting to keep thing clean whilst logging into a site.
I understand this is unexciting for you. :/
You need to specify which site to keep cookies from. Dooble doesn't know what you want.
Showing a "do you want to accept cookies from" dialog would be disastrous.
I want to keep cookies in private windows (that is until I close the private window) and use cookie crusher in normal windows
Left is a private cookie window and right is the official cookie window. Both operate independently.
I enable the crusher in the official widow and disable it in the private cookie window. I log into GH in the private window and my cookies are retained. Meanwhile, those cookies are not delivered to the official cookie window and profile.
I enable the crusher in the official widow and disable it in the private cookie window. I log into GH in the private window and my cookies are retained. Meanwhile, those cookies are not delivered to the official cookie window and profile.
This is what I'm after yes. But also saving the fact that you disabled cookie crusher for private windows in .dooble
OK, the solution almost works, but not quite. Here's what I did.
- Open Dooble, Normal Window
- Turn Cookie Crusher On in Normal Window
- Open Private Window
- Turn Cookie Crusher Off in Private Window
- Close Dooble (Private and Normal Window)
- Open Dooble (Normal Window)
- Check cookie crusher settings in Normal window.
Unfortunately turning cookie crusher off in Private Window, turns it off in Normal window upon going through the steps and checking at step 7.
Expected behaviour I think is to save normal window and private window cookie crusher settings seperately.
... A bit unfortunate the solution wasn't quite there. Possible you could get this route fixed?
It almost did it before, but there was this glitch :- it wasn't saving it in .dooble
As I wrote, I did that in a few seconds. Making the change in the software would require several hours.
Hi,
When I last used dooble, I had cookie crusher turned on and some tabs open and the cookies for the open tabs were being deleted (crushed).
I think the preferred behaviour would to be not to crush cookies from open tabs. Ie. only delete cookies when the tabs are closed; not when while they're open.
Looking forward to hearing back to you ... there may or may not be a small bounty attached to this issue.
Cheers,
Josh