Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Chrome “clear cookies on exit” feature does not work (superuser.com)
218 points by rdslw on March 24, 2019 | hide | past | favorite | 77 comments


Deleted by SuperUser diamond moderators are two answers dated 2019-02-10 that point to the exact bug report in the Chromium bug reporting system for this. The Chromium bug report that the deleted answers point to is listed as fixed as of 2019-02-18.


I've also noticed a persistent problem with stackexchange sites where useful information is deleted, appropriate questions are unnecessarily closed, locked, etc. by moderators.

Fortunately in this case it looks like a good answer hasn't been deleted.


Unfortunately, this is not true.

This is still NOT (fully+) fixed in current (73) Chrome/Chromium.

+) in most real usage scenarios your cookies will persist, contrary to your/users belief.

The even bigger problem, is google employees for a few years (sic!) delaying fix for this. AFAIK press article documenting it is in the works, but you can just jump into chrome bugs discussions and draw your own conclusion if this was prompt and appropriate reaction.

So the problem is:

1. it is not yet fully fixed

2. it is MULTIPLE years in this state

3. google knew about it and was interested in keeping it as it is.


Could you post those links?


A search on the Chromium issues page shows this: crbug.com/750452


Sounds like these replies didnt answer the question and should have been comments.


Hopefully this spurs more than a few people to move to Firefox. Im not looking forward to an all chrome/chromium future


I agree that more of us should use Firefox, though if you're switching because of this bug, you may be in for some disappointment.

https://armin.dev/blog/2019/03/firefox-extensions-browsing-d...


Those bugs are all extension bugs. The built-in option to "clear data on exit" that Firefox has in about:preferences seems not affected by them. Although of course they should be fixed.


But it is affected. It's very easy to confirm that even with "Clear data on exit" activated, websites recognize you across sessions.


"Clear data on exit" means remove all traces of me visiting websites from my device. It has nothing to do with how the websites will operate if I decide to do so.


That could be due to fingerprinting, your IP address etc, which is much harder to anonymize.


Firefox has its own problems in this realm, namely that all "Private" windows/tabs share a single session that persists as long as any of them exist.

I discovered this recently when I logged in to website X in a Private window, then closed the window without explicitly logging out, and returned to X later that day. I had another Private window open (with a completely different site). I was still logged in to X! because that second Private window had preserved the session.

This means, of course, that sites you visit simultaneously in separate Private windows are not isolated from each other either.

I still am mostly happy with Firefox and use it daily, but this was a completely unexpected and unwelcome behavior.


Yes, I wanted to use Firefox private windows To limit the scope of privileged cookies (like I can with Safari) but they are no use for that.

The multi-account containers extension mostly solves the problem for me https://addons.mozilla.org/en-GB/firefox/addon/multi-account... though I wish it was more convenient to open a tab in a specific container, and to discard and create containers.


Yep, I've been using containers; the core functionality is great, but it really needs some UI love. I found an extension for opening a new tab in a container: https://github.com/gsomoza/firefox-easy-container-shortcuts which helps. Likely there are other helper add-ons.


Maybe this is a platform dependant issue? On Arch each private window is independent, or so it seems. I was actually hoping for what you describe and instead found that when visiting my company website in two different private windows I had to login to each window separately. I found this so annoying because accessing some system amin tools on a few of our pages requires an annoying number of steps.


I'm on arch and Firefox 66.0.1 and for me the Private windows do share a session. Containers also fixed it for me, but when I discovered this it was very unexpected


Surely you could open it in a separate tab in the same window and then drag the tab out into a new window?


also (thanks to little snitch) even though I closed a tab visiting a site, little snitch still shows activity to that site afterwards.


I posted an answer on SO but may be worth repeating here. The screenshots show "reddit.com" as clear-on-exit and "www.reddit.com" as the owner of the cookie.

When adding a site to the clear-on-exist list, the box shows

  [*.]example.com
I think you need to use

  [*.]reddit.com
if you want to include sub-domains too.


Perhaps we need a way to delete chrome, re-install it, and then re-populate w/ the exact cookies we want persisted. Nothing else. No chance for web storage or other hidden/zombie cookies. This could be done every time the app is closed.

Quite frankly we need to stop trusting apps, particularly browsers at all. ;)


I use firefox, and find this function useful:

     # Open a new firefox instance, with a temporary profile
     function firefox_temp() {
        dir=$(mktemp -d)
        echo "Profile directory: ${dir}"
        firefox --new-instance --profile ${dir}
        echo "Cleaning up .."
        rm -rf ${dir}
     }
I'm not familiar with Chrome, but perhaps there is a similar "profile-directory" argument you can point to a temporary location?


