Last Comment Bug 664589 - [meta] Allow content security policy to inform developer tools JS execution
: [meta] Allow content security policy to inform developer tools JS execution
Status: NEW
[sg:want?][see comment 34]
: sec-want
Product: Firefox
Classification: Client Software
Component: Developer Tools (show other bugs)
: Trunk
: All All
: -- normal with 2 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 779406 (view as bug list)
Depends on: 710273
Blocks: dev-self-xss
  Show dependency treegraph
 
Reported: 2011-06-15 15:58 PDT by Brandon Sterne (:bsterne)
Modified: 2015-03-19 08:21 PDT (History)
28 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Brandon Sterne (:bsterne) 2011-06-15 15:58:11 PDT
There is some security risk to having Developer Tools like the Web Console available by default to all users.  We are seeing attacks in the wild where users have been convinced to paste malicious bookmarklets in their Location Bar:
http://www.nytimes.com/2011/06/14/technology/14security.html?src=recg&pagewanted=all

Bug 656433 fixed the Location Bar vector, but we suspect that these social engineering attacks will move to the Web Console or similar.  We should consider hiding Developer Tools for this reason unless the user opts-in through a preference.
Comment 1 Joe Walker [:jwalker] (needinfo me or ping on irc) 2011-06-16 04:06:36 PDT
Surely the Citi thing was an insecure direct object reference vuln, rather than a location bar problem?

Previously devtools argued that just pushing devtools to an Option/Preference, simply meant that Facebook scammers needed to add another couple of lines to their "How to get more Farmville goods" scam scripts.

In the GCLI review, the sec group argued (persuasively to me, at least) that simply dropping down the console and typing some gibberish, does feel like a way to get something cheap - it's not that dissimilar like an infinite lives hack on a computer game.

On the other hand instructions that involve naming web developer tools also help to point out that this affects the browser and not the website - this is especially true if we default to "undocked".

Also, with social attacks, we can never be 100% safe, this is about percentages, and this would probably help more innocent people than it hurts developers.
Comment 2 David Dahl :ddahl 2011-06-16 08:50:55 PDT
I don think we should do this. There must be a middle ground here. Developer tools are the new "View Source" and hiding them will be detrimental to people experimenting and learning about what is happening in web pages.
Comment 3 Daniel Veditz [:dveditz] 2011-06-16 09:43:43 PDT
The article about Citi is a red herring. The copy/paste scams have been on social sites, primarily Twitter and especially Facebook. Here are two recent scams

"dislike button"
http://www.spamfighter.com/News-16216-%27Dislike%27-Button-Scam-Rapidly-Propagating-on-Facebook.htm

"see who's checking out your profile"
http://socialbarrel.com/check-out-your-profile-scam-spreads/8200/

  -- Facebook clearly needs to add those features :-)

The tension is that developers who want to use these tools don't want to dig deep into menus every time, and naive users who have no idea what these windows are can be talked through simple keystrokes without raising their suspicions. The current attack instructions

 right-click-copy, Ctrl-L, Ctrl-V

easily become

 right-click-copy, Ctrl-Shift-K, Ctrl-V

The only saving grace is that now you need "in Firefox..." instructions separate from other browser, but it's a small grace.

Safari's approach is to hide the developer tools until the user enables them in preferences (actual pref UI, don't bury in about:config). The bonus is that the tools become more accessible for developers because they're top-level rather than buried on a sub-menu.

Another approach might be to disable the keyboard shortcuts until users have found the tools on the menu first, maybe with a doorhanger asking the user to turn on the shortcuts rather than just doing it.
Comment 4 Joe Walker [:jwalker] (needinfo me or ping on irc) 2011-06-16 09:50:15 PDT
Brandon do we have any data about current misuse of the JS web-console? (as opposed to the location bar) I guess it's hard to know since bug 656433 hasn't been shipped yet?

We might also consider a range of UI options to mitigate this problem:

- The developer tools menu starts out being called "Enable Developer Tools", and could begin with a warning like about:config does.

- The web console (and other dev tools), when first opened, begins with a warning.

