297435 - Enable per-session permissions for javascript for regex url black/white lists

Status: NEW

(Firefox :: Settings UI, enhancement)

Description

[Chris Beck]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

It would be nice to have fine-grained control over javascript execution
permissions.  I would like to enable/disable javascript on black and white list
URL regexs on a permanent/per-session basis similar to cookie handling.
Access should be as simple as clicking on a warning bar like for XPI installs or
maybe a astatus bar icon.

Reproducible: Always

Steps to Reproduce:
1. Visit a site that tries to run javascript
2. A GUI alert appears
3. I chose to enable/disable javascript for a regex URL
Actual Results:  
The feature isn't there

Expected Results:  
The feature should be there :)

Treating javascript like cookies would go a long way towards reducing security
holes.

Comment 1

[Peter van der Woude [:Peter6]]

If you want this you'll need an extension.

1. the avg user will never use this
2. most pages will bring up the dialog, driving you nuts w/i an hour or so

WONTFIX

Comment 2

[Chris Beck]

I understand your point of view, however,  most pages use cookies but we still
provide for cookie handling up to and including the annoying pop-ups that you
mention,  If it can be done for cookies & privacy concerns, why can it not be
done for javascript & security concerns?  The default to accept all javascript
would be justr like the default accept all cookies.

I will be honest here and admit that the feature request was driven by my use of
the no-script extension which causes firefox to crash on a regular basis.

This feature would be very useful in the following case:
A new security risk is discovered where the only work-around (until a new
release) is to turn off javascript.  By having per-site permissions we could
still browse important sites (online banking &c) safely but disable it for
casual browsing.  The UI alert feature could be made less intrusive than a
pop-up or not.

Comment 3

[Peter van der Woude [:Peter6]]

yeah, it seams i made the wrong call
I looked for duplicate bugs (plenty) and they very vague
reopening

Comment 4

[Chris Beck]

Thank you, I appreciate it.  Oh, and I am guessing that a gmail email address
means that you are a volunteer, so thank you again.

Comment 5

[Peter van der Woude [:Peter6]]

CC mconnor

I'm confused about this bug and its dupes

1.most are ventually duped against a seamonkey bug with status NEW
2.I would guess that the common annoyance thingy for javascript options is
pretty much final and the policy is not to expand it with more options again.

wontfix or not is the question

Comment 6

[Mike Connor [:mconnor]]

First, the assertion that providing white/blacklisting for end users will have
_any_ positive effect on security is placing far too much onus on the user.  We
should fix security holes, and make updating safe and easy, not leave it on
people to inspect js code before enabling js for any particular site.

This isn't something I want to try to address in the current cycle, but there's
got to be a way of balancing finer-grained controls with something users can
understand...

Comment 7

[Peter van der Woude [:Peter6]]

since the older bugs date from before the current UI (and are duped against a
seamonkey bug) I'll set this one new

status->New
comp->Preferences
os->All
target->future

Comment 8

[Chris Beck]

Perhaps it could be combined with the Policy Manager extension which tries to
add a UI to the native-but-no-GUI functionality:

http://piro.sakura.ne.jp/xul/_policymanager.html.en
and is an elaboration of the extension which started this all for me: noscript
http://www.noscript.net/changelog.

And Mike, this sort of feature would be very useful in the gaps between a
vulnerability being announced and a patch or new build being released. 
Sometimes turning of javascript completely is not a viable option.

It seems to me that if the features exist in the core but don't have a UI then
it is reasonable to guess that a UI would not be contrary to the design intention.

Comment 9

[Mike Connor [:mconnor]]

That's a completely invalid assumption.  The reason we can selectively blacklist
or whitelist sites for different content types is because mvl wrote a bridge
between nsIContentPolicy and nsIPermissionManager, so anything the content
policy interface could distinguish can now be manipulated by the permission
manager.  This is a backend feature with a lot of potential applications, not
all of which are necessarily core UI features for Firefox.

Just because we can utilize a backend feature from Gecko doesn't mean we will,
or we should.

Comment 10

[Cees T.]

NoScript https://addons.mozilla.org/firefox/722/ can whitelist things based on simple URL matches. AdBlock has regex matching but doesn't block JavaScript.

NoScript 1.1.4.1 encountering Windows Media Player crashes Firefox 1.5.0.6 though.
https://bugzilla.mozilla.org/show_bug.cgi?id=349631

And AdBlock might have a few unresolved memory leaks. (How hard is it to just delete stuff when a page is closed/reloaded?)