View source for Identifying Returning Users

==Full Title or Meme==
Exploring the ways that a web site (aka [[Relying Party]]) can determine if the current user of the site is known to that site from previous visits.

==Context==
* [[Single Sign-On]] to multiple websites is a great improvement in any [[User Experience]] it was enabled by the use of [[Third Party]] [[Cookies]].
* With the demise of [[Third Party]] Cookies, new methods for identifying returning users is more complex for a [[Relying Party]].
* In addition, the advent of [[WebAuthn 3]] gives the user a variety of other hardware tokens for authentication to a [[Relying Party]], including the use of the [[Trusted Execution Environment]] present on nearly all computing devices in 2022.
* [[Native SSO]] allows sharing of [[Single Sign-On]] among native apps from the same vendor.

==Problems==
* There is little control on protocol handlers that are added to the operating system. That means that a protocol handler that is relied upon for any purpose can be replaced by a new one. While user permission is required to load a protocol handler, the impact of that handler on a user's experience or security is not obvious.
* Each browser has their own self-imposed [[Browser Origin Policy]] that limits access to cookies and origin file systems that frequently change, making the user experience for [[Authentication]] change in unpredictable ways. It is likely that if a user has a game console, a laptop and a [[Smartphone]] the experience on each will vary over time and among each.
* Use of multiple wallets to hold user [[Authentication]] secrets, as described on the wiki page [[Self-issued OpenID Picker]], can make it difficult for the [[Relying Party]] to tell the [[User Agent]] what types of [[Identifier]] are acceptable to it.

==Solutions==

The Protocol Handler as a means to accept [[Authentication]] queries from [[Relying Party]] -- statuses from blink-dev

===Permission automation for registerProtocolHandler===

Javier Fernandez <jfernandez@igalia.com>
Fri, May 13, 3:12 AM
to blink-dev@chromium.org

Explainer
https://github.com/Igalia/explainers/blob/main/custom-protocol-handlers/Permission-API/README.md

Specification
https://html.spec.whatwg.org/multipage/system-state.html#custom-handlers

Summary
Provides Automated testing support for the registerProtocolHandler method, so that we could avoid the user prompt dialog to grant permission for the protocol handler registration.
We would need to define a new 'PermissionName' that we can use as part of the 'PermissionDescriptor' argument for the SetPermission command provided by the WebDriver API.

Blink component
Blink>HTML>CustomHandlers

Motivation
Currently there are only manual tests in the WPT repository to cover the registerProtocolHandler functionality. The main challenges to implement automated testing are:
* UserActivation: The registerProtocolHandler method requires transient activation to consider the request; otherwise it'll be ignored.
* Permission prompt dialog: Although the spec is quite vague on this regard, current implementations (Firefox and Chrome) requires the user to grant permissions for the handler registration.

Using the test_driver.set_permission function we could make tests like this:
 promise_setup(async () => {
  await test_driver.set_permission({name: 'protocol-handler'}, 'granted');
  await test_driver.bless('handler registration'); // Provides UserActivation
  register();
 });


Initial public proposal
https://github.com/whatwg/html/issues/7920


Risks
*Interoperability and Compatibility
**Gecko: No signal
**WebKit: No signal
**Web developers: No signals


Flag name - none!!

Requires code in //chrome?
True

Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1321073

Estimated milestones
No milestones specified


Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5047679389270016

---

Rick Byers <rbyers@chromium.org>
Fri, May 13, 7:21 AM
to Javier, blink-dev@chromium.org

Cool! Thank you for making more of the platform testable in WPT!

Has there been any discussion in the HTML spec community of making registerProtocolHandler an official "powerful feature"? Will doing so also have web visible implications via permissions policy?

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


Javier Fernandez <jfernandez@igalia.com>
Fri, May 13, 8:17 AM
to Rick, blink-dev@chromium.org


Has there been any discussion in the HTML spec community of making registerProtocolHandler an official "powerful feature"? Will doing so also have web visible implications via permissions policy?


I've just started the discussion, both at the level of WPT [1] and in the html spec [2], but still not much feedback.

Honestly, I've started this journey just trying to improve the feature's testing, but the issue has growth so that we have now the opportunity to evolve the registerProtocolHandler feature itself. In any case, I think the goal is worth the effort, so that's why I've sent the intent. 

IMHO, with the "powerfull feature" definition in mind "is a web platform feature (usually an API) for which a user gives express permission before the feature can be used"  the registerProtocolHandler should be considered as such. I'd really like to get feedback from people with more experience, but I really think user must grant permissions in all the cases before registering any protocol handler. Currently, the spec is a bit vague [3] on this regard, so I think we can improve a bit:

