Consider checking for security context in the PresentationRequest constructor

[mfoltzgoogle]

@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.

[mounirlamouri]

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]

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]?

[mfoltzgoogle]

Okay, let's move the security context check to the constructor.

The URL arguments come from the PresentationRequest that is the target of getAvailability(). Filed #363 to improve the description.

Can you provide a link to define [SecureContext]?

[annevk]

Target? It's defined on that object, no?

SecureContext is defined in IDL.

[schien]

@mfoltzgoogle Is this link you want? https://heycam.github.io/webidl/#SecureContext

[mfoltzgoogle]

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]

Can you point to the conclusion? I thought we wanted to move most new APIs to require them.

[mfoltzgoogle]

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]

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]

I thought that definitely for things that involve user-facing dialogs there was consensus to require a secure context. @hillbrad?

[mikewest]

@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]

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

[mfoltzgoogle]

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]

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.

[mfoltzgoogle]

Filed #380 to address the concern of @annevk. Closing this with PR #377.