Agenda for 09 Jan 2013 TPE call - V01

Hi Team,

Happy New Year and welcome to our first call in 2013!

I hope you enjoyed your vacation and are now full of energy to finalize 
our DNT efforts.

Below is my V01 proposal for tomorrow's call with a focus on TPE. I am 
aware that we are unlikely to address all 10 items on this agenda.
Let's start from the top and see how far we get.



1. Peter plans to suggest a scribe

2. Offline-caller-identification (NEW):
If you intend to join the phone call, you must either associate your 
phone number with your IRC username once you've joined the call 
(command: "Zakim, [ID] is [name]" e.g., "Zakim, ??P19 is schunter" in my 
case), or let Nick know your phone number ahead of time. If you are not 
comfortable with the Zakim IRC syntax for associating your phone number, 
please email your name and phone number to by 8am PT 
tomorrow. We want to reduce (in fact, eliminate) the time spent on the 
call identifying phone numbers. Note that if your number is not 
identified and you do not respond to off-the-phone reminders via IRC, 
you will be dropped from the call.

3. Next steps for Compliance (20min; Peter)

Peter would like to spend 15 minutes for discussion of next steps on the 
compliance spec.
- We will discuss the technical meeting on de-identification in DC on 
January 17,
    as well as the possibility of a follow-up tech meeting in Brussels, 
perhaps on January 25.
- We will discuss how to handle the pending actions for the compliance spec

Old business

4. Review of overdue action items: 

5. Revised approach to Exceptions

David has introduced proposed text into our spec that reflects our draft 
new approach to exceptions:

- Feedback on the draft
- David Singer: I think there is a clearly missing API (or rather, pair 
thereof).  Though a site can ask "what DNT header would I get in the 
current context?" it cannot currently ask "does this exception that I 
previously requested still exist?".  That's clearly needed to guide its 
behavior (e.g. it might go to a page expressing its sadness and 

6. ISSUE-190: Multiple First Parties on a Site
Proposed text:

If we agree on the approach proposed by Roy, I would ask him to 
implement the corresponding changes in the text.

7 Updates to our JS Script API

Related message:
In this message, Nick proposed changes to our Javascript API
1. - Move JS doNotTrack property to window (from navigator)
2. - remove the requestDNTStatus( ) since it seems redundand

I suggest (a) to implement these changes and (b) to discuss what 
additional APIs are needed.
For (b), David proposed argued that two new APIs are needed:
   -  "does <this> site-exception still stand?"
    - "does <this> web-wide exception still stand?"
If we agree on those two APIs, I would suggest that Nick/David propose 
text to spec these changes

8. Service Providers

David Singer has summarised suggested behavior for service providers 
below. I would like to
introduce this text into the spec and/or gather feedback.

"I think the basic discussion is in
and the redux in

The summary:
-- use the same-party resource for sites that are truly in the same 
party, or appear uniquely associated with only one party; (we don't need being the same as both and, which 
would suggest boeing and airbus are the same party);

-- if you operate under a service contract, then you're under the 
privacy policy of the organization you're providing service to; your 
policy link in the well-known resource should be a URL that identifies 
both that organization's site and its policy (the URL may then, of 
course, re-direct if needed); (note that sharing a privacy policy might 
occur under other circumstances, e.g. if an organization like creative 
commons publishes some easy-to-use ones) [the adobe case]

-- if you are concerned that users/user-agents might see you claiming 
1st party or consent status when you don't appear to have it, because 
the organization you are servicing does, set the service-provider 
qualifier (in the response and/or well-known-resource, as appropriate); 
the 'policy' link then should show who you provide service to (as above)


- Agree on adding the proposed text (or create action for writing 
alternative text)

ISSUE-113: How to handle sub-domains (ISSUE-112)?

On these issues IMHO the status is as follows:
- If a site-wide exception is requested, all subdomains are 
automatically included
- This issue is only relevant for explicit/explicit lists of domains (if 
the site uses them)
- An original proposal (from Ian) used cookie-like handling
- There is a need for wildcards (see note from David Wainberg)
    and if we agree that wildcards are useful, we should discuss the "how".

10. ISSUES marked OPEN

Goal: review open issues at
and assign actions to them

ISSUE-164: Should the 'same-party' attribute be mandatory?

My understanding of the minutes is that we agreed in Amsterdam:
- keep a MAY (optional)
- Say that if a site that loads additional content "to be used in 1st 
party context" (flag: 1)
    from other domains, this content may not work properly unless this 
domain is desclared as "same-party"
- If this approach is still OK, I suggest to create an action to textify it.

11. Announce next meeting & adjourn
================ Infrastructure =================

Zakim teleconference bridge:
Phone +1.617.761.6200 passcode TRACK (87225)
IRC Chat: <>, port 6665, #dnt


Received on Tuesday, 8 January 2013 16:02:27 UTC