Open Bug 38933 Opened 24 years ago Updated 2 years ago

Warn before using foreign authentication/cookies/POST data

Categories

(Core :: Security, defect, P3)

Product:
Core
Component:
Security
Type:
defect

Tracking

()

Milestone:
Future

People

(Reporter: mpt, Assigned: dveditz)

References

(Blocks 2 open bugs,
URL
)

Details

A new class of trojan horse attack has been discovered which affects practically 
all browsers, and most Web sites which allow individual users to enter data (such 
as message boards, for example).

See URL for details. Briefly, someone posts an innocuous-looking link to a page, 
and you click on it; the linked page, however, redirects you to an URL which does 
something malicious with your user account on some server -- such as posting an 
embarrassing comment on a discussion board, or deleting your Web site using
Web-based server administration, or whatever.

A simpler form of the attack is to provide a link which is not even a redirect, 
but a link to the actual damaging URL, and to use JavaScript to mimic the 
client's feedback for a legitimate link (e.g. putting a fake URL in the status 
bar).

Individual servers can implement a number of partial fixes to this problem, based 
on the HTTP referrer, cookies, and so on. But every site in the world can not be 
trusted to do this, so Mozilla should do its bit to fix the problem too.

So, I recommend that whenever a user is directed
--- to an URL which requires authentication,
--- from a non-local source which did not require that same authentication,
e.g.
--- to an URL which deletes my Hotmail Inbox folder (if I have one)
--- from an URL which did not require my Hotmail authentication,

AND the required authentication has been cached (either permanently, or for the 
current session) by the browser, THEN a dialog should be displayed:

