With the background on P3P compact policies covered in the first part of this series, time to answer the vexing question: why do nonsensical P3P policies appear to meet the Internet Explorer privacy settings?
This is partially a consequence of the way IE privacy settings are specified. As described in MSDN, compact policies are evaluated using a rules-based system, triggered by the presence or absence of specific policy tokens. For example the token CUS stands for “customization” and is part of the P3P vocabulary for data collection purposes. Similary FIN is a token indicating the category of data collected, in this case financial information. IE privacy engine is a series of rules where the condition is that presence/absence of some combination of tokens and the action defines what to do with that cookie. For example it is possible to state that if financial data (FIN) is being shared with third-parties (OTR) and the user has no recourse (no presence of LEG token) then reject the cookie.
In principle this mechanism is expressive enough to implement either blacklist or whitelist approach. In the first case, one accepts all policies except those containing certain combination of tokens, which are subject to additional restrictions. In the second case, the browser is more strict and by default rejects/downgrades cookies except when the policy meets a particular criteria. Looking at the medium privacy settings which are the default for Internet zone, IE takes the former approach– the default action attribute is accept.
The catch is that if Internet Explorer runs into unrecognized tokens such as “HONK” it will simply ignore these. The original motivation for this is forward compatibility: IE6 was finalized before P3P standard itself was completed, creating the possibility that the vocabulary could be expanded. In fact even if P3P standard had been finalized as W3C recomendation, that would be version 1.0– future revisions could introduce new tokens, with the result that users running earlier versions of IE would be faced with unrecognized tokens. That mindset is hard to imagine today when software is updated periodically, and often automatically. In 2001 the picture was different, with no monthly patch-Tuesday or near instant Chrome updates.
There is also a correctness problem in ignoring unknown tokens, in conjunction with the blacklisting approach used for settings. Any new token introduced in the spec could have signalled some pernicious data practice worse than those that existing rules were trying to block. Ignoring the new token in that case results in a decision resulting in less privacy and more cookies accepted than intended. This highlights a cultural preference common to MSFT at the time, in favor of failing open, favoring compatibility at all costs over privacy/security. (Trustworthy Computing has been successful in shifting that attitude.)
In reality of course P3P never went anywhere, with the W3C group eventually disbanding in frustration, citing “… insufficient support from current Browser implementers for the implementation of P3P 1.1.” That was 2006. With the vocabulary stabilized, a more strict parser could have been implemented. Even admitting for the possibiltiy of new tokens, sanity checks could have been added: since compact policies are supposed to be derived from a full XML policy, the well-formedness requirement for the XML rules out certain situations such as empty policy without any valid, recognized tokens.
With the perfect hindsight of 10+ years, that is one feature one of the designers regrets not implementing.