Add isProtocolSupportedByClient static method #221
Conversation
There was a problem hiding this comment.
Thanks for doing this, I think it probably is important and valuable given WebKit's plans to not support some popular protocols. Should we perhaps define this to call an internal function, which then we also call from the main processing parts of the spec and return a well-defined error for when the result is 'false'? @marcoscaceres @mohamedamir WDYT?
Co-authored-by: Matthew Miller <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
|
Hey all, please see #168 ... I proposed a different way of doing this there that is, IMO, more developer friendly and avoid the "support" question... that the browser recognizes the protocol string does not imply "support" for it. I suggest we refactor this pull request to align more fully with #168 |
Co-authored-by: Christian Bormann <[email protected]>
|
Is this intended to only reveal information on what the browser version supports passing through and specifically not to reveal any details of what wallets are available, what the user has configured, what credentials they have, whether they have another device that supports credentials, etc.? (I know I raise this question every time it comes up, but we haven't written down the answer, so I keep asking.) If so, we should add normative requirements that indicate that. |
Essentially: "can you pass a request with this protocol to the next component" There is no possible way for it to reveal any details about wallets or credentials. It just returns a boolean given a protocol identifier. |
|
Browsers could modify the response based on some knowledge of wallet availability or configuration. I think we should just specify that the UA shouldn't use that kind of knowledge for a customized value, they should only describe browser-level support without user/device/app/wallet configuration detail. |
Not sure I follow. The browser is the only party handling this request and response. |
|
As in, a browser vendor trying to implement this section could try to use their knowledge of system/app/wallet/user-configuration properties to modify the return value, and I think this API should tell the browser vendor implementer not to do that. |
|
Gotcha. I'm not sure how we write something like that given each browser has their own method of determining what the response should be. Do you have some suggested text? |
|
I can try to propose something (tomorrow, likely) that would set some SHOULD NOT/MUST NOT conditions to try to capture what I think is the agreement. |
| This method does not convey protocol support in the underlying platform | ||
| or credential provider. | ||
| </p> | ||
| <p> |
There was a problem hiding this comment.
| <p> | |
| <p> | |
| User agents SHOULD NOT vary the response value based on any information about availability of hardware, presence or configuration of software, wallets or credentials, or user configuration or preferences. If the response value varied, the user agent would introduce risks both of fingerprinting and of silently revealing other details about user behavior or configuration. The response value SHOULD vary only by user agent major version and indicate whether the browser supports distributing requests with that protocol to underlying platform or provider. | |
| </p> | |
| <p> |
There was a problem hiding this comment.
This is just a starting point proposed text for trying to capture the idea that this is just a convenience method indicating browser version support, rather than details to the site about what the user has configured.
There was a problem hiding this comment.
That sounds great @npdoty. thanks!
Closes #219
The following tasks have been completed:
Implementation commitment:
Documentation and checks
Preview | Diff