Where's our data, Google? Chrome 79 update 'a catastrophe' for Android devs with WebView apps

A change to the location of profile data in Chrome 79 on Android, the new version rolling out now, means that applications using the WebView component lose data stored locally. "This is a catastrophe; our users' data are being deleted as they receive the update," complained one developer. "I heard from a company that uses …

[Hans Neeson-Bumpsadese]

"I heard from a company that uses local storage for offline no-connection available that had local record[s] of animals getting vaccination. The update 'erased' all the data. They don't know which animals got [a] vaccine and can't repeat on all of them. Serious stuff,"

Not to defend Google here, but in this particular case some blame must lie at the application developer's door. This sort of data is indeed "serious stuff", so to trust its storage only to a client device, and not to maintain a copy on a server somewhere seems sloppy.

[GnuTzu]

Phone-app consumer mentality in a business setting (not to mention IoT). :-(

Once upon a time, computers we serious business products, save for the occasional game of Wumpus. Now... Geesh, I'll just let somebody else finish the thought.

[Pascal Monett]

Indeed. You're a company and the only record you have is bloody phone ?

Well now you know why you shouldn't work like that.

[Ol'Peculier]

The way I understood it that data was been stored whilst the device was without an internet connection, and would be uploaded once a connection was available, so I can't blame the developer here, they were doing what it was intended to do.

[Jason Bloomberg]

But it was still a mistake to store the data somewhere where they had no control over it. If they had written it to an explicit file, rather than leaving whatever to deal with it, it would have still been there and visible.

Just appending an explicit file with any data produced, stored and used internally, would have given them an on-device backup which was easy to access; 'lost everything' wouldn't have been the immediate situation.

At least developers have now had their wake-up call.

[GnuTzu]

Well, maybe those "developers have now had their wake-up call." Or are they really getting that message, as we'd hope? And, will it get out to the rest of the industry?

[Anonymous Coward]

Mistake number one was using a a browser for serious stuff. Remember they were designed to show documents, not run applications - the latter was bolted on by marketing departments - which actually it's what Google is.

[Anonymous Coward]

Nice to know you weren't being 'serious'

[Andy Nugent]

would a web app have permission to just write to any file? A question, but I'm suspecting the answer is no, and they're writing to the sandboxed file area that they do have permission to use (which due to this issue now just appears empty).

[Dave Fox]

Except that the device would've needed internet access in order to update to Chrome 79 in the first place...

Regardless of that though, if the app does sync back to the cloud whenever it has a data connection, how much data would've really been lost here? How would it be any different if the vet had accidentally dropped the device down a well? ;)

[John H Woods]

Well ...

It would different because that's just one vet who's dropped it down a well.

This is why pen and paper is so good. I'd have had a portable printer pumping out mini vacc certificates.

[cdrcat]

Re: Well ...

Fortunately there is a partial wet backup in the pet owners' brains.

[Anonymous Coward]

Re: Well ...

If it was vaccinations in a farm with many animals, good luck remembering each of them...

[John Brown (no body)]

Re: Well ...

"I'd have had a portable printer pumping out mini vacc certificates."

"The paperless office" :-)

[Kiwi]

Re: Well ...

This is why pen and paper is so good. I'd have had a portable printer pumping out mini vacc certificates.

When I was farming we had old-fashioned paper log books for the herd. For certain things, the cow's tag # was entered into the book. Somewhere else, there as a line pre-printed for each cow (again based on tag #) and as the vet did the job the appropriate item was marked in the book by the stupid kid roped in to follow the very around all day taking notes (not that I'd know who that kid was, no not me, honest! :) - though I got to spend some quality time with the vet learning a hell of a lot more about herd health then the farmer could ever teach me)

With some jobs, we actually just used a paint marker that'd wash/rub off in a few days/weeks. At the start of the mating season a marker that'd rub off was also used to tell us which ones the bull had met with.. If Mastitis or other issues were detected with the udder/teats (including cuts or other sores), a red marker was applied so her milk couldn't go with the normal lot until she was healed. Using the paint was quick and simple, and would last plenty long enough so if the vet lost the logs on the way back to their office or the office burnt down the following week etc, we still could just look and see which cow'd had what treatment.

