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 (chrlsim@futureone.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

Don't forget mail. I'd imagine any general solution will fix mail, but the most annoying problems for *me* are when porno spammers send me mail that keeps opening windows that they won't let me close. Surfing mainly to reputable web sites I haven't had anywhere near the troubles I've had with mail. [There is already a pref to turn javascript off in mail, but then you lose it completely.] Steve Morse's cookie manager does something like this for cookies. I wonder if it could be extended or generalized this purpose as well? Jar and Raman had discussed zone-based security for Java in the past, they may have thought through some of the issues already.

Brendan was noting that we could actually use prefs to do this - something like javascript.deny.domain where domain is the domain you want to keep from using JS. Or you could do javascript.allow.domain with the default set to not letting anyone use it so that you could allow home.netscape.com to use JS but not anyone else. About mail and news, isn't there a pref now like javascript.allow.mailnews or something like that?

I simplified the Summary to deal with JS only (plugins are caveat-downloader, Java should get a separate bug). We already have a javascript.allow.* pref namespace, that's where javascript.allow.mailnews lives. I was proposing by phone to mlm (and therefore dots got lost) this idea: Add a new pref object node, javascript.allow.domain. Under it, users could create names like javascript.allow.domain.mypal.sgi.com javascript.allow.domain.netscape.com javascript.allow.domain.mozilla.org Add another new pref node, javascript.deny.domain, so that users can arrange for JS to be disabled elsewhere: javascript.deny.domain.com // restrictive! javascript.deny.domain.sgi.com and perhaps even javascript.deny.domain["*"] for all. Then modify LM_CanDoJS (http://cvs-mirror.mozilla.org/webtools/lxr/ident?i=LM_CanDoJS) after making sure it is used universally to decide whether JS is enabled to have this logic: if (there is a pref of the form javascript.deny.domain.x where x is a domain-name-suffix of the current URL's host part, or the same as the current URL's host part) { if (there is not a pref of the form javascript.allow.domain.y where y is a longer domain-name-suffix of the current URL's host part) { return JS_FALSE; } } ... rest of LM_CanDoJS logic here This is almost too easy. There'll probably be hassles with LM_CanDoJS not being universally quantified. There won't be any threading hassles cuz this function is used only in the mozilla thread. There could be some sharing of domain suffix checking or extraction with the lm_doc.c DOC_DOMAIN property's code, but it's short enough to rip off. After this is done, the UI could be done entirely by a signed script, say on Netscape's home page (signed by Netscape's SSL cert so it's already trusted, for better or worse). /be

How would this proposal deal with JavaScript in mail? Yes, we can turn off JS for mail (all or nothing), but we can currently do the same for JS as a whole and that's what this RFE is trying to change. Please don't leave JS-in-mail out when designing the solution to this problem. If HR sends me a form, I'd like JS to work in it. If some unknown sends me spam that tries to open unclosable windows I *don't* want to run JS. As to javascript.allow.* and javascript.deny.*, perhaps you need a third pref that toggles between "allow unless specifically denied" and "deny unless specifically allowed". If I had a per-domain feature most of the time I'd probably want JavaScript off except for specific trusted sites. But if I ran across a new site that required JavaScript I'd probably want to be able to easily turn it on and give that site a whirl without having to say I trust that site.

This feature won't work well in mail without authentication. We could invent a magic domain for all JS-in-mail that defaults to deny, but which you could selectively enable (see next). > perhaps you need a third pref that toggles between "allow unless specifically > denied" and "deny unless specifically allowed". Right -- the way to do this, it seems to me, is not to make those prefs I sketched boolean, but string-valued: javascript.allow.domain.com = "ask" or similar for deny (which would change the default sense of the confirming dialog's OK or Yes button from the allow... = "ask" case). Mike, are you keen to do this in mozilla? /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

Design nits: Overloading `.' as pref-hierarchy-separator and domain-part-separator grates a bit. Mail/news does this already with imap.server.tintin.mcom.com and it makes it hard to build a general preferences UI. I'd prefer javascript.domain["sgi.com"] = "ask"/"on"/"off"/"whatever". Maybe "signed" for signed JS only? "http,mail" to allow both HTTP and read-mail stuff, but "http" to not allow mail?

Setting all current Open/Normal to M4.

This is not a core JavaScript bug (RFE) -- it's really somewhere near the DOM, so I'm giving it to DOM level 0 and joki, who is security policy fallguy for JS stuff in the client. /be

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.

I've implemented some of the per-domain policy ideas proposed by the researchers at Lucent. With my checkin yesterday it is possible to edit the preferences file to indicate that certain domains have a named policy. That policy can then be specified to grant or restrict access to DOM properties one-by-one. I haven't yet made it possible to disable the execution of JavaScript controllable by domain, but I'll do that before I close this bug.

I've got changes in my tree that allow a user to disable JavaScript for certain selected sites using lines in the all.js preferences file like: pref("security.policy.strict.sites", "http://warp.mcom.com"); pref("security.policy.strict.javascript.enabled", "noAccess");

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. ***

How does one use this to implement a whitelist? I tried user_pref("capability.policy.default.javascript.enabled", "noAccess"); user_pref("capability.policy.relaxed.javascript.enabled", "sameOrigin"); user_pref("capability.policy.relaxed.sites", "http://www.goodsite.com/"); but this does not permit goodsite to run javascript. What's the proper incantation?

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().

(suggestion to try pref() instead of user_pref()): That still doesn't work. In prefs.js: pref("capability.policy.jsallowed.sites", "http://www.mozilla.org http://bugzilla.mozilla.org"); pref("capability.policy.jsallowed.javascript.enabled", "sameOrigin"); pref("capability.policy.default.javascript.enabled", "noAccess"); Then load up http://www.mozilla.org/quality/help/bug-form.html and check out the blank page.

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