Closed Bug 128639 Opened 23 years ago Closed 22 years ago

"Enable Cookies based on privacy levels" missing in Cookies prefs panel

Categories

(Core :: Networking: Cookies, enhancement)

Product:
Core
Component:
Networking: Cookies
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: ralentz, Assigned: harishd)

References

Details

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8+) Gecko/20020226 BuildID: 2002030109 I have enjoyed using the "Enable Cookies based on privacy levels" option on the Cookies prefs panel, currently in 2002022603. This morning I tried 2002030109 (at least the build from that ftp directory) and it was missing from the preferences panel. I was left with only the less powerful options (though fortunately it did not revert my preference to one of the listed options). -Robert Reproducible: Always Steps to Reproduce: 1. Select Edit -> Prefences. 2. Open the "Privacy & Security" area. 3. Then select the cookies panel. Actual Results: The cookie choice I was used to did not appear, only less powerful options were presented. Expected Results: Listed the choice of basing cookie acceptance upon privacy level.
I dunni if we have already the p3p enabled in the builds. The pref were removed with bug 126360
You were fooled before into thinking that you had been blocking cookies based on your privacy prefences. In truth, the module that parses the compact policy has never been turned on in the build. So the cookie module, which does a call to the parser module, was not finding that module and therefore just "pretending" that it knew what the compact policy said. So this week I put in new code to remove the choice from the UI if the parser module is not found. That is what you are now seeing. The parser module is in source tree, but it does not get built by default. If you manually do nmake -f makefile.win in the extensions/p3p directory, it will get built. I don't know when that directory is going to start being built by default, nor do I know why it hasn't been done up until now.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
*** Bug 130264 has been marked as a duplicate of this bug. ***
*** Bug 131004 has been marked as a duplicate of this bug. ***
Are we to take it, then, that the standard Mozilla releases will *not* have p3p turned on?
It will, once harishd gets approval to do so.
My request got denied. So, p3p will not be enabled in mozilla by default. In order to enable it we need voices from the mozilla community requesting for P3P.
And where should these voices be raised? (ie: who do we need to bug?)
OK here's my voice, what do I do with it :) I'll hit that 'vote for this bug' link for starters. Maybe if a fair amount of people are needed to back the idea, someone could put it on the front page for Mozilla.org? It might just be that not many people have noticed yet, or even thought about looking up the bug if they have. I'm really big on privacy, though still like cookies to work on honourable sites... which makes p3p ideal for me, for all the obvious reasons. It'd seem like a huge missing feature (one where IE6 has a major advantage). As an idea of how important, I'd probably use IE as my main browser for this unless there's a p3p option or plugin with the release version.
You can always turn it on yourself if you can build the product. Simply go to the extensions/p3p directory and do nmake -f makefile.win.
May be you can use the news group ( news.public.mozilla.seamonkey ). Also, you can vote in bugzilla ( http://bugzilla.mozilla.org/votehelp.html ).
Compiling in the option from the source code is probably fine for me, but definitely not an option for the ordinary everyday users who will hopefully be using it when 1.0 comes out... I'm thinking of those who are average users, but don't want to use the full Netscape with all the AOL additions. Chances are they won't know how to compile from source, let alone be inclined to :)
Compiling from source doesn't bother me under Linux, but I don't have the time/money/patience to set up a build environment for Windows, and I need Mozilla for Windows too.
*** Bug 131045 has been marked as a duplicate of this bug. ***
I'll add my vote for P3P turned on by default. It's not perfect, but it makes it simpler to implement a policy of "accept cookies from sites that use them for benign purposes but not anybody else". Without it I need a huge block list and have to keep checking daily for new sites I need to block. With it I just need a list of sites that lie in their P3P policy. Various advertisers and commercial site operators might not want P3P on by default, but IMHO the Mozilla configuration shouldn't be driven by what non-users want.
I'd like to add my two cents' to get P3P put back in. It's useful, and it's a competitive feature (IE has it).
Clarification here! It's not a matter of putting it back in -- it never was in to start with. There was a UI but it did nothing because the underlying code was never part of the build. The change that I made recently was to hide the UI if the underlying code was not present.
Morse: I'm surprised, because I'm fairly sure I saw a couple of cases where cookies were doing funky things when I changed the behavior in the P3P UI. I could be wrong, but changing settings in that dialog did affect some of my cookie settings, and also made changes to prefs.js.
OK, let me clarify further. The code in the UI to collect your preferences and write them to the prefs.js file is there (and has been for many months). And the code in the cookie module that acts upon the p3p settings that you made is also there and has been for a while. If you had set your preferences to block in all cases, it indeed would have blocked. However if you set it to block in certain settings, based on what was stated in the compact policy sent back by the site, then you were being fooled. That's because the code that parses the compact policy didn't exists (that's what's in extensions/p3p which is not turned on). So if the cookie module detected that the compact-policy-parser module (i.e., p3p module) was not present, it just made up a policy (I forget what value I had hard-coded that to be). And that's what you were observing. So the cookie behavior that you were observing had absolutely nothing to do with any privacy policy from the site. I did a great job of fooling you into thinking that I was protecting your privacy. Perception is not always reality! ;-)
Is extensions/p3p turned off because it doesn't work right, or because someone's explicitly decided it should be turned off, or just by default because nobody's pushed to have it turned on?
Todd Knarr: Why not read the bug before you add a comment ? p3p was NEVER enabled. We had only the pref (without backend)
Matthias: I did. See Stephen Morse's comment #10, which seems to say that the back-end does exist and works if you explicitly enable it, it just isn't enabled in the default build configuration, and other bugs seem to indicate the back-end is working at least as far as handling compact policies. Hence my question as to the possible reasons for not enabling it by default.
*** Bug 131101 has been marked as a duplicate of this bug. ***
*** Bug 135468 has been marked as a duplicate of this bug. ***
Since this bug was invalidated on the basis that P3P was never enabled, and bug 135468 requesting the feature to be enabled was marked a dupe... I'm morphing this to a RFE. Updating summary, severity, resolution, Platform/OS...
Severity: normal → enhancement
Status: RESOLVED → UNCONFIRMED
OS: Windows NT → All
Hardware: PC → All
Resolution: INVALID → ---
Summary: "Enable Cookies based on privacy levels" missing in Cookies prefs panel → Enable P3P in nightly builds / "Enable Cookies based on privacy levels" missing in Cookies prefs panel
Confirming (don't hit me, timeless!)
Status: UNCONFIRMED → NEW
Ever confirmed: true
this is harish's. See comments in bug 135468.
Assignee: morse → harishd
To address timeless' concerns about p3p's inherent complexity expressed in one of the bugs marked a duplicate of this one (I don't recall which!), implementing APPEL may be helpful. APPEL specifies an XML format to import p3p preferences. This would mean extensive p3p "options" could be provided under simple(r) labels, as well as allowing 3rd parties (or possibly concerned parties at mozilla) to make customized p3p preferences. I think having the ability to import and export APPEL documents would make cookie control much "smoother" (there are ample tools already in existence for creating APPEL documents from scratch). I've made an RFE for adding APPEL here: http://bugzilla.mozilla.org/show_bug.cgi?id=135551 Oh, voted for this bug too. Not only is p3p a "standard", its pretty neat.
Sam: I agree with you APPEL is a good thing to have. But it's of no use without the full implementation of P3P. Please open up a separate bug requesting for APPEL support. Thanx.
harishd: he already filed a bug for it, at: http://bugzilla.mozilla.org/show_bug.cgi?id=135551 i've just confirmed that bug.
*** Bug 153990 has been marked as a duplicate of this bug. ***
In bug 124503 comment 70, Heikki said: "Currently the P3P code is in Netscape's tree because MOZILLA.ORG DID NOT WANT IT IN MOZILLA TREE (the code that is in the mozilla.org tree is very outdated)." Does that mean that you can't get the latest and greatest P3P stuff in Mozilla even if you're willing to build it yourself?
RE comment #32: "MOZILLA.ORG DID NOT WANT IT [P3P code] IN MOZILLA TREE" -> Has a reason for this (bad?) decision be made public somewhere?
Hello! It's 2003 and nothing is happening w/ this bug! What's going on!? Just trying to call attention to the bug.
Blocks: 121842
taking P3P bugs
QA Contact: tever → gbush
Well, the Netscape P3P code now IS in the Mozilla tree (see bug 177822), just not enabled...
Splitting bug because of bug 198089.
Depends on: 198089
Summary: Enable P3P in nightly builds / "Enable Cookies based on privacy levels" missing in Cookies prefs panel → "Enable Cookies based on privacy levels" missing in Cookies prefs panel
Hasn't this actually been fixed? As of the 3/25 builds, I'm now seeing privacy level UI for cookie prefs - although I haven't actually made use of it to see if it works or not...
Based on the original bug report (and title), and from looking at the UI on 2003032611-TRUNK, it looks fixed to me. Since I wasn't really involved in this bug, I'm not going to change the Status.
fixed with bug 198089 and bug 198148
Status: NEW → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → FIXED
verified 4/1 build
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.