Closed Bug 128639 Opened 23 years ago Closed 21 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 → 21 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.