+--------------------------------------------------------+
|[] Security warning ::::::::::::::::::::::::::::::::::::|
+--------------------------------------------------------+
| /!\  To open this address, Mozilla needs to use your   |
| `-'  stored login for `{Realm}' at`{server}'.          |
|                                                        |
|      If you did not intend to use your `{Realm}' login |
|      now, you should select Cancel.                    |
|                                                        |
| ( Help )                     ( Cancel ) (( Continue )) |
+--------------------------------------------------------+

This wouldn't fix the whole problem (such as the recent example on Slashdot where 
someone posted a link which, when clicked by any subscriber, posted a comment of 
arbitrary content which appeared to be from that subscriber); but it would be a 
good start.

You probably want a list of trusted source domains too, along the lines of the 
`No proxy for:' list in prefs -- so that corporate firewall users don't have to 
be presented with this dialog each and every time they follow a link which goes 
from their Intranet (which doesn't require authentication) to the world outside 
(which does).
See also bug 38008.

Gagan, I heard you know about HTTP authentication. This is a security exploit
involving redirects and authentication - could you please take a look?
Assignee: mstoltz → gagan
*** Bug 40132 has been marked as a duplicate of this bug. ***
Waitasec. My original suggestion would work for cases using genuine HTTP 
authentication, but it wouldn't work for the usual (Hotmail, Slashdot, etc) cases 
of just using cookies for login. Hmmmm.

Ok, the analagous way of dealing with it for cookies would be: whenever a user is 
directed
--- to an URL where the HTTP request reads a particular existing cookie,
--- from a non-local source which did not read that same cookie,
show a similar dialog.

And you'd want to have a checkbox to turn the dialog off on a cookie-by-cookie 
basis, for those cookies where any use of the cookie was harmless. Come to think 
of it, you'd probably want that for HTTP authentication, too.

So, take two. For HTTP authentication:

+--------------------------------------------------------+
|[] Security warning ::::::::::::::::::::::::::::::::::::|
+--------------------------------------------------------+
| /!\  To open this address, Mozilla needs to use this   |
| `-'  stored login (HTTP authentication):               |
|      server [                                        ] | \ non-editable, but
|      realm  [                                        ] | / scrollable, fields
|                                                        |
|      If you did not intend to use this login now, you  |
|      should select Cancel.                             |
|                                                        |
|      [*] Always warn me about using this login         |
|          (this can also be changed in the Xyz Manager) |
|                                                        |
| [?]                          ( Cancel ) (( Continue )) |
+--------------------------------------------------------+

And for cookies:

+--------------------------------------------------------+
|[] Security warning ::::::::::::::::::::::::::::::::::::|
+--------------------------------------------------------+
| /!\  While opening this address, Mozilla has been      |
| `-'  asked to send this stored data (cookie):          |
|      server [                                        ] | \ non-editable, but
|      name   [                                        ] | / scrollable, fields
|                                                        |
|      If you did not intend to use this data now, you   |
|      should select Don't Send.                         |
|                                                        |
|      [*] Always warn me about using this cookie        |
|          (this can also be changed in the `Cookies'    |
|          category of Preferences)                      |
|                                                        |
| [?]  ( Don't Send )              ( Cancel ) (( Send )) |
+--------------------------------------------------------+

Note that the second dialog doesn't actually show the value of the cookie -- as a 
guard against the case where a malicious co-worker sends you an e-mail message 
containing such a link, and then tries to read over your shoulder as you follow 
the link.

The difference between `Don't Send' and `Cancel' in the second dialog is that 
`Don't Send' continues the HTTP request without sending the cookie, whereas 
`Cancel' cancels the HTTP request altogether.

Further thoughts:

* This attack can be called from JavaScript, not just from redirects. This calls
  for two changes in the dialogs:
  - instead of the server name, the dialogs should probably show the actual
    address being accessed, providing the user with some additional information
    about what the access is actually trying to do (this would probably have been
    a good idea anyway);
  - the text `To open this address' or `While opening this address' should be
    deleted, since the attack may be called from JavaScript when (as far as the
    user is concerned) the main `address' has already been opened.

* It would still be up to discussion sites such as Slashdot to prevent posters
  from including JavaScript in their posts -- otherwise a poster could post an
  attack on the same site as the one on which the undesirable effect happened,
  and this dialog would never appear (because the source and the destination
  would be at the same server).

Here's some useful linkage (mostly from bug 40132):
* <http://www.zope.org/Members/jim/ZopeSecurity/ClientSideTrojan> (original
  article)
* <http://lwn.net/2000/features/Redirect.phtml> (a general summary)
* <http://www.linuxnews.com/news/?1,145> (another general summary)
* <http://slashdot.org/comments.pl?sid=00/05/19/190219&cid=42> (example of
  attack -- there's a more friendly example on Slashdot somewhere, but I can't
  find it)
* <http://weblogs.oreillynet.com/edd/stories/storyReader$52> (possible solutions
  discussed)
* <http://weblogs.oreillynet.com/edd/discuss/msgReader$54> (a suggested need for
  some measurement of `intent' when doing something with authentication).

Martijn and I posted some comments on bug 40132 (marked as dup) that I think 
are very relevant here.  Martijn suggested that we tell sites what type of user 
interaction led to the loading of the site; I suggested that mozilla filter all 
cross-site form submissions (including GET forms, but with a separate "ignore 
this warning" setting).


Matthew's dialog only seems to address the case where the victim has a cookie 
or http auth.  It doesn't help with sites that accept anonymous comments, or 
sites that accept comments based on self-reported name and display your IP 
address, if the sites don't check the referrer for form submissions.


> from an URL which did not require my Hotmail authentication
Does the browser know that *.hotmail.passport.com requires the same 
authentication that *.hotmail.msn.com requires?
I said `Mozilla should do its bit to fix the problem', but Mozilla will only be 
able to go so far. Here's why the situations cited by Jesse can't be guarded 
against in the client.

> Martijn suggested that we tell sites what type of user interaction led to the
> loading of the site

We do this already, through the HTTP referrer. If sites need more detail than 
that, there's not much we can do without extending the HTTP standard.

> mozilla [should] filter all cross-site form submissions (including GET forms,
> but with a separate "ignore this warning" setting)

There are far too many ordinary URLs which are both (a) of the GET type and (b) 
often linked to from other sites, for something like this to be useful. Examples:
- Bugzilla bug reports
- ZDNet stories
- search engine results
- CNet stories
- Deja.com Usenet articles
- most NetCenter links.
Even with the option for turning it off for individual servers, you'd be turning 
it off more often than you'd be actually using it. So dialog fatigue would set in 
-- the user would start clicking `Continue' automatically, making the dialog 
useless.

> Matthew's dialog ... doesn't help with sites that accept anonymous comments,

And the damage would be much less for such sites -- such an attack would not do 
anything more harmful than post an anonymous comment claiming to be from you, 
something which could be easily refuted since it was posted anonymously.

>                                                                              or 
> sites that accept comments based on self-reported name and display your IP
> address, if the sites don't check the referrer for form submissions.

Such sites are broken -- if Mozilla tried to cater for them then it would be too 
annoying when visiting other sites, and the warning effect would be lost (as 
described above).

> Does the browser know that *.hotmail.passport.com requires the same
> authentication that *.hotmail.msn.com requires?

No, and that's a good thing. On both the big-brother level and the practical 
security level, Mozilla should be encouraging storage of global passwords in your 
local Wallet or Keychain, not on a server like passport.com.

Heh. Just when I post a bug on the issue it turns out someone else already did
this for me. Thanks Matthew.

This problem will not be easy to fix. It comes in several forms, involving
redirects, tricking users into clicking an image, a link, a button, or using
Javascript.

I can also think of several scenarios where the Referere field does not give
enough contextual information for the server to be able to determine wether or
not the request is legitimate. Also, the Referer field is seen as revealing
privacy sensitive information, and is filtered out by some proxies or firewalls,
often outside the control of the affected user.

I suggested that browsers start giving some more contextual information,
information that is not privacy sensitive, and which can help in many
situations. I do not claim that with it we can fully mitigate risk in all
possible scenarios, just that it would help.

Again, this is not a problem easily solved. Discussion on this issue is needed.
Matt, I don't think you got many of my points.  Maybe my wording sucks.

>There are far too many ordinary URLs which are both (a) of the GET type and 
>b) often linked to from other sites, for something like this to be useful. 

Good point.  Since (someone?) recommends that GET forms be used for searches 
and displaying information and POST forms be used for altering data, it would 
be reasonable to not block cross-site GET forms.  

Mozilla should (IMO), however, aggressively filter cross-domain posting.  That 
means hotmail.com should give a warning the first time, and allow the user the 
option of saying "allow hotmail.com to post to passport.com".

You say "these sites are broken" in response to one of my examples.  This is 
not an adequate response, this bug is *about* protecting broken sites and users 
of those sites.  A huge percentage of dynamic-content sites are vulnerable, and 
some fairly recent (but not current) versions of apache itself were as well.

Many "anonymous" comments sites do log ip addresses.  I can make it look like 
one of the visitors on my website is attacking another website.  Also, I can 
flood another site from various IP addresses without the attack being traceable 
back to me.  This problem will mostly go away if major browsers block cross-
site posting.

Another problem with only enforcing the POST policy for sites where you have a 
cookie/auth is that you might want to get a cookie/auth later, or might assign 
you a cookie when you make your first post.

Sites that use cross-domain posting, while usually not malicious, are 
relatively rare, and more importantly, are indistinguishable from malicious 
sites doing the same thing.  Hotmail.com should show a warning the first time.

Note: bugzilla is not excluded from the "broken sites" set.  It accepts GET 
forms for modifying data, doesn't check for cross-site posting, and only 
escapes URL parameters on about half of the commonly used pages.  The last two 
are at least partially covered by dependencies of bug 38852.

<end unconnected rant>
Summary: Warn before going to URLs which need different authentication → Warn before using foreign authentication/cookies/POST data
Jesse, you're right. The bit about cross-domain POSTing flew completely over my 
head.

Ok, take three -- incorporating fixes for all the problems I've thought of so far 
(including the problem where the first sentence of the dialog needs to give some 
idea of the purpose of the dialog) ...

For following a link/redirect/script from a non-authenticated document to an 
authenticated one:
+--------------------------------------------------------+
|[] Security warning ::::::::::::::::::::::::::::::::::::|
+--------------------------------------------------------+
| /!\  Mozilla needs a different login to open the       |
| `-'  address                                           |
|      [http://cantsb.canterbury.ac.nz/transfer_funds.c] |
|                                                        |
|      To open this address, Mozilla needs to use the    |
|      following login (HTTP authentication):            |
|      Server: [cantsb.canterbury.ac.nz                ] |
|      Realm:  [ITS                                    ] |
|      If you did not intend to use this login now, you  |
|      should select `Cancel'.                           |
|                                                        |
|      [*] Always warn me about using this login         |
|                                                        |
| [?]                          ( Cancel ) (( Continue )) |
+--------------------------------------------------------+

For following a link/redirect/script from document A to document B, where 
document B requires a cookie which document A did not:
+--------------------------------------------------------+
|[] Security warning ::::::::::::::::::::::::::::::::::::|
+--------------------------------------------------------+
| /!\  Mozilla has been asked for a different cookie     |
| `-'  while opening the address                         |
|      [http://webmail.com.foo/act/DELETE/folder/Inbox/] |
|                                                        |
|      Mozilla has been asked to send the following      |
|      stored data (`cookie').                           |
|      Server: [webmail.com.foo                        ] |
|      Data:   [user_id                                ] |
|      If you did not intend to use this data now, you   |
|      should select Don't Send.                         |
|                                                        |
|      [*] Always warn me about using this cookie        |
|                                                        |
| [?]  ( Don't Send )              ( Cancel ) (( Send )) |
+--------------------------------------------------------+

And finally, for following a link/redirect/script which POSTs data from one 
server to another:
+--------------------------------------------------------+
|[] Security warning ::::::::::::::::::::::::::::::::::::|
+--------------------------------------------------------+
| /!\  Mozilla has been asked to post data to a          |
| `-'  different server to open the address              |
|      [http://slashdot.org/post_comment.cgi           ] |
|                                                        |
|      Mozilla has been asked to post the following      |
|      data:___________________________________________  |
|      [Name_________|_Value___________________________] |
|      |user_id      | davidr8                       |A| |
|      |comment      | STUPIDEST POST!!!!!1          |:| |
|      |_____________|_______________________________|V| |
|      If you did not intend to send this data, you      |
|      should select Cancel.                             |
|                                                        |
|      [*] Always warn me about posting from this server |
|                                                        |
| [?]                              ( Cancel ) (( Send )) |
+--------------------------------------------------------+

I'm concerned about taking a user-warning based approach to this 
problem. As Matthew touched on above, there is a big danger that
"dialog fatigue" will render these warnings useless over time. I 
think that in the end to really solve this problem in a satisfactory
way web clients and servers will need to cooperate in a way that 
(with or without client-based warning dialogs) provides servers 
with enough context to determine if a request is appropriate. 

As Matthew also noted, this may be hard without extending protocol 
expectations. That may well be the case - but just because it's hard 
doesn't mean it shouldn't be done. The more I think about this the more 
convinced I am that this is the more promising direction (though I dont 
pretend to be clear about the details of that direction yet). 

The server will need to be involved in this process, because any 
arbitrary decisions made by client(s) will restrict the kinds of 
things you can do securely on a server. A case in point: the current 
proposals tend to be concerned about security across a "domain" or
"servers". While a domain or server is certainly an example of _a_
security context, there are much finer-grained security contexts in
use on the Web. And what we are really talking about here is not even
totally confined to a _security_ context, but to context in general. 
The current Web architecture provides ways for foreign objects to 
force you into taking unintended actions, and provides no reliable 
standard ways for either the client or the server to discover enough 
about the context to determine if the action is suspicious. 

FWIW, the default security for javascript suffers from the same lack
of context IMHO. Current clients take measures to prevent "cross-site 
scripting" but the idea of "site" here is quite literal, "hard-coded" 
(in the client implementations) and too coarse-grained. What about a 
"site" like a GeoCities or any number of similar web presences where many, 
many people and/or organizations share the same site? The cross-site 
scripting protection currently provided by clients does not protect 
these folks. I think that it would be a poor answer to say
"well, sites like that will just never be secure, so don't build sites
like that".


Brian, Martijn, Jesse: If you want a more thorough, protocol-based solution to 
this kind of trojan, you should reopen bug 40132, mark this bug as a dependency 
of that one, and carry on the discussion there. Or even better, discuss the 
problem in n.p.m.security, so you can then file specific bugs which will get 
fixed rather than using Bugzilla as a discussion board.

This particular suggestion is a relatively cheap (in development hours) attempt 
to curtail the vast majority of these attacks, right now. Yes, I do realize it 
won't work with GeoCities, but I calculate that the ratio of {risk of one 
GeoCities site attacking another} to {stuff that could be done about that problem 
right now} is very low. And no, I don't think it will cause dialog fatigue by 
having a high rate of false positives, since (a) it doesn't operate on GET 
requests and (b) it is possible to turn the warnings off on a server-by-server 
basis.

Nominating for RTM -- these attacks are already appearing in experimental form on 
sites such as Slashdot, so it's only a matter of time before they manifest 
themselves elsewhere. And CCing verah, just in case she can find anything wrong 
with my dialog text.
Keywords: rtm
Okay, marking dependency, reopening other bug.
Depends on: 40132
No longer depends on: 40132
Depends on: 40132
Fixing dependencies ...
No longer depends on: 40132
... done
Blocks: 40132
Assigning Qa to czhang.
QA Contact: junruh → czhang
Interesting!

I'd like a chance to rewrite the dialogs slightly, just so the "average" person 
out there will know what's going on and perhaps have a clue as to what to do 
about it.

What's the target milestone for this?
IMO, this is all a case of bad server-side design.

Classic examples of this class of error include using GET rather than POST when
submitting passwords (and hence getting passwords placed into the history list
:-( ).

Sites which take actions based solely upon a visit with an appropriate URL
(where actions are defined as posting email, deleting accounts, changing
privledge on access to things, etc. etc.) have fatal flaws.  If we try to
protect people from the poorly designed sites, we'll end up harming the
usability of well designed sites.

As an example, the New York Times requires certain logins for use. A lot of
folks email out pointers to articles in the New York Times.  If we add this
protective feature, we'll soon begin bother folks with extra dialogs as the
visit the New York Times.

Considering that there is even an attempt listed above to block
cookie-based-authentication, we'd also end up slowing all sorts of visits to
advertising sites that have already set a cookie on the user (there is no way to
distinguish identifying cookies from authentication cookies :-( :-( ).

In fact, since Netscape sets an id cookie historically, we'd end up issuing a
security warning every time anyone tried to link to a Netsacpe site :-( :-(.  My
bet is that 90% of all commercial sites set some cookies... so all such sites
would now have security warnings on visitations :-/.  The big follow-up RFE
would be to have a way to turn off this feature.

Bottom line: Please think carefully about such RFEs.  Unless there is a big
gain, and usability, the security we gain may come in the form of folks not
being willing to use our product :-(.
This isn't an easy issue, as already stated in #40132. This bug is a concrete
proposal for solving one problem, but the root cause of the problem is discussed
in #40132.

The servers aren't entirely to blame, the current set of information sent by the
browser doesn't contain enough context to always fully determine the context of
a request, which would help the server decide if the request is genuine. If more
contextual information was available, this particular RFE may not be necessary
at all, the server can then more accuratly assess the situation.
Jim: I guess you're right about URL-dependent servers being too broken to 
bother fixing. Ok, so let's apply the warnings just to redirects, IMGs/OBJECTs, 
and scripts, and not to links. That removes the dialog from well-behaved 
servers like nytimes.com (though whether requiring registration at all is `good 
behavior' is obviously a matter of opinion). It doesn't solve the problem for
badly-behaved (but non-malicious) sites like netscape.com, which redirect you 
between half a dozen different places when you click on a link; but if you 
visit sites like that regularly, you can check the `Always warn me about using 
this cookie' checkbox.

This will be getting the 4xp keyword soon ... Microsoft is about to offer the 
same dialog for cookies in IE 5.5. See
<http://microsoft.com/presspass/images/features/07-20cookies.jpg>. (And IMNSHO, 
my dialog is clearer than IE's one.:-)
Assignee: gagan → mstoltz
Keywords: rtm → nsbeta3
Removing nsbeta3 and retargeting Future, for the following reasons:
1) This bug is mainly the server's responsibility to fix
2) Our security UI policy is for as few warning dialogs as possible. I'm not 
convinced these things really help security (although they may reduce Netscape's 
liability).
3) Adding new dialogs could be destabilizing at this point in the product cycle.

I think the ratio of work to benefit here is too high to be working on this 
problem right now.
Status: NEW → ASSIGNED
Keywords: nsbeta3
Target Milestone: --- → Future
*** Bug 51691 has been marked as a duplicate of this bug. ***
QA Contact: czhang → junruh
Mass changing QA to ckritzer.
QA Contact: junruh → ckritzer
Blocks: csrf
Assignee: security-bugs → dveditz
Status: ASSIGNED → NEW
QA Contact: ckritzer → toolkit
This issue is closely related to the recently reported drive-by pharming security threat. in that case, the illegitimately accessed web site is the user's home router. See https://bugzilla.mozilla.org/show_bug.cgi?id=371598 for more details. 
I'm not sure which of XSRF related bugs is the correct place for this comment.

I was thinking that a large number of the vulnerabilities can be mitigated by not sending cookies by default if the referrer is on a different domain from the URL being fetched. But proceed with loading the URL as usual.

I guess it may break some sites. But I think the way to find out what it breaks is to introduce the functionality to suppress cookies in those cases. There should be a setting to turn it on and off, and at first it should probably use the old behaviour by default.

This issue has been open for a decade. And by now I think we can agree that getting it fixed on all the vulnerable sites is just not going to happen.

Even security aware users are bound to need to use vulnerable sites once in a while, and currently it seems the only safe way to do so is to:
1. Ensure nothing else is open while logging in to the vulnerable site (restart the browser before just to be on the safe side).
2. Stick to just that one site for the session.
3. Log out when done.
4. Restart the browser again, just in the site left some sensitive session cookies even after logging out.

It is possible to use sites with XSRF vulnerabilities safely, but it requires a huge amount of discipline from the users and severely reduces the usability of the browser when you can't open other tabs to look up documentation while logged in to a vulnerable site.

The defence in depth principle suggests this should be fixed both on the client and on the server side.
I strongly support this RFE.

@Jim: This isn't actually bad server-side design. A server receives a POST request that has the correct cookies or HTTP AUTH for a validly logged-in user. The fact that the user didn't intend to make the request, or even know about it, is not apparent. Actioning that request is not a broken thing to do. I've recently been implementing protection against these threats at work, and even with a framework that specifically supports this, getting it right is non-trivial.

Also, the proposed dialog would not be significantly more fatiguing than the existing 'Ask me every time' dialog for cookies, particularly if it applied only to POST requests (which is reasonable). There's lots of synergy, too, because if you're selective about which domains can set cookies, you shouldn't often see the cross-site cookie dialog. But like the original cookie dialog, it should probably be off by default.

At present, if I browse to evil.com, it can send arbitrary requests to bank.com (using JavaScript, IFRAMES, redirects, etc), and if I happen to be logged in, then the browser will happily attach the appropriate cookies or auth so that bank.com thinks those requests came from me. The problem is made worse because Firefox shares session across all browser windows, so there's no way to isolate bank.com without shutting the browser down and restarting it. That sounds to me like bad browser design.

Currently I have to rely on highly invasive addons like NoScript and RequestPolicy to protect against holes like this. I personally am happy to make that tradeoff to keep my security, but very many users are not. Incorporating an optional warning like this would allow security-conscious-but-not-tech-savvy users to be safer.

I would suggest wording similar to:
"The site foo.com is trying to send a request to bar.com. You currently have one or more cookies for bar.com, which could mean that you are logged in to bar.com.

If you allow this request to use your cookies, then bar.com will think that the request came from you.

Do you trust foo.com to take actions on your behalf at bar.com?

x Remember my decision for this website

Yes (send cookies)    No (send without cookies)    Block request
HTTP AUTH dialog would be similar, but shorter:

"The site evil.com is trying to send a request to bank.com. You are currently logged in to bank.com.

If you allow this request to use your logged-in session, then bank.com com will think that the request came from you.

Do you trust evil.com to take actions on your behalf at bank.com?
...
"
The recently-published CRIME attack against TLS could be defeated by this RFE, because when the attack script started to send requests to the target site, the user would be alerted and given the option to anonymize or block the requests.
And now we have the BREACH attack against TLS, which allows an attacker to extract sensitive data from encrypted HTTP responses. Again, this RFE could defeat the attack, because if the request is anonymized, then the response will not contain anything sensitive.

I think it's clear by now that from a security standpoint, the idea of automatically attaching cookies to any arbitrary request, made by any website, is broken. Cookies have become a 'something you have' authentication factor, and that authentication should not be available for any random website to exploit without even notifying the user.
Can something be done about this?

Cookies may have started life as mere site preferences, but now they represent authentication. Blindly attaching the user's authentication to any and every potentially-malicious cross-site request is begging for trouble.

Let's at least do something about the worst-case scenario: an unencrypted site (attacker.com) wants to send a cross-domain POST request to an encrypted site that has set cookies. That's pretty clearly suspicious behavior. There should be at least an about:config preference to block this or prompt the user.
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 10 votes.
:dveditz, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dveditz)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(dveditz)
You need to log in before you can comment on or make changes to this bug.