Last Comment Bug 757046 - Investigate interim solutions for enablePrivilege
: Investigate interim solutions for enablePrivilege
Status: RESOLVED FIXED
: addon-compat, dev-doc-needed, relnote
Product: Core
Classification: Components
Component: Security: CAPS (show other bugs)
: unspecified
: All All
: -- normal (vote)
: mozilla17
Assigned To: Bobby Holley (:bholley) (busy with Stylo)
:
Mentors:
: 546848 (view as bug list)
Depends on: 695292 762528 762908 778420 783031 784560 784857 785162 786852 791526 817523
Blocks: 762314 797443
  Show dependency treegraph
 
Reported: 2012-05-21 07:48 PDT by Bobby Holley (:bholley) (busy with Stylo)
Modified: 2013-11-08 08:23 PST (History)
26 users (show)
dveditz: sec‑review? (dveditz)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Proof-of-concept. v1 (5.73 KB, patch)
2012-06-04 08:17 PDT, Bobby Holley (:bholley) (busy with Stylo)
no flags Details | Diff | Splinter Review
PoC. v2 (5.63 KB, patch)
2012-06-19 08:59 PDT, Bobby Holley (:bholley) (busy with Stylo)
no flags Details | Diff | Splinter Review
Convert enablePrivilege into an insecure test-only construct (preffed off everywhere but in automation). v2 (12.36 KB, patch)
2012-06-29 14:47 PDT, Bobby Holley (:bholley) (busy with Stylo)
bzbarsky: review+
Details | Diff | Splinter Review
Turn on enablePrivilege for JSReftests. v1 (816 bytes, patch)
2012-08-22 17:39 PDT, Bobby Holley (:bholley) (busy with Stylo)
no flags Details | Diff | Splinter Review

Description Bobby Holley (:bholley) (busy with Stylo) 2012-05-21 07:48:02 PDT
We're running up against a wall with enablePrivilege. It looks like it's going to break when IonMonkey lands on June 15th, because it uses stack frame annotations to scope capabilities, and IonMonkey doesn't create JSStackFrames.

Gijs is hard at work fixing up our test suite over in bug 750638. But the amount of stuff remaining over there is still a pretty big unknown, and just crossing our fingers on this one is dangerous.

So I think it's worth investigating what we can do to keep our test suite running with enablePrivilege more or less removed.

My current thinking is that we should turn enablePrivilege into a really dumb and kludgy hack that's accessible exclusively to mochitests via a pref. Well, ok, it's already sort of like that. But I'm proposing we make it more so.

My hope is that we can just get rid of the stack-scoping and turn it into a per-compartment boolean that, once set, is never unset. This will break any consumers that change compartments between the enablePrivilege call and the privileged operation, but hopefully there aren't too many of those.

I've got a patch that does just that. I'll push it to try momentarily.
Comment 1 Bobby Holley (:bholley) (busy with Stylo) 2012-05-21 07:52:07 PDT
https://tbpl.mozilla.org/?tree=Try&rev=7ef083f465f8
Comment 2 Boris Zbarsky [:bz] 2012-05-21 08:13:16 PDT
I thought that Ion could reify stackframes as needed (e.g. for debugging purposes).  Is that not the case?

> My hope is that we can just get rid of the stack-scoping [and leave privs on once
> enabled]

1)  That will almost certainly break some tests.  Of course we need to fix those anyway.

2)  This will open security holes in existing enablePrivilege consumers.  I don't think that's acceptable.  Disabling enablePrivilege entirely is preferable to making it a footgun from hell.
Comment 3 Bobby Holley (:bholley) (busy with Stylo) 2012-05-21 08:17:45 PDT
(In reply to Boris Zbarsky (:bz) from comment #2)
> I thought that Ion could reify stackframes as needed (e.g. for debugging
> purposes).  Is that not the case?
> 
> > My hope is that we can just get rid of the stack-scoping [and leave privs on once
> > enabled]
> 
> 1)  That will almost certainly break some tests.  Of course we need to fix
> those anyway.

Yeah. The hope is that the overlap between that and the wrapped-Components-injection strategy gives us a reasonable amount of tests to fix manually.

> 2)  This will open security holes in existing enablePrivilege consumers.  I
> don't think that's acceptable.  Disabling enablePrivilege entirely is
> preferable to making it a footgun from hell.

My intention is to turn it off entirely for external consumers. There will be a new pref, unpublicized, that we'll set in the mochitest profile. We'll call it something scary like "make_everything_insecure" and make big comments around it telling people that it's only suitable for testing. If someone digs it up and decides to use it, well, too bad.
Comment 4 Boris Zbarsky [:bz] 2012-05-21 08:29:57 PDT
> The hope is that the overlap between that and the wrapped-Components-injection strategy
> gives us a reasonable amount of tests to fix manually.

I should have been clearer.  "break" meant "make them no longer test what they're supposed to be testing", not "make orange"...

