hackcoughgasp

I don't remember the names, but there were client programs designed to dial up, download pre-specified content, and disconnect, to minimize phone charges. My favorite client program (not an automated one) at the time was QModem (from John Friel of The Forbin Project, who recently passed away I believe). Not automated, just really well-designed.

>"outdated certificate data" would be domains you no longer control.

Or certificates which were revoked

I know this thread is over, but it's important to understand that it's the browsers who have all the power in CABF and they were the drivers behind this change. Apple proposed it and Google voted yes within minutes of the voting period opening. It was unanimous among CAs too (with 5 abstentions), and nobody really disagrees with it, but it was the browsers who started the initiative now. The article links to the vote thread: https://groups.google.com/a/groups.cabforum.org/g/servercert... And here's the CABF discussion before the vote: https://github.com/cabforum/servercert/pull/553/commits/69ce...

Certificate pinning is suicide in an environment where certificates expire in max 47 days. You'll have to rebuild and push your app at least that often and probably sync your devops with your certificate management.

I was a happy customer of The Forbin Project. QModem was a great product. It's probably hard for younger people to appreciate how important terminal software once was.

If you're going to argue that implementation difficulties make DNSSEC too much trouble I can respect the argument. To say that it doesn't solve a problem worth solving is strange.

They are definitely counter to Apple's interest, but Apple is slowly pushing Webkit along anyway. See caniuse.com. You'd think the same about Google, but as I say in the article (I'm the author) PWAs are happening because Google has put a lot of effort into promoting them, pushing the standards forward and implementing those standards in Chrome. Why? My guess is (once again, as I say in TFA) that once all the code is back up on the web, the advertising shifts back to the traditional ad networks, i.e. Google.

The standards are still young and implementation is spotty. Several years from now the things that you can't do in a web app will be few.

I'm the author of the article and I'd like to thank Nolan one more time. He really helped me to understand a lot about this. The storage issue is this: If you install a native app, the code is there on your device, the entire program, even if you haven't used it in a month. The code in the web version of that app would likely consume nothing soon. The amount of data consumed by each should be equal I think. No question Google has many teams working at cross purposes. It's a "throw everything up against the wall and see what sticks" approach. (What else could justify Chromebooks?) Apple has done this too in the past, but the distant past: Think Mac vs. Apple ][. But by now I think the value of their app store and ancillary revenue streams is so significant that institutionally I would expect them to be reluctant to do anything that would threaten it. I assumed in the story that Google had all the same perverse incentives as Apple in this regard, but I suppose app and in-app revenues for Google are probably a small fraction of Apple's. They're not even really trying hard to maximize that revenue. They allow 3rd party stores. But if even mobile devices moved back to the web, the ad revenue on them would move back to the platform that they dominate. So perhaps that explains their motivations.