- From: Rigo Wenning <rigo@w3.org>
- Date: Sun, 05 May 2013 04:41:05 +0200
- To: public-tracking@w3.org, ifette@google.com
- Cc: Rob van Eijk <rob@blaeu.com>, "Matthias Schunter (Intel Corporation)" <mts-std@schunter.org>
Ian, thanks for the remarks. They helped my understanding and I agree that the notion of "session" is getting more and more difficult boundaries. On Friday 03 May 2013 10:16:37 Ian Fette wrote: > Why is it that if you > propose the default is "unset" and the user makes an affirmative > choice for DNT0/1, that one choice would have to be re-affirmed on a > session basis whereas the other choice would persist? I think the issue Rob is addressing is the same as with the location engine. Especially on mobile, it is extremely useful to be able to locate yourself and ask for surrounding services and restaurants and the like. (an ideal advertisement situation, if used responsibly). We had a wild discussion in the Geolocation API WG about what geolocation meant for privacy. Initially, the device people wanted to only provide ONE question for a service asking for your location. Then, the interface would never bother again. But a user may use location based services on the go and does not remember that she has given permission. Coming back in a different context, she is not asked anymore and the location is just given and shared. This is why the ePrivacy Directive requires a beacon when geolocation is active. Despite me failing to impose this on the geolocation API Specification, that's what modern phones implement. The same could be true for DNT. Just some uninvasive sign somewhere. Nobody wants to ask back all the time. But a device with an interface to the user could probably be more informative than just asking once and then bury everything in 7 levels of menus. Given that innovation happens in the interface, I would not argue for a MUST or SHOULD, rather some non normative considerations that explain further that DNT must be an informed decision of the user (I always said that this cuts both ways) --Rigo
Received on Sunday, 5 May 2013 02:41:46 UTC