Intent to Ship: Launch ".well-known/change-password" URL support

[Ali Sarraf]

Contact emails

vas...@chromium.org

jdoe...@chromium.org

bat...@chromium.org

sar...@chromium.org

Spec

Apple developed the spec: https://wicg.github.io/change-password-url

Summary

Websites can set a well-known change-password URL using the format, '/.well-known/change-password', to allow users to quickly navigate to a page allowing them to change their password. Chrome will leverage this URL to help users easily change their weak / compromised passwords following a bulk password check (Desktop, Android, iOS). We want to ship this to 100% in M86.

We’ve published an article announcing that we’ll support '/.well-known/change-password' URL formats: https://web.dev/change-password-url

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

Yes.

Debuggability

N/A given that this launch isn’t something that developers will need to debug.

Risks

Interoperability and Compatibility

Firefox: Public support (https://bugzilla.mozilla.org/show_bug.cgi?id=1644338)

Safari: Apple developed the spec (https://wicg.github.io/change-password-url)

Ergonomics

N/A considering that we’re not making changes to Blink.

Activation

N/A considering that we’re not making changes to Blink.

Security

N/A considering that we’re not making changes to Blink.

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

N/A considering that we’re not making changes to Blink.

Entry on the feature dashboard

https://chromestatus.com/features/6256768407568384

Tracking bug

https://crbug.com/1115041

[Chris Harrelson]

On Fri, Sep 11, 2020 at 11:10 AM Ali Sarraf <sar...@chromium.org> wrote:

Contact emails

vas...@chromium.org

jdoe...@chromium.org

bat...@chromium.org

sar...@chromium.org

Spec

Apple developed the spec: https://wicg.github.io/change-password-url

Summary

Websites can set a well-known change-password URL using the format, '/.well-known/change-password', to allow users to quickly navigate to a page allowing them to change their password. Chrome will leverage this URL to help users easily change their weak / compromised passwords following a bulk password check (Desktop, Android, iOS). We want to ship this to 100% in M86.

We’ve published an article announcing that we’ll support '/.well-known/change-password' URL formats: https://web.dev/change-password-url

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

Yes.

Debuggability

N/A given that this launch isn’t something that developers will need to debug.

Risks

Interoperability and Compatibility

Firefox: Public support (https://bugzilla.mozilla.org/show_bug.cgi?id=1644338)

This does not count as public support. See this document.

 

Safari: Apple developed the spec (https://wicg.github.io/change-password-url)

Is it shipped in Safari yet?

 

Ergonomics

N/A considering that we’re not making changes to Blink.

The ergonomics are still web-developer-exposed, regardless of where the code changes are in Blink.

e.g. two questions come to mind:

* What should developers expect if they do not implement the server-side feature?

* What if a site has a buggy response to the requests?

* What is the interaction with Service Workers?

 

Activation

N/A considering that we’re not making changes to Blink.

Same answer as above.

You've already said that you plan to advertise this feature on web.dev, which is a good activation strategy.

 

Security

N/A considering that we’re not making changes to Blink.

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

N/A considering that we’re not making changes to Blink.

As above, this is not a good N/A reason. However, I agree that it's unclear what a WPT could possibly test for this feature.

 

Entry on the feature dashboard

https://chromestatus.com/features/6256768407568384

Tracking bug

https://crbug.com/1115041

--
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/CABAjHBoM-O0UB1DS7ApVhr3Bd1%2BcRqR8ZG0oXqYAJahqaST%2B%2BQ%40mail.gmail.com.

[Chris Harrelson]

Three! :)

[Dominic Battre]

Hi Chris,

thanks for helping. This is the first time our team goes through the intent to ship process.

On Fri, Sep 11, 2020 at 8:20 PM Chris Harrelson <chri...@chromium.org> wrote:

On Fri, Sep 11, 2020 at 11:20 AM Chris Harrelson <chri...@chromium.org> wrote:

On Fri, Sep 11, 2020 at 11:10 AM Ali Sarraf <sar...@chromium.org> wrote:

Contact emails

vas...@chromium.org

jdoe...@chromium.org

bat...@chromium.org

sar...@chromium.org

Spec

Apple developed the spec: https://wicg.github.io/change-password-url

Summary

Websites can set a well-known change-password URL using the format, '/.well-known/change-password', to allow users to quickly navigate to a page allowing them to change their password. Chrome will leverage this URL to help users easily change their weak / compromised passwords following a bulk password check (Desktop, Android, iOS). We want to ship this to 100% in M86.

We’ve published an article announcing that we’ll support '/.well-known/change-password' URL formats: https://web.dev/change-password-url

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

Yes.

Debuggability

N/A given that this launch isn’t something that developers will need to debug.

Risks

Interoperability and Compatibility

Firefox: Public support (https://bugzilla.mozilla.org/show_bug.cgi?id=1644338)

This does not count as public support. See this document.

https://mozilla.github.io/standards-positions/#change-password-url --> "worth prototyping"

 

 

Safari: Apple developed the spec (https://wicg.github.io/change-password-url)

Is it shipped in Safari yet?

It launched in Safari 13 (https://developer.apple.com/documentation/safari-release-notes/safari-13-release-notes).

Ergonomics

N/A considering that we’re not making changes to Blink.

The ergonomics are still web-developer-exposed, regardless of where the code changes are in Blink.

e.g. two questions come to mind:

* What should developers expect if they do not implement the server-side feature?

If a website does not support this feature, an attempt to navigate to https://www.example.com/.well-known/change-password redirects the user to the homepage (https://www.example.com/).

 

* What if a site has a buggy response to the requests?

The spec suggests a clever trick:

It is possible that https://www.example.com/.well-known/change-password returns a 200 status even though the server does not support .well-known/change-password and should return 404.

To check for this, we validate that https://www.example.com/.well-known/resource-that-should-not-exist-whose-status-code-should-not-be-200 does NOT return a 200 status (actually, we are more conservative and check that it returns a 404).

Only if the first request returns a 2xx status (after following redirects) and the latter request returns a 404, we actually navigate the user to the final redirect of .well-known/change-password. In all other cases, we send the user to the homepage.

 

* What is the interaction with Service Workers?

Three! :)

Frankly, I don't know. Does it help saying that we introduce a NavigationThrottle here and that the request for .well-known/resource-that-should-not-exist-whose-status-code-should-not-be-200 is created here as a SimpleURLLoader, which uses the SharedURLLoaderFactory of the default storage partition of the webcontents (see here).

Best regards,

Dominic

 

 

 

Activation

N/A considering that we’re not making changes to Blink.

Same answer as above.

You've already said that you plan to advertise this feature on web.dev, which is a good activation strategy.

 

Security

N/A considering that we’re not making changes to Blink.

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

N/A considering that we’re not making changes to Blink.

As above, this is not a good N/A reason. However, I agree that it's unclear what a WPT could possibly test for this feature.

 

Entry on the feature dashboard

https://chromestatus.com/features/6256768407568384

Tracking bug

https://crbug.com/1115041

--
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/CABAjHBoM-O0UB1DS7ApVhr3Bd1%2BcRqR8ZG0oXqYAJahqaST%2B%2BQ%40mail.gmail.com.

-- 

Google Germany GmbH - Erika-Mann-Str. 33 - 80636 München - Germany

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

[Chris Harrelson]

On Fri, Sep 11, 2020 at 1:30 PM Dominic Battre <bat...@chromium.org> wrote:

Hi Chris,

thanks for helping. This is the first time our team goes through the intent to ship process.

No problem at all! Apologies if anything came across as too pithy, we're here to help. :)

 

On Fri, Sep 11, 2020 at 8:20 PM Chris Harrelson <chri...@chromium.org> wrote:

On Fri, Sep 11, 2020 at 11:20 AM Chris Harrelson <chri...@chromium.org> wrote:

On Fri, Sep 11, 2020 at 11:10 AM Ali Sarraf <sar...@chromium.org> wrote:

Contact emails

vas...@chromium.org

jdoe...@chromium.org

bat...@chromium.org

sar...@chromium.org

Spec

Apple developed the spec: https://wicg.github.io/change-password-url

Summary

Websites can set a well-known change-password URL using the format, '/.well-known/change-password', to allow users to quickly navigate to a page allowing them to change their password. Chrome will leverage this URL to help users easily change their weak / compromised passwords following a bulk password check (Desktop, Android, iOS). We want to ship this to 100% in M86.

We’ve published an article announcing that we’ll support '/.well-known/change-password' URL formats: https://web.dev/change-password-url

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

Yes.

Debuggability

N/A given that this launch isn’t something that developers will need to debug.

Risks

Interoperability and Compatibility

Firefox: Public support (https://bugzilla.mozilla.org/show_bug.cgi?id=1644338)

This does not count as public support. See this document.

https://mozilla.github.io/standards-positions/#change-password-url --> "worth prototyping"

Excellent!

 

 

 

Safari: Apple developed the spec (https://wicg.github.io/change-password-url)

Is it shipped in Safari yet?

It launched in Safari 13 (https://developer.apple.com/documentation/safari-release-notes/safari-13-release-notes).

Ergonomics

N/A considering that we’re not making changes to Blink.

The ergonomics are still web-developer-exposed, regardless of where the code changes are in Blink.

e.g. two questions come to mind:

* What should developers expect if they do not implement the server-side feature?

If a website does not support this feature, an attempt to navigate to https://www.example.com/.well-known/change-password redirects the user to the homepage (https://www.example.com/).

 

* What if a site has a buggy response to the requests?

The spec suggests a clever trick:

It is possible that https://www.example.com/.well-known/change-password returns a 200 status even though the server does not support .well-known/change-password and should return 404.

To check for this, we validate that https://www.example.com/.well-known/resource-that-should-not-exist-whose-status-code-should-not-be-200 does NOT return a 200 status (actually, we are more conservative and check that it returns a 404).

Only if the first request returns a 2xx status (after following redirects) and the latter request returns a 404, we actually navigate the user to the final redirect of .well-known/change-password. In all other cases, we send the user to the homepage.

 

* What is the interaction with Service Workers?

Three! :)

Frankly, I don't know. Does it help saying that we introduce a NavigationThrottle here and that the request for .well-known/resource-that-should-not-exist-whose-status-code-should-not-be-200 is created here as a SimpleURLLoader, which uses the SharedURLLoaderFactory of the default storage partition of the webcontents (see here).

I'm not sure either if intercepting this URL on a Service Worker is good or bad. +Matt Falkenhagen any thoughts?

 

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

[Matt Menke]

Not touching blink doesn't mean there are not security considerations - e.g., you could modify the omnibox to always display the URL of someone's bank, and that would most definitely be a security problem, but would not touch blink/.

More related to this intent, though, sending SameSite=Strict cookies for cross-site change password URLs would be a security issue. I assume we don't cache the redirect destination, but instead navigate directly to the well-known URL, which then might redirect a user across sites, correctly not sending SameSite=strict cookies?

[Dominic Battre]

Hi Matt,

On Fri, Sep 11, 2020 at 11:22 PM Matt Menke <mme...@chromium.org> wrote:

Not touching blink doesn't mean there are not security considerations - e.g., you could modify the omnibox to always display the URL of someone's bank, and that would most definitely be a security problem, but would not touch blink/.

More related to this intent, though, sending SameSite=Strict cookies for cross-site change password URLs would be a security issue. I assume we don't cache the redirect destination, but instead navigate directly to the well-known URL, which then might redirect a user across sites, correctly not sending SameSite=strict cookies?

Here is what happens...

I see three fundamental approaches to navigating to a change-password URL:

1) User types https://www.example.com/.well-known/change-password into the omnibar

2) The user is on a website (either example.com or evil.com) and navigates via a link to https://www.example.com/.well-known/change-password

3) The user clicks on a button in native UI that opens a custom chrome tab which navigates to https://www.example.com/.well-known/change-password

In all of these cases, the browser takes care of selecting the right cookies.

If we observe a navigation to $domain/.well-known/change-password, we instantiate a NavigationThrottle which

1) Fires a cookieless network request to $domain/.well-known/resource-that-should-not-exist-whose-status-code-should-not-be-200 and waits for the response.

2) Initially, only defers the original navigation until the request from 1 returns (but does not interfere with cookies during redirects, nor does it interfere with the redirects).

3.a) If the original navigation ended in a 2xx code and the request from 1 returns a 404, we just resume the navigation (we did not touch any cookies or redirects, this should feel like a navigation to $domain/.well-known/change-password before this feature was implemented).

3.b) If the original navigation ended in something but a 2xx code or the request from 1 returns not 404, we cancel the navigation and call web_contents_->OpenURL() with the target url.GetOrigin(), where url is the result of the last redirect of the initial navigation. We use these OpenURLParams. This should feel like a new mainframe navigation (with params.transition = ui::PAGE_TRANSITION_CLIENT_REDIRECT) with new cookies.

