Preflight/Proposal: Upstreaming Microsoft Edge's change to ExternalProtocolHandler Prompting

[eri...@microsoft.com]

The Chrome Enamel team suggested this would be a good forum to get feedback on an Edge change Microsoft would like to propose for Chromium.

Starting in Chromium v77, the prompt when invoking an application protocol (aka ExternalProtocolHandler) from the browser:

    

...was changed to hide the "Always open links of this type in the associated app" checkbox. 

Following significant outcry from individuals and enterprises, a Group Policy was introduced in Chromium 79 to permit the checkbox to be shown again. However, most end-users will not benefit from this work, as it's only a policy (not exposed to humans through the browser UI) and after enabling the policy, the security risk is reintroduced.

Much of the risk inherent in open-without-prompting behavior comes from the site that any random site (http://evil.example.com) can abuse (previously-granted) ambient permission to launch the protocol handler. If browsers change the option to “Always allow this site to open this protocol”, the risk will be significantly reduced such that a user could allow, e.g. https://teams.microsoft.com to open the msteams protocol without further prompts.

To that end, the Edge team has landed a change in Edge 82.0.425 that replaces the old flat list of exempted schemes with a new list of Origin/Scheme pairs. Our believe is that this change strikes a better balance between risk and user-annoyance, and it will allow us to restore an origin-scoped checkbox to the UI, unchecked by default:

    

We're currently hiding this option behind a feature flag: edge://flags/#edge-exclude-schemes-per-origin, but in a future release, we expect to turn this flag on by default.

A few notes about our implementation:

• Exemptions are stored on a per-scheme, per-origin basis (e.g. “Allow teams: from https://teams.microsoft.com“, so if multiple origins use the same scheme, users must exempt each one.
• Stored exemptions are origin specific: “https://site.example” and “https://www.site.example” and “http://site.example” are all different origins.
• Stored exemptions are only available for HTTP and HTTPS origins.
  
• Exemptions granted while Incognito are forgotten at session's end.
• At present, there is no Group Policy for an admin to push exemptions to the client (https://crbug.com/911605 proposes one)
  
• To clear stored exemptions, users may continue to use the “Cookies and other site data” checkbox in the Clear Browsing Data dialog box. Note that you can set the time range to anything you like– all Origin+Scheme exemptions will be cleared. 
• Mike has expressed interest in exposing a more direct control for viewing/clearing decisions within the Settings WebUI pages.
• The older (non-origin-scoped) excluded_schemes list will not be immediately removed from the code. Instead, it will continue to be respected, but upon use, the origin/scheme will be recorded in the new excluded_scheme_origin_pairs list. In some future milestone (N+1 or 2?) we will remove support for the non-origin-scoped list.
  

We think that Chrome will benefit from this change as well, so we're interested in getting your feedback before we propose the change via Gerrit CL early next week.

Thanks!

-Eric Lawrence
Microsoft Edge

[Daniel Veditz]

This is a great approach, and I hope I can sell it to Firefox devs, too.

Do you really mean to expose permanent potentially-abusable permissions to insecure HTTP pages? There are fewer and fewer insecure sites all the time so I hope you can make insecure contexts work like your proposal for Incognito pages.

-Dan Veditz

[eri...@microsoft.com]

Mozilla's issue is this one, right? https://bugzilla.mozilla.org/show_bug.cgi?id=1565574

Originally, I'd hoped to omit the checkbox for HTTP entirely, but worried that this wouldn't be enough to defuse the complaints. Converting the checkbox while on a HTTP origin to be a "per-session" decision is an interesting middle-ground we hadn't considered, though it might be sorta hard to explain to users?

[David Benjamin]

Including a plain persistent checkbox for http:// is also poor for users, as it requires they realize that http://example.com is pronounced "the network". The notion of session for a non-incognito page is unfortunately also rather fussy, and the user may switch networks without restarting their browser.

Given we've already shipped the UI without the checkbox at all, it seems to me the best option for http URLs is to not offer the checkbox there at all. That aligns with what we're already shipping.

[Mike West]

1. Thank you Eric. This is a good approach that I'm sure the permissions team would be happy to review. +engedy@.

2. I do not want us to expose persistent permissions to non-secure origins. I would be happiest if we would consider external protocol handlers to be a feature that would in itself be limited to secure origins (and Emily, et al. might have plans there already?). Until that's done, maintaining the status quo lack of persistence seems essential.

-mike 

[Emily Stark]

+Joe DeBlasio 

On Tue, Mar 3, 2020 at 1:52 AM Mike West <mk...@chromium.org> wrote:

1. Thank you Eric. This is a good approach that I'm sure the permissions team would be happy to review. +engedy@.

2. I do not want us to expose persistent permissions to non-secure origins. I would be happiest if we would consider external protocol handlers to be a feature that would in itself be limited to secure origins (and Emily, et al. might have plans there already?). Until that's done, maintaining the status quo lack of persistence seems essential.

Indeed, we're interested in removing the ability of nonsecure pages to navigate to external protocols, though I don't believe we yet have metrics on whether that's feasible or not, and it would likely have to have an enterprise policy escape hatch.

[Joe DeBlasio]

I'm excited for Edge to upstream this!

Since it's our dream to remove the HTTP's ability to navigate to external protocols entirely, offering a new persistence to HTTP feels especially like moving in the wrong direction.

Do you have any usage data that you can share re: HTTP vs HTTPS? I'll be adding some metrics sometime this month, and our plan was to go from there.

[eri...@microsoft.com]

Hey, Joe-- We do not, at present, have telemetry around secure/non-secure invocations of protocol handlers; adding that telemetry sounds great.

I'll talk to our dev about exempting http from the persistence option. While this obviously is tactically safer, it does run the risk of pushing protocol implementers into more dangerous architectures (e.g. loopback web servers) if we don't also ship restrictions that will block access to those servers from non-secure contexts at the same time.

[David Benjamin]

I'm not sure what the status is, but that sounds like https://groups.google.com/a/chromium.org/d/msg/blink-dev/EeGg7TxW6U4/9aohper3BQAJ.

That said, if the lack of persistence was already shipped in M77, it seems any incentives there would be to use loopback have already been established.