關於p3p 簡潔策略,以及瀏覽器的支援情況

轉載：http://www.cnblogs.com/_franky/archive/2011/03/16/1985954.html

簡述部分摘自某本關於P3P隱私權原則的書籍.而部分詳細的表格來自w3.org.而相關測試資料出自本人測試.如有遺漏或錯誤,歡迎指正.相關資源:1. http://www.w3.org/P3P/2. http://www.w3.org/TR/2002/REC-P3P-20020416/

簡述:

從本質上來說， P3P 策略是由一系列多選項問題的答案組成的，因此，它並不總像一個人類可讀的隱私權原則那樣包含許多資訊細節（例如，用英語或者其他某種口語語言寫成的策略是用來讓人閱讀的,而不是讓電腦識別的）。P3P策略的標準格式使它便於自動處理。同 樣 ， P3P規範也包含有用於請求和傳輸P3P策略的協議.P3P協議所基於的HTTP協議與 網頁瀏覽器用來與 Web伺服器進行通訊的 HTTP 協議相同。 1-1 所示，P3P
的使用者代理程式使用標準的 HTTP 要求從 Web 網站上一個眾所周知的地方擷取 P3P 策略引用檔案，並發送給發出請求的使用者。這個策略引用檔案指出了Web網站上各個部分所應用的P3P策略檔案的位置。整個網站有可能只應用了一種策略，也可能是網站的不同部分分別應用了幾種策略。這樣使用者代理程式就可以根據使用者的選擇來擷取合適的策略，將其解析出來並採取相應的動作P3P 也允許網站在其他位置放置策略引用檔案。在這些情況下，網站在聲明策略引用檔案的位置時，必須使用一個特定的 HTTP 前序，或者在應用了 P3P 策略的H T M L 文 件 內 嵌 入 一 個 L I N K 標 記 . 不論在何時設定cookie都可以用特定的HTTP前序來傳送一個可選的 P3P 簡潔策略.簡潔策略是完整 P3P 策略的一個短小摘要，僅描述了與cooki e 相關的資料處理方式，並且不需要P3P 策略的完整的表達效能.

如何使Web網站支援P3P:
從技術角度看，使 Web網站支援 P3P 是一個很容易的過程。但是，它要求網路電訊廠商在審視資料處理方式時比以前更加仔細，並要求他們協調域內各個主機上的策略和處理方式。以下是如何使網站支援P3P 技術的具體步驟。1. 建立一個隱私權原則。
2. 分析 cookie 的使用方式以及您的網站上的第三方內容。
3. 確定要對整個網站應用一個P3P策略還是對網站的不同部分應用不同的P3P 策略。
4. 為網站建立一個或幾個 P3P 策略。
5. 為網站建立一個策略引用檔案。
6. 為 P3P 設定管理員。
7. 測試網站，以確定它確實支援 P3P。大多數支援P3P 的Web網站會在每台伺服器上放置一個P3P策略引用檔案，同時它還會在中央伺服器上放置一個或多個P3P策略。這些網站也會將自己的伺服器配置為使用者在設定 cooki e 時發送 P3P 的簡潔策略。P3P 策略包括以下資訊：● 如何與擁有該網站的公司、組織或個人進行聯絡的資訊。
● 使用者是否可以尋找該網站的資料庫中儲存了自己的哪些個人資訊。
● 如何解決與網站之間有關隱私的糾紛（如客戶服務台、隱私封印以及與隱私相關的法律等）。
● 所收集資料的種類。
● 所收集資料的使用方式，以及使用者是否能選擇接受或拒絕這些用途。
● 資訊是否會被共用以及何時被共用，使用者是否有選擇的權力。
● 對所收集的使用者資訊進行定期清除的策略。有很多軟體工具可以協助Web網站開發人員開發支援P3P的網站。要想瞭解最新的P3P 工具列表，請訪問http://p3ptoolbox.org/tools/     和     http://www.w3.org/P3P/implementations/ 簡潔策略對應的 HTTP Response Header :

相關資源:http://www.w3.org/2002/04/P3Pv1-header.html 
Compact Policies (簡潔策略)
簡潔策略,本質上就是P3P策略的一個摘要. 他們的作用是,使使用者代理程式,可以快速敏捷的擷取到網站的P3P策略資訊,所以是對效能有益的.為了深入的解釋簡潔策略,按照 P3P1.0[4]規範,我們列出下面這些限制性的文法：

compact-policy-field         =   `CP="` compact-policy `"`

compact-policy                = compact-token *(" " compact-token)

