Parody aside, we actually need something like this.
Here’s a non-exhaustive list of breaking changes to the web platform:
Here’s a non-exhaustive list of breaking changes to the web platform:
It's <plaintext> which basically means "stop parsing for rest of the page". There's no way to close the tag. It's super easy to implement which is probably why it's still around.
Deprecated 28 years ago in HTML 1.1, yet still supported in all major browsers. Test page over here: http://9ol.es/TopLevel/example.html reference rendering: http://9ol.es/tl.png
There's some modern timing issue in chrome I think, it's intermittent Looks like there's a bug.
My original post on the hack, blowing off the cyber dust from 2014: https://news.ycombinator.com/item?id=7850301
I'll have to check the blink source whenever I have some free time. There's probably a strange way around it (for instance, maybe convincing the browser it's a really old website and it reverts to the traditional policy for compatibility or perhaps maybe there's another strange old feature I can leverage, I dunno I'll have to check). And yes, I know this is just pure theater and it's completely useless, I still want to do it well!
It requires a rather curious definition of “breaking change” to consider this one.
> A̶r̶r̶a̶y̶.̶p̶r̶o̶t̶o̶t̶y̶p̶e̶.̶f̶l̶a̶t̶t̶e̶n̶ ̶b̶r̶e̶a̶k̶s̶ ̶M̶o̶o̶T̶o̶o̶l̶s̶ renamed to Array.prototype.flat
That doesn’t belong in the list at all; it’s a prime example of the platform bending over backwards to avoid a breaking change, for better or for worse (it means that future users are stuck with an inferior name, see also contains which got renamed to includes because of, if I recall correctly, MooTools again).
---
8 points by buu700 on Aug 17, 2018 | parent | favorite | on: OpenPGPjs has passed an independent security audit
We (Cyph) have been pretty disappointed in the Chrome team's decision to kill HPKP.
Paraphrasing, but IIRC the reasoning pretty much boiled down to "it's a pain to maintain and Expect-CT is kind of similar anyway" — which I think is a really weak justification for harming end user security and breaking established APIs that people depend on in production. Fingers crossed that Firefox keeps it alive! [Narrator: They didn't.]
That said, it doesn't entirely break WebSign in Chrome, just weakens a bit further below strict TOFU. https://www.cyph.com/websign goes into detail, but WebSign has some client-side logic to validate its own hash against a signed whitelist. The major downsides to relying on this are:
1. It depends on a caching layer, not a security feature. This means that any guarantees are potentially out the window if a browser vendor decides to do something crazy for performance reasons or whatever.
2. It opens up an attack vector where it can be forcibly unpinned by filling up the user's disk and making the browser evict the cached WebSign instance.
All in all I think it's still basically fine, but shipping an optional browser extension for hardening WebSign is now a higher priority because of this.
Although i guess im kind of surprised that worked. I'd assume that service workers could fall out of cache before hkpk at random, and then your app would just be bricked (?) Seems like a bad failure case that could just happen without anything makicious going on, but maybe i just dont understand how service workers work well enough.
I'd assume that service workers could fall out of cache before hkpk at random, and then your app would just be bricked
Well... that did actually happen on occasion, although IIRC it was considered to be an edge case browser bug in the ServiceWorker and/or Persistent Storage implementations rather than expected behavior, since the locally installed worker shouldn't have been wiped before its replacement had been successfully fetched. We had to set up a support page with instructions to unpin the keys through about:config / chrome://net-internals, which wasn't really ideal. (Both browsers did end up actually fixing this, not that it ultimately did us much good.)