It would be really nice to get rid of enablePrivilege. It's incredibly poor UX (popups asking a user to grant incomprehensible permissions), it has weird function-level scoping, and it has opaque privilege strings that make no sense to anyone. It also complicates security code a fair amount.
At the same time, it seems to be used a fair bit for intranet apps. Earlier today there was a brainstorming session about use cases for enablePrivilege, and we came up with the following:
1) Working around same-origin restrictions 2) Working around DOM security/privacy restrictions (things like getting the full path from a file input, or setting the value of a file input). 3) Enabling programmatic copy/paste in Midas 4) Cross-site XHR (a variant of #1) 5) Mochitests
First of all, are there other major classes of use cases we're missing?
If not, here's a possible course of action:
A) Do something with mochitests (move the relevant one to chrome tests, expose an object that allows running privileged code, whatever). B) Announce that we plan to remove this API in the release after Gecko 1.9.1. Possibly add a warning when it's used in 1.9.1. C) Do something about the other 4 use cases. The "something" should have only two levels of permissions: "normal sandbox website" and the equivalent of UniversalXPConnect. The intermediate privilege levels are more confusing than they're worth. D) Remove enablePrivilege after 1.9.1 is done, as well as removing signed jar code (which is really only used for enablePrivilege).
After a good bit of discussion, for item (C) we're thinking the answer is an extension. One concern is that making the extension (which must take input from untrusted content, obviously) secure is nontrivial. So what would be ideal is for us to expose a communications channel that such extensions could use and a way to have prefs specifying which sites can use the communications channel for a given extension. Alternately, the prefs could specify hostnames that are allowed to pass a chunk of script with privileges (something like evalOutsideSandbox()). Or something along those lines. The assumption is that intranet deployments can set preferences as needed, of course.
The open question are what form this communication channel or evalOutsideSandbox() functionality should take place. What's really needed, I think, is feedback on use cases and some discussion (and then a decision!) about how to make this work.
Ideally the solution we come up with should be simple enough to implement that we can do it for 1.9.1, to allow sites to start migrating to the new setup.
Thoughts?
Boris
P.S. Please respect the reply-to and followup-to and keep this on m.d.platform.
> First of all, are there other major classes of use cases we're missing?
I'm not clear on whether the proposed change only applies to calls to enablePrivilege in extensions or only in web pages, but Firebug calls it so it can use the MD5 hash function to compute a message digest for eval() buffers.
... > After a good bit of discussion, for item (C) we're thinking the answer > is an extension. One concern is that making the extension (which must > take input from untrusted content, obviously) secure is nontrivial. So > what would be ideal is for us to expose a communications channel that > such extensions could use and a way to have prefs specifying which sites > can use the communications channel for a given extension. Alternately, > the prefs could specify hostnames that are allowed to pass a chunk of > script with privileges (something like evalOutsideSandbox()). Or > something along those lines. The assumption is that intranet > deployments can set preferences as needed, of course.
> The open question are what form this communication channel or > evalOutsideSandbox() functionality should take place. What's really > needed, I think, is feedback on use cases and some discussion (and then > a decision!) about how to make this work.
Again I'm not clear on exactly what you need here, but Firebug 1.2 had to implement a complex scheme to allow web pages to write into the Firebug console without compromising the browser. A DOM element is written from the extension into the page, code is injected via a mixture of evalInSandbox() and script tags; then both sides set event handlers on the element to marshal the restricted subset method calls and arguments.
Conceptually the channel is fine and it works in practice (eventually). But the setup code has a jizillion failure modes, especially since we don't want to inject the channel in every page only when the user needs it (like your prefs I suppose).
Wouldn't you need something similar? If so, it would cool if we had a better way to achieve it.
John J. Barton wrote: > I'm not clear on whether the proposed change only applies to calls to > enablePrivilege in extensions or only in web pages
Extensions shouldn't need to call it at all, so this all only applies to code running in web pages.
> Conceptually the channel is fine and it works in practice (eventually). > But the setup code has a jizillion failure modes, especially since we > don't want to inject the channel in every page only when the user needs > it (like your prefs I suppose).
> Wouldn't you need something similar? If so, it would cool if we had a > better way to achieve it.
Yeah, your use case was mentioned in this context. I agree that it would be good to have a better solution for it, and it's worth having a separate thread about your requirements...
Dave Townsend wrote: > I trust you don't mean completely remove the signed jar checking > functions we have which are used to verify signed extensions as well.
Probably not, no. ;) I was more talking about removing certificate stuff from nsPrincipal, and so forth.
> 2) Working around DOM security/privacy restrictions (things like > getting the full path from a file input, or setting the value > of a file input). > 3) Enabling programmatic copy/paste in Midas > 4) Cross-site XHR (a variant of #1) > 5) Mochitests
> [...]
> C) Do something about the other 4 use cases. The "something" should > have only two levels of permissions: "normal sandbox website" and > the equivalent of UniversalXPConnect. The intermediate privilege > levels are more confusing than they're worth.
> After a good bit of discussion, for item (C) we're thinking the answer > is an extension.
I'd be curious to understand why that stuff doesn't belong in the core, given that it seems like there were be a large set of users for that group of things...
> Again I'm not clear on exactly what you need here, but Firebug 1.2 had > to implement a complex scheme to allow web pages to write into the > Firebug console without compromising the browser. A DOM element is > written from the extension into the page, code is injected via a mixture > of evalInSandbox() and script tags; then both sides set event handlers > on the element to marshal the restricted subset method calls and arguments.
> Conceptually the channel is fine and it works in practice (eventually). > But the setup code has a jizillion failure modes, especially since we > don't want to inject the channel in every page only when the user needs > it (like your prefs I suppose).
> Wouldn't you need something similar? If so, it would cool if we had a > better way to achieve it.
Absolutely. What firebug is doing is exactly what I had in mind when we discussed this.
Basically we should have a way for an extension to install some API into a page, and do it such that it is: * Simple! Should be as close to just providing a object or function from the extension that will be accessible by the webpage as possible. Security is the main limiting factor here. All the hoops that firebug currently has to jump through is not acceptable. * Secure Firefox should take care of most of the security stuff so that the extension can focus on functionality. Should be easy to get the functionality installed only on a limited set of sites, such as all intranet sites, or just a single site. * Reliable Should install the API early enough that it's always accessible from page script. We should reduce those 'jizillion' failure modes to something more manageable :)
> Dave Townsend wrote: >> I trust you don't mean completely remove the signed jar checking >> functions we have which are used to verify signed extensions as well.
> Probably not, no. ;) I was more talking about removing certificate stuff > from nsPrincipal, and so forth.
> Basically we should have a way for an extension to install some API into > a page, and do it such that it is:
Possibly related: webkit has a 'console' object intended to be compatible with Firebug's console. So in addition to "some API" we could consider "a particular API" (if for example the general case proves difficult). There is much distance between these really, since you can only do one thing safely with web-page objects in an extension: walk the property names down to primitives (getter controls needed). The only other operation you need is the ability to call a web page function in the web page (using the name you get from the property walk).
> * Simple! > Should be as close to just providing a object or function from the > extension that will be accessible by the webpage as possible. Security > is the main limiting factor here.
A global object/function would solve many problems. I didn't realize until recently that components can implement global objects. What I don't know is whether an extension could control the global object availability. We need the global to either exist whether or not Firebug (or another particular extension) was installed or we need the global existence to be controllable by the extension. Otherwise web pages can test the existence of the global to learn if the user has Firebug (or...) installed, but its none of their business. (I'm not enthusiastic about another round of Firebug console implementation, but this global object avenue seems promising).
> All the hoops that firebug currently has to jump through is not > acceptable. > * Secure > Firefox should take care of most of the security stuff so that the > extension can focus on functionality. > Should be easy to get the functionality installed only on a limited > set of sites, such as all intranet sites, or just a single site. > * Reliable > Should install the API early enough that it's always accessible from > page script. We should reduce those 'jizillion' failure modes to > something more manageable :)
These last two bits are the two cases I mentioned above: "always available" or "under control of extension". The case we don't want is "available whenever the extension is installed".
Dan Mosedale wrote: >> After a good bit of discussion, for item (C) we're thinking the answer >> is an extension.
> I'd be curious to understand why that stuff doesn't belong in the core, > given that it seems like there were be a large set of users for that > group of things...
A key point here is that the user experience for enabling expanded privileges for a site needs to clearly indicate that they are installing software on their computer and that this software can then do whatever it wants.
We already have such UI in the form of the extension manager, so we want to leverage that. What the extension does is still an open question. One possibility is that it just sets some prefs that core code then reads. Intranet deployment could set those prefs directly during install of the browser, of course.
That still raises the question of how the site gets its chosen script communicated to whatever can run things with privileges. I don't think we ever want to be running privileged code on the untrusted JSContext, so one way or another the code to be run needs to migrate elsewhere. Whether the code is put into the extension itself, or passed as a string to some sort of evalOutsideSandbox() method or something else is also still open.
> That still raises the question of how the site gets its chosen script > communicated to whatever can run things with privileges. I don't think > we ever want to be running privileged code on the untrusted JSContext, > so one way or another the code to be run needs to migrate elsewhere. > Whether the code is put into the extension itself, or passed as a string > to some sort of evalOutsideSandbox() method or something else is also > still open.
> -Boris
I've made my opinion of evalInSandbox() known, so I'd vote for "extension itself" with evalOutsideSandbox() as an option that the extension may choose. (BTW some example code would make these issues clearer....)
John J. Barton wrote: > I've made my opinion of evalInSandbox() known, so I'd vote for > "extension itself" with evalOutsideSandbox() as an option that the > extension may choose.
The problem with the "extension itself" approach is that it increases complexity of the extension, as well as increasing the complexity of the safe channel we need to expose, since the page needs to be able to indicate to the extension which code to run.
> (BTW some example code would make these issues clearer....)
Mochitest is a good source of examples. Grep it for EventUtils.js or enablePrivilege calls, and ask yourself how you'd do that sort of thing with an extension and how you'd go about securing that extension.
Boris Zbarsky wrote: > John J. Barton wrote: >> I've made my opinion of evalInSandbox() known, so I'd vote for >> "extension itself" with evalOutsideSandbox() as an option that the >> extension may choose.
> The problem with the "extension itself" approach is that it increases > complexity of the extension, as well as increasing the complexity of the > safe channel we need to expose, since the page needs to be able to > indicate to the extension which code to run.
Ok, you could just say you already decided on the other solution ;-)
>> (BTW some example code would make these issues clearer....)
> Mochitest is a good source of examples. Grep it for EventUtils.js or > enablePrivilege calls, and ask yourself how you'd do that sort of thing > with an extension and how you'd go about securing that extension.
> -Boris
By design of the safe channel the only operation the page will allowed is some possibly elaborate version of "print()" right? The web page can't run any methods outside its context; the extension can't run any methods of the page from outside. So the extension is going to fill the sandbox with some methods that ultimately yield strings. It has to take care that these methods do not expose data to the page, eg other pages state, users settings? The web page, over joyed to see these methods, will call them with data from the page. When the extension gets control again it can take strings out of the box. It still has to take care to not to eg write the strings to disk or another page etc.
Safe but not very powerful, works for Firebug console, but I don't get how you can allow the other cases and still be safe.
John J. Barton wrote: > Ok, you could just say you already decided on the other solution ;-)
Nothing's been firmly decided on that front. I'm just explaining what the tradeoffs are.
> By design of the safe channel the only operation the page will allowed > is some possibly elaborate version of "print()" right?
That depends...
> The web page can't run any methods outside its context; the extension can't run any > methods of the page from outside.
The latter is false, and the former may be false depending on the approach we take here.
> So the extension is going to fill the > sandbox with some methods that ultimately yield strings.
That's one approach to the situation, yes.
> It has to take > care that these methods do not expose data to the page, eg other pages > state, users settings?
Not necessarily, since the fundamental assumption is that this setup should allow selected pages to do things they normally can't do.
> Safe but not very powerful, works for Firebug console, but I don't get > how you can allow the other cases and still be safe.
"safe" means that you don't allow sites other than the ones the user trusts to cause code to be executed with privileges (either directly or on their behalf).
> Sure. Or we can keep an nsIPrincipal that represents a signed cert, but > assert in various places about such certs being used in security checks.
> I'd love to know (offline, if you want) what you use this principal for, > other than the prettyName.
Currently yes we just get the prettyName off the principal (with some comment from you that maybe that isn't the best option) and it is displayed in the add-on install confirmation dialog. Then after download of course we verify that the contents of the xpi haven't changed since being signed.
There are bugs around requesting improvements here, such as bug 278629 which wants to include access to the full signing certificate from the install dialog.
Dave Townsend wrote: > There are bugs around requesting improvements here, such as bug 278629 > which wants to include access to the full signing certificate from the > install dialog.
Right. So in all cases, you'd be OK with just an nsIX509Cert or an nsISupports that you can QI to that interface.
In any case, removing code here is a lower priority than switching to a new setup for expanded privileges, so I'd sort of like to refocus discussion on use cases for expanded privileges and suggestions for how they should work.
We are developing a rather large signed remote XUL application, and we are making a fairly intensive use of enablePrivilege (~ 300-400 occurences in our code base). That's the reason why, after Boris pointed out this discussion, I take the opportunity to give some feedback on the subject.
I speak on behalf of all the developers involved. First a little overview of what we're doing :-)
The application's entire interface is implemented in XUL. Of course, it requires the user to be authentified. A signed jar containing the main window is generated upon login and it references stylesheets (not included in the jar as of today) that map the apprioriate tags to our 50-100 custom bindings we implemented. Those bindings are fetched from the server one by one "on demand" (by using the -moz-binding CSS property, which contains the URL of a php script). They are always processed server-side, using php, as they depend on the user connected (lang, permissions, ...). The processing often only consists in using our i18n translation mechanisms, but sometimes we complete the implementation section of the bindings (adding methods, fields, properties...).
The reason we interact with XUL this way won't be discussed here - choices made more than three years ago, we use this technology since 2005 and have several hundreds of customers for the product.
To come back to the subject, among the first 4 use cases of enablePrivilege mentionned in the first post, we are directly concerned by 1,2,3 (our Richtext Editor is based on Midas and the same origin issue often arises through the use we make of iframes). We don't do cross site XmlHttpRequest as far as the core of our product is concerned, but customer specific developement might use this feature.
We also access some XPCOM interfaces here and there: - for file uploads (nsIMultiplexInputStream, nsIFileInputStream, nsIBufferedInputStream, ...) - for writing/accessing local files (nsILocalFile, directory service) - all drag and drop operations in general inside the interface (nsIDragService).This is a crucial point for us. - inIDOMUtils to perform operation on content of iframes displaying html content generated by the CMS, and fetch the result of the transformations. - ...
90% of the time we ask for UniversalXPConnect and a few UniversalBrowserWrite here and there. I suppose you get the idea :-)
Our overall feeling is that the existing privilege API is confusing and agree that it's scoping policy is a bit strange. Also, since firefox 1.5 and the clear(and legitimate) concern that you guys showed in improving FF security, the number of places where we had to use enablePrivilege increased, while we have the feeling that given the nature of our application our clients aren't directly concerned by most of the exploits.
We are developing and deploying a very specific application: we host it, configure client machines to access, have full control on the code (server-side and client-side). It is our responsibility to handle its security and protect it against exploits. Of course, FF should be as secured as possible - but ideally it should not prevent us from doing accessing some functionalities, for that specific application, hosted on a specific domain.
If my interpretation of Boris' first post is correct, going towards the possibility to set preferences "somewhere" to handle privileges would be nice as long as people doing remote XUL rather than extensions don't get left over.
This post might be a bit vague, but, well - the application is not open source and there are a certain number of points that can't be discussed on a public list. There are probably very few projects using XUL the way we do :-)
Franck, thank you for sending in this feedback! It's quite useful.
fstauf...@gmail.com wrote: > To come back to the subject, among the first 4 use cases of > enablePrivilege mentionned in the first post, we are directly > concerned by 1,2,3 (our Richtext Editor is based on Midas and the > same origin issue often arises through the use we make of iframes)
OK.
> We also access some XPCOM interfaces here and there:
This is something we'd like to avoid exposing to web content, basically. Looking at your use-case, would using chrome over https basically work for you instead of using signed jars over https? Sine you control both client and server, this might be an acceptable option. That said, see below.
> - for file uploads (nsIMultiplexInputStream, nsIFileInputStream, > nsIBufferedInputStream, ...)
Would the new HTML5 APIs for getting file data once the user selects a file in an <input type="file">, combined with XMLHttpRequest fill this need?
> - for writing/accessing local files (nsILocalFile, directory service)
Do you need this to just save information your app uses, or to create arbitrary files? Could you use DOM storage for the former?
> - all drag and drop operations in general inside the interface > (nsIDragService).This is a crucial point for us.
Would the HTML5 drag/drop API (which I believe will be implemented in Firefox 3.1) fill this need? If not, what are the shortcomings it has?
> - inIDOMUtils to perform operation on content of iframes displaying > html content generated by the CMS, and fetch the result of the > transformations.
I'd be curious to find out more about the use cases here.
> We are developing and deploying a very specific application: we host > it, configure client machines to access, have full control on the code > (server-side and client-side).
Does this application have to run inside the browser, or could it run as a Prism app, say?
> If my interpretation of Boris' first post is correct, going towards > the possibility to set preferences "somewhere" to handle privileges > would be nice as long as people doing remote XUL rather than > extensions don't get left over.
I have to be honest... Given that you control both sides of the table, why can't your code be an extension? It could even behave the same from the user's point of view as far as looking like a tab in Firefox, if that's desired. I realize the code is already written; I'm wondering whether there are technical reasons it couldn't work.
> There are probably very few projects using XUL the way we do :-)
We've heard of quite a number sorta anecdotally (nor precisely as you do, with on-the-fly jar generation, but similar after that point)... We've just had a hard time getting hold of the people involved.
Again, I really appreciate the feedback; knowing what people are doing and in what ways existing (or upcoming) web specifications don't address their needs is very helpful in this context.
Boris Zbarsky wrote: > First of all, are there other major classes of use cases we're missing?
I just stumbled on this thread. I realize it is a couple of months old but here are my thoughts.
I manage a set of about 30 signed xul/jar intranet apps.
In all cases, when needed I use UnivercalXPConnect, mostly because that works and documentation is (or at least was at the time) sparse on what priv to ask for.
I have been developing the code since 2004 and there may be changes in the interim that I am not aware of.
Here is a list of how I use enablePrivilege:
1) Assigning a custom view to a <tree>. This is critical functionality. Without custom tree views I would not be using XUL. I long for the day when something similar makes its way into HTML but I am not holding my breath.
2) Creating 'atoms' for use in a custom tree view (getCellProperties and getRowProperties). I have never understood why styling should need protection.
3) Opening windows to other XUL or HTML applications. This code really bothers me: var blocked = PB.getBoolPref("dom.disable_open_during_load"); if(blocked) PB.setBoolPref("dom.disable_open_during_load",false); win = window.open(url,name,features); if(win) win.focus(); if(blocked) PB.setBoolPref("dom.disable_open_during_load",true); Manipulating browser preferences in this instance is scary.
4) Copy a string to the clipboard. Usually transferring a grid of data as a string in a form that a spreadsheet will understand.
5) Logging a message to the error console, Only needed for debugging. The js debugger is flaky and to my knowledge firebug does not work in jar files.
6) Populating the HTML content of an iframe. I had problems with this last Spring. I think those problems were fixed in FF3.0 and I need to review this to see if the privs are still required.
7) Printing the content of an iframe. iframe.contentWindow.print().
8) JSON encode/decode. My understanding is FF3.1 will have an alternate API and will not require privs.
9) iframe.contentWindow.scrollTo(0,pos);
10) drag and drop
11) Some mechanism for file upload. My current hack is to embed an iframe with an HTML file upload form.
One of my pet peaves is the dialog that pops up the first time the user runs an app. If they decline permission, the will never be able to use any of the apps. There is no Options GUI for revisiting this decision. Short of creating a new profile, I am not even certain how do to this now.
> Boris Zbarsky wrote: >> First of all, are there other major classes of use cases we're missing?
> I just stumbled on this thread. I realize it is a couple of months old > but here are my thoughts.
> I manage a set of about 30 signed xul/jar intranet apps.
> In all cases, when needed I use UnivercalXPConnect, mostly because that > works and documentation is (or at least was at the time) sparse on what > priv to ask for.
> I have been developing the code since 2004 and there may be changes in > the interim that I am not aware of.
> Here is a list of how I use enablePrivilege:
> 1) Assigning a custom view to a <tree>. This is critical functionality. > Without custom tree views I would not be using XUL. I long for the day > when something similar makes its way into HTML but I am not holding my > breath.
> 2) Creating 'atoms' for use in a custom tree view (getCellProperties and > getRowProperties). I have never understood why styling should need > protection.
> 3) Opening windows to other XUL or HTML applications. This code really > bothers me: > var blocked = PB.getBoolPref("dom.disable_open_during_load"); > if(blocked) > PB.setBoolPref("dom.disable_open_during_load",false); > win = window.open(url,name,features); > if(win) win.focus(); > if(blocked) > PB.setBoolPref("dom.disable_open_during_load",true); > Manipulating browser preferences in this instance is scary.
> 4) Copy a string to the clipboard. Usually transferring a grid of data > as a string in a form that a spreadsheet will understand.
> 5) Logging a message to the error console, Only needed for debugging. > The js debugger is flaky and to my knowledge firebug does not work in > jar files.
> 6) Populating the HTML content of an iframe. I had problems with this > last Spring. I think those problems were fixed in FF3.0 and I need to > review this to see if the privs are still required.
> 7) Printing the content of an iframe. iframe.contentWindow.print().
> 8) JSON encode/decode. My understanding is FF3.1 will have an alternate > API and will not require privs.
> 9) iframe.contentWindow.scrollTo(0,pos);
> 10) drag and drop
> 11) Some mechanism for file upload. My current hack is to embed an > iframe with an HTML file upload form.
Couldn't you use <input type="file"> and then grab the data using input.files.item(0).getAsDataURL() and send that data using XMLHttpRequest?
> One of my pet peaves is the dialog that pops up the first time the user > runs an app. If they decline permission, the will never be able to use > any of the apps. There is no Options GUI for revisiting this decision. > Short of creating a new profile, I am not even certain how do to this now.
Bryan White wrote: > 1) Assigning a custom view to a <tree>. This is critical functionality. > Without custom tree views I would not be using XUL. I long for the > day when something similar makes its way into HTML but I am not holding > my breath.
OK. That doesn't need dynamic per-JS-stackframe permissions, though, right?
> 2) Creating 'atoms' for use in a custom tree view (getCellProperties and > getRowProperties). I have never understood why styling should need > protection.
Because the API is moronic. We should just fix this.
> 3) Opening windows to other XUL or HTML applications. This code really > bothers me: > var blocked = PB.getBoolPref("dom.disable_open_during_load"); > if(blocked) > PB.setBoolPref("dom.disable_open_during_load",false); > win = window.open(url,name,features); > if(win) win.focus(); > if(blocked) > PB.setBoolPref("dom.disable_open_during_load",true); > Manipulating browser preferences in this instance is scary.
This looks like you're trying to bypass the popup blocker, no? Why do you need to do that, exactly?
> 4) Copy a string to the clipboard. Usually transferring a grid of data > as a string in a form that a spreadsheet will understand.
Yeah, this is a problem; untrusted content shouldn't be able to get at the clipb oard. OK.
> 6) Populating the HTML content of an iframe. I had problems with this > last Spring. I think those problems were fixed in FF3.0 and I need to > review this to see if the privs are still required.
Yeah, that's odd. This is quite doable without privileges, in general
> 7) Printing the content of an iframe. iframe.contentWindow.print().
An iframe you don't control, right?
> 8) JSON encode/decode. My understanding is FF3.1 will have an alternate > API and will not require privs.
Indeed.
> 9) iframe.contentWindow.scrollTo(0,pos);
Again, if the subframe is something you don't control, correct?
> 10) drag and drop
Firefox 3.1 is shipping an implementation of the HTML5 d&d API. Does that address your use cases?
> One of my pet peaves is the dialog that pops up the first time the user > runs an app.
How would you like the setup to look here, in terms of the user basically allowing you to do whatever you want with their computer?
There are definitely things below for which there is no current alternative if you don't have extra privileges. And that will always be the case.
I think that part of our plan here was to create better APIs to enable extensions to inject APIs into pages of their choice. The pages could then call into these APIs to perform the operations they need.
So for example an extension could add an API to a set of pages that exposes the ability to access the clipboard.
Boris Zbarsky wrote: > Bryan White wrote: >> 1) Assigning a custom view to a <tree>. This is critical >> functionality. Without custom tree views I would not be using XUL. >> I long for the day when something similar makes its way into HTML but >> I am not holding my breath.
> OK. That doesn't need dynamic per-JS-stackframe permissions, though, > right?
>> 2) Creating 'atoms' for use in a custom tree view (getCellProperties >> and getRowProperties). I have never understood why styling should >> need protection.
> Because the API is moronic. We should just fix this.
>> 3) Opening windows to other XUL or HTML applications. This code >> really bothers me: >> var blocked = PB.getBoolPref("dom.disable_open_during_load"); >> if(blocked) >> PB.setBoolPref("dom.disable_open_during_load",false); >> win = window.open(url,name,features); >> if(win) win.focus(); >> if(blocked) >> PB.setBoolPref("dom.disable_open_during_load",true); >> Manipulating browser preferences in this instance is scary.
> This looks like you're trying to bypass the popup blocker, no? Why do > you need to do that, exactly?
>> 4) Copy a string to the clipboard. Usually transferring a grid of >> data as a string in a form that a spreadsheet will understand.
> Yeah, this is a problem; untrusted content shouldn't be able to get at > the clipb oard. OK.
>> 6) Populating the HTML content of an iframe. I had problems with this >> last Spring. I think those problems were fixed in FF3.0 and I need to >> review this to see if the privs are still required.
> Yeah, that's odd. This is quite doable without privileges, in general
>> 7) Printing the content of an iframe. iframe.contentWindow.print().
> An iframe you don't control, right?
>> 8) JSON encode/decode. My understanding is FF3.1 will have an >> alternate API and will not require privs.
> Indeed.
>> 9) iframe.contentWindow.scrollTo(0,pos);
> Again, if the subframe is something you don't control, correct?
>> 10) drag and drop
> Firefox 3.1 is shipping an implementation of the HTML5 d&d API. Does > that address your use cases?
>> One of my pet peaves is the dialog that pops up the first time the >> user runs an app.
> How would you like the setup to look here, in terms of the user > basically allowing you to do whatever you want with their computer?
> There are definitely things below for which there is no current > alternative if you don't have extra privileges. And that will always be > the case.
> I think that part of our plan here was to create better APIs to enable > extensions to inject APIs into pages of their choice. The pages could > then call into these APIs to perform the operations they need.
> So for example an extension could add an API to a set of pages that > exposes the ability to access the clipboard.
I like this direction a lot, in part because while I'm wearing my messaging hat, I can imagine various ways to enhance people's messaging experiences on the web using this approach.
Boris Zbarsky wrote: > Bryan White wrote: >> 1) Assigning a custom view to a <tree>. This is critical >> functionality. Without custom tree views I would not be using XUL. >> I long for the day when something similar makes its way into HTML but >> I am not holding my breath.
> OK. That doesn't need dynamic per-JS-stackframe permissions, though, > right?
My recollection is this was not always the case but I do not know when it changed.
>> 3) Opening windows to other XUL or HTML applications. This code >> really bothers me: >> var blocked = PB.getBoolPref("dom.disable_open_during_load"); >> if(blocked) >> PB.setBoolPref("dom.disable_open_during_load",false); >> win = window.open(url,name,features); >> if(win) win.focus(); >> if(blocked) >> PB.setBoolPref("dom.disable_open_during_load",true); >> Manipulating browser preferences in this instance is scary.
> This looks like you're trying to bypass the popup blocker, no? Why do > you need to do that, exactly?
It is possible this is not needed. I remember having problems at one time with windows not opening. I quick test shows it is not now needed. I need to do a more through test.
>> 7) Printing the content of an iframe. iframe.contentWindow.print().
> An iframe you don't control, right?
>> 9) iframe.contentWindow.scrollTo(0,pos);
> Again, if the subframe is something you don't control, correct?
I just tried both the above without the privs and it seems to work. Perhaps it did not at some point in the past.
>> 10) drag and drop
> Firefox 3.1 is shipping an implementation of the HTML5 d&d API. Does > that address your use cases?
I have not looked at HTML5 d&d yet. I hope to soon.
>> One of my pet peaves is the dialog that pops up the first time the >> user runs an app.
> How would you like the setup to look here, in terms of the user > basically allowing you to do whatever you want with their computer?
It is not how it looks. The problem is if the user does not grant the access it does not ask again and there is no good way to get it to ask again. The remembered decision does not show up anywhere in the Options stuff (at least that I can find).
