Closed Bug 546848 Opened 14 years ago Closed 12 years ago

Remove support for enablePrivilege

Categories

(Core :: Security, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 757046
Tracking Status
blocking2.0 --- -

People

(Reporter: jruderman, Unassigned)

References

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

Details

(Keywords: relnote, sec-want, Whiteboard: [sg:want]See comment 57 regarding why we are doing this.)

Attachments

(1 file)

enablePrivilege has had security holes, complicates our entire JavaScript security model, and seems to be barely used by web sites.  Let's remove it.

Firefox extensions are more popular, more sane, and have reasonable UI.

The only counterargument I've heard is "some intranet sites might use it".  I don't think that's enough reason to keep it.
Depends on: 523896
> Firefox extensions are more popular, more sane, and have reasonable UI.

Unfortunately, for a lot of the enablePrivilege users I've seen they are not in fact more sane as things stand.  As in, they make it much harder to not introduce holes into the browser in the course of giving a particular site extra privileges.

Bug 523896 may address that, though.
Depends on: 546866
The js tests use it to enable twiddling of preferences. That will need to be reworked or the tests disabled in the browser.
No longer depends on: 523896
Arghh... I really, really hope this doesn't get discarded... If you want to write bona fide web applications that work cross-browser, in the here-and-now, and compete with other client-side apps, this is the only way to do it. No browser restart needed as with an extension, no browser-specific coding (outside of the privilege escalation code which I wish would be standardized). I use this for a Mac-style column browser which allows browsing the desktop in IE and Firefox, and I'd hope to see more such support rather than less... :(  With the exception of databases, HTML5 only competes with other client-side apps if you're content to store stuff in the cloud rather than have control over your own data by storing it in and being able to work with local files. Please don't get rid of this! If anything, make it easier for sites to do without forking over money for code signing certificates...
Brett, can you give an example of something that's easier to do cross-browser due to enablePrivilege?  As far as I know, no other browser has something like it.  So what are you doing in the other browsers?
Sure... As an example, at http://svn2.assembla.com/svn/brettz9/colbrowser/ I have some code for a Mac OSX-style column browser (a way to browse local files and directories in their desktop "Finder"). Besides browsing through one's file hierarchy (or also the hierarchy of any XML file), it allows previewing of images, videos, text files, HTML, etc. on one's desktop (and could conceivably be altered to allow the likes of CodeMirror syntax highlighting and editing of local files, turning HTML/CSS/JS into a real IDE without the need for what seems to be the much slower (at least for small to moderately large files) Bespin.

Besides Mozilla-specific code to view a user's file system, my code can also use Explorer's ActiveX features to do the same in IE. Apparently some of the historical security risks have been mitigated now with ActiveX (see http://en.wikipedia.org/wiki/ActiveX#History ), even if some companies (I guess more the IE6-based ones) won't allow their use.

I'm not keen (nor is there a choice) on using browser-specific code which is still necessary in parts here, but at least it can be delivered over the web and run in different browsers (again, I'd love to see standardization so web apps really become full-blown apps). There are hurdles here, and this may explain their present lack of popularity/familiarity, though I really think this may be like another humble, previously under-appreciated and not-widely-familiar ActiveX feature, called XMLHttpRequest... Especially if a site like Mozilla could be persuaded to review such code, it would overcome both the trust hurdle, as well as the signing certificate issue (since it is only $40/year for such signing certificates and even penny-pinching developers wouldn't mind hosting it elsewhere if it could be accessed by their users).

If conditions were right, I think we could see as much innovation at the level of the desktop (via the browser) as we do on the web. There are still files on one's local system to browse, files to read, etc. Not having a standard nor wide documentation probably doesn't help.

If I can make a popular-culture analogy, the client-server barrier, while of course of great concern, is to me like how the god-like comic book character called "The Beyonder" was able to reveal to another already powerful character, "Molecule Man" that his ability to manipulate molecules was not limited to inorganic molecules. While it is of course dangerous to manipulate organic matter (i.e., the user's desktop), it is also a very powerful opportunity when used in a responsible environment, such as how signed scripts allow.... :)

Thank you...
Oh, and you can see some of the ActiveX code alongside the Mozilla code at http://svn2.assembla.com/svn/brettz9/colbrowser/dirGen.js specifically....
I would also add that we use enablePrivilege() to allow:

1. Cross-origin XHR calls
2. Calls to 1 or 2 XPCOM services, such as mozStorage
3. Saving to the file system.

all from 'web content' (served in an intranet, so security permissions are enabled specifically for our web app on a limited basis by the sys admins).

We've been using this mechanism for years and years and have apps in production that rely upon it.

Are there proposals on the table as to how similar functionality will be provided once enablePrivilege() goes away?
The replacement for when enablePrivilege is going away is to write an addon which supplies the functionality you need.
(sorry for spam)

Forgot to add that we'll provide good hooks and documentation for how to do this.
Ok, while I'm not crazy about this, that's not a horrificly bad answer.

Excuse my lack of knowledge re: addons and their capability here, but if I wanted to limit the amount of code that the add-on has to just a set of 'services' (i.e. read/write the filesystem, talk to mozStorage, make cross-origin XHR calls), is there a way then to 'pass back and forth' data into a regular page (where the regular page is just 'calling upon' a set of well-known services embedded in the add-on) can I do that? I'm thinking something along the lines of HTML5's 'postMessage' capability.

Thoughts anyone?
Yes, you'll be able to expose pretty much any functionality you want to any pages you want. You won't even need to use cumbersome postMessage methods, but simply syntax like

myExtension.setMozStorageValue(...);
file = myExtension.openFile(...);
Coincidentally, I just started some new work for a very large client, and their main system relies on this feature. Our developers would have to use IE in order to work with it, even though it is working just fine in Firefox.
Here's my main use case:

Allow transparent client-side mash-ups which can display:
1) data from one site in one column (e.g., paragraphs from a book)
2) data from a local (XML) database in another column (e.g., one's private notes about the book), and 
3) data from another third-party remote site in another column (e.g., a collaborative wiki site with separate pages for each paragraph of that book).

I'm developing my own extension API for accessing a local (native XML) database (though it would be great if Mozilla would implement!), so that part should be covered.

However, in order to display data from a third-party site in a flexible manner, such as a wiki which links to yet other sites, what I'd really like to see is an iframe with its own independent navigation controls so that the user can find resources pertaining to a particular paragraph without needing to leave the context of the larger document.  Having such an iframe depends on the parent framing document having privileges to be able to intercept events from the child iframe.

I've implemented this previously with enablePrivilege() at http://gist.github.com/321851 and made my own simple XBL at http://gist.github.com/326473 to wrap this into its own reusable element, and it worked fine. If enablePrivilege() is thrown out and not replaced by something which websites can access, my only thought is to make a special API available to websites from an extension which allows sites to make GET requests from external sites regardless of explicit cross-domain access to the remote site in question but dependent upon explicit user permission and a per-site basis (per originating site and even per target site).

However, this would be less ideal than some kind of iframe, even if my workaround can be made to work against problems with base URLs, etc. Might a new frame element (or an extra attribute on iframe) be created which offers this independent navigation functionality without even needing such permissions (or at least allowing extension code to conditionally override iframe privileges)? I believe this can be very useful for sites which foster editing, esp. collaborative editing. With more sites such as governments sharing their data, it would be nice to be able to give the user/client control of adding their own information pertaining to such data, whether locally, or at a remote editable site, without needing explicit permission from the data source site.  

Server-side mash-ups do not make this process transparent, thus bringing into question the reliability or freshness of the data as well as failing to offer the advantages that transparent delivery of JavaScript has offered for learning techniques of others' code. Also with the burden for loading the sites shifted to the user, sites may be more willing to experiment with mash-ups.

I would really appreciate some feedback on this, as this has been a very long-term plan, and even a main motivation for me getting into Firefox development. Thank you... I can file a new bug if necessary...
(In reply to comment #0)
> enablePrivilege has had security holes, complicates our entire JavaScript
> security model, and seems to be barely used by web sites.  Let's remove it.

It also makes us slow, and removing it would actually fix some security bugs.

Removing it will take me 2-3 weeks of test cleanup, I'm guessing.
Assignee: nobody → sayrer
Sicking, if you still have it, could you attach the add-on you told me about?
sayrer, the components/ directory of this extension shows the technique of observing content-document-global-created and injecting functions.

https://www.squarefree.com/extensions/domFuzzLite.xpi
A question on timing here.  While I'm not about to argue for keeping enablePrivilege, one of the primary reasons for removing it is that it will not work by design on electrolysis.  So, that in my mind makes this a post gecko 2.0 project (firefox 5 or what have you).  

Are we intending to try to move ahead with this for Firefox 4/Gecko 2.0?

I had some folks lined up to help with this a month or two ago, but when it looked more like a post 2.0 project, they focused on more pressing things.  If we decide to take it now, I might be able to juggle some priorities and get you some help with the test cleanup effort.
(In reply to comment #17)
> A question on timing here.  While I'm not about to argue for keeping
> enablePrivilege, one of the primary reasons for removing it is that it will not
> work by design on electrolysis.  So, that in my mind makes this a post gecko
> 2.0 project (firefox 5 or what have you).  
> 
> Are we intending to try to move ahead with this for Firefox 4/Gecko 2.0?

It turns out that it is slowing down JM. See

https://wiki.mozilla.org/JSStackFrame_Evisceration

My plan is to get an extension rolled into mochitest that will provide the functions people need. After I've done that, help altering enable privilege users would be great.
Blocks: 557378
Actually we had plans to remove .enablePrivilege for security reasons long before e10s was in the picture. And I really don't think .enablePrivilege is directly related to e10s: it still works in e10s content processes, kinda, although the environment you get back is different.
Yeah I've known about the security issues for a while.  Well, as I said, I'm all for removing it, and if removing it sooner makes us faster, I'm doubly for it!

Thanks for the clarification.  Let me know how/when we can help.
(In reply to comment #18)
> My plan is to get an extension rolled into mochitest that will provide the
> functions people need. After I've done that, help altering enable privilege
> users would be great.

Freudian slip with "altering" instead of "alerting" there ;-).

Clint, this is the rub: we can't necessarily alter or alert developers (who may no longer be around even if their code is). We need to build up our rapport and communication with any active ones though. If there's a hot add-on or app that thinks it must have enablePrivilege, and a placebo won't suffice, then we may need to do some work to help that software cope with removal.

We need to make a coherent effort here, not just break things and say "haha, you lose" (not saying Sayre was doing that; it has happened even without the "haha", it comes off that way sometimes). Hope you can help.

/be
(In reply to comment #21)
> we may need to do some work to help that software cope with removal.

My plan is to create a demonstration extension that inserts functions into content just like Jesse's does, and our mochitest extension will. The extension installation experience is strictly better: no flipping of a pref in about:config, and no in-content (!!!) dialog asking for permission to do anything.

Even with such documentation available, there will still be code that is tedious to rewrite as an extension (I don't think anything will be impossible). That is something we should live with, because the core features of enablePrivilege are what cause security and performance problems. Those problems affect all of our users, so enablePrivilege and anything resembling it have to go.
sayrer, you are overselling. I'm first to get rid of enablePrivilege (if we do not make it a no-op) and remove the annotation member of JSStackFrame. Yeesh.

My point in comment 21 was about interaction with developers and coverage of popular code our reputation hangs on, even if we didn't write it. We can't fix everything, but not trying ensures we'll do no better than get lucky.

/be
I'm going to second Brendan's comments here.

Since we use a Web browser as a "OS independent client-side application virtual machine", our usage pattern dictates the usage of enablePrivilege() on occasion (file system access, cross-origin XHR, etc).

My expectation is that there would be a minimum 1 year lead time between the "announcement" of removal of this feature and actual shipping in a new version of Gecko.

Cheers,

- Bill
This was publicly proposed Oct 31 2008, on mozilla.dev.platform and there was significant discussion at the time:

http://groups.google.com/group/mozilla.dev.platform/browse_frm/thread/cbf02410bbfb2ece/fde60efc513cdf7b?lnk=gst&q=enablePrivilege#fde60efc513cdf7b

The solutions presented have for the most part been implemented (it is now possible for addons to easily insert a privileged object into the DOM which exposes "unsafe" activities to trusted web pages.
Better yet, why not try to standardize this in HTML5, if not for JavaScript as a whole, then for an API to provide as many specific actions as possible with user permission--if not for file system access (which would be great to preserve as I still don't know why we can't make a standard file-browsing interface over the web), then for those web features I assume will be already within or closer to the potential competence of the other browsers in the market (e.g., cross-domain access).
Here's a few panels of the comic strip I was referring to (though my mistake--it was Doom who bestowed the powers on Molecule Man, after obtaining the powers from the Beyonder)--a storyline which I think holds parallels for giving the power of "organic matter manipulation" (i.e. privileged access) to websites upon user permission: http://forums.marveldatabase.com/download/file.php?id=33 . (Of course, both Doom and Molecule Man had been or were criminals, but...). Hope you don't mind the "spam"...
Molecule Man, Molecule Man
Doing the things a molecule can
What's he like? It's not important
Molecule Man

Is he secure, or is he a hole?
When he prompts users do they understand?
Or do they just get pwn3d instead?
Gutmann[1] knows, Molecule Man.

[1] http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf
I <3 TMBG and Dolske!

Brett, do read Peter Gutmann and turn away from the path of evil. With great power comes great responsibility, but absolute power corrupts absolutely, and even a little is way too easily abused. Also, I suggest you read Mark Waid's "Irreedemable" and put down the Jim Shooter era Marvel :-/.

/be
(In reply to comment #28)
> Molecule Man, Molecule Man
> Doing the things a molecule can

Variant on Godwin's Law: as a geeky discussion grows longer, the odds of someone paraphrasing "Particle Man" approaches 1.
Will this be done for Firefox 4, or later release?

Some critical features of Lotus iNotes depend on signed script and it is
important for us to know when enablePrivilege will be removed, for our
future product planning.

Thanks.
I haven't been paying attention here, but we'd need to know pretty much RFN if this is going to be removed for FF 4.0.

I assume that since its not been tagged as a blocker that it will not be 'fixed' for 4.0, but can someone with Mozillian confirm or deny?

Cheers,

- Bill
I meant "Mozillian authority" :-)

Cheers,

- Bill
This is a very good question.

Word on the street is that we're trying to remove it for Firefox 4 still, however it seems to me that we're a little too close for that to actually happen.

Sayre: Are there any specific reasons (other than the usual "it's a very unsafe feature") we want to do this? I seem to recall JS-perf or JS-implementation-sanity being mentioned as reasons, but my memory is very hazy.
(In reply to comment #32)
> I haven't been paying attention here, but we'd need to know pretty much RFN if
> this is going to be removed for FF 4.0.

Assume it will be removed.


(In reply to comment #34)
> 
> Sayre: Are there any specific reasons (other than the usual "it's a very unsafe
> feature") we want to do this?

Reason enough. We suck for not removing it earlier. There were JS perf reasons, but we found a way to work around them.
<snarky>gee - thanks for the advance notice</snarky>.

This means a minimum of a man-month of rework and testing to be performed by a very small team. Sigh...

In any case, does anyone have good pointers to example code / websites that would show how to replace said functionality? (An extension that we must now package with our code or whatever...)

Cheers,

- Bill
(In reply to comment #26)
> ... I still don't know why we can't make a standard file-browsing
> interface over the web ...

The internet is a hostile place. Please believe us--and every other browser vendor--when we say that we do not know a way to offer that functionality safely without also likely giving that access to Nigerian, Russian, and Chinese hackers.
blocking2.0: --- → ?
Hi,

I meant to reply earlier, also appreciating if not agreeing with the humor, but I realized I was not getting around to the extended blog post that I felt this discussion deserves.

(Non-bug aside: @Brendan: I love the Jim Shooter era of Marvel (esp. the X-Men); Marvel imo seemed to go downhill after that, perhaps not unrelated to the dropping of the Comics Code which Shooter favored; even Alan Moore lamented the like ( http://www.wired.com/entertainment/hollywood/magazine/17-03/ff_moore_qa ))

@Daniel: As far as the (perhaps inadvertently unqualified) reference to Chinese, etc., hackers, please consider that there are developers in these countries whose respect for moral standards is far higher than many American developers (one of my Chinese employees hoped I would have all our employees pledge not to violate intellectual property in their private lives) and its violators in these countries in no way represent the whole, even if there may be government complicity and/or lack of enforcement in some cases.

But if your point is that a big proportion of security challenges may result from the latter, then at some point, the issue ought to be addressed at an institutional level, rather than the very questionable technical level. If certain countries are lax in protecting, or active in violating certain laws, in my view, there ought to be real consequences, starting with the worst offenders, including even restricting their access to the network (or other carrot and stick options). We have international monitors for atomic weapons--why not for internet security enforcement?  In this analogy, you are asking to eliminate use of nuclear technology for any purpose whatsoever, just because the technology can be abused (and in that analogy, the consequences are far more serious).

@Justin, @Brendan, @Daniel, etc: I'm well aware that the internet is a hostile place, and that it is not so difficult to deceive people (as well shown in the Gutmann article). But I'm also aware that the highway is a hostile place, and I'm not advocating tearing down roads, even if it means people die from their continued existence, as I recognize there are costs and benefits to be weighed by a society. Similarly, I'm not in favor of dismantling the postal office or telephones, because their existence enables more people to get scammed.

Indeed, with great power comes great responsibility, and I'm glad you all are seeking to honor that, but with great power also comes great opportunities which a responsible society ought not seek to unduly curb, and at the very least should not precipitously seal off discussion and consideration as though it is such a simple cut-and-dried issue needing no further consideration or debate.

If tomorrow, there were a cheap way to spread code over the internet for immediate use in a brain plug-in which allowed people to learn foreign languages, automate motor movements, and yes, potentially take over the brain, even this, I for one would not reject out of hand, and I'm frankly surprised that there is this strong group-think, even among brilliant technologists as yourselves and among citizens from a country whose intellectuals are not known for neo-Luddite conservatism, to make such a blanket decision about something of lighter, if still potentially grave, consequences. This seems to me to be something requiring a wider debate rather than just a seal of "We know what's best for you.".

I'm even more surprised that it seems to escape people here that Firefox can with two clicks by the user (in installing an extension)--and with no sarcasm, I thank you for your hard work in making such power possible to extension authors given all its benefits--do everything from wipe out your hard-drive to turn your machine into a spam bot. Shall we get rid of extensions too, and limit them to lame superficial tweaks? Or should we try to become an even bigger nanny, contravening all of your historical openness, and not allow extension installation (whether from remote or on your local machine) unless from the AMO site?

Unless you favor the option of getting rid of extensions (GLWT), with such inconsistency you're basically saying it's ok to make an extension which uses proprietary features of Mozilla, yet it is not ok to be able to access the same functionality in a cross-browser-supporting way (albeit an admittedly and regrettably non-standard way). Seriously, can anyone address what makes this the slightest bit different (in a harmful way) from extension installation? Could you not apply the same Gutmann 'Make this dialog go away' meme to the Firefox add-on warning?

This is not to mention HTML5 currently supporting sharing of your geo-coordinates in asking permission, which probably could have more dangerous consequences for some people than the average hack attack.

I'm all in favor for considering the consequences of technical power, but I find it odd that while our society seems to have no problem pushing forward in frightening technology like military drones, that we're so skittish about giving some power to an internet user (which has been around already for some time too) by their own explicit permission... If you were backing this up at least with statistics stating that this attack vector is responsible for 90% of compromised systems over the web, etc., then this would at least seem to me to be a rationale discussion, but as it is now, it seems arbitrary, not to mention oblivious to all of the unimagined positive power that could be achieved and dogmatic in rejecting cost-benefit analysis. Do you really want to be the people who may be seen as alarmists standing in the way of the cross-browser desktop revolution? Sorry for the drama, but I don't think this would be beyond implausibility.
We don't have the resources to make this block, AFAICT, and we have a workaround in JM. We should fix this ASAP, though.
blocking2.0: ? → -
So won't this be removed for Firefox 4.0?
Need clear and definite information whether it will removed or not...
IMHO we need to focus on other blockers and leave this one for the next release.

We are however making good progress on implementing the replacement, so I'd say that there is very little reason to believe that this will remain in the release after Firefox 4, which might happen as early as the first half of 2011.
Thank you for the info.

Then can you please explain what happens exactly when this is fixed?

This is important to implement fallback - I'm expecting that exception occurs when enablePrivilege is called in signed script (similar to when user clicks "Deny" on the security alert produced by enablePrivilege) so our product can fallback not to use signed script.

Thanks.
Note that my comment should not be taken as an official decision. It's just my opinion.

The bug is assigned to Robert Sayre so at least he needs to have a say as well.
Yes, I understand it is not official, so I'd like to know how this is fixed.

Sayre: Can you please my question above? (Comment 42)
I would really appreciate an explanation from someone about why, from a security standpoint, it is ok to have non-AMO add-on installation available on the web, but not cross-browser-friendly (if non-standard) enablePrivilege? I can understand the argument about speed, but it seems that security cannot even be used as an argument while non-AMO add-on installation exists (unless the add-on requirement of HTTPS is somehow significant and not possible for enablePrivilege).

And if we in the community are to overcome this by building extensions which use "content-document-global-created notification" ( https://developer.mozilla.org/en/Observer_Notifications ) or custom DOM events https://developer.mozilla.org/en/Code_snippets/Interaction_between_privileged_and_non-privileged_pages to allow websites to communicate with privileged code, would AMO at least be open to accepting and perhaps even standardizing on a generic extension which could allow sites to ask permission of the user for specific privileges?

It would certainly be more convenient for enterprise and other developers to avoid the need to develop their own extensions and APIs and just rely on a standard or pseudo-standard. While I haven't looked carefully at them, maybe even the Jetpack APIs could simply be wrapped, encouraging reuse of such a "standard" for any kind of privileged development (incidentally, I would think the Jetpack API itself could either be standardized on or at least made into an adapter class for use in other browsers' extension systems, so it is not only unprivileged HTML5 which benefits from standardization).

If you want people to be reared in an environment where a single flavor of HTML5 can be used anywhere, including enterprise, and where developers are rewarded who know standards they can use (thus facilitating standards-based developers finding work and encouraging wider study and adoption of standards), and for the increasingly important but also increasingly fragmenting add-on development process, you have to give some way that the community can at least make its own standard for use across these environments. If a standard is beneficial on the web, why not outside of it?

I'd prefer no need for an add-on, but how about at least allowing us this add-on concept which could be distributed at AMO if not also with an API overseen by Mozilla or possibly others? If Mozilla is not interested in this, I'd at least like to try to the extent I can find time, as long as I wouldn't be told that we can't offer this extension as it could possibly be abused.

At least this separation into an add-on would speed up JavaScript, and provide one additional step needed for duping anyone (though again, there is always the option of non-AMO extensions for abusers which don't even need subsequent HTML interaction).
Did something go by here unmentioned?  There's a complaint in mozilla.dev.extensions of XPCOM errors when trying to use enablePrivilege in what is presumably 5 beta. <http://groups.google.com/group/mozilla.dev.extensions/browse_thread/thread/305e271667170863#>
Yep - noticing it here too in 5 beta... has the long-dreaded change taken effect?
No, this bug is still open and we have not removed enablePrivilege. Whatever that problem is, it's something else.
Depends on: 651012
Depends on: 668030
I am just a user. I found a site with a really annoying scroll, that depended on javascript.  I wanted to disable js- on just that one site, forever- without installing NoScript, which broke too many sites.
There IS a way to do this.  
http://www.mozilla.org/projects/security/components/ConfigPolicy.html

   user_pref("capability.policy.policynames", "nojs");
   user_pref("capability.policy.nojs.sites", "http://site1.com http://site2.com");
   user_pref("capability.policy.nojs.javascript.enabled", "noAccess");

HOWEVER, this pref is not visible in about:config  (So I'm told)
and creates this problem, documented at
https://bugzilla.mozilla.org/show_bug.cgi?id=284673  :

QUOTE
> I can't really think of any common use case for changing these prefs using the
> UI, and there are none listed here. That makes me think we should leave things
> as they are and not take this patch.

As it has been already written in the bug report, the preferences _can_ be changed using the about:config UI, but are not _displayed_. The typical user interaction looks like this:

* User sets a capability.policy preference.
* It appears not to work. Users sets more preferences, trying to figure out what is wrong.
* It appears not to work, again. User gives up, unaware (yet) that JavaScript is now partially broken in a weird and mysterious way.

(And even if the user figures where the breakage comes from, there is now no obvious way to reset the preferences to a usable state.)
ENDQUOTE

The solution to THIS is to edit config.js so the changes are visible in about:config. = Removing the following lines:

  if (/^capability\./.test(prefName)) // avoid displaying "private" preferences
      return;

    if (/^capability\./.test(prefName)) // avoid displaying "private" preferences
      continue;

also at https://bugzilla.mozilla.org/show_bug.cgi?id=284673


I am only an egg.  I can't evaluate half the discussion above.
However, it seems to me that part of the answer is to edit config.js as above (by default/in the mainstream Firefox release), so the changes that half-knowlegeable people (like me) might make to prefs.js are always visible.  
Hope this helps add some light, not heat, to the discussion.
Thanks for all you do.
What is the current plan for fixing this bug?  It is still marked new and FF8 is out already.  Thanks!
It's in progress. If you look at the dependency tree for this bug:
https://bugzilla.mozilla.org/showdependencytree.cgi?id=546848&hide_resolved=0

You can see that lots of work has been going on, but it's a large project.
Depends on: 674917
Depends on: 717647
The documentation at http://www.mozilla.org/projects/security/components/signed-scripts.html should be edited to make it very clear that this feature will be removed.
Depends on: 750859
Whiteboard: [sg:want]
(In reply to Brett Zamir from comment #45)
> I would really appreciate an explanation from someone about why, from a
> security standpoint, it is ok to have non-AMO add-on installation available
> on the web, but not cross-browser-friendly (if non-standard)
> enablePrivilege? I can understand the argument about speed, but it seems
> that security cannot even be used as an argument while non-AMO add-on
> installation exists (unless the add-on requirement of HTTPS is somehow
> significant and not possible for enablePrivilege).

I would love to keep all of Brett Zamirs remarks as quotes just to make you read them again. 

What exactly is the problem you want to solve by removing support for enablePrivilege?
Surely not security. In an extension you can make and install even better and more effective viruses than in a external binary call. The mob can write extensions too. Imagine the ways you can phish if you can get somebody to install your extension.
Usability? Usability of Firefox will be seriously diminished by removing it. For instance all the functionality introduced by js-ctypes will be discarded in 1 blow. Not very smart to put so much effort into creating that and then blocking the possibility to use it. 
Ease of use? The first user who thinks it will be easier to install an extension than to just click ok when asked is yet to be born. 
Performance? If there are performance issues with it that influence code that does not use it you should review the engine. If there is a performance issue with code that does use it, shouldn’t we do better just to optimize it and maybe accept some discomfort? After all, a slow car is better than no car at all. If running the code would lead to performance of 80% (or 40%) of what is desired, removing the option will bring performance back to 0%. Hardly an improvement I would say. 
Cleanliness? If it becomes a custom to create extensions for every functionality of every website your extension list will get very long. People will forget what extensions they installed and where and why they installed them. Needless to say that is a recipe for security disaster.
Modernity? enablePrivilege would fit in ms’s metro style app concept. Surely you don’t want to block the way to that would you?

I am now creating a utility that I want to make available on a website using js-ctypes. It is a gimmick for a certain rather limited (and probably quite technical) user group. I explicitly do not want to have them install it as an extension, simply because I think it is unethical to lure people into sacrificing resources and performance to use some functionality maybe only once.
Extensions are practical for regular use, preferably on many sites. Not for obscure single custom appliances. Let's be sensible and not burry people in our garbage.

Removing enablePrivilege? Not smart! Don’t do it!
Unless you have something that works better of course. 

I have followed the link in comment 28 and read what mr. Gutmann has to say with interest. 
But I have to conclude that not one of the issues he identifies would be solved by removing enablePrivilege. On the contrary. Installing an extension means installing an invisible security risk for all use of firefox in the future, without additional warnings.
Security on the internet eventually always comes down on trust. The individual user has to decide here and now if the person presenting the website to her is trustworthy. 
Certificates, keys etc. only move the problem from the maker of the site to the CA. But who is that CA? I never drink coffee with a CA. The mob can have it’s own CA that looks very convincing. The mob can also easily set up a https connection. Every technical solution to create security will always come down to one final problem: Do I trust the supplier of what is offered to me right now?

enablePrivilege is  a very good help in this, because when it pops up the user can know that she needs to take some care and needs to decide on the trustworthiness of the site owner. 
An extension can never provide the same amount of security because, just as mr Gutmann says, the extension can be installed from a site about knitting patterns, but be in use when you do your bank business, regardless if you are using https. 

So:
DO NOT REMOVE enablePrivilege.
If you want total security why not just remove all features. No browser no problem.

Backwards compatibility is one of the greatest promises in software. Users want software that worked yesterday to still work today irrespective of system updates. However, you have chosen to ignore that and remove enablePrivilege from javascript thereby breaking numerous existing applications. 

It seems that enablePrivilege has been removed in Firefox 15. I am getting the following error, which I don't get in Firefox 14, and which breaks the application completely:-

A script from "file://" was denied UniversalXPConnect privileges.

Great, many thanks.
(In reply to John Middlemas from comment #54)
> If you want total security why not just remove all features. No browser no
> problem.
> 
(...)
> 
> It seems that enablePrivilege has been removed in Firefox 15. I am getting
> the following error, which I don't get in Firefox 14, and which breaks the
> application completely:-
> 
> A script from "file://" was denied UniversalXPConnect privileges.
> 
> Great, many thanks.

It's just my luck I suppose. Only last week I had a very promising test result with my little program. And now it just stopped working at all. 
I bet this move is perfectly logical if you know the code of Firefox. It only looks endlessly stupid from a user point of view. But users are a nuisance anyway
Anyway I still have time to rearrange everything and explain people they can't use it in Firefox. "Firefox is deficient, so you have to use MSIE now." I hope they will believe me.

I know you are all volunteers and need to be appreciated for all the work you do on Firefox. But I would much rather have seen nobody volunteer for this part. 

As I mentioned earlier:
You can now throw away js-ctypes entirely, since starting in version 15 it is inaccessible anyway. That will probably be the case for a host of other features and utilities too.
Removing enablePrivilege now causes signed scripts to fail.
The example of a signed script in the Mozilla documentation on page http://www.mozilla.org/projects/security/components/signed-script-example.html will not run anymore.
If you follow the link to it ( jar:http://www.mozilla.org/projects/security/components/signed-script-demo.jar!/signed-script-demo.html ), you get an error, but the page does not open at all.
Is this what you meant to do?
Did any of you guys really think this through? Or did you just assume someone else would?
We are very aware that this causes problem for people. It's not a decision we are taking lightly. There are several reasons we are doing it anyway:

1. The way enablePrivilege works is just not safe for users. The fact that the
   only thing protecting a user from having arbitrary privileged code is a plain
   popup. This popup is displayed with little help giving the user basically no
   chance to make an informed decision.
2. Implementation-wise enablePrivilege has always been very quirky. It only
   enables privileges during a given callstack which is very contrary to how the
   rest of javascript works. It has forced us to have a lot of complexity in our
   implementation which at best caused bad performance, but also has has caused
   lots of security bugs.
3. It stood no chance of getting standardized and working cross browser. Other
   browsers were simply not interested in implementing it. At mozilla our goal
   is to push a standardized web as the platform. Browser specific APIs is no
   better when they are Firefox-only than when they are IE-only.
4. Because we, compared to our competitors, are operating on a pretty limited
   budget, we simply can't afford to keep around any feature just because there
   is someone out there using it. Despite what you might think, enablePrivilege
   isn't used that much out there. Especially in comparison to other mechanisms
   that extend the capabilities of the browser, like addons. We have been
   investing in making these mechanisms more capable with the explicit goal of
   making it possible write addons which replace the use of enablePrivilege. For
   example much of the recent wrapper work makes it much easier and safer to
   write an addon which inject APIs in selected pages.


We are very aware that enablePrivilege is used and that removing support for it is a hassle for many of you. We are not taking it lightly which is why we have chosen to invest in making addons more capable and give lots of headsup to allow people to transition to them.

It's simply too costly for us to keep supporting enablePrivilege, even when considering the additional investments that we've had to do in addons to allow people to transition off of enablePrivilege and onto using addons.

We realize that rewriting your signed jar as an addon isn't easy. If there is any particular problems you run in to while doing this, please raise that in dev-platform. There are people there who can help both with coming up with a solution, and that can help with adding features to Firefox which would help you in the transition.
Whiteboard: [sg:want] → [sg:want]See comment 57 regarding why we are doing this.
(In reply to Jonas Sicking (:sicking) from comment #57)
> 1. The way enablePrivilege works is just not safe for users. The fact that
> the only thing protecting a user from having arbitrary privileged code is a
> plain popup. This popup is displayed with little help giving the user basically
> no chance to make an informed decision.

Not so. For unsigned code the popup clearly states that to accept could be UNSAFE if the source of the code is not trusted by the user. This is true of any software, including any FF add-on that you propose will replace enablePrivilege. So changing to the add-on system does not necessarily add security. A vandal can also use an add-on.  

> 2. Implementation-wise enablePrivilege has always been very quirky. It only
> enables privileges during a given callstack which is very contrary to how
> the rest of javascript works. It has forced us to have a lot of complexity in
> our implementation which at best caused bad performance, but also has has
> caused lots of security bugs.

Backwards compatibility is way more important than implementation and even performance problems. There are always "other ways" to solve problems in software while still maintaining backwards compatibility, look how Microsoft had done it for their OS's. Obviously it may take more effort but it is worth it. Each security bug would have to be looked at to see if there was another way to solve it.

> 3. It stood no chance of getting standardized and working cross browser.
> Other browsers were simply not interested in implementing it. At mozilla our
> goal is to push a standardized web as the platform. Browser specific APIs is no
> better when they are Firefox-only than when they are IE-only.

Active X for IE can be used to do similar things to enablePrivilege so although enablePrivilege itself would not be implemented on other browsers you could make an application run for FF and IE by using both of these in the same code section. Replacing enablePrivilege with an add-on means you need the add-on plus active X and the code is split into two places. This is worse and messy plus add-ons are browser specific. 

> 4. Because we, compared to our competitors, are operating on a pretty limited
> budget, we simply can't afford to keep around any feature just because
> there is someone out there using it. Despite what you might think,
> enablePrivilege isn't used that much out there. Especially in comparison to
> other mechanisms that extend the capabilities of the browser, like addons.
> We have been investing in making these mechanisms more capable with the
> explicit goal of making it possible write addons which replace the use of
> enablePrivilege. For example much of the recent wrapper work makes it much
> easier and safer to write an addon which inject APIs in selected pages.
 
Cheaper to keep an existing feature than mess around. How much have you expended in patching up the 800 or so instances of enablePrivilege in your own test procedures? I have never seen any figures out there of how many are using enablePrivilege. I wonder if you actually know? There seems quite a few complaints so far... Addons destroy the simplicity of a pure javascript app, another thing to patch onto the application, very messy, browser specific, and more inconvenient to the user to install rather than just accepting the enablePrivilege popup. In addition some developers must learn another bag of worms (the addon system) and expend considerable effort just to keep their app running. Many will not bother and for other apps the developer is long gone. Net result is you have permanently broken many apps. Not acceptable to common sense and you could have found another way.
 
> It's simply too costly for us to keep supporting enablePrivilege, even when
> considering the additional investments that we've had to do in addons to
> allow people to transition off of enablePrivilege and onto using addons.

What about the cost to users and app developers. What about the cost of permanently broken apps. Isn't the customer always supposed to come first.
 
> We realize that rewriting your signed jar as an addon isn't easy. If there
> is any particular problems you run in to while doing this, please raise that
> in dev-platform. There are people there who can help both with coming up
> with a solution, and that can help with adding features to Firefox which
> would help you in the transition.

Not only isn't it easy, it won't be done in many cases, broken permanently, end of app.

So in summary, all your arguments have been negated above and the reasons for your policy are incorrect. I therefore think decisions about Mozilla should go to a referendum of all users rather than a select few in dictatorship who are clearly making bad decisions.
(In reply to Jonas Sicking (:sicking) from comment #57)

I back all the comments John Middlemas made.

Furthermore:
> 1. The way enablePrivilege works is just not safe for users. The fact that
> the only thing protecting a user from having arbitrary privileged code is a
> plain popup. This popup is displayed with little help giving the user basically
> no chance to make an informed decision.

I agree the popup window was a bit non-alarming. But that could be solved by just redesigning the window. You can easily redesign 3 windows like that on a rainy afternoon. Much cheaper than removing it. 
The whole point of the window is that the user crosses a border there. That border can not be crossed anymore because an iron curtain is let down.

> 2. Implementation-wise enablePrivilege has always been very quirky. It only
> enables privileges during a given callstack which is very contrary to how
> the rest of javascript works. It has forced us to have a lot of complexity in
> our implementation which at best caused bad performance, but also has has
> caused lots of security bugs.

The scope of javascript is very local to the given page. The scope of enablePrivilege is (or can be) bounded just the same. I don’t see the problem here. The effort of removing it would much better be directed to solving dependency issues inside Firefox one-by-one. After all enablePrivilege would only be practical in the context of a webpage or extension. So any deeper dependencies would be pointless anyway. 

>3. It stood no chance of getting standardized and working cross browser.

As mr Middleton said other browsers have  replacement systems. This argument is essentially right, but not to the point. There is no replacement that made it to cross browser compatibility and as mr. Middleton said forcing us to make an extension only makes cross browser compatibility more difficult. 
Making an extension for every f*rt we blast is not the way forward. Apart from the fact that we are users of the system and not builders of it, there are far too many extensions already. 
For instance: since the beginning of days we have  a bookmarking utility in firefox / netscape. Yet extension makers come up with many toolbars containing only 1 button linking their own site. Most of those toolbars are only a very annoying and costly way to advertise their own websites and are therefore essentially adware and malware. Instead of properly marking that practice as malicious you (and norton and macafee and avg) add to the problem by producing your own and actively promoting them in the documentation.
Anyway, once installed extensions are there always and everywhere and can make ff instable at any given time for no obvious reason. So they are not fit to replace specific functionality of only 1 website. Imagine we all do what you propose and flood users with one-time-use extensions and toolbars. If everyone takes only 1 MB after 3 weeks of surfing just starting Firefox will crash your OS. They would just stop using firefox because there would be no space on the screen fro the browserwindow. The whole screen would be filled with toolbars.
Cleaning up your extensions will be very tedious, because you want to preserve the ones that you like or need. The idea seems nice, till you start thinking about it. After that it just causes bad dreams.

Extensions are no solution to the problem. Because if you want to use the same functionality in an extension you will need enablePrivilege too. And that is gone. 
Just suggesting making an extension for the functionality proves enough that you didn’t really think about this properly. (I am not an expert on extensions. So a simple example of a functionality you can access by an extension without the use of enablePrivilege that is blocked now by removing it in common javascript will prove me (partially) wrong.) 

The program I am making (as a practice project for a more complicated application) does some quite low level filesystem access that will not be even remotely possible in javascript. So I am making a dll in C++. A scripted extension will just not solve my problem. I am looking at the possibilities of making a npruntime plug-in now. But I am very reluctant, because my program is designed to do a specific way of file copies that will only scarcely be needed by some people, and therefore does not justify a position as a plug-in, which will be on the users computer forever and ever. Let alone if you guys will approve of it of course. And then of course: does npruntime still work? Who knows after this action.
“Open source software in inherently unreliable.” I know what they mean with that now.

Talking about npruntime: as far as I can see now (after 1 afternoon reading) that can be a good replacement for enablePrivilege and js-ctypes and xpdcom. It is already cross browser compatible and would benefit if you extend usability to remote calls (or limited remote calls). Of course with proper dramatic popups to warn the user that she is going a dangerous path. I haven’t tried using npruntime yet though. 

> 4. Because we, compared to our competitors, are operating on a pretty limited
>    budget, we simply can't afford to keep around any feature just because
> there is someone out there using it. Despite what you might think,
> enablePrivilege isn't used that much out there. Especially in comparison to   > other mechanisms that extend the capabilities of the browser, like addons.    > We have been investing in making these mechanisms more capable with the       > explicit goal of making it possible write addons which replace the use of      > enablePrivilege.
> For example much of the recent wrapper work makes it much easier and safer to
> write an addon which inject APIs in selected pages.

The use of functionality protected by enablePrivilege (like js-ctypes and xpdcom) was very tricky. And the misleading, fragmented and often erratic documentation only made it more difficult. It took me 2 weeks of painstaking trial and error and going around in circles to get my first dll call on the road. For instance only 1 source mentioned enablePrivilege in association with js-ctypes, and only in a comment somewhere. So just figuring out that I needed it took me quite some time. Figuring out how to define a function in c++ that could be called from javascript was something else. The Mozilla documentation just skips that part, and all the sources on the internet were just wrong. People commenting problems usually just copied the Mozilla documentation and did not bother to try first if what they said was true. Eventually after investigating a lot of uninformed hints by lazy support writers I figured it all out and got it working. And then you blocked it. 
I am sure many a more capable and more experienced developer gave up on it just because he had no time for it. If I worked for a boss I couldn’t have done it either. I would have looked like an idiot after 2 weeks of trying with not a single resulting line of code. He would have probably taken me off the assignment after 2 days. 
I was planning to write a tutorial that showed how I did make the connection between javascript and the dll that actually would make it work. But of course there is no point in doing that anymore.

Making a dll with an interface that is both accessible in firefox using js-ctypes and activex in msie turned out not to be difficult at all. It is possible to make a dll with a combined interface of native c++ functions for js-ctypes and microsoft managed functions for activex. Those functions would be just a wrapper for the functionality that would not have to differ at all.
But I will not tire you with things of the past. Npruntime is the word now or forget about firefox forever. After all most people have several browsers installed so it is no problem to ask them to close firefox and use another one. 

> We realize that rewriting your signed jar as an addon isn't easy. If there
> is any particular problems you run in to while doing this, please raise that
> in dev-platform. There are people there who can help both with coming up
> with a solution, and that can help with adding features to Firefox which
> would help you in the transition.

I don’t need cr*p. I need a working solution. There is a whole world outside firefox and “adding features to Firefox”. You just destroyed the road to a large part of it just because you never go out and can’t imagine anyone else does. Words, however compassionate can never make up for that.
Firstly let me thank Jonas for your sincere engagement here. Regardless of disagreements, that really made me feel someone was listening and doing some consideration here.

1) As far as warning dialog safety, I believe a model example is the "I understand the risks" vs. "Get me out of here" security certificate exception dialog. The default answer with non-standard placement would not seem to lend itself to uninformed or Pavlovian clicking.

2) As far as the problems with enablePrivilege's implementation, why not a middle ground? Why not build up a new API which, for one, does not use "netscape" or "firefox" as the obviously non-standards-friendly object, and which can allow behaviors across callstacks. I'd propose the Jetpack API (or Addons SDK or whatever it's called now) as a possible starting point, perhaps with some kind of loading API like requirejs or an extension for the new ECMAScript import. (For Hans' use case, perhaps this API could also allow the likes of C++ code to be passed through.) This would not have the enablePrivilege issues, and it could allow other browsers to come on board in a feature-by-feature way. (It would also be nice to have a single global since HTML5 keeps adding its own globals.)

3) As far as adherence to standards, there is another presumable goal of Firefox to provide usability. I have seen repeated lectures from Mozillians about how standards should not be implemented just because they are standards, so why should the web be held back just because some companies are unwilling to agree to standards and want you to filter all your actions through their services? While it was admirable that Mozilla worked with other companies that were willing to standardize, did Mozilla sniffle about IE not participating initially saying it was worthless to implement if all were not on board? Is an unchecked oligarchy that much better than an unchecked monarchy?

You're already enabling (now requiring) add-ons which are non-standard. So the only difference really, as John and Hans have effectively pointed out, is not only that it is extra work for an application developer, but you are making a system whereby it is less likely for other browsers too to come along and implement the same API, as to be compatible with Firefox extensions, they'd have to implement the same custom XPI file packaging (as opposed to leveraging HTML5 offline cache manifests), implement the Mozilla-specific syntax for accessing bookmarks and history components, etc. rather than allowing access of this information via an (albeit privileged and shared) IndexedDB database whose general methods of access are already being standardized, implement the XUL overlay system with Firefox/Thunderbird/etc.-specific IDs (as opposed to leveraging HTML5-friendly and abstract overlaying through the kind of extensibility offered by the HTML5 contextmenu attribute), and utilize @mozilla-namespaced XPCOM Components and interfaces (rather than agree on a neutral syntax), etc.

4) As far as the limited budget discussion and wrappers to make it easier for addons to inject APIs, again, why not just expose the Jetpack API, but with a site-specific (or page-specific) system and inventing a dialog to go with each requested preference (or for starters, just have one big scary dialog to give all permissions--even scarier than the dialog that already comes when you try to open a downloaded exe file)?

I disagree with Hans in the case of extensions being too many, as I feel toolbars are a choice which people can ignore (and in fact, I'd like a common API for adding toolbars, so one's own HTML5 browser-in-a-browser (i.e., a web app which requested cross-origin privileges) could request access to add these registered toolbars to its own view, perhaps with their information simply added to a shared IndexedDB database).

(Note to @Hans: in normal extensions there is no need for enablePrivilege as already privileged; the Jetpack system is a little more controlled; and a few behaviors, like accessing webpage content, offer restricted APIs and may be disallowed from the AMO site if employed.)
And to amend my oligarchy hyperbole, the situation is more like the Articles-of-Confederation/United Nations vetocracy. If one self-interested power doesn't like it, the rest are supposed to sit still in the name of order and unity...
(In reply to Brett Zamir from comment #61)
>  If one self-interested
> power doesn't like it, the rest are supposed to sit still in the name of
> order and unity...
Or just go on following their own agenda. If it can't be enforced it also can't be prohibited. 

(In reply to Brett Zamir from comment #60)
> 1) As far as warning dialog safety, I believe a model example is the "I
> understand the risks" vs. "Get me out of here" security certificate
> exception dialog. The default answer with non-standard placement would not
> seem to lend itself to uninformed or Pavlovian clicking.
Warnings and cautions, however dramatically formulated, loose their edge if you see them too often. It is important that a user gets a choice if there is something dangerous going on, but it should be avoided if there isn't. Every time a user has to click "ok, I take the risk" in a dialog, it looses a bit of it's value.

> 2) As far as the problems with enablePrivilege's implementation, why not a
> middle ground? Why not build up a new API which, for one, does not use
> "netscape" or "firefox" as the obviously non-standards-friendly object, and
> which can allow behaviors across callstacks. 
I would support or vote for any standardised way of doing this. Obviously the whole world would benefit from that.
I do not believe in roadblocking dangerous operation because, as in this case, you also block even more very desirable albeit non-standard operation if you do that. 
Allowing it with caution is better. 

> (...) implement the
> Mozilla-specific syntax for accessing bookmarks and history components, etc.

More standardisation or developing it to a system that could be a standard is always desirable. 
More standards = good.

> but
> with a site-specific (or page-specific) system and inventing a dialog to go
> with each requested preference (or for starters, just have one big scary
> dialog to give all permissions--even scarier than the dialog that already
> comes when you try to open a downloaded exe file)?

Maybe an enablePrivilege like warning system should be extended to the chrome also. I wouldn't be sure how it could be implemented, but what about a system that would build in warnings for unusual functionality applied by extensions, that could be switched off on a functionality by functionality basis per extension? An extension downloaded from an approved site would then come with an explicit set (controlled by the site admins) of privileges enabled for that extension alone, while a wildly downloaded extension would have to generate popups for every dangerous functionality it wants to perform.
Extension specific enabled privileges should then be listed in the information page of the extension (in the add-on manager).

By the way, I think that writing the registry (on windows) or starting a chain of events that ultimately writes the registry is dangerous nonstandard operation that should be behind a warning sign. That may also be the case for writing anything outside the designated mozilla application-data directory. 

> I disagree with Hans in the case of extensions being too many, as I feel
> toolbars are a choice which people can ignore (and in fact, I'd like a
> common API for adding toolbars, so one's own HTML5 browser-in-a-browser
> (i.e., a web app which requested cross-origin privileges) could request
> access to add these registered toolbars to its own view, perhaps with their
> information simply added to a shared IndexedDB database).

Maybe this is also a problem of standardisation. If you want to add a control you are kind of forced to add a group on the menu bar or a whole toolbar where just a menu item in a sub menu or a single button would be better, because there is no designated place to add a menu item or button. I might bet (not too much) that a standard “extensions” toolbar where extension developers can add their button would be welcomed by many.
Of course the "too many" statement is a matter of taste. I think there are too many that have the single purpose of advertising a single website or commercial activity, but you may disagree. And it would not be my station to disallow any of them. 
Maybe the aggressive way the Ask toolbar (for instance) is marketed added a lot to my aversion. And of course the way it hijacks your standard search engine and homepage just like any Russian rogue would do it.
 
> (Note to @Hans: in normal extensions there is no need for enablePrivilege as
> already privileged;
So I learned. My initial opposition to removing enablePrivilege was partly inspired by the assertion that the now blocked functionality would be restricted by enablePrivilege  for an extension too and hence now impossible. That turned out to be a wrong assertion. So I am still not convinced of the need to remove enablePrivilege, but I accepted it as a fact of life now.
I was rather surprised to find (and I still am) that Firefox allows unrestricted operation to extensions and has such a huge security hole entirely unattended. (Well, not entirely, but still.)
> and a
> few behaviors, like accessing webpage content, offer restricted APIs and may
> be disallowed from the AMO site if employed.)
Like DIRECTLY accessing webpage content or running webpage content in the chrome.
Interaction between webpage and extension is very well possible in a safe way, using for instance event triggers.  That keeps the extension in the chrome and the page content in the page.
Hi everybody !

Here, at Numalliance, a leading and innovative company in  it's domain, we are a nice busy developer's team that have developed an  html/javascript application (look at attachment 660397 [details]) running inside firefox and thus needing writing or reading xml files created with this appliction.

Thanks to some stupid guys (I am sorry, but I do not have any other word) , that may never leave their desktop , our application does not work anymore, since we are not able to save files.

So, now, it is urgent providing a workaround to achieve this feature, we are awaiting for solutions.

Regards,
Stephane Ancelot
There is a very very strange behaviour on Win XP.
upgrading from ff14 it runs fine
setting up a brand new ff15 does not work ..????????
To be honest, I don't really care how things turn out... as long as my TiddlyWiki instances don't have to fall back to using TiddlySaver.jar to save to disk using the exploit-prone Java plugin.

As is, I already have a copy of Firefox 4 that I keep around for upgrading instances of TiddlyWiki old enough to rely on the pre-CORS mechanism for privileged XMLHttpRequest calls.

I'd really rather not have to start doing all my TiddlyWiki work in outdated versions of Firefox.
Assignee: sayrer → nobody
(I'm the developer of Remote XUL Manager.)

In my opinion, the difference is that there are many features in remote XUL that aren't in HTML, and many internal deployments relied on them. The purpose of the extension is still to help these people transition to other technologies, because Remote XUL will eventually break (and is partially broken now).

In the case of enablePrivilege, there's a very simple solution: create an add-on that fills the gap. This is not only more effective and flexible than enablePrivilege, but also much safer.
Thanks Jorge, but forgive me, I wasn't asking for a comparison of the two; was asking why enablePrivs could not be brought back but only accessed via a whitelist of URLs.  

I have to declare here, I am much in agreement with both Brett Zamir and  Hans Hokke - whose arguments "against" (IMV) pretty much negate any arguments "for".  This change is causing harm to existing code (as did the remote XUL affair).

Anyway, thanks for the contrib.
So, the end of this story is that pages containing javascript code that
make use of extended functionalities (such as reading and writing to the
local filesystem) no longer work on Firefox 15 (and will not even more in
Firefox 17 where granting manually privileges will be removed altogether).
Such applications should then be reimplemented as extensions.
This is quite a big change since implementing extensions is quite different
than writing html pages (with javascript in them).
It is something that should be advertised properly so as to let application
producers plan what they have to do to make their applications continue
to function.
I have not seen any such warning in Firefox 15.
Can someone tell me when (in what release version of firefox) this disaster is going to appear?

Also, this the following URL correct for downloading old versions?
http://releases.mozilla.org/pub/mozilla.org/firefox/releases/

TIA
(In reply to Russ from comment #71)
> Can someone tell me when (in what release version of firefox) this disaster
> is going to appear?
> 
> Also, this the following URL correct for downloading old versions?
> http://releases.mozilla.org/pub/mozilla.org/firefox/releases/
> 
> TIA

From my experience, I can tell you that Firefox 17 (current Aurora) removes it entirely, breaking apps in existing profiles. I didn't notice, but Firefox 15 apparently removes enough of the UI to force you to manually edit prefs.js to add new exceptions.

As for that link, apparently not. It just has versions still considered current in some sense. Can anyone tell me where I could find a Linux version of Firefox 4? (As is, I have to use Wine and a Firefox 4 Win32 installer to use the internal updater in old, pre-CORS versions of TiddlyWiki)
The more I think about this, the more disappointed I become with Mozilla's approach to this.  As I see it, there are two key items:

1 - The removal of enablePrivs
2 - Moz's handling of it

One can take a view on the former - it's either a good or bad idea depending on your circumstances (I guess).  

But as regards how it was handled?  Astonishingly bad, in my view. 

It was only a few days ago that I stumbled on this "bug" and since then, I have been trying to figure out what I need to read or subscribe to so that this kind of thing does not sneak up on me again - any pointers, anyone? I'm sub'd to dev-planning as of yesterday, but is there anything better?

Jeremy Ruston (creator of tiddlywiki.com) has managed to code up an addon for tiddlywiki users - which is great, of course.  But what about folks that don't subscribe to the tiddlywiki list or don't follow @tiddlywiki? (addon is linked in comment 67, if you need it) 

And realise, tiddlywiki is just ONE app that relies on enablePrivs. Measuring impact is of course difficult but tiddlywiki has a huge user base a significant proportion of which use firefox.  The day will soon come when as a result of doing the "right thing" (enabling updates) these people will find their beloved tiddlywiki(s) suddenly and inexplicably broken.

Guys, that's poor management and bad behavior.

Back in the last century, when I was involved in software support, we had a bug logging system that dealt with "bug severity" in real simple terms:

CRITICAL - if it damages user data; if it fails to save user data; if it crashes the app; if it crashes the computer.

Under those terms, Firefox is going critical somewhere between 15 (now) and 17.

Question:  why can't mozilla release a tide-you-over addon to enable this functionality?  Take a leaf from jQuery's book - put the stuff-you-consider-to-be-**** in a plugin.

Please?
The disaster has already occurred in the current release, Firefox 15:
adding manually the enabling lines in prefs.js or user.js simply does
not solve the problem.

The position of Firefox is that pages with javascript code that needs
privileged operations must be coded as extensions.
This is a bad idea for several reasons:

   1. extensions are meant to add functionality to the browser, but
      most client-side apps do not want to add items to Firefox menus
      or icons somewhere in the window: they need much more real things
      such as accessing the filesystem
   2. extensions that are client-side apps are much more difficult to program
      even with the new SDK (think to the code you need to write to make
      a privileged operation)
   3. extensions need to be installed ....

In my opinion, removing the possibility to interact with the local OS and
filesystem effectively makes impossible to implement client-side apps
with Firefox. This is a very severe reduction of the capability of Firefox,
and makes it lag behind IE.
Is there any way to escalate this issue to Gary Kovacs?
(In reply to Angelo Borsotti from comment #74)
> The disaster has already occurred in the current release, Firefox 15:
> adding manually the enabling lines in prefs.js or user.js simply does
> not solve the problem.
> 
> The position of Firefox is that pages with javascript code that needs
> privileged operations must be coded as extensions.
> This is a bad idea for several reasons:
> 
>    1. extensions are meant to add functionality to the browser, but
>       most client-side apps do not want to add items to Firefox menus
>       or icons somewhere in the window: they need much more real things
>       such as accessing the filesystem
>    2. extensions that are client-side apps are much more difficult to program
>       even with the new SDK (think to the code you need to write to make
>       a privileged operation)
>    3. extensions need to be installed ....
> 
> In my opinion, removing the possibility to interact with the local OS and
> filesystem effectively makes impossible to implement client-side apps
> with Firefox. This is a very severe reduction of the capability of Firefox,
> and makes it lag behind IE.

Right.  It makes one wonder if firefox running on B2G/Firefox OS will suffer the same crippling, ill-thought-out, "axe-weilding from above".
The major problem in this discussion is that everybody will be impacted since some people will remove functions without providing a migrating/developers guide.

When you will provide the guide and documentation to workaround this problem, nobody will be afraid.
This is the first thing to do, before inhibiting working functions , thus giving time to developers to migrate their applications using this guide.

For the only purpose of retrieving a temp directory in my program I had to write an extension, for the only reason being able to access environment variable !!!!
To live this experience, I can tell  it was a pain, and a waste of time !!! 

But, I think some people like myself will have a look at how is it done with google chrome ....it may be easier... ?
I have sent a tweet to Gary Kovacs on twitter ...
(In reply to Angelo Borsotti from comment #77)
> I have sent a tweet to Gary Kovacs on twitter ...

Cool.  Reviewing his latest tweet:  

#WEF Look forward to speaking at the World Economic Forum tomorrow: "creating a resilient cyber economy" - Users must be at the center.

Here's hoping some of that "users must be at the center" rubs off here.
(In reply to Russ from comment #73)

> It was only a few days ago that I stumbled on this "bug" and since then, I
> have been trying to figure out what I need to read or subscribe to so that
> this kind of thing does not sneak up on me again - any pointers, anyone? I'm
> sub'd to dev-planning as of yesterday, but is there anything better?

* https://blog.mozilla.org/addons/
* http://www.squarefree.com/burningedge/
* The https://developer.mozilla.org/en-US/docs/Firefox_17_for_developers series
* dev-platform (e.g. this message from 18 months ago: https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.platform/77VjjKrEbow)
* Your error console (there has been a deprecation warning since Firefox 7, see bug 668030)
* Use nightly or Aurora builds, so you notice changes (and bugs!) before your users do.
(In reply to Jesse Ruderman from comment #79)
> (In reply to Russ from comment #73)
> 
> > It was only a few days ago that I stumbled on this "bug" and since then, I
> > have been trying to figure out what I need to read or subscribe to so that
> > this kind of thing does not sneak up on me again - any pointers, anyone? I'm
> > sub'd to dev-planning as of yesterday, but is there anything better?
> 
> * https://blog.mozilla.org/addons/
> * http://www.squarefree.com/burningedge/
> * The https://developer.mozilla.org/en-US/docs/Firefox_17_for_developers
> series
> * dev-platform (e.g. this message from 18 months ago:
> https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.platform/
> 77VjjKrEbow)
> * Your error console (there has been a deprecation warning since Firefox 7,
> see bug 668030)
> * Use nightly or Aurora builds, so you notice changes (and bugs!) before
> your users do.

Somehow, I get the impression that's either insufficient or insufficiently advertised. I run Aurora as my day-to-day browser AND I'm subscribed to the full Planet Mozilla firehose (which one would assume would cover all of that) and I didn't know about this change until the update to Firefox 17 broke the ability to save in the TiddlyWikis I use for day-to-day personal organization.
(In reply to Jesse Ruderman from comment #79)
> > sub'd to dev-planning as of yesterday, but is there anything better?
> 
> * https://blog.mozilla.org/addons/
> * http://www.squarefree.com/burningedge/
> * The https://developer.mozilla.org/en-US/docs/Firefox_17_for_developers
> series
> * dev-platform (e.g. this message from 18 months ago:
> https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.platform/
> 77VjjKrEbow)
> * Use nightly or Aurora builds, so you notice changes (and bugs!) before
> your users do.

Thanks, Jesse, that's a great list that took some time to compile - your diligence is noted :)

> * Your error console (there has been a deprecation warning since Firefox 7,
> see bug 668030)

I see no evidence of this warning in 15.0.1 Win7/64. 

Confirmed in 16/beta.  

15.0.1 saves a file from js code using enablePriv just fine, whereas 16 fails to save and the only error reported (in firebug and native error console) is that a var in my code is undefined (no doubt due to enablePrivilege being kneecapped - I'll need to check further).

Sorry, I maintain my view from earlier; this is poorly handled.  I checked my notes for the app that I built that relies on xpcom and found my references to the MDN docs that I used.  At the very top of the list, is:

https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference_group

I've just been back to that page and did a search for "deprecat" < no results.  This is bad. The first stop for me when writing new code is to RTFM. So, in response to,

> * dev-platform (e.g. this message from 18 months ago:
> https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.platform/
> 77VjjKrEbow)

Firstly, 18 months ago, I wasn't aware I'd need the xpcom api a whole six or nine months later... so it would not have been on my radar.  Therefore, going forward, I face the same problem - subscribing to the list now won't help me "down the line" unless I happen to *at the same time* be doing something relevant and related to the point under discussion (or at least, have some historic knowledge of it).

Guys, really, this is all about the *handling* of the change (I don't like the change itself, either, but progress is progress - "I get it").

And if I'm a good boy and RTFM, can somebody, PLEASE, W(rite)TFM, too? Or, UTFM - Update the damn thing?  This bug is how old - 30 months?  That posting to the dev-platform is 18 months old - and the docs were and are *still* talking as if xpcom/enablePriv is current - *today*.

And guys, I know you're volunteers (mostly) - believe me, I DO APPRECIATE that... but this is the second time Moz have ripped the rug out from under me/my code.  It hurts.

Finally, I could be wrong, but I sense there's a "tone" developing here - it's starting to sound like a flame war.  I don't like that, nor will I be a part of such.  I'm going to (try to) back off, now.  I just hope you guys take the points raised here and apply them going forward - never introduce a CRITICAL bug by doing less than is required to COMPLETELY prevent it.

Thanks for listening.
Russ / @codacoder
I would be happy to work on providing such a generic add-on as I proposed in Comment 60 to allow add-on developers to have a single reusable and dependable resource for allowing escalation of privileges from within web applications, if I can have assurances that the add-on reviewer at AMO will not say "Your add-on is not accepted for allowing dangerous behaviors" since that is the whole point. Yes, I know I can host it at some HTTPS site, but not really interested in doing that.

We can put all kinds of disclaimers on the add-on page, even name it "Living Dangerously" or whatever can be agreed on, and it can be reviewed to ensure that the add-on is only providing privileges with which the user is complying and after sufficient warning, and whose privileges have been explained clearly. We can progressively expose more of the API, but start with some probably in-demand ones like local file/database and remote file access.

Would that work?
(In reply to Brett Zamir from comment #82)
Brett, in Firefox 17, also the user_pref that grants the privilege in the
pref.js file will be removed. Where do you plan to remember the urls of
the applications that are allowed (by the user) to escalate privileges 
would be kept?
(In reply to Brett Zamir from comment #82)
> I would be happy to work on providing such a generic add-on as I proposed in
> Comment 60 to allow add-on developers to have a single reusable and
> dependable resource for allowing escalation of privileges from within web
> applications, if I can have assurances that the add-on reviewer at AMO will
> not say "Your add-on is not accepted for allowing dangerous behaviors" since
> that is the whole point. Yes, I know I can host it at some HTTPS site, but
> not really interested in doing that.

I gave that add-on idea some thought a few weeks ago and decided not to make it because I think it would be to insecure to create (at all). While there are ways to make it safer, the enabling process would be too convoluted for it to be practical for end users.

You're free to create it yourself, of course, but I doubt that it would ever be accepted on AMO because of how unsafe it is, potentially.
Just wondering what mileage may be gained by coding to this:
https://developer.mozilla.org/en-US/docs/DOM/File_API/File_System_API

Obviously, any code written against it will need close attention due to the nature of the thing - it's highly likely to change before it's fully spec'd and stable.  Plus, I think it likely easier for users to blow away the content without realizing they may be affecting their cherished browser-based apps and/or data.  Dunno.  Need to think about it.

Thoughts?
(In reply to Russ from comment #85)

The file API allows to access a sandboxed filesystem, i.e. a dedicated part
of you local filesystem only. All the worse, files there may be recoded with
a format that is not the usual one, and thus you may not access them from
outside the web app that created them (as it is in Crome).
For some apps this may be sufficient, but in the general case it is not.
To the people trying to argue against the complex-code-/stack-walking-issue or formulating a "reasonable solution" to this: You probably have no idea about the complexity of an interpreter. Don't try to argue against the developers unless you have a masters degree in computer science, just don't. If they think it's best to remove enablePrivileges completely, they based their decision upon a thorough review, and not because "it just does not feel right". (Note, I'm no computer science alumni or student myself, but I have huge respect for their work.) 


If you have concerns about the functionality of your project: 

1) Try to use standard API where feasible. Try to live with the sandbox. You can store and read any file you want from your sandbox (though I recommend IndexedDB rather than a file system access). 

2) If you need to store settings, in whatever format you like, see No. 1. If you need clients to "save" files e. g. for printing or archiving, make them "download" (HTTP header "Content-Disposition") the file (or display inline, e. g. PDFs). If you need access to some files from the local file system, make clients upload (<input type="file"/>) them. Look out for new APIs (e. g. for portrait photos, take a look at getUserMedia()). Advance or propose new APIs by bringing yourself in the process. 

3) If you need to sync a lot of data between several clients, setup a master-client-infrastructure where the master acts as a "cloud". Proceed with standard APIs and leave the clients' OS and FS alone. Also, see No. 2. If you don't have the money for a server (master) in your network, go buy a RaspberryPi (or probably any very old computer will be happy running Linux and Node.js). Or "abuse" a client PC for running Node.js as a server / "cloud" instance. 

4) If you really need to access your full file system without any limitations, and you are using this software in a limited environment (personal use or in an intranet), write a small Node.js server providing a simple FS API (this can be done with less than or close to 100 lines of code). 

5) If you need full FS access, and you are providing this for a large user base sans intranet (not in one company), you are likely doing something wrong. However, you can write an addon that provides a tailored API for your needs – please note that your code is still wherever you want it to be, just the (e. g. FS access) API needs to be provided by the addon. No code seperation. Full Yay. 

6) If you want to write an app that alters your OS settings (e. g.!), a web app is not what you are looking for. You need a native app. (However, have a look at No. 4 again, e. g. if your UI is "webby" and your logic is a compiled or Node.js code.)


The bug tracker is the wrong place for discussing this issue. If you need help removing enablePrivileges, you should provide a detailed review on why and how you use enablePrivileges and what your project attempts to solve (e. g. on the mailing lists): Maybe there is a totally differenct solution to your problem! 

Hope that helps.
(In reply to Florian Bender from comment #87)

> 1) Try to use standard API where feasible. Try to live with the sandbox. You
> can store and read any file you want from your sandbox (though I recommend
> IndexedDB rather than a file system access). 

I don't trust either of those with my data. Extensions like BetterPrivacy make it too easy to accidentally leave my data off one of my privacy whitelists and about:permissions seems to have just faded out of mention before it got completed and hooked in.
Then provide an online backup which can be reloaded in case it gets lost. This is the Internet (or, in some cases, Intranet). For personal use, take a look at the Mozilla WebApp efforts.
(In reply to Florian Bender from comment #89)
> Then provide an online backup which can be reloaded in case it gets lost.
> This is the Internet (or, in some cases, Intranet). For personal use, take a
> look at the Mozilla WebApp efforts.

...or I could just install the recently-written TiddlyFox extension and continue with the comfortable, intuitive option of keeping my semi-private data AND the code to read and modify it in a single file named ~/Dropbox/tiddlyme.html.

Heck, TiddlySaver.jar still works in browsers other than Chrome for Linux, but I try to only enable Java when I'm using the Opera Mini Simulator.
Well, you can. I just want to point out that Dropbox has an API, too. Problem solved, without an extension.
(In reply to Florian Bender from comment #91)
> Well, you can. I just want to point out that Dropbox has an API, too.
> Problem solved, without an extension.

True, but that's not too different from opening a free account on TiddlySpace and creating a private instance there. More complication when dealing with intermittent connectivity and at least the server-side code for TiddlySpace is open-source.

I'm just really getting tired of seeing everyone rushing to kill off the useful abstraction that is the application-independent, non-munged bag of bits that can be easily copied, moved, and organized. (Whether it's intentional as in iOS or through ignorance)

One of the guys at FilePicker.io wrote a good little bit on that:

http://blog.filepicker.io/post/26157006600/why-files-exist
I beg to differ - it solves a semi-related problem which sidesteps the original intent of (in this case) tiddlywiki (further dicussion of which would be very much off-topic).  

But to be clear,  removal of this API/family will kill off use of Firefox as a standalone app platform  < read OFFLINE!  

So-called "solutions" and "answers" based on online/server functionality are asking the wrong question.
I bought an android phone today and I was very displeased to find out that I bought myself into slavery to google.
I could install Firefox on it, but the Mozilla website linked me to the google appstore where I could (by the grace of google) download and install Firefox for “free”. But only after I made a google / gmail account. The fake name  igave them is used to personalise my phone, so they say. I wonder what other information on the phone is directly linked to their website, and  I wonder how much bandwidth I will need just uploading my phone history ans GPS data to google every month.
This is of course illegal abuse of market power by the greatest phishing company in the world, for the sole purpose of spamming me with commercial junk, but that is beside the point of this topic. The point is the parallel to what happens in Firefox today. 
EnablePrivilege allowed us to offer all kind of internet functionality, also functionality that was non obvious or vulnerable, as we pleased, to be accepted or distrusted to the discretion of the user.
Removing EnablePrivilege forces us to make extensions, which are distributed and filtered not by the supplier or the user, but by one central authority, which is the admin of the Mozilla app shop. And the admin receives that postion by Firefoxes default settings. So it all boils down to power. Should a user be allowed to choose freely and for himself, with the danger of making the “wrong” choice (whatever you mean with “wrong”), or should we decide what is right for him and only offer him the “right” choice?
Of course the tendency in the internet is toward centralisation of power in the well known power blocks and all power blocks are very busy expanding their control over us by their app shops and road blocking each other and outsiders. But should Mozilla go with that flow?
What is the point of open source software if it denies people the basic right to choose just like the commercial sharks do? 
What are all the people who oppose this really fighting for?

Freedom of course. 

Extensions are meant to enhance the functionality of the Firefox program. Not to enable web based functionality. The twisted logic of forcing the use of extensions for web based functionality becomes much clearer if you take into account (maybe subconscious)  power and control factors. 
After all the “vulnerabilities” addressed were not really weaknesses of the program or it’s developers. They were vulnerabilities caused by problems of choice on a user level. The desire to address those vulnerabilities arose from a concern about the wellbeing of the ignorant and inapt user who has to be protected against herself. 
The desire of “fatherly care”, undoubtedly with the best intentions. But it is always with the best intentions. Whether it’s feudal rule over ignorant and superstitious peasants, colonial rule over child like dim witted natives or any form of dictatorship. It’s always the father knows best argument that is cherished most.

But do we really have the right? And is this what we wanted to achieve when we started?
(In reply to Hans Hokke from comment #94)

While I don't want to undermine your argument too much, Firefox (at least on the desktop. I own no phone.) lets you install extensions from anywhere and that's probably not going to change.

People put their extensions up on addons.mozilla.org because of all the additional benefits (automated linting, version bumps, free advertising, appearing more trustworthy, etc.)

Chrome and Android also allow you to install extensions from places other than the Google app store, but Google has been making the incantations you have to utter to Chrome longer and more arcane because Joe Everyman is stupid and keeps installing crapware from outside their store. (Note: Their store requires you to pay $5 for a developer account and can remotely remove installed apps from your phone)
This discussion is all seriously off-topic. Please take it to a newsgroup.
Regarding comment #83, Angelo, if I do it, it would probably be using https://developer.mozilla.org/en-US/docs/Using_content_preferences . Feel free to message me out of this bug about possible implementation decisions. However, at the moment, I am really wishing to first ensure such an extension could gain acceptance for hosting by the AMO (addons.mozilla.org) site in the first place.

Regarding comment #84, Jorge, why would the enabling process need to be any more convoluted than the user consent to install an extension? What is, or what would need to be, the difference? I really don't get what all the hand wringing is about when third-party installation is already allowed (as I believe it indeed should be, given the historically open mission of Mozilla)... Privileges could all be requested at once to avoid every new operations requiring new permissions, if that is what you are speaking about.

As far as approval on AMO, Jorge, are you not the one who makes the final decision there? In either case, how can we get a definitive answer along with a rationale about how this would be any different from normal third-party extension installation--except by being MORE secure in its potential for greater granularity and transparency in privilege approval? 

I would think the granularity and transparency proposed for this add-on could actually be useful to have for any extension installation--it would be nice to know, for example, whether the toolbar button I have added wishes to go beyond opening a dialog and rather wishes to access my browser history and send my data back to some server.
(In reply to Florian Bender from comment #87)
> To the people trying to argue against the complex-code-/stack-walking-issue
> or formulating a "reasonable solution" to this: You probably have no idea
> about the complexity of an interpreter. Don't try to argue against the
> developers unless you have a masters degree in computer science, just don't.

I can. I have a master Phd degree in computer science and I implemented interpreters for over 40 years. Believe me, implementation is not that terribly difficult. Of course, I understand the desire to keep the code simple and more maintainable. But the whole point is that a very big feature is being (almost silently) removed without providing a replacement.
From my perspective it is as if Microsoft or Ubuntu one day shipped a patch (that gets installed automatically) that removes the possibility to access the local filesystem or the whole OS from within native applications, alleging that it makes their code simpler and safer.
A solution that, e.g. removes enablePrivilege, but introduces a new function
to grant them to a page instead than to a function (it is just an example)
could be easily retrofitted to applications because it implies a small amount
of changes. The use of an extension on the other hand requires to implement
a piece of code that effectively is a language bundle for an OS, quite a big
thing, and to change all calls to XPConnect functions, another big change.

> If you have concerns about the functionality of your project: 
> 
> 
> 4) If you really need to access your full file system without any
> limitations, and you are using this software in a limited environment
> (personal use or in an intranet), write a small Node.js server providing a
> simple FS API (this can be done with less than or close to 100 lines of
> code). 

I am not sure I understand this. Do you mean I have to install a web server
on my computer and provide some server-side logic in it to access the local
filesystem?

> The bug tracker is the wrong place for discussing this issue. If you need
> help removing enablePrivileges, you should provide a detailed review on why
> and how you use enablePrivileges and what your project attempts to solve (e.
> g. on the mailing lists): Maybe there is a totally differenct solution to
> your problem! 
> 

Well, people here are providing arguments not to remove it. So it is not
such a wrong place. There are lots of reasons to access the local filesystem,
the very same as the ones of traditional applications. It seems queer for
Firefox to first provide such an access and later question the reasons to
access it.
(In reply to Stephan Sokolow from comment #95)
> (Note: Their
> store requires you to pay $5 for a developer account and can remotely remove
> installed apps from your phone)
Which is scary if you think of it. If they can access those apps, what else can they access? Who is in control here? How safe am I? This defies everything American and Dutch culture stands for.

>  Firefox (at least on
> the desktop. I own no phone.) lets you install extensions from anywhere and
> that's probably not going to change.
That is a big difference I admit. But the warnings built in to Firefox still favour that proprietary site over competing sources, just on the basis of propriety. You can change that setting, but who will? 
As it is now you can easily and without warning install extensions from the appointed websites, and all other sources are branded "dangerous" just because they are not controlled by Mozilla.

One of the peculiarities of "fatherly concern" is usually that "friendly" sources (being friends of the controller, not so much of the user) are favoured over "unfriendly" (competing) sources. The argument is usually that they are “dangerous and possibly hostile”, which really means they are not controlled (or taxed) by the controller. The judgement of the user plays no part in this. He can have his own program downloaded from his own (fully trusted) website and still get warned he is in mortal danger.  

> Chrome and Android also allow you to install extensions from places other
> than the Google app store, but Google has been making the incantations you
> have to utter to Chrome longer and more arcane because Joe Everyman is
> stupid and keeps installing crapware from outside their store.
Who decides what is **** and what is not? Just paying a fee to google does not make your app less ****. 
How arrogant can hey get? This is the essence of authoritarianism and power abuse. 
They seem to get away with it for now. I expect the first lawsuits very soon.
Seriously, who has been involved in safety problems with this function ?

Do you think it is up to a browser to provide the whole safety process ????
What is the main function  of web browser ?

I don't think so, but if you need safety ---> YES ! plug a special extension :-),

like you will plug an antivirus a parent control and so on !!!!
> all other sources are branded "dangerous" just
> because they are not controlled by Mozilla.

No.  They're treated differently because they haven't undergone a code review that ensures a minimum quality standard.
(In reply to Brett Zamir from comment #97)
> As far as approval on AMO, Jorge, are you not the one who makes the final
> decision there?

I'm in charge of AMO policy, yes. I can't give you a final answer because I would need to look at the implementation and user interaction to be sure that it won't be accepted. However, I'm almost sure that it wouldn't be accepted, not even as an experimental add-on. Please send any further policy questions to amo-editors AT mozilla DOT org or directly to me.

> In either case, how can we get a definitive answer along
> with a rationale about how this would be any different from normal
> third-party extension installation--except by being MORE secure in its
> potential for greater granularity and transparency in privilege approval? 

Users install non-AMO add-ons at their own risk, and Firefox warns them about this. AMO add-ons are held to a higher standard, and we wouldn't want to widely distribute something that is potentially this dangerous, allowing arbitrary sites advanced privileges.

Again, for policy replies, see above.
(In reply to Hans Hokke from comment #99)
> Who decides what is **** and what is not? Just paying a fee to google does
> not make your app less ****. 
Note that the (automatically?) removed words were taken from the citation. 

(In reply to Nicholas Nethercote [:njn] from comment #101)
> No.  They're treated differently because they haven't undergone a code
> review that ensures a minimum quality standard.
"By the Mozilla publishers." You forgot to add that. 
That is basically the point I am making. Even if I fully trust that site, if the site admins there make a much greater effort to ensure validity of what they offer than the admins of addons.mozilla.org and are more reliable, all those factors are void because the Mozilla publishers did not explicitly approve. 
And of course there is a power imbalance because the admins of that site can not present a warning every time people try to install an extension from addons.mozilla.org, although they can guarantee validity and reliability of what I download there just as little as you can guarantee their site.

EnablePrivilege was indiscriminate. That was good. It was apt, timely, and appropriate. Warnings at install of extensions are inapt untimely and inappropriate. And the extension system is inherently unfit to harbour web functionality and content.
It can be used for it, but at great cost.
This happened over in bug 757046. See Blake's blog series on why this needs to happen:

https://blog.mozilla.org/mrbkap/2012/09/12/security-checks-and-enableprivilege-in-gecko-part-1/
https://blog.mozilla.org/mrbkap/2012/09/14/security-checks-and-enableprivilege-in-gecko-part-2/
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Sheesh... no wonder it's difficult for Moz to track all this **** - it's a rats nest.

But one wonders... why would this bug (thread) started in Feb 2010, be treated as a dupe of 757046 first reported just a few months ago?  Isn't that a chronological impossibility?

Wonder also, why those participating in the other thread didn't feel any need to mention it here?

Having read all of 757046, the only person that really seems to get how this should have been handled, is Boris Zbarsky.

Bobby Holley: My intention is to turn it off entirely for external consumers.

Boris Zbarsky: 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.

Crying shame that never happened.

The way I see it, using the initial conversation in both threads as the guiding line, this thread is about removal of enablePrivs and the other thread is about the impact of same on testing.  And going only on the bug title, "interim solutions", it's a hell of a stretch to call this thread a dupe.

Right Bobby?  

Moz's handling of this was/is careless.  It's not what I've come to expect from you guys.
(In reply to Russ from comment #105)
> Sheesh... no wonder it's difficult for Moz to track all this **** - it's a
> rats nest.
> 
> But one wonders... why would this bug (thread) started in Feb 2010, be
> treated as a dupe of 757046 first reported just a few months ago?  Isn't
> that a chronological impossibility?

It's a dupe in the sense that the code changes discussed here happened in bug 757046. I would have mentioned it earlier in this bug, but I actually didn't know it existed. :-( I just knew that enablePrivilege was something we'd been warning about removing for a year now, and that there were pressing reasons to make it finally happen.

> Wonder also, why those participating in the other thread didn't feel any
> need to mention it here?

Because, as mentioned, I didn't know about it. Also, getting flamed is never fun. And my mentioning of it here comes only a few weeks after the code in that bug landed.

> Having read all of 757046, the only person that really seems to get how this
> should have been handled, is Boris Zbarsky.

Yes, that's generally a good way to describe Gecko stuff. ;-)


> Bobby Holley: My intention is to turn it off entirely for external consumers.
> 
> Boris Zbarsky: 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.
> 
> Crying shame that never happened.

It did. Maybe not loudly enough. But it's not clear what else we could do there. We've sent mail to the enterprise working group, warned in the console, flagged for a release note, and blake wrote a bunch of blog posts about it. That code is still only on aurora, and several months from shipping.

> Moz's handling of this was/is careless.  It's not what I've come to expect
> from you guys.

Sorry for letting you down. :-(

For this bug, it's not clear to me what more could have been done. What _should_ have been communicated more clearly was that the confirmation dialog (but not enablePrivilege itself) was going away in FF15. That one was my fault. But it's a wake-up all, and folks can set the principal capability prefs manually until FF17 rolls out the door.
Bobby - if you read the rest of my comments here, you'll see *I* am sensitive to the whole tone/flame thing <- tried hard to avoid it sounding like a flame war.

You'll also see that I owned up to the fact that I missed this - and asked for advice on what I could subscribe to to improve that whole situ.

I agree, though, I don't know what could have been done.  But then it's not my code base, is it?  I have my own customers to worry about for whom I am responsible and I know it aint easy (or a fair comparison!) but it (moz's handling of it) needs to be improved.  Reminder: I (my customers) suffered the same "sudden loss" of remote XUL too.  This whole things "feels the same".  But at least we were (eventually) given a real solution for that.

Anyway... works beckons...
https://bugzilla.mozilla.org/show_bug.cgi?id=546848

(In reply to Bobby Holley (:bholley) from comment #106)
> For this bug, it's not clear to me what more could have been done. What
> _should_ have been communicated more clearly was that the confirmation
> dialog (but not enablePrivilege itself) was going away in FF15. 
Yes. A clear well communicated timeline with benchmarks that are comprehensible to outsiders would be nice to have published in advance.
And with "published" I don't mean discussing it in this forum. This is obviously a place for insiders and a few outsiders with a very warm interest in the Mozilla project. I ended up on here only after I saw a remark about EnablePrivilege on stackoverflow (?). And even 2 days before you released version 15 I mailed Brett Zamir that I expected it not to be too urgent, because no concrete timeline had been provided and the bug had been marked "new" for 2 1/2 years now. Hardly a sign of high activity.

What can you do to communicate it better? A Blog entry is one thing. That Blog may be read by more people than this thread, but will still only reach that small minority with a warm interest in the project. About 400 million of your 400 million users do not read that blog. 
You have to find the places where most people do go and advertise it there. Preferably in advance. 

I think it would have been great if a warning was posted on the Mozilla update page, starting at version 12 or 13 (or earlier), telling that a major change in the security system was due in version 15. Of course explicitly telling that enablePrivilege would be removed (or disabled, and removed in version 17). It may be that 200 million of the 400 million wouldn't read that, but my bet is that most developers would at least skim it, specially if they are busy building something new. Of course the reader base of that would increase if you announce future changes there as a standard procedure.

And a very important other place is of course the documentation. In the documentation I read, I never found anything about deprecation of enablePrivilege. Even now it still seems all business as usual there. A search on enablePrivilege in https://developer.mozilla.org even today produces 0 hits. I would not call that effective communication.
I think that any description of any functionality that would have needed enablePrivilege should contain a warning that it is deprecated and restricted to use in the chrome in the future. Just a single sentence and a link to a page where it is explained would be all that is needed.
If you started doing that 6 months ago, explicitly mentioning your benchmark targets (v 15 and 17, v 15 expected in august 2012). It would have been clear to everybody who needs it.

If you would have supported that with some simple instructions on how to quickly convert a simple web application to a webpage controlled extension that would have helped a lot for many. 

(As it is now, the documentation on the most obvious safe method of communicating between a webpage and an extension (with events) is insufficiently documented, with an erratic and needlessly complicated example, omitting crucial information on how to really make it work.)

Another trick for making it known on the web may be to just search for enablePrivilege with a search engine, and then commenting a link to the planning information on the most important hits. Usually that would be spam, but in this case it would be important information right from the source that users and admins of those sites would appreciate.
(In reply to Bobby Holley (:bholley) from comment #106)
> It did. Maybe not loudly enough. But it's not clear what else we could do
> there. We've sent mail to the enterprise working group, warned in the
> console, flagged for a release note, and blake wrote a bunch of blog posts
> about it. That code is still only on aurora, and several months from
> shipping.

I the release note of Firebug 15 there is no mention of it:

http://www.mozilla.org/en-US/firefox/15.0/releasenotes/

and not even in the more detailed one:

http://www.mozilla.org/en-US/firefox/15.0/releasenotes/buglist.html

which basically is a list of bug numbers and titles, not much friendly.

The place in which I would expect to advertise changes is the "releases tab in the main Firefox page:

http://www.mozilla.org/en-US/firefox/channel/

A list of changes (not a list of bugs resolved) there would do.
(In reply to Angelo Borsotti from comment #109)
> (In reply to Bobby Holley (:bholley) from comment #106)
> > It did. Maybe not loudly enough. But it's not clear what else we could do
> > there. We've sent mail to the enterprise working group, warned in the
> > console, flagged for a release note, and blake wrote a bunch of blog posts
> > about it. That code is still only on aurora, and several months from
> > shipping.
> 
> I the release note of Firebug 15 there is no mention of it:

It wasn't removed in FF15. It will be removed in FF17. The change in FF15 is explained at the end of comment 106.


(In reply to Hans Hokke from comment #108)

Those all sound like good ideas, Hans, especially the documentation and outreach. Are you (or anyone else) interested in helping out on that?
(In reply to Bobby Holley (:bholley) from comment #110)
> (In reply to Angelo Borsotti from comment #109)

> It wasn't removed in FF15. It will be removed in FF17. The change in FF15 is
> explained at the end of comment 106.
> 

In FF15 when you open a page that contains a call to enablePrivilege
gets an error dialog box. In order to make it work you have to edit
manually the pref.js file (hoping that this works too, as Boris Zbarsky
wrote me referring to some limitations in file:// URIs, see bug https://bugzilla.mozilla.org/show_bug.cgi?id=790913.)
(In reply to Angelo Borsotti from comment #111)
> 
> In FF15 when you open a page that contains a call to enablePrivilege
> gets an error dialog box. In order to make it work you have to edit
> manually the pref.js file (hoping that this works too, as Boris Zbarsky
> wrote me referring to some limitations in file:// URIs, see bug
> https://bugzilla.mozilla.org/show_bug.cgi?id=790913.)

I don't see this. No problems using enablePrivs in 15 at all. As I mentioned in Comment 81 :

>> * Your error console (there has been a deprecation warning since Firefox 7,
>> see bug 668030)

> I see no evidence of this warning in 15.0.1 Win7/64. 
> Confirmed in 16/beta.  
> 15.0.1 saves a file from js code using enablePriv just fine, whereas 16 fails to save and the only error reported (in firebug and native error console) is that a var in my code is undefined (no doubt due to enablePrivilege being kneecapped - I'll need to check further).

Maybe it's dependent on which actual APIs are used?  I'm saving files locally from webpages served via file: protocol.
(In reply to Bobby Holley (:bholley) from comment #110)
> Those all sound like good ideas, Hans, especially the documentation and
> outreach. Are you (or anyone else) interested in helping out on that?
Of course  I am prepared to help out. I am afraid I may not be the right person though, because I am just new to this and my technical knowledge and my oversight on the documentation and dependencies are very limited.
I'd like to formally request that the Mozilla foundation review this carefully with their ESR lifecycle in mind. As of right now, the plan is for the next ESR version of Firefox (17.0.0) to be released on November 20th, which is two months from tomorrow. This deprecation to a major public API went in to Firefox 15, about a month ago. This is a very poor behavior in terms of extended support releases. Enterprise applications built with Firefox in mind will have only three months to re-engineer, requalify and deploy a new version of their applications (or create a Firefox extension to mitigate this lack).

I'd like to strongly recommend that, for the sake of sanely providing an upgrade path for ESR users, this deprecation should last through Firefox 18, not Firefox 17. The net result there would be that the ESR version of Firefox 17 would still have this feature available (but deprecated) and enterprise applications would then have a full year to develop their next-generation solution.

To back this up with a real-world example[1], Firefox is the target and supported browser for the web interface to the FreeIPA Linux Domain controller. The FreeIPA WebUI relies on the ability to use the enablePrivilege() routine in order to facilitate automatic configuration of the Kerberos settings needed to achieve GSSAPI single-sign-on to the WebUI. This UI is used both by domain administrators as a primary console for managing the domain as well as for users to perform self-service tasks. FreeIPA is in use at a number of high-profile sites, and losing the ability for Firefox to auto-configure the settings necessary to connect to it would be a significant hit to usability.

Having read through this BZ as well as BZ #757046, it is clear to me that this change will have a significant impact on enterprise web applications, FreeIPA being just one example. So once again, I implore you to extend the deprecation phase through the next ESR cycle to ease this transition for users and administrators of web applications.

[1] Full disclosure: I am a Red Hat employee who has worked as a developer on the FreeIPA project.
(In reply to Stephen Gallagher from comment #114)
> I'd like to formally request that the Mozilla foundation review this
> carefully with their ESR lifecycle in mind. As of right now, the plan is for
> the next ESR version of Firefox (17.0.0) to be released on November 20th,
> which is two months from tomorrow. This deprecation to a major public API
> went in to Firefox 15, about a month ago. This is a very poor behavior in
> terms of extended support releases. Enterprise applications built with
> Firefox in mind will have only three months to re-engineer, requalify and
> deploy a new version of their applications (or create a Firefox extension to
> mitigate this lack).

The API has been deprecated for over a year, and we've been communicating this in the error console, over email lists (including the Enterprise WG). The formal notification to the EWG went out in june (per bug 757046 comment 13), seven months before the EOL of ESR10 (unless I'm mistaken - this isn't my area of expertise). That seems like plenty of time.

> I'd like to strongly recommend that, for the sake of sanely providing an
> upgrade path for ESR users, this deprecation should last through Firefox 18,
> not Firefox 17. The net result there would be that the ESR version of
> Firefox 17 would still have this feature available (but deprecated) and
> enterprise applications would then have a full year to develop their
> next-generation solution.

It would also require us to support enablePrivilege for another year and a half. This requires significant engineering effort, and puts users at risk. See Blake's blog post for more details.

Anyway, this is just my opinion as developer who maintains this code. I don't sit on the EWG, though I certainly spend a lot of my time maintaining esr10. ;-)

Bugzilla isn't really the place for this kind of formal request, so maybe bring it up with the EWG and/or mkaply? Again, my response only represents Mozilla as an organization to the extent that our rules and traditions give me some degree of purview over the code I maintain. I won't be offended if you go over my head. :-)
(In reply to Bobby Holley (:bholley) from comment #115)
> (In reply to Stephen Gallagher from comment #114)
> > I'd like to formally request that the Mozilla foundation review this
> > carefully with their ESR lifecycle in mind. As of right now, the plan is for
> > the next ESR version of Firefox (17.0.0) to be released on November 20th,
> > which is two months from tomorrow. This deprecation to a major public API
> > went in to Firefox 15, about a month ago. This is a very poor behavior in
> > terms of extended support releases. Enterprise applications built with
> > Firefox in mind will have only three months to re-engineer, requalify and
> > deploy a new version of their applications (or create a Firefox extension to
> > mitigate this lack).
> 
> The API has been deprecated for over a year, and we've been communicating
> this in the error console, over email lists (including the Enterprise WG).
> The formal notification to the EWG went out in june (per bug 757046 comment
> 13), seven months before the EOL of ESR10 (unless I'm mistaken - this isn't
> my area of expertise). That seems like plenty of time.
> 

In my opinion, even if such a message was sent out the ERG, this wasn't a sufficient communication to let application developers know that they needed to change the behavior. The first time that this came to my attention was this week, as some of my colleagues were testing the FreeIPA negotiation auto-config and suddenly discovered that it no longer worked. They only learned why when they decided to enable the debug logs.


> > I'd like to strongly recommend that, for the sake of sanely providing an
> > upgrade path for ESR users, this deprecation should last through Firefox 18,
> > not Firefox 17. The net result there would be that the ESR version of
> > Firefox 17 would still have this feature available (but deprecated) and
> > enterprise applications would then have a full year to develop their
> > next-generation solution.
> 
> It would also require us to support enablePrivilege for another year and a
> half. This requires significant engineering effort, and puts users at risk.
> See Blake's blog post for more details.
> 
> Anyway, this is just my opinion as developer who maintains this code. I
> don't sit on the EWG, though I certainly spend a lot of my time maintaining
> esr10. ;-)
> 

Please believe me, I understand completely the support load that this would drop on you (I maintain my share of security software for Fedora/Red Hat).

> Bugzilla isn't really the place for this kind of formal request, so maybe
> bring it up with the EWG and/or mkaply? Again, my response only represents
> Mozilla as an organization to the extent that our rules and traditions give
> me some degree of purview over the code I maintain. I won't be offended if
> you go over my head. :-)

Agreed. I am currently approaching the EWG with this. Thank you for your consideration.
As some people were complaining but not acting, I decided to write a bug which aims to implement a way to access the local file system from web content (but also with some huge barriers). See Bug 797443 for the proposal. 

Stephen Gallagher, would this solve your problem? 

As for those who think my proposal is too tedious for accessing the local FS, I suggest them to query a local Node.js server instead (e. g. see jsDAV for a complete WebDAV implementation, allowing to write such a server with just a few lines) or write their own addon (which cannot be hosted on AMO). 

Does anybody need an API besides local file system access? 

I hope this will end the discussion.
(In reply to Florian Bender from comment #117)
> Stephen Gallagher, would this solve your problem? 

No, we're not looking for filesystem access, but rather the capability to set certain options in the Firefox configuration on the user's behalf related to Kerberos configuration.

Basically, we want the user to be able to click and accept our web application adding its domain to the network.negotiate-auth.delegation-uris and network.negotiate-auth.trusted-uris config options.

We have been investigating an alternative approach where we are going to instead provide a Firefox extension on the web application instead. The user will be prompted to install it the first time they browse to the application.
(In reply to Florian Bender from comment #117)
> As some people were complaining but not acting, I decided to write a bug
> which aims to implement a way to access the local file system from web
> content (but also with some huge barriers). See Bug 797443 for the proposal. 

I read it and to respond fully would take some time.  However, briefly...

You mentioned "web content" - if by that you mean "stuff served via http from a web server" then no, that's not what I've been "complaining" about.  The big change here is that stuff served via file: will fail, too.  THAT is the pertinent complaint (IMO).  

Associated with that is the poor communication of this change - there will be people and organizations that rely on enablePrivs for the daily operation of their apps who, by doing "the right thing" (i.e. upgrade firefox) find their app no longer works.  That's bad. Very bad.  It matters not that there is an error/warning printed to the log - I dev in firefox ALL DAY ALL WEEK and didn't see it.  I don't know ANY users who look in the error log.

> As for those who think my proposal is too tedious for accessing the local
> FS, I suggest them to query a local Node.js server instead 

If by that you mean http (and not a node.js server somehow magically consumed in a plugin) then no, that's not a solution.  I want to open a browser on my desktop and run a local file (html/js) and save data to a local file. LOCALFILE -> BROWSER -> LOCALFILE. To me, that was what XPCOM was originally designed to do (win a war on the desktop via the browser - mozaic/netscape back then - yes, I was there!). 

I'm no security expert but I don't see the difference between opening/saving local files in MS Word compared to the browser (which just happens to offer the file protocol).  The attack surface, I believe, is pretty much the same.  Both types of document may contain risky code.  If I'm wrong, please tell me how so.

Thanks
I need guidance on what needs to be documented and how to use it here. I simply don't have the time to research this properly, so any help would be appreciated.
(In reply to Eric Shepherd [:sheppy] from comment #120)
> I need guidance on what needs to be documented and how to use it here. I
> simply don't have the time to research this properly, so any help would be
> appreciated.

I think it's mostly about removing any documentation that might suggest using enablePrivilege. That may have already been done though. Maybe Jesse knows more?

Hans may have been working on a migration guide - not sure how far that got.
(In reply to Bobby Holley (:bholley) from comment #121)
> I think it's mostly about removing any documentation that might suggest
> using enablePrivilege. That may have already been done though. Maybe Jesse
> knows more?

No it hasn't been done and that's why Eric is looking into it.

Had "whoever" got the docs straight sooner rather than later, it would have saved some (if not all) the tears caused by this mess.  

Credit where it's due, one tweet to Eric and he got right on it.
(In reply to Russ from comment #119)
> I don't see the difference between opening/saving
> local files in MS Word compared to the browser
I totally agree.

I developed a little local app that generates a HTML report that needs to launch a script when clicking on a button. I have no way to do this any more!

I see no reason to not be allowed to give some privileges to a local page that is already installed on your machine. The mechanism could be allowed for local files only.
Quick FYI (email me off thread if interested to collaborate): I've gotten an alpha/beta version working of what I hope could become a GENERIC add-on to allow escalation of privileges to users at their discretion without requiring developers to deal with packaging files and leaving open the possibility of cross-browser support. Named for its functionality, as well as in honor of the recent 25th anniversary of The Princess Bride (hopefully not to its dishonor, anyways), as "As You Wish".

Have a few kinks to work out, especially when the user refuses site permission, it currently sometimes fails, but you can get it to work, esp. after a refresh and then without problems after each privilege requested on a page is approved. The SDK-based add-on code has a few demos you can try locally (at your own risk--though you can see the source code to confirm for yourself that it is ok).

https://builder.addons.mozilla.org/package/155676/latest/

Currently supports api-utils's xhr, url, file and addon-kit's clipboard, but easy to add more (at least it seems to be working for what I've tried as shown in the demos). (Am eagerly awaiting iframe srdoc/sandbox to try making an HTML5 full-fledged web browser!)

THAT BEING SAID, I would be most appreciative of a security review, if not toward getting accepted to AMO, then at least I would hope to make sure the add-on is not endangering users beyond that for which they are giving permissions. I am rather in the dark about the full details of the security issues at hand, but I think I've at least written some fairly clean code which I hope others may be able to build on. I would also appreciate explanations of what is wrong or even irremediable. Thanks very much!
Awesome work Brett!

Jorge, can we get someone from the AMO review team to spare some cycles to look at this? Whether or not we take this on AMO, I think it would be worthwhile to give Brett some feedback here.
Well done Brett!

What should a web page do to get the privileges?
I appreciate the nice support, everybody.

I'd recommend taking a look at the demos (following the link above doesn't auto-install the extension, so you can safely browse samples there).

But here's one:

// Cross-domain access (sync request for demo purposes only)
AsYouWish.requestPrivs('xhr', function (xhr) {
   var x = new xhr.XMLHttpRequest();
   x.open('GET', 'http://mozilla.org/', false);
   x.send(null);
   alert(x.responseText);
});

Should cause a notification warning you of the dangers, and then if you accept (not the default), it should perform the requested task.

I started out injecting just a function, but to try to get rid of __exposedProps__ warnings (though still getting them to some degree), I went with an object (IIRC, I couldn't get it to work with a function).

I hesitate to elaborate here too much on examples though because I hope the final API can be decided on after a full opportunity for testing and consultation (presumably off list somewhere), as besides the function naming, there are also questions about whether to make it synchronous as in CommonJS (or ECMAScript import?) or async as in requireJS, and whether to name these identically to SDK (e.g., "clipboard" is clearly more cross-browser friendly than "addon-kit/clipboard", but need to be able to map clearly).
Brett: I have some comments on your add-on I'll send by email that you'll need to address if you want this on AMO, and should probably address regardless. I haven't had a chance to look over it thoroughly, but it seems like a useful model overall.

I think there are probably limits to the kind of privileges we can and should allow this add-on to grant if it's to be hosted on AMO, though. In particular, the model we currently have for web apps is that only packaged, local apps can request certain permissions, and I think for things like filesystem access, we'd at least a preliminary step, such as adding the site to a whitelist, before it can even request such privileges.
@Kris: Much appreciated, thanks! Look forward to the feedback! I'm particularly vexed by the apparent loss of reference to DOM nodes that is giving the "can't access dead object" errors upon refusal to allow privileges and then refresh the page.

As far as hosting on AMO, that sounds to me like that could be quite a good compromise. But since the preference indicating a whitelist would presumably be accessible in about:config, and subject, to social programming anyways (though with a good many more hoops than even installing a third-party add-on), how about also allowing a general boolean pref as well whereby the current behavior (allowing websites to freely request access) becomes possible when set?

Regardless of whether they were in the right or not, similar behavior has existed in IE via ActiveX, including in corporate settings, and that doesn't even require an add-on to enable (and again, in Firefox itself, one can already visit sites to download addons with full privs, allowable by default no less--thankfully, since that is, I feel, in the spirit of the open web whereby Firefox is not attempting to constrain where applications built for it can be deployed and enjoyed).

Since the whole idea is to gain privileges which can't be found in regular web apps, I'm comfortable applying this constraint on privileges for all behaviors by default, thereby I hope relieving someone from having to decide which ones can be enabled by default (unless you have some in mind to offer by default).

As far as the UI for adding sites to the whitelist, I figure maybe something like IE's Compatibility View options in the main menu might work.

But just want to make sure the final decision-makers are comfortable with this approach first before I go ahead with this whitelisting behavior.
(In reply to Brett Zamir from comment #129)
> I'm particularly vexed by the apparent loss of reference to DOM nodes that is
> giving the "can't access dead object" errors upon refusal to allow
> privileges and then refresh the page.

See bug 695480 and http://blog.kylehuey.com/post/21892343371/fixing-the-memory-leak.
I wouldn't have a problem with a hidden preference to disable the whitelist, but allowing websites to request particularly dangerous privileges without a whitelist by default is not something I think we could accept. As for websites being able to install add-ons without being whitelisted, you're right that it is possible now, but it wasn't always, and it's likely that in the near future the AMO install process is going to get simpler while the non-AMO install process gets more complicated, for similar security reasons.
Sounds great about default whitelist with about:config option to alter or disable whitelist. So it would be ok then for the UI to allow adding to a whitelist, but not to disable the whitelist in an options dialog?

As far as websites installing add-ons without being whitelisted, I am glad to know that the rules are not to be applied in an arbitrary way indefinitely.
Maybe the whitelist could apply directory or site wide, but pages would need to ask for one-time permissions...
Beyond my other comment just now, by giving me an inch here, you've encouraged my ambitions. :) 

Why not apply this add-on's kind of functionality by default in Firefox, Thunderbird, etc., and actually encourage it as the default method at AMO itself? The default behavior could be to solely whitelist AMO "addons" in some approved site namespace (e.g., https://addons.mozilla.org/en-US/HTML5Plus/approved/myAppInsideASandboxedIframe.html ), whereby the "addons" are simply HTML5 apps (with or perhaps even without offline manifests?) obtained from a website, similar, if I understand it correctly, to how the Marketplace can package up HTML5 sites.

Besides making the process more friendly, there would be no net change of security, as the site would be limited by default to AMO though, I'd also hope that non-approved sites (or an experimental section of pages at AMO), could also, in a similar manner as we have been discussing, and without needing to get their users to install an add-on, request privs of the user if their site is first added by the user to a whitelist (e.g., through about:config, or if the whitelisting is considered not desirable to be available in the UI by default, through an add-on which could expose the whitelist preference to user modification). This ought to also facilitate implementation of the 3rd-party installation tightening you mentioned as remote XPI installation could be deprecated entirely in favor of this new approach, thereby increasing security, while still allowing for a built-in means of enabling third-party add-ons.

Here are some of the benefits I can see:

1) Let people write privileged addons using familiar standard HTML5, modified with just one extensible custom global which could in the future be standardized if other browsers showed interest. Maybe it could start with a moz prefix, so that client-side libraries could be written today to allow future adaptation of the API if needed without hopefully needing to modify any code in the future upon standardization except the library code.

2) Allow web content creators to host the app at their own site without making special packaging. I really believe you may see a lot wider participation in "addon" development, if you can lower the barrier this one step further. If someone can start an addon, adding just one feature they need in their app, by reading a quick blog post, with no need for manifests, XPI, blah blah, and then being able to be guided to submit their app at AMO simply by providing the URL of their app, I think it will open up add-on development dramatically on this "Web+" (web + (reviewable, restartless add-on-like) privileges).

3) Allow debugging to be done on one's own site rather than say at the Addons Builder site, though it would be cool if there could be some open REST API or the like (maybe with a client-side API as with BrowserID) to allow the addon to ask itself to provide a credentialed update for incremental unapproved versions to the Builder site, as well as an API to request review for the add-on (or delete itself, etc.). This would also allow alternative web-based IDEs to handle local development yet have access to rapid submission for review at AMO as with the builder site--without the cruft of downloading some custom non-JavaScript (i.e., Python) build environment.

4) Allow such "addon" users the ability to either have the addons packaged up as XPI files or the like, but also be able to unpack them as regular HTML (treated, however, as though hosted at the given domain as far as resolution of links, etc.) to be able to modify source files on their file system in the tradition of Firefox's hackability. Again, no need for understanding of file packaging--just hacking HTML/CSS/JS (though maybe including HTML5 offline manifests).

5) Would allow the same development language and deployment process to work for regular websites, Marketplace apps, and add-ons. Besides simplifying development and code availability in more environments, this could allow the Marketplace in turn to work with such officially approved privileged apps, or by option, non-approved ones.
While I haven't gotten to implementing the whitelist, nor a means of requesting multiple privs in one request (nor am I requiring https yet), I think I have fixed all bugs (besides a relatively minor one when two separate pages requesting privs are loaded around the same time). (Thanks Jesse, for the reference on leaks which helped me overcome them.)

However, though I see from the docs at https://developer.mozilla.org/en-US/docs/XPConnect_wrappers#__exposedProps__ that __exposedProps__ is supposed to be mandatory as of FF 17, I am able to overcome the issue for now when returning plain privileged objects, but in cases where privileged functions/constructors are returned by my chrome code for use by the user (e.g., XMLHttpRequest) and the content page user invokes the constructor and seeks to access the return object's properties, the user will get deprecated notices (though again, for now at least it works).

I tried to wrap such functions so that their return objects would also be wrapped by __exposedProps__, but this received errors.

Is there any way to work around this for the future? Is it indeed going to be necessary to work around this?

Thanks very much.
Firefox downloaded release 17, and now my apps that used enableprivilege
no longer work, not even setting the proper user preferences.
Unfortunately, NO WORKAROUND EXIST, except the app the Brett Zamir is
implementing.
It is sad to see this bug classified as "RESOLVED", and to note that the
Firefox team is dismissing this problem as if it did not exist.
I have found a workaround: http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/16.0b6/win32/en-US/
has still the installer for release 16. I have downloaded it -- DISABLED
THE AUTOMATIC UPDATING -- and solved the problem. I will stay with release
16 until a viable solution will appear.
(In reply to Brett Zamir from comment #135)
> However, though I see from the docs at
> https://developer.mozilla.org/en-US/docs/XPConnect_wrappers#__exposedProps__
> that __exposedProps__ is supposed to be mandatory as of FF 17, I am able to
> overcome the issue for now when returning plain privileged objects, but in
> cases where privileged functions/constructors are returned by my chrome code
> for use by the user (e.g., XMLHttpRequest) and the content page user invokes
> the constructor and seeks to access the return object's properties, the user
> will get deprecated notices (though again, for now at least it works).

It's likely that this is working only because we currently make an exception for jetpack addons for this stuff. You should generate the appropriate __exposedProps__ object for anything you expose to content. Alternatively, you can do some tricky stuff with proxies like we do in SpecialPowers. See the ExposedPropsWaiverHandler stuff here:

http://mxr.mozilla.org/mozilla-central/source/testing/specialpowers/content/specialpowersAPI.js#196

> Is there any way to work around this for the future? Is it indeed going to
> be necessary to work around this?

Going forward, all chrome objects exposed to content will need __exposedProps__, otherwise they'll be opaque (though functions can still be called, and arrays will still permit indexed access).
(In reply to Angelo Borsotti from comment #137)
> I have found a workaround:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/16.0b6/win32/en-US/
> has still the installer for release 16. I have downloaded it -- DISABLED
> THE AUTOMATIC UPDATING -- and solved the problem. I will stay with release
> 16 until a viable solution will appear.

There are known and published security vulnerabilities in Firefox 16 (especially 16.0b6, which doesn't have the security fixes we released in 16.0.1 and 16.0.2). You're putting yourself at risk by doing this. If you need enablePrivilege for something, I'd suggest keeping two copies of Firefox around.
(In reply to Bobby Holley (:bholley) (on vacation though Dec 4) from comment #139)
> If you need enablePrivilege for something, I'd suggest keeping two
> copies of Firefox around.

Or using ESR10, which is still supported for the next two cycles.
Brett Zamir,

Can you provide a code for write a local file like

 AsYouWish.requestPrivs('file', function (fileObj) {
            alert(
                fileObj.read('/root/anoop.txt')
            );

        }, errBack);
I have now completed work for:
1) All previous bugs of any real significance, e.g., requiring refreshes, dead DOM objects, __exposedProps__ warnings (solved via a few small changes to specialpowersAPI.js , so thanks again for that)
2) Added an options dialog with site whitelist ability
3) Allowed multiple simultaneous object requests

For questions on the SDK itself (whose API the addon is simply passing on to websites conditionally), you might visit https://forums.mozilla.org/addons/viewforum.php?f=27 . 

For usage questions or bugs of AsYouWish itself, or API suggestions, please report to me personally or better, at https://github.com/brettz9/asyouwish/issues . You may also see some of my future hopes for this (and background) at https://github.com/brettz9/asyouwish/ .

So unless there are any objections, I'd like to submit this now to AMO. :)
I have installed the AsYouWish addon (the Crome branch, actually) and
had been able to make my apps properly (the ones that had been broken
by the removal of enableprivileges in FF 17).
Awesome addon.
I fully support its inclusion in AMO.
As an additional argument for eventual default inclusion in Firefox--it would seem to me (from my very limited understanding of plugins) that such a standardized API ight overcome the use case for plugins entirely--while ensuring that users were duly informed about attempts to make privileged access requests...
Have published version 0.2 at https://github.com/brettz9/asyouwish , and if people can access it, on AMO, at https://addons.mozilla.org/en-US/developers/addon/as-you-wish/ .

* Replace unstable select option expansion with CSS-based tooltip
* Add and wrap remaining high level APIs and add own custom x-namespaced-simple-storage API (a subset of simple-storage requiring specification of a namespace to allow sites to develop joint APIs without any site being the owner)
* Listen to all option changes, e.g., if made from Firefox's own dialog
* Remove hard-coding of https in allowed protocols for those who wish to disallow
* applied i18n for ability to switch options HTML file (no way to detect current locale from the SDK?)
* add getDefautPrivs() method for introspection on possible privs
* Update demos to contain try-catch within callbacks

The only main feature I can see left to implement (besides perhaps wrapping more low-level APIs) is support for launching site-registered URLs at start-up (courtesy of a page-worker) so these sites could, for example, add an add-on bar icon without the user needing to load the site manually on each browser load.

One fairly minor issue I ran into in testing this is that on line 72 of /resources/addon-sdk/lib/sdk/widget.js (as at https://github.com/mozilla/addon-sdk/blob/master/lib/sdk/widget.js#L72 ) , the ok() method of the Panel object had problems with user-created wrapped Panel's being added to a (user-created wrapped) widget.

As a workaround, instead of "v instanceof panels.Panel", I duck-typed for "v.show" and it worked fine, but is there any way the dependencies on instanceof can be removed to avoid such issues for wrapped objects (so I don't have to make a custom SDK bundle)? Perhaps your SpecialPowers tests would have the same problem too, Bobby? Anyways, it doesn't appear it would be too demanding of a change to be made... (I'd make a pull request, if I knew what preferences you might have on how to do this.)
Can you file a new bug about this Brett and CC me with the question? This isn't really the best place to discuss it. :-)
As per Bug 823790, Bobby has asked me to track AsYouWish in a new separate bug which I have added as Bug 823811 (and which I have described as being aimed at issues related to interaction with the SDK/Core).

Please, however, continue to add bug reports for the addon itself at https://github.com/brettz9/asyouwish/issues/ .

With these, I think those wishing to go the AsYouWish route can now stop spamming this issue entirely. Thank you.
Blocks: 984012
Depends on: 1365199
No longer depends on: 1365199
You need to log in before you can comment on or make changes to this bug.