As in, we still need to make sure that all enablePrivilege calls are gone from tests.

> My intention is to turn it off entirely for external consumers.

OK.  We should make that clear _now_. Loudly.  Because we definitely have external consumers, and now we can give them a hard timeline on when they need to fix their stuff.
Comment 5 Bobby Holley (:bholley) (busy with Stylo) 2012-05-21 10:26:32 PDT
(In reply to Boris Zbarsky (:bz) from comment #4)
> As in, we still need to make sure that all enablePrivilege calls are gone
> from tests.

Agreed.

> 
> > My intention is to turn it off entirely for external consumers.
> 
> OK.  We should make that clear _now_. Loudly.  Because we definitely have
> external consumers, and now we can give them a hard timeline on when they
> need to fix their stuff.

Sounds good. I think we should land this at the beginning of the next cycle. We've already landed the removal of the confirm dialog, which will serve as a wake-up call (customers can still use enablePrivilege by manually setting a pref). So we can communicate that the confirm dialog goes away in FF15, and that enablePrivilege goes away in FF16. The merge happens on June 2, which should give us time to land this and let the dust clear before IM lands on the 15th.

Boris, what's the best way to communicate this? A dev-platform email? A blog post?

The try push is orange, but not insurmountably so. I could probably turn that tree green in 4 hours or so, give or take. Or maybe Gijs could take a look at it, given that it looks like there's some overlap with the failures he's seeing.
Comment 6 Boris Zbarsky [:bz] 2012-05-21 10:38:14 PDT
> Boris, what's the best way to communicate this?

I have no clue.  At the very least getting Jorge involved is important.  He may be able to recommend others who have ideas as well.  The point is to communicate to extension authors and intranet developers, not to people who would be reading dev-platform or your blog...
Comment 7 Jorge Villalobos [:jorgev] 2012-05-21 13:07:37 PDT
Add-ons using enablePrivilege have been rejected for a very long time now, and at least add-on developers on AMO should know that it isn't an option anymore. We will certainly announce on the blog when it finally breaks, and I expect the impact for add-ons to be small.

As for intranet usage, I'm not sure. It would make sense to announce it in the EWG list, at least. Adding Kev and Mike Kaply for comment.
Comment 8 Mike Kaply [:mkaply] 2012-05-21 13:15:53 PDT
I would suggest we ask on the EWG, but I know the last time I tried to do signed scripts it was such a pain in the butt that I gave up.

My bet is that anyone else trying to do this encountered the same problem.
Comment 9 Bobby Holley (:bholley) (busy with Stylo) 2012-06-04 08:17:01 PDT
Created attachment 629785 [details] [diff] [review]
Proof-of-concept. v1

Attaching proof-of-concept. This turns the tree orange, but not impossibly so.
Comment 10 Bobby Holley (:bholley) (busy with Stylo) 2012-06-06 04:51:11 PDT
Did an updated push with wchen's changes:

https://tbpl.mozilla.org/?tree=Try&rev=19592932cb80
Comment 11 Bobby Holley (:bholley) (busy with Stylo) 2012-06-08 08:45:36 PDT
I've fixed a bunch more tests for this. Repushing to try:

https://tbpl.mozilla.org/?tree=Try&rev=bfd6272b10f7
Comment 12 Bobby Holley (:bholley) (busy with Stylo) 2012-06-10 14:51:20 PDT
more: https://tbpl.mozilla.org/?tree=Try&rev=9894827c9486
Comment 13 Mike Kaply [:mkaply] 2012-06-15 05:58:45 PDT
Can someone give me a summary to post to the EWG? Should I just say enablePrivilege is going away?
Comment 14 Bobby Holley (:bholley) (busy with Stylo) 2012-06-18 12:33:27 PDT
(In reply to Michael Kaply (mkaply) from comment #13)
> Can someone give me a summary to post to the EWG? Should I just say
> enablePrivilege is going away?

Yes. The confirm dialog goes away in FF15, which means that continued use of enablePrivilege will require manually setting a pref (rather than clicking through the confirm dialog, which did that automatically). In FF16 enablePrivilege goes away entirely (we'll continue to use a bastardized form of it for Mochitest only, but it will not be available in production releases).
Comment 15 Bobby Holley (:bholley) (busy with Stylo) 2012-06-18 12:33:56 PDT
(Also, recommend that privileged code move into an extension)
Comment 16 Bobby Holley (:bholley) (busy with Stylo) 2012-06-19 03:19:30 PDT
Doing another try push now that some of the dependent code has stabilized:

https://tbpl.mozilla.org/?tree=Try&rev=c9d74be1f097
Comment 17 Bobby Holley (:bholley) (busy with Stylo) 2012-06-19 05:59:28 PDT
Alright! This is starting to look greener than ever. :-)
Comment 18 Bobby Holley (:bholley) (busy with Stylo) 2012-06-19 08:59:33 PDT
Created attachment 634458 [details] [diff] [review]
PoC. v2
Comment 19 Bobby Holley (:bholley) (busy with Stylo) 2012-06-28 15:27:49 PDT
I just landed bug 754202, so now it's time to take another look at the state of affairs here:

https://tbpl.mozilla.org/?tree=Try&rev=a2dc261b6f9a
Comment 20 Bobby Holley (:bholley) (busy with Stylo) 2012-06-29 03:04:10 PDT
Alright, looking good!

So Joel, those M-5 prompt tests are the ones I was talking about. Can you look into them? I'll fix those last 2 M-4 editor failures and then we should be in good shape!
Comment 21 Bobby Holley (:bholley) (busy with Stylo) 2012-06-29 03:33:19 PDT
For reference, my github branch (equivalent to what I just pushed to try) is here:

https://github.com/bholley/mozilla-central/commits/interimprivs
Comment 22 Bobby Holley (:bholley) (busy with Stylo) 2012-06-29 14:47:51 PDT
Created attachment 638024 [details] [diff] [review]
Convert enablePrivilege into an insecure test-only construct (preffed off everywhere but in automation). v2

Turned my PoC into a real patch.
Comment 23 Bobby Holley (:bholley) (busy with Stylo) 2012-06-29 14:49:07 PDT
Alright, I fixed up M-4, and got the tests fixes into more reviewable condition. Pushing to try again:

https://tbpl.mozilla.org/?tree=Try&rev=139a7dbcfcae
Comment 24 Bobby Holley (:bholley) (busy with Stylo) 2012-06-30 01:46:46 PDT
Hm, looks like this patch (which puts enablePrivilege behind a pref enabled in automation.py.in) totally borks talos:

		Stopped Fri, 29 Jun 2012 16:26:42
Traceback (most recent call last):
  File "run_tests.py", line 580, in run_tests
    browser_dump, counter_dump, print_format = mytest.runTest(browser_config, test)
  File "/Users/cltbld/talos-slave/talos-data/talos/ttest.py", line 261, in runTest
    self.initializeProfile(profile_dir, browser_config)
  File "/Users/cltbld/talos-slave/talos-data/talos/ttest.py", line 133, in initializeProfile
    if not self._ffsetup.InitializeNewProfile(profile_dir, browser_config):
  File "/Users/cltbld/talos-slave/talos-data/talos/ffsetup.py", line 288, in InitializeNewProfile
    raise talosError("initialization timed out")
talosError: 'initialization timed out'

Joel, any thoughts here? Is talos still using enablePrivilege on try? If so, does it not use the prefs in automation.py or something?
Comment 25 Martijn Wargers [:mwargers] (not working for Mozilla) 2012-07-28 06:40:59 PDT
What is the alternative for enablePrivilege?
Comment 26 Bobby Holley (:bholley) (busy with Stylo) 2012-07-28 06:59:05 PDT
(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #25)
> What is the alternative for enablePrivilege?

SpecialPowers.
Comment 27 Mike Kaply [:mkaply] 2012-07-28 07:26:26 PDT
He's talking for web sites and apps.

Can an add on give a site SpecialPowers?

Everyone keeps saying "write an add on" but that doesn't really help.

For people that have web apps with signed scripts using enable privilege, is there a documented replacement?
Comment 28 Bobby Holley (:bholley) (busy with Stylo) 2012-07-28 07:43:50 PDT
(In reply to Michael Kaply (mkaply) from comment #27)
> He's talking for web sites and apps.
> 
> Can an add on give a site SpecialPowers?

It could, in theory, but that's really backwards. The point is that privilege stuff needs to happen in a privileged context. This requires an extension.

> Everyone keeps saying "write an add on" but that doesn't really help.

Why not?

> For people that have web apps with signed scripts using enable privilege, is
> there a documented replacement?

There is not, and my understand is that we're explicitly dropping support for that with a vanilla browser. If people are willing to write an extension to make them work, they can do the privileged stuff in the extension.
Comment 29 Martijn Wargers [:mwargers] (not working for Mozilla) 2012-07-28 07:46:20 PDT
Is there another way to get chrome privileges for local files?
Comment 30 :Gijs Kruitbosch (Gone July 28 - Aug 11) 2012-07-28 09:04:46 PDT
(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #29)
> Is there another way to get chrome privileges for local files?

The most straightforward way to do that is to map them to resource: or chrome:, I suspect? There should be documentation on doing that, and/or looking at MXR for what's happening in the chrome registry should help with getting that going...

If you need something quick for just script, you could just load a file into scratchpad and run it in a chrome env (there's a menu for that).
Comment 31 Mike Kaply [:mkaply] 2012-07-30 11:13:17 PDT
>> Everyone keeps saying "write an add on" but that doesn't really help.

>Why not?

Well, I could write an add-on that gives every site access to Components, but that would probably be bad.

Everyone is saying "write an add-on" without really giving any indication of what a "correct" add-on would look like.

Or without giving any pointers on how to write correctly emulate enablePrivilege.

These folks aren't add-on developers, they are web developers that are losing a core functionality that they needed for their web apps.

So a little bit of specific direction versus "write an add-on" would be nice.
Comment 32 Boris Zbarsky [:bz] 2012-07-30 11:27:01 PDT
The right way to write the add-on is to have it do all the privileged work and only do it on behalf of sites that it trusts.

Now _how_ you go about doing that really depends on the sort of work being done, which is why it's hard to give specific direction.
Comment 33 Jorge Villalobos [:jorgev] 2012-07-30 12:39:51 PDT
Writing an add-on that emulates enablePrivilege would be a bad idea, IMO. Like bz suggests, an add-on should be written to deal with whatever problem is being solved. A website and easily communicate with an add-on by firing a custom event, and all the privileged code can run in the chrome side.
Comment 34 Martijn Wargers [:mwargers] (not working for Mozilla) 2012-08-06 08:28:41 PDT
It doesn't seem that I can do the same with SpecialPowers as with enablePrivilege, can I?
Comment 35 Bobby Holley (:bholley) (busy with Stylo) 2012-08-06 12:17:44 PDT
(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #34)
> It doesn't seem that I can do the same with SpecialPowers as with
> enablePrivilege, can I?

Define "the same"? What are you trying to do? In what context?
Comment 36 Martijn Wargers [:mwargers] (not working for Mozilla) 2012-08-06 12:45:38 PDT
Doing random privileged stuff in local files.
Comment 37 Bobby Holley (:bholley) (busy with Stylo) 2012-08-06 15:05:37 PDT
If you have SpecialPowers installed, you can just do SpecialPowers.wrap(Components).classes[...] and everything should just work. Or you can feel free to add things to the SpecialPowers API.
Comment 38 Bobby Holley (:bholley) (busy with Stylo) 2012-08-16 19:04:59 PDT
Comment on attachment 638024 [details] [diff] [review]
Convert enablePrivilege into an insecure test-only construct (preffed off everywhere but in automation). v2

All the prereqs have landed. Flagging bz for review. \o/
Comment 39 Bobby Holley (:bholley) (busy with Stylo) 2012-08-17 15:32:34 PDT
Green last I checked, but doing an updated macosx-only run to be sure: https://tbpl.mozilla.org/?tree=Try&rev=f21b9bd12250
Comment 40 Boris Zbarsky [:bz] 2012-08-21 20:03:33 PDT
Comment on attachment 638024 [details] [diff] [review]
Convert enablePrivilege into an insecure test-only construct (preffed off everywhere but in automation). v2

>+++ b/caps/src/nsSecurityManagerFactory.cpp
> nsSecurityNameSet::InitializeNameSet(nsIScriptContext* aScriptContext)
>+    nsCOMPtr<nsIPrefBranch> prefs = do_GetService(NS_PREFSERVICE_CONTRACTID);
>+    if (!prefs)
>+        return NS_ERROR_FAILURE;
>+    bool enabled = false;
>+    nsresult rv = prefs->GetBoolPref("security.enablePrivilege.enable_for_tests",
>+                                     &enabled);
>+    if (NS_FAILED(rv) || !enabled)

How about:

  if (!mozilla::Preferences::GetBool("security.enablePrivilege.enable_for_tests"))
    return NS_OK;

r=me with that
Comment 41 Bobby Holley (:bholley) (busy with Stylo) 2012-08-22 17:39:17 PDT
Created attachment 654459 [details] [diff] [review]
Turn on enablePrivilege for JSReftests. v1
Comment 42 Bobby Holley (:bholley) (busy with Stylo) 2012-08-22 21:35:11 PDT
https://tbpl.mozilla.org/?tree=Try&rev=41b695e52362
Comment 43 Bobby Holley (:bholley) (busy with Stylo) 2012-08-23 11:51:47 PDT
This is green modulo the Android M-8 failure. I'm disabling that test in bug 785162.

Pushed to m-i:
http://hg.mozilla.org/integration/mozilla-inbound/rev/c1e3da499d87

If for some reason this breaks tests using enablePrivilege (it shouldn't given the green try run, but still), consider temporarily disabling those tests rather than backing this out, given that it's only the tests breaking, not the feature breaking. Getting rid of enablePrivilege for the web is a huge win (at this point, we only need it for certain legacy tests) that would be great to have on FF17. I'm on PTO from Aug 24-Sept 3, and will look at any fallout when I return.
Comment 44 Ryan VanderMeulen [:RyanVM] 2012-08-23 19:18:09 PDT
https://hg.mozilla.org/mozilla-central/rev/c1e3da499d87
Comment 45 Hans Hokke 2012-09-03 05:12:38 PDT
(In reply to Bobby Holley (:bholley) (on vacation Aug 24 - Sept 3) from comment #43)

> Getting rid of enablePrivilege for the web is a
> huge win (at this point, we only need it for certain legacy tests) that
> would be great to have on FF17. I'm on PTO from Aug 24-Sept 3, and will look
> at any fallout when I return.

A win for who? Google or microsoft? Certainly not for the ff community I would guess. 
I am too late here anyway so I better quit this I think. I needed that functionality and if you can't deliver it I can't use you anymore. Bye. Good luck with your program.
Comment 46 Boris Zbarsky [:bz] 2012-09-03 13:11:07 PDT
> A win for who?

Most firefox users, since it leads to better performance and fewer security problems.
Comment 47 Hans Hokke 2012-09-03 13:19:46 PDT
(In reply to Boris Zbarsky (:bz) from comment #46)
> > A win for who?
> 
> Most firefox users, since it leads to better performance and fewer security
> problems.

Nonsense.
Comment 48 Boris Zbarsky [:bz] 2012-09-03 13:26:22 PDT
Speaking as someone who has had to deal with the security problems caused by enablePrivilege and he performance issues it caused for going on 10 years now, I can assure you it's not nonsense.
Comment 49 Hans Hokke 2012-09-03 14:27:43 PDT
(In reply to Boris Zbarsky (:bz) from comment #48)
Good. Here we go again. 
See the comments in thread https://bugzilla.mozilla.org/show_bug.cgi?id=546848
1. If you remove the engine from a car because it is too slow you are just stupid.
2. If there are performance problems where dependency is not logic, you can also just remove that dependency.
If there are performance problems where dependency is necessary, you just have to accept it. After all, what performance did you improve there when you removed the whole functionality?
3. This will always go on. Security is like a pendulum. 
You open some door because it gives possiblilities to go outside. But it is cold outside so you close it. But if you close it you can't go outside anymore, so after a while you decide to open it again. Sensible people have a lock on the door and unlock it when they want to go out. Unsenible people remove the door and lock themselves in.
Having the road to the outside world open, but guarded and clearly marked by a warning window is a compromise that makes you hope the pendulum will rest for a while. But it won't. Sooner or later it will be rocked again and some dramaqueen will get support. Some dictator or group of overly concerned people will decide they don't want to go out and can't imagine other people would. Or they are just afraid of other people. So they try to close it again.
Usually this goes together with a lot of disdain for the abilities and interests of the people, and usually they are soon overthrown by those people. Because it turns out that even the most paranoid and ruthless dictator can never really control the people. They will “vote with their feet”and just move to other options that do not involve you, or, if they can’t, just stop complying.
 
> Speaking as someone who has had to deal with the security problems caused by
> enablePrivilege and he performance issues it caused for going on 10 years
> now, I can assure you it's not nonsense.

That sounds like a severe case of ptsd. Ever thought of seeking professional help?
I have to disapoint you, but you are not going to stop bad people being bad. You can't even slow them down. In fact there is not a single known security issue that you solve here.
For instance, I had a virus a few times lately that installs in my application data folder and then puts a link in the startup list. No need of enablePrivilege at all. I am lucky it is easy to remove for me and it is not a very destructive virus, but anyway. You didn't stop it and you won't.
Anything you do on the internet is inherently dangerous because you always and ever deal with other people and conflicting interests. That is difficult. Specially for a nerd like me. But the alternative is closing it down entirely. You will see you can not close it down for other people. The only thing you can ever achieve is lock yourself out from mainstream society. 

I know, and everybody else knows, that there are viruses around and that there are all kinds of vulnerabilities on the internet. But I also know that if I go out tonight I can meet a drunk guy driving a car. I do not prohibit roads just to avoid that. I need roads. Otherwise I wouldn’t go out. I know a dictator would, but that is because dictators are scared of people like me. 
I just accept that there are risks in life I can't control.

Of course if I can I will try to convince that man that he shouldn't drive drunk, although I know he just won't listen. Same as I know that you just won't listen, because you just don't get what I am talking about. But I still argue.
Comment 50 Boris Zbarsky [:bz] 2012-09-03 17:10:07 PDT
> 1. If you remove the engine from a car because it is too slow you are just stupid.

And if you make false analogies, then I'm just not sure what they have to do with the discussion.

Nor does the bit about social order or viruses, for that matter.  Can we please stick to the topic, such as it is?
Comment 51 Hans Hokke 2012-09-03 18:18:52 PDT
Viruses are spread via the vulnerabilities addressed here. So that is on topic.
The analogy is that you removed functionality because it "slows things down", without offering a real alternative. So now the particular functionality has come to a standstill. Just like a car without an engine.

Social order is exactly what you are trying to achieve. At least you define the problem as "security issues" you have to deal with for 10 years now. I don't think you mean your own personal security issues here, but the security issues of the whole user community. That is a social order thing by definition.

You are very powerful. Your decisions affect all 400 million users of Firefox. That is comparable to decisions made by the president of the USA. 
You have to be aware of that when you decide on issues concerning Firefox.

Generally speaking there is always the danger that our scope limits to our direct environment and the issues we are addressing right now, and that we lose sight of the immense consequences of what we are doing. 

A programmer may experience it as removing a few lines of code that didn't seem to fit in the logical framework anyway. To people somewhere in Utah or in Europe it may mean months of work building a new UI and million dollar losses and many layoffs because the company cannot access it's accounting data for months. It may even involve rebuilding the entire application because, as it turns out, making a complicated application browser based was not a very good idea at all.
Comment 52 :Gijs Kruitbosch (Gone July 28 - Aug 11) 2012-09-04 00:12:07 PDT
(In reply to Hans Hokke from comment #51)
> The analogy is that you removed functionality ... without offering a real alternative.

This part just isn't true. As outlined by Bobby, Jorge, and Boris in comment 26 through comment 37, there are alternatives to do priviliged stuff. Yes, it will take effort from your part, but there *are* alternatives.

If the comments are not clear enough and you want to describe your usecase and think about a solution, you can email me privately (just remove the "+bugs" from my bugzilla email address) and I'll do my best to give you a hand. You could also pop onto irc.mozilla.org and find folks in the relevant channels about js / add-on development and describe your situation.
Comment 53 Hans Hokke 2012-09-04 01:45:23 PDT
(In reply to Gijs Kruitbosch from comment #52)
> This part just isn't true. As outlined by Bobby, Jorge, and Boris in comment
> 26 through comment 37, there are alternatives to do priviliged stuff. Yes,
> it will take effort from your part, but there *are* alternatives.
If you say so. But I am not a Firefox expert and I just need a way to get that web app going. Is the solution you propose in comment 30 safe for users? Or is it vulnerable to attack?
I appreciate your offer to help and  I may use that at some moment, if I run into problems I really can't solve myself. That may be pretty soon...
Comment 54 :Gijs Kruitbosch (Gone July 28 - Aug 11) 2012-09-04 02:19:41 PDT
(In reply to Hans Hokke from comment #53)
> (In reply to Gijs Kruitbosch from comment #52)
> > This part just isn't true. As outlined by Bobby, Jorge, and Boris in comment
> > 26 through comment 37, there are alternatives to do priviliged stuff. Yes,
> > it will take effort from your part, but there *are* alternatives.
> If you say so. But I am not a Firefox expert and I just need a way to get
> that web app going. Is the solution you propose in comment 30 safe for
> users? Or is it vulnerable to attack?

The solution I proposed involved mapping local files to privileged URLs, using an add-on. That will be safe as they are local files. I don't think you can map remote paths to those kinds of URLs (because indeed, that would be unsafe).

I have no idea what your web app is doing, and this is not the best place to really go into it. But if it's a web app and all you need is cross-domain requests, perhaps using CORS headers on the server side would be the best idea (best of all, that solution could work cross-browser). If you need access to local files or other privileged system access, you would need an add-on that provides such access only to validated sites (probably HTTPS, perhaps with extra checks on the certificates).

> I appreciate your offer to help and  I may use that at some moment, if I run
> into problems I really can't solve myself. That may be pretty soon...

If you want to discuss further, please do reply privately instead of on this bug, which isn't the best place. :-)

Separately, perhaps it would be useful if there was some kind of dev-doc for developers with intranet apps / add-ons etc. that need to migrate.
Comment 55 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2012-09-05 10:28:05 PDT
(In reply to Bobby Holley (:bholley) from comment #3)
> My intention is to turn it off entirely for external consumers. There will
> be a new pref, unpublicized, that we'll set in the mochitest profile. We'll
> call it something scary like "make_everything_insecure" and make big
> comments around it telling people that it's only suitable for testing. If
> someone digs it up and decides to use it, well, too bad.

So I've already heard from one person whose app was broken by this discuss suggesting that users set this pref.

Was there a reason it wasn't called "security.enablePrivilege.make_everything_insecure" like you suggested?  Could you changed it to be named that way so that users at least have a chance of recognizing how bad the advice they're being given is?
Comment 56 Boris Zbarsky [:bz] 2012-09-05 10:32:04 PDT
For that matter, would it make sense to only support that pref #ifdef ENABLE_TESTS ?
Comment 57 Bobby Holley (:bholley) (busy with Stylo) 2012-09-05 12:08:38 PDT
(In reply to Boris Zbarsky (:bz) from comment #56)
> For that matter, would it make sense to only support that pref #ifdef
> ENABLE_TESTS ?

We can't, because we ship builds with ENABLE_TESTS to users.

I filed bug 788653 to rename the pref.
Comment 58 Martijn Wargers [:mwargers] (not working for Mozilla) 2012-09-05 12:52:31 PDT
Ah, cool! I didn't know there was the security.enablePrivilege.enable_for_tests pref. Thanks!
Comment 59 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2012-09-05 13:11:39 PDT
(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #58)
> Ah, cool! I didn't know there was the
> security.enablePrivilege.enable_for_tests pref. Thanks!

Cool in what sense?  I think it's there only so that the uses can be removed over time, not because we want anyone to use it or add new things that depend on it.
Comment 60 Hans Hokke 2012-09-05 16:42:06 PDT
(In reply to David Baron [:dbaron] from comment #59)
> Cool in what sense?  I think it's there only so that the uses can be removed
> over time, not because we want anyone to use it or add new things that
> depend on it.

I am now in the process of converting my unsafe content to an extension and  imust say it is really not difficult to do. I have little experience in web development and it only took me less than a day of study. And a few hours to have my first functions functioning in an extension (in rudimentary form).
Tip for other newbies: start here:
https://developer.mozilla.org/en-US/docs/XUL_School/Getting_Started_with_Firefox_Extensions 
I adjusted the “hello world” example to my needs with no great effort.

I think if it is communicated better that an extension runs in the chrome and, once installed, will run your unsafe content without further warnings, a lot of opposition to removing enablePrivilege will just disappear.
Comment 61 Hans Hokke 2012-09-05 16:47:19 PDT
Sorry,  I missed a line for some reason. After the quote I was planning to write: 

(In reply to David Baron [:dbaron] from comment #59)
> Cool in what sense?  

At least it will buy people time to convert their applications to extensions.
Comment 62 Bobby Holley (:bholley) (busy with Stylo) 2012-09-05 18:20:16 PDT
(In reply to Hans Hokke from comment #61)

> At least it will buy people time to convert their applications to extensions.

Flipping this pref leaves your browser wide open to being hijacked by any website anywhere. It literally grants chrome privileges unconditionally to anyone who asks for them. Flipping the pref on anything connected to the web is suicide. See bug 788653.
Comment 63 Corey 2012-09-06 07:34:41 PDT
(In reply to Bobby Holley (:bholley) from comment #37)
> If you have SpecialPowers installed, you can just do
> SpecialPowers.wrap(Components).classes[...] and everything should just work.
> Or you can feel free to add things to the SpecialPowers API.

Thanks for this information -- I tried SpecialPowers with a locally run tool I've created, and it seems to work fine.  However, SpecialPowers sounds like it's meant for disabling security during testing, which I'd assume opens you up to security risks?  Would you advise against using this as a replacement (interim or otherwise) for enablePrivilege in locally run HTML files?
Comment 64 Bobby Holley (:bholley) (busy with Stylo) 2012-09-06 08:22:41 PDT
(In reply to Corey from comment #63)
> Thanks for this information -- I tried SpecialPowers with a locally run tool
> I've created, and it seems to work fine.  However, SpecialPowers sounds like
> it's meant for disabling security during testing, which I'd assume opens you
> up to security risks?  Would you advise against using this as a replacement
> (interim or otherwise) for enablePrivilege in locally run HTML files?

If SpecialPowers is installed, the SpecialPowers object will be injected into every web page, giving them chrome privileges. Therefore, it should only be used during automation, and never with a build that interacts with the real web. Doing so has the same security characteristics as flipping the pref in comment 62.

For locally-run html files, you can just package them as an extension that exposes them as chrome:// URIs, and everything should Just Work, I'd think.
Comment 65 Martijn Wargers [:mwargers] (not working for Mozilla) 2012-09-07 09:28:57 PDT
If you shouldn't use SpecialPowers for testing, then what should be used?
And why is SpecialPowers preferred in automated as opposed of using the security.enablePrivilege.enable_for_tests pref flipping?
Comment 66 Bobby Holley (:bholley) (busy with Stylo) 2012-09-07 09:45:01 PDT
(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #65)
> If you shouldn't use SpecialPowers for testing, then what should be used?

Define "testing"? If you're testing in a controlled enough situation that you _want_ arbitrary web pages to have system privileges, then you can use SpecialPowers. If you only want those privileges to be available to certain websites, then you should write an extension (or modify the SpecialPowers extension) to fit your needs.

> And why is SpecialPowers preferred in automated as opposed of using the
> security.enablePrivilege.enable_for_tests pref flipping?

Because enablePrivilege is now totally unsupported. I've been altering its semantics all over the place in bug 788914 and bug 789224, and making it work for fewer and fewer cases. This breaks lots of tests that use enablePrivilege, but I've just been responding by ripping enablePrivilege out of those tests. So it's really a moving (or rather, shrinking) target.
Comment 67 Martijn Wargers [:mwargers] (not working for Mozilla) 2012-09-07 09:53:40 PDT
Yes, it is in a controlled environment.
Currently, enablePrivilege works fine for that. Rewriting it to SpecialPowers would be a lot of work.
Comment 68 Bobby Holley (:bholley) (busy with Stylo) 2012-09-07 09:56:08 PDT
(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #67)
> Yes, it is in a controlled environment.
> Currently, enablePrivilege works fine for that. Rewriting it to
> SpecialPowers would be a lot of work.

Ok. Just keep in mind that you'd be gambling that I don't remove the enablePrivilege functionality you're using or break it in some other way. Any code that invokes enablePrivilege is entirely unsupported.
Comment 69 Bobby Holley (:bholley) (busy with Stylo) 2012-09-19 03:44:58 PDT
*** Bug 546848 has been marked as a duplicate of this bug. ***
Comment 70 nikec 2012-10-06 07:53:28 PDT
I do not want to involve in the right-or-wrong discussions about removing the privilege functionality, I just want to share my experience:

Since the last FF upgrade when I try to use my on-line banking, there is a script on the banking page that is denied UniversalXPConnect privileges. Editing prefs.js does not help.

The "write an extension" advice is not applicable for me and I am no programmer in any case. I can only complain to my on-line banking provider, but since they are a small and mainly IE oriented company, the result is extremely unsure.

This renders FF useless for my on-line banking, which in turn (being a Linux users and unable to use IE) forces me to resort to using the old-fashioned method: walking to the bank.

Not exactly happy with this.
Comment 71 Virtual_ManPL [:Virtual] - (ni? me) 2012-10-07 02:44:09 PDT
They're are 2 options in this case:
-change bank
-persuade bank to create not only IE site
Comment 72 Don Kleppinger 2013-06-25 16:09:42 PDT
We have an internal web app for which javascript needs to be able to copy to clipboard.  With the removal of this privilege, that feature no longer works.  How can I make the following code work

function  copyTextToClipboard(copytext){
      
        try{  
        
         if (window.clipboardData) // Internet Explorer
        {  
          window.clipboardData.setData("Text", copytext);
          return;
        }

        // the property must be set in the firefox about:config for this function to work.
        // pref("signed.applets.codebase_principal_support", true); should be set in the eagle-config.cfg file
        netscape.security.PrivilegeManager.enablePrivilege('UniversalXPConnect'); // warns user first time
        var clip = Components.classes['@mozilla.org/widget/clipboard;1'].createInstance(Components.interfaces.nsIClipboard);
        var trans = Components.classes['@mozilla.org/widget/transferable;1'].createInstance(Components.interfaces.nsITransferable);
        var str = Components.classes["@mozilla.org/supports-string;1"].createInstance(Components.interfaces.nsISupportsString);
        str.data=copytext;
        trans.addDataFlavor('text/unicode');
        trans.setTransferData("text/unicode",str,copytext.length*2);
        var clipid=Components.interfaces.nsIClipboard;
        clip.setData(trans,null,clipid.kGlobalClipboard);
        } catch(e){
            alert("This browser does not have permission to copy to the clipboard");
            return;
        }
  
}
Comment 73 Bobby Holley (:bholley) (busy with Stylo) 2013-06-25 16:21:43 PDT
(In reply to Don Kleppinger from comment #72)
> We have an internal web app for which javascript needs to be able to copy to
> clipboard.  With the removal of this privilege, that feature no longer
> works.  How can I make the following code work

You'll need to write a simple addon that does the clipboard munging and exposes the relevant API to your web-app.
Comment 74 Don Kleppinger 2013-06-25 21:48:11 PDT
Do you know of an example?  All I've found you same technique as above.  I found extension but it breaks also in latest firefox.
Comment 75 Bobby Holley (:bholley) (busy with Stylo) 2013-06-26 09:23:35 PDT
(In reply to Don Kleppinger from comment #74)
> Do you know of an example?  All I've found you same technique as above.  I
> found extension but it breaks also in latest firefox.

Such a thing has not yet been written. But if you write it and put it on addons.mozilla.org, I'm sure other people will find it useful as well.

Here's what you need to do, roughly:

1 - Download the Mozilla Addon SDK, and figure out the basic development workflow.

2 - (Optional) Add some basic UI to specify a whitelist of domains to which clipboard functionality should be exposed. You can also hardcode the domain of your intranet app, but that makes it less useful for other people with the same problem.

3 - In main.js, implement the functionality in comment 72.

4 - Apply a page-mod to all matching domains from (2), which defines a copy-paste API and uses postMessage to communicate with the machinery in (3).

This should only take an hour or two for someone who knows what they're doing with the addon SDK, though it will probably take longer for someone unfamiliar with it. You could also hire someone to build it if you prefer - I can try to put you in touch with a freelance addon developer if that interests you.
Comment 76 Don Kleppinger 2013-11-08 08:23:22 PST
I finally got around to making this work in my extension.   I just put the code from comment 72 into the extension minus the PrivilegeManager line (not available)   and then call the function using an event from the page.   Works like a charm (On Firefox 24 ESR)

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