Authenticity of screen selection permission is problematic in insecure contexts

[markafoltz]

In Issue #362, @annevk raised the issue that the "authenticity" of the permission granting step for screen selection is problematic in insecure contexts.

@annevk can you provide any examples where this issue is addressed concretely in other specs/APIs?

[annevk]

Well, for instance, Chrome started to require a secure context for geolocation.

[annevk]

The overall problem is that users shouldn't have to pay attention to the lock icon when responding to dialogs. If they sometimes don't and sometimes do, you're just making things worse.

[markafoltz]

Regarding geolocation, the motivation posted to blink-dev was that geolocation returned privacy sensitive information, and should not be exposed to a MITM, which I totally agree with. We don't believe the Presentation API returns the same kind of privacy sensitive information.

The Secure Contexts TR [1] was also referenced to deprecate insecure use of "Powerful Features." However "Powerful Features" are not defined by that spec. @mikewest is this the document that defines what Chrome considers to be powerful features? [2] Is there anything in the W3C space that is the equivalent?

Regarding the dialog, that seems an issue with all Web platform APIs that require user interaction: alert(), file uploads, printing, running plugins, etc. I'd like to understand better if the intention of some folks is to deprecate all of these on insecure contexts, and can follow up internally within Chrome.

[1] https://www.w3.org/TR/secure-contexts/
[2] https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features

[annevk]

The end goal is to get rid of insecure contexts, so yes.

[markafoltz]

Chrome's guidelines on origin display are documented here [1].

In the origin display section of the spec [2], we can make it stronger to show that insecure origins are indeed insecure.

[1] https://www.chromium.org/Home/chromium-security/enamel#TOC-Presenting-Origins
[2] https://w3c.github.io/presentation-api/#user-interface-guidelines

[annevk]

That doesn't really address my concern.

[anssiko]

[Piggy-packing on this existing issue that provides the most recent context.]

In preparation for the Presentation API CR refresh #406, we explicitly asked the WebAppSec WG folks for feedback whether they see it as an issue that the Presentation API is not gated behind [SecureContext], see https://lists.w3.org/Archives/Public/public-webappsec/2017Jan/0031.html. In that thread (still developing) the general recommendation is that indeed new features should be exposed into secure context only.

Earlier, as part of the privacy and security review of the Presentation API documented in #45, we solicited feedback from the Web Security IG, PING, and Mike West (lunch at TPAC 2015), and at that time, [SecureContext] was not seen as a must requirement.

It appears new information has surfaced and the web security community's thinking has evolved since then, and we should consider re-evaluating that decision. We must understanding that might delay our CR refresh plans.

Comments, concerns? What are the key use cases that motivate the use in insecure contexts?

If we decide to require [SecureContext], there's reusable prose and guidance for editors at https://w3c.github.io/webappsec-secure-contexts/#new. Also major implementations seem to provide isSecureContext() or similar method that implements the checks defined in the Secure Contexts spec, so the required implementation effort would be reasonable.

[markafoltz]

I'm fine reopening the issue but some things should be clarified before we can have an intelligent discussion.

• Is there a WebAppSec consensus position, what is it, where was it discussed?
• Are there specific risks identified by WebAppSec from insecure contexts?

[markafoltz]

One issue identified thus far was that displaying insecure origins as part of a permission prompt devalues prompts overall (for higher stakes questions like geolocation, payments, etc.) as users should assume that all prompts are from secure contexts and could ignore any indications otherwise.

This aligns with research done by the Chromium Enamel team [1] and is what I think @annevk was getting at in #380 (comment).

[1] https://drive.google.com/file/d/0BxdLBiVAM05cRVhOMi1FMmlnenM/view

[anssiko]

@mfoltzgoogle could you make the Chromium Enamel research [1] you refer to world-readable? (Currently: "you need permission")

There's a lot of interesting material in the Enamel team's public folder, but not immediately obvious what might be the most relevant to this discussion.

[markafoltz]

Here's a link to the USENIX proceedings where it was published.

https://www.usenix.org/sites/default/files/soups2016_full_proceedings_interior.pdf#page=7

[anssiko]

Thanks! Based on a quick scan of abstracts I see the following relevant papers:

• Rethinking Connection Security Indicators (pp. 1-14)
  • "We surveyed 1,329 people about Google Chrome’s security indicators using a custom Chrome extension."
• A Week to Remember: The Impact of Browser Warning Storage Policies (pp. 15-26)
  • "How long should a browser store a user’s decision to override an HTTPS error warning?"

The whole of the proceedings with its 354 pages is a goldmine for anyone who wants to get to the bleeding edge of the security and privacy UX.

[markafoltz]

There are two other specific issues with allowing the presentation to be fetched from an insecure context.

1. The specific type of phishing attack mentioned in the spec [1] becomes possible for any attacker who can manipulate the resources fetched by the presentation page.

2. The user should expect that the presentation screen doesn't retain browsing state after the presentation is terminated. In an insecure context, it's impossible to guarantee that browsing state isn't leaked to a third party.

[anssiko]

Regarding WebAppSec consensus position, @tidoust's mail to public-webappsec was not a formal Call for Consensus, but rather a check that that group is still fine with our approach. So the process is the usual: any input we receive from WebAppSec friends we should evaluate in this group along with any other new information that is brought to our attention, and take all that into consideration in resolution of this issue.

[markafoltz]

Okay, the WebAppSec discussion thus far has been incorporated into this issue. If there's any additional feedback we'll add it here.

I read Rethinking Connection Security Indicators, and the basic conclusion is that it is hard to design effective security indicators and we should avoid adding new ones to the browser chrome if possible.

[anssiko]

I observe no further comments in the related public-webappsec thread or in this issue.

@mfoltzgoogle you identified two specific issues in #380 (comment). Does https://w3c.github.io/webappsec-secure-contexts/#new provide you with appropriate guidance and hooks to mitigate the identified attacks? Any open questions to the group?

If all clear, I'd suggest you submit a PR to be reviewed with the WebAppSec people who raised this issue.

[markafoltz]

I don't have any questions at this time. However do we have consensus? I don't know what other implementations think on this issue.

Implementations have shipped in insecure contexts for some time, so there's a question of how willing we are to break existing Web content.

[anssiko]

All - Please speak up by 21 Feb if you have concerns on requiring a secure context for the Presentation API as discussed in this issue. Silence is considered consent. Ping @schien for Mozilla's position.

[anssiko]

Implementations have shipped in insecure contexts for some time, so there's a question of how willing we are to break existing Web content.

@mfoltzgoogle You're raising an important point regarding compatibility with existing web content. Do we have telemetry data?

To mitigate, I'd expect implementations to log warnings (to developer console) on non-secure use over a period of possibly multiple major releases, before disabling. Alternatively or in addition, display a user facing warning that requires active user consent. This is up to each implementation, however. Your Enemel team's recommendation would be good to hear.

[markafoltz]

We don't have telemetry that breaks down usage in secure vs. insecure contexts. Filed a bug to track this work. Will Mozilla do the same?

In general when deprecating Web platform features, Blink logs console warnings until usage drops below a threshold of pageviews, then removes the feature.

[anssiko]

All - Please speak up by 21 Feb if you have concerns on requiring a secure context for the Presentation API as discussed in this issue. Silence is considered consent. Ping @schien for Mozilla's position.

No concerns raised.

@mfoltzgoogle You are now free to implement the change. In addition to this group, we should loop in key WebAppSec people to review the PR.