Intent to Implement: NavigatorContentUtils.IsProtocolHandlerRegistered API

[gyuyou...@lge.com]

Contact emails

gyuyou...@lge.com (or gyuy...@igalia.com)

Summary

The feature is a way to check whether there is the registered custom scheme. Web developers can check whether they have registered the custom scheme they want to register.

Spec

https://www.w3.org/TR/html52/webappapis.html#dom-navigatorcontentutils-isprotocolhandlerregistered. But, the latest WHATWG spec removed the feature - https://html.spec.whatwg.org/multipage/system-state.html#custom-handlers. Because no browsers have supported the feature.

  - The issue to remove on github: https://github.com/whatwg/html/issues/630

  - The commit to remove the feature: https://github.com/whatwg/html/commit/b143dbc2d16f3473fcadee377d838070718549d3

Motivation

Web developers have been able to register or unregister their own custom schemes, but there is no way to verify that the custom schemes are well registered. This feature is motivated by the review thread of *Intent to Implement and Ship: Additional safelisted schemes for "registerProtocolHandler"*. As more schemes will be added, web developers need to have a way to check what schemes are registered.

  - https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/registerProtocolHandler%7Csort:date/blink-dev/29sFh4tTdcs/uAZlMjtdBwAJ

Although the feature was removed from the WHATWG specification, the reason to remove was no browser supported it. If Chromium implements the feature, it may be able to be added to the specification again.

Risks

Interoperability and Compatibility

The feature is less risky as it only adds a new feature that allows web developers to see the registered custom schemes.

- Firefox: In development. But the development has been pending - https://bugzilla.mozilla.org/show_bug.cgi?id=440620​

- Edge: No public signals

- Safari: No public signals

- Web developers: Positive. It would be good if web developers have a way to check what schemes are registered.

Ongoing technical constraints

None

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

Yes

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

The wpt has been only supporting the test for registerProtocolHandler - https://github.com/web-platform-tests/wpt/blob/master/html/webappapis/system-state-and-capabilities/the-navigator-object/protocol.https.html. But, we can add tests of isProtocolHandlerRegistered to the test or make a new test file based on the test. And, there were test cases in third_party/WebKit/LayoutTests/http/tests/navigatorcontentutils/is-protocol-handler-registered.html. But it was removed due to the removal from the spec. The test will be restored additionally.

OWP launch tracking bug

https://crbug.com/883180

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/4722478060404736​

Requesting approval to ship?

No. I'd like to implement this feature behind a flag first. Then, I'd like to ship it when it becomes more stable.

[Anne van Kesteren]

On Thu, Sep 13, 2018 at 9:07 AM gyuyou...@lge.com
<gyuyou...@lge.com> wrote:
> Although the feature was removed from the WHATWG specification, the reason to remove was no browser supported it. If Chromium implements the feature, it may be able to be added to the specification again.

It isn't stated in the linked issues, but the main reason this was
never implemented is the somewhat nontrivial fingerprinting footprint
this would add. I don't think it should be added back without a plan
to counter that and some agreement from at least two implementers that
it's worth doing.

[gyuyou...@lge.com]

 Thank you for your explanation of the reason. But, could you elaborate on the nontrivial fingerprinting footprint issue? 

[K. York]

As specced, the isProtocolHandlerRegistered must return answers even for other domains that are not the one asking. A better version would be to only return true if the registered handler is same-site to the requester.

It would also enable some predatory behavior - e.g. if mailto: is a registered handler, but the server doesn't remember you accepting this particular mail app, add obnoxious "heavy-handed" notices to "switch to [our]" mail app. (This applies equally to all protocols that could be implemented by multiple webapps.)

[K. York]

Something I didn't realize - a valid use of the API is to ask, "if I present a link with this protocol, will it do something?" -- that is, to check for system registered handlers as well. The API as currently specified conflates that use with the usage of "did the prompt I gave the user get accepted?".

This is possible on desktop platforms, but has been blocked on mobile as a fingerprinting vector.

[Asanka Herath]

On Sat, Sep 15, 2018 at 8:37 PM K. York <kane...@gmail.com> wrote:

Something I didn't realize - a valid use of the API is to ask, "if I present a link with this protocol, will it do something?" -- that is, to check for system registered handlers as well. The API as currently specified conflates that use with the usage of "did the prompt I gave the user get accepted?".

This is possible on desktop platforms, but has been blocked on mobile as a fingerprinting vector.

On Saturday, September 15, 2018 at 5:22:39 PM UTC-7, K. York wrote:

As specced, the isProtocolHandlerRegistered must return answers even for other domains that are not the one asking. A better version would be to only return true if the registered handler is same-site to the requester.

It would also enable some predatory behavior - e.g. if mailto: is a registered handler, but the server doesn't remember you accepting this particular mail app, add obnoxious "heavy-handed" notices to "switch to [our]" mail app. (This applies equally to all protocols that could be implemented by multiple webapps.)

To clarify:

Prior to its deletion the spec required both a scheme and a URL and required the same preprocessing for the URL as for registerProtocolHandler. The preprocessing steps include the step "If the resulting URL record’s origin is not the same origin as the origin specified by the entry settings object, throw a "SecurityError" DOMException." which addresses the question of scope. I.e. isProtocolHandlerRegistered cannot be used to query handlers that other origins have registered. It also necessarily rules out platform handlers from scope. In addition, the resulting proto-url must be matched against those that have already been registered for the scheme. I.e the question is limited to a specific handler for a specific scheme where the handler is same-origin as the caller.

