P3P의 압축정책 Spec
| 개인 정보 태그 |
압축 토큰 |
| <contact-and-other/> |
CAO |
| <pseudo-analysis/> |
PSA |
| <contact required="opt-in"/> |
CONi |
| <other-recipient/> |
OTR |
| <ours/> |
OUR |
| <demographic/> |
DEM |
| <online/> |
ONL |
| 범주 |
압축 토큰 |
설명 |
| <physical/> |
PHY |
연락처 또는 위치 정보 |
| <online/> |
ONL |
인터넷 상의 연락처 또는 위치 정보(예: 전자 메일 주소) |
| <government/> |
GOV |
정부에서 발급한 ID(예: 사회 보장 번호) |
| <financial/> |
FIN |
개별 재무 정보 |
| 용도 |
압축 토큰 |
설명 |
| <customization/> |
CUS |
사용자에 의해 명시적으로 요청된 사이트 수정 |
| <individual-analysis/> |
IVA |
개별 사용자와 관련될 수 있는 분석 |
| <individual-decision/> |
IVD |
사용자 기록에 기초한 동작 수행 |
| <contact/> |
CON |
개별 사용자에게 연락하는 데 사용할 수 있는 정보 |
| <telemarketing/> |
TEL |
전화 판촉에 사용할 수 있는 정보 |
| <other-purposes/> |
OTP |
다른 P3P 용도 이외의 기타 용도 |
| 수신인 |
압축 토큰 |
설명 |
| <same/> |
SAM |
일관된 관례에 따라 고유한 목적에 데이터를 사용하는 정식 항목 |
| <delivery/> |
DEL |
주어진 용도 이외에 목적에 데이터를 사용할 수 있는 배달 서비스를 수행하는 정식 항목 |
| <other-recipient/> |
OTR |
공급자에게 책임이 있지만 알려지지 않은 방법으로 데이터를 사용할 수 있는 항목 |
| <unrelated/> |
UNR |
공급자에게 알려지지 않은 방법으로 데이터를 사용하는 항목 |
| <public/> |
PUB |
공개 포럼 |
여기에 안나온것들은
http://www.w3.org/TR/P3P/ 이곳에서 살펴봐라.
또 영어라고 울렁증 걸릴텐데 -_- 제가 찾아보니..
여기부분을 봐라 ㅡㅡ 쫌 !!
쫌 알고 쓰자 -_-;;;
그리고 이건 덤으로 ...
The Situation
The other day I came across a weird security problem at work: While a system to customize a site's appearance worked fine in Firefox, storing the state kept failing in IE. Now, I'm not a big fan of these browser discussions and don't mind using either, but that error made me curious. I quickly found out that it was down to the company's security standard, which defaulted IE's privacy level to high-medium. This level doesn't allow third-party cookies for permanent storage, and as the whole site was running in a Frameset for a couple of days (thank you, domain-hogging cheapie-host), the cookies used were rightly considered third party.
They are allowed to be stored under this setting, though, when they come with a P3P (Platform for Privacy Preferences) policy. Microsoft offers a nice overview to what this is, but leaves you pretty much in the dark of how you actually get from A (Problem) to B (Solution). P3Ptoolbox.org, a website dedicated to P3P offers an all-embracing guide, but the sheer amount is more off-putting than encouraging.
What Is P3P?
P3P is a protocol designed to offer an "automated way for users to gain more control over the use of personal information on Web sites they visit", states the W3C. Policies are something that is used quite frequently, in the Flash and Java (J2EE) World, usually describing a set of permissions granted or revoked. P3P is an XML based policy that describes the scope or the way how the data in cookies is used. It consists of four logical parts:
- a written, and as they like to state "human readable" policy, as html-file is recommended as the easiest starting point for it all. But, hooray, if you rather track down cookie operations in your code, the policy editor will generate one for you, which you can then amend to your needs.
- The policy editor helps you create the full XML privacy policy
- The Policy-Reference File, again as XML, which is stored in a "well-known location", links to the privacy policy.
- The compact policy(a string of 3-letter-abbrevations), which is sent in the header of the page containing the cookie-related action.
How can I build it?
If you look into tools for generating P3P policies, you'll find yourself in a land of darkness and badly designed websites with dollar signs. But there's light at the end of the tunnel: The IBM P3P Editor is free, being an executable jar it's crossplatform, and if you know what you're doing, it's really easy. So what do you have to do?
- Do your homework: the first step is, and the P3Ptools site isn't wrong with it, a thorough preparation. Does the company running the website already have a privacy policy? Does it cover all cookie-related actions as well? If not, "Where do you store and read out cookies?", and "What's stored in them?" are the first key questions to ask. Ideally you know it beforehand, if not, an extended search over the usual cookie-dealing functions should refresh your memory.
- What to do with the data? Who will be dealing with it? Once you have figured out what it is you'll need to ask yourself or, even better, your client, if they are planning to use the requested data, e.g. for stats on returning users or to find out about preferred customizations and the like. This should be (again ideally) honest, or alternatively passed by a legal department that does the juggling of the words.
- Fire it up. The IBM P3P policy editor luckily generates XML and P3P strings as well as a good skeleton for the written privacy policy. All you have to do is
- To categorise your cookies into groups and usage.
- Connect them to their purpose
- Add information about dispute and contact possibilities
- Generate policy
- Deploy: A great word which took me a while to understand, back at university. In this case, all it means is to take the generated xml and html and drop it in a folder.
An example
Let's say we set and read a cookie on the homepage that stores a unique ID for tracking reasons and retrieves preferences from the db on how the site is displayed (font size and regular/high-contrast layout, for example).
Open up the P3P editor, choose "create a blank policy", and you'll find a well categorized list of elements on the left, and an empty tree on the right.
Locate and drag the data elements matching your purpose from the list into the "new group" on the right. In our case that's:
Broad Categories --> unique identifier and
Dynamic Data --> http cookie
You can edit the group name, and you'll probably want to do it in real life situations that are more complex - in order to find grouped entries easier later on.
When you do so, you are also asked to put down an explanation to why the data is requested and you have to decide if "there is no reasonable way to link this data to the visitor's real-world identity." (check the help button). As users don't register on my site, they will be unique by identifier, but I won't be able to find out who they really are. The display data is anonymous anyway, so, tick the box here as well. Describe the reasons then on to the next step.
Make your way through the tabs, I will check "Site customisation" and "Anonymous user tracking", I offer an opt-out possibility for the site customisation, and uncheck pseudonymous decision-making, as I’m not tracking that. Recipient is just me, and as Retention I choose indefinitely.
To the right of the tabs in the lower part of the window is a properties button, click that to add all necessary data for the website, starting with a full contact information of the person/organisation responsible for the site.
Click on the next tab to enter a generic name for the policy and add an opt-out url (essentially a page where you can choose to get all cookies from your site deleted).
Make sure your language selection is the right one and add the url for your privacy policy on your website.
The Access-tab wants you to indicate what personal data the user can view to doublecheck what's stored on your site. In my case: no identified data is collected.
Next, let's eliminate that dispute warning: go to "Assurances", and add a dispute. I call it "all disputes" chose customer service as dispute remedy for "all disputes", with a link to contact-us, to reach the customer service.
Lastly, in the global properties, set the expiry date. I chose the same as the cookies lifetime, or up to a date when the cookie situation, and therefore the privacy policy, changes.
The easiest way to get rid of the must-haves is to eliminate one error after the next. Click the error tab to see them. If you have any other errors, fix them accordingly... it's most probably in your data group, or it’s a conflict between your data elements, the group and global properties.
All done? I had to add a category to my HTTP cookie. Now it looks like this:
Save it, and go to the final step: deploy your data. For that, you'll need to generate a reference file first. Here's one that fits my example - it directs to the P3P file in all cases (include \*).
<META xmlns="http://www.w3.org/2000/12/p3pv1">
<POLICY-REFERENCES>
<POLICY-REF about="testsite_com.p3p">
<INCLUDE>\*</INCLUDE>
<COOKIE-INCLUDE name="*" value="*" domain="*" path="*"/>
</POLICY-REF>
</POLICY-REFERENCES>
</META>
All you have to do now, is:
- Save the P3P reference file in a folder called w3c in the webroot, as /w3c/p3p.xml. Feel free to look at my example reference.
- Save the P3P. You can see from how I set up the reference file that I chose to store it in the same folder, which is the easiest and most common thing. Here's my example p3p policy for download
- Every time you interact with the cookie, send the created header first. Below is an overview of how to do it for my example, taken directly from the privacy council.
- Finally: Take a look at it (in IE: view-->privacy report).
P3P compact policy implementations
| Method |
Code |
| HTML |
<meta http-equiv="P3P" content="CP='NOI DSP NID TAIo PSAa OUR IND UNI OTC TST'"> |
| PHP |
Header("P3P: CP='NOI DSP NID TAIo PSAa OUR IND UNI OTC TST'") |
| ASP |
Response.AddHeader "P3P","CP='NOI DSP NID TAIo PSAa OUR IND UNI OTC TST'" |
| JSP |
Response.setHeader("P3P","CP='NOI DSP NID TAIo PSAa OUR IND UNI OTC TST'") |
| ColdFusion |
<cfheader name="P3P" value="CP='NOI DSP NID TAIo PSAa OUR IND UNI OTC TST'" /> |
Conclusion
Congratulations, you made through this dry and rocky path of an article, or alternatively you found the scrollbar overly useful. I've had my doubts while writing this, about how complex it should be, and decided to go for an overview with a simple A-Z example, as my key problem was piecing it together initially.
P3P doesn't end here though - there are many more possibilities, from setting up different policies for different parts of a website, to getting deeper into the personal data aspect (there's quite a difference in cookie handling with P3P when personal data is involved), to taking a closer look into the client side and the possibilities that P3P offers, which mostly aren't quite built into browsers yet.
The idea of P3P is a good one, but it's flawed, as it's so far based on honesty. If I used information differently than I stated in my P3P policy, how would the user ever know? If developers use half-hearted workarounds by simply adding a non-offensive P3P header, why would the user trust P3P? These are the first things that you'll ask yourself while spending time on this, but there's more elaborated critizism: the Electronic Privacy Information Center has assessed P3P and is not happy at all with it. So why do it? Given you do use cookies, 3 reasons come to mind, and they seem oddly close to web standards (looking forward to the comments):
- Because you have to: I don't use cookies very much, maybe a couple of projects a year. But if I do and it doesn't work for a group of users or, even worse (*gasp*) the client, heck, I gotta make it work.
- Because you would rather solve problems than work around them: I never like grey areas in projects, identified ones or the ones that are brushed off. The fix-it-now-research-it-later approach usually ends in not researching it at all, and next time round you're none the smarter.
- Because it makes a better website: This is the moral high ground for today, but think about it: the web standards movement is something that had to happen sooner or later. Cookies aren't used as much as in the olden days, but as the basics are set and can be extended, any improvement in their handling should improve users trust in using personal data on the internet, with reasonable resonance in the future.
0