- Developer tools default to opening in a separate window so they can't be confused with page content.

- Hide all the dev tools until an option is clicked (as noted above).

- etc
Comment 5 Nick Fitzgerald [:fitzgen] [⏰PDT; UTC-7] 2011-06-16 10:06:42 PDT
I hesitate to use the term "middle ground" because that implies to me that the security and usability of developer tools are somewhat mutually exclusive or that if you have more of one, you get less of the other. In reality I don't think that is true; I think we can find a solution which can maximize both properties.

What if we did something similar to what happens when you visit an encrypted page that contains unencrypted assets?

That is, when any developer tool is opened, display a pop up warning which asks the user if they know what they are doing and summarizes the risks. It would also include a "never show me this warning again" checkbox.

The advantages that I see with this approach are:

  * Developer tools can still be easily accessible and discoverable, as they currently are. The spirit of "view source" lives on.

  * "Normal" users get a pretty shocking warning when they open a tool that they could potentially be "persuaded" to shoot themselves in the foot with. Furthermore, it should be clear that the warning isn't just part of the webpage, but outside of that in browser land.

  * Developers can check the box to hide the message in the future so that the usability of the tools is not negatively impacted in the future.

Thoughts?
Comment 6 Jesse Ruderman 2011-06-16 10:22:16 PDT
I'm only worried about the aspects of developer tools that allow modifying the page, and in particular injecting script into the page.

"The spirit of View Source" does not require being able to inject scripts into page.  Anyone who is far enough into web development to want to do that would be happy having a Develop menu instead of a submenu of Tools.

By the way, "View Source" itself may get some big improvements soon: https://wiki.mozilla.org/DevTools/Features/ViewSource.
Comment 7 David Dahl :ddahl 2011-06-16 11:20:23 PDT
(In reply to comment #6)
> I'm only worried about the aspects of developer tools that allow modifying
> the page, and in particular injecting script into the page.
> 
indeed a concern

> "The spirit of View Source" does not require being able to inject scripts
> into page.  Anyone who is far enough into web development to want to do that
> would be happy having a Develop menu instead of a submenu of Tools.
On Linux and Windows these tools are already in a submenu in the default toolbar configuration

I was not comparing our tools to a benign 'view source', I meant that modern pages need to be understood as much as old-school static html. I'd hate to hide these from everyday people, and I'd not want to scare people too much about using them. I do agree we have a responsibility to protect the innocent as much as is reasonable.
Comment 8 Brandon Sterne (:bsterne) 2011-06-16 13:15:49 PDT
(In reply to comment #4)
> Brandon do we have any data about current misuse of the JS web-console? (as
> opposed to the location bar) I guess it's hard to know since bug 656433
> hasn't been shipped yet?

I don't for the reason you mentioned.

> We might also consider a range of UI options to mitigate this problem:
> <snip>

Of the options you listed, I strongly favor:
> - Hide all the dev tools until an option is clicked (as noted above).

Any strategy that depends on a warning, a la about:config, is only likely to add another "Enter" to the "Highlight, Ctrl+C, Ctrl+Shift+K, Ctrl+V, Enter" sequence (the extra "Enter" dismissing the warning).

I understand the discoverability issue, but do we really think there are users capable of understanding and utilizing Developer Tools who wouldn't be willing to first set a pref?
Comment 9 Joe Walker [:jwalker] (needinfo me or ping on irc) 2011-06-16 14:39:51 PDT
Quick review of what everyone else does.

This is the fastest route I could find to execute JavaScript in the clipboard on the various browsers, from default install:

- Safari: CMD+,, click Advanced tab, click Show Develop menu, close dialog, OPT+CMD+C, CMD+V
- Opera: OPT+CMD+I, ESC, CMD+V
- Chrome: OPT+CMD+J, CMD+V
- Firefox: CMD_SHIFT+K, CMD+V
- IE (win): F12, click console, CTRL+V

I strongly suspect that Safari are doing their thing not because of a Facebook scam, but because they think the Develop menu is ugly.
I strongly suspect that Microsoft are doing their thing because they've not actively tried to make it easy (or make it easy for me to find the shortcut).

So maybe no-one else is trying to solve this problem.

I wonder if we have contacts in Google that could answer the question about where the scammers go when they close the location bar hole - I see they already strip "^javascript:" off anything that is pasted in the url bar (which has the *very* nice side effect of searching for the script - which tells Google of the attack)
Comment 10 Rob Campbell [:rc] (:robcee) 2011-06-21 07:56:56 PDT
A couple of thoughts, since I'm late to this party:

1) an about:config preference is terrible UI. I think everybody here agrees with that.

2) adding a preference UI to turn on the features is the least egregious solution to these problems, though an attacker will only have to convince a user to select that once and then we're back in the same boat.

3) having to restart the browser to have developer tools access would suck.

Assuming we were to implement 2 (and 3), we'll need to add a bunch of first-time-use startup code, some additional preference UI (probably to the already-busy Advanced pane, or create a new Developer Tools pane with one checkbox) and additionally, because of our focus on being able to turn off new features for rapid releases, provide an additional pref allowing the release gods to be able to turn off all of this new functionality.

In short, it's a surprising amount of work for something that is a fairly theoretical attack. Work that takes us away from actually implementing useful developer tools.
Comment 11 Rob Campbell [:rc] (:robcee) 2011-06-21 08:05:20 PDT
oh, and to be clear, I'm not opposed to actually doing the work I mention in C10. I just want to emphasize that there is some cost.

Another possibility might be to disable the menu items (or some set of them) in the Web Developer submenus until a user selects an enable item.
Comment 12 Paul Rouget [:paul] 2011-10-04 05:25:57 PDT
In bug 691452, I was proposing:

> The "Web Developer" menuitem could be a check box (<menuitem type=checkbox>), once activated, it becomes a nested submenu (the one we have right now), and the "Inspect Element" menuitem in the context menu appears. Then, the way to disable it could be an extra menuitem in the "Web Developer" menu, called "disable developer tools".
Comment 13 Paul Rouget [:paul] 2011-10-04 05:28:04 PDT
(sorry for the bad formatting)

In bug 691452, I was proposing:

> The "Web Developer" menuitem could be a check box (<menuitem type=checkbox>), once
> activated, it becomes a nested submenu (the one we have right now), and the "Inspect
> Element" menuitem in the context menu appears. Then, the way to disable it could be an
> extra menuitem in the "Web Developer" menu, called "disable developer tools".
Comment 14 Kevin Dangoor 2011-10-05 06:06:57 PDT
(In reply to Paul Rouget [:paul] from comment #12)
> In bug 691452, I was proposing:
> 
> > The "Web Developer" menuitem could be a check box

How does this impact add-ons that put things in the Web Developer menu?
Comment 15 Rob Campbell [:rc] (:robcee) 2011-10-05 06:15:36 PDT
How about leaving the items in the Web Developer menu but disable them? At the top of the menu, place a "Enable Developer Tools" menuitem checkbox that turns the whole thing on leaves the setting in place.

Tools
-----
  ...
  Web Developer>
  -------------
    Enable Developer Tools ☐
    ------------------------  <- items below this are disabled.
    Web Console
    Inspect
    Scratchpad
    ...
Comment 16 David Dahl :ddahl 2011-10-05 06:22:18 PDT
(In reply to Rob Campbell [:rc] (robcee) from comment #15)
> How about leaving the items in the Web Developer menu but disable them? At
> the top of the menu, place a "Enable Developer Tools" menuitem checkbox that
> turns the whole thing on leaves the setting in place.

This is the least ridiculous solution, however, I still feel like this is all so theoretical without a study and number of victims, cnn news footage, etc.
Comment 17 Rob Campbell [:rc] (:robcee) 2011-10-05 06:26:44 PDT
(In reply to David Dahl :ddahl from comment #16)
> (In reply to Rob Campbell [:rc] (robcee) from comment #15)
> > How about leaving the items in the Web Developer menu but disable them? At
> > the top of the menu, place a "Enable Developer Tools" menuitem checkbox that
> > turns the whole thing on leaves the setting in place.
> 
> This is the least ridiculous solution, however, I still feel like this is
> all so theoretical without a study and number of victims, cnn news footage,
> etc.

agreed.
Comment 18 Joe Walker [:jwalker] (needinfo me or ping on irc) 2011-10-05 06:50:43 PDT
(In reply to Kevin Dangoor from comment #14)
> (In reply to Paul Rouget [:paul] from comment #12)
> > In bug 691452, I was proposing:
> > 
> > > The "Web Developer" menuitem could be a check box
> 
> How does this impact add-ons that put things in the Web Developer menu?

Installing a web developer add-on is an indication that you are a web developer, and so the menu should be enabled automatically.
Comment 19 Kevin Dangoor 2011-10-05 07:06:04 PDT
(In reply to David Dahl :ddahl from comment #16)
> (In reply to Rob Campbell [:rc] (robcee) from comment #15)
> > How about leaving the items in the Web Developer menu but disable them? At
> > the top of the menu, place a "Enable Developer Tools" menuitem checkbox that
> > turns the whole thing on leaves the setting in place.
> 
> This is the least ridiculous solution, however, I still feel like this is
> all so theoretical without a study and number of victims, cnn news footage,
> etc.

Indeed (both on the solution and the theoretical nature of this bug). Perhaps this discussion better fits bug 691452.
Comment 20 Brandon Sterne (:bsterne) 2011-10-05 09:11:58 PDT
The attack that this bug was filed to mitigate is not theoretical at all.  See bug 527530 comment 70 for commentary from Facebook Security about how the malicious bookmarklet attack evolved after Chrome disabled _pasting_ of javascript: URLs in the location bar (you can still type them).

The attack morphed into copying a 'avascript:' URL and convincing the user to type 'j' then paste.  It is completely reasonable to expect attackers to go after Firefox users by saying type Ctrl+Shift+K then paste.  I fully expect this to happen now that we've fixed bug 656433.

Comment 15 sounds eminently reasonable.
Comment 21 Dave Camp (:dcamp) 2011-10-05 14:09:11 PDT
If we do need to mitigate this attack, I'd prefer to do it without wholesale declaration of developer tools as Dangerous.

What if we started the web console, let people watch their page in action, but instead of a command line have a button of some sort saying "Enable developer-only tools that might hurt my computer."  Same with any other place we allow code execution.
Comment 22 Dave Camp (:dcamp) 2011-10-05 14:10:20 PDT
That does add some implementation burden to developer tools hackers and reviewers, and adds a standard question to the security reviews of developer tools features.
Comment 23 Brandon Sterne (:bsterne) 2011-10-05 14:20:11 PDT
(In reply to Dave Camp (:dcamp) from comment #21)
> What if we started the web console, let people watch their page in action,
> but instead of a command line have a button of some sort saying "Enable
> developer-only tools that might hurt my computer."  Same with any other
> place we allow code execution.

I'm personally fine with this approach too.  In some ways, this is better than the simple pref or Dev-Tools-enabling checkbox, because it adds a cognitive barrier to users who wouldn't otherwise understand that they are about to run software in the context of the site they're viewing.  The former only makes the attack require more steps and thus raise the suspicion of potential victims.

I could definitely accept a solution that exposes all of the more "passive" or "introspective" elements of our Dev Tools by default and hides the code executing functionality behind a sufficiently scary warning.
Comment 24 Johnathan Nightingale [:johnath] 2011-11-17 13:46:02 PST
It doesn't seem likely to me that this would mitigate the described threat. The victims of these scams are being told, essentially, "There is valuable stuff hidden in facebook that you can only get by hacking on the site using this secret recipe - check it out!" My sense is that while additional steps may cause some level of fall-off, a preference or an in-console prompt that says "Enable developer tools" will mostly just reinforce the notion that they are getting access to secret goodies.

I appreciate that this is not a particularly constructive comment, since I haven't been clever enough yet to think of something that I *do* believe would prevent this attack. Nevertheless, I am concerned that we would harm the usability of a developer tool without concomitant user safety gained.
Comment 25 Joe Walker [:jwalker] (needinfo me or ping on irc) 2011-11-17 15:42:53 PST
(In reply to Johnathan Nightingale [:johnath] from comment #24)
> .. My sense is that while additional steps
> may cause some level of fall-off, a preference or an in-console prompt that
> says "Enable developer tools" will mostly just reinforce the notion that
> they are getting access to secret goodies.

Dave's example did have the phrase 'that might hurt my computer', which could indicate to some people that rather than attacking Facebook you're being duped into attacking yourself.

Simply protecting the command line isn't enough (or at least won't be when we're allowing editing in all the places we have planned)
The correct solution might be a read-only mode which the whole of developer tools can be put into, I wonder how much work that would be.

Various barriers have been suggested - perhaps the people that don't overcome the suggested barriers are unlikely to learn anything useful about the web from our tools. So maybe humanity won't actually lose anything?
Comment 26 Johnathan Nightingale [:johnath] 2011-11-21 14:04:41 PST
(In reply to Joe Walker from comment #25)
> (In reply to Johnathan Nightingale [:johnath] from comment #24)
> > .. My sense is that while additional steps
> > may cause some level of fall-off, a preference or an in-console prompt that
> > says "Enable developer tools" will mostly just reinforce the notion that
> > they are getting access to secret goodies.
> ...
> 
> Various barriers have been suggested - perhaps the people that don't
> overcome the suggested barriers are unlikely to learn anything useful about
> the web from our tools. So maybe humanity won't actually lose anything?

My question is, are we actually keeping users safer by introducing this, or are we placating ourselves by having "done something" while, in point of fact, our users still get victimized?

I don't have an alternate suggestion - I wish I did. Maybe a pref that says "enable developer tools" is good enough, though I don't think I love the scary language associated with it - keeping users safe is on-mission, but so is helping people take apart the web to understand how it works. I don't want to scare people off doing so.

It's not an easy problem to solve. We've got users blindly copy-pasting code they don't understand, but we want to build a UI that helps them understand the potential impacts. And we want to do it in tools expressly designed for a different set of users, who don't want or need to be nagged. Is that possible? Adding a swath of UX people to add clever ideas to the mix.

I know no one's arguing that we should just Do Something in order to say that we've done something. I just don't see (and I admit that it's intuition, not data governing this) that an opt-in pref will do the thing we want for the audience we want, whereas it will add (albeit minor) nuisance to a segment we don't want to annoy.
Comment 27 Rob Campbell [:rc] (:robcee) 2011-11-22 07:13:42 PST
Dave Camp, Dietrich and I discussed this a bit last week. Short tldr; précis: We have no magic bullet for this.

I don't like the scary language either, and anyone who's being told they are going to "hack ${SOCIALNETWORK}" already feel like they're doing something dangerous and sneaky. A warning dialog is probably not going to stop them.

I don't like hiding the tools behind a preference for the reasons you mention. We want to give people tools to help them understand what's going on under the covers.

Preventing pasting? Heuristics to determine where a user is trying to run code and preventing them from doing so on blacklisted pages seems error-prone and, frankly, a lot of work.

I would love to have a solution that feels good, but my developer-tool-loving gut says, the best solution is to leave these on and available to everyone without scary language and hoops to jump through. I want people to feel good about learning how to hack the web. I don't want them to feel like what they're doing is dangerous or scary or creepy.
Comment 28 Joe Walker [:jwalker] (needinfo me or ping on irc) 2011-11-22 07:48:19 PST
Personally, I don't think we can do nothing about comment 20.

I also think that bugzilla is a terrible place to discuss this. We're losing ideas in the scroll, and in danger of going over the same ground over and over again.
Even etherpad would be better.
Comment 29 Johnathan Nightingale [:johnath] 2011-11-22 07:51:01 PST
(In reply to Joe Walker from comment #28)
> Personally, I don't think we can do nothing about comment 20.
> 
> I also think that bugzilla is a terrible place to discuss this. We're losing
> ideas in the scroll, and in danger of going over the same ground over and
> over again.
> Even etherpad would be better.

Wanting to do something about comment 20 is righteous, but I don't think the remedy suggested in the bug summary/comment 15 accomplishes that.

You could move it to a newsgroup or something if you like. I'm not actually sure where you'd get the discussion you want, tbh.
Comment 30 Mike Beltzner [:beltzner, not reading bugmail] 2011-11-22 07:57:45 PST
I suspect I was cc'd for a reason, and so I'll throw in my $0.02:

We've been fighting these attacks, which are essentially social hacking attacks, through many vectors as long as I've been involved with the project. It is essential that we all agree, up front, that complete elimination of the threat NOT be a goal: it's simply an impossible one. As Johnath states in comment 24, the true threat occurs when someone is able to convince a user that there is tasty cake to be eaten - once that metaphorical hunger digs in, the battle is almost certainly lost. The user will do whatever it takes to get at the cake, despite the cake being a lie[1].

Our only defense is to make it *less* trivial for an attacker to be successful in their instruction to a cake-thirsty[2] user. We've done this various ways in the product, always resulting in the same problem where friction added to prevent trivially guided malice also added UX friction to those looking to use the feature in question. Sometimes this added friction has been reasonable (I think the javascript-in-URL-bar mentioned in comment 20 is a decent example) and other times it's ended up being a frequent PITA (the countdown timer used to defeat "punch the monkey" attacks, the unsigned add-on UI). Ultimately, though, and referring back to the previous paragraph, these additional frictions can be worked around by the clever attacker and cake-desiring user (again, see comment 20)

All that said, I think the Safari-style solution is probably best, and also serves to remove these features from the everyday user's face, which is a bit of a win-win. It won't solve the problem, but it adds a bit more friction to keep it from being entirely trivial/tweetable. We could also add a one-time transition in which the user is notified that they should be sure to trust whomever is telling them to turn on the tools, much like we do with "This may void your warranty".

I tend to agree with Joe - it feels like discussion here has been exhausted and represents all available views. Now I would suggest that the product manager (Asa as of this writing) and feature owner (Rob, I believe?) confab with the security lead assigned (Brandon, I think?) and come to a plan of action, each acting as representative for their groups' concerns. That's the only way out of deadlock, IMO.

[1]: hopefully you see what I did there
[2]: and there
Comment 31 Mike Beltzner [:beltzner, not reading bugmail] 2011-11-22 08:07:55 PST
(I have been told that Joe is the PM for DevTools, not Rob - sorry for that! I guess I meant that stakeholders from: DevTools, Firefox, Security all get their heads together on a plan, holding their respective stakes and representin' for their peeps.)
Comment 32 Johnathan Nightingale [:johnath] 2011-11-28 18:15:36 PST
Could we do something like autocomplete=off here? Give sites a way to say "please don't execute client-supplied JS on me"? meta tag, header, navigator.dontHurtMe(), something?

This preserves the value of the tools in the vast majority of cases, since tinkerers can still tinker unmolested with nearly every site on the web, and we can throw a descriptive error in the cases where the site has opted out. Actual site developers control the horizontal and vertical there so they can remove the opt-out during test/development. If we think that's compromising too much of our "we answer to no one but you" stance, we can allow disabling of respect for this guard in about config - which is already wrapped in warranty disclaimers, and we can even name the pref devtools.attackme.

I don't know if that would meet facebook's needs (how easy is it for them to add header junk?) or if there is some other signal we can key off of (my first thought was https, but that throws out too much baby, I think, and anyhow co-opting one tech to serve as signal for another is peril-fraught.)

Anyhow, trying to find solutions that don't pit security concerns directly against privacy.

(And while I appreciate the suggestion in comment 30, I think the discussion needs to happen here because we're gonna do 30 laps on this now that script kiddies have added social-js to their arsenal. If we do reach a solution, I want the debate here so that other browsers can follow along at home.)
Comment 33 Mike Beltzner [:beltzner, not reading bugmail] 2011-11-28 18:46:30 PST
> Could we do something like autocomplete=off here? Give sites a way to say
> "please don't execute client-supplied JS on me"? meta tag, header,
> navigator.dontHurtMe(), something?

Is the attack we're concerned about in comment 0 limited to a strict subset of the web? Not that I think it's a bad idea, I just am not sure I understand why we'd want to respond to a specific location based attack. If we think that there are ways of clearly communicating "you best know what you're doing" to people, I'd rather we do it for all sites, not just the ones who are savvy enough to know that we may offer such protection.

> (And while I appreciate the suggestion in comment 30, I think the discussion
> needs to happen here because we're gonna do 30 laps on this now that script
> kiddies have added social-js to their arsenal. If we do reach a solution, I
> want the debate here so that other browsers can follow along at home.)

I didn't mean to suggest a solution to be developed in private and thrown over the wall. I meant for that group to get together in a high-bandwidth communication channel and brainstorm up some solutions, then bring them back to the group along with estimates.
Comment 34 Kevin Dangoor 2011-12-13 10:27:42 PST
A handful of us (Brandon, Johnathan, Rob, Dave and Joe) just discussed this. The consensus formed around a solution along the lines of what johnath suggests in comment 32.

The general idea is to use Content Security Policy to allow sites to request that user run JavaScript not be allowed on that site. Users would be able to override this, using a simple about:config pref as the override mechanism to begin with.

An important part of this will be to provide the user with a link to documentation explaining why the JS cannot be executed.

We'll use this bug as a meta bug, because the implementation of this sort of plan would require several other bugs. Comments on the plan in general are welcome here!
Comment 35 Joe Walker [:jwalker] (needinfo me or ping on irc) 2011-12-13 10:54:37 PST
(In reply to Kevin Dangoor from comment #34)
> An important part of this will be to provide the user with a link to
> documentation explaining why the JS cannot be executed.

And also to explain how to set the pref to turn this off.

We are keen that this doesn't come off as us conspiring with the big guys to shut off access to the little guys. We are conspiring with our broad user base against dr. evil.
Comment 36 Joe Walker [:jwalker] (needinfo me or ping on irc) 2011-12-14 10:54:48 PST
Copying comments in from email:

Johnath wrote:
> On 2011-12-14, at 12:22 PM, Joe Walker wrote:
> > Mike asked: What about bookmarklets? Since we're terming
> > this 'no-user-js' then bookmarklets probably count.
> >
> > On the one hand this is a separate issue, however it's worth considering what
> > our mitigation if any, against this would be before we invest too much in the
> > devtools/csp solution.
>
> Don't make me hyperventilate with your subject lines, Joe.
>
> Personally, I think I'm fine with either stance:
>
> 1) Fail open: "this is meant to mitigate an ease-of-user-victimization problem.
> Getting people to create a bookmarklet and then execute it against the page is
> not materially easier than just getting them to download an executable, so we'll
> let bookmarklets through regardless because they're out of scope for this
> feature"
>
> 2) Fail closed: "bookmarlets are user-supplied js. If you want to override CSP,
> go flip the pref."
>
> I think I lean towards #2 - going to the trouble of adding a CSP rule is pretty
> explicit and users still have ultimate control. I'd say CSP directive kills
> bookmarklet execution, doorhanger with explanation when someone tries, voila.
> But reasonable minds could differ and the work could still otherwise move
> forward, I assert.

The trouble with #2 is that bookmarklets are usable by anyone that can drag a button, and our current re-enabler is only available to people who can edit about:config

On 14/12/2011 17:47, Brandon Sterne wrote:
> It's a fair question.  My sense is that we should still allow bookmarklets under
> no-user-js, since they require the extra step of the user creating the bookmark
> before running it.  This is even harder now that we've removed the bookmarks
> toolbar by default (before, you could create a <a href=javascript:...> element
> and tell the user to drag it to the toolbar).
>
> If we later find that users are getting owned by bookmarking a malicious
> javascript: URL, we could add a checkbox in the bookmark manager that says
> something like "Trust this bookmark to run software in my browser", and we could
> require that this option be checked before we run any script.

So importantly no-one is proposing anything that changes our solution to bug 664589. We can reasonably consider this separately. Breathe normally!
Comment 37 Mardeg 2011-12-17 13:25:22 PST
Should there be a bug that tracks endangering of bookmarklets? They always seem to be an afterthought to "allow" whenever new security measures are being implemented :(
Comment 38 Joe Walker [:jwalker] (needinfo me or ping on irc) 2011-12-21 02:21:07 PST
(In reply to Mardeg from comment #37)
> Should there be a bug that tracks endangering of bookmarklets? They always
> seem to be an afterthought to "allow" whenever new security measures are
> being implemented :(

In this case we're actively planning on not touching bookmarklets. If we were to raise a bug, what would you like it to say?
Comment 39 Rob Campbell [:rc] (:robcee) 2011-12-22 07:00:48 PST
(In reply to Mardeg from comment #37)
> Should there be a bug that tracks endangering of bookmarklets? They always
> seem to be an afterthought to "allow" whenever new security measures are
> being implemented :(

I don't think we need to create a speculative bug in case we break bookmarklets. As Joe says, we won't be affecting them by fixing this bug. I can personally guarantee I will continue using my bookmarklets when we have code for this feature and will raise bugs if I find them. :)
Comment 40 Andreas van dem Helge 2012-06-05 00:44:21 PDT
I wish to negative vote this but don't see any option how to.
Comment 41 Tanvi Vyas[:tanvi] 2012-06-05 11:16:16 PDT
(In reply to Andreas van dem Helge from comment #40)
> I wish to negative vote this but don't see any option how to.

Andreas, do you have some feedback on why you don't like the no-user-js directive that sites could set if they are targeted by these types of social engineering attacks?
Comment 42 Kevin Dangoor 2012-08-08 07:18:49 PDT
*** Bug 779406 has been marked as a duplicate of this bug. ***
Comment 43 Tantek Çelik 2012-08-29 16:46:32 PDT
(In reply to Brandon Sterne (:bsterne) from comment #0)
> There is some security risk to having Developer Tools like the Web Console
> available by default to all users.  We are seeing attacks in the wild where
> users have been convinced to paste malicious bookmarklets in their Location
> Bar:
> http://www.nytimes.com/2011/06/14/technology/14security.
> html?src=recg&pagewanted=all

There is no mention of javascript URLs in that nytimes article. Please explain how that citation substantiates any of the points made here. Or provide any other "real world" data/citations about how javascript: URLs in the URL bar have been exploited in actual sites (e.g. Facebook). All I've seen so far is hearsay.
Comment 45 Daniel Veditz [:dveditz] 2014-02-12 20:40:24 PST
As was predicted earlier, scammers have now moved these scams to the various browser's dev tools
http://webcache.googleusercontent.com/search?q=cache:-OBSVnTjcHUJ:iamshemul.com/facebook-new-spam-scripts-hack-fb-accounts-3-minutes/+&cd=1&hl=en&ct=clnk&gl=us&client=firefox-nightly

(cache copy because the original appears overlimit)

According to http://www.ultgate.com/3742/arabic-facebook-spam this has affected 1/2 million accounts.
Comment 46 Joe Walker [:jwalker] (needinfo me or ping on irc) 2014-03-07 02:12:15 PST
*** Bug 971613 has been marked as a duplicate of this bug. ***
Comment 47 Jeff Griffiths (:canuckistani) (:⚡︎) 2014-04-22 15:08:04 PDT
I have a modest proposal:

* implement something similar to chrome's 'warn if console history has less than ten entries'[1]
* turn on the feature for only Release and Beta channels

IMO chrome's approach would help us to, on release and beta. If we reduce the surface area for these scams to just the Aurora/Nightly populations, even if we grow those 10x to 2 million users I doubt a user base that size would be of much interest to scammers given my understanding of the relative sophistication of Aurora / Nightly users. 

[1] https://code.google.com/p/chromium/issues/detail?id=345205#c21
Comment 48 Manish Goregaokar [:manishearth] 2014-04-22 15:39:26 PDT
@Jeff doing what Chrome does was agreed on by jruderman on bug 994134

(Unfortunately the discussion for this isue is spread out across many bugs/metabugs)

Note You need to log in before you can comment on or make changes to this bug.