You can use the `--user-data-dir` arg to specify a profile location when opening chrome. So, on a mac, something like:

  open -Fna /Applications/Google\ Chrome.app \
  --args --user-data-dir=/my_temp_profile_dir/my_tmp_profile
If you copy an existing profile to `my_tmp_profile` chrome will use that, otherwise it behaves like a new setup.


That's interesting... does it behave much differently to private windows?


If we assume that the private-mode is "secure", then I suspect there's probably not a huge difference in practice.

But this way I'm very certain extensions, history, local-storage, etc, are absolutely not available.

(To be honest I tend to use this mostly avoid caching, and other things. Useful when you're testing redirects and new designs.)


There is a flaw in your proposal: Deinstalling doesn’t necessarily ensure all program data is removed (at least on desktop OSes). When you reinstall the program, your previous program data can still exist and be used as is. So the persistent cookies can actually be super persistent in that they survive the program removal.


Some people run Chrome in a container:

https://github.com/jessfraz/dockerfiles/blob/master/chrome/s...

It could be configured to run in a totally clean container to keep the browser reasonably isolated from the host system.

Of course, the truly harcore can use Qubes OS and spawn a disposable VM to browse the web from:

https://www.qubes-os.org/doc/disposablevm/



IIRC Chrome installs some kind of persistent daemon that is entirely separate from the application itself. Keystone Agent or something like that.


I've come across this before. I don't know what its full responsibilities are, but I know it's part of the Chrome update process.

I came across it when I was trying to get two totally separate Chrome installs working on one machine (using https://github.com/djbclark/chrome-schismator), in such a way that they can run in parallel, update in parallel, each totally isolated from one another. It seems as though it's not possible to have two Chrome installs update themselves separately due to the Keystone application only being able to store one reference to a Chrome install at a time, meaning that the other Chrome instance never detects that it's out of date.


Perhaps you should use Firefox.


Perhaps Firefox should finally get around to not being a destroyer of performance, stability and battery life on a large subset of MacBooks, so people such as myself can use it.


I honestly never had that problem, sure performance wasn't great 5 or 6 years ago. I've used Firefox as my primary browser for at least five years, switching from Chrome when performance started to improve for Firefox.


Agreed. When I open up Brave on my phone to use Google Newsreel or something, I feel that it is a bit more snappy than Firefox. Firefox also crashes more often than I would like on my ArchLinux personal laptop. However, Firefox rendering speed has caught up with Chrome since the Quantum update, maybe the rest will catch up also.


I have Firefox (with accidentally permanently 50+ tabs open) on a touch bar MBP and it's fine.


It doesn't seem to affect everyone/every machine.


Then it doesn't seem fair to blanket blame FF on macOS. A few more details would go a long way to legitimize the complaint.


If a user tests Chrome and Firefox and only Firefox has bad performance/battery life, they'll blame Firefox.

Mozilla is aware - there are a few bugzilla reports open about this - but like most Firefox bugs it takes months or years to be fixed. Last year (nov/dec?) they fixed something that improved battery life, but it's still worse than Chrome for me.


Mozilla has been tracking cpu utilization/power consumption issues with certain MacBooks since Quantum was released. It seems to mostly affect MacBook Retinas without discrete GPUs. From the big tracker it appears the latest theory is it caused by an interaction between Firefox's compositor and the macOS compositor.


Nah, they rather implement a file sharing website.


Just thinking. Maybe using lxd with rendering on the X server of the host if you use Linux. Then keeping a base container that you can clone anytime you want to start a new browsing session. Or making use snapshots if you like.


Browsers should be on our side. If they're failing at that, then they're not good.

Personally, I'd like browsers to be much smarter about which cookies to keep and which to throw away. Keep cookies about settings, throw away everything else. And instead of not accepting cookies, leading to sites complaining about that, just accept them and throw them away at the end of the session.

Also, I'd really like the option to open some sites always in incognito mode. Many sites have no business knowing who I even am, but some really do. Same cookie policy for all sites makes no sense. Cookies need to be a lot more transparent, and instead of relying on annoying and incomprehensible GDPR popups, the browser should take care of that.


You can use docker for this


This is most likely a website keeping the same data in HTML5 web storage, flash cookies or other, and when noticing one of them has been removed, repopulating them. These are also sometimes called super, zombie or persistent cookies.


Hold on. The setting is called “keep local data only until you quit your browser”. Not “local cookies”. And that’s always how I expected it to work. If it preserves data from web storage or others than this is either a massive fuck up or a disingenuous placebo setting.


I believe handling of Flash cookies is completely outside the browser.


Flash is bundled with and sandboxed by Chrome.


And disabled by default, too.


Isn't local data a superset of local cookies?


It seems it was kept in IndexedDB, but Chrome was only cleaning it up when you closed it and not when you closed all its windows (I didn't even know there was a difference).

https://bugs.chromium.org/p/chromium/issues/detail?id=750452...


There is on macOS, (for all 'apps', not just Chrome) but not, I think, on any other platform.

I don't know why anyone feel anything more than indifference about it; I find it annoying.

I used to use a tool (I think it was called RedQuits) that implemented the windows closed -> app quit behaviour.


This happens for a few years (much older than URL in question).

This happens also in Chromium.

There is (proably?) a logic when cookies will be deleted, but it is under so strange conditions, that 99% of users who choose this options, DO NOT HAVE cookies deleted on chrome/quit/restart AT ALL.

:-o


Do you have any citations as to how old the issue is?


At least since July 2017, when this bug was opened: https://bugs.chromium.org/p/chromium/issues/detail?id=750452


I've been using an extension called "Auto History Wipe" for almost two years because of this bug, so it's at least ~2 years old.


Why are cookies even persisted on disk in the first place when such an option is enabled?


I can imagine that multiple tabs/windows don't share the same address space, so in case of opening the same website on another browser instance, saving to disk would make sure that the cookie is exposed to other running processes as well.


Saving to disk is probably one of the simplest ways of sharing data between processes, but it's far from the only one (e.g. named pipes)


I’m guessing here, but maybe it’s in case of a crash, it can reload them back when you reopen the browser?


Still waiting for Google to add a feature to display a warning alert box when you try to close all tabs by accident, but a decade later no such feature exists even though everyone wants it, and Firefox has it, and it seems trivial to implement.


Control-shift-T when you start Chrome back up again.

I don't want the feature you describe. I prefer undo to confirmation.


If you CMD Q on osx you get a warning


Which is annoying. I though that would be a good idea, because I occasionally closed a browser by accident. In reality I more often than not actually want to close Chrome, and the "press and hold cmd+q" is pretty annoying.


On the flip side, I often hit it accidentally when hitting cmd-w, and I don't think I ever intentionally hit it. Choosing good defaults is hard.


Reminds me of door control buttons in an elevator that you use everyday only to find the button resting on the floor one day, revealing that it was adhered to the control panel with a hot glue gun the whole time.


I keep hearing that, and apparently that's the case in the US [1]. In Japan, the buttons are usually very much operational and they have devised a whole system of etiquette around them. [2]

[1] https://www.sciencealert.com/the-close-door-buttons-in-eleva...

[2] https://boingboing.net/2017/10/12/button-mashing.html


The US buttons don't work because there are mandatory waiting times for the doors closing due to the ADA ((your article mentions that)) - they're still normally plugged in.


I've been in elevators where they definitely did work, with immediate effect. But also some where they don't seem to do anything.


that's the case in the US [1]. In Japan

Broad generalizations about nations are rarely accurate.

It has to do with the owners of the elevators choosing to override the programming.

Elevator doors are initially programmed to stay open for a period of time based on their capacity, intended use, type of building, etc...

If the owner or installer of the elevator finds this default not suitable for the environment and use, then the wait time can be changed, and/or the door close button function can be altered.

[edit] In some elevators, the reason the door close button doesn't work is because it's not meant to be used by ordinary people on an ordinary day. It's meant for when the elevator is in utility or fire mode, used by maintenance people, firefighters, moving companies, etc...

They push the door open button and the door opens, and stays open while equipment is moved in and out. The door closes when the door close button is pressed.

People assume every button is for them.


> Broad generalizations about nations are rarely accurate.

Agreed. But I was trying, by giving a counterexample, to respond to an even broader generalization: that "door buttons in elevators don't do anything". And I did say "usually".


Anecdotally, there does seem to be a lot of elevators for which the "close doors" button doesn't work, which I can only assume is deliberate.

Haven't noticed any other buttons not working though.


Serious question, is this a bug in Chrome that affects all cookies or is it something specific to that reddit.com cookie?

It might be the case that Reddit or another vendor just adds that cookie from other sites (like within a share button functionality)


As another comment pointed out there is no bug. reddit.com and www.reddit.com are different origins.


Disadvantage for web users who care about privacy; advantage for advertisers and adtech companies that want to track you.

I wonder if Chromium has the same problem?


good time to remember that Google employees silently rolled back, over years, every single attempt by chromium contributors to block or add privacy features (e.g. restrict to same domain) for the referrer http header (which is the basis of Google ad business)


crbug.com/750452


If the cookie is stored in-file somewhere you could probably make a batch file to delete it and then start chrome and put the shortcut on your desktop and in your start menu.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: