Re: ISSUE-187 - some thoughts on using javascript

I would not want to store this in a cookie. As others have pointed out, we
see very high rates of cookie churn already, some of these are explained by
third party tools clearing cookies (which I agree would be "surprising" to
affect DNT exceptions), but there's cookie churn as well that we do not
understand.

As we have discussed at length in the group earlier, we have no interest in
building in UI in the browser around exceptions. To the extent that it's
minimal UI to let users manage granted exceptions, that's something I
believe we can come to terms with, but we do not want to be the one
responsible for infobars and popups appearing all over the web.

As for whether it should be a header or JS API, the notion of making the
request in a header is a bit odd to me. The server has no way to make a
request, only a response. So, you would still have to get the client to
make a request to a given URI that you know would then cause the server to
respond with a set-dnt, and then hope the browser does the right thing.
This may be fine if you're redirecting the user to a confirmation page, but
seems rather limiting. I don't understand the argument against using
JavaScript. It sounds like Walter's argument had nothing to do with
JavaScript (the proposal involving browser-managed UI also used
JavaScript), but rather around whether the browser showed UI or not. The
issue of JavaScript seemed to be a non-sequitor. (Both are
"machine-recognisable" as Walter put it.)

-Ian

On Thu, Nov 8, 2012 at 2:52 PM, Walter van Holst <walter.van.holst@xs4all.nl
> wrote:

> On 11/8/12 9:17 PM, Vinay Goel wrote:
> > Hi Walter,
> >
> > I agree with you that the logical solution would be to store them
> together
> > in the UA preferences.  From what I understand, though, the major UAs
> > would likely not implement this, though.
>
> I probably should have spotted that in the list archives before, but
> have missed it. I cannot speek for the UAs, nonetheless all research on
> user opinions on tracking suggests that they are much more inclined to
> go for a all-out DNT:1 than for DNT:0, which makes me assume that any
> exception mechanism is unlikely to be used often. Sadly not all research
> in this field is publicly available, so we have to make do with what is.
>
> >  So, servers are keen on
> > Adrian's/Ian's latest proposal which removes the dependence on Uas.  I'm
> > operating under the assumption that in order to have UGEs work in
> > practice, we have to remove reliance on the UAs.  Is my assumption not
> > shared amongst others?
>
> Again, cannot speak for the UAs and do understand the conundrum here. I
> can only reiterate my wish for whatever solution chosen by this group to
> be machine-recognisable. I must also stress that I am rather indifferent
> to the question whether we should have an exception mechanism to begin
> with or not. I just happened to notice some potential issues with the
> proposed mechanism as I understood it.
>
> > Also, how can a server detect loss of a previously granted exception?  If
> > a server can detect the loss of a previously granted exception, in your
> > cookie-based approach can the server re-write the exception?
>
> If an exception has been granted, I don't see why a server would not be
> allowed to store the granted exception server-side in order to be able
> to compare it with the UA stored version at a later stage. Rewriting the
> exception would again require the user's consent, since its earlier
> removal is very likely to be caused by withdrawal of earlier given consent.
>
> Regards,
>
>  Walter
>
>