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...
It wasn't just the browsers. Some CAs supported this for a long time, and even directly endorsed the ballot.
You're not wrong about the browsers having 'the power', but then again - they are the representatives of billions of relying parties, so it's expected.
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.
Only if you pin a CA/Browser Forum-approved certificate. But you don't have to do that.
You can instead pin a self-signed or private CA-signed certificate, and then it can have the maximum lifetime you're comfortable with and that the software supports. A related option is to ship your app with a copy of your private CA certificate(s) and configure the HTTPS client to trust those in addition to, or instead of, the system-provided CAs.
I'm not sure how viable these approaches are on more locked-down platforms (like smartphones) and, even if they are viable today, whether they will remain viable in the future. It's also only good for full apps; anything that uses the system browser has to stick with the system CAs.
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.
Interrogate the thought more carefully. I understand why your default assumption is that securing DNS records is a good thing. But why is that, really? All sorts of things aren't secured cryptographically --- ARP! IP options! --- and we don't care. The modern Internet was designed with the assumption that the DNS is insecure.
ARP, and more generally any single-segment Ethernet network, is insecure, and it’s a problem. It’s just a very ingrained problem that’s unlikely to get fixed any time soon.
I don't understand your argument. Again, we have SPF and DKIM now, and neither rely on DNSSEC, which is good, because virtually nobody uses DNSSEC. You absolutely do need SPF and DKIM configured to be a mail sender; the Internet does rely on those. But you do not need DNSSEC to do that, and nobody cares if you do or don't.
That's not how security works. In the real world, security is in part a resource allocation problem. We spend resources to raise the cost of an attack over the threshold a model attacker would pay. There is a reason nobody gives enough of a shit to sign SPF records, and you can start to see it by taking the time to track down all the incident reports where someone exploited cache poisoning to override SPF.
I kind of wish there was a version of 'Against DNSSEC' that was just about that. The 'Unnecessary' and 'Architecturally Unsound' parts of that argument are so strong, the other bits end up feeling like springboards for DNSSECtarians to launch into debate.
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.
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.
Or certificates which were revoked