- From: イアンフェッティ <ifette@google.com>
- Date: Mon, 30 Apr 2012 14:22:20 -0700
- To: Jonathan Mayer <jmayer@stanford.edu>
- Cc: Nicholas Doty <npdoty@w3.org>, Rigo Wenning <rigo@w3.org>, public-tracking@w3.org
- Message-ID: <CAF4kx8ftHFLuK58g6w+akf1sGabDgTyFoqb-EO=vF4xAC1PK3g@mail.gmail.com>
As a website operator, your proposal adds even more complexity to the mix. This is not a good idea. On Mon, Apr 30, 2012 at 1:55 PM, Jonathan Mayer <jmayer@stanford.edu> wrote: > As best I can tell, here's the current state of the debate: Some working > group participants believe there are important use cases for > explicit-explicit exceptions, others do not. Some browser vendors are > willing to implement support for explicit-explicit exception pairs, at > least one is not. > > Given that background, how's this as a compromise: We make support for the > various exception types optional for browsers, and we include some ability > for a website to learn which exception types are supported by a browser. A > website isn't left guessing how a browser will interpret its exception > requests, and a browser vendor is free to pass on the exception types that > it doesn't believe it can provide a good user interface for. > > One approach would be to include simple flags that indicate support (e.g. > booleans like navigator.supportsWebWideExceptions). Another approach would > be to modify the TrackingResponseCallback to handle a not-supported state. > If a website learns the browser doesn't support its preferred exception > type, it can fall back to a different exception type or an out-of-band > exception. > > On Monday, April 30, 2012 at 9:37 AM, Ian Fette (イアンフェッティ) wrote: > > I'm a bit perplexed as to the fact that you think a UI such as the one you > describe would actually be compliant. I thought the whole point of this > exercise was to allow the user to express a preference and translate that > as directly as possible to something that can be passed on to websites they > visit. > > If you start picking and choosing from the API as if it were a buffet, > where does that leave you? You seem to imply it's fine for a UA to ignore > the explicit nature of a "first/third" exception and turn it into a > "first/*". Would it be equally fine then to just ignore the distinction > between "first/*" and "*/third" and just offer "site" exception regardless > of first/third issues? Or just to ignore exceptions all together and say > "Eeh, it's a UI issue, if the site grants an exception to anything we'll > just turn off DNT globally." > > I think what is being proposed is unworkable and people are trying to use > the notion that it's "just a UI issue" to keep it in the spec. This is not > a good idea. > > As for the new corner cases, I think many of us are expecting that there > will be new regulatory considerations (either under existing or future > regulatory regimes) that will involve DNT. Whenever there are new > considerations, there are new corner cases. For instance, cookie blocking > doesn't actually send any explicit signal to the server, nor does the > server have any clue as to what the heck is actually going on. Now we're > giving servers a clue, hence there's much more complex considerations. > > -Ian > > On Mon, Apr 30, 2012 at 12:24 AM, Nicholas Doty <npdoty@w3.org> wrote: > > On Apr 25, 2012, at 8:21 AM, Ian Fette (イアンフェッティ) wrote: > > > Also, I don't think we should just punt something by saying "It's a UI > issue." The spec has implications on UI that should not be ignored. > explicit/explicit means we have to come up with UI to support this, where > so far we have failed, it means sites now have to worry about corner cases > they didn't before, etc. > > I agree with Rigo that this is a UI issue in the sense that user agent > developers are completely free to decide whether or not to create what kind > of UI they want. (We were able to discuss this confusion in DC, but only > briefly, so I'll try to recap.) If Google Chrome decides that its users > never want or need to see a list of domains, even when a site requests > exceptions for a specific list, Chrome need not present any such UI; the > browser can just display whatever UI the Chrome team creates for a > site-wide exception and the team doesn't have to come up with any other UI. > The browser also may choose not to store the list version of the > permissions but just store a site-wide permission, or not to store the > permission at all, the spec explicitly leaves all of these choices up to > the user agent implementation. (Section 6.5 lists several other UI > decisions that are also completely up to the user agent developer.) I > expect user agent UIs to vary -- some browsers will use a simple built-in > UI to avoid burdening their users; a developer of plugins for particularly > privacy-conscious users might build a more complex configuration panel. > Vive la différence. > > What are the corner cases that sites have to worry about that they didn't > before? In the current self-regulatory opt-out cookie system the publishing > site never gets an indication of whether one of its advertisers received an > opt-out signal (unless it communicates on the server side) and the site may > have a mix of advertisers that received opt-out cookies or not. Sites that > only wish to ask for site-wide exceptions can always call > requestSiteSpecificTrackingException with the "*" parameter; that some > unrelated sites specify a list of origins in the parameter need not affect > them. Of course, even sites that always use "*" may still receive visitors > where some of their parties receive DNT:0 and others receive DNT:1, but > that situation will exist whether the JavaScript API takes a list parameter > or not. > > Hope this helps, > Nick > > > >
Received on Monday, 30 April 2012 21:22:50 UTC