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

Sorry I'm hopping into this thread without the larger context. I'm sure
many of these points have been made before, and I hope you'll be patient
with my probable repetition.

On Fri, Nov 7, 2014 at 1:24 AM, Martin Thomson <martin.thomson@gmail.com>
wrote:

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

:( "I hate security" hats are no fun.


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


Hopefully my previous response clarified the intent of the term.


> 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 agree. Which is why user agents (and specification authors) need to
create clear security boundaries when we can't reasonably ask users to have
enough context to answer a security-related question.


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

As it should! Hooray!


> 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 scenario I raised in my previous response is one which requiring
encrypted and authenticated endpoints significantly mitigates. As long as
an active network attacker can exploit the fact that I've granted `
http://insecure-but-beautiful-maps.com/` access to my location by injecting
content which appears to be from that origin, reading the location
information, and postMessaging/XHRing/whatevering it anywhere she likes.

Can we agree that mitigating that scenario would be helpful?


> Let me know how that goes.  But I don't believe that there needs to be
> a one-size-fits-all policy for browsers.


I think that there are some things that we can probably agree should be
one-size-fits-all. The same-origin policy, for instance. We probably don't
want browsers competing on that particular 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.
>

It sounds like your concern is more related to existing deployment of
geolocation-using websites, rather than a principled opposition to a
hypothetical world in which we'd chosen to restrict geolocation from the
get-go. Is that accurate?

If so, great! Perhaps we could agree that it would be nice if geolocation
wasn't available in plaintext, and figure out how we could get there
together via some sort of staged deprecation process. The nice thing about
location is that it's wonderfully fungable: we don't have to _break_ `
http://insecure-but-beautiful-maps.com/`, we can, for example, slowly
reduce it's accuracy to ratchet down the risk to users over time.

-mike