Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Remove p3p from the default build

RESOLVED FIXED

Status

()

Core
Networking: Cookies
RESOLVED FIXED
14 years ago
10 years ago

People

(Reporter: mconnor, Unassigned)

Tracking

Trunk
Points:
---
Bug Flags:
blocking1.7.5 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

14 years ago
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

14 years ago
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

14 years ago
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

14 years ago
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.
(Reporter)

Comment 4

13 years ago
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)
(Reporter)

Comment 5

13 years ago
Created attachment 146937 [details] [diff] [review]
turn p3p off by default and revert pref to pre-p3p state
Assignee: dwitte → mconnor
Status: NEW → ASSIGNED
(Reporter)

Updated

13 years ago
Attachment #146937 - Flags: superreview?(bzbarsky)
Attachment #146937 - Flags: review?(dwitte)

Comment 6

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

Updated

13 years ago
Attachment #146937 - Flags: superreview?(bzbarsky) → superreview?(darin)

Comment 7

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

r=dwitte
Attachment #146937 - Flags: review?(dwitte) → review+

Comment 8

13 years ago
_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

13 years ago
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?
(Reporter)

Comment 10

13 years ago
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

13 years ago
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

13 years ago
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

13 years ago
dveditz writes some "proprietary legacy code", does this affect you?
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

13 years ago
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.
Attachment #146937 - Flags: superreview?(darin) → superreview-
(Reporter)

Comment 16

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

bummer.

Comment 17

13 years ago
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.

Updated

13 years ago
Attachment #153863 - Flags: superreview?(dveditz)
Attachment #153863 - Flags: review?(mkaply)

Comment 18

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

agreed
Attachment #153863 - Flags: review?(mkaply) → review+
Comment on attachment 153863 [details] [diff] [review]
revert pref to "accept all" (checked in)

sr=dveditz
Attachment #153863 - Flags: superreview?(dveditz) → superreview+
What other releases need this patch?

/be
Flags: blocking1.7.3+

Comment 21

13 years ago
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.
Attachment #153863 - Attachment description: revert pref to "accept all" → revert pref to "accept all" (checked in)
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.
"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.
(Reporter)

Comment 24

12 years ago
Not going to be working on any Seamonkey UI bugs for the foreseeable future. 
You can filter on "danlikesgoats" to delete this spam.
Assignee: mconnor → nobody
Status: ASSIGNED → NEW

Comment 25

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

Comment 26

11 years ago
bug 366611 has been filed for completely removing the unowned and unmaintained p3p module completely from trunk
Blocks: 366611

Comment 27

10 years ago
neither firefox nor seamonkey build p3p anymore. marking fixed.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED

Comment 28

10 years ago
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

10 years ago
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

10 years ago
Ah, makes sense.. thanks for info ;)
You need to log in before you can comment on or make changes to this bug.