Intent to Ship: Protect `application/x-protobuffer` via Cross-Origin-Read-Blocking

[David Dworken]

Contact emails

ddwo...@google.com

Explainer

None

Specification

https://www.chromium.org/Home/chromium-security/corb-for-developers

Summary

Protect `application/x-protobuffer` from speculative execution attacks by adding it to the list of never sniffed MIME types used by Cross-Origin-Read-Blocking. `application/x-protobuf` is already protected as a never sniffed mime type. `application/x-protobuffer` is another commonly used MIME type that is defined as an "ALT_CONTENT_TYPE" by the protobuf library. See the original Intent to Implement and Ship notice for CORB here: https://groups.google.com/a/chromium.org/g/blink-dev/c/hnA

Blink component

Blink>SecurityFeature

TAG review

Not necessary because this is just adding one additional MIME type to the CORB list

TAG review status

Not applicable

Risks

Interoperability and Compatibility

If a website includes a cross-origin resource via either `<script>` or `<img>` and the content type is set to `application/x-protobuffer` then CORB will block the response. The most common protobuf MIME type (`application/x-protobuf`) is already blocked by CORB so we expect this to break very few (if any) endpoints.

Gecko: Positive (https://github.com/annevk/orb/pull/17)

Edge: No signal

WebKit: No signal

Web developers: No signals

Is this feature fully tested by web-platform-tests?

Yes

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5670287242690560

[yo...@yoav.ws]

On Friday, February 5, 2021 at 12:11:24 AM UTC+1 David Dworken wrote:

Contact emails

ddwo...@google.com

Explainer

None

Specification

https://www.chromium.org/Home/chromium-security/corb-for-developers

Summary

Protect `application/x-protobuffer` from speculative execution attacks by adding it to the list of never sniffed MIME types used by Cross-Origin-Read-Blocking. `application/x-protobuf` is already protected as a never sniffed mime type. `application/x-protobuffer` is another commonly used MIME type that is defined as an "ALT_CONTENT_TYPE" by the protobuf library. See the original Intent to Implement and Ship notice for CORB here: https://groups.google.com/a/chromium.org/g/blink-dev/c/hnA

Blink component

Blink>SecurityFeature

TAG review

Not necessary because this is just adding one additional MIME type to the CORB list

TAG review status

Not applicable

Risks

Interoperability and Compatibility

If a website includes a cross-origin resource via either `<script>` or `<img>` and the content type is set to `application/x-protobuffer` then CORB will block the response. The most common protobuf MIME type (`application/x-protobuf`) is already blocked by CORB so we expect this to break very few (if any) endpoints.

Gecko: Positive (https://github.com/annevk/orb/pull/17)

I don't believe that counts as support from Mozilla. See https://bit.ly/blink-signals

[Alex Russell]

There's also no reason not to send a note to the TAG about this. They should understand the full set of mime types and their implications for loading; in particular, I'd expect them to have asked about mimetypes being sent by other data-type backends with similar implications (e.g. Thrift messages, flatbuffer data, etc.)

[Łukasz Anforowicz]

On Thursday, February 11, 2021 at 5:18:51 AM UTC-8 yo...@yoav.ws wrote:

On Friday, February 5, 2021 at 12:11:24 AM UTC+1 David Dworken wrote:

Contact emails

ddwo...@google.com

Explainer

None

Specification

https://www.chromium.org/Home/chromium-security/corb-for-developers

Summary

Protect `application/x-protobuffer` from speculative execution attacks by adding it to the list of never sniffed MIME types used by Cross-Origin-Read-Blocking. `application/x-protobuf` is already protected as a never sniffed mime type. `application/x-protobuffer` is another commonly used MIME type that is defined as an "ALT_CONTENT_TYPE" by the protobuf library. See the original Intent to Implement and Ship notice for CORB here: https://groups.google.com/a/chromium.org/g/blink-dev/c/hnA

Blink component

Blink>SecurityFeature

TAG review

Not necessary because this is just adding one additional MIME type to the CORB list

TAG review status

Not applicable

Risks

Interoperability and Compatibility

If a website includes a cross-origin resource via either `<script>` or `<img>` and the content type is set to `application/x-protobuffer` then CORB will block the response. The most common protobuf MIME type (`application/x-protobuf`) is already blocked by CORB so we expect this to break very few (if any) endpoints.

Gecko: Positive (https://github.com/annevk/orb/pull/17)

I don't believe that counts as support from Mozilla. See https://bit.ly/blink-signals

The unfortunate current state is that 1) CORB is only implemented in Chromium and 2) only part of CORB is covered by https://fetch.spec.whatwg.org/.  Hopefully this can change once Chromium and Firefox experiment with CORB's alternative: ORB (https://github.com/annevk/orb) and decide based in these experiments whether to proceed with one or the other (I am currently working on UMA covering subset of ORB and hope to land it in M90;  AFAIK Firefox is actively implementing full ORB).  Given this, I hope that you can excuse not covering `application/x-protobuffer` anywhere other than https://github.com/annevk/orb/pull/17.

I think that the current state (while indeed unfortunate and undesirable in the long-term) is well justified in the short-term:

• One reason why CORB is right now a Chromium-only feature is because CORB is not a strong defense in absence of OOPIFs (out-of-process iframes).  As OOPIFs are worked on in other browsers (e.g. project Fusion in Firefox) they will have to adopt CORB (or ORB) to get full security benefits - this gives us an opportunity to align (and as pointed out above, we _are_ talking with Firefox about their ORB experiments).
• As pointed out in the original intent-to-ship for CORB (see here), it's border line whether this is even a web facing change.  CORB *is* web observable, but the effects of CORB are only visible in corner-cases (incorrect Content-Type): sometimes only visible to end-users (CORB blocked and therefore misrendered images), sometimes only visible to webpages (CORB blocked script requests).

I hope this helps,

Lukasz

[Yoav Weiss]

LGTM1

The fact that this is a small addition to the already shipped list, coupled with the fact that the web observability level of this list is low and that we are working with Mozilla on eventually defining it makes me comfortable shipping this specific change.

At the same time, I'd like to see some spec convergence before shipping future related features - either we converge on ORB, or send a PR/monkey-patch Fetch's (e.g. by adding a step to Fetch's determine nosniff that looks at MIME types and returns true if they are on the never-sniff list) to document what we do today.

On Sat, Feb 13, 2021 at 12:56 AM Łukasz Anforowicz <luk...@chromium.org> wrote:

On Thursday, February 11, 2021 at 5:18:51 AM UTC-8 yo...@yoav.ws wrote:

On Friday, February 5, 2021 at 12:11:24 AM UTC+1 David Dworken wrote:

Contact emails

ddwo...@google.com

Explainer

None

Specification

https://www.chromium.org/Home/chromium-security/corb-for-developers

Summary

Protect `application/x-protobuffer` from speculative execution attacks by adding it to the list of never sniffed MIME types used by Cross-Origin-Read-Blocking. `application/x-protobuf` is already protected as a never sniffed mime type. `application/x-protobuffer` is another commonly used MIME type that is defined as an "ALT_CONTENT_TYPE" by the protobuf library. See the original Intent to Implement and Ship notice for CORB here: https://groups.google.com/a/chromium.org/g/blink-dev/c/hnA

Blink component

Blink>SecurityFeature

TAG review

Not necessary because this is just adding one additional MIME type to the CORB list

TAG review status

Not applicable

Risks

Interoperability and Compatibility

If a website includes a cross-origin resource via either `<script>` or `<img>` and the content type is set to `application/x-protobuffer` then CORB will block the response. The most common protobuf MIME type (`application/x-protobuf`) is already blocked by CORB so we expect this to break very few (if any) endpoints.

Gecko: Positive (https://github.com/annevk/orb/pull/17)

I don't believe that counts as support from Mozilla. See https://bit.ly/blink-signals

The unfortunate current state is that 1) CORB is only implemented in Chromium and 2) only part of CORB is covered by https://fetch.spec.whatwg.org/.  Hopefully this can change once Chromium and Firefox experiment with CORB's alternative: ORB (https://github.com/annevk/orb) and decide based in these experiments whether to proceed with one or the other (I am currently working on UMA covering subset of ORB and hope to land it in M90;  AFAIK Firefox is actively implementing full ORB).  Given this, I hope that you can excuse not covering `application/x-protobuffer` anywhere other than https://github.com/annevk/orb/pull/17.

It's understandable how we ended up in that state (with the urgency in which CORB was shipped), but indeed unfortunate that we haven't properly specified the mechanisms since.

ORB seems like a step in the right direction.

 

I think that the current state (while indeed unfortunate and undesirable in the long-term) is well justified in the short-term:

• One reason why CORB is right now a Chromium-only feature is because CORB is not a strong defense in absence of OOPIFs (out-of-process iframes).  As OOPIFs are worked on in other browsers (e.g. project Fusion in Firefox) they will have to adopt CORB (or ORB) to get full security benefits - this gives us an opportunity to align (and as pointed out above, we _are_ talking with Firefox about their ORB experiments).

Encouraging to hear about the conversations with Mozilla!

• As pointed out in the original intent-to-ship for CORB (see here), it's border line whether this is even a web facing change.  CORB *is* web observable, but the effects of CORB are only visible in corner-cases (incorrect Content-Type): sometimes only visible to end-users (CORB blocked and therefore misrendered images)

Do we maintain the dimensions the image would have if not for CORB in such cases? If not, it's also web observable.

[Tom Jones]

I will always object to any stardardization of any mime type beginning with x-.  If it is to be added to the browser mime-types, it is worth the effort to get rid of the "x-".

Be the change you want to see in the world ..tom

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b64ece7e-7eba-408e-a361-62a820fcbbfan%40chromium.org.

[Łukasz Anforowicz]

Ack :-/ 

 

I think that the current state (while indeed unfortunate and undesirable in the long-term) is well justified in the short-term:

• One reason why CORB is right now a Chromium-only feature is because CORB is not a strong defense in absence of OOPIFs (out-of-process iframes).  As OOPIFs are worked on in other browsers (e.g. project Fusion in Firefox) they will have to adopt CORB (or ORB) to get full security benefits - this gives us an opportunity to align (and as pointed out above, we _are_ talking with Firefox about their ORB experiments).

Encouraging to hear about the conversations with Mozilla!

• As pointed out in the original intent-to-ship for CORB (see here), it's border line whether this is even a web facing change.  CORB *is* web observable, but the effects of CORB are only visible in corner-cases (incorrect Content-Type): sometimes only visible to end-users (CORB blocked and therefore misrendered images)

Do we maintain the dimensions the image would have if not for CORB in such cases? If not, it's also web observable.

Good point about image dimensions - they are not preserved (CORB replaces the response body with an empty body, so no, it doesn't preserve image dimensions).  And the results of image blocking are also observable through img.onerror (rather than img.onload) event - I forgot that we already have some coverage of that in wpt/fetch/corb/img-mime-types-coverage.tentative.sub.html.

[Łukasz Anforowicz]

On Sun, Feb 14, 2021 at 10:39 AM Tom Jones <thomascli...@gmail.com> wrote:

I will always object to any stardardization of any mime type beginning with x-.  If it is to be added to the browser mime-types, it is worth the effort to get rid of the "x-".

Be the change you want to see in the world ..tom

FWIW there are some precedents in other specs that already recognize the reality of having to deal with x-... MIME types:

• https://mimesniff.spec.whatwg.org/#javascript-mime-type: text/x-ecmascript, text/x-javascript, application/x-ecmascript, application/x-javascript
• https://mimesniff.spec.whatwg.org/#archive-mime-type: application/x-rar-compressed, application/x-gzip
  
• https://mimesniff.spec.whatwg.org/#matching-an-image-type-pattern: image/x-icon
  
• https://html.spec.whatwg.org/multipage/iana.html#multipart/x-mixed-replace: multipart/x-mixed-replace
  
• https://fetch.spec.whatwg.org/#body-mixin: application/x-www-form-urlencode

 

You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/87Q-8hjVtLE/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAK2Cwb5p-cFF2ETSaUWmPViGeKkoXcNuJvDv8n%3DXPvh04Vc3og%40mail.gmail.com.

[Łukasz Anforowicz]

Just to make sure the message clearly comes across, let me repeat it using a bit more impactful words.  We (the Chrome Security Architecture team in general and lukasza@ and creis@ in particular) are strongly committed to working with other browser vendors on making sure that browsers consistently adopt either CORB xor ORB + that both of these algorithms are fully covered by the specs.  At this point, our work in Chromium focuses on experimenting with ORB (e.g. see r858278) to help us collectively decide whether to continue using and tweaking CORB (and afterwards make sure that is fully covered by the specs) vs adopt ORB (replacing CORB with ORB in Chromium and in the Fetch spec).

[Mike West]

I'm quite supportive of protecting interesting MIME types behind CORB/ORB, and protobufs are certainly interesting!

I wonder whether y'all can help me understand the usage of this particular type, though. I took a quick trawl through HTTP Archive, and didn't see any non-Google resources in the 2021-02-01 run that returned this type (165 non-Google registrable domains returned `application/x-protobuf`).

Is this MIME type used outside of Google? If not, could we suggest to our friends at Google that they should drop a few letters from their `Content-Type` headers to gain protection today rather than waiting for M91 to ship?

-mike

[David Dworken]

Interesting that there aren't any usages in the HTTP Archive, I wonder whether protobuf endpoints are more likely to be behind auth. The protobuf libraries define this MIME type as an `ALT_CONTENT_TYPE` so at least as of now, it is a recommended MIME type. Looking around on Github, I do see a few non-google usages of it. Chrome itself also uses it in a few places. But I think you're definitely right that Google is the main user of it. 

If landing this change in Chrome is too difficult we can certainly withdraw this, but from my perspective this seems like an easy enough change that it is worth landing in order to ensure that all users of this MIME type are protected. 

[Mike West]

After some internal conversation, LGTM2.

David pointed me to some Android dependencies which make it difficult to shift away from `application/x-protobuffer`, as well as library usage across a reasonable number of GitHub projects. Since the MIME type has been in the reference implementation, and has spread from there to other implementations, pulling it back at this point is a losing battle.

I do agree with Alex, though, that poking the TAG about the general question of MIME types generally used for data transfer would be a good way to shift from piecemeal additions to something more holistic. I wouldn't block this change on that conversation, but would appreciate you kicking it off so that CORB and/or ORB can coalesce around something solid.

-mike

[Chris Harrelson]

LGTM3. I second what Mike said about standards followup in parallel with shipping.

--

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+...@chromium.org.

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