Tracking Protection Working Group Teleconference

19 Jun 2017

See also: IRC log


dsinger, moneill, fielding, Moneill2, rvaneijk, aleecia, brendan, vincent, wiley
aleecia, brendan


<dsinger> scribenick: aleecia

<Brendan> Brendan can scribe

<dsinger> scribenick: brendan

dsinger - we have 2 things on agenda

Resolution 22

Final CTA

Anything else to discuss?

What to do next?

Yes - Direct to recommendation.

<dsinger> https://lists.w3.org/Archives/Public/public-tracking/2017Jun/thread.html

3 rd topic - what to do next to get to recommendation.

<dsinger> https://lists.w3.org/Archives/Public/public-tracking/2017Jun/0038.html

Dsinger: In the mail you will see 2 copies of the mail from Mattias.

Is there any follow-up to do. General consensus offline seems to be "we can live with it".

Fielding: OK with general direction, but need to make words better

Fielding will take action to massage the language.

Any other editorial comments?

<fielding> yes, that can move to privacy -- the pull request is fine

rvaneijk - section 7 is fingerprinting, should it be moved to privacy?

Dsigner: Consensus. OK, we'll move it.

<wileys> What was just moved to security and privacy considerations? UGEs?

<rvaneijk> @wileys: 7.10 fingerprinting risk

Also we were going to change the API names?

Mike: If we are going to change the names, then we need to have a discussion to take into account the MS implementation.

The only change is confirm, the others were not existing.

If we wanted to add a line of text, the confirm can return the results immediately, to support legacy implementation.

dsinger: Roy, can you do an analysis?

Fielding: it's relatively easy to replace APIs, it's much harder to replace.

Mike: The implementation is different, because it's started at a different time.

Do we have agreement to change names? Fielding: There was discussion on issue tracker, there was consensus to change.

<wileys> With the understanding it breaks the MS IE implementation

dsinger: Roy, make the changes.

Fielding: Draft will be posted with all the changes, so that's cook.

<dsinger> and if there are open technical questions, Roy will raise with the list

dsinger: any other editorial or pending issues?

Aleecia: I don't want to hold up the draft, but there's open issue on "should" vs "may"

Dsinger: which specific issue?

<fielding> https://github.com/w3c/dnt/issues/35

Aleecia: Has submitted text multiple times. This might be it.
... Confirmed, it's issue 35.

6.5.8 "should" provide policy.

<dsinger> Thread starting https://lists.w3.org/Archives/Public/public-tracking/2017May/0022.html

"should inform what changes between DNT 0 and DNT 1"

<wileys> Still stand by MAY as the appropriate path as not legal jurisdictions require this element

<wileys> not “all” legal jurisdictions

<dsinger> sorry, thread starts https://lists.w3.org/Archives/Public/public-tracking/2017Apr/0036.html

Aleecia: I can live with what these as not diff, but prefer requiring diff.

<wileys> It is supposed to be!

dsinger - is UA responsible for UX? I thought it was site.

Aleecia: Agree - it should be site not UA.

<wileys> +q

Fielding: I think that this is non-blocking, discussing it in parallel is fine.

Aleecia: No harm in discussing it now?
... If I'm willing to give up "Should" and go for "May", is that fine?

<dsinger> Shane’s response: https://lists.w3.org/Archives/Public/public-tracking/2017Apr/0040.html

Fielding: I can include that, not in any huge rush.

wileys: Thanks for linking my response. Some is appropriate in California, but rest of the world may differ.

I still side on the "may" instead of "should" to account for varying global legal environments.

Aleectia: I backed off "Must" because of IoT, where there's no UI.

<wileys> This language belongs in a compliance document - not the TPE

Discussion on Informed Consent.

<dsinger> Roy will integrate all of Issue 35 that is editorial; continued discussion of SHOULD vs. MAY

<wileys> Don’t disagree with the discussion - the TPE is just the wrong place for this

wileys: The use of "should" is a compliance decision. It shouldn't be in TPE. The use of "may" is neutral, and enables the scenario in varying jurisdictions.

The technical specification is not where we need to dictate compliance.

Aleecia: Since technical spec is the only one we have, it's the only place we can put it.

<wileys> +q

Mike: Can't see why there's objection to this.

<fielding> I just wanted to say that we could add examples and an explanation of how to use the compliance array.

Fielding: We could add examples on how people can use the compliance array.

The reason for not making it normative is to constrain the space in which compliance would be implemented.

We'd have to agree to one universal standard. This isn't the way of the world.

discussion about examples / best practices.

wileys: we do still have a compliance doc, but we've decided not to go forward with.

dsinger: Wileys - can you make example?

Wileys: Maybe aleecia: Aleecia, you OK with making this examples?

Aleecia: Yeah. I can live with.

Dsigner: Please work to make normative may and non-normative examples?

Wileys: OK with "may" in the normative text, and non-normative examples.

Fielding: It's already possible to include a compliance spec. Anyone can provide a compliance spec.

dsigner: Aleecia, wileys, fielding - put something together?

<wileys> That text should be placed in the compliance and scope document

<dsinger> let’s try changing SHOULD to MAY, leave UX with the site not UA, add an example

Aleecia - I was imagining two changes to text in 35: "should" to "may" and change the party responsible from UA to Site.

<wileys> Attempts to pull C&SD text into the TPE doesn’t make sense

Aleecia: plus add example.

dsigner: while this is redundant, it's probably useful.

<wileys> Examples of how the Compliance array is a great way to go in a technical specification

dsinger: If this is done in a day or so, we can probably include by end of week

dsigner: Make the incantations!

<rvaneijk> from aleecia to everyone: Scribing here, from aleecia to everyone: Roy: ok with general direction but would like to fix working. from aleecia to everyone: David: you'll take the action to polish? from aleecia to everyone: Roy: yes from aleecia to everyone: ... will get that done this week. from aleecia to everyone: David: other things needed before 2nd CR? from aleecia to everyone: Rob: editorial, section on fingering printing could move from section 7.1[CUT]

Aleecia notes:

to be sent via email.

<fielding> Aleecia's notes are are at https://lists.w3.org/Archives/Public/public-tracking/2017Jun/0044.html

<fielding> trackbot, end meeting

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/06/19 16:50:53 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Default Present: dsinger, moneill, fielding, rvaneijk, aleecia, brendan, vincent, wiley
Present: dsinger moneill fielding Moneill2 rvaneijk aleecia brendan vincent wiley
Found ScribeNick: aleecia
WARNING: No scribe lines found matching ScribeNick pattern: <aleecia> ...
Found ScribeNick: brendan
Inferring Scribes: aleecia, brendan
Scribes: aleecia, brendan
ScribeNicks: aleecia, brendan

WARNING: No "Topic:" lines found.

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 19 Jun 2017
Guessing minutes URL: http://www.w3.org/2017/06/19-dnt-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report

[End of scribe.perl diagnostic output]