Intent To Deprecate and Remove: Remove Content Type Sniffing for Worker Scripts

[Daniel Vogelheim]

Contact emails

voge...@chromium.org, mkwst@chromium.org

Summary

Remove content sniffing for worker scripts. That is, reject all worker javascript resource that have are delivered with a MIME type that is not supported for JavaScript.

("supported for JavaScript" == listed in kSupporedJavascriptTypes in mime_util.cc)

Motivation

Web browsers will execute JavaScript, use CSS, etc., even if the Content-Type: header indicates a non-matching MIME type. For example, including a text/html resource via a <script src=.... > tag would succeed. This has been a security concern for quite a while, and there's a long-standing desire to eliminate or at least reduce this. The main blocker for removing this mis-feature is legacy usage.

This intent intents to disable 'content type sniffing' for worker scripts only. That is, only allow execution from resources with a supported JavaScript content type. This edges us a little closer to the goal of never second-guessing the content type of a resource. Since worker scripts are a relatively new addition to the web platform, they don't usually have legacy usage. UseCounter confirms that usage of content type mismatches in worker scripts is low. Hence we can remove this undesired functionality now without significant risk.

Interoperability and Compatibility Risk

Firefox: Tentative support voiced.

Edge: No signal.

Safari: No signal.

Reference: https://github.com/whatwg/html/issues/3255

Alternative implementation suggestion for web developers

Serve JavaScript resources with a "text/javascript" content type.

Developers will be alerted through the existing console warning

  (which is currently triggered e.g. by the "X-Content-Type-Options: nosniff" header),

  "Refused to execute script from ... because its MIME type (...) is ...".

Usage information from UseCounter

- ~0.01% of page loads contain worker scripts that would fail these stricter checks

Further metrics & discussion can be found in https://github.com/whatwg/html/issues/3255

OWP launch tracking bug

https://crbug.com/794548

Entry on the feature dashboard

https://www.chromestatus.com/feature/6037497138118656

[Mike West]

(I’m abstaining on this, since my name is on it, but for clarity: this seems like a good idea to me, moving us towards the eventual goal of enforcing MIME type checks generally. The numbers for Workers are low and the workaround for developers is straightforward. +1 from me!)

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPOW99Zwqyok1qOy0pMyo%3DhBxfWuo2711sTLsBDcJVQ%2BAw%40mail.gmail.com.

--

-mike

[Chris Harrelson]

0.01% is quite a lot, given what it could do to the site. This will need at least a deprecation for one release cycle since it could break sites pretty badly. Also, it looks like a few sites (e.g. graph.facebook.com) account for most of the use. Have you reached out to them to fix their response types?

Chris 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DcV0asGbS9FqSOrRZ5kwVrvPq7jUT6%3Do%2BzgVNytcBbABw%40mail.gmail.com.

[Rick Byers]

+1 to what Chris says.  Facebook in particular should be easy to get fixed (talk to owencm to get in touch), and if not that's a really valuable signal.  Hopefully if we can get a couple major sits fixed, the usage will drop dramatically and it'll be a no-brainer.

Could be a good candidate for UKM UseCounters.  Talk to loonybear@.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8RzoMAUCEQY%2BcajbNZZqPBFdatbFbX8RZNyWE%3D4ThE0g%40mail.gmail.com.

[Mike West]

Hey folks! The metrics Daniel pointed to in the original thread have hit stable, and have made their way to HTTPArchive, which makes analysis simpler.

In HTTP archive, there are 6 hits for `CrossOriginWorkerTextHtml`, which is hovering around 0.012% of page views over the last month. In itself, this low number in HTTPArchive vs the higher number Out There On The Web somewhat confirms my suspicion that it's ads and measurement widgets, but let's dig in:

*   http://www.autorambler.ru/, http://www.balkaninsight.com/, and http://www.building-body.com/ All 6 pages include a script from `t.contentinsights.com`, which stuffs a few Blob scripts into dedicated Workers, which  `importScript` some JSONP from `https://graph.facebook.com/` and `http://www.building-body.com/` (the former served as `application/json`, the latter as `text/html`).

*   https://www.wikitribune.com/, http://www.gb.by, and http://www.quto.ru/ load a script from a random hostname (like https://d7d3cf2e81d293050033-3dfc0615b0fd7b49143049256703bfce.ssl.cf1.rackcdn.com/stf.js) that looks like it's copy/pasted from the same source as the script above.

Likewise, there are 6 hits for `CrossOriginWorkerTextPlain`, which is hovering around 0.0006% of page views over the last month:

*   https://www.avis.co.in/, https://www.carnivalcinemas.com/, https://iho.in/, https://www.jetairways.com/, and https://www.techgig.com/ all have a service worker, which attempts to set up push messaging (in a fairly pushy way) by `importScript`ing https://cdnp.notifyvisitors.com/js/brand_hosted/push-worker.js and a configuration block from https://s3.amazonaws.com/notifypush/cache_worker/config-4567.js (the latter served as `text/plain`).

