Closed Opened 8 years ago Closed 8 years ago

# Investigate interim solutions for enablePrivilege

Not set
normal

RESOLVED FIXED
mozilla17

## Attachments

### (1 file, 3 obsolete files)

 12.36 KB, patch bzbarsky : review+ Details | Diff | Splinter Review
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.
https://tbpl.mozilla.org/?tree=Try&rev=7ef083f465f8
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.
(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.
> 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.
(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.
> 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...
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.
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.
Attached patch Proof-of-concept. v1 (obsolete) — Splinter Review
Attaching proof-of-concept. This turns the tree orange, but not impossibly so.
Assignee: nobody → wchen
Did an updated push with wchen's changes:

https://tbpl.mozilla.org/?tree=Try&rev=19592932cb80
Blocks: 762314
Depends on: 762528
Depends on: 762908
Assignee: wchen → bobbyholley+bmo
Depends on: 695292
I've fixed a bunch more tests for this. Repushing to try:

https://tbpl.mozilla.org/?tree=Try&rev=bfd6272b10f7
more: https://tbpl.mozilla.org/?tree=Try&rev=9894827c9486
Can someone give me a summary to post to the EWG? Should I just say enablePrivilege is going away?
(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).
(Also, recommend that privileged code move into an extension)
Doing another try push now that some of the dependent code has stabilized:

https://tbpl.mozilla.org/?tree=Try&rev=c9d74be1f097
Alright! This is starting to look greener than ever. :-)
Attached patch PoC. v2 (obsolete) — Splinter Review
Attachment #629785 - Attachment is obsolete: true
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
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!
For reference, my github branch (equivalent to what I just pushed to try) is here:

https://github.com/bholley/mozilla-central/commits/interimprivs
Turned my PoC into a real patch.
Attachment #634458 - Attachment is obsolete: true
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
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?
Depends on: 778420
What is the alternative for enablePrivilege?
(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #25)
> What is the alternative for enablePrivilege?

SpecialPowers.
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?
(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.
Is there another way to get chrome privileges for local files?
(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).
>> 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.
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.
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.
It doesn't seem that I can do the same with SpecialPowers as with enablePrivilege, can I?
(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?
Doing random privileged stuff in local files.
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.
Depends on: 783031
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/
Attachment #638024 - Flags: review?(bzbarsky)
Green last I checked, but doing an updated macosx-only run to be sure: https://tbpl.mozilla.org/?tree=Try&rev=f21b9bd12250
Depends on: 784560
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)

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

r=me with that
Attachment #638024 - Flags: review?(bzbarsky) → review+
Depends on: 784857
Attachment #654459 - Flags: review?(continuation)
Attachment #654459 - Attachment is obsolete: true
Attachment #654459 - Flags: review?(continuation)
https://tbpl.mozilla.org/?tree=Try&rev=41b695e52362
Depends on: 785162
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.
https://hg.mozilla.org/mozilla-central/rev/c1e3da499d87
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
Depends on: 786249
Depends on: 786852
No longer depends on: 786249
(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.
> A win for who?

Most firefox users, since it leads to better performance and fewer security problems.
(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.
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.
(In reply to Boris Zbarsky (:bz) from comment #48)
Good. Here we go again.
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.
> 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?
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.
(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.
(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...
(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.
(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?
For that matter, would it make sense to only support that pref #ifdef ENABLE_TESTS ?
(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.
Ah, cool! I didn't know there was the security.enablePrivilege.enable_for_tests pref. Thanks!
Keywords: dev-doc-needed
(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.
(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.
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.
(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.
(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?
(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.
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?
(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.
Yes, it is in a controlled environment.
Currently, enablePrivilege works fine for that. Rewriting it to SpecialPowers would be a lot of work.
(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.
Keywords: relnote
Flags: sec-review?
Duplicate of this bug: 546848
Flags: sec-review? → sec-review?(dveditz)
Depends on: 791526
Blocks: 797443
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.
They're are 2 options in this case:
-change bank
-persuade bank to create not only IE site
Depends on: 817523
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.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;
}

}
(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.
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.
(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.
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)
Flags: sec-review?(dveditz)
You need to log in before you can comment on or make changes to this bug.