8 ms·

Parody aside, we actually need something like this. Here’s a non-exhaustive list of breaking changes to the web platform: https://github.com/styfle/breaking-c

by styfle 5y ago

Parody aside, we actually need something like this. Here’s a non-exhaustive list of breaking changes to the web platform: https://github.com/styfle/breaking-changes-web https://github.com/styfle/breaking-changes-web

buu700 5y ago
I'd add HTTP Public Key Pinning (HPKP) to the list. I was burned by that one.
- AnonHP 5y ago
  Could you elaborate more? I’ve seen advice that it’s not recommended (and not been recommended for some years), but I’ve also seen questions in recent times by app developers who are bent on using it to “increase the security” (as it relates to where the apps want to connect to securely without any interception/modification).
  - freeone3000 5y ago
    HPKP locks you into one public key forever, so you can't ever rotate private keys for your website. (You can rotate the cert, but this isn't the same.) Heartbleed was one time where your keys would be leaked and you'd have to rotate, but even normal business processes prefer key rotation (and heaven forfend you ever lose it!). Too much burden for too little gain.
    - rossy 5y ago
      No, HPKP didn't lock you into one public key forever. You could rotate keys. The HPKP header had an expiry date and let you specify multiple keys, so you could add a new key to the list and switch over when the previous key expired.
    - smnrchrds 5y ago
      Plus, I think it can make a domain unusable forever. You can end up buying a domain you cannot use because the previous owner had used HPKP.
    - toast0 5y ago
      It makes sense to use HPKP to pin to a CA (maybe a CA's intermediate, I can't remember what they let you do) or better, multiple. Depending on your expiration, and what terrible thing happens in the PKI universe, you should probably be able to resolve an issue if you've got multiple independent CAs pinned.
  - buu700 5y ago
    Sure, I'll just defer to an older comment on this: https://news.ycombinator.com/item?id=17779395 https://news.ycombinator.com/item?id=17779395 --- 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 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.
    - bawolff 5y ago
      Hmm, https://www.cyph.com/websign-architecture https://www.cyph.com/websign-architecture the hkpk suicide bit is a beautiful hack, but is so far removed from the motivating purpose of hpkp, that i dont think you can really blame web browsers for not caring. 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.
      - buu700 5y ago
        Ah yeah, 100% agreed. I think it was a cool concept, but if we're being fair we were practically exploiting a vulnerability in HPKP to produce unintended behavior. (On that note, one of the HPKP Suicide demos we presented at Black Hat and DEF CON was actually a ransomware concept.) 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.)
chrismorgan 5y ago
> Forms with passwords marked Not Secure over HTTP 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).
- electroly 5y ago
  If I'm interpreting the list right, I think they agree with you about flatten. I think the strikeout is supposed to indicate that the struck portion would have made the list, but they took corrective action. I spelunked through the commit history and the struck portion was indeed unstruck originally, and then when the situation was resolved they crossed it out and added the description afterwards.
kristopolous 5y ago
Take the word "deprecated" with a grain of salt. I've got a project that utilizes an HTML tag deprecated in 1993! https://github.com/kristopolous/TopLevel https://github.com/kristopolous/TopLevel 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 http://9ol.es/TopLevel/example.html reference rendering: http://9ol.es/tl.png 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 https://news.ycombinator.com/item?id=7850301
- adzm 5y ago
  This is a crazy hack! I'm amazed it works.
  - kristopolous 5y ago
    appears to actually be flaky these days. I'll have to get back to it and figure it out. There's something subtle going on on mobile chrome. Things are being done differently. The image appears to get pre-fetched even though technically, according to the old-school <script> blocking rule, it shouldn't. 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!
- Sohcahtoa82 5y ago
  That'll be a fun tag to use the next time I find an XSS vulnerability.
  - kristopolous 5y ago

by styfle 5y ago

buu700 5y ago

I'd add HTTP Public Key Pinning (HPKP) to the list. I was burned by that one.

AnonHP 5y ago
Could you elaborate more? I’ve seen advice that it’s not recommended (and not been recommended for some years), but I’ve also seen questions in recent times by app developers who are bent on using it to “increase the security” (as it relates to where the apps want to connect to securely without any interception/modification).
- freeone3000 5y ago
  HPKP locks you into one public key forever, so you can't ever rotate private keys for your website. (You can rotate the cert, but this isn't the same.) Heartbleed was one time where your keys would be leaked and you'd have to rotate, but even normal business processes prefer key rotation (and heaven forfend you ever lose it!). Too much burden for too little gain.
  - rossy 5y ago
    No, HPKP didn't lock you into one public key forever. You could rotate keys. The HPKP header had an expiry date and let you specify multiple keys, so you could add a new key to the list and switch over when the previous key expired.
  - smnrchrds 5y ago
    Plus, I think it can make a domain unusable forever. You can end up buying a domain you cannot use because the previous owner had used HPKP.
  - toast0 5y ago
    It makes sense to use HPKP to pin to a CA (maybe a CA's intermediate, I can't remember what they let you do) or better, multiple. Depending on your expiration, and what terrible thing happens in the PKI universe, you should probably be able to resolve an issue if you've got multiple independent CAs pinned.
- buu700 5y ago
  Sure, I'll just defer to an older comment on this: https://news.ycombinator.com/item?id=17779395 https://news.ycombinator.com/item?id=17779395 --- 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 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.
  - bawolff 5y ago
    Hmm, https://www.cyph.com/websign-architecture https://www.cyph.com/websign-architecture the hkpk suicide bit is a beautiful hack, but is so far removed from the motivating purpose of hpkp, that i dont think you can really blame web browsers for not caring. 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.
    - buu700 5y ago
      Ah yeah, 100% agreed. I think it was a cool concept, but if we're being fair we were practically exploiting a vulnerability in HPKP to produce unintended behavior. (On that note, one of the HPKP Suicide demos we presented at Black Hat and DEF CON was actually a ransomware concept.) 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.)

chrismorgan 5y ago

> Forms with passwords marked Not Secure over HTTP 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).

electroly 5y ago
If I'm interpreting the list right, I think they agree with you about flatten. I think the strikeout is supposed to indicate that the struck portion would have made the list, but they took corrective action. I spelunked through the commit history and the struck portion was indeed unstruck originally, and then when the situation was resolved they crossed it out and added the description afterwards.

kristopolous 5y ago

Take the word "deprecated" with a grain of salt. I've got a project that utilizes an HTML tag deprecated in 1993! https://github.com/kristopolous/TopLevel https://github.com/kristopolous/TopLevel 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 http://9ol.es/TopLevel/example.html reference rendering: http://9ol.es/tl.png 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 https://news.ycombinator.com/item?id=7850301

adzm 5y ago
This is a crazy hack! I'm amazed it works.
- kristopolous 5y ago
  appears to actually be flaky these days. I'll have to get back to it and figure it out. There's something subtle going on on mobile chrome. Things are being done differently. The image appears to get pre-fetched even though technically, according to the old-school <script> blocking rule, it shouldn't. 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!
Sohcahtoa82 5y ago
That'll be a fun tag to use the next time I find an XSS vulnerability.
- kristopolous 5y ago