Index: drafts/tracking-compliance.html
===================================================================
RCS file: /w3ccvs/WWW/2011/tracking-protection/drafts/tracking-compliance.html,v
retrieving revision 1.86
diff -r1.86 tracking-compliance.html
460d459
< 
478a478
>           <p>Explanations of some techniques that may satisfy these requirements are documented in the <a href="#techniques-precautions">Technical Precautions</a> section of the appendix.</p>
480,586d479
< 
<         <section class="informative">
<           <h2>Non-Normative Discussion</h2>
< 
<           <section>
<             <h3>Siloing in the Browser</h3>
< 
<             <p>
<               Outsourcing services should use browser access control features
<               so that stored data specific to one party is never accessed or
<               collected when the user visits another party.
<             </p>
< 
<             <section>
<               <h4>Same-Origin Policy</h4>
< 
<               <p>
<                 The same-origin policy silos stored data by domain name. An
<                 outsourcing service can use a different domain name for each
<                 first party.
<               </p>
<               <pre class="example">
<         Example Analytics provides an outsourced analytics service to Example News
<         and Example Sports, two unrelated websites. Example Analytics stores its
<         cookies for Example News at examplenews.exampleanalytics.com, and it
<         stores its cookies for Example Sports at
<         examplesports.exampleanalytics.com.
< </pre>
<             </section><!-- closes same origin policy, h4 -->
< 
<             <section>
<               <h4>Cookie Path Attribute</h4>
< 
<               <p>
<                 The HTTP cookie path can be used to silo data to a first
<                 party.
<               </p>
<               <pre class="example">
<         Example Analytics stores its cookies for Example News with
<         "Path=/examplenews", and it stores its cookies for Example Sports with
<         "Path=/examplesports".  
< </pre>
<             </section><!-- closes cookie path attribute, h4 -->
< 
<             <section>
<               <h4>Storage Key</h4>
< 
<               <p>
<                 For key/value storage APIs, such as Web Storage and Indexed
<                 Database, an outsourcing service can use a different key or
<                 key prefix for each first party.
<               </p>
<               <pre class="example">
<         Example Analytics stores data for Example News at
<         window.localStorage["examplenews"] and data for Example Sports at
<         window.localStorage["examplesports"].
< </pre>
<             </section><!-- closes storage key, h4 -->
<           </section><!-- closes siloing in the browser, h3 -->
< 
<           <section>
<             <h3>Siloing in the Backend</h3>
< 
<             <section>
<               <h4>Encryption Keys</h4>
< 
<               <p>
<                 An outsourcing service should encrypt each <a>first
<                 party</a>'s data with a different set of keys.
<               </p>
<             </section><!-- closes encryption keys, h4 -->
< 
<             <section>
<               <h4>Access Controls</h4>
< 
<               <p>
<                 An outsourcing service should deploy access controls so that
<                 only authorized personnel are able to access siloed data, and
<                 only for authorized purposes.
<               </p>
<             </section><!-- closes access controls, h4 -->
< 
<             <section>
<               <h4>Access Monitoring</h4>
< 
<               <p>
<                 An outsourcing service should deploy access monitoring
<                 mechanisms to detect improper use of siloed data.
<               </p>
<             </section><!-- closes access monitoring, h4 -->
<           </section><!-- closes siloing in the Backend, h3 -->
< 
<           <section>
<             <h3>Retention in the Backend</h3>
< 
<             <p>
<               An outsourcing service should <a>retain</a> information only so
<               long as necessary to provide necessary functionality to a first
<               party. If a service creates periodic reports, for example, it
<               should delete the data used for a report once it is generated.
<               An outsourcing service should be particularly sensitive to
<               retaining protocol logs, since they may allow correlating user
<               activity across multiple first parties.
<             </p>
<           </section><!-- closes retention in the backend, h3 -->
<         </section><!-- closes Non-Normative Discussion, h2 -->
< 
595,641c488
< 
<           <section class="informative">
<             <!-- Unclear whether this non-norm tagging works, may need to fix -->
< 
<             <h3>Non-Normative Discussion</h3>
< 
<             <section>
<               <h4>Policy</h4>
< 
<               <p>
<                 An outsourcing service should establish a clear internal
<                 policy that gives guidance on how to <a>collect</a>,
<                 <a>retain</a>, and <a>use</a> outsourced data in compliance
<                 with this standard.
<               </p>
<             </section><!-- closes policy, h4 -->
< 
<             <section>
<               <h4>Training</h4>
< 
<               <p>
<                 Personnel that interact with outsourced data should be
<                 familiarized with internal policy on compliance with this
<                 standard.
<               </p>
<             </section><!-- closes Training, h4 -->
< 
<             <section>
<               <h4>Supervision and Reporting</h4>
< 
<               <p>
<                 An outsourcing service should establish a supervision and
<                 reporting structure for detecting improper access.
<               </p>
<             </section><!-- closes supervision and reporting, h4 -->
< 
<             <section>
<               <h4>Auditing</h4>
< 
<               <p>
<                 External auditors should periodically examine an outsourcing
<                 service to assess whether it is in compliance with this
<                 standard and has adopted best practices. Auditor reports
<                 should be made available to the public.
<               </p>
<             </section><!-- closes auditing, h4 -->
<           </section><!-- closes non-normative discussion, h3 -->
---
>           <p>Explanations of some techniques that may satisfy these requirements are documented in the <a href="#techniques-internal">Internal Practices</a> section of the appendix.</p>
1728c1575
< 		  <p=note>There is an open action to define "graduated response," and an open
---
> 		  <p class="note">There is an open action to define "graduated response," and an open
1730c1577
< 		  addressed through non-normative examples</p>
---
> 		  addressed through non-normative examples.</p>
2017a1865,2018
>   <section id="techniques" class="appendix">
>       <h2>Privacy Preserving Techniques</h2>
>       
>               <section class="informative" id="techniques-precautions">
>                 <h2>Technical Precautions</h2>
> 
>                 <section>
>                   <h3>Siloing in the Browser</h3>
> 
>                   <p>
>                     Outsourcing services should use browser access control features
>                     so that stored data specific to one party is never accessed or
>                     collected when the user visits another party.
>                   </p>
> 
>                   <section>
>                     <h4>Same-Origin Policy</h4>
> 
>                     <p>
>                       The same-origin policy silos stored data by domain name. An
>                       outsourcing service can use a different domain name for each
>                       first party.
>                     </p>
>                     <pre class="example">
>               Example Analytics provides an outsourced analytics service to Example News
>               and Example Sports, two unrelated websites. Example Analytics stores its
>               cookies for Example News at examplenews.exampleanalytics.com, and it
>               stores its cookies for Example Sports at
>               examplesports.exampleanalytics.com.
>       </pre>
>                   </section><!-- closes same origin policy, h4 -->
> 
>                   <section>
>                     <h4>Cookie Path Attribute</h4>
> 
>                     <p>
>                       The HTTP cookie path can be used to silo data to a first
>                       party.
>                     </p>
>                     <pre class="example">
>               Example Analytics stores its cookies for Example News with
>               "Path=/examplenews", and it stores its cookies for Example Sports with
>               "Path=/examplesports".  
>       </pre>
>                   </section><!-- closes cookie path attribute, h4 -->
> 
>                   <section>
>                     <h4>Storage Key</h4>
> 
>                     <p>
>                       For key/value storage APIs, such as Web Storage and Indexed
>                       Database, an outsourcing service can use a different key or
>                       key prefix for each first party.
>                     </p>
>                     <pre class="example">
>               Example Analytics stores data for Example News at
>               window.localStorage["examplenews"] and data for Example Sports at
>               window.localStorage["examplesports"].
>       </pre>
>                   </section><!-- closes storage key, h4 -->
>                 </section><!-- closes siloing in the browser, h3 -->
> 
>                 <section>
>                   <h3>Siloing in the Backend</h3>
> 
>                   <section>
>                     <h4>Encryption Keys</h4>
> 
>                     <p>
>                       An outsourcing service should encrypt each <a>first
>                       party</a>'s data with a different set of keys.
>                     </p>
>                   </section><!-- closes encryption keys, h4 -->
> 
>                   <section>
>                     <h4>Access Controls</h4>
> 
>                     <p>
>                       An outsourcing service should deploy access controls so that
>                       only authorized personnel are able to access siloed data, and
>                       only for authorized purposes.
>                     </p>
>                   </section><!-- closes access controls, h4 -->
> 
>                   <section>
>                     <h4>Access Monitoring</h4>
> 
>                     <p>
>                       An outsourcing service should deploy access monitoring
>                       mechanisms to detect improper use of siloed data.
>                     </p>
>                   </section><!-- closes access monitoring, h4 -->
>                 </section><!-- closes siloing in the Backend, h3 -->
> 
>                 <section>
>                   <h3>Retention in the Backend</h3>
> 
>                   <p>
>                     An outsourcing service should <a>retain</a> information only so
>                     long as necessary to provide necessary functionality to a first
>                     party. If a service creates periodic reports, for example, it
>                     should delete the data used for a report once it is generated.
>                     An outsourcing service should be particularly sensitive to
>                     retaining protocol logs, since they may allow correlating user
>                     activity across multiple first parties.
>                   </p>
>                 </section><!-- closes retention in the backend, h3 -->
>               </section><!-- closes Technical Precautions appendix, h2 -->
>               <section class="informative" id="techniques-internal">
>                 <h3>Internal Practices</h3>
> 
>                 <section>
>                   <h4>Policy</h4>
> 
>                   <p>
>                     An outsourcing service should establish a clear internal
>                     policy that gives guidance on how to <a>collect</a>,
>                     <a>retain</a>, and <a>use</a> outsourced data in compliance
>                     with this standard.
>                   </p>
>                 </section><!-- closes policy, h4 -->
> 
>                 <section>
>                   <h4>Training</h4>
> 
>                   <p>
>                     Personnel that interact with outsourced data should be
>                     familiarized with internal policy on compliance with this
>                     standard.
>                   </p>
>                 </section><!-- closes Training, h4 -->
> 
>                 <section>
>                   <h4>Supervision and Reporting</h4>
> 
>                   <p>
>                     An outsourcing service should establish a supervision and
>                     reporting structure for detecting improper access.
>                   </p>
>                 </section><!-- closes supervision and reporting, h4 -->
> 
>                 <section>
>                   <h4>Auditing</h4>
> 
>                   <p>
>                     External auditors should periodically examine an outsourcing
>                     service to assess whether it is in compliance with this
>                     standard and has adopted best practices. Auditor reports
>                     should be made available to the public.
>                   </p>
>                 </section><!-- closes auditing, h4 -->
>               </section><!-- closes non-normative discussion of Internal Practices, h3 -->
>   </section>
>