Is there a hidden security issue?

+Vasilii Sukhanov: I think that this exercise made it clear to me that there may be one bug in the implementation: The NavigationThrottle should probably only observe mainframe navigations. Otherwise, the web_contents_->OpenURL may be surprising (an iframe navigation could trigger a mainframe navigation).

Thanks for your help!

Best regards,

Dominic

[Matt Menke]

[+clamy, +titouan]:  The request for $domain/.well-known/resource-that-should-not-exist-whose-status-code-should-not-be-200 uses the NetworkIsolationKey of $domain, I assume?  What about redirects from remote to local servers?  They (will soon) require CORS, but does this request enable CORS?  This could let you sniff for a (single) local HTTP server, bypassing those new CORS requests.  I have no idea if that's a concern.  Could perhaps sniff for more by making the fallback request in step 3.b) redirect back to the change password URL.  I assume the redirect limit enforced by NavigationURLLoader applies here?

Thanks for the details!

[Dominic Battre]

At the moment, we don't set a NetworkIsolationKey, but only resource_request->credentials_mode = network::mojom::CredentialsMode::kOmit; (src). Is that sufficient?

Best regards,

Dominic

On Mon, Sep 14, 2020 at 9:33 AM Titouan Rigoudy <tit...@chromium.org> wrote:

I'll defer to Camille regarding navigation details. I will say that right now all requests should by default be subject to CORS-RFC1918 checks - there is no option to turn those off, AFAIK. Thus the cookieless request should be blocked if insecure.

Cheers,

Titouan

[Matt Menke]

Thanks for the link!

It looks like we're using the URLLoaderFactory returned by GetURLLoaderFactoryForBrowserProcess(), which in general shouldn't be used for web-initiated requests, at least without some care.  It means we're bypassing ServiceWorker, we're bypassing the initiator lock checks (and we should presumably be setting initiator here), and we're bypassing extension's ability to take over a request (so the result might actually be different from the probe).

It also means we're using the default non-webby NetworkIsolationKey logic, which just uses the origin of the requested resource.  The NetworkIsolationKey (NIK) consists of (main frame site, innermost frame site), and will be used as a key to most separate network resources, including the cache, to be used to track a user across sites.  Subresources requests use the same NIK across redirects, while frame requests update one or both sites for each redirect.

So, back to the case of the probe requests we're adding here.  The non-webbyNetworkIsolationKey logic just uses the site of the URL being requested as both the top-level site and innermost iframe site, and doesn't update it for resources.  This is certainly wrong for subframes, and will let sites exfiltrate data across NetworkIsolationKeys by navigating a subframe to this URL (Looks like we create the throttle for subframe navigations as well as main frame ones, at least).

