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.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, theisProtocolHandlerRegistered
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, addobnoxious"heavy-handed" notices to "switch to [our]" mail app. (This applies equally to all protocols that could be implemented by multiple webapps.)
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.
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, theisProtocolHandlerRegistered
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, addobnoxious"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.
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.