5 ms·

This is good of course, however, it will probably take at least 5+ years until a majority of users use eventual browsers that has this feature built-in.

lloydatkinson 5y ago
Why would it take five years for Chrome to implement it?
- fabiospampinato 5y ago
  It's already implemented in Chrome latest, available under a flag. Although support for <svg> and <math> elements is not in yet.
- skrebbel 5y ago
  It won't, but it will take a while (not sure about five years) for everybody to be on the latest version. Chrome has nice auto-update but not everybody has it enabled, for all kinds of good and bad reasons.
  - wongarsu 5y ago
    According to statcounter.com any new Chrome version is adopted by a large majority of users within 30 days [1]. Sure, some cooperate users hold out much longer, but those seem to be a tiny minority. 1: https://gs.statcounter.com/browser-version-market-share https://gs.statcounter.com/browser-version-market-share
    - codedokode 5y ago
      There are other browsers except for Chrome. For example there are built-in browsers in smartphones that will never be updated. It is wrong to rely on everyone using a latest version of a browser. Every site should support at least 5 years old browsers and a good site will be usable in 10 years old browser including builtin browser of Windows. Sadly, in reality most sites are made so poorly that they don't open on 5-years old smartphone. It shows how low qualified became modern web developers.
      - wongarsu 5y ago
        I agree that apps will need a fallback for a couple years. So far only Chrome and Firefox are implementing it, and given that Safari took 2.5 years for IntersectionObserver I wouldn't hold my breath until we can even claim that all major browsers implement this. But this API doesn't implement anything we couldn't do before, it's a more correct and much faster implementation of something we already have libraries for. The vast majority of users will have an almost immediate benefit from sites using this API, both in speed and security. That's what I take this comment chain to be about, since talking about "a majority" doesn't make sense otherwise. Supporting browser versions used by at most 2% of all users is the name of the game in webdev, that's what made IE so annoying.
- 19870213 5y ago
  You're forgetting 'legacy' devices, as in, older than a couple of minutes. I maintain an application that is used in primary education in the Netherlands, and the oldest device thus far with issues is an iPad4 with iOS10.3, which the school only invested in a couple of years ago (I don't know any further details). And in their infinite wisdom Apple fixed the safari version to the ios version, and no alternative browsers allowed. /rant
  - TheCoelacanth 5y ago
    Well, they did say "majority", which would be covered just by Chrome users alone. Granted, most sites aren't going to be willing to write off Safari users, so they are almost always going to be the ones you are waiting on.
fleddr 5y ago
Even after 5 years, you will continue to need to implement a fallback, basically forever. An attacker will always be able to use an older browser version that does not have the built-in feature.
- matsemann 5y ago
  That's not how XSS generally works. You need a victim to visit a trusted page where you've managed to insert some html/scripts, and then execute that in the context of the user (cookies, read sensitive data etc). If you can trick a user to use a different browser, you probably already have full control.
- jacobmischka 5y ago
  It doesn't matter if attackers can intentionally use older browsers, they can also use other tools like curl or even an intentionally malicious browser application that doesn't have these features either. It matters if users use the secure browsers, and with Chrome, Firefox, and (hopefully) Safari implementing it the vast majority of them will within a few release cycles.
- tlamponi 5y ago
  > An attacker will always be able to use an older browser version that does not have the built-in feature. You do not purify DOM for the attackers' browser, they can just open the dev console and execute arbitrary JS anyway, you purify it so that user-input that one renders is also safe for others users to see without allowing attacker controlled scripts to be executed or DOM elements that leak user info on load to be inserted. And you can always simply start to show a banner that tells "contnet blocked, upgrade your browser" in a few years, once a big enough majority of your target user base upgraded to a browser that supports it.
deleted 5y ago
[deleted]
dwheeler 5y ago
The problem isn't that you need a majority; in many such situations you need a supermajority. It's usually not okay if your website can't be safely used by 49% of your users. In particular, Apple is notoriously slow at improving its JavaScript support in iOS, and they don't allow competing JavaScript implementations to run on iOS, so on iOS you're stuck. In this case, as long as there is an easily-available OSS polyfill, it'll be okay. Ideally sites will only load the polyfill when they need to (primarily only if they're on iOS).

lloydatkinson 5y ago

Why would it take five years for Chrome to implement it?

fabiospampinato 5y ago
It's already implemented in Chrome latest, available under a flag. Although support for <svg> and <math> elements is not in yet.
skrebbel 5y ago
It won't, but it will take a while (not sure about five years) for everybody to be on the latest version. Chrome has nice auto-update but not everybody has it enabled, for all kinds of good and bad reasons.
- wongarsu 5y ago
  According to statcounter.com any new Chrome version is adopted by a large majority of users within 30 days [1]. Sure, some cooperate users hold out much longer, but those seem to be a tiny minority. 1: https://gs.statcounter.com/browser-version-market-share https://gs.statcounter.com/browser-version-market-share
  - codedokode 5y ago
    There are other browsers except for Chrome. For example there are built-in browsers in smartphones that will never be updated. It is wrong to rely on everyone using a latest version of a browser. Every site should support at least 5 years old browsers and a good site will be usable in 10 years old browser including builtin browser of Windows. Sadly, in reality most sites are made so poorly that they don't open on 5-years old smartphone. It shows how low qualified became modern web developers.
    - wongarsu 5y ago
      I agree that apps will need a fallback for a couple years. So far only Chrome and Firefox are implementing it, and given that Safari took 2.5 years for IntersectionObserver I wouldn't hold my breath until we can even claim that all major browsers implement this. But this API doesn't implement anything we couldn't do before, it's a more correct and much faster implementation of something we already have libraries for. The vast majority of users will have an almost immediate benefit from sites using this API, both in speed and security. That's what I take this comment chain to be about, since talking about "a majority" doesn't make sense otherwise. Supporting browser versions used by at most 2% of all users is the name of the game in webdev, that's what made IE so annoying.
19870213 5y ago
You're forgetting 'legacy' devices, as in, older than a couple of minutes. I maintain an application that is used in primary education in the Netherlands, and the oldest device thus far with issues is an iPad4 with iOS10.3, which the school only invested in a couple of years ago (I don't know any further details). And in their infinite wisdom Apple fixed the safari version to the ios version, and no alternative browsers allowed. /rant
- TheCoelacanth 5y ago
  Well, they did say "majority", which would be covered just by Chrome users alone. Granted, most sites aren't going to be willing to write off Safari users, so they are almost always going to be the ones you are waiting on.

fleddr 5y ago

Even after 5 years, you will continue to need to implement a fallback, basically forever. An attacker will always be able to use an older browser version that does not have the built-in feature.

matsemann 5y ago
That's not how XSS generally works. You need a victim to visit a trusted page where you've managed to insert some html/scripts, and then execute that in the context of the user (cookies, read sensitive data etc). If you can trick a user to use a different browser, you probably already have full control.
jacobmischka 5y ago
It doesn't matter if attackers can intentionally use older browsers, they can also use other tools like curl or even an intentionally malicious browser application that doesn't have these features either. It matters if users use the secure browsers, and with Chrome, Firefox, and (hopefully) Safari implementing it the vast majority of them will within a few release cycles.
tlamponi 5y ago
> An attacker will always be able to use an older browser version that does not have the built-in feature. You do not purify DOM for the attackers' browser, they can just open the dev console and execute arbitrary JS anyway, you purify it so that user-input that one renders is also safe for others users to see without allowing attacker controlled scripts to be executed or DOM elements that leak user info on load to be inserted. And you can always simply start to show a banner that tells "contnet blocked, upgrade your browser" in a few years, once a big enough majority of your target user base upgraded to a browser that supports it.

deleted 5y ago

[deleted]

dwheeler 5y ago

The problem isn't that you need a majority; in many such situations you need a supermajority. It's usually not okay if your website can't be safely used by 49% of your users. In particular, Apple is notoriously slow at improving its JavaScript support in iOS, and they don't allow competing JavaScript implementations to run on iOS, so on iOS you're stuck. In this case, as long as there is an easily-available OSS polyfill, it'll be okay. Ideally sites will only load the polyfill when they need to (primarily only if they're on iOS).