The p3p code is currently used by seamonkey and has not been owned or touched since 2003. We really shouldn't keep unowned code around for this long.

If Neil(?) says this is OK I'd like to go ahead and do it.

If no one objects by the end of the week I'm going to go ahead and remove this.

Hmmm, just because code has not been touched does not mean some people do not find its functionality useful. Has the question of removing this being asked on any of the forums/newsgroups?

Another option is for it to move somewhere under /suite if it is still needed and wanted for SeaMonkey and not wanted in the /extensions

It's been discussed in newsgroups, without objections. Even 3 years ago in n.p.m.seamonkey there was no real objection, see http://groups.google.com/group/netscape.public.mozilla.seamonkey/browse_thread/thread/b2386a962ba6d685/d544ef392f558a92?lnk=gst&q=p3p&rnum=4#d544ef392f558a92 IMHO, this is a technology that never took off, has no real/significant users and the code for supporting it should therefore just die a silent death.

As someone pointed out to me, IE does implement this feature (on IE6 look under Internet Options, Privacy, Advanced or on browser page, View, Privacy Report), whether that is a good or bad thing is another matter.

I have not heard any real arguments for leaving P3P in yet, so I think it should be just removed. Apparently no sites are really depending on this technology any more, or Firefox requests for it would have come up by now. This actually seems to be one technology that never really took off the way it was hoped it would, so we probably should admit it's dead and kill the code.

Having thought about this more, I'm happy for this to happen.

as advertised - removes p3p from the MOZ_EXTENSIONS_ALL and MOZ_EXTENSIONS_DEFAULT (for suite) lists. kairo has given approval on irc for this patch; bsmedberg, could you please review the build change?

Without an owner for the maintenance of this code, it seems difficult to justify its continued inclusion, especially if it is no longer functioning as intended. However, I have to disagree about the assumption that no one is using this capability. Advertising networks (including Tacoda, for whom I now work) and measurement firms rely on P3P compact headers to declare that they will not merge information collected with cookies with personally identifiable information. These advertising networks serve approximately 99% of advertising-supported web publishers, so although the number of servers issuing P3P compact headers is relatively small, the number of web sites on which they serve content with compact headers is large. I have heard estimates that as much as 90% of all advertisements served on the internet involve a P3P compact header to which the FTC can enforce compliance under truth in advertising rules. The reason why the use of P3P compact headers is limited is because for the most part they do not affect default and mainstream user agent behavior for first party web sites. P3P compact headers DO make a difference (at least for IE 6+) for third parties because those third parties are largely invisible to users and their interaction and data collection is involuntary and has more onerous data protection implications. Thus the intent of both my original IETF draft ("Trust labels" based on PICS) and P3P compact headers was that browsers should have a higher standard for default treatment of third party cookies that doesn't totally prevent smaller web sites that rely on third parties advertisements from competing with the large portals. The most widespread uses of the third party cookies described by P3P compact headers that are often considered non-controversial are: 1) counting anonymous unique visitors to a site or who see a specific advertisement, 2) limiting the number of times a visitor is shown the same ad, 3) letting advertisers know their marketing was effective by letting them count how many unique visitors made a purchase or took an action on their site after seeing an advertisement they paid for at another site. Without P3P, there is no way to distinguish anonymous third party cookies that are at least subject to some regulatory oversight without also allowing more malicious uses of the technology (merger with PII, etc.). Again, without an owner (and I am not volunteering :-) I cannot argue for its continued inclusion. I don't think the p3p.xml based privacy report functionality is widely used. I just wanted to point out the potential implications and clarify where the technology is being actively used.

(In reply to comment #10) >especially if it is no longer functioning as intended. Firefox doesn't use P3P but as far as I know it's still usable in SeaMonkey (it's off by default) - how would I know whether it's functioning as intended?

Comment on attachment 264344 [details] [diff] [review] remove p3p from built extensions (checked in) r=me as long as the SeaMonkey folks don't care about it.

Comment on attachment 264344 [details] [diff] [review] remove p3p from built extensions (checked in) checked in to trunk.

This has caused no problems. Can we go and cvs remove this and have this bug finally fixed?

i'll take care of this in the next few days, and file a followup bug to remove various p3p hooks around the place (esp. in cookie code).

removed extensions/p3p. the only remaining references to it are the ui components in suite (bug 383993) and the p3p hooks in cookie code (bug 383994), which can be taken care of separately.