Re: Additional security and privacy considerations?

Hi,

I think we need to close this discussion. After discussing with Thomas
offline, we have one wording proposal and one question for our group.

Here is the wording proposal:

//-------------------------------------------------------
Additional implementation consideration

This section is non-normative

Further to the requirements listed in the previous section,
implementors of the Geolocation API are also advised to consider the
following aspects that may negatively affect the privacy of their
users: in certain cases, users may inadvertently grant permission to
the User Agent to disclose their location to Web sites. In other
cases, the content hosted at a certain URL changes in such a way that
the previously granted location permissions no longer apply as far as
a user is concerned. Or the users might simply change their mind.

While predicting or preventing these situations is inherently
difficult, mitigation and in-depth defensive measures are an
implementation responsibility and not prescribed by this
specification. In designing these measures, implementers are advised
to enable user awareness of location sharing, and to provide easy
access to interfaces that enable revocation of permissions, even when
users have previously granted authorization.
//-------------------------------------------------------

I think such wording captures well the privacy concerns that were
raised by Thomas while clearly indicating that the defenses against
potential problems are completely up to the implementations to
consider. We also both think that listing these privacy concerns in
the spec is a responsible thing for us to do.

And here is the question:

Should the wording also contain the following additional sentence:

"Additional defense measures might include limiting the scope of
authorizations in time by asking for re-authorization in certain time
intervals."

My personal opinion is that it should not. This sentence suggests a
concrete solution direction to solve the above mentioned concerns. I
think we should not add it to the spec because:

1. Adding such concrete implementation recommendations, especially
without any implementation experience or user studies to back them up,
is dangerous. They are likely to get ignored by implementers who will
do what they think best for their product, making the spec less
credible. At the same time, people can wrongly accuse implementers of
ignoring the spec, as Doug rightly pointed out.

2. I have concerns about this solution. There is no expiry interval
magic constant that applies well to all Web applications, while the
user experience of having to repeatedly and for no apparent reason
grant permissions to the same origins is terrible.

Anyway, I would be grateful to know your opinion on this matter.

Many thanks,
Andrei

Received on Tuesday, 2 June 2009 21:36:00 UTC