Intent to Ship: fetch() credentials default to "same-origin"

[Dominic Farolino]

Contact emails

domfa...@gmail.com, yhi...@chromium.org, yo...@yoav.ws

Spec

https://fetch.spec.whatwg.org/#dom-request (see step 6)

Change here: https://github.com/whatwg/fetch/commit/811575d6889026c68d55a327f79198dccfea403c

There is no TAG review for this as it is an incredibly small modification to existing fetch() Request logic with minimal side effects.

Summary

A Request object’s credentials mode defaults to “omit” in Chrome right now. A spec change recently changed the default to “same-origin”, thus providing credentials to same-origin requests instead of omitting them. I intend to update Chromium to match the spec.

Link to “Intent to Implement” blink-dev discussion

Implementation is trivial, so there is no link here. The in-progress CL can be found at https://crrev.com/c/981512.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Demo link

https://fetch-event-echo.glitch.me/

Instructions: navigate to the site. Open DevTools and execute fetch(“test”). See that the default credentials mode for the created Request is “omit”, while the spec now mandates “same-origin”.

Risks

Interoperability and Compatibility

The interoperability risk here is low, as the change has shown positive signals in all browsers except Safari, shipped in Firefox nightly, and the Fetch Standard has been updated. The compatibility risk is also very low, as we’d now be including credentials on same-origin requests, which should have no impact on applications unless some servers for some reason get confused with credential info suddenly being included with certain requests.

Edge: Public support/issue is confirmed on their bug tracker

Firefox: Shipped in nightly, on track for stable in June

Safari: No signals

Web developers: Almost exclusively positive.

Ergonomics

We’ll potentially be sending more bytes down the wire (in form of credentials) on all fetch()-originating same-origin requests, but this likely won’t have a big performance impact.

Activation

No.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

• Chrome currently fails the request-init-003.sub.html and request-structure.html tests in https://wpt.fyi/fetch/api/request due to adhering to the old spec. The WPT changes have modified these files to test for compliant implementations.

Entry on the feature dashboard

Change is probably too small to have a corresponding feature in the dashboard, but if common opinion leans towards creating one, I’m happy to do so.

[PhistucK]

It would be great if you created an entry. This feeds the beta blog post and it basically means that cookies will now be sent with such requests to the same origin (right?).

Thank you!

☆PhistucK

--
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/6121b6d7-627f-4225-bc9f-6e5f85ea78ca%40chromium.org.

[Dominic Farolino]

That is correct. That sounds good, I'd be happy to create an entry. Any help with this would be appreciated though as I don't seem to have the appropriate access to do so.

☆PhistucK

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

[PhistucK]

Did you request access? The footer of chromestatus.com has some link.

☆PhistucK

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/fcc45292-bd92-428f-86d3-b50c7f47d448%40chromium.org.

[Dominic Farolino]

Ahh, I filled that out a few weeks ago for something unrelated, but have not heard back yet...wonder who I could ping.

☆PhistucK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fcc45292-bd92-428f-86d3-b50c7f47d448%40chromium.org.

[Yoav Weiss]

+Joe Medley - Can you make sure that Dominic has edit access to chromestatus.com?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/670700bd-678d-434f-87a7-60d320b1bbc7%40chromium.org.

[Mike West]

LGTM1. This is a nice ergonomic change for developers, with no actual change in the capability we expose. Following along with other vendors' implementations and the spec change sounds pretty reasonable.

Please do create a `chromestatus.com` entry once you're able (or ask one of your co-contacts to do so for you? :) ).

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEjofO-5suBYoK_bR32Wc%3DMSMBTA1Ad4ZHXyAy-2at%2BbLg%40mail.gmail.com.

[Yoav Weiss]

LGTM2 

(despite the fact that Dominic added me to the contact list, I'm not actively involved in this effort beyond reviewing the linked CL, so I'm permitting myself to weigh in)

Beyond the ergonomics improvements Mike mentioned, I suspect this will also have a nice performance improvement, as this will mean that `fetch()` calls (and eventually ES6 modules) will no longer use connections from the private connection pool, so will no longer contend on bandwidth with credentialed resources, and will get downloaded according to their assigned priority.

As far as compat risk goes, I agree with Philip's comment and think that cases where added credentials will cause issues will be sufficiently rare. Other browsers moving in that direction would certainly help to weed out even those rare cases.

On Wed, Apr 25, 2018 at 8:37 AM Mike West <mk...@chromium.org> wrote:

LGTM1. This is a nice ergonomic change for developers, with no actual change in the capability we expose. Following along with other vendors' implementations and the spec change sounds pretty reasonable.

Please do create a `chromestatus.com` entry once you're able (or ask one of your co-contacts to do so for you? :) ).

I suspect that vesting Dominic with "edit" rights to chromestatus.com will probably have a good ROI :) If that takes too long, I'm happy to help creating an entry there.

[Yoav Weiss]

Hmm, one compat issue I just realized (following this twitter exchange) we would have is when people use `<link rel=preload as=fetch crossorigin>` to preload `fetch()` called resources.

Once we switch, they will start seeing double downloads (at the same time, people getting it wrong now will stop seeing double downloads...)

Might be worth while to gather some data on that...

[Anne van Kesteren]

On Wed, Apr 25, 2018 at 3:09 PM, Yoav Weiss <yo...@yoav.ws> wrote:
> Hmm, one compat issue I just realized (following this twitter exchange) we
> would have is when people use `<link rel=preload as=fetch crossorigin>` to
> preload `fetch()` called resources.
>
> Once we switch, they will start seeing double downloads (at the same time,
> people getting it wrong now will stop seeing double downloads...)
>
> Might be worth while to gather some data on that...

Assuming there's a same-origin URL there (and the crossorigin thus not
being applicable as it has no relation to this change that I can see),
it seems this would be more compatible, as currently rel=preload uses
credentials, whereas fetch() would not. What am I missing?


--
https://annevankesteren.nl/

[Yoav Weiss]

Even for same origin, credential-less requests (*same-origin* credentials mode) are not being matched in the preload/memory cache with credentialed requests ("include" credentials mode). The reasoning for that is that these requests could be redirected to a different origin (and theoretically, redirected to different places).

Preload requests are credentialed by default, but when preloading `same-origin` mode resources, the current advice is to add a `crossorigin` attribute. (e.g. for fonts & XHR)

However, `crossorigin` does not include an "omit" option, so you're correct that `fetch()` based resources cannot be preloaded currently.

Given that, my previous compat concerns are not valid and this change will also enable preload for default `fetch()` requests, which is now not feasible.

[Joe Medley]

Working on it. No ETA.

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

[Chris Harrelson]

LGTM3

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

[Dominic Farolino]

I've created a Chrome Platform Status entry for this at https://www.chromestatus.com/features/4539473312350208, thanks for the advice!