Nice to see even today computer's aren't as reliable as a can of Dazzle :)

[Anon]

Down the well

Then Skippy would have told Timmy and the data would be saved from near-certain death.

[TimMaher]

Re: Down the well

Yeah but Skippy didn’t tell me.

We don’t get on so we’ll these days.

I don’t know why.

Maybe there is somebody else?... Sob...

[Anonymous Coward]

Re: Down the well

> We don’t get on so we’ll these days.

Well maybe if you stopped calling him Skippy...

[Brewster's Angle Grinder]

"Except that the device would've needed internet access in order to update to Chrome 79 in the first place..."

But if the app is killed while there is no wifi, and the webview update happens before the app is re launched, then the data will be lost before it's had time to sync.

[iron]

What part of "no-connection available" do you not understand?

[Hans Neeson-Bumpsadese]

What part of "no-connection available" do you not understand?

I understand "no-connection available" perfectly well. What I don't understand is why an application which stores data which is considered to be "serious stuff" does not maintain some secondary copy of that data, e.g. copying to a server when a connection does become available, rather than an all-eggs-in-single-offline-basket model.

[localzuk]

A potential scenario. You're a vet, out on a farm on a welsh hillside. You vaccinate a bunch of cows. You've done half the herd and head back to the office for the end of the day. Once you get back, your phone connects to wifi and Android goes "ooh, updates" and downloads Chrome 79. You then open the app up, ready to do its sync, but your data is gone.

[Anonymous Coward]

I'm glad everyone is focused on the animal caretakers and not Google... good show beancounters*... good show.

*For some, the best thing about Christmas is that tax season is just around the corner.... so out comes that cheerful herd.

[Alumoi]

I knew there was a reason I disable autoupdates of each and every program I can.

[headrush]

Were you somehow expecting the vet to go through the whole herd again when they returned to complete the job? If they had done half the herd then they would have kept the unvaccinated half separate or marked the vaccinated ones somehow. You don't just roam the hills and hope to find the ones you need.

[Kiwi]

If they had done half the herd then they would have kept the unvaccinated half separate or marked the vaccinated ones somehow.

In many places it's common to have ear tags with a unique (to the herd) number or some other identifier on a cow.

Stock have a lot of things happen to them each year, and while paint is a very simple way to mark for some things, it's also generally a very good idea to have stuff written down.

(In the case of vaccines, you bet I'd use paint unless there's some compelling reason not to).

Just remembered that also there's a lot of automation on the farm these days based on RFID implants in the animals. They walk past a reader, the system records whatever was done. I believe in some cases animals that come back in for another round can automatically be 'rejected' as well.

[Nick Ryan]

That sounds exactly like what happened.

A "proper" application would have been considerably more sensible in this situation. Relying on an entirely arbitrary third party application which is not designed for the persistent of critical and irreplaceable data... is extremely poor design.

Google definitely dropped one with the poor update process, but the non-application developer really failed very badly here too.

[Dog11]

You mean, store backup to a server when a connection becomes available, the same as the typical PC program (MSWord etc.) does?

[Tim 37]

LocalStorage data has always been in peril

Sure the bug and it's handling has been terrible, but localStorage, IndexedDb, WebSQL, etc data has never been entirely safe. For starters, Chrome has never included code that can handle/migrate this data when Chrome is downgraded. An Android user has always been able to remove a Chrome update and it's never been obvious what consequences this has for other installed apps. Phonegap/Cordova have ways to save data more persistently not linked to the Chrome implementation and if your data is important, this is where it should be saved.

[eldakka]

Re: LocalStorage data has always been in peril

LocalStorage data has always been in peril

Absolutely.

However, automatic updates have increased this peril. You can't even make the decision to manually back up important data before applying an update (as was always advised previously as good practice before updates were manually applied, like Windows Service Packs etc.).

[Jamie Jones]

Re: LocalStorage data has always been in peril

Indeed. They are really about as reliable as cookies.

[RyokuMas]

Hang on...

"...applications using the WebView component lose data stored locally."

But surely it would be simple for Google to restore any lost data from all their telemetry... right?

[Zippy´s Sausage Factory]

Re: Hang on...

"Hey Google, are my dog's shots up to date?"

"Skippy will need his vaccines on the ninetee - er, I mean, Google doesn't know this information, haha why would you think that?"

[JanCeuleers]

Similar to a supply chain attack

These apps' developers should perhaps view their dependence on 3rd-party-provided functionality as a supply chain attack vector and act accordingly.

I am not saying that these developers are at fault for causing this issue, but it is clear that they have taken a risk by relying on the 3rd-party functionality, which makes that functionality part of their supply chain.

[Anonymous Coward]

Re: Similar to a supply chain attack

But in this day and age, commodity computing is all the rage. There are lots of companies out there offering tools and utilities to 'aid' developers. Its no longer the case where you have someone who can code *everything* they might want in order to deploy their code.

Reliance on 3rd party functionality is probably a necessary evil in a lot of cases - why spend even more time developing tools that already exist. On the other hand, why would you think to code around a function supplied by a 3rd party? Your code size would balloon if all you did was think about 'what if they screw this/that' for everything.

[Anonymous Coward]

Blame, blame everywhere ...

No sympathy for any developers that were relying on Google - that's weapons grade idiocy.

However, it's scary to think how an update this dramatic managed to slip out of the Chocolate factory, with it's untold ratio of genuises/lattes without at least one person saying: "Hang on, is this right ?"

Imagine how many more subtle unseen and potentially corrosive bugs have slipped thought these past months and years. And imagine the horror of some poor "app" user when their data vanishes forever.

[Kiwi]

Re: Blame, blame everywhere ...

No sympathy for any developers that were relying on Google - that's weapons grade idiocy.

The thing with a lot of Android (and I assume IOS) apps is that they're often relatively small because they're written around common libraries/OS APIs etc. They write to a published standard, use expected storage folders (like placing a new spreadsheet under "C:\users\username\My Documents" or /home/username/Documents) - a lot of that sort of work is done for them.

Also, I recall with Android that a lot of the file system access is removed except for certain areas though I could be remembering the wrong bit of marketting guff.

My reading is that Google suddenly removed "/home/' and expected everyone to use "/slurp/" instead, without really telling anyone in advance.

I can have sympathy for coders who use the expected locations and are shat on by the OS writers, even though given experiences with MS and I believe Apple (apols if wrong) perhaps they should've been wary.

Google is the most at fault for not migrating data though. Google have also done some other interesting things in recent times, like mandating that WiFi signal strength apps also have GPS data turned on. Why should the app I use to tell me which WiFi channel is least congested in a given area need to know the GPS location?

[Anonymous Coward]

WebView?

WebView is only used to display an existing web page in an app :

https://developer.android.com/guide/webapps/webview

[Jamie Jones]

Re: WebView?

.... and web pages can be made of HTML5 and javacrtpt, and hence be "web based applications", and html allows for storing data locally (like super-cookies with a size up to 5M per site). This is called "Local Storage", and is the thing this article is talking about!

[Danny Boyd]

Re: WebView?

JavaScript? What is JavaScript? Do you still have it enabled? Pfui!

[Jamie Jones]

Re: WebView?

I don't know how to disable javascript in webview!

[chuckufarley]

Back up your data...

...Even if you are locked in to one vendor that makes it hard to access. Back Up. Your. Data.

[Steve Graham]

Re: Back up your data...

The Android permissions model may make this difficult unless the app developer has taken steps to allow it.

[chuckufarley]

Re: Back up your data...

Oh, right, because it is so hard to install the Android SDK yourself.

[Kiwi]

Re: Back up your data...

Oh, right, because it is so hard to install the Android SDK yourself.

So how does one install it? Instructions in terms a rather busy and not-computer-savvy vet could follow please.

Agree backing up is a very good practice, but not every one has the nous to work out how to do it.

[Chris Hills]

Carl Sagan seems apt here

"If you wish to make an apple pie, first you must create the universe."

If you do not build every component yourself and instead mix in unknown 3rd party elements, your system will surely have undefined behavior.

[trevorde]

The browser

is the new operating system :-(

Write once and test on every version/update of Chrome. If you manage to find a serious bug in a canary build, good luck with convincing Google to fix it for you.

[arthoss]

Where’s our data, Google?

Is this a Rick and Morty reference (where are my testicles, Summer?)

[Cynic_999]

Quiz

You are a developer needing to create an application to allow a vet to keep patient records. A reasonable starting point would be:

1) "Animal Farm" by George Orwell

2) A text editor