*   http://www.religarehealthinsurance.com/ didn't resolve (I'd put money on it being the same script from the same source. :) )

There's one hit for `CrossOriginWorkerApplicationOctetStream`, which hovers around 0% of page views:

*   https://www.gimpshop.com/ has a service worker, which `importScript`s https://s3-us-west-2.amazonaws.com/psi-notifications/general/sfsw.js, which does a number of things, including agressively asking for push message permissions.

This data suggests a few things:

1.  We should reach out to VK and Facebook to see if they'd be willing to change their service endpoints to serve JSONP as `application/javascript`.

2.  We should reach out to NotifyVisitors to ask them to poke at their S3 buckets to change the MIME type of their configuration scripts from `text/plain` to `application/javascript`.

3.  Users would see very little breakage if all of the scripts above just stopped working catastrophically.

I'd like to proceed with deprecation and removal, in conjunction with outreach to the services listed above. I think that has a good chance of success. WDYT?

-mike

[Chris Harrelson]

On Wed, Mar 21, 2018 at 1:33 AM Mike West <mk...@chromium.org> wrote:

Hey folks! The metrics Daniel pointed to in the original thread have hit stable, and have made their way to HTTPArchive, which makes analysis simpler.

In HTTP archive, there are 6 hits for `CrossOriginWorkerTextHtml`, which is hovering around 0.012% of page views over the last month. In itself, this low number in HTTPArchive vs the higher number Out There On The Web somewhat confirms my suspicion that it's ads and measurement widgets, but let's dig in:

*   http://www.autorambler.ru/, http://www.balkaninsight.com/, and http://www.building-body.com/ All 6 pages include a script from `t.contentinsights.com`, which stuffs a few Blob scripts into dedicated Workers, which  `importScript` some JSONP from `https://graph.facebook.com/` and `http://www.building-body.com/` (the former served as `application/json`, the latter as `text/html`).

*   https://www.wikitribune.com/, http://www.gb.by, and http://www.quto.ru/ load a script from a random hostname (like https://d7d3cf2e81d293050033-3dfc0615b0fd7b49143049256703bfce.ssl.cf1.rackcdn.com/stf.js) that looks like it's copy/pasted from the same source as the script above.

Likewise, there are 6 hits for `CrossOriginWorkerTextPlain`, which is hovering around 0.0006% of page views over the last month:

*   https://www.avis.co.in/, https://www.carnivalcinemas.com/, https://iho.in/, https://www.jetairways.com/, and https://www.techgig.com/ all have a service worker, which attempts to set up push messaging (in a fairly pushy way) by `importScript`ing https://cdnp.notifyvisitors.com/js/brand_hosted/push-worker.js and a configuration block from https://s3.amazonaws.com/notifypush/cache_worker/config-4567.js (the latter served as `text/plain`).

*   http://www.religarehealthinsurance.com/ didn't resolve (I'd put money on it being the same script from the same source. :) )

There's one hit for `CrossOriginWorkerApplicationOctetStream`, which hovers around 0% of page views:

*   https://www.gimpshop.com/ has a service worker, which `importScript`s https://s3-us-west-2.amazonaws.com/psi-notifications/general/sfsw.js, which does a number of things, including agressively asking for push message permissions.

This data suggests a few things:

1.  We should reach out to VK and Facebook to see if they'd be willing to change their service endpoints to serve JSONP as `application/javascript`.

2.  We should reach out to NotifyVisitors to ask them to poke at their S3 buckets to change the MIME type of their configuration scripts from `text/plain` to `application/javascript`.

3.  Users would see very little breakage if all of the scripts above just stopped working catastrophically.

I'd like to proceed with deprecation and removal, in conjunction with outreach to the services listed above. I think that has a good chance of success. WDYT?

I'm ok with deprecation for one milestone and then removal in parallel with reaching out to VK and Facebook. If they don't respond/are unable to fix in time please come back for more discussion. LGTM1 for this plan.

 

-mike

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DcV0asGbS9FqSOrRZ5kwVrvPq7jUT6%3Do%2BzgVNytcBbABw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

[Daniel Bratell]

LGTM2 (to the deprecation., outreach and removal plan outlined below)

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_uuUhzFFxgBin3%2B-j-5LMXrorA4-teXpKB9OE-QfSjnw%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[Rick Byers]

Looks like that's actually the LGTM3, so we're done :-)

Mike, can you also try those known sites on a build with the planned behavior change to see if you can confirm the "severity of breakage" is indeed low in the cases you can find?  Eg. is facebook integration visibly broken or anything?

Assuming there's not some obvious serious breakage in any of these examples, then I agree the risk is probably low enough for a one milestone deprecation then attempted removal.

-mike

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DcV0asGbS9FqSOrRZ5kwVrvPq7jUT6%3Do%2BzgVNytcBbABw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8RzoMAUCEQY%2BcajbNZZqPBFdatbFbX8RZNyWE%3D4ThE0g%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_uuUhzFFxgBin3%2B-j-5LMXrorA4-teXpKB9OE-QfSjnw%40mail.gmail.com.