The spec as it stood made it distinguishable whether or not a registration attempt has been made for a <origin, scheme, handler> for the caller's origin. That distinction may also be used to store and retrieve one bit of information per origin per handler in a manner that could sidestep cookie restrictions.

I don't think the addition of this API is a good tradeoff.

On Saturday, September 15, 2018 at 4:59:14 AM UTC-7, gyuyou...@lge.com wrote:

On Thursday, September 13, 2018 at 4:13:11 PM UTC+9, Anne van Kesteren wrote:

On Thu, Sep 13, 2018 at 9:07 AM gyuyou...@lge.com
<gyuyou...@lge.com> wrote:
> Although the feature was removed from the WHATWG specification, the reason to remove was no browser supported it. If Chromium implements the feature, it may be able to be added to the specification again.

It isn't stated in the linked issues, but the main reason this was
never implemented is the somewhat nontrivial fingerprinting footprint
this would add. I don't think it should be added back without a plan
to counter that and some agreement from at least two implementers that
it's worth doing.

 Thank you for your explanation of the reason. But, could you elaborate on the nontrivial fingerprinting footprint issue? 

--
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/d0a17fb1-7f98-48ef-8928-506f00908a35%40chromium.org.

[gyuyou...@lge.com]

On Tuesday, September 18, 2018 at 2:37:35 AM UTC+9, Asanka Herath wrote:

On Sat, Sep 15, 2018 at 8:37 PM K. York <kane...@gmail.com> wrote:

Something I didn't realize - a valid use of the API is to ask, "if I present a link with this protocol, will it do something?" -- that is, to check for system registered handlers as well. The API as currently specified conflates that use with the usage of "did the prompt I gave the user get accepted?".

This is possible on desktop platforms, but has been blocked on mobile as a fingerprinting vector.

On Saturday, September 15, 2018 at 5:22:39 PM UTC-7, K. York wrote:

As specced, the isProtocolHandlerRegistered must return answers even for other domains that are not the one asking. A better version would be to only return true if the registered handler is same-site to the requester.

It would also enable some predatory behavior - e.g. if mailto: is a registered handler, but the server doesn't remember you accepting this particular mail app, add obnoxious "heavy-handed" notices to "switch to [our]" mail app. (This applies equally to all protocols that could be implemented by multiple webapps.)

To clarify:

Prior to its deletion the spec required both a scheme and a URL and required the same preprocessing for the URL as for registerProtocolHandler. The preprocessing steps include the step "If the resulting URL record’s origin is not the same origin as the origin specified by the entry settings object, throw a "SecurityError" DOMException." which addresses the question of scope. I.e. isProtocolHandlerRegistered cannot be used to query handlers that other origins have registered. It also necessarily rules out platform handlers from scope. In addition, the resulting proto-url must be matched against those that have already been registered for the scheme. I.e the question is limited to a specific handler for a specific scheme where the handler is same-origin as the caller.

First, the same origin can be checked by the blink's implementation. It can generate the security error if the requested url doesn't have the same origin - https://cs.chromium.org/chromium/src/third_party/blink/renderer/modules/navigatorcontentutils/navigator_content_utils.cc?q=navigator_content_utils.cc&sq=package:chromium&dr&l=79 

The registered schemes and URLs have been managed by the chrome module(i.e. ProtocolHandler, ProtocolHandlerRegistry, and so on). So I think we should ask the chrome module about it. So I made a simple prototype to implement the feature using |ProtocolHandlerRegistry::IsRegistered| in //chrome/browser/ui/browser.cc as below,

 Browser::IsProtocolHandlerRegistered(
    content::WebContents* web_contents,
    const std::string& protocol,
    const GURL& url,
    bool user_gesture) {
...

  content::BrowserContext* context = web_contents->GetBrowserContext();
  if (context->IsOffTheRecord())
    return blink::kWebCustomHandlersDeclined;

  ProtocolHandler handler =
      ProtocolHandler::CreateProtocolHandler(protocol, url);

  ProtocolHandlerRegistry* registry =
      ProtocolHandlerRegistryFactory::GetForBrowserContext(context);
  bool registered = registry->IsRegistered(handler);

Additionally, it seems to me that we can check if the resulting proto-url has the same origin in the chrome module here once again because the chrome module has facilities to check it. For example, there is a ProtocolHandler::IsSameOrigin function.

- https://cs.chromium.org/chromium/src/chrome/common/custom_handlers/protocol_handler.h?q=ProtocolHandler&sq=package:chromium&dr=CSs&l=38

In my humble opinion, it's possible to check if the requested URL has the same origin.

The spec as it stood made it distinguishable whether or not a registration attempt has been made for a <origin, scheme, handler> for the caller's origin. That distinction may also be used to store and retrieve one bit of information per origin per handler in a manner that could sidestep cookie restrictions.

 

I was planning to support this feature through the existing facilities of the chrome module because the registered schemes and URLs have been managed by the facilities. Besides, I guess that there won't be critical issues because registerProtocolHandler, unregisterProtocolHandler have been worked by the facilities of the chrome module. Please let me know if I'm still missing other issues.

[PhistucK]

While not exactly the same flow, encrypted media extensions recently dropped (by default) a permission prompt for playing encrypted media because clearing cookies and site data now clears the encrypted media licenses.

The fingerprinting bit of protocol handlers can be alleviated by also clearing the protocol handler when you clear the cookies and site data.

☆PhistucK

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/fae4d058-f6bd-4202-a90d-bb98f120d707%40chromium.org.