W3C home > Mailing lists > Public > public-tracking@w3.org > November 2012

action-325: Help re-factor into appendices

From: Nicholas Doty <npdoty@w3.org>
Date: Tue, 6 Nov 2012 22:28:46 -0800
Message-Id: <AAB632F1-6AD9-4EA1-9654-F5CBBF4B5288@w3.org>
Cc: Justin Brookman <Justin@cdt.org>, Heather West <heatherwest@google.com>, Jonathan Mayer <jmayer@stanford.edu>
To: "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
I volunteered to draft a version of the Compliance document where some of the non-normative sections could be refactored into appendices, something that has been requested a few times, and is tracked by issue-175.

My proposal is that we start with an appendix for "Privacy Preserving Techniques" and use that appendix to store any text that just provides a non-normative description of one technology or technique for accomplishing the high-level goals that we tend to use in our compliance requirements. This creates an appendix that looks like the following:

Appendix A: Privacy-Preserving Techniques
(TOC numbers from their existing locations.)
3.4.1.3 Technical Precautions
   3.4.1.3.1 Siloing in the Browser
       3.4.1.3.1.1 Same-Origin Policy
       3.4.1.3.1.2 Cookie Path Attribute
       3.4.1.3.1.3 Storage Key
   3.4.1.3.2 Siloing in the Backend
       3.4.1.3.2.1 Encryption Keys
       3.4.1.3.2.2 Access Controls
       3.4.1.3.2.3 Access Monitoring
   3.4.1.3.3 Retention in the Backend
3.4.1.4.1 Internal Practices
   3.4.1.4.1.1 Policy
   3.4.1.4.1.2 Training
   3.4.1.4.1.3 Supervision and Reporting
   3.4.1.4.1.4 Auditing

I think we could profitably write up an explanation of k-anonymity to go into this section, perhaps as one way to handling the unlinkability debate. Shane had also suggested some techniques for hashing for frequency capping, which could also end up here.

I've attached a diff and the resulting HTML file in case the group wants to inspect how this looks. I'm not sure the editors or authors of these sections support moving these pieces around right now, though. I'm fine either way, but if the group/editors decide that we should refrain from refactoring the document until more options have been closed out, then I would suggest that we POSTPONE issue-175 until such time that the editors think it would be useful.

Thanks,
Nick






Received on Wednesday, 7 November 2012 06:30:27 UTC

This archive was generated by hypermail 2.3.1 : Friday, 21 June 2013 10:11:38 UTC