Last Comment Bug 62399 - [P3P] Implement 100% Support for W3C P3P Platform for Privacy Preferences
: [P3P] Implement 100% Support for W3C P3P Platform for Privacy Preferences
Status: VERIFIED WONTFIX
[helpwanted]
: helpwanted, meta
Product: Core
Classification: Components
Component: Networking: Cookies (show other bugs)
: Trunk
: All All
: -- normal with 26 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://www.w3.org/P3P/
: 80351 (view as bug list)
Depends on: 2800 7380 28825 47041 47352 47353 50661 56518 62453 64668 74495 78638 80697 LinkUI 104894 124503
Blocks:
  Show dependency treegraph
 
Reported: 2000-12-08 19:50 PST by David Krause
Modified: 2008-06-24 00:32 PDT (History)
48 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Notes on how to build with P3P support (6.88 KB, text/plain)
2001-01-16 13:51 PST, Mitchell Stoltz (not reading bugmail)
no flags Details
P3P Patch 1 - Diffs (Zipped) (6.02 KB, application/octet-stream)
2001-01-16 13:52 PST, Mitchell Stoltz (not reading bugmail)
no flags Details
P3P Patch 2 - New Files (Zipped) (245.83 KB, application/octet-stream)
2001-01-16 13:53 PST, Mitchell Stoltz (not reading bugmail)
no flags Details
Update to nsP3PUI to support weak references for adding a WebProgressListner (5.01 KB, application/octet-stream)
2001-02-12 11:49 PST, Thomas Lendacky
no flags Details
Updates for change to nsIChannel and nsILoadGroup (includes previous updates) (22.06 KB, application/octet-stream)
2001-02-23 07:12 PST, Thomas Lendacky
no flags Details
Updates for changes to nsIGenericFactory and nsCString (all previous updates included) (43.10 KB, application/octet-stream)
2001-03-21 06:58 PST, Thomas Lendacky
no flags Details
[patch] remove unneeded strres.js, prefutilities.js from pref-P3P(cust).xul (1.75 KB, patch)
2001-04-02 15:06 PDT, Peter ``jag'' Annema
no flags Details | Diff | Splinter Review
Updated (non-build related) patches for P3P (3.87 KB, application/octet-stream)
2001-04-03 04:53 PDT, Thomas Lendacky
no flags Details
Mac build changes (816 bytes, patch)
2001-04-03 11:27 PDT, Heikki Toivonen (remove -bugzilla when emailing directly)
no flags Details | Diff | Splinter Review
Update for nsIChannel interface change (note: old tree structure) (43.10 KB, application/octet-stream)
2001-04-10 11:51 PDT, Thomas Lendacky
no flags Details
Source changes to build on Mac (47.82 KB, patch)
2001-04-22 18:12 PDT, Peter Van der Beken [:peterv] - away till Aug 1st
no flags Details | Diff | Splinter Review
Patch to the Mac build system (3.00 KB, patch)
2001-04-22 18:12 PDT, Peter Van der Beken [:peterv] - away till Aug 1st
no flags Details | Diff | Splinter Review
Patch to chrome for xul syntax changes (160.87 KB, patch)
2001-04-22 18:14 PDT, Peter Van der Beken [:peterv] - away till Aug 1st
no flags Details | Diff | Splinter Review
Patch to source outside mozilla/extensions/p3p (8.83 KB, patch)
2001-04-22 18:15 PDT, Peter Van der Beken [:peterv] - away till Aug 1st
no flags Details | Diff | Splinter Review
Changes to the preference JS file to match XUL changes (1.08 KB, patch)
2001-04-23 07:17 PDT, Thomas Lendacky
no flags Details | Diff | Splinter Review
Patch to make P3P compile against recent http changes [ bug 80351 ] (32.25 KB, patch)
2001-05-21 18:31 PDT, harishd
no flags Details | Diff | Splinter Review
Patch to fix P3P build problems related to http & xpcdom changes. (42.01 KB, patch)
2001-05-22 12:52 PDT, harishd
no flags Details | Diff | Splinter Review
Patch v1.1 to fix P3P build problems caused by recent http & xpcdom changes. (41.75 KB, patch)
2001-05-22 12:54 PDT, harishd
no flags Details | Diff | Splinter Review

Description David Krause 2000-12-08 19:50:40 PST
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
Comment 1 HJ 2000-12-08 22:32:19 PST
Yes yes and yes please do that!
Comment 2 Peter 'Rufus' Nelson 2000-12-09 14:36:44 PST
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.
Comment 3 Mitchell Stoltz (not reading bugmail) 2000-12-11 09:42:41 PST
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.
Comment 4 Thomas Lendacky 2000-12-11 12:21:33 PST
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.
Comment 5 Mitchell Stoltz (not reading bugmail) 2000-12-11 12:33:51 PST
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.
Comment 6 Hixie (not reading bugmail) 2000-12-11 17:05:10 PST
Mitchell: see bug 7380, backend support for all page prefs on a URL by URL basis.
Comment 7 Hixie (not reading bugmail) 2000-12-17 00:36:21 PST
*** Bug 63096 has been marked as a duplicate of this bug. ***
Comment 8 HJ 2000-12-17 06:03:47 PST
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.

Comment 9 Mitchell Stoltz (not reading bugmail) 2001-01-16 13:51:11 PST
Created attachment 22684 [details]
Notes on how to build with P3P support
Comment 10 Mitchell Stoltz (not reading bugmail) 2001-01-16 13:52:46 PST
Created attachment 22685 [details]
P3P Patch 1 - Diffs (Zipped)
Comment 11 Mitchell Stoltz (not reading bugmail) 2001-01-16 13:53:23 PST
Created attachment 22686 [details]
P3P Patch 2 - New Files (Zipped)
Comment 12 Mitchell Stoltz (not reading bugmail) 2001-01-16 14:01:02 PST
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.
Comment 13 Thomas Lendacky 2001-02-12 11:49:59 PST
Created attachment 25076 [details]
Update to nsP3PUI to support weak references for adding a WebProgressListner
Comment 14 Thomas Lendacky 2001-02-12 11:51:40 PST
Updated nsP3PUI to support a weak reference when adding it as a 
WebProgressListener.
Comment 15 Thomas Lendacky 2001-02-23 07:12:08 PST
Created attachment 26016 [details]
Updates for change to nsIChannel and nsILoadGroup (includes previous updates)
Comment 16 Mitchell Stoltz (not reading bugmail) 2001-03-08 18:56:38 PST
Help Wanted!
Comment 17 Thomas Lendacky 2001-03-09 07:01:10 PST
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.
Comment 18 harishd 2001-03-19 19:16:43 PST
Taking bug from Mitch.
Comment 19 Thomas Lendacky 2001-03-21 06:58:02 PST
Created attachment 28350 [details]
Updates for changes to nsIGenericFactory and nsCString (all previous updates included)
Comment 20 harishd 2001-03-30 12:40:17 PST
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.
Comment 21 harishd 2001-03-30 12:41:40 PST
Tom, could you please take a look at my previous comment and let me know if I 
missed something? Thanks
Comment 22 Thomas Lendacky 2001-04-02 04:28:58 PDT
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.
Comment 23 Peter ``jag'' Annema 2001-04-02 15:06:10 PDT
Created attachment 29499 [details] [diff] [review]
[patch] remove unneeded strres.js, prefutilities.js from pref-P3P(cust).xul
Comment 24 Peter ``jag'' Annema 2001-04-02 15:13:48 PDT
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/)?
Comment 25 Blake Ross 2001-04-02 15:20:46 PDT
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...
Comment 26 harishd 2001-04-02 15:39:17 PDT
Jag: You're correct. jar.mn, I think, should be updated to direct P3P related 
stuff to its own directory.
Comment 27 Peter ``jag'' Annema 2001-04-02 15:58:43 PDT
And with it the xul files referencing p3p xul/dtd/js files.
Comment 28 Stephen P. Morse 2001-04-02 17:13:51 PDT
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.
Comment 29 timeless 2001-04-02 17:33:41 PDT
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.
Comment 30 Daniel Veditz [:dveditz] 2001-04-02 23:32:35 PDT
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.
Comment 31 Thomas Lendacky 2001-04-03 04:53:43 PDT
Created attachment 29594 [details]
Updated (non-build related) patches for P3P
Comment 32 Thomas Lendacky 2001-04-03 04:58:32 PDT
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.
Comment 33 Heikki Toivonen (remove -bugzilla when emailing directly) 2001-04-03 11:27:12 PDT
Created attachment 29615 [details] [diff] [review]
Mac build changes
Comment 34 Heikki Toivonen (remove -bugzilla when emailing directly) 2001-04-03 11:37:19 PDT
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.
Comment 35 Ben Goodger (use ben at mozilla dot org for email) 2001-04-03 14:30:27 PDT
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. 
Comment 36 Daniel Veditz [:dveditz] 2001-04-03 16:34:49 PDT
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.
Comment 37 Thomas Lendacky 2001-04-10 11:51:50 PDT
Created attachment 30302 [details]
Update for nsIChannel interface change (note: old tree structure)
Comment 38 Peter Van der Beken [:peterv] - away till Aug 1st 2001-04-22 18:12:08 PDT
Created attachment 31786 [details] [diff] [review]
Source changes to build on Mac
Comment 39 Peter Van der Beken [:peterv] - away till Aug 1st 2001-04-22 18:12:54 PDT
Created attachment 31787 [details] [diff] [review]
Patch to the Mac build system
Comment 40 Peter Van der Beken [:peterv] - away till Aug 1st 2001-04-22 18:14:02 PDT
Created attachment 31788 [details] [diff] [review]
Patch to chrome for xul syntax changes
Comment 41 Peter Van der Beken [:peterv] - away till Aug 1st 2001-04-22 18:15:04 PDT
Created attachment 31789 [details] [diff] [review]
Patch to source outside mozilla/extensions/p3p
Comment 42 Peter Van der Beken [:peterv] - away till Aug 1st 2001-04-22 18:27:15 PDT
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.
Comment 43 Thomas Lendacky 2001-04-23 07:17:31 PDT
Created attachment 31832 [details] [diff] [review]
Changes to the preference JS file to match XUL changes
Comment 44 Thomas Lendacky 2001-04-23 07:23:33 PDT
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.
Comment 45 harishd 2001-04-23 14:44:25 PDT
Peter: Here is the list of P3P enabled sites.

http://www.w3.org/P3P/compliant_sites
Comment 46 harishd 2001-05-02 14:00:22 PDT
r=harishd for patch id 31786.
Comment 47 Peter Van der Beken [:peterv] - away till Aug 1st 2001-05-04 13:25:26 PDT
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.
Comment 48 harishd 2001-05-04 13:28:57 PDT
yey! Good job Peter et al.
Comment 49 lchiang 2001-05-14 17:09:08 PDT
Need to find Mozilla QA to cover the test plan and test case execution for this
feature.  Asa - can you help coordinate?
Comment 50 harishd 2001-05-21 18:31:42 PDT
Created attachment 35521 [details] [diff] [review]
Patch to make P3P compile against recent http changes [ bug 80351 ]
Comment 51 harishd 2001-05-22 12:52:17 PDT
Created attachment 35635 [details] [diff] [review]
Patch to fix P3P build problems related to http & xpcdom changes.
Comment 52 harishd 2001-05-22 12:54:52 PDT
Created attachment 35636 [details] [diff] [review]
Patch v1.1 to fix P3P build problems caused by recent http & xpcdom changes.
Comment 53 Blake Ross 2001-08-09 11:26:01 PDT
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?
Comment 54 timeless 2001-08-09 11:49:33 PDT
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.
Comment 55 Blake Ross 2001-08-09 11:54:12 PDT
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?
Comment 56 Ben Bucksch (:BenB) 2001-08-09 23:14:46 PDT
Bug 62453.
Comment 57 Kevin Berkheiser 2001-08-14 19:11:02 PDT
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.

Comment 58 Christopher Hoess (gone) 2001-09-18 13:06:11 PDT
*** Bug 80351 has been marked as a duplicate of this bug. ***
Comment 59 chris hofmann 2001-11-28 08:51:52 PST
if its going to land witch side of mozilla 1.0 is it going to come?
harish can you post a status update?
Comment 60 Heikki Toivonen (remove -bugzilla when emailing directly) 2001-11-28 10:07:32 PST
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).
Comment 61 harishd 2001-11-28 11:06:17 PST
chofmann: As heikki mentioned this is post m1.0
Comment 62 Heikki Toivonen (remove -bugzilla when emailing directly) 2002-02-08 16:04:00 PST
Full support: Future. Will file new bugs for work under way.
Comment 63 John Unruh 2002-02-14 12:57:53 PST
nsbeta1
Comment 64 Heikki Toivonen (remove -bugzilla when emailing directly) 2002-02-14 13:14:22 PST
nsbeta1-, see bug 124503 and bug 104894 to see what is planned in the short term.
Comment 65 Frederic Nilsson 2002-06-21 12:12:33 PDT
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."
Comment 66 Mike Shaver (:shaver -- probably not reading bugmail closely) 2002-06-21 13:49:16 PDT
"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.
Comment 67 pitrou 2002-08-07 10:34:24 PDT
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).
Comment 68 Chris Snyder 2003-02-10 08:53:51 PST
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.
Comment 69 Grace Bush 2003-03-10 13:41:04 PST
taking P3P bugs
Comment 70 Mike Connor [:mconnor] 2004-04-04 12:15:23 PDT
per discussion with mvl and dwitte, moving bugs in our p3p impl to
nobody@mozilla.org and adding helpwanted keyword
Comment 71 dwitte@gmail.com 2007-06-11 14:37:05 PDT
p3p has been permanently cvs removed, marking wontfix.
Comment 72 benc 2008-06-24 00:32:33 PDT
V.

Note You need to log in before you can comment on or make changes to this bug.