-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What kind of same-site rule is appropriate? #8
Comments
While this might expand beyond the scope of WebKit, schemelessly perhaps makes sense if there's some interest in binding the functionality to more than just web pages. As to scheme where it would apply to WebKit, perhaps OTP autocompletion should only be offered or succeed on https origins anyway. If so, eliminating characters in the SMS message is desirable as native max message size is small in SMS. But if, for example, an app wanted OTP confirmation, being schemeless might signal allowing an App which has authenticated as belonging to/with the stated origin to utilize the autocomplete? At least in the Apple ecosystem, there are already mechanisms for binding DNS identifiers in an authenticated manner to apps (for several purposes). Perhaps a DNS identifier as origin here would achieve the same outcome for an app which has that same entitlement? |
Requiring a scheme would also inflate the payload size if a human-readable format is used. |
Agreed on the payload inflation -- presumably you'd want the feature to only supply the OTP via mechanisms the platform regarded as secure anyway. |
For web content, an origin-bound one-time code should be understood to be intended for a secure context.
Just to clarify for others, Apple’s machinery for associating apps with a website (origin) is called associated domains. I understand that Android has a similar mechanism. |
If we are to go with this I'd somewhat prefer a same origin default/option. And yeah, maybe not offer the feature without secure contexts as it becomes very brittle then. |
If a server intends to allow sign-in on an HTTPS site, it would be Bad™ for that OTP to leak by being made available on an HTTP page that is both visible to and controllable by everyone on the network between the user and the server. To me, that means we need to respect the scheme of any origin asserted by the sender. Similarly, it's not clear to me why it would be valuable to allow an OTP targeting one origin ( |
@mhardeman wrote:
@riking wrote:
Ahh, I think there's a misunderstanding here. The syntax doesn't have to specify a scheme, merely a host. When parsed, we end up with an origin whose host matches what was in the message, and whose scheme and port are "https:" and "" respectively. Regardless of what same-site rule we end up going with, the syntax doesn't have to change. |
This strikes me as an excellent argument against schemelessly same-site. I'll update the PR accordingly, but I'm gonna leave this issue open as I think we should continue to discuss the same-origin v. same-site question. |
Circling back on this, I think I've partially changed my mind from last week. I think we should
(For same origin and same site in the below table, I'm assuming it'd be secure contexts only.)
|
How would developers know what to rely on? |
I think we're gonna need RFC2119 SHOULD-level language here. It'd be great if it could be a MUST, but we know (given shipping behavior in several password autofill implementations) that "that there may exist valid reasons in particular circumstances to ignore [the requirement]," so SHOULD it is. Here's a quick straw person proposal, which I'll try to return to later today to provide additional rationale:
|
Thinking as an implementer for a moment, here’s what I suspect a sensible policy would be:
This is consistent with some Password AutoFill implementations, which save credentials per-origin (analog: origin in the message), but offer them same-site (but label them when they’re doing so). |
The spec matches @rmondello's suggested policy. I'm going to close this issue here. If, after reviewing the spec text, people still have concerns on this topic, please file an issue in the spec's dedicated repo. |
The explainer currently says:
Should this really be schemelessly same site, or should we tighten it a bit to (schemefully) same site?
The text was updated successfully, but these errors were encountered: