2.79 KB, patch
Darin Fisher: superreview-
|Details | Diff | Splinter Review|
1.36 KB, patch
|Details | Diff | Splinter Review|
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.
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?
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.
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.
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)
Created attachment 146937 [details] [diff] [review] turn p3p off by default and revert pref to pre-p3p state
Mike, I'm not doing srs right now (see the super-reviewers page). You'll need to find someone else.
Comment on attachment 146937 [details] [diff] [review] turn p3p off by default and revert pref to pre-p3p state r=dwitte
_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.
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?
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?
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.
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.
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 firstname.lastname@example.org?
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 on attachment 146937 [details] [diff] [review] turn p3p off by default and revert pref to pre-p3p state bummer.
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 on attachment 153863 [details] [diff] [review] revert pref to "accept all" (checked in) agreed
Comment on attachment 153863 [details] [diff] [review] revert pref to "accept all" (checked in) sr=dveditz
What other releases need this patch? /be
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.
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.
Not going to be working on any Seamonkey UI bugs for the foreseeable future. You can filter on "danlikesgoats" to delete this spam.
Please do not do this. The suite needs unique features. why copy firefox?
bug 366611 has been filed for completely removing the unowned and unmaintained p3p module completely from trunk
neither firefox nor seamonkey build p3p anymore. marking fixed.
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) ? :(
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.
Ah, makes sense.. thanks for info ;)