Re: Call for proposals for ISSUE-194

In response to Rob's proposal about tying DNT:0 to a "session", from the
Google side we have been doing all we can to get away from the notion of
"sessions" generically (not with respect to DNT but in a broader context).
The notion of "sessions" are becoming increasingly meaningless, especially
on a mobile device where a tab may stay open for a very long time (I've got
100+ tabs open on Chrome on my Android, some of which I may come back to
and some of which I may never come back to). On the desktop (and ChromeOS)
we want to be able to forcefully evict a tab if we get memory pressure (we
already do this on ChromeOS). That looks the same as "closing" the tab and
then reloading it later. Or, if we have an important security update, we
want to be able to silently restart the browser and restore the user's
state. Or, if the user comes back and opens something from "recently closed
tabs" (or chooses "restore the windows I last had open when I start
Chrome") again, is that really a new "session"? From our perspective, the
notion of "sessions" is outdated and holding things back and something
we're actively questioning. I would not expect support for tying anything
to a "session".

Also, I'm not sure why you assume it would be a good user experience for a
user to have to do something on every session. I understand you may prefer
DNT:1, but why should someone have to keep clicking at seemingly random
time intervals just because they prefer DNT:0? 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?

-Ian


On Tue, Apr 30, 2013 at 3:22 AM, Rob van Eijk <rob@blaeu.com> wrote:

>
>
> Hi Matthias,
>
> For me, the goal of ensuring that sites reliably receive valid DNT signals
> is connected with the communication between sites and users. The underlying
> problem for me is the ability to have a granular and valid DNT dialogue
> between a site and a user. The underlying problem is also connected to the
> defaults. My proposal starts with adressing the defaults and continues with
> a technical solution. I conclude with a text proposal.
>
> Two weeks ago, I discussed DNT with DPAs in Prague. The consensus is that
> for DNT to be an effective instrument to provide user control, it is
> crucial that sites can be certain that the DNT signal which they receive is
> a true indication of the user’s wishes. The discussion on the defaults that
> was part of the DAAs proposal that was brought to the table on yesterday's
> call.
>
> The DAA takes the position that DNT would be off by default. I strongly
> advise against this postion. The consensus amoungst DPAs is that in the
> absence of fully informed user choice a site must assume that a user is not
> aware of Web Tracking and therefore assume the default position as if they
> had received a DNT:1 signal, which indicates a wish from the user that this
> user prefers not to be tracked on the target site (TPE section 4.1).
>
> To seperate the noise from the music, the subject of reliably receiving
> valid DNT signals contains an element of trust. Trust can be established by
> creating a chain of identity, in which the level of authentication
> determines the level of trust. As a vehicle for the level of
> authentication, a session key or token can used. The key or token can be
> stored temporarily in the cookie store or HTML5 local storage.
>
> In lign with the imperative of privacy by design, the level of
> authentication must be adequate, relevant and not excessive in relation to
> the purpose. To maintain the level of trust, the expiry of the
> authentication is something to consider. In other words, the lifespan of
> trust is important. For the purpose of the communication between a site and
> a user, I would think the duration of a session is enough. A session is
> proportional to the amounth of time to maintain the level of trust.
>
> What is considered a session is a level of detail we need to discuss
> further. For me there are a few elements that signal the end of a session,
> for example closing a browser, clearing the cookie, clearing the local
> storage, but also closing a browser tab. The latter is a invitation for the
> browser vendors to make expiry transparent to the user.
>
> So in terms of concrete text, I propose the following:
>
> <text proposal>
> In the absence of a validated DNT signal, which indicates a fully informed
> user choice, a site MUST assume that a user is not aware of Web Tracking
> and therefore MUST assume the default position as if they had received a
> DNT:1 signal, which indicates a wish from the user that this user prefers
> not to be tracked on the target site.
>
> Trust MAY be established by creating a chain of identity, in which the
> level of authentication determines the level of trust. As a vehicle for the
> level of authentication, sites MAY use a session key or token. The key or
> token MAY be stored temporarily in for example the cookie store or HTML5
> local storage. The expiry of the key or token MUST be limited, and for a
> minumum MUST expire through automatic deletion when the Browser Tab closes.
> </text proposal>
>
> Looking forward to fruitful discussion at the forthcoming face 2 face,
> Regards,
> Rob
>
>
>
> Matthias Schunter (Intel Corporation) schreef op 2013-04-30 09:38:
>
>  Hi Team,
>>
>>
>>
>> during the last TPE call, we discussed ISSUE-194. One goal of
>> ISSUE-194 is to ensure that sites reliably receive valid DNT signals.
>> Without such a mechanism, there is a risk that a multitude of things
>> spray DNT;1 signals (antivirus, network devices, operating systems,
>> ...; often without user interaction).
>> As a consequence, sites can no longer reasonably by required to
>> listen to those signals.
>>
>> We agreed that separating noise from signals is a valid concern and
>> there were concerns
>> whether there exists any solution that satisfies our goals.
>>
>> If we could reliably distinguish between valid user
>> preferences/choice and noise from other entities on the net,
>> then this allows sites to actually reliably act on user preferences
>> while "D"isregarding the noise.
>>
>> As part of discussing this further, I would like to issue a call for
>> proposals. The question is
>> what mechanisms are envisioned that allow sites to (more) reliably
>> separate noise from preferences.
>>
>> Any proposals (as responses) are welcome. My goal is to then discuss
>> and compare thes proposals
>> to understand whether they help sites with this concern.
>>
>>
>> Regards,
>> matthias
>>
>
>