Open Bug 664589 Opened 13 years ago Updated 2 years ago

[meta] Allow content security policy to inform developer tools JS execution

Categories

(DevTools :: General, defect)

Product:
DevTools
Component:
General
Type:
defect

Tracking

(Not tracked)

People

(Reporter: bsterne, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Keywords: meta, sec-want, Whiteboard: [sg:want?][see comment 34]) 

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.
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.
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.
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.
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
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?
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.
(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.
(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?
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)
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.
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.
Whiteboard: [sg:want?]
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".
(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".
(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?
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
    ...
(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.
(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.
(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.
(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.
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.
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.
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.
(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.
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.
(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?
(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.
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.
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.
(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.
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
(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.)
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.)
> 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.
Depends on: 710273
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!
Summary: Hide Web Console and other Developer Tools behind a preference → [meta] Allow content security policy to inform developer tools JS execution
(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.
Whiteboard: [sg:want?] → [sg:want?][see comment 34]
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!
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 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?
(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. :)
I wish to negative vote this but don't see any option how to.
(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?
(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.
Blocks: dev-self-xss
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.
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
@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)
Product: Firefox → DevTools
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.