- From: Thomas Roessler <tlr@w3.org>
- Date: Fri, 5 Jun 2009 18:58:51 +0200
- To: Andrei Popescu <andreip@google.com>
- Cc: Alissa Cooper <acooper@cdt.org>, Doug Turner <doug.turner@gmail.com>, Greg Bolsinga <bolsinga@apple.com>, Rigo Wenning <rigo@w3.org>, public-geolocation <public-geolocation@w3.org>
On 5 Jun 2009, at 18:02, Andrei Popescu wrote: >> The way that the first sentence is constructed suggests that the >> difficulty >> of prediction and prevention is somehow at odds with the fact that >> defensive >> measures are not prescribed by the spec. In fact, the two ideas are >> unrelated (unless I'm missing something). My suggestion would be to >> alter >> the first sentence like so, breaking it into two sentences and >> linking it to >> the third sentence with "however": >> >> Predicting or preventing these situations is inherently >> difficult. Mitigation and in-depth defensive measures are an >> implementation responsibility and not prescribed by this >> specification. However, in designing these measures . . . >> > > Yep, good point. ok with me. >>> 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. >> >> I don't understand how this is any more concrete than the included >> suggestions about user awareness and revocation of permission. >> There are a >> million different ways a UA could limit the scope of >> authorizations, just as >> there are a million different ways to indicate when location is >> shared and >> to provide for permission revocation. Why are the first two >> suggestions >> acceptable but not the third? >> >> > > Revocation of permissions is already discussed in the normative > section. Here we're just saying "please remember to make the UI for > revoking permissions easily accessible". User awareness is pretty > vague, I agree. Perhaps we should replace this entire paragraph with a > link to this thread? There's a lot more info about implementation > suggestions (with pros and cons) on this thread than we could ever > capture in the spec. A link into mailing list archives is not a useful replacement for specification text. I'd be open to see the paragraph extended into a more detailed summary of the key points of this thread.
Received on Friday, 5 June 2009 16:58:59 UTC