- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Sat, 09 Jun 2012 01:12:42 +0200
- To: Shane Wiley <wileys@yahoo-inc.com>
- Cc: "ifette@google.com" <ifette@google.com>, "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
* Shane Wiley wrote: >That is the sticking point here. The standard is voluntary but we still >want a large majority of 3rd parties to implement DNT. If we require >that supporting W3C DNT also requires accepting non-compliant UA >signals, I can't see a reason why many, if any, 3rd parties would >implement. If we're setting up a "failed start", then I'm at a loss for >our path as a Working Group. I think the DNT specifications need to say that the DNT signals can and must be taken at face value, including the absence of such signals. If you start with the second guessing, you will have to answer questions why you exercise or reserve the right to second guess in one case but not in some other case, and that will lead to pain and suffering. I do not think there will be notable cases where user agents send non- compliant DNT signals under normal circumstances; the user agent vendor will rather argue that they are compliant, while others dispute that, and there is currently no proposed mechanism to resolve that dispute. It is possible that platform and browser vendors would be willing to subject themself to some veto mechanism where they won't ship or revise their user interfaces if tracking organizations do not like their user interface decisions, which would resolve such disputes, but that's very much out of scope of this Working Group as chartered, and not so likely. I note that Internet Explorer 9 for instance will prompt users on first use whether they accept, or not, or want to decide later, whether to use the "recommended" security and compatibility settings. If Firefox had a similar prompt and would throw in a DNT:1 recommendation in the dialog, there would be similar complaints, even though I would find that in com- pliance with any specification the Working Group could come up given its limitations on making user experience requirements. I do not think there is a big difference between that kind of prompt and an outright default. Similarily, in the longer term, I would expect that platform, read: operating systems, vendors will allow users to make more "bundled" privacy decisions, like to turn on DNT for browsers and "apps" running on the system. Someone feeling strongly about "privacy" may want a general OS-level prompt they can use so applications stop asking them if they are okay with sending crash reports, stop offering to particpate in UI studies, stop storing their Wifi passwords in the cloud, and so on and such a setting may similarily turn on DNT in the platform's browser. The Working Group as currently chartered cannot make that obviously non- compliant, so I see non-compliant DNT signals as a red herring for this Working Group. As above, it would be better to simply define that DNT:1 is, by definition, the user's preference, and tracking organizations are better off opposing DNT altogether if browser vendors make unreasonable user interface decisions where DNT signals don't reflect user decisions. There will be a Candidate Recommendation phase where the W3C calls for implementations of the DNT proposals and the Working Group will evaluate browser and "website" implementations of it, and compliance disputes, as they are known by then, can be resolved, or not, at that point. That'd be a better point to argue about possibly needed "escape clauses". As I said earlier, if the Working Group cannot agree that "no means no", it is unlikely that there will be a Recommendation; and I've listed some of the options there are to turn "no means no" into "it's complicated". As for the specific issue of a mainstream browser that is pre-installed on a very large number of systems sending some DNT signal "by default", well, if the vendor doesn't mind to say that it's a default (as opposed to saying that users typically choose this browser explicitly because it's known to offer "strong privacy protections" or whatever), require them to make that explicit in the header and API. Let them send "DNT:23" until users "manually" confirm this default. That gets you around "users cannot activate DNT:1 explicitly in this browser" issue, and "browser sniffing" issues, and would give services that honour "do not track" in all cases an advantage over services that ignore "DNT:23" signals, pro- vided they don't fall into the same conformance class (they should not). -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Received on Friday, 8 June 2012 23:13:09 UTC