Difference between revisions of "Identifying Returning Users"

From MgmtWiki
Jump to: navigation, search
(→‎Problems)
(→‎Solutions)
Line 14: Line 14:
 
==Solutions==
 
==Solutions==
  
−
Protocol Handler as a means to accept [[Authentication]] queries from [[Relying Party]] -- statuses from blink-dev
+
The Protocol Handler as a means to accept [[Authentication]] queries from [[Relying Party]] -- statuses from blink-dev
  
 
===Permission automation for registerProtocolHandler===
 
===Permission automation for registerProtocolHandler===

Revision as of 13:58, 1 October 2022

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

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.

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

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

Retrieved from "http://tcwiki.azurewebsites.net/index.php?title=Identifying_Returning_Users&oldid=15988"