W3C home > Mailing lists > Public > public-geolocation@w3.org > November 2014

Re: Requiring Authenticated Origins for Geolocation API's: Open Call for Comments (deadline - February 1, 2015)

From: Nicholas Doty <npdoty@w3.org>
Date: Fri, 7 Nov 2014 15:31:52 -0800
Cc: "Mandyam, Giridhar" <mandyam@quicinc.com>, public-geolocation <public-geolocation@w3.org>
Message-Id: <D39C2C1B-0C6E-4E8B-B530-C2FE51CA743B@w3.org>
To: Martin Thomson <martin.thomson@gmail.com>
On November 5, 2014, at 10:10 AM, Martin Thomson <martin.thomson@gmail.com> wrote:

> The conclusion on this topic in other groups that I am aware of
> (WebCrypto and Media Capture) was that a restriction to authenticated
> origins was not valuable.
> 
> An authenticated origin is not sufficient to prevent situations where
> users release information.  For an authenticated origin to provide
> meaningful protection, users not only need to verify that the site is
> authenticated (for which there is ample evidence that they do not),
> they also need to ensure that it is the site that they intend to send
> this information to.  That's much, much harder.
> 
> Requiring an authenticated origin is not a particularly high hurdle
> for a motivated attacker to clear.  In fact, it's trivial to redirect
> to an authenticated origin from an authenticated one.  Once there, the
> entire toolbox of phishing tricks (confusable characters, long names,
> etc...) are available to help make the URL look credible.

Was that the conclusion in Media Capture? I had a little bit of trouble keeping up (perhaps in part because ekr talks at least 1.5 timbls), but I don't follow why the authenticated origin is not valuable. I agree that it's trivial to redirect to an HTTPS site and cheap for an attacker to obtain a certificate (for a domain other than the target's). And it seems clear that even when the permission request comes from an authenticated origin that users can still be confused by various phishing techniques.

But that authenticated origins don't alone prevent all impersonation attacks doesn't imply that restricting to authenticated origins is not a valuable mitigation. As I see it, it makes it possible for the user to consider the identity of the requester when considering whether to give permission. That's not the only relevant piece of context for making the permission decision (maybe while I'm at TPAC, I could decide to share my location even when I'm uncertain about who will receive it) and making it possible doesn't guarantee that it will always be used, but I still think we should make it possible.

Currently, the Geolocation API requires that permission prompts include the host of the requesting site in asking for permission [1]. Providing that in the permission prompt given the prevalance of network attackers now seems naive [2].

> I think that punishing sites in this way is bad for the web.  We need
> to provide carrots for the use of HTTPS, not sticks.

+1. We had a breakout session at TPAC about the secure origin question and while it wasn't a detailed topic of discussion, I think there is some general agreement that the purpose of these restrictions (if in fact we conclude that they're worthwhile) is for sensitivity of information, rather than a way to incentivize Web developers to switch to HTTPS. As has been pointed out, there would be no reason to limit restrictions to APIs with certain sensitivity for users if the goal were just HTTPS migration: it could just be for any attractive feature.

In case any of that discussion is useful, here are the minutes from that session:
	http://www.w3.org/2014/10/29-permon-minutes.html

> n.b., This is orthogonal to the question of whether we should
> recommend against the use of persistent permissions on those origins.
> I believe that it is an absolute requirement that persistent
> permission grants only be available to authenticated origins.  I don't
> believe that any implementation currently does this, but they should.
> We already concluded that for Media Capture.

I'm not sure they're entirely orthogonal. It sounds like a point of agreement is that persisted permissions for unauthenticated origins is particularly dissonant, because it allows every future MITM to access the user's geolocation without any permission prompt at all. Adding a requirement for persisted permission would still be a significant change to the spec and to existing deployments of the Geolocation API, but seems particularly valuable and causes less restriction of functionality. A compromise might be something like "MUST NOT persist permissions for unauthenticated origins and SHOULD warn the user if providing temporary permission to an unauthenticated origin".

Thanks,
Nick

[1] http://www.w3.org/TR/geolocation-API/#privacy_for_uas
[2] https://tools.ietf.org/html/draft-thomson-perpass-statement-01

Received on Friday, 7 November 2014 23:32:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:51:10 UTC