225287 - Remove p3p from the default build

Status: RESOLVED FIXED

(Core :: Networking: Cookies, defect)

Description

[Mike Connor [:mconnor]]

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

[[e-mail]]

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]

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]

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]]

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]]

Attachment: turn p3p off by default and revert pref to pre-p3p state

Comment 6

[Boris Zbarsky [:bzbarsky]]

Mike, I'm not doing srs right now (see the super-reviewers page).  You'll need
to find someone else.

Comment 7

[[e-mail]]

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]

_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

[[e-mail]]

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]]

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]

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]]

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]

dveditz writes some "proprietary legacy code", does this affect you?

Comment 14

[Daniel Veditz [:dveditz]]

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 [e-mail]?

Comment 15

[Darin Fisher]

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]]

Comment on attachment 146937 [details] [diff] [review]
turn p3p off by default and revert pref to pre-p3p state

bummer.

Comment 17

[[e-mail]]

Attachment: 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]]

Comment on attachment 153863 [details] [diff] [review]
revert pref to "accept all" (checked in)

agreed

Comment 19

[Daniel Veditz [:dveditz]]

Comment on attachment 153863 [details] [diff] [review]
revert pref to "accept all" (checked in)

sr=dveditz

Comment 20

[Brendan Eich [:brendan]]

What other releases need this patch?

/be

Comment 21

[[e-mail]]

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]]

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)]

"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]]

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]

Please do not do this. The suite needs unique features. why copy firefox?

Comment 26

[Robert Kaiser]

bug 366611 has been filed for completely removing the unowned and unmaintained p3p module completely from trunk

Comment 27

[[e-mail]]

neither firefox nor seamonkey build p3p anymore. marking fixed.

Comment 28

[STEvil]

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

[[e-mail]]

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]

Ah, makes sense.. thanks for info ;)