3) A search engine

4) A database engine

5) Minecraft

6) A web browser

7) The cloud

8) Blockchain

9) Internet of Things

10) All of the above

11) Any of the above

12) None of the above

How many went for (6) ?

[Kiwi]

Re: Quiz

How many went for (6) ?

I would, but it would depend on where the vet is working and if a secure internet connection is reasonably available. I've written quite a few front ends for client databases etc that are strongly based around them using a web browser to access things.

Not having written for Android, I don't know how easy it would be to write a simple program that outputs to a machine-readable text file (done that many times too, where data portability was a very high priority (back before Y2K), but I've seen some 30+MB apps on Android that seem to do SFA and leave me scratching my head - certain I could write it from scratch for less than 1/10th of the size! (but no knowledge of what it is like to code for Android so...)

[Danny Boyd]

Where, where... There!

Customer: "Where's our data, Google?"

Google: "All your data belongs to us. *We* have it, no need to worry."

[William Higinbotham]

Re: Where, where... There!

It all went to a cloud called Old Smokey that never rains back down.

[Milton]

There was a time—

—when you sold your software on a CD. Go back far enough, you may even have sold it on a floppy. You had to print millions of the things and ship 'em across the world to an equally enormous number of people and organisations.

The cost of a screwup, financially and reputationally, could be existential, so you had absolutely no choice but to ensure that you tested the stuff very, very, very thoroughly.

