Intent to deprecate: Insecure usage of powerful features

[Joel Weinberger]

Please note that the main discussion for this is intended to be on the
blin...@chromium.org mailing list (
https://groups.google.com/a/chromium.org/forum/#!forum/blink-dev). However,
to alert relevant groups of the intent, we have bcc’d the following lists
on this email:

securi...@chromium.org

dev-se...@lists.mozilla.org

public-w...@w3.org

public-web-...@w3.org

public-de...@w3.org

public-ge...@w3.org

public-h...@w3.org We want to start applying the concepts in
https://w3c.github.io/webappsec/specs/powerfulfeatures/ to features that
have already shipped and which do not meet the (new, not present at the
time) requirements. We want to start by requiring secure origins for these
existing features: - Device motion / orientation - EME - Fullscreen -
Geolocation - getUserMedia As with gradually marking HTTP as non-secure (
https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure),
we expect to gradually migrate these features to secure-only, based on
thresholds of usage, starting with lowest usage and moving towards higher.
We also expect to gradually indicate in the UX that the features are
deprecated for non-secure origins. The deprecation strategy for each of
these features is not decided on and may very well differ from feature to
feature. We don’t currently know what the thresholds will be, or how
heavily used the features are on what kinds of origins. We are in the
process of gathering data, and will report back when we have it. There are
no firm plans at all at this time, other than eventual deprecation. We
intend for this to stimulate a public discussion of the best way to
approach this deprecation. So, to that point, we'd love to hear what the
community thinks.


Thanks,

Joel Weinberger, Chrome Security

[Kevin Chadwick]

On Thu, 26 Feb 2015 23:25:43 +0000
Joel Weinberger wrote:

> Geolocation - getUserMedia As with gradually marking HTTP as non-secure (
> https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure),
> we expect to gradually migrate these features to secure-only, based on
> thresholds of usage, starting with lowest usage and moving towards higher.
> We also expect to gradually indicate in the UX that the features are
> deprecated for non-secure origins. The deprecation strategy for each of
> these features is not decided on and may very well differ from feature to
> feature. We don’t currently know what the thresholds will be, or how
> heavily used the features are on what kinds of origins. We are in the
> process of gathering data, and will report back when we have it. There are
> no firm plans at all at this time, other than eventual deprecation. We
> intend for this to stimulate a public discussion of the best way to
> approach this deprecation. So, to that point, we'd love to hear what the
> community thinks.

Seems reasonable, though I think dos and amplification (100x
demonstrated in the past) through ssl is ignored in the TLS speed
concerns.

In the long term and depending on the depth of features that are
moved to requiring https then it may make it more difficult to keep
serving http despite https servers being saturated.

[Joel Weinberger]

Hi everyone. A couple of clarifications and thoughts.

- As mentioned before, there is no timeline for this deprecation. That's
one of the things that we're trying to figure out. We certainly will
consider the "ease of use" of SSL in the timeline. But in the meanwhile,
check out some of the references given earlier (e.g. sslmate,
letsencrypt.org, etc.).
- The problem with fullscreen is not just privacy; it's very much about
MitM attackers. If, for example, http://example.com has a legitimate use
of fullscreen, and the user grants it, now *any* Man-in-the-Middle can
silently use this fullscreen feature. They could inject a phishing attack,
for example, Or, perhaps they could just abuse it for fullscreen ads. In
any case, the concern isn't necessarily http://example.com, but an
attacker.
- As mentioned before, localhost is already considered a "secure
context", which should help as development. Additionally, we intend to
build a flag that will temporarily disable the secure origin requirement
for features for a specific origin. Thus, for testing, this should give a
lot of flexibility.
- I love the idea of restricting persistence of these permissions before
outright deprecation. I do not believe we've done this previously, but it's
certainly something we've discussed.

Keep the comments, thoughts, and ideas coming. Thanks!
--Joel

On Sat, Feb 28, 2015 at 8:14 AM Kevin Chadwick <ma1l...@yahoo.co.uk>
wrote:

[Joel Weinberger]

I certainly agree that this would be a great start/halfway point, but it
doesn't really address the fundamental issue, which is that if a user
trusts an origin, they'll grant the permission. And even if the permission
isn't persistent, they'll still be granting the permission to any
man-in-the-middle.
--Joel

On Mon, Mar 2, 2015 at 1:55 PM <oli...@omattos.com> wrote:

> How about "HTTP origins can't persist any permission grant.".
>
> That way every feature still works. Network attackers can still do bad
> stuff, but it won't persist. It also provides an SSL upgrade incentive.
>
> The permission grant dialogue for insecure origins could be reworded to
> say "Do you want to give *the internet* access to your camera?"
>
> Now users are informed that potentially more than just the website showing
> can access the camera.
>
>
>
> On Monday, March 2, 2015 at 2:37:28 AM UTC, Jeffrey Yasskin wrote:

>
>> On Mar 1, 2015 5:01 PM, "Joel Weinberger" <j...@chromium.org> wrote:
>> >
>>
>> > The problem with fullscreen is not just privacy; it's very much about
>> MitM attackers. If, for example, http://example.com has a legitimate use
>> of fullscreen, and the user grants it, now *any* Man-in-the-Middle can
>> silently use this fullscreen feature. They could inject a phishing attack,
>> for example, Or, perhaps they could just abuse it for fullscreen ads. In
>> any case, the concern isn't necessarily http://example.com, but an
>> attacker.
>>

>> Fullscreen, pointer lock, and keyboard lock have spoofing risks that
>> multiply, the more of them you have enabled. It may make sense and be
>> feasible to restrict combinations before restricting the individual
>> features.
>>
>> Jeffrey
>>
>

[Jeffrey Yasskin]

[Randell Jesup]

>How about "HTTP origins can't persist any permission grant.".
>
>That way every feature still works. Network attackers can still do bad
>stuff, but it won't persist. It also provides an SSL upgrade incentive.
>
>The permission grant dialogue for insecure origins could be reworded to say
>"Do you want to give *the internet* access to your camera?"
>
>Now users are informed that potentially more than just the website showing
>can access the camera.

In Firefox, for getUserMedia(), we don't allow persistence of any camera/mic
permissions if the origin is insecure, and we don't allow (even for
whitelisted sites) access to ScreenSharing captures for insecure origins.

>> On Mar 1, 2015 5:01 PM, "Joel Weinberger" <j...@chromium.org <javascript:>> wrote:
>> The problem with fullscreen is not just privacy; it's very much about
>> MitM attackers. If, for example, http://example.com has a legitimate use
>> of fullscreen, and the user grants it, now *any* Man-in-the-Middle can
>> silently use this fullscreen feature. They could inject a phishing attack,
>> for example, Or, perhaps they could just abuse it for fullscreen ads. In
>> any case, the concern isn't necessarily http://example.com, but an
>> attacker.

--
Randell Jesup, Mozilla Corp
remove "news" for personal email

[Martin Thomson]

On Mon, Apr 20, 2015 at 10:43 AM, Randell Jesup <rjesu...@jesup.org> wrote:
> we don't allow (even for
> whitelisted sites) access to ScreenSharing captures for insecure origins.

That's only because the whitelist is a form of persistence. If we
opened this feature up to the drive-by web, we might. But we haven't
had that discussion yet.