Re: Additional security and privacy considerations?

Hi Thomas,

On Wed, May 20, 2009 at 11:40 AM, Thomas Roessler <tlr@w3.org> wrote:
> So, that brings up a deeper point.  My reading was that the current security
> and privacy considerations are essentially non-normative --

Oh, I see. The privacy section is normative.

> they certainly read like they are.

Ok, can you please explain why do you think they read like they are
non-normative?

> I know that that's causing dismay in some quarters (and
> I'm not particularly happy with it, either), but I'd be willing to support
> non-normative looking considerations of the kind we now have, provided they
> lead to clearer and more strongly worded recommendations than what one would
> get out of normative ones.

To be clear, the current privacy section already is normative. The
group considered the option of making it non-normative and decided
against it.

>  If, however, we're now going through the
> wordsmithing that would be applied to normative recommendations, then we can
> as well make clear that the privacy considerations are normative.
>

But the "conformance requirements" section clearly states that

"All diagrams, examples, and notes in this specification are
non-normative, as are all sections explicitly marked non-normative.
Everything else in this specification is normative."

So it is therefore clear that the privacy section is normative. But I
am happy to emphasize this aspect if you still think it is needed. Do
you have a suggestion for this?

> As far as usability studies are concerned, the underlaying question here is
> what the goal of the indicator is.  The goal that I have in mind is: "Users
> must be able to tell when location is shared." That goal is different from
> "users must be aware that location is shared at all times" -- even though
> I'd certainly prefer if we could achieve the latter one.  If you don't
> achieve the former one, though, you're basically asking for trouble on the
> policy side of things.
>

Well, what really matters is for us to have a clear set of privacy
protection requirements for API implementers and recipients of
location information. Asking for user consent and offering the
possibility for users to revoke permissions are basic requirements
that are meant to put the user in control of how their location is
made available. However, a goal such as "Users must be able to tell
when location is shared", well-intended as it may sound, would need to
be tested to prove its real benefits. This is why I am proposing that
we add it as a non-normative suggestion, at least until some evidence
is produced to prove its value. Having it as a non-normative
suggestion will encourage implementers to explore it but will not
force them to stick to it if it doesn't work or, as Hixie said, they
find some better solution.

>>> 2. When location information is passed to a web application, a user
>>> interface for revoking the relevant permissions must be easily and obviously
>>> available.
>
>> Again, since we cannot define what is meant by "easily and obviously
>> available", I feel that this requirement is not really useful.
>
> A different way to say it would be "the revocation mechanism must actually
> be credible, and it mustn't be put into the UI equivalent of the local
> planning council on Alpha Centauri".  But that isn't useful specification
> language -- so, take this as a challenge to come up with better wording.
>

I understand. I don't have a better alternative at the moment.

>>> 3. User agents should limit the scope of authorizations in time by asking
>>> for re-authorization in certain intervals.  As a general guideline,
>>> authorizations related to location information should not be considered
>>> valid for more than one week. Often, a shorter time will be appropriate.
>
>> Ok, I agree with the "User agents should limit the scope of
>> authorizations in time by asking for re-authorization in certain
>> intervals" part.  But why exactly would the guideline say one week and
>> not some other period? Again, I think we should refrain from
>> suggesting such magic constants in the absence of any usability
>> studies or implementation experience that would demonstrate their
>> validity.
>
> I'm not feeling too strongly about this point -- as you say, any magic
> constant will have problems (hence "general guideline" and "should"); the
> goal was to draw a line somewhere, so people don't say "oh, 2000 years are a
> perfectly limited scope."  In other words, we probably know what is totally
> unreasonable, but we don't quite know where precisely the border sits.
>

Right, so perhaps we could just live without giving a concrete number?
Since this is a "should", those UA who will implement it will also
have a sensible limit?

>>> </add>
>>>
>>>> Some User Agents will have prearranged trust relationships that do not
>>>> require such user interfaces. For example, a Web browser will present a user
>>>> interface when a Web site performs a geolocation request. However, a VOIP
>>>> telephone may not present any user interface when using location information
>>>> to perform an E911 function.
>>>
>>> Additional points:
>>>
>>> - Add: "In some circumstances, use of sensor data (GPS, wireless
>>> networks, GSM/CDMA cell information) to acquire location data might be
>>> inappropriate.  Conforming implementations of this specifications may use
>>> other mechanisms to acquire location data, including prompting users for
>>> location data that is then made available through the API specified here."
>>>
>>
>> I'm sorry, I don't really follow. The API is meant to be agnostic wrt
>> to the sources of location data. What purpose would the above wording
>> serve?
>
> Reading this again, it's probably phrased in a way that obscures the actual
> point.  That point being: "The API is agnostic. The location source may be
> unreliable. Don't assume that you're always told the truth by this API."
>
> The goal here is to make clear to anybody who cares to read the
> documentation that, e.g., prompting users to give location information (in
> other words, giving them the opportunity to lie about where they are) is
> totally acceptable.  Yes, that is implicit in the API's being agnostic to
> location sources, but I think it's worth calling out.
>

Ok, I thought it's pretty clear already but perhaps it isn't. The
"Introduction" section says:

"The API itself is agnostic of the underlying location information
sources. Common sources of location information include Global
Positioning System (GPS) and location inferred from network signals
such as IP address, RFID, WiFi and Bluetooth MAC addresses, and
GSM/CDMA cell IDs."

We can add to the above paragraph that asking the user is another
example of a source of location? We can also say that the location
information is not necessarily guaranteed to be correct. Can you
suggest a sentence to this effect?

All the best,
Andrei

Received on Thursday, 21 May 2009 20:23:01 UTC