compact-token                = compact-access           |

                                        compact-disputes         |                                        compact-remedies         |                                        compact-non-identifiable |                                        compact-purpose          |                                        compact-recipient        |                                        compact-retention        |                                        compact-categories       |                                        compact-test  compact-access           = "NOI" | "ALL" | " CAO" | "IDC" | "OTI" | "NON"

compact-disputes            = "DSP"

compact-remedies          = "COR" | "MON" | "LAW"

compact-non-identifiable = "NID"

compact-purpose           = "CUR"        | "ADM" [creq] | "DEV" [creq] | "TAI" [creq] |
                                       "PSA" [creq] | "PSD" [creq] | "IVA" [creq] | "IVD" [creq] |                                        "CON" [creq] | "HIS" [creq] | "TEL" [creq] | "OTP" [creq]creq                              = "a" | "i" | "o"compact-recipient       = "OUR" | "DEL" [creq] | "SAM" [creq] | "UNR" [creq] |
                                        "PUB" [creq] | "OTR" [creq]compact-retention          = "NOR" | "STP" | "LEG" | "BUS" | "IND"

compact-category           = "PHY" | "ONL" | "UNI" | "PUR" | "FIN" | "COM" |

                              "NAV" | "INT" | "DEM" | "CNT" | "STA" | "POL" | 

                                        "HEA" | "PRE" | "LOC" | "GOV" | "OTC"compact-test                  = "TST"

我們常用的簡潔策略的 P3P頭為 -   P3P : CP=CAO PSA OUR （其實, CP=. 就可以了.或者其他任何值都是可以的）分別對應了 :

　　compact-access(訪問)    :  CAO -  contact-and-other 

Identified Contact Information and Other Identified Data: access is given to identified online and physical contact information as well as to certain other identified data.直譯 : 被識別的聯絡資訊,和其他被識別的資料: 網上,或現實中的聯絡資訊,和某些被識別的資料,允許被訪問. 我的理解: 應該是, 允許被確認的資訊和資料的訪問. (允許第三方cookie的讀寫)

　　compact-purpose(目的)  :  PSA -  pseudo-analysis .這個就不放解釋了,字面意思很明顯, 目的就是做身分識別驗證、分析

　　compact-recipient(受體) :  OUR - ours

