Open
Bug 297435
Opened 19 years ago
Updated 2 years ago
Enable per-session permissions for javascript for regex url black/white lists
Categories
(Firefox :: Settings UI, enhancement)
Tracking
()
NEW
Future
People
(Reporter: mozilla.org, Unassigned)
Details
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•19 years ago
|
||
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
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → WONTFIX
Reporter | ||
Comment 2•19 years ago
|
||
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•19 years ago
|
||
yeah, it seams i made the wrong call I looked for duplicate bugs (plenty) and they very vague reopening
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
Reporter | ||
Comment 4•19 years ago
|
||
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•19 years ago
|
||
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•19 years ago
|
||
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•19 years ago
|
||
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
Status: UNCONFIRMED → NEW
Component: Security → Preferences
Ever confirmed: true
OS: Windows XP → All
Target Milestone: --- → Future
Reporter | ||
Comment 8•19 years ago
|
||
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•19 years ago
|
||
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.
Updated•18 years ago
|
QA Contact: firefox → preferences
Comment 10•18 years ago
|
||
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?)
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•