"User agents may, within the constraints described, do whatever they like. A user agent could, for instance, prompt the user and offer the user the opportunity to add the site to a shortlist of handlers, or make the handlers their default, or cancel the request. User agents could also silently collect the information, providing it only when relevant to the user."

I have to say that, for the time being, the intent is only for the Automated testing capabilities. It's not in my plans to implement the "request permission" [4] functionality. Currently in chrome we do have a PROTOCOL_HANDLER setting but we don't store any data; the requestProtocolHandler method just launch a prompt dialog to ask the user for permissions to proceed or not with the registration. I don't have plans to change that, for now.

Regarding permissions policy, I admit I haven't considered it and I don't have experience with that spec, but now that you mention I guess it'd made sense to implement a permission policy for the Custom Handlers feature.

--
javi

[1] https://github.com/web-platform-tests/wpt/issues/26819
[2] https://github.com/whatwg/html/issues/7920
[3] https://html.spec.whatwg.org/multipage/system-state.html#custom-handlers
[4] https://www.w3.org/TR/permissions/#requesting-more-permission
--
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/0e556a0f-1bce-d4c2-0d11-e88a87c19040%40igalia.com.


Rick Byers <rbyers@chromium.org>
Fri, May 13, 1:02 PM
to Philip, Ian, Javier, blink-dev@chromium.org


On Fri, May 13, 2022 at 11:17 AM Javier Fernandez <jfernandez@igalia.com> wrote:
Hi Rick,

On 13/5/22 16:21, Rick Byers wrote:
Cool! Thank you for making more of the platform testable in WPT!

Has there been any discussion in the HTML spec community of making registerProtocolHandler an official "powerful feature"? Will doing so also have web visible implications via permissions policy?

I've just started the discussion, both at the level of WPT [1] and in the html spec [2], but still not much feedback.

Honestly, I've started this journey just trying to improve the feature's testing, but the issue has growth so that we have now the opportunity to evolve the registerProtocolHandler feature itself. In any case, I think the goal is worth the effort, so that's why I've sent the intent. 

IMHO, with the "powerfull feature" definition in mind "is a web platform feature (usually an API) for which a user gives express permission before the feature can be used"  the registerProtocolHandler should be considered as such. I'd really like to get feedback from people with more experience, but I really think user must grant permissions in all the cases before registering any protocol handler. Currently, the spec is a bit vague [3] on this regard, so I think we can improve a bit:

"User agents may, within the constraints described, do whatever they like. A user agent could, for instance, prompt the user and offer the user the opportunity to add the site to a shortlist of handlers, or make the handlers their default, or cancel the request. User agents could also silently collect the information, providing it only when relevant to the user."

I have to say that, for the time being, the intent is only for the Automated testing capabilities. It's not in my plans to implement the "request permission" [4] functionality. Currently in chrome we do have a PROTOCOL_HANDLER setting but we don't store any data; the requestProtocolHandler method just launch a prompt dialog to ask the user for permissions to proceed or not with the registration. I don't have plans to change that, for now.

Regarding permissions policy, I admit I haven't considered it and I don't have experience with that spec, but now that you mention I guess it'd made sense to implement a permission policy for the Custom Handlers feature.

Thanks, that all makes sense! If it's ultimately just a webdriver change, then I'm not sure if an 'intent to ship' is even necessary. @Philip Jägenstedt would know.

And certainly, I didn't mean to imply that you should integrate with permission policy etc., I was just trying to understand the scope of the web platform exposure. I can see how this may or may not really match what we normally think of as 'permissions'. @Ian Clelland could probably advise. Even if integration with the 'powerful feature' definition is the "right" thing to do, it may not be worth the effort to do it when the most important thing is just getting some automated test coverage...

--
javi

 [1] https://github.com/web-platform-tests/wpt/issues/26819
 [2] https://github.com/whatwg/html/issues/7920
 [3] https://html.spec.whatwg.org/multipage/system-state.html#custom-handlers
 [4] https://www.w3.org/TR/permissions/#requesting-more-permission

===URL Protocol Handler Registration for PWAs===
Explainer
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/URLProtocolHandler/explainer.md

 https://web.dev/url-protocol-handler/
 https://web.dev/pwa-url-handler/

Specification
https://pr-preview.s3.amazonaws.com/w3c/manifest/pull/972.html#protocol_handlers-member

Contact emails
samuel.tang@microsoft.com, mjackson@microsoft.com, luigonza@microsoft.com, dmurph@chromium.org

Design docs
https://docs.google.com/document/d/1NHlWLjAPZ-dyxcz3AoTWibeerDeHW7Vqrx6FmhB0XmE

Summary
Enable web applications to register themselves as handlers of custom URL protocols/schemes using their installation manifest.

Blink component
UI>Browser>WebAppInstalls

TAG review
https://github.com/w3ctag/design-reviews/issues/482

TAG review status
Issues addressed, resolution: satisfied.

Risks
* Interoperability and Compatibility
** Low; manifest elements will be ignored if unsupported by the client.
**Gecko: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1635272)
**WebKit: No signal (https://bugs.webkit.org/show_bug.cgi?id=211401)
**Web developers: Positive (https://twitter.com/search?q=url%3Ahttps%3A%2F%2Fweb.dev%2Furl-protocol-handler%2F&src=typed_query&f=live)
*Security
**https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/URLProtocolHandler/explainer.md#security-considerations
DevTrial instructions
https://web.dev/url-protocol-handler/#enabling-via-about:flags-or-edge:flags

Flag name #enable-desktop-pwas-protocol-handling

Tracking bug
https://crbug.com/1019239

Launch bug
https://crbug.com/1063658

Sample links
 https://protocol-handler.glitch.me/
 https://fabiorocha.github.io/pwa

===Progressive Web Apps as URL Handlers===

Explainer
https://github.com/WICG/pwa-url-handler

Design docs
 https://github.com/WICG/pwa-url-handler
 https://docs.google.com/document/d/19dGklalQTRtRrG3PKrVbDRmYPLHGLnsGEwUaed7sAFQ/edit?usp=sharing
 https://docs.google.com/document/d/14-_u_DSUKCC0XT9rWgQz9SytDQpCet--KVROV_YTkGw/edit?usp=sharing

Summary: Enables web applications to register as https URL handlers using their web app manifest.

TAG review
https://github.com/w3ctag/design-reviews/issues/552

Risks
* Interoperability and Compatibility: This feature is new to the web and web apps that do not opt in will not be affected because any additions to the web app manifest will be optional. Browser behavior will also not be affected if there are no installed apps that opt in. Browser that do not support this feature will not be adversely affected by new members in the web app manifest.
*Gecko: No signal
*WebKit: No signal
* Web developers: Positive (https://techcommunity.microsoft.com/t5/discussions/click-url-to-open-pwa-automatically/m-p/2192994)

Security
https://github.com/WICG/pwa-url-handler/blob/main/explainer.md#security-considerations

Goals for experimentation: Allow third party developers to use the API and provide feedback.

Contact emails: 'Mandy Chen (SHE/HER)'  mandy.chen@microsoft.com, lu.huang@microsoft.com, luigonza@microsoft.com, mek@chromium.org
===Web app launch handler===
Original I2E
https://groups.google.com/a/chromium.org/g/blink-dev/c/wNOClobsLrs

Explainer
https://github.com/WICG/sw-launch/blob/main/launch_handler.md

Specification
In progress: https://github.com/WICG/sw-launch/pull/58

Summary
Adds a "launch_handler" app manifest member that enables web apps to customise their launch behaviour across all types of app launch triggers (start menu launch, link capture, share target, etc.).

Example usage:
 {
  "name": "Example app",
  "start_url": "/index.html",
  "launch_handler": {
    "route_to": "existing-client-navigate"
  }
 }

This will cause all launches of the Example app to focus an existing app window and navigate it (if it exists) instead of always launching a new app window.

Blink component
Blink>AppManifest

TAG review
https://github.com/w3ctag/design-reviews/issues/683

TAG review status
Closed. Satisfied to see this move ahead but keeping in mind compatibility with the MiniApp lifecycle.

Risks:
*Interoperability and Compatibility
** Gecko: No signal
** WebKit: No signal
** Web developers: Strong positive signals on the previous Declarative Link Capturing origin trial, strong positive signals from the origin trial so far.

Experiment Summary
Web App Launch Handler Origin Trial 1 Developer Feedback

Experiment Goals
# Test the new syntax with "existing_client_navigate" removed.
# Give more opportunities to gather feedback on the "route_to": "existing-client-retain" behaviour that wasn't present in the DLC origin trial.

Experiment Timeline
Previous: M97 to M102.
Requested: M103 to M108.

Reason this experiment is being extended
The shape of the API changed to address TAG feedback on default behaviors.

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

Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1231886

Link to entry on the Chrome Platform Status
https://www.chromestatus.com/feature/5722383233056768

Contact emails
alancutter@chromium.org

==References==

[[Category: Authentication]]
[[Category: Identity]]