Ourselves and/or entities acting as our agents or entities for whom we are acting as an agent: An agent in this instance is defined as a third party that processes data only on behalf of the service provider
for the completion of the stated purposes. (e.g., the service provider and its printing bureau which prints address labels and does nothing further with the information直譯 :  我們自己,以及（或）實體作為我們自己的代理,或被我們所代理方的實體:這種情況下的代理,被定義為,相關進程資料,代表格服務提供者,用來完成其所設定服務的,第三方.(就好像,一個印刷局作為提供列印服務的,服務提供者,其只負責列印標籤神馬的,但是卻不會進一步,對相關的資訊,做任何事情 )我的理解:聲明使用相關資訊的人是誰.這裡聲明是第三方自己, 或作為代理.需要操作第三方Cookie. 大概就是這個意思.

　　ps : 其他項就不列舉,基於瀏覽器中只有IE支援.(chrome 部分支援).這一事實.深入研究沒有必要. 如果你有興趣,可以去相關連結查看文檔.

使用者代理程式對簡潔策略支援的狀況 和實現, 拿IE6來說:

IE6 ，可以自動核對設定了 cooki e的網站的 P3P 簡潔策略。使用者也可以配置 IE6 來過濾那些沒有簡潔策略的cookie，或那些具有與他們的偏好不相匹配的簡潔策略。當 cookie 被阻止時，IE6還會在瀏覽器的右下角顯示一個“眼睛”符號。使用者也可以從Vi ew（查看）菜單中選擇Privacy Report（隱私報告）命令來讓 IE6 擷取網站的 P3P 策略，並產生及顯示一個人們可讀取的版本

對於眾多提示性的反饋,是十分符合 P3P隱私權原則的.即使用者代理程式應該在恰當的時候,提醒使用者.

已測知的問題:

IE6 第三方cookie 在有p3p頭(使用p3p簡介策略時) ,JS雖然有讀寫權限,但是在寫的時候有個bug. 即,對於某第三方頁面,如果是首次讀到.其P3P頭的話,則 js的寫入權限是沒有的.必須要第二次訪問到這個頁面,且這個頁面存在第三方cookie操作時,才允許JS寫入Cookie.當然,讀是一直沒問題的.

Safair3,則頑固到連Post方式都無法寫入第三方Cookie.
Safari4+ 系列則有自己一套隱私權原則,而完全無視P3P的存在:在其不支援P3P的情況下,其策略為. 預設設定瀏覽器禁止第三方Cookie操作.那麼此時,無論JS 還是 HTTP ，都無寫入Cookie的許可權,而僅具備讀的許可權. 除非, 進行表單Post時,才允許第三方Cookie的寫入.參考下面的代碼: (在//www.a.com/test.htm 中的代碼)

if(Safari4或Safari5){    var ifm = document.createElement('iframe');    ifm.name ="postforcookie";    ifm.src="about:blank";    document.body.appendChild(ifm);       var form = document.createElement('form');    form.target = 'postforcookie';    form.action = '//www.php.com/test.php';    document.body.appendChild(form);       Cookie.setCookie = function () {        form.submit();    }}  

假設,setCookie是一個寫入第三方Cookie的函數,則在Sacari4,Sacari5下劫持他們,觸發代碼中 form的submit即可.此時,如果//www.php.com/test.php，有寫入Cookie的操作.則可以保證第三方Cookie被寫入. 預設不禁止第三方cookie的瀏覽器測試:

測試為在下列瀏覽器中,禁止第三方Cookie,並配置簡潔P3P策略.

Firefox下 :Firefox下禁止第三方Cookie後，很直接, 無論HTTP 還是 JS都無法讀寫Cookie.
Chrome:Chrome10 開始 支援使用者自訂是否允許在 地址欄: about:flags 中配置 是否允許第三方cookie.而之前的版本需要通過, 選項-進階選項-隱私權-內容設定-攔截第三方cookie 來配置.對於chrome9 和之前的Dev版本來說,通過選項配置禁止第三方cookie後, 在配置P3P簡潔策略後, JS 可讀cookie,但不能寫,而 HTTP方式,則都可以.而chrome10+ 無論選擇什麼方式設定, 只允許HTTP、JS讀,但是不允許寫.而Chrome的非Dev版, 甚至沒有提供第三方Cookie的隱私權原則選項. 有的僅僅是,關於Cookie的網站允許清單,或者主動訪問過的網站的Cookie. Opera:通過 工具-喜好設定-進階-Cookie-僅接受來自我訪問網站的Cookie 來設定禁止第三方Cookie.Opera的有趣之處在於,一但禁止第三方Cookie,則 P3P頭毫無意義,而Opera自身的隱私權原則則非常有趣,允許JS 的讀寫,以及HTTP的讀, 但是禁止HTTP 對Cookie的寫入.

總結:

瀏覽器	預設允許第三方Cookie	是否支援P3P	禁止第三方Cookie後,配置P3P簡明策略頭的效果	補充
IE6	否	是	HTTP可讀寫Cookie JS可讀Cookie 首次讀到P3P頭,JS無寫Cookie許可權.第二次才OK (第二次.直接Cache.也不行.除非第一次非Cache並讀到p3p頭.後面我會提到解決方案.)	避免JS的寫操作
IE7-IE9	否	是	HTTP、JS,可隨意讀寫.	-
FireFox	是	否	HTTP、JS都不可讀寫	-
Chrome	是	部分支援,趨勢-否	趨勢為HTTP、JS可讀不可寫.	-
Safari	否	否	HTTP、JS可讀不可寫	藉助Post提交表單,實現寫操作.
Opera	是	否	JS可讀寫 HTTP可讀不可寫.	-

建議:

1. 其實P3P簡潔策略,可以最簡寫成: P3P:CP=. 就OK啦,也就是說IE對P3P簡介策略的支援，屬於搞笑層級的.根本不看內容,至少對於第三方操作cookie是如此的.2. IE6的實現有bug.需要注意.首次訪問第三方頁面,JS無法寫入第三方Cookie的bug.建議盡量避免JS對Cookie的寫操作.3. 要搞定Safari,需要藉助後台至少配置一個APP,與前台配合.4. 對於第三方來說,建議避免使用JS操作Cookie,最多用來讀,而不是寫. 除非是和登入驗證有關,否則建議使用Storage代替Cookie的使用.最後:

如果你非要用在ie6下，用js寫cookie. 那麼有一個很悲劇的做法.. 伺服器端給資源配置可緩衝.(包括反向 Proxy和用戶端.) 然後想辦法在IE6的時候重新整理一次頁面.這樣就ok了. 重新整理時一定要用 location.reload(false)  即先忽略用戶端緩衝.嘗試304伺服器端校正用戶端緩衝可靠性..這樣做的好處是.即保證了 cookie的寫入性. 又保證,如果頁面是靜態資源.則反向 Proxy的可用性.. 否則還是直接用動態資源,http方式去寫好了.  需要注意的是.除了頁面重新整理.譬如其他方式載入頁面資源.試圖通過預讀其p3p簡介策略頭.是無效的.
比如 用 script type="text/c" 方式去預讀一次. 如果你有這個想法。還是早早放棄的好.