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: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 6 Nov 2014 16:24:14 -0800
Message-ID: <CABkgnnVPongPpPaUZqoWL=SXs2YXqQi6H5ttynPL_+exDBJrRg@mail.gmail.com>
To: Mounir Lamouri <mounir@lamouri.fr>
Cc: "public-geolocation@w3.org" <public-geolocation@w3.org>, Mike West <mkwst@google.com>
I really don't like having my "I hate security hat" on for this, ....

On 6 November 2014 13:21, Mounir Lamouri <mounir@lamouri.fr> wrote:
> I'm confused, what's the difference between a secure origin and an
> authenticated origin?

Precisely my point.  I'm sure that your UX research will help you
understand just how little difference whether an origin is
authenticated or not makes to user behaviour.

> I would assume that a secure origin had a valid
> certificate that was certified by a trusted source. Is it that easy to
> get such certificate?

Yes, yes it is.  I think that the monetary cost for the cert is now
basically zero and the cost of a domain is approaching zero.

> Also, an issue with using the geolocation api over insecure origins (and
> especially http) is that you might end up passing in clear trough the
> wire some personal and identifiable information, which obviously, isn't
> a great idea.

Obviously it's not a great idea to offer anything service in the
clear, but people do and until they stop doing that entirely, changes
like this aren't going to solve the problem.

But that is not the concern I raised.  The concern I raised is that
this doesn't provide any material security advantage to users.

>> 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).
> Chromium added some metrics recently to check whether there is a
> significant usage on non-secure origins. I think it's too early to share
> data but I'm pretty sure, we will be able to do so soon. The plan is to
> iterate from there. If we the usage is low enough, we will try to
> deprecate the API on non-secure origins.

Let me know how that goes.  But I don't believe that there needs to be
a one-size-fits-all policy for browsers.  We've tried that, and it
would be nice for so many reasons, but we need to recognize that
things like this policy are an important part of what makes one
browser different from another.

I'm more interested in finding things that will make a real
difference.  Incentives to add more security, not punishment for being
lax.  If you have ideas that help there, then I'm all ears.
Received on Friday, 7 November 2014 00:24:42 UTC

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