RE: Agenda for Monday Feb 06, 9am Pacific

If we end up disallowing http-equiv making life more difficult for many first-parties we should compensate by allowing variable TSR via a response header embedded TSR URL

 

I just remembered that the same mechanism was used for P3P https://www.w3.org/TR/P3P11/#syntax_ext with the policyref attribute, you must remember the discussion on that Matthias.

 

I think we need to make it easier for (first-party) sites to comply, not put pointless barriers in the way.

 

So I object to dropping the issue till we get to the bottom of http-equiv

 

 

From: Matthias Schunter (Intel Corporation) [mailto:mts-std@schunter.org] 
Sent: 02 February 2017 08:25
To: public-tracking@w3.org (public-tracking@w3.org) <public-tracking@w3.org>
Subject: Agenda for Monday Feb 06, 9am Pacific

 

Hi Folks,

thanks a lot for the lively and productive discussion on the mailing list.
Below info for our call on monday.

BTW: Should we return to weekly calls?

Matthias

 

FINDINGS

- We seem to have found consensus that the Tracking Status resource should remain at the well-known resource.
We should not allow content-owners to ship some TSR-like-information via http-equiv.
The reason was that a TSR at a well-known resource allows to ensure that the server owner is indeed part of the 
DNT support. Please object if you disagree.

 

AGENDA

I propose to discuss the following topics next week:

-----------

0. Should we return to weekly calls?

--------------
1. Should we allow transmission of TK headers within http-equiv. 

PRO reasons I heard: 
- Convenient; 
- May simplify dynamic generation of Tk info along with dynamically generated content; 
- If content includes tracking mechanisms, then the content can also include Tk signal 
CONTRA
- May lead to ambiguities (header vs. http-equiv info) [would require conflict resolution]
- Tracking (unlike CSP) are not a content property. Thus attaching it breaks the logics of server design
- Headers are easy to set for content-owners (once the server owner enabled it).

-------

2. Implementation/Validation Strategy

To reach REQ state, we have to demonstrate implmentation and interoperability.

Question: What is a viable strategy for us.

Proposals I have seen so far:
- Use the existing browser implementations; retrofit the spec
    PRO: No implementation effort
    CONTRA: Minimal spec that we can no longer change (since browser changes are unlikely)
- Use one or more plugins (e.g. Badger and Mike's plugin) and a number of sites.
    PRO: Allows us to evolve our spec
    CONTRA: Implementation effort; We have to double-check that this meets the requirements of W3C.

-------- 

3. Should the Javascript API return promises ?

PRO
- Allows call-back
- More developer friendly; User-agent is notified once call is completed
CONTRA
- Changes the API
- Unclear what the meaning of the callback is.

-----

4. Do we want to change our exception model

Mike to explain what he suggests to change.

------

5. Other issues from our tracker:

https://github.com/w3c/dnt/issues

 

 

UPDATED Webex Info
--
This is a placeholder for the biweekly TPWG Telco.
We agreed to calendar a placeholder and cancel if needed

CHAT: irc.w3.org channel #dnt

PHONE:
12:00 pm  |  Eastern Daylight Time (New York, GMT-04:00)  |  1 hr

Meeting number: 642 521 085 
Meeting password: dnt 
Meeting link: 
   <https://mit.webex.com/mit/j.php?MTID=m1e591a8d322ec7d4989b2dd6fbf11c35> https://mit.webex.com/mit/j.php?MTID=m1e591a8d322ec7d4989b2dd6fbf11c35 
Audio connection: +1-617-324-0000