Read more about Data Workbench’s End-of-life announcement.
Conceptual information about third-party tagging and preventing cookie-blocking using P3P.
In most implementations, the Adobe persistent cookie is viewed as a first-party cookie. First-party cookies are defined as those associated with the host domain.
Suppose a user visits https://www.example.com/. Assuming that a Sensor is installed and operational on the web server hosting the domain, an Adobe persistent cookie is set and viewed as a first-party cookie. You may, however, want to collect measurement data from a third-party site through the use of embedded objects, which are requested and loaded from your server that is running Sensor instead of from the third-party server hosting the page or advertising program. For example, https://www.example2.com/ serves a web page with an embedded object request served from https://www.example.com/. The request for the embedded object from https://www.example.com/ results in a cookie being set; however, in this context, the web browser or user-agent views the cookie as a third-party cookie.
In newer web browsers such as Microsoft’s IE6, privacy features filter cookies based on their compact policies sent in the HTTP response header from the web server. In the default IE6 settings, which most users never change, third-party cookies are blocked when they have nonexistent or unsatisfactory compact policies. Most sites that are experiencing cookie-blocking problems have third-party cookies on their site that do not have the appropriate compact policies being sent in the HTTP response header. Additionally, some cookie-blocking problems occur when a site is framed by another site. For example, an online store that is part of an online shopping portal may appear in a frame provided by the portal. From the perspective of the browser, the store content may appear to be third-party content when framed by the portal. However, if a visitor goes directly to the online store without going through the portal, the content will be first-party content. Thus, the online store finds their cookies are blocked only when visitors come in through the portal.
Web-based mail systems cause a similar problem. If a website visitor emails a web page to a friend who uses a web-based mail system, the email message appears as third-party content to the friend’s browser because it is framed by the email system. If there are any cookies associated with the page that was emailed, they are treated as third-party cookies by IE6.
P3P provides a standard way for websites to encode their privacy policies in a computer-readable XML format. P3P-enabled web browsers and other P3P user agents automatically fetch P3P privacy policies, parse them, and compare them with a user’s privacy preferences.
To prevent IE6 from blocking cookies on your site, you need to ensure the following:
The following is an example of such a P3P header:
P3P: policyref=” https://www.myserver.com/w3c/p3p.xml”, CP=”NOI DSP COR PSA PSD OUR IND COM NAV”
In this example, the file p3p.xml is used to reference an associated policy.xml file residing on your web server that denotes the kinds of information your website collects, dispute resolution methods that your organization adheres to, how the data collected is used, who owns the data, and other standard information related to Internet Privacy. The three character codes following the “CP” are the compact policy codes that emulate what is stated within your policy.xml file.
For more information on how Internet Explorer 6 handles P3P Headers, please visit: