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.
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.
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.
"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.
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.
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
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
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. ;)
# 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?
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.
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 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.
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.
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.
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.
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).
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.
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.
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.
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.
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]
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.
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.
> 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".
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)
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.