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: Wed, 5 Nov 2014 10:10:50 -0800
Message-ID: <CABkgnnWFkJ88qYbY1AwrUWEq2CMbvwgfCxCgLpFKx02OeN8pRQ@mail.gmail.com>
To: "Mandyam, Giridhar" <mandyam@quicinc.com>
Cc: public-geolocation <public-geolocation@w3.org>
a)

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.

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.

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.

--Martin

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.

On 5 November 2014 07:23, Mandyam, Giridhar <mandyam@quicinc.com> wrote:
> As was discussed at TPAC 2014, the topic of requiring authenticated origins
> for geolocation is now being taken up in the form of an open call for
> comments on the public-geo mailing list.  An overview of the issue was
> presented at last week’s face-to-face meeting:
> https://www.w3.org/2008/geolocation/wiki/images/1/12/Geolocation_-_Trusted_Origin.pdf.
> The definition of “authenticated origin” may be found at
> http://w3c.github.io/webappsec/specs/mixedcontent/.  This requirement would
> apply to all specifications developed by the Geolocation Working Group.
>
>
>
> As decided at that meeting, before acting upon this issue it is important to
> gather feedback from affected parties.  This includes web service providers,
> developers, and browser (web runtime engine) vendors.
>
>
>
> The following is requested from respondents:
>
>
>
> a)      If you are against requiring authenticated origins for geolocation
> API’s, please state so and state your reasons for objection.
>
> b)      If you are in favor of requiring authenticated origins for
> geolocation API’s, please state so and your reasons for support.  In
> addition, please provide a proposal for how support for unauthenticated
> origins could be phased out (e.g. a schedule for developer evangelization,
> warning dialog boxes in browsers, hard cutoff for ending support in
> browsers).
>
>
>
> After responses are received, I will do my best to compile results and
> provide a representative synopsis of the feedback.  I hope this call for
> comments is clear as written above, but if not please let me know.
>
>
>
> -Giri Mandyam, Geolocation Working Group Chair
>
>
>
> P
>
>
Received on Wednesday, 5 November 2014 18:11:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:01 UTC