Oof! When updating Chrome to 79.0.3945.79 or newer, some items aren’t migrated, so they’re wiped and start from scratch. This includes localstorage, websql, cookies-journal, and quota managers.
A title change might be in order. “Chrome 79 bug forgets localstorage and websql, rollback WIP,” maybe?
I see lots of comments on the veins of “those developers are bad because they trusted localStorage”. I think that people who are thinking that this bug is reduced to this are missing the point completely. LocalStorage is used by many apps as a temporary location to keep stuff while they are offline for future synchronizing with the server. This is a best practice, keep things in localStorage, sync when you can. That in-transit data is now lost. There are cases of veterinary hospirals losing the information on which animals have been vaccinated. They simply can’t do the vaccinations again. Field workers losing their work.
This affects hybrid apps the most. There are a ton of specialized android applications built with phonegap/cordova/ionic, in which localStorage is the primary storage. All that data is lost now. This also affects webSQL which was heavily used by those apps in the past.
In many cases, the end users feeling there was something wrong with the app, reinstalled them which made the process even worse.
What people should be rallying around is: “How was this bug not caught by an automated test by the Chrome team?” It is all cool that developers can pick betas and test stuff out but the responsibility for shipping a working product is Google’s, and they are not, in my opinion, having the correct posture on this.
I read approximately 1/3 of the bug thread word for word. I too thought that the application devs screwed up here. But, you’re missing something, I think… I don’t think most of these apps have any online storage at all. Let’s see, here’s one… https://play.google.com/store/apps/details?id=com.biblioeteca.apps.NoMorePass&hl=en_US It is a password manager.
So, the crime that these devs committed against their users wasn’t failure to use online storage–that was by design. The crime was failing to explain to the users that their data was being stored in what is tantamount to ephemeral storage–the kind of storage that should be BACKED UP.
“LocalStorage, webSQL, IndexedDB have been rock solid solutions for hybrid apps for probably close to a decade. Data eviction seldom happens for hybrid apps. These are stable APIs and have been working reliably for many years.”
People been using these storages (localStorage, webSQL) for probably close to a decade in client-only apps. It has been very reliable. After spending many years using it and reading the specs, which doesn’t mention it should be used only for caches or ephemeral data IIRC, it is understandable that those mobile devs started being confident on it. I’ve built apps that used those storages as main storage for many years until the app started to need complex queries and I moved to SQLite, I didn’t move because localStorage was not safe at the time, I moved because I had other needs. Still, my apps always had a way to backup your data to a file which I bet many of those apps also have but if there is no data to backup, then it becomes quite tricky.
soapdog, ah, I did not know that. Thanks exposing me to this.
Do many of your users know how to reach into their browser’s profile directory?
Are these local storage mechanisms synced across devices by some organization (Google, Microsoft, Mozilla)’s sync service? Or backed up “to the cloud”?
If not.. Then what does a user do when they upgrade to a new device?
Something that stands out is the number of developers complaining on-thread that their users stood to lose irreplaceable data - in one case, years of financial data! - as a result of this bug.
When I worked for my local University on the helpdesk back in … 1998? … we had huge posters on the lab walls explaining how important it is to have multiple floppies, with backups of your important work on each. And we still had multiple near-hysterical students turn up to the helpdesk in the hopes of recovering data from their single, damaged, floppy.
(You might also ask, “why didn’t the students have a network drive they could use?”. They did … but that was only for postgrads and staff. A little behind the time for the 90s.)
Aaaaaanyway … it’s sad to see that people who should know better are still making this mistake in 2019.
Did the posters also tell people how to take localstorage and cookies from the browser and back them up onto said floppies?
It’s ridiculous to put the blame on browser users in this situation. If anything it’s the developers that didn’t accurately convey the importance.. or didn’t have the foresight to realize that a browser environment is not suitable for their application that assumes “data permanence”.
Bearing in mind this was the 90s (so, no local storage, or even serious local web apps, back then), but the posters did contain explicit instructions on how to back up Eudora (email) and documents. They contained everything you needed to know to keep yourself safe (or at least, safer than having your data on just a single floppy).
In my opinion the bulk of the blame lies with the developers; that’s why I wrote “developers complaining on-thread that their users stood to lose irreplaceable data”. The developers knew, or should have known, what the consequences of loss of local storage would be, and failed to make those consequences clear to their users. (And not just loss from soft-deletion; I’ve personally destroyed two smartphones by dropping them in toilets.). I have little sympathy for authors of apps who gave no fucks about any of this, who are suddenly receiving strings of 1-star reviews as a result.
But at least some users are partially to blame, though. If you (or your teams) are running something business-critical, and don’t care to understand how the data are backed up and restored, you’re doing it wrong.
Yeah, I’ve always been careful to not store something irreplaceable in the browser, although that’s mostly I’m using squandering the browser by treating it as a terminal rather than an active participant in a web application.
However, it’s also irresponsible of Google to not treat the in-browser data managed by their software with the same care they treat users’ Google Drive data.
So, this is what I’m trying to form an opinion on.
I’m not sure there’s a winning position for Google, here. Force users to create Google accounts to auto-synchronise the offline storage, and be subject to criticism around surveillance and coercion? Or leave the offline storage to be an issue for the app developers, and just trust them to do the right thing? Then you’re accused of irresponsibility.
Yeah, it’s a hard problem! Google doesn’t want to make it obvious when web applications are using local storage (because the extent of using it for advertising/surveillance wouldn’t look good). Relying on the population of web developers to do the right thing is a losing proposition (look at the absolute sewer MSIE became).
Looking a bit further, it looks like the webview that a lot of these apps use changed what profile it uses, so while the data are still on disk, it’s not attached to the new profile. Which, lmao. The #1 reason I ever bothered with Chrome was support for multiple profiles, #1 thing I’ve griped about Google’s UI team messing with for no reason, so getting some schadenfreude from it also breaking a bunch of apps that aren’t my problem.
When I started getting in to computers with FreeBSD 20 years ago the FreeBSD handbook listed various popular backup solutions. The top of the list was “do nothing” :-)
I’d sort of expected humankind would stay the same - hard to change except by repeated, painful, experience. It’s how most industries improve over time; apparently we haven’t had enough of those lessons yet ;(
Suggested a better title.
You’re not the only one. Perhaps lobste.rs could use a function which allows users to vote for a new title?
Small stuff like years are usually added automatically. This big of an edit usually requires a mod.
Or a sufficiently consistent hivemind…
Oof! When updating Chrome to 79.0.3945.79 or newer, some items aren’t migrated, so they’re wiped and start from scratch. This includes localstorage, websql, cookies-journal, and quota managers.
A title change might be in order. “Chrome 79 bug forgets localstorage and websql, rollback WIP,” maybe?
I see lots of comments on the veins of “those developers are bad because they trusted localStorage”. I think that people who are thinking that this bug is reduced to this are missing the point completely. LocalStorage is used by many apps as a temporary location to keep stuff while they are offline for future synchronizing with the server. This is a best practice, keep things in localStorage, sync when you can. That in-transit data is now lost. There are cases of veterinary hospirals losing the information on which animals have been vaccinated. They simply can’t do the vaccinations again. Field workers losing their work.
This affects hybrid apps the most. There are a ton of specialized android applications built with phonegap/cordova/ionic, in which localStorage is the primary storage. All that data is lost now. This also affects webSQL which was heavily used by those apps in the past.
In many cases, the end users feeling there was something wrong with the app, reinstalled them which made the process even worse.
What people should be rallying around is: “How was this bug not caught by an automated test by the Chrome team?” It is all cool that developers can pick betas and test stuff out but the responsibility for shipping a working product is Google’s, and they are not, in my opinion, having the correct posture on this.
I read approximately 1/3 of the bug thread word for word. I too thought that the application devs screwed up here. But, you’re missing something, I think… I don’t think most of these apps have any online storage at all. Let’s see, here’s one… https://play.google.com/store/apps/details?id=com.biblioeteca.apps.NoMorePass&hl=en_US It is a password manager.
So, the crime that these devs committed against their users wasn’t failure to use online storage–that was by design. The crime was failing to explain to the users that their data was being stored in what is tantamount to ephemeral storage–the kind of storage that should be BACKED UP.
Oh, I am not missing that. On my longer commentary on that bug, I mention:
People been using these storages (localStorage, webSQL) for probably close to a decade in client-only apps. It has been very reliable. After spending many years using it and reading the specs, which doesn’t mention it should be used only for caches or ephemeral data IIRC, it is understandable that those mobile devs started being confident on it. I’ve built apps that used those storages as main storage for many years until the app started to need complex queries and I moved to SQLite, I didn’t move because localStorage was not safe at the time, I moved because I had other needs. Still, my apps always had a way to backup your data to a file which I bet many of those apps also have but if there is no data to backup, then it becomes quite tricky.
soapdog, ah, I did not know that. Thanks exposing me to this.
Do many of your users know how to reach into their browser’s profile directory?
Are these local storage mechanisms synced across devices by some organization (Google, Microsoft, Mozilla)’s sync service? Or backed up “to the cloud”?
If not.. Then what does a user do when they upgrade to a new device?
Something that stands out is the number of developers complaining on-thread that their users stood to lose irreplaceable data - in one case, years of financial data! - as a result of this bug.
When I worked for my local University on the helpdesk back in … 1998? … we had huge posters on the lab walls explaining how important it is to have multiple floppies, with backups of your important work on each. And we still had multiple near-hysterical students turn up to the helpdesk in the hopes of recovering data from their single, damaged, floppy.
(You might also ask, “why didn’t the students have a network drive they could use?”. They did … but that was only for postgrads and staff. A little behind the time for the 90s.)
Aaaaaanyway … it’s sad to see that people who should know better are still making this mistake in 2019.
Did the posters also tell people how to take localstorage and cookies from the browser and back them up onto said floppies?
It’s ridiculous to put the blame on browser users in this situation. If anything it’s the developers that didn’t accurately convey the importance.. or didn’t have the foresight to realize that a browser environment is not suitable for their application that assumes “data permanence”.
Bearing in mind this was the 90s (so, no local storage, or even serious local web apps, back then), but the posters did contain explicit instructions on how to back up Eudora (email) and documents. They contained everything you needed to know to keep yourself safe (or at least, safer than having your data on just a single floppy).
In my opinion the bulk of the blame lies with the developers; that’s why I wrote “developers complaining on-thread that their users stood to lose irreplaceable data”. The developers knew, or should have known, what the consequences of loss of local storage would be, and failed to make those consequences clear to their users. (And not just loss from soft-deletion; I’ve personally destroyed two smartphones by dropping them in toilets.). I have little sympathy for authors of apps who gave no fucks about any of this, who are suddenly receiving strings of 1-star reviews as a result.
But at least some users are partially to blame, though. If you (or your teams) are running something business-critical, and don’t care to understand how the data are backed up and restored, you’re doing it wrong.
Yeah, I’ve always been careful to not store something irreplaceable in the browser, although that’s mostly I’m using squandering the browser by treating it as a terminal rather than an active participant in a web application.
However, it’s also irresponsible of Google to not treat the in-browser data managed by their software with the same care they treat users’ Google Drive data.
So, this is what I’m trying to form an opinion on.
I’m not sure there’s a winning position for Google, here. Force users to create Google accounts to auto-synchronise the offline storage, and be subject to criticism around surveillance and coercion? Or leave the offline storage to be an issue for the app developers, and just trust them to do the right thing? Then you’re accused of irresponsibility.
Yeah, it’s a hard problem! Google doesn’t want to make it obvious when web applications are using local storage (because the extent of using it for advertising/surveillance wouldn’t look good). Relying on the population of web developers to do the right thing is a losing proposition (look at the absolute sewer MSIE became).
Looking a bit further, it looks like the webview that a lot of these apps use changed what profile it uses, so while the data are still on disk, it’s not attached to the new profile. Which, lmao. The #1 reason I ever bothered with Chrome was support for multiple profiles, #1 thing I’ve griped about Google’s UI team messing with for no reason, so getting some schadenfreude from it also breaking a bunch of apps that aren’t my problem.
Why would you expect humankind to have changed in the intervening years? We were ignoring warnings to keep a backup 20 years ago…
When I started getting in to computers with FreeBSD 20 years ago the FreeBSD handbook listed various popular backup solutions. The top of the list was “do nothing” :-)
I’d sort of expected humankind would stay the same - hard to change except by repeated, painful, experience. It’s how most industries improve over time; apparently we haven’t had enough of those lessons yet ;(
Don’t auto-update, see for example https://github.com/Homebrew/homebrew-cask/issues/69898