This is a request for enhancement. It's overdue in mozilla, in the competition, and demanded by champions and users. When I or Chuck Simmons (email@example.com, netscape champion) or many others surf the wilds of the Internet, we turn JS off. Why? Paranoia, good sense, whatever -- it doesn't matter. Mozilla has not had its last security hole closed. This goes for JS, Java, HTML layout (remember the Danish form-type-change attack), netlib, etc. Then there are denial of service attacks to consider. OK, what can be done? This bug (really, RFE) asks that mozilla at least automate the disabling of executable content when surfing away from URLs that begin with host parts from a known-trustworthy set of fully-qualified domain names. That requires preference UI support, I suppose. Although with just the pref checking code in libmocha and the Java glue, and with a signed script that called navigator.preference, we (or anyone trusted) could construct a "set your shields-up preferences" page on mozilla.org, home.netscape.com, that acted as a web-server-based pref UI. So Mike, can you bug me about implementation, do the libmocha hacks (or find someone else to do them), then reassign this bug to raman for Java? We should figure out the pref syntax and value types first, make them common and extensible. After you and raman are done, we can give it to german for UI consideration -- but the web-based pref UI approach seems better to me. /be
Certainly; it'll probably just be a few weeks before I can start pushing full speed on it. (I have 4.x merges to take care of first.)
> We could invent a magic domain for all JS-in-mail that defaults to deny, but > which you could selectively enable (see next). s/JS-in-mail/JS-in-unauthenticated-mail/ For SMIME etc., we can use the host part of the From address as the domain to allow or deny. /be
Setting all current Open/Normal to M4.
per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
QA contact re-assigned according to the product areas we're currently working on.
The code from Lucent will accomplish some of these. We can look adding this particular feature to it as well. But this isn't for M4. Moving to M6
People have been requesting feature-wise disabling, e.g., window.open -- if that's done, it should be per-domain and/or all-but-this-domain too. /be
I'll take this on my plate. No promises on implementation for 5.x, but I see why this feature would be desirable.
Any restrictions should also apply to window.status and toolbar changes in the current window as well as any new windows. Perhaps also restrict access to java as well.
Bug #7380 is a superset of this functionality.
Is the Lucent code anywhere we can get to? There's a lot of interest in this particular feature, and we might be able to get someone else to do the hevy integration lifting for us.
There already seems to be some cookie people doing a site by site feature, if you're gonna do this, you might want to touch base with them over a set of common APIs. See my comments in bug #7380.
norris? joki? bueller? What's the deal with the Lucent code? People are itching to see this stuff, and I'm sure some of them would help us out, but we're all waiting to see what Lucent's stuff gives us first. We're a long way from the original M6 estimate; is M9 a ``real'' plan?
Depends on 7254, which is M10.
I'm working to enable the core security code in caps, some of which we're migrating from dom. This includes joki's work to port the code from Vinod Anupam and Alain Mayer, the Bell Labs researchers (see http://www.mozilla.org/projects/security/ for a couple of their papers). Right now the code is butt-ugly, a consequence of being ported too many times by different people. I'll be bringing up the functionality and cleaning up the code.
*** Bug 11931 has been marked as a duplicate of this bug. ***
I've posted a quick, rough web page on the configurable security policies that are a new feature that many people would like to see in mozilla. http://www.mozilla.org/projects/security/configPolicy.html Discussion in netscape.public.mozilla.security
Why do you feel that my bug #7380 proposals are not worth implementing? Are they too complex? Is there not enough time? If the latter is the case, I'm worried that any decision now may lock in interface declarations that will be inflexible later. Have you discussed your model and possible shared architecture and UI with smorse, who knows about the current implementation of the exact same thing for cookie acceptance? This is a lot broader than the security issues, or at least it should be. I believe the whole point of writing Gecko, Necko, etc was to get past the old architecture which wasn't designed as well as it could be ... I apologise for my tone which could be interpreted as haughty, but I've been railing on about this issue for a while now and no-one has given me any feedback. I only want to avoid problems in future.
Time's a factor, but I didn't look through your 7380 proposals to incorporate them into my document. Even if we don't implement full functionality for 5.0, I don't want to prevent future development. I'll try to look over 7380 and take it into account.
Can the "sites" pref's value be a comma-separated list? Is the "http://" really necessary? And (final question!) how hard would it be to do the "...sites['warp.mcom.com']" thing, i.e., a pref for each site, whose value told how that site was handled? Then no CSV parsing, just constant-time pref hash table lookup. /be
I just checked in the changes that enable this. To answer brendan's questions: >Can the "sites" pref's value be a comma-separated list? Space separated. See http://www.mozilla.org/projects/security/configPolicy.html >Is the "http://" really necessary? It's required now. I guess we could have a rule that if there is no colon, then the scheme defaults to http. > And (final question!) how hard would it be to do the > ...sites['warp.mcom.com']" thing, i.e., a pref for each site, whose value told > how that site was handled? Then no CSV parsing, just constant-time pref hash > table lookup. I maintain a hash table that maps from a domain to the name of the policy. My thought was that people will want to deal with groups of sites when setting policies like the Lucent proposal or with IE's zones. I'll mark this bug fixed; requests for additional changes can be logged either by reopening this or by filing additional bugs.
After reading norris's comments, I feel that this one should be verified, and requests for additional changes could be made by filing new bugs. Marking Verified.
Moving all CAPS bugs to Security: CAPS component. CAPS component will be deleted.
*** Bug 40005 has been marked as a duplicate of this bug. ***
Is there a prefs UI tracking bug for this?
There's bug 7380, but no UI-specific bug. If you file one, please CC me on it.
*** Bug 69144 has been marked as a duplicate of this bug. ***
I believe there is a bug that restricts setting capability prefs to the default prefs in the installation directory; they don't work from a profile. Use pref() not user_pref().
How about furthering IE's ability to set all security on a site-per-site basis and fully allowing the user to make their own named "zone" and ability to put sites in it? Huge addition to prefs file, but a one-up to IE.
Is it possible to declare the sites preference with wildcards like: pref("capability.policy.UBS_trustable.sites", "http://*.ubs.com"); or: pref("capability.policy.UBS_trustable.sites", "ubs.com"); The idea behind this is to enable privileges for an entire intranet. Big companies cannot configure all their webservers by name in the preference-string. This is not maintainable. Thanks for any info. Hugo Kortschak
An extension which is an easy to use UI for this feature: http://www.noscript.net