Nowadays we have the world's biggest companies reaping billions while treating end-users as unpaid beta testers of startlingly flawed software. The billions accumulating in Google's pockets (and those of Microsoft, for that matter) are directly stolen as the losses of time, data and damage incurred by customers who have to waste effort and lose money, yet again compensating for the shoddy wares inflicted upon them.

From politics to finance to the tech business, increasingly I see a world in which a sizeable majority of basically lazy, unaware, gullible people might as well be hooked up to IV lines as they are relentlessly bled for the benefit of the few.

I'd like to believe this is just a bit of cynical moodiness speaking, really I would—but everywhere I look, and as recent political events demonstrate, a vast number of people seem to walk, sheep-like and heedless, directly into the abattoir ... staring transfixed at their stupid little screens, probably.

[TeeCee]

"We have asked Google how the problem made it into production..."

It went into production? You mean there's a Google product that doesn't say "beta" on it?

Google are great believers in large scale beta testing to ensure production versions are thoroughly stable. The fact that the pace of change means no version completes beta before being superseded isn't their problem.

[Brewster's Angle Grinder]

Mostly we use if for caching. That stuff will be recalculated - which will make for a slow app start and force the installation wizard to rerun, but it won't otherwise cause harmful effects for anyone who has the internet.

Users without internet, however, will lose access to their purchased features until they're back on line. At that point, Play Services will renotify the app that they own the feature and it will be recached. (I've just had a panic about subscriptions. But I think that's true even for them.)

Ironically we use a file on iOS because storage was far more flaky. (And also because iTunes wouldn't renotify us of purchases and because on iOS we had to store the level of consumables.)

[Temmokan]

So

- Google Chrome doesn't create profile backup before any upgrade; if anything breaks, it's lost for good

- Google Chrome isn't in fact thoroughly tested within Google - the guinea pigs are randomly selected real-life users (a great cost saving)

- users, in their absolute majority, have no habit and/or knowledge of backing up their data

Welcome to brave new world.