- From: Mike O'Neill <michael.oneill@baycloud.com>
- Date: Wed, 13 Sep 2017 17:16:19 +0100
- To: <singer@apple.com>, "'Roy T. Fielding'" <fielding@gbiv.com>, "'Matthias Schunter \(Intel Corporation\)'" <mts-std@schunter.org>
- Cc: <public-tracking@w3.org>
- Message-ID: <20d701d32cab$a2623050$e72690f0$@baycloud.com>
The tables got mangled, here they are as word documents. Mike From: Mike O'Neill [mailto:michael.oneill@baycloud.com] Sent: 13 September 2017 16:14 To: singer@apple.com; 'Roy T. Fielding' <fielding@gbiv.com>; 'Matthias Schunter (Intel Corporation)' <mts-std@schunter.org> Cc: public-tracking@w3.org Subject: RE: Towards CR - Feedback / requirements from W3C There is a test page at <https://baycloud.com/api/test> https://baycloud.com/api/test that now uses the new API. It has been there since 2015 but supported the old API. Bouncer ( <https://baycloud.com/bouncerDownload> https://baycloud.com/bouncerDownload) now supports the new API I think, but the test matrix needs extending, i.e. new tests for subresources calling the store API. The tests rely on servers for 2 other domains echoing back the value of the DNT header in a JSON response (to an XHR), so that the test page can check site specific exceptions are working. The server used responds to domain1.cookieq.com & domain2.cookieq.com. The controller for them support CORS in “anything goes” mode. In the test matrix below “topdomain” would be “baycloud.com”, “domain1” would be “domain1.cookieq.com” and “domain2” would be “domain2.cookieq.com” After the tests are extended and they all work on Bouncer I will post the html file to Web Platform Tests. The test matrix currently is as follows: Test Description targets site isSiteWide DNT topdomain DNT domain1 DNT domain2 1 DNT header value? 1 1 1 2 navigator.doNotTrack exists? 1 1 1 3 Consent API exists? 1 1 1 4 confirm TRUE after 1st party webwide store null "*" 0 1 1 5 1st party navigator.doNotTrack value == 0 0 1 1 6 Check 1st party DNT = 0 0 1 1 7 confirm FALSE after 1st party webwide remove 1 1 1 8 Check 1st party DNT = 1 1 1 1 9 Site-specific store 1st party site-wide null null true 0 0 0 10 Site-specific remove 1st party site-wide null null 1 1 1 11 Site-specific store 1st party only (not site-wide) empty null false 0 1 1 12 Site-specific store domain1 AND 1st party maxAge=10secs ["domain1", "topdomain"] null false 0 0 1 13 DNT domain1 still 0 after 5 seconds 0 0 1 14 DNT domain1 1 after 10 seconds 1 1 1 Bouncer never sets “isSiteWide” true unless “targets” is null or undefined. There should be a few more tests, below are some I think necessary, please suggest others. Questions for Roy/David: does the API now support incremental site-specific UGEs? Can the remove call remove particular ones? Is the matrix correct? new tests Test Description targets site isSiteWide DNT topdomain DNT domain1 DNT domain2 15 Site-specific store domain2 only ["domain2"] null false 1 1 0 16 Site-specific store domain1 only ["domain1"] null false 1 0 0 17 Site-specific remove domain1 ["domain1"] null 1 1 0 18 Site-specific store domain1, domain2 ["domain1", "domain2"] null false 1 1 0 19 Webwide/site-specific store in iframes? Mike -----Original Message----- From: singer@apple.com <mailto:singer@apple.com> [mailto:singer@apple.com] Sent: 12 September 2017 22:05 To: Matthias Schunter (Intel Corporation) <mts-std@schunter.org <mailto:mts-std@schunter.org> > Cc: Roy T. Fielding <fielding@gbiv.com <mailto:fielding@gbiv.com> >; 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> >; Mike O'Neill <michael.oneill@baycloud.com <mailto:michael.oneill@baycloud.com> > Subject: Re: Towards CR - Feedback / requirements from W3C So concretely we state in the CR request that we wish to see the whole spec. move to PR or stay integral but in CR; there are no features we would remove piece by piece due to lack of implementation. Since we’re not marking any features as at-risk, we removed that marking for DNT-extension from the previous CR, and though the API design is brand new we didn’t mark it either; and instead the whole spec. should be considered at-risk of being stuck in CR indefinitely. I think this works; Bert should check with the process mavens in the team, I think. Not sure what they will want in the status-of-this-document... Which leaves just wide-review and the technical questions Mike has raised… > On Sep 12, 2017, at 12:14 , David Singer <singer@mac.com <mailto:singer@mac.com> > wrote: > > >> On Sep 12, 2017, at 2:53 , Mike O'Neill <michael.oneill@baycloud.com <mailto:michael.oneill@baycloud.com> > wrote: >> >> 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. > > I think the alternative to marking features at-risk through lack of tested implementations (no test suite suite, few implementations) would be to say in the CR transition request that the whole spec. is at risk of being stuck in CR indefinitely. My guess is that the WG agrees with Mike here, that it’s not worth removing features from the spec. > > I’d be fine with this as well; I’m checking on whether this meets the process requirements (but Bert could check with the team). > >> >> 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] >> 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 >>> >> >> >> > > Dave Singer > > singer@mac.com <mailto:singer@mac.com> > > David Singer Manager, Software Standards, Apple Inc.
Attachments
- application/vnd.openxmlformats-officedocument.wordprocessingml.document attachment: testmatrix.docx
Received on Wednesday, 13 September 2017 16:17:19 UTC