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: Anne van Kesteren <annevk@annevk.nl>
Date: Fri, 7 Nov 2014 10:20:25 +0100
Message-ID: <CADnb78iy4ViPZM4nhVWqMRMuF6DT40PsmavkwLkpHq4DE7BOoA@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: "Mandyam, Giridhar" <mandyam@quicinc.com>, public-geolocation <public-geolocation@w3.org>
On Wed, Nov 5, 2014 at 7:10 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> 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.

The way you frame this makes it sound like it is harder for the user
if we require authenticated origins, which is false. If we require an
authenticated origin, the only bit the user has to verify is the
domain name. That is much easier than the choice you seem to want to
impose on end users. Namely, that they verify the domain name, and
have some reasonable confidence about the security of the network
(which they can't, since the network is insecure).



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

I don't see why these would be arguments to make the status quo even
worse for end users. And these concerns are in fact getting addressed
with HSTS and less cluttered address  bars.


> There are ways in which this is valuable on a site-by-site basis, but
> that option is already available to sites that want actual security.
> Sites can use https.  The problem with this proposal is that it
> generalizes from what is essentially an exception without considering
> the second order effects.

What is an exception?

And this is not about sites wanting actual security. This is about
users wanting actual security.


> The cost of the proposed change is that this will actually break sites
> that currently use the API.  From the large (maps.bing.com) to the
> small (www.wtfsigte.com).
>
> 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.

If we provide sufficient migration time, those sites will be able to
cope just fine. And users will end up with an improved security and
privacy from the network.


-- 
https://annevankesteren.nl/
Received on Friday, 7 November 2014 09:20:52 UTC

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