RE: Towards CR - Feedback / requirements from W3C

>> Anyway, the ability for nested contexts (iframes) to specify exceptions for other domains makes the whole "cookie rules" apparatus redundant in my view.

I agree with this argument.

Rob

-----Original message-----
From: Mike O'Neill
Sent: Tuesday, September 12 2017, 11:54 am
To: 'Matthias Schunter (Intel Corporation)'; 'Roy T. Fielding'
Cc: public-tracking@w3.org
Subject: RE: Towards CR - Feedback / requirements from W3C


I agree with David that DNT without the API is useless, you might as well put the whole recommendation "at risk".  I also agree with Roy that is makes no sense to make the header extensibility  at risk because anything can be extended if the need for new features arises.

If we have to point out a particular feature to be at risk I would go for the "cookie rules" facility in the API (where arbitrary subdomains can be identified in the "site" property. 

It was pointed out in the Last Call comments that this weakens the Same Origin Policy and goes against the grain of recent W3C standards work. It also leads to implementations being more compute heavy than they need to be, because, when deciding what DNT header to send in a particular request, tests have to be made against an indeterminate number of domain components, and the recognition of top-level domain components requires access to an externally curated lookup table. Anyway, the ability for nested  contexts (iframes) to specify exceptions for other domains makes the whole "cookie rules" apparatus redundant in my view.

Mike

-----Original Message-----
From: Matthias Schunter (Intel Corporation) [mailto:mts-std@schunter.org <mailto:mts-std@schunter.org> ] 
Sent: 12 September 2017 09:55
To: Roy T. Fielding <fielding@gbiv.com <mailto:fielding@gbiv.com> >
Cc: public-tracking@w3.org <mailto:public-tracking@w3.org>  (public-tracking@w3.org <mailto:public-tracking@w3.org> ) <public-tracking@w3.org <mailto:public-tracking@w3.org> >
Subject: Re: Towards CR - Feedback / requirements from W3C

Hi Roy,

thanks a lot for the feedback.

When discussing with W3C and David, I (belately) realized that an "all
or nothing" approach (=no features at risk) limits our options and
increases our risk of failure.

Since I do not see an advantage of "all or nothing", I suggested to mark

those two features at risk.

I hope this works for you. If you see a substantial downside of marking
these features at risk, please educate me (either you or anyone else).


Regards,
matthias


On 11.09.2017 21:56, Roy T. Fielding wrote:
>> On Sep 11, 2017, at 9:36 AM, Matthias Schunter (Intel Corporation) <mts-std@schunter.org <mailto:mts-std@schunter.org> > wrote:
>>
>> Dear TPWG,
>>
>> thanks a lot for all then hard work you put into the CR proposal of the
>> TPE.
>>
>> As you know, a CR needs to satisfy certain criteria:
>> - List of features at risk (if any)
>> - Wide review
>> - Implementation reports (test suite as a plus)
>>
>> Despite the fact that most parts are unchanged, the feedback received is
>> that we should preferably repeat these steps and re-compile this package
>> for each subsequent CR release.
>>
>> As a consequence, my suggested next steps are:
>> 1 - We mark two features as at risk (changes to the CR draft):
>>  - Extensibility of the DNT header (unchanged from first CR)
>>  - Exception API (also to emphasize that we need more implementations)
> 
> Why?  We had that discussion on one of the calls and it was felt
> that we did not have any pieces that would be removed prior to REC.
> That is, either the document succeeds as a whole or it should stop
> progression to REC.  The "at risk" category is only for stuff
> that can be removed at REC without going back to the WG.
> 
> I could re-introduce the bits about DNT being extensible at risk,
> but that seems to be a waste of time.
> 
>> 2 - Bert asks again for a wide review (PING, security, Art29,
>> accessibility / internationalization, ...) within 2 weeks.
>> Points to make:
>>  - Exception API has been redesigned
>>  - Otherwise, the spec largely unchanged
>>  - It does not have any user interface (machine2machine)
>>
>> 3 - We call for implementations and implementation reports (also within
>> 2 weeks):
>>  - Mike suggested he should be able to update his implementation
>>  - For the signals, we can re-use existing reports.
>>  - Other implementations of the API?
>>
>> 4- If we receive no blocking feedback in these 2 weeks, we can then
>> submit the full CR package around end of September.
>>
>> If you agree, then no action is required ;-)
> 
> Well, someone has to send mail for (2) and update the wiki page for (3).
> 
> ....Roy
>