[Feature] JavaScript auto-disable per-domain RFE




21 years ago
11 years ago


(Reporter: brendan, Assigned: norrisboyd)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




21 years ago
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

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.

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

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.


21 years ago

Comment 2

21 years ago
Brendan was noting that we could actually use prefs to do this - something


where domain is the domain you want to keep from using JS.  Or you could


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?


21 years ago
Summary: JavaScript and Java (and plugins? All executable content?) auto-disable per-domain RFE → JavaScript auto-disable per-domain RFE

Comment 3

21 years ago
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


Add another new pref node, javascript.deny.domain, so that users can arrange for
JS to be disabled elsewhere:

javascript.deny.domain.com	// restrictive!

and perhaps even


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

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

Comment 5

21 years ago
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?


Comment 6

21 years ago
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.)

Comment 7

21 years ago
> We could invent a magic domain for all JS-in-mail that defaults to deny, but
> which you could selectively enable (see next).


For SMIME etc., we can use the host part of the From address as the domain to
allow or deny.

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?

Comment 9

20 years ago
Setting all current Open/Normal to M4.


20 years ago
Component: LibMocha → JavaScript
Product: MozillaClassic → Browser


20 years ago
Assignee: mlm → joki
Component: JavaScript → DOM Level 0

Comment 10

20 years ago
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.



20 years ago
QA Contact: 4015

Comment 11

20 years ago
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser


20 years ago
QA Contact: 4015 → 4616

Comment 12

20 years ago
QA contact re-assigned according to the product areas we're currently working


20 years ago
Target Milestone: M4 → M6

Comment 13

20 years ago
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

Comment 14

20 years ago
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.



20 years ago
Assignee: joki → norris


20 years ago
Target Milestone: M6 → M9

Comment 15

20 years ago
I'll take this on my plate. No promises on implementation for 5.x, but I see why
this feature would be desirable.

Comment 16

20 years ago
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.


20 years ago
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.
Blocks: 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?


20 years ago
Depends on: 7254
Target Milestone: M9 → M11

Comment 21

20 years ago
Depends on 7254, which is M10.

Comment 22

20 years ago
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

Comment 23

20 years ago
*** Bug 11931 has been marked as a duplicate of this bug. ***


20 years ago
Blocks: 12633

Comment 24

20 years ago
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


Discussion in



20 years ago
Whiteboard: Lucent folks have offered help with security policies


20 years ago
Whiteboard: Lucent folks have offered help with security policies → Help wanted: Lucent folks have offered help with security policies


20 years ago
Blocks: 7252
No longer blocks: 12633
Target Milestone: M11 → M14
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.

Comment 26

20 years ago
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.


20 years ago
Severity: normal → enhancement


19 years ago
Whiteboard: Help wanted: Lucent folks have offered help with security policies

Comment 27

19 years ago
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.


19 years ago
Component: DOM Level 0 → CAPS
Summary: JavaScript auto-disable per-domain RFE → [Feature] JavaScript auto-disable per-domain RFE


19 years ago
Target Milestone: M14 → M15

Comment 28

19 years ago
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");

Comment 29

19 years ago
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.



19 years ago
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 30

19 years ago
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.


19 years ago

Comment 31

19 years ago
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.


19 years ago
Component: CAPS → Security: CAPS

Comment 32

19 years ago
Moving all CAPS bugs to Security: CAPS component.  CAPS component will be 
*** Bug 40005 has been marked as a duplicate of this bug. ***

Comment 34

19 years ago
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. ***

Comment 37

18 years ago
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
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().

Comment 39

18 years ago
(suggestion to try pref() instead of user_pref()):
That still doesn't work.  In prefs.js:

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

Comment 40

18 years ago
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.

Comment 41

16 years ago
Is it possible to declare the sites preference with wildcards like:
pref("capability.policy.UBS_trustable.sites", "http://*.ubs.com");
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
You need to log in before you can comment on or make changes to this bug.