-
Notifications
You must be signed in to change notification settings - Fork 39
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
Consider checking for security context in the PresentationRequest constructor #362
Comments
Seems fine. (I don't really understand how this specification works by the way. https://w3c.github.io/presentation-api/#getting-the-presentation-displays-availability-information says that there's some kind of input, whereas the method takes no arguments per IDL.) Also, should this entire API be using |
Okay, let's move the security context check to the constructor. The URL arguments come from the Can you provide a link to define |
Target? It's defined on that object, no? SecureContext is defined in IDL. |
@mfoltzgoogle Is this link you want? https://heycam.github.io/webidl/#SecureContext |
Note: I'm going to work on this after other PRs land that touch the same parts of the spec. Re: |
Can you point to the conclusion? I thought we wanted to move most new APIs to require them. |
Who is "we"? One part of the relevant discussion is here. This was also discussed with WebAppSec and PING, perhaps @tidoust can help dig up the relevant links. https://www.w3.org/2015/10/29-webscreens-minutes.html#item06 |
Mozilla at least. I also heard similar signals from @mikewest though Google overall might not be convinced yet. But since you're going through a permission dialog it seems actually very important to require a secure context. Otherwise the user cannot be sure about who they are granting the permission to. |
I thought that definitely for things that involve user-facing dialogs there was consensus to require a secure context. @hillbrad? |
@mikewest would indeed prefer that every new API require a secure context. As @annevk notes, especially when we're gating this on a permission, then it needs to require a secure context in order for that permission to have any meaning. As @annevk also notes, not everyone on Chrome's security team agrees with me yet. :) Can you point to the discussion? I see some assertions in https://www.w3.org/2015/10/29-webscreens-minutes.html#item06 that seem strange, but I'd like more context before arguing about them. :) |
I'm not sure there are more discussions to point at regarding conclusions. The minutes only summarize the joint Second Screen WG / @mikewest TPAC lunch, which was not minuted in itself. My recollection from the lunch is that it was deemed acceptable at the time not to require secure contexts for the Presentation API, and actually especially given the presence of a user prompt. The point was also raised in a subsequent request for review sent to the WebAppSec Working Group shortly after our discussions at TPAC: We discussed various points with PING, but not that particular issue as far as I remember. Minutes of the main discussion with PING are at: |
The permission to use a presentation display is intended to be ephemeral and only for the duration of the presentation, like following a link. If something is presented that the user doesn't want they can close the presentation (or the tab that started it) and nothing has changed. Also note the features that cause a user dialog to appear are gated by a user gesture requirement. The group (led by @tidoust) also assessed the API against the "Powerful Features" rubric authored by @mikewest, the conclusions are in Issue #45 linked above and the thread linked in #45 (comment). If you have new information specific to the Presentation API you'd like the group to consider around this, then feel free to open a new issue in GitHub. Meanwhile, I'll prepare a PR to address the original suggestion to improve the spec around the mixed context check. |
I think what was not considered is that dialogs shown to the user should only be done through HTTPS since otherwise the authenticity of the dialog cannot be determined by the user. |
@mounirlamouri brought up the following:
Currently, we check for mixed content in the steps to execute
start()
,reconnect()
andgetAvailability()
. It would simplify both the spec and the implementation to move this check to the PresentationRequest constructor.I am not sure if it is okay to throw exceptions in conctructors of Web APIs. If there are precedents, I'd like to know.
Also, we would need to be assured that the security context could not be changed between constructor and method invocation.
The text was updated successfully, but these errors were encountered: