Last Comment Bug 225287 - Remove p3p from the default build
: Remove p3p from the default build
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Networking: Cookies (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on:
Blocks: 366611
  Show dependency treegraph
 
Reported: 2003-11-10 20:32 PST by Mike Connor [:mconnor]
Modified: 2007-11-28 09:45 PST (History)
17 users (show)
brendan: blocking1.7.5+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
turn p3p off by default and revert pref to pre-p3p state (2.79 KB, patch)
2004-04-24 13:57 PDT, Mike Connor [:mconnor]
dwitte: review+
darin.moz: superreview-
Details | Diff | Review
revert pref to "accept all" (checked in) (1.36 KB, patch)
2004-07-20 22:13 PDT, dwitte@gmail.com
mozilla: review+
dveditz: superreview+
Details | Diff | Review

Description Mike Connor [:mconnor] 2003-11-10 20:32:50 PST
Its big, its really not used by anyone, and the UI isn't exactly sterling (like
the p3p statusbar icon which appears, then never goes away).

Its not to say it doesn't have any value, but not for 98% of users.
Comment 1 dwitte@gmail.com 2003-11-10 20:36:07 PST
it's also the default cookie behavior pref for new profiles.

i'm not doing anything here until we have input from the p3p folk... what are
your thoughts on this?
Comment 2 Alec Flett 2003-11-10 22:38:56 PST
I'm not a p3p person, but I have my doubts that 'its big'.. and the claim of not
being used by anyone.. well it seems like a random claim that I could make about
any component that I don't personally use.

Comment 3 Axel Hecht 2003-11-11 04:50:14 PST
I'd expect to get a driver-filed bug on removal of functionality.
And a pre-announcement in .seamonkey. That is, drivers should be willing to put
up with the public heat before removing it.
Comment 4 Mike Connor [:mconnor] 2004-04-24 13:41:35 PDT
approximately 30k of code (p3p.dll is 32k on a recent SM nightly) and probably
40k of chrome.  I guess people could argue "a drop in the bucket" but its 60k on
disk, with whatever memory footprint that entails (since we use it by default)
Comment 5 Mike Connor [:mconnor] 2004-04-24 13:57:55 PDT
Created attachment 146937 [details] [diff] [review]
turn p3p off by default and revert pref to pre-p3p state
Comment 6 Boris Zbarsky [:bz] (Out June 25-July 6) 2004-04-24 14:00:50 PDT
Mike, I'm not doing srs right now (see the super-reviewers page).  You'll need
to find someone else.
Comment 7 dwitte@gmail.com 2004-04-24 23:44:12 PDT
Comment on attachment 146937 [details] [diff] [review]
turn p3p off by default and revert pref to pre-p3p state

r=dwitte
Comment 8 Alec Flett 2004-04-25 12:37:18 PDT
_40k_ of chrome? that's insane, and frankly I'm doubtful.

look, I'm all for cutting down extraneous code, but the way this has been
handled kind of saddens me. Was this run by drivers or staff? It just seems like
we're cutting a feature just because someone filed a bug about it.
Comment 9 dwitte@gmail.com 2004-04-25 13:17:01 PDT
Well, Mike did post in npm.seamonkey about it... the only driver to respond to
that posting was Asa, overall it didn't attract much attention. Would you prefer
feature removal to have the support (or majority concensus) from all of the
drivers? Would you prefer it to be brought up at, e.g., a staff meeting so that
they're all aware of it?

I'd also add that this bug wasn't filed by "somebody" - mconnor is a peer to
cookies now, and disabling of p3p has the support of mvl and myself. While this
doesn't give him authority over p3p, I'd say it does give him authority over the
cookie UI, to decide what's useful to a large number of users and what's not.

Do you have some suggestions for what we might do here, to make a more
convincing case?
Comment 10 Mike Connor [:mconnor] 2004-04-25 13:39:56 PDT
http://lxr.mozilla.org/seamonkey/source/extensions/p3p/resources/

it's actually well over 40k between content and locale.

Camino and Firefox have long since dropped p3p without harmful effects to users.
 Since the only major embedding project still using it is Seamonkey, which is
due to rot on the trunk based on recent n.p.m.seamonkey comments by Brendan,
continuing to support it is a limited-time process anyway.  Assuming we start to
make bigger, compatibility-breaking API changes at some point, who is going to
step up to maintain p3p, especially since its not supported by the future
products from MF?
Comment 11 Darin Fisher 2004-04-28 00:43:59 PDT
I think a change like this should definitely require explicit approval from
drivers.  Remember, Seamonkey is supposed to be on a sustaining path =)

There may be some enterprise customer out there who happen to like this feature.
Comment 12 Mike Kaply [:mkaply] (Out June 27-July 5) 2004-04-28 05:15:44 PDT
Ah the memories.

We (IBM) wrote the original P3P implementation and then Netscape proceeded to
write their own.

So both our companies wasted immense amounts of time that everyone thought was a
crappy proposal to begin with.

Remove it.
Comment 13 Axel Hecht 2004-05-04 00:03:53 PDT
dveditz writes some "proprietary legacy code", does this affect you?
Comment 14 Daniel Veditz [:dveditz] 2004-05-04 09:20:46 PDT
My problem was a previous fix changed the default P3P action to REJECT in error
cases, which only matters to me because P3P is the default cookie setting. The
change here would work around my problem.

I'm 100% behind changing the pref and would sr= that in a heartbeat. Removing
P3P entirely, though, would require more discussion. Why has no one flown this
by drivers@mozilla.org?
Comment 15 Darin Fisher 2004-06-08 15:06:57 PDT
Comment on attachment 146937 [details] [diff] [review]
turn p3p off by default and revert pref to pre-p3p state

Despite comment #12... the latest word from my employer is that P3P matters to
enterprise customers.  I must therefore sr- this patch.
Comment 16 Mike Connor [:mconnor] 2004-06-08 15:11:33 PDT
Comment on attachment 146937 [details] [diff] [review]
turn p3p off by default and revert pref to pre-p3p state

bummer.
Comment 17 dwitte@gmail.com 2004-07-20 22:13:45 PDT
Created attachment 153863 [details] [diff] [review]
revert pref to "accept all" (checked in)

while we're seeing if there's enough concensus to disable building p3p by
default, i think the least we can do is change the default pref.

we're getting bugs filed about p3p "not working", which frankly is embarassing
to me - while bugs are inevitable, it seems unprofessional to knowingly
distribute this code when we have no owner to actively investigate and fix
problems as they arise. per mozilla.org/roadmap, this would at least suggest
that the appropriate course of action would be to reduce user exposure to this
code, until (a) we determine that it won't cause undue problems to disable it
in the default build, or (b) we find an active maintainer.

so, given that we do want to support seamonkey for a long time to come, i think
the responsible thing to do, for now, is change the default pref.
Comment 18 Mike Kaply [:mkaply] (Out June 27-July 5) 2004-07-21 06:39:01 PDT
Comment on attachment 153863 [details] [diff] [review]
revert pref to "accept all" (checked in)

agreed
Comment 19 Daniel Veditz [:dveditz] 2004-08-05 12:09:41 PDT
Comment on attachment 153863 [details] [diff] [review]
revert pref to "accept all" (checked in)

sr=dveditz
Comment 20 Brendan Eich [:brendan] 2004-08-05 12:31:52 PDT
What other releases need this patch?

/be
Comment 21 dwitte@gmail.com 2005-01-13 19:25:00 PST
Comment on attachment 153863 [details] [diff] [review]
revert pref to "accept all" (checked in)

i noticed this patch was never checked in to trunk. remedied.
Comment 22 Daniel Veditz [:dveditz] 2005-01-14 12:19:31 PST
Wouldn't "dontAcceptForeign" be a better default, more in keeping with our
general concern for privacy and security? Too much breaks if we turn off cookies
entirely--let the paranoids do that for themselves--but nothing good comes from
foreign cookies.
Comment 23 Mike Shaver (:shaver -- probably not reading bugmail closely) 2005-01-14 13:44:48 PST
"Foreign" cookies -- for varying definitions of foreign -- are sometimes used as
part of a single-sign-on system for intranet apps.  They may well all be
assigned down to the same domain suffix, and therefore not be counted as
"foreign" for our purposes, but it would suck a lot to break those systems.

I'll play with my prefs and see what I can break in Oracle's, when I get a chance.
Comment 24 Mike Connor [:mconnor] 2005-09-07 12:39:15 PDT
Not going to be working on any Seamonkey UI bugs for the foreseeable future. 
You can filter on "danlikesgoats" to delete this spam.
Comment 25 Sam Katz 2006-10-28 21:58:56 PDT
Please do not do this. The suite needs unique features. why copy firefox?
Comment 26 Robert Kaiser (not working on stability any more) 2007-01-10 14:15:54 PST
bug 366611 has been filed for completely removing the unowned and unmaintained p3p module completely from trunk
Comment 27 dwitte@gmail.com 2007-06-08 20:16:09 PDT
neither firefox nor seamonkey build p3p anymore. marking fixed.
Comment 28 STEvil 2007-11-27 23:31:55 PST
Hey guys just wondering how current versions of Firefox handle this issue?  I was listening to a webcast (http://media.grc.com/sn/SN-119.mp3) from Leo Laporte and Steve Gibson that is about how Paypal and Doubleclick.net are playing hooky with each other and firefox (mozilla as a whole actually) does nothing about this then doesnt that void a lot of the "security" selling point firefox offers over IE or others?

Firefox is my favorite browser, say its on the list of being fixed (or is fixed in current versions) ? :(
Comment 29 dwitte@gmail.com 2007-11-28 01:32:19 PST
the issues discussed in that webcast really don't have much to do with p3p; but in fact we are switching off 3rd party cookies *by default* for firefox 3 (see bug   	324397), which no other browser currently does. there's really not much we, or anyone, can do about redirects though, which is what paypal is using.
Comment 30 STEvil 2007-11-28 08:39:08 PST
Ah, makes sense.. thanks for info ;)

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