One possible way to handle the nested iframe case. #5
Conversation
|
This all looks good and makes sense to me. |
README.md
Outdated
| @@ -69,6 +69,21 @@ In this example, | |||
|
|
|||
| The characters `"@"` and `"#"` identify the origin and the code, respectively. (We can always introduce additional prefix characters in the future if it turns out we need to include additional information in these messages.) | |||
|
|
|||
| Some sites use third-party `iframe`s for authentication. In such cases, the third-party `iframe`'s origin can be specified using a `"%"` field after the code. | |||
There was a problem hiding this comment.
High level question: is the goal for this repo to specify specifically the sms format or to also go over the browser implementation that uses it.
That is, shouldn't this text go under the whatwg/html spec or the wicg/WebOTP spec?
There was a problem hiding this comment.
I think the format, and considerations for use by user agents. For instance, the spec talks about UA considerations that would apply to any feature in a browser that’d assist with providing codes to websites (e.g. Security Code AutoFill or WebOTP).
There was a problem hiding this comment.
See also my answer to this question here: #4 (comment)
|
|
||
| * `"https://example.com"` is the origin the code is associated with, | ||
| * `"747723"` is the code, | ||
| * `"https://ecommerce.example"` is the origin of the third-party `iframe`, and |
There was a problem hiding this comment.
The attack vector I'm concerned about here is something along the lines of an ad network running on an iframe and sending SMSes to users to identify them. There is user permission involved, which I think helps, but still feels more dangerous than needed.
Can you help me understand what are the alternatives you considered?
There was a problem hiding this comment.
I’m not sure I’m seeing the attack. The iframe extension only lets the party sending the text bind the code to an iframe they trust on their own page. Can you be more specific about the attack vector here?
The alternatives considered were:
- Implicitly allow a code bound to a website to be used on all subframes of the website. We considered this to be a potential security risk.
- Never allow use of origin-bound codes in iframes. We found this to be limiting, because some real-world websites delegate authentication to use auth widgets from other origins.
There was a problem hiding this comment.
The attack vector I have in mind here is that there are a lot of widgets that are embedded on websites as iframes at scale. Ad networks, analytics, commenting widgets, etc are highly deployed.
- highly-deployed iframe-widget evil.com wants to find a user on the web on example.com
- example.com embeds evil.com as an iframe
- user goes to example.com
- evil.com suspects a specific user of interest is at example.com and sends an SMS to the user's phone
- browser shares the SMS with evil.com while the user is on example.com
- evil.com now gets confirmation that the specific user was visiting example.com
This, I think, is mitigated if the user agent asks for the user's consent on step (5), which I think is sufficiently true for the autocomplete="one-time-code" formulation which uses autocomplete and the current formulation of WebOTP, but seems like a hard requirement going forward for future implementations of WebOTP (at least for iframe-based use cases it would seem). I'm wondering if this requirement needs to be encapsulated here in this spec or on the WebOTP spec specifically.
There was a problem hiding this comment.
Other specifications have resolved this class of issue through Feature Policy. If usage of WebOTP in cross-origin frames required opt-in from the top-level origin then I think that would resolve the concern in @rmondello's alternative (1).
| This specification does not impose any requirements or restrictions on the use of one-time codes which are not [=origin-bound one-time codes=]. | ||
| User Agents determine whether or not to assist the user to provide an origin-bound one-time code to a website with [=origin-bound one-time code=] |otc| and {{Document}} |doc| by running these steps: | ||
|
|
||
| 1. If |doc| is not the [=active document=] of a [=/browsing context=], return failure. |
There was a problem hiding this comment.
Same here: wondering if you are expecting this repo to specify browser API behavior or specifically the formatting of the SMS.
|
On a related note, on format, I think I generally prefer "@a.com @b.com" (maybe there is an analogy to be made with twitter at-replies) or maybe "@a.com > @b.com" (maybe there is an analogy that can be made with CSS selectors) rather than a new token type (which I was hoping to reserve for new values to be passed to the origins). So, something along the lines of: That is, from a mental model perspective I have this separation between AUDIENCE : CONTENT in formatting (e.g. "@example.com #18923") and would like to see that cohesion hold over time as we expand both AUDIENCE (e.g. to iframes) and CONTENT (e.g. for payment tokens). I dunno if that breakdown between AUDIENCE : CONTENT makes sense (and happy to be convinced otherwise), but just wanted to explain my mental model so far :) |
|
Note to self: rebase this after #7 lands. |
Fixes #4.