4 ms·

This makes no sense for this example. It's an always enabled browser security API. It doesn't expose anything about the device, it doesn't even have state, they

This makes no sense for this example. It's an always enabled browser security API. It doesn't expose anything about the device, it doesn't even have state, they're just proposing a new Sanitizer API with methods to sanitize DOM objects. All you could detect is its presence, which provides far less info than the browser version alone. There are other fingerprinting issues on the web, sure, but this is not one of them. The knee-jerk "all changes on the web are bad" responses are not helpful.

0xy 5y ago
The change is redundant because there are userspace solutions today, and they will continue to be used for decades. So what use does this serve? Another fingerprinting vector to narrow down browser versions, or worse -- a security hole. When the "Web Audio API" was rolled out by the Chrome team not only was it fundamentally flawed, but it also contained memory leak CVEs. Every time they add more trash to the browser nobody asks for (except their ad clients), they introduce more security problems. So -- why are they adding more APIs when they could fix the old ones that are utterly broken and abused daily by the ad industry? $$$.
- maple3142 5y ago
  Because DOMPurify is not perfect. Due to some problem of HTML parsing, there were some ways to bypass it: https://research.securitum.com/mutation-xss-via-mathml-mutation-dompurify-2-0-17-bypass/ https://research.securitum.com/mutation-xss-via-mathml-mutat... Having a builtin XSS sanatizer means it could always use a single parser to prevent such bypass.
- pimterry 5y ago
  The browser version is always already accessible, and even in future plans to reduce user agent info (https://www.chromestatus.com/feature/5704553745874944 https://www.chromestatus.com/feature/5704553745874944) the major version number is never going to be hidden. This API exposes zero new fingerprinting bits. Meanwhile userspace solutions for the same solution are a) occasionally buggy b) not as widely used as they should be c) not as performant as they could be if implemented directly within the browser and d) not automatically updated as new browser features are released. Standardizing this will improve all of that. It is valuable to standardize APIs and build them into the web for features like this where there's a clearly correct approach that's required by a large percentage of modern sites (anything with client side dynamic content). Having browser vendors implement this, embedded in the browser itself and supported by browser implementers directly, is a free security win for the web.
- bugmen0t 5y ago
  The intent is to shift the responsibility to the browser. Decades worth of userspace solution have failed us. The browser is pretty good at HTML parsing.

0xy 5y ago

The change is redundant because there are userspace solutions today, and they will continue to be used for decades. So what use does this serve? Another fingerprinting vector to narrow down browser versions, or worse -- a security hole. When the "Web Audio API" was rolled out by the Chrome team not only was it fundamentally flawed, but it also contained memory leak CVEs. Every time they add more trash to the browser nobody asks for (except their ad clients), they introduce more security problems. So -- why are they adding more APIs when they could fix the old ones that are utterly broken and abused daily by the ad industry? $$$.

maple3142 5y ago
Because DOMPurify is not perfect. Due to some problem of HTML parsing, there were some ways to bypass it: https://research.securitum.com/mutation-xss-via-mathml-mutation-dompurify-2-0-17-bypass/ https://research.securitum.com/mutation-xss-via-mathml-mutat... Having a builtin XSS sanatizer means it could always use a single parser to prevent such bypass.
pimterry 5y ago
The browser version is always already accessible, and even in future plans to reduce user agent info (https://www.chromestatus.com/feature/5704553745874944 https://www.chromestatus.com/feature/5704553745874944) the major version number is never going to be hidden. This API exposes zero new fingerprinting bits. Meanwhile userspace solutions for the same solution are a) occasionally buggy b) not as widely used as they should be c) not as performant as they could be if implemented directly within the browser and d) not automatically updated as new browser features are released. Standardizing this will improve all of that. It is valuable to standardize APIs and build them into the web for features like this where there's a clearly correct approach that's required by a large percentage of modern sites (anything with client side dynamic content). Having browser vendors implement this, embedded in the browser itself and supported by browser implementers directly, is a free security win for the web.
bugmen0t 5y ago
The intent is to shift the responsibility to the browser. Decades worth of userspace solution have failed us. The browser is pretty good at HTML parsing.