Closed Bug 62399 Opened 24 years ago Closed 17 years ago

[P3P] Implement 100% Support for W3C P3P Platform for Privacy Preferences

Categories

(Core :: Networking: Cookies, defect)

defect
Not set
normal

Tracking

()

VERIFIED WONTFIX

People

(Reporter: mozilla, Unassigned)

References

()

Details

(Keywords: helpwanted, meta, Whiteboard: [helpwanted])

Attachments

(18 files)

(deleted), text/plain
Details
(deleted), application/octet-stream
Details
(deleted), application/octet-stream
Details
(deleted), application/octet-stream
Details
(deleted), application/octet-stream
Details
(deleted), application/octet-stream
Details
(deleted), patch
Details | Diff | Splinter Review
(deleted), application/octet-stream
Details
(deleted), patch
Details | Diff | Splinter Review
(deleted), application/octet-stream
Details
(deleted), patch
Details | Diff | Splinter Review
(deleted), patch
Details | Diff | Splinter Review
(deleted), patch
Details | Diff | Splinter Review
(deleted), patch
Details | Diff | Splinter Review
(deleted), patch
Details | Diff | Splinter Review
(deleted), patch
Details | Diff | Splinter Review
(deleted), patch
Details | Diff | Splinter Review
(deleted), patch
Details | Diff | Splinter Review
Please implement 100% support for the W3C's Platform for Privacy Preferences (P3P) Project. (http://www.w3.org/P3P/) See also: http://www.theregister.co.uk/content/4/15316.html
Keywords: mozilla1.0
Depends on: 2800, 28825, 47041, 47352, 47353
Keywords: meta
Yes yes and yes please do that!
This DEFINETLY would be cool and would go along perfectly with the cookie manager, the ability to only accept original images/cookies, and the wallet. Once moz has all of these it would be the de facto security/privecy browser.
Agreed. This is something I've been considering for awhile, and it is definitely on my priority list to implement some P3P support. First, I'd like a good general mechanism for storing site-specific prefs, like the cookie manager does. I'll see if I can leverage existing code for this, or rewrite it more generally. If somebody else wants to work on P3P support before I get to it, please do; I'll accept patches in this area.
Status: NEW → ASSIGNED
I'm getting ready to contribute P3P support as soon as I get past all the open source submission stuff I'm supposed to get through. Should be a few days from now hopefully. The support is current to the September 15, 2000 version of the spec. I'll have more to say once it's available to the community.
Thomas, Can you post your changes as a patch here? That way I can review them and get them approved, and hopefully start integrating it with other privacy code.
Mitchell: see bug 7380, backend support for all page prefs on a URL by URL basis.
*** Bug 63096 has been marked as a duplicate of this bug. ***
First of all, bug 63096 is not a duplicate of this bug. The Platform for Privacy Preferences 1.0 (P3P1.0) Specification may be visit by using this uri: http://www.w3.org/TR/2000/CR-P3P-20001215/ It's a W3C Candidate Recommendation starting from December 15. Microsoft is working hard on this issue, Netscape/Mozilla should do this also. Protecting the users privacy is getting more and more attention, this will be very important, for a lot of us.
I've just posted Tom Lendacky of IBM's patches for P3P support, with a textfile that explains how to merge them. This code has a problem which is documented in bug 64668. If anyone wants to work on integrating this stuff before I get to it, please go ahead.
Updated nsP3PUI to support a weak reference when adding it as a WebProgressListener.
Keywords: helpwanted
Whiteboard: [helpwanted]
Target Milestone: --- → mozilla1.0
I thought of a way to temporarily work around bug 64668. It requires the following: 1. Copy the P3P Base Dataschema (p3p\resources\content\P3PBaseDataSchema.xml) to a local HTTP server. 2. Modify p3p\src\nsP3PDataSchema.cpp::PostInit to point to the local HTTP server copy: In the "if (aURISpec.EqualsWithConversion( P3P_BASE_DATASCHEMA ))" block, set mReadURISpec and mcsReadURISpec to the URL where the base dataschema file was copied to, leave mUseDOMParser as false, and return NS_OK right after. This should work. However when I tested it I kept getting random failures in the parsing of the XML file saying that the file is not well formed. These failures happen at different spots in the file. Loading it directly into the browser window sometimes worked and sometimes failed. Loading the XML file with IE was always successful. So it looks like there is a parsing bug in Mozilla.
Taking bug from Mitch.
Assignee: mstoltz → harishd
Status: ASSIGNED → NEW
What needs to be done to get to December 2000 specification. MUST - policy refrence file referenced by a LINK tag can specify policies other than the URI prefix as the policy reference file itself. - P3P parser should taught about TEST element and NON-IDENTIFIABLE element. - import user preferences using a documented mechanism ( need APPEL support ). - Base Data Schema should be updated to comply with December 2000 spec. - support COOKIE-INCLUDE and COOKIE-EXCLUDE. MAY - support Compact Policies. - support POLICIES element within policy. - support multiple languages. - export user preferences.
Status: NEW → ASSIGNED
Tom, could you please take a look at my previous comment and let me know if I missed something? Thanks
Supporting the POLICIES element is a MUST. Additionally, there are some XML tags and attributes that had a spelling change and these MUST be corrected to match the new spelling. Other than that your list looks good.
Depends on: 50661, 56518, 64668
I've attached some changes needed after I cvs removed pref-utilities.js recently. It seems to me these xul files need to be updated for the recent XUL tag name changes, cc'ing blake who can give some pointers on that. Also, since this is an extension, shouldn't this be going into its own jar file in its own subdirectories (e.g. comm/content/p3p/, en-US/locale/en-US/p3p/)?
The xul syntax changes are outlined in my recent 'XUL SYNTAX' thread to news.public.mozilla.xpfe. Let me know if you need additional help in making the changes...
Jag: You're correct. jar.mn, I think, should be updated to direct P3P related stuff to its own directory.
And with it the xul files referencing p3p xul/dtd/js files.
When I created my own jar file for the cookie and wallet stuff, super-review complained saying that we shouldn't be creating additional jar files and should put this into the existing comm.jar and en-US.jar files. He said the jar files are only a packaging issue so there's nothing wrong with putting things from the extensions directory into the common jar files. Go figure.
I very much prefer for wallet and all other extensions to get there own jars. If we can't handle localization of individual components then we have a serious problem. p3p needs its own jars. I for one do not want to download a single bit of p3p support.
Depends on: 74495
In a chrome .jar file any subdirectory with its own contents.rdf could be mechanically moved from .jar to .jar with simple build (and install script) changes to reference the new location. There's no conflict between creating a separate chrome structure for some feature and for now putting it in one of the existing chrome .jars for simplicity. At the very least make the P3P chrome movable in this way, and then people can fight out the packaging issues elsewhere.
Created attachment 29594 [details] for the problem reported in 74495 (http://bugzilla.mozilla.org/show_bug.cgi?id=74495). The problem could be related to the validity of the patches since they were created months ago.
I am trying to make the Mac project files. p3pIDL.mcp seems to be ok, but the normal p3p.mcp will not compile - cannot file header files like nsCOM.h. I have no idea why, the include paths seem to be OK. Also, I am not sure what extra libs needs to be included in the project (besides the .cpp files in the p3p dir). Also I am not sure what needs to be done with the resource files. So some help would be needed here. I attached the diff (could not get unified diff to work) to make the Mac build script changes. These changes would make p3p not be built by default, as it should be to begin with.
Just a comment on the packaging issue :- packaging is completely independent of the underlying code. We collect all the packages that we ship with by default in our distribution together into the comm.jar file, this includes chrome that CAN NOT be deselected during the install process, while chrome that can receives its own jars (mailnews, chatzilla, etc). There is ZERO POINT creating new jar files for chrome that will always be present in our distribution, and it adds to the file clutter that we lay down on disk. This does not stop other distributions from repackaging as they see fit, should they choose to offer installation options or remove a feature completely, however it is appropriate for our distribution to try and use as few jar files as possible, rather than balkanizing the front end into hundreds of jar files for every add-on.
Another reason for creating .jars would be to save startup time for chrome that isn't used often since the open-jar time spent is directly proportional to the number of files in each archive. Of course the big losers on that front are the skin and locale jars which contain everything whether used or not. I'm not recommending further balkanization of the chrome .jars at this point, but it might be interesting to measure what time could be saved by being smarter.
I've attached the necessary source changes to build P3P support on Mac. Most of it is changing #include <blah.h> to #include "blah.h". Angle brackets are used to indicate system headers on Mac. Also some minor changes to handle PRTime correctly. I've also attached a patch to the Mac build system so that it has a p3p build option. The third patch I just attached contains the changes for the new XUL syntax, someone needs to check these and the fourth patch groups most of the previously attached patches to source outside of mozilla/extensions/p3p (in text/plain, not zipped *ugh*). With this, I can use P3P somewhat in Mozilla, though I haven't found a site for which it really works (seems related to the version of the spec it supports). Also, the privacy icon doesn't display most of the time, because some of the gifs that are in the cvs are broken and customizing the settings in the prefs doesn't work either.
Sorry, you can ignore attachment 31832 [details] [diff] [review] since this is already in attachment 31788 [details] [diff] [review]... i just missed it when I was going through them.
Peter: Here is the list of P3P enabled sites. http://www.w3.org/P3P/compliant_sites
r=harishd for patch id 31786.
Depends on: 78638
Attachment 31786 [details] [diff] (Source changes to build on Mac) and 31787 (Patch to the Mac build system) have been checked in. This brings Mac at the same level of the other platforms with regards to the p3p code.
yey! Good job Peter et al.
Need to find Mozilla QA to cover the test plan and test case execution for this feature. Asa - can you help coordinate?
Keywords: qawanted
Depends on: 80351
Depends on: LinkUI
Harish, where are we on this? Will http://news.cnet.com/news/0-1003-200-6828424.html?tag=tp_pr change anyone's mind on hurrying to get this in?
I'm still opposed to this. Microsoft's actions appear to be anticompetitive and are probably just as illegal as some of their previous actions. That should not be the reason for something to be added to mozilla's tree.
Probably done for anticompetitive reasons, but I don't see how supporting a standard is really anticompetitive. Anyways, what do you mean "still" opposed to this? I only saw one complaint from you here and it was directed at the way this was getting checked in. Is that what you're against, or are you against adding P3P in general?
Depends on: 62453
Is Hotmail a passport service? Does the Cnet article mean that Microsoft will require IE 6 (or another P3P browser) to access hotmail? There may be a few Mozilla/Netscape users out there that would be upset if they had to start using IE 6 for hotmail. Suddenly this bug could take on a whole new priority.
No longer depends on: 80351
*** Bug 80351 has been marked as a duplicate of this bug. ***
Depends on: 80697
if its going to land witch side of mozilla 1.0 is it going to come? harish can you post a status update?
At the moment it looks like this is post 1.0. What we will do instead is land support for P3P compact policies (see bug 104894).
chofmann: As heikki mentioned this is post m1.0
QA Contact: ckritzer → junruh
Full support: Future. Will file new bugs for work under way.
Target Milestone: mozilla1.0 → Future
nsbeta1
Keywords: nsbeta1
nsbeta1-, see bug 124503 and bug 104894 to see what is planned in the short term.
Depends on: 104894
Keywords: nsbeta1nsbeta1-
Maybe a more thorough approach would be beneficial? P3P is all fine and dandy, but it leaves issues to address. http://www.kcoyle.net/response.html "It is interesting to note that these more privacy-oriented cookie controls, although not at all complex as a technology, are not available in the browsers themselves. Had they been included in the primary Web browsers and been in wide use over the last five years, the Net would be different to what it is today in terms of personal privacy. We have to conclude that the developers of browsers made a conscious decision not to include privacy-oriented cookie controls because it might interfere with the economic model of many Web sites, including their own. It is also significant that the P3P privacy policy interaction relates solely to the immediate Web page that is visited. This means that P3P does not include the gathering of data through banner ad cookies and thus ignores the vast majority of privacy invasions on the Web."
"We have to conclude that the developers of browsers made a conscious decision not to include privacy-oriented cookie controls[...]" What are we to make of the fact that even NS4.x had "no cookies from secondary servers" as a pref (though not pref-panel) option more than 5 years ago, then? Curious.
Hi, As the co-developer of a GPL'ed CMS / Web publication system (named SPIP), I would like to know how our individual / non-profit users (i.e. webmasters) are expected to be able to fill a bunch of complex administrative XML stuff if they want our authentication cookies to work for them. P3P is aggressively discriminative against non-corporate webmasters. Right now, if a MSIE 6 user tells us his browser refuses the cookies, we suggest he jumps to Mozilla. If Mozilla implements P3P by default, then the only thing we can tell them is to set a low privacy level in their browser. A good way to promote privacy, isn't it ? Yours Antoine (antoine@rezo.net).
As the developer of a GPL'd CMS (Berylium) I don't think P3P is such a big hurdle. I think the biggest problem might be lack of examples-- once you see a few other implementations, it's not so difficult to create your own. (http://chxo.com/w3c/ ) The trick with a CMS is to provide a default policy that will at least get your cookies accepted, and then allow/encourage site owners to create more comprehensive XML policies. Sending a P3P header with a compact cookie policy (CP="") is not so difficult.
taking P3P bugs
QA Contact: junruh → gbush
per discussion with mvl and dwitte, moving bugs in our p3p impl to nobody@mozilla.org and adding helpwanted keyword
Assignee: harishd → nobody
Status: ASSIGNED → NEW
Component: Security: General → Cookies
QA Contact: agracebush → cookieqa
Summary: Implement 100% Support for W3C P3P Platform for Privacy Preferences → [P3P] Implement 100% Support for W3C P3P Platform for Privacy Preferences
Priority: P3 → --
Target Milestone: Future → ---
p3p has been permanently cvs removed, marking wontfix.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
V.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: