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

On Thu, Nov 6, 2014 at 4:24 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

> I really don't like having my "I hate security hat" on for this, ....

So don't wear that hat, then. It's ugly and out of style.

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

People expect that, like automotive engineers, software engineers are
not deliberately making basic functionality unsafe. Nobody wants their
engine block to explode upon ignition, and nobody wants goats.com to
broadcast their GPS coordinates over the internet in the clear. And
when they give goats.com permission to access the GPS coordinates,
they expect to give it to *goats.com*, not "any ISP, attacker, or
other entity who likes to inject JavaScript into pages they don't
own".

We know better. We know what safety guarantees HTTP provides (none),
we know what safety guarantees HTTPS provides, and we know that
people's location can be sensitive information.

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

That is good. That is on purpose. We want for every domain operator to
run HTTPS. Cheap/free certs are very much part of the plan.

No, HTTPS does not solve phishing or social engineering (and expensive
certificates wouldn't help). Those are human brain problems that no
software can fix. But HTTPS goes a way toward providing the minimal,
basic integrity and confidentiality that features like Geolocation
should require.

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

The problem of unauthenticated cleartext is solveable incrementally.
And that is how we are doing it, despite active resistance from people
who don't put user safety first.

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

HTTPS provides people the ability to grant a permission to a named
origin, rather than any ISP, attacker, or other entity who likes to
inject JavaScript into pages they don't own. It provides people some
confidence that the origin is not (intentionally, at least)
broadcasting the person's GPS coordinates to anyone on the internet.

I'd call those material advantages.

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

Our telemetry shows us that an extremely marginal percentage of users
grant origins Geolocation permission when the "Grant goats.com
Geolocation?" infobar is raised. Ignore and Deny events far overshadow
Allow events.

Maybe the goats.coms of the world are not making a very strong value
proposition to users. In any case, it seems likely that very few HTTP
origins would behave differently, compared to now, if Geolocation were
available only to HTTPS origins.

Origins with a clear value proposition for Geolocation, such as
maps.google.com, maps.yahoo.com, or maps.bing.com, offer HTTPS by
default or at least make it available right now. And surely, they are
among the highest-volume sites that might want to use the feature.

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

Don't think of it as a punishment for laxity. Think of it as basic,
bare-minimum safety engineering for helping people. Because that's
what it is.

Received on Saturday, 8 November 2014 01:15:21 UTC