Real World Implementation Experience February 4, 2002

1. Real World Implementation ExperienceFebruary 4, 2002 Common Difficulties in correctly writing and maintaining Compact and Cookie Policies DoubleClick Jules Polonetsky, Chief Privacy Officer Brooks Dobbs, Manager of Privacy Technology

2. Topics • Accurately Declaring a Compact and Cookie Policy • Impact of unique cookies • Concerns with cookie scope • Changing a Compact Policy during the life of a cookie

3. What must be covered by a cookie policy • P3P specification 2.3.2.7 • A cookie policy MUST cover any data (within the scope of P3P) that is stored in that cookie or linked via that cookie. • The troubles presented here are: • Cookies with compact policies are replayed not just to the host that set them but often to other hosts on the domain • Unique cookies become foreign keys that link disparate data sources including multiple server log files and offline databases • There is often no concrete difference between data that could be linked and data that is linked. If A=B and B=C, you can claim that you don’t know A=C but the data is linked.

4. Two ways a cookie manages data: stored and linked • If a site wants to store my age in a cookie it can do it one of two ways (first lets assume it somehow gets me to give up my age). • Stored: age=33 • Linked*: guid=abc123 then have abc123 be a foreign key to a data structure such that the relationship abc123=33

5. stored and linkedcontinued… * Typically, a linked cookie uses its foreign key relationship to match a unique id to more than one data point. This is best illustrated through a data table. This table, in an actual implementation, could be an online user registration database connected to the web server. User Table

6. Question: “How does the cookie link this information to anything else?”Answer: “Web server log files”

7. What a typical web server log file looks like 8 sample lines of a typical server log file

8. Bottom line – what is linked to a cookie? Well lets look at one instance, guid=abc123 • All the info in the user table (age, email, name) • All the info linked via another table in the CRM database (perhaps mailing address, credit card #, prior purchase info) • That the cookie was interested in dating services on the last site it was on • That the cookie was interested in male pattern baldness while browsing within a site • What if guid is replayed to 3rd party say maps.domain.com they get the cookie too and could potentially tie data to it??? You need to know and declare this.

9. Typical linkages

10. Domain level cookies replayed to: • P3P compliant hosts within the domain • Non P3P compliant hosts within the domain • Hosts on the domain hosted by 3rd parties

11. Common Example

12. Recommendations: • Be aware of the nature data that is collected in log files. What is passed in refer? What is passed in query_string? • Keep very close track of unique cookies, particularly domain level. • Examine all server’s in the domain’s default settings to be sure that they do not log or set cookies. • Examine where cookies can become (intentionally or otherwise) foreign keys to off line data. Is a cookie stored with a user login? • Examine policies of 3rd parties that run servers for you on your domain. • Pay close attention to internal servers particularly intranets or even test boxes. • Pay close attention to any client facing boxes that require authentication of collect unique information • Don’t rely strictly on an editor to generate CPs – editors don’t take into account sharing data across hosts

13. Upgrading a Compact Policy • The Challenges • A Compact Policy needs to be honored for the lifetime (expiry) of the cookie • The cookie is sent with a request for a URI prior to checking to see if there is a new policy in effect • Often a cookie with a discreet CP is replayed to many hosts all with: • Multiple cookie policies pointed to through separate PRFs • The policies all potentially have different expiries – but still need to collectively support the CP of the cookie replayed to all the hosts covered by the separate policies

14. Step 1: Plan aheadan ounce of prevention is worth several pounds of cure When a cookie is sent to a server from a browser it passes the cookies name and the cookies value in a request header as: Cookie: guid=abc123 Conspicuously absent are the expiry of the cookie (does it have 1 day or 10 years left to live) and the compact policy under which the cookie was set (if I have changed my policy can I use this cookie or not?) You can work around this by carefully naming your cookies. For instance, all cookies set under “compact policy 1” could be of the form guid_cp1=abc123 set to expire on the hard date of 1/31/2010.

15. Upgrading Compact PolicySetting the initial cookie

16. Upgrading Compact Policyupgrading policy CP accepted CP not accepted

17. Recommendations: • PLAN AHEAD • Carefully consider the expiration date of cookies in anticipation of possible future changes • Carefully examine your proposed CP – balance extensibility and accuracy • Make sure that a cookie with a CP will be replayed to hosts who’s cookie policies are mutually supportable • Establish a cookie / CP naming convention • Build your upgrade mechanism before you need it. Make sure this includes the ability to throw out data from non-supported cookies

18. For questions, assistance or consulting services contact: Brooks Dobbs Coordinating DoubleClick / Privacy Council P3P Consulting Services bdobbs@doubleclick.net 404.836.0525