Difference between revisions of "Identifying Returning Users"

Revision as of 10:51, 1 October 2022

Full Title or Meme

Exploring the ways that a web site (aka a 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.
• Native SSO allows sharing of Single Sign-On among native apps from the same vendor.

Solutions

Protocol Handler

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

1. Test the new syntax with "existing_client_navigate" removed.
2. 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