Repository navigation
Consider checking for security context in the PresentationRequest constructor #362
Description
@mounirlamouri brought up the following:
Currently, we check for mixed content in the steps to execute start(), reconnect() and getAvailability(). 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.
Activity
mounirlamouri commentedon Oct 25, 2016
There are precedent to throw in constructors. For example, the Fetch API does this for most of its defined constructor, for example
Request.CC @annevk how does it sound?
annevk commentedon Oct 25, 2016
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
[SecureContext]?markafoltz commentedon Oct 25, 2016
Okay, let's move the security context check to the constructor.
The URL arguments come from the
PresentationRequestthat is the target of getAvailability(). Filed #363 to improve the description.Can you provide a link to define
[SecureContext]?annevk commentedon Oct 25, 2016
Target? It's defined on that object, no?
SecureContext is defined in IDL.
schien commentedon Oct 26, 2016
@mfoltzgoogle Is this link you want? https://heycam.github.io/webidl/#SecureContext
markafoltz commentedon Nov 21, 2016
Note: I'm going to work on this after other PRs land that touch the same parts of the spec.
Re:
[SecureContext]After security, privacy, TAG review #45 it was concluded to not restrict API to secure contexts.annevk commentedon Nov 22, 2016
Can you point to the conclusion? I thought we wanted to move most new APIs to require them.
markafoltz commentedon Nov 22, 2016
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
annevk commentedon Nov 23, 2016
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.
annevk commentedon Nov 23, 2016
I thought that definitely for things that involve user-facing dialogs there was consensus to require a secure context. @hillbrad?
mikewest commentedon Nov 23, 2016
@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. :)
tidoust commentedon Nov 23, 2016
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:
https://lists.w3.org/Archives/Public/public-webappsec/2015Nov/0064.html
... which did not lead to further comments.
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:
http://www.w3.org/2015/12/03-privacy-minutes.html#item02
markafoltz commentedon Nov 28, 2016
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.
annevk commentedon Nov 29, 2016
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.
markafoltz commentedon Nov 29, 2016
Filed #380 to address the concern of @annevk. Closing this with PR #377.