For main frames...the situation is less clear.  For the actual navigation, we want to update NIKs across redirects, so setting the NIK to be updated across redirects would match the navigation, if we actually end up navigating.  However, main frame navigations can leak data across domains, and we're (hoping) we can eventually figure out and mitigate cross-NIK link decoration.  That logic would need to be applied here as well.  It seems safer to me to treat these requests as subresources of the main resource, though that does mean we can't use the right ServiceWorker in the case of cross-frame redirects (Though, as noted either, we're bypassing all ServiceWorkers already, which is perhaps desired to avoid confusing them, anyways).  While treating these as subresources is, fortunately, what the default NIK used for browser-initiated requests does, we should probably be setting NIK directly, since these aren't browser-initiated requests (or at least are third party / potentially attacker controlled).

This should probably be looked at by a CORS expert to figure out if there's anything else we need to set on these requests to make them safely.

[Titouan Rigoudy]

I'll defer to Camille regarding navigation details. I will say that right now all requests should by default be subject to CORS-RFC1918 checks - there is no option to turn those off, AFAIK. Thus the cookieless request should be blocked if insecure.

Cheers,

Titouan

On Sat, Sep 12, 2020 at 12:50 AM Matt Menke <mme...@chromium.org> wrote:

[Joe Medley]

If this didn't ship in 86, then did something happen in 86? Developer or origin trial?

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

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

--

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/CAEK7mvrNEMQm-%3DSDY6FL_PTx%3Dzf0uzDDYKmA6f6kewb46RN6Og%40mail.gmail.com.

[Matt Menke]

NavigationURLLoader already has both an initiator and an IsolationInfo (which includes NIK) in its NavigationRequestInfo request_info_ field.  I think the simplest thing to do is to just copy those, but change the IsolationInfo's RedirectMode to kUpdateNothing (Which will require creating a new one with arguments pulled from the original).

On Mon, Sep 14, 2020 at 12:48 PM Vasilii Sukhanov <vas...@chromium.org> wrote:

The action items I noted so far:

1. Disable the feature for iFrames.
2. Set NIK (an example is very welcomed).
3. Set initiator (an example is very welcomed).

Anything else?

We didn't have trials. The feature is just in 50% Beta now.

Vasilii Sukhanov

Software Engineer

vas...@google.com

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.

    

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

[Vasilii Sukhanov]

The action items I noted so far:

1. Disable the feature for iFrames.
2. Set NIK (an example is very welcomed).
3. Set initiator (an example is very welcomed).

Anything else?

We didn't have trials. The feature is just in 50% Beta now.

On Mon, Sep 14, 2020 at 6:23 PM Joe Medley <jme...@google.com> wrote:

Vasilii Sukhanov

Software Engineer

vas...@google.com

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

[Vasilii Sukhanov]

Do we get this data from NavigationHandle? Are those supported by network::ResourceRequest?

[Matt Menke]

IsolationInfo is in ResourceRequest::trusted_params.  request_initiator is in ResourceRequest itself, though may eventually move into TrustedParams as well.

I'm not too familiar with NavigationHandle or NavigationThrottles, so I'm not sure if they're currently available from those.  They're certainly available to URLLoaderThrottles (since those have access to the ResourceRequest).

[Łukasz Anforowicz]

This seems similar to the security bug in PaymentRequests (https://crbug.com/966507) where the initiator origin was not propagated (allowing an attacker to avoid having `Sec-Fetch-Site: cross-site` HTTP request header attached to the outgoing request).  

On Monday, September 14, 2020 at 10:43:18 AM UTC-7, Vasilii Sukhanov wrote:

The action items I noted so far:

1. Disable the feature for iFrames.
2. Set NIK (an example is very welcomed).
3. Set initiator (an example is very welcomed).

Anything else?

I think it would be best if you 1) used the factory obtained via RenderFrameHost::CreateNetworkServiceDefaultFactory (this should have the right NIK, request_initiator_origin_lock, etc. - all based on the frame's origin) and 2) propagated |network::ResourceRequest::request_initiator|.

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/CAEK7mvrNEMQm-%3DSDY6FL_PTx%3Dzf0uzDDYKmA6f6kewb46RN6Og%40mail.gmail.com.

[Łukasz Anforowicz]

On Monday, September 14, 2020 at 11:26:50 AM UTC-7, Matt Menke wrote:

IsolationInfo is in ResourceRequest::trusted_params.  request_initiator is in ResourceRequest itself, though may eventually move into TrustedParams as well.

Matt, if  RenderFrameHost::CreateNetworkServiceDefaultFactory is used, then is it still necessary to populate network::ResourceRequest::trusted_params?  Or is it sufficient to just populate network::ResourceRequest::request_initiator?

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

[Matt Menke]

I don't think CreateNetworkServiceDefaultFactory() will work currently -  we don't update the IsolationInfo for each redirect, we only update it at navigation start and commit.  I think if we changed that, and update it before we call into the NavigationThrottle stack, it would work.  This might be generally a good thing to do, though I haven't thought about it much.  I do think this would be much more future proof than having (potentially) a bunch of consumers setting parameters themselves. CreateNetworkServiceDefaultFactory() also needs a process and frame ID, which we don't have prior to commit, so this might take a fair bit of work to get working.

Unfortunately, I'm not sure if request_initiator is sufficient - a lot of the more CORS-y stuff I'm just not familiar with.

There's also the question of whether we want to show proxy auth/cert request dialogs, which requires a way for the NetworkService to tell the browser process what tab this is associated with.  For renderer-initiated requests, this is done with process/frame IDs, for navigation requests, some other id is used for frame ID, and a process ID of 0.  But these requests don't have a life renderer, and aren't navigations, so that will likely break. Server auth doesn't matter, since we're omitting credentials (Potentially break password change URLs in that case), but if the proxy also requires auth, I assume it would be reasonable to ask for credentials for it.

Anyhow, I'm a big fan of making there be one right way to do things that just works, so investing in beefing up CreateNetworkServiceDefaultFactory() might be the way to go.

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

--
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/UN1BRg4qTbs/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/b1eb6aab-ab46-49ea-9c90-309ca1f50883o%40chromium.org.

[Mike West]

Hey folks! A few things occur to me reading this thread:

1.  It feels like the detail discussion of the outgoing requests' properties are important to get right, but would likely be best moved to a more narrow bug filed against the spec (in terms of Fetch's understanding of requests' client, URL, etc), or a Chromium-specific design doc (in terms of NIK, initiator, etc), to make sure that the right set of folks are engaged. blink-dev@ probably isn't the most targeted forum to work in.

2.  The behavior you're proposing for the Chrome-UI-generated navigation (battre@'s #3 above) seems quite reasonable to me, and helpful for users. I think it also matches my understanding of what's in the specs referenced above and what Safari has shipped.

3.  The behavior for #1 and #2 seems to go beyond what Safari has shipped. Navigating to `https://mikewest.org/.well-known/change-password` shows an exceptionally interesting 404 page in Safari, which matches my expectations for user experience on that particular site. It might well be the case that we can improve the experience based on user agent heuristics (perhaps Chrome could know that a given site had a change-password form at a given location, and perform redirects on users' behalf with that additional information), but it seems like it would be helpful to engage other vendors in that discussion to make sure we have predictable behavior for developers and users both.

Would y'all consider shipping behavior today that matches Safari (which I think only entails putting #1 and #2 behind a flag), and chatting with Mozilla and Apple folks about pushing beyond that in a future release? That approach sounds pretty reasonable to me.

-mike

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

[Vasilii Sukhanov]

1. We addressed all the implementation security concerns in CL1, CL2. 
2. The discussion with the Safari folks has started. No reply from them yet.
3. We are OK to implement Mike's proposal too.

[Mike West]

LGTM1 to ship behavior matching Safari 13.

I'd note, though, that this intent did not include a TAG review, which generally speaking shouldn't happen. We value their feedback, and would appreciate them being involved in the discussion around features like this. In this particular case, it seems reasonable to ship the feature without their input only because:

1.  The relevant specifications have been adopted by a relevant standards body without objection (in this case WebAppSec).

2.  We don't anticipate substantial change to the feature in that WG.

3.  Safari has already shipped, and Mozilla considers it "worth prototyping" without suggestion for change.

4.  We see semi-substantial adoption in the wild (from sites like Facebook, Google, GitHub, Twitter, and WordPress on board).

This feels to me like a de facto standard, and in this particular case TAG review is unlikely to change the URL's meaning in the wild. So, let's ship support for it as well.

-mike

[Chris Harrelson]

LGTM2

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