directories. Or, more specifically, with the users inability to
override this default behaviour.
(I.e. ".../username/132da5.slt/...")
This is discussed under two different Bugzilla bug reports:
http://bugzilla.mozilla.org/show_bug.cgi?id=56002
http://bugzilla.mozilla.org/show_bug.cgi?id
>and i think its silly to call it stupid. it may not be worth the
>provide but which mozilla works around to provide. "if you wish to
>use mozilla, use NT or Linux" is a meagre response, imho.
I agree with you on this one. It seems slightly hypocritical
and/or confused to me that the Mozill
> The feature being requested is not a security measure, it is security
> snake oil. This is precisely the sort of misfeature that, when broken,
> causes a lot of bad press for a product.
Then what do you call password protecting your list of passwords to
various Web sites, or password protec
> >Then what do you call password protecting your list of passwords to
> > various Web sites, or password protecting your list of auto-fill
> > forms?
> You need to acquaint yourself with what is being requested. The password
> list and auto-fill password protection is implementing using s
> It still doesn't explain why we need PSM if the holy OS deals with
> security. Protecting my form data should then also be dealt with by my
> OS user profile.
Exactly! There are only 3 consistent approaches that can be taken
to this issue:
1. Have no security in Netscape at all and "let
> That's complete nonsense. PSM's primary function is SSL (https etc.) and
> S/MIME. Password encryption is only a minor function that were added
> only recently. (Does 4.x even have it?)
Then - why was password encryption added? Again, the argument
doesn't work. It makes no sense to argue
> Good grief! If you know how to use Windows Search, you're considered a
> "power user"? I can customize my start menu, does that make me a 1337 h4x0r?
It's sad, but true. I've had to support thousands of "end
users" at various companies during my career, as well as friends and
family, and t
> Anyway, as it pertains to this argument, I still tend to think that we
> can do without profile passwords: Anyone who knows how to set up a
> profile can figure out their own workaround - eg run windows in
> so-called multiuser mode with separate desktops, and add "-P whoever" to
> every shortcu
> 2. If "Always" is selected, windows opened by javascript will require a
> click before they can call window.open anyway. This will let users kill
> "hydras" as easily as they can kill normal pop-up ads. However, after
> the user clicks, the window will revert to the "Always" setting, becaus
> When I said "windows opened by javascript will require a click before
> they can call window.open", I didn't mean that the user would have to
> click "yes" in a dialog. I meant that if a window is opened by
> javascript, scripts in that new window wouldn't be able to open new
Oh. Never
> What *I* want is not possible, not even with backend prefs: Never open a
> new window unless I triggered it directly by e.g. a click. I.e. allow
> window.open when (effectively) called from oncommand or onclick or
> similar, but never from onload or onunload.
That would be absolutely perf
Is there any method of automatically rejecting ALL cookies except for
those from sites that are listed in a whitelist, i.e. those that
you've manually told Mozilla to accept cookies from?
1. If you set Mozilla to disable cookies it does not honour your
whitelist.
2. If you have it always ask, yo
Nevermind - I tracked down an existing bug on this specific topic:
http://bugzilla.mozilla.org/show_bug.cgi?id=75915
The short answer is that, no, this is not possible at present.
(Although it's being worked on.)
Jason.
> user_pref("capability.policy.default.window.open", "noAccess");
> user_pref("capability.policy.non_spammers.sites", "http://www.microsoft.com";);
> user_pref("capability.policy.non_spammers.window.open", "allAccess");
> user_pref("capability.policy.non_spammers.windowinternal.open", "allAccess")
> It doesn't matter if Mozilla is running or not when I edit
> the file. The fact is that if Mozilla starts up with those
The reason for the response is that any changes you make to the
prefs.js file while Mozilla is running are lost when you exit the
application. The only way to make permane
> I'm sorry but what are saying simply appears to be wrong.
> I just now added these lines to my defaults/pref/security-prefs.js file:
> user_pref("capability.policy.default.Window.open", "noAccess");
The above is what I said. The reason it didn't work for you before
is because you didn'
> You quit mozilla *after* you edited the file? That's wrong; as the
> message you are replying to quoted from the 0.9.2 release notes:
>
> > > To block pop-up windows, add this line to the prefs.js file
> > > in your Mozilla profile directory while Mozilla is not running:
Yes, but if you not
> I just added *exactly* what you wrote to my 'defaults/pref/security-prefs.js'
> file, restarted Mozilla, and went to 'http://www.wpi.edu/~dpotter/infinite.html'
> and that page had no problem popping up windows on my computer.
> Either way, the fact is that nothing anyone has suggested has stop
> Why does everyone hate the salting so much?
Nobody is objecting to the security benefits of salted directories.
(At least I'm not.) People are simply objecting to the inability of
the user to turn OFF this features through a preference if desired.
Personally, I don't want some random d
> Any installed application imposes some constraints on directory
> structure, and Mozilla is no exception.
It IS an exception in the fact that the salted directory is random.
Even those applications that don't let the user choose install
location / directory name are not random. If Mozilla
> Does the salting dir get added when the user specifies an explicit path
> during creation? It shouldn't. (We're just trying to prevent guessing of
Unfortunately, yes. This brought up criticism of the UI "lying" to
the user and ignoring their specifically chosen explicit path. (My
other "
> Personally, I would prefer more unpredictability. My profile could be
> named "Ben", and if somebody starts an attack targetted at my
> personally, it would not be hard to guess.
Why not, then, implement something akin to the UNIX/Linux password
strength checker? Unless you enter somethi
> Are the UIless cookie prefs documented anywhere?
Good question. I understand that there IS some method of forcing
cookie expiration times (after session or X days) but I have no idea
where to find that information.
> I'd like to do the following:
> * Enable persistent cookies for bugzilla.
> That blocking we did of certain ports (1080, etc.) to stop Mozilla
> connecting to them is breaking people's sites. See several recent posts
> in n.p.m.general and security.
I think that port blocking should be enabled by default (it's a
good security precaution), but there should be a way o
> You can limit the lifetime of cookies. (The prefs are not yet listed in
> all.js.) See bug 53354.
The only possibility I can see there are from your source code for
a possible fix that was then rejected by morse.
+user_pref("network.cookie.lifetimeLimit",0)
But if the patch wasn't che
> page. Please give this a try, and post feedback about how this feature
> could be improved.
Excellent! It works just fine so far, bypassing the need to have a
whitelist. I haven't yet seen a popup that I didn't want, nor have I
not receieved a popup that I did want.
It's interesting b
26 matches
Mail list logo
