User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.77 Safari/535.7 Steps to reproduce: document.getElementById('iframeXXX').contentDocument.XX tried to reference the inner content of an iframe. Actual results: access denide error. Expected results: should have had access.. same code worked in firefox 9 and earlier and works in other browsers.

Please provide a public URL or reduced test case that exhibits this issue. Any errors reported in the error console?

I've seen the problem in Yahoo Mail site. Open one of your emails, and look at the message body - it is in another iframe. This line of code was able to access it until FF 10: document.getElementsByTagName('iframe')[0].contentDocument.body There is no error in the console, but through firebug I seethe error Error: Permission denied to access property 'body'

OK, news - the fault is not firefox 10, but sdk 1.4. I switched back to sdk 1.3 and the same code works.. another feature of 1.4 is the console - nothing is written to it.. not with console.log and not console.err.

Which SDK? Should we close out this bug report?

I don't think we can close it.. it didn't work with sdk 1.4. I switched back to sdk 1.3 and the same code works.

Which SDK?

I'm missing something? the add-on SDK 1.4, the one you download here: https://addons.mozilla.org/en-uS/developers/builder

Could you link to or attach your addon's code so we can see what exactly is going wrong? The console logging problems should be fixed by updating your version of the SDK to 1.4.3 (or next week's 1.5 release).

Hi, the relevant code is here: https://addons.mozilla.org/en-US/firefox/files/browse/144316/file/resources/jid0-aatdxo87qhqpnf4yu5yegrjlwtc-at-jetpack-enlocked-data/yahoo-common.js#top in the getYahooMsgMap() method. You will see that: $('iframe.om-views-messagepane').contents() returns the error mentioned above (with the access denied) in SDK 1.4, but running that code in SDK 1.3 works fine.

Alex, can you take a look at this and see what is going on?

Hi, this is the same issue as in bugs: 715755, 722232, 723434. I saw that it will be targeted in SDK 1.6? but in the mean while, Firefox 11 will not work with SDK 1.3 which will cause our add-on to stop working..

Yes, it is most likely due to the security elevation, where content script now execute with exactly same priviledges that the webpage you attached to. In your case, it seems to be cross domain iframe content access. Can you describe your usecase? I have no idea how Yahoo mail is written, but do they have iframes on a different domain?!

If they are on same domain and it fails, it may only be related to bug 715755 [fixed, hopefully cherry picked in 1.6]. If they are and it still fails with git master version, it is another unknown bug that will have to be fixed. If they are in different domains, it is a more tricky question. We would like to give again more priviledges to content scripts but we are still unsure if it is a good idea and we are still discussing how we can give them more.

Hi, no - it's not in the same domain. the message in Yahoo is taken from another domain, for exmple: http://36ohk6dgmcd1n-c.c.yom.mail.yahoo.net (the page domain is: http://us.mg5.mail.yahoo.com/). You thought it was a good idea in SDK 1.3 :) + Chrome and IE allows it.. My main concern is Fierfox 11 - which our add-on will stop working when compiled with SDK 1.3.. is there any chance for you guys to allow FF11 working with SDK 1.3 or issuing a fix for SDK 1.5 to allow the cross-domain?

SDK 1.3 may still be compatible with FF11, we programatically bump firefox version supports. You can give it a try by modifying /python-lib/cuddlefish/rdf.py file here: https://github.com/mozilla/addon-sdk/blob/master/python-lib/cuddlefish/rdf.py#L162-168 Interesting, IE has some content script feature? Do you have any link to a related documentation? For the context, jetpack content scripts are different from chrome ones. We are closer to Greasemonkey ones. Mainly because of the `unsafeWindow` global that can easily leak content script priviledges to the webpage. This attribute is still experimental and we might get rid of it. We are still missing a clear picture between raw JS access and enhanced content script capabilities.

I don't have proper documentation for it, but I can tell u that we write it in c# and install it as an IE dll add-on.

The iframed website needs to add the 'X-Frame-Options:ALLOWALL' header to declare itself embeddable in Chrome and Firefox ( unsure about other browsers ). Otherwise, you get an error. In your case, if you're not Yahoo and Yahoo doesn't explicitly allow embedding, iframes aren't the right solution.

Alex, I am using the SDK from master as of yesterday, and I have a problem accessing iframe content on the same domain. The main document is on www.cnn.com. The iframe source is on ads.cnn.com I assume this should work. Same domain, different sub-domain.?

Gordon: because the security model is the same as web content, you may need to set document.domain to the top level domain for that to work.

Hi, I don't know if i'm asking in the rigth thread. I'm new in firefox extension development I'm trying to access to an iframe content on SAME domain: - the main document is http://www.juntadeandalucia.es/educacion/vscripts/centros/listado_int.asp - the iframe source is http://www.juntadeandalucia.es/educacion/vscripts/centros/tab/datos_centro_curact.asp?COD=04000134. I haven't any problem when I access it from firebug, but when I try to do it from my firefox extension, I allways have "undefined" value: - iframe.contentDocument is a HTMLDocument - iframe.contentDocument.body is a HTMLBodyElement - but iframe.contentDocument.body.childNodes.length = 0 - iframe.contentDocument.body.getElementsByTagName("div").length = 0 I can't access to the iframe content from my extension. There is no error in the console nor on firebug. It is a sidebar extension and I'm testing it on firefox 12.0 Sorry for my English

Hi again, We've just tested SDK 1.7, and the problem I described in this thread still exists. I keep getting "Permission denied to access property 'XXX'" on every attempt to access the inner iframe.. You guys mentioned in the past that maybe it will be addressed in 1.6, but... So, any suggestions? My add-on is broken.. (and works fine in Chrome / Safari / IE) Thanks Asi

(In reply to asi from comment #21) > You guys mentioned in the past that maybe it will be addressed in 1.6, but... The "maybe addressed in 1.6 or 1.7" thing was if the page and the iframe were served from the same domain, but you said in comment 14 that they were from different domains.

right.. so, is it going to be addressed with different domains?

I say this with the utmost respect--but for the love of God, can people PLEASE stop dumbing down extension development by all these restrictions?! Pretty soon, all that it is going to be left in extension development is getting to put an icon in the status bar which opens a plain vanilla website! With cache manifests, etc. now in place in HTML5, the only good reason in my book for writing an extension is to get elevated privileges! After suffering through the uncertainties of enablePrivilege being deprecated without any cross-browser replacement (Bug 546848)--which by the way mentioned that its replacement would be writing an extension--and seeing that unsafeWindow at least existed for the time being in the SDK, I tried it out--and ran into this bug (my use case is allowing iframes with a given attribute to have their own independent navigation controls, as requested by me in Bug 618354). And if I take the time to go back to XUL extensions, will I be able to get this access? Also, rather than waiting for a ready event, is there some XBL code for iframe by which I can modify it directly (without getting into C++), as I'd be happy to try to make a patch if I can be pointed in the right direction. Thanks for your help and patience with my impatience.

(In reply to Brett Zamir from comment #24) > I say this with the utmost respect--but for the love of God, can people > PLEASE stop dumbing down extension development by all these restrictions?! I agree with this to a certain extent... unfortunately the other side of the story is if we put all the responsibility on the addon developers/reviewers to write _safe_ addons, the likelihood of unsafe addons will be a lot bigger (not to mention of the extra work the security part might take). In the end that will hurt both the reputation of the browser and the extensions in general... That being said we are trying to find the balance by giving as much freedom as possible without risking extremely critical security leaks. Content-scripts with system rights was just too much risk to the point that we decided it is plan wrong. But I agree that we need to address all the problems that has occurred. > And if I take the time to go back to XUL extensions, will I be able to get > this access? Also, rather than waiting for a ready event, is there some XBL > code for iframe by which I can modify it directly (without getting into > C++), as I'd be happy to try to make a patch if I can be pointed in the > right direction. No. The security layer is deep in c++ (not the easiest part of it...) And usually it's not that simple to just hack something together to get this working, the real difficulty is change it in a way that does not break anything else... I don't know enough about XUL addons, maybe someone else can answer your question. I've landed a patch that should address this problem to a certain extent, you can extend the privilege of your content-script with an array of origins you want to have same origin access to. For google chrome you can even use wild cards when you specify these origins. I'm actually considering implementing something similar too, but for that I will need some good use cases to pass it through. (one very strong argument I already have, google chrome extensions have it and I would love to support browser extensions with similar API on all browsers...) So please anyone would love to see wild card supports, let me know, and give me some good use cases :)

One use case would be integrating with a provider that has a large infrastructure and a deep & abiding love for subdomains and relatively dynamic use of them for hosting. It's telling that some of the examples in this and other bugs involve yahoo, because this is a pretty accurate description of how yahoo rolls out infrastructure. If I look at how most companies like Yahoo or Google provide embeddable content though, they tend to stick with a canonical / top-level domain ( www.flickr.com or maps.google.com ) for the embed code's iframe src.

There is much confusion about the removing the netscape privilege manager. And, there is absolutely no information posted anywhere to assist current users of the proprietary Mozilla XPCOM calls to migrate. First I am experiencing a bug, mozilla bug 808361, that is manifest loading error and potentially related to the removal of the netscape privilege manager. So two questions. 1) I go the mozilla link below that is the reference for nsIProcess which I use extensively. https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIProcess This document was last updated Aug 15, 2012. There is no mention of being deprecated, there is no mention of do not use, etc. The code snippet example shows the Component.Class call with no netscape privilege manager call before it. This implied to me that Mozilla was registering this library of calls in the chrome (which it is) and then allowing these calls to used directly from javascript with no additional security. This does not appear to be the case 2) If I enter a Component.Class and an alert box displaying the return value in the Error Console "Code:" line and click evaluate, it works perfectly and returns "xpconnect wrapped nsIProcess" yet when I enter the same code in javascript within an HTML document I get "Error: TypeError: Components.classes is undefined." The alert box title is "javascript application" just like it would be for my javascript code. Why does the Error Console have direct access to the XPCOM extensions while a user's does not? To me this even appears as a security breach since someone can use the Error Console to hack into a webpage via the chome. As I stated there is little if any help out there right how. I posted no MozillaLine and have received no responses in 24 hours. Any assistance, direction would be appreciated including what Mozilla documents are valide.

(In reply to PJAL from comment #27) > call before it. This implied to me that Mozilla was registering this > library of calls in the chrome (which it is) and then allowing these calls > to used directly from javascript with no additional security. This does not > appear to be the case 'chrome' here means the highest possible privilege a particular javascript code can ever get. No site will ever get it, only browser code or reviewed addons can use the chrome API. Just imagine the scenario that regular sites are allowed to use this API and can freely put files on your computer and even execute them... That would be simply a security disaster. > > 2) If I enter a Component.Class and an alert box displaying the return value > in the Error Console "Code:" line and click evaluate, it works perfectly and > returns "xpconnect wrapped nsIProcess" yet when I enter the same code in > javascript within an HTML document I get "Error: TypeError: > Components.classes is undefined." The alert box title is "javascript > application" just like it would be for my javascript code. Why does the > Error Console have direct access to the XPCOM extensions while a user's does > not? To me this even appears as a security breach since someone can use the > Error Console to hack into a webpage via the chome. Error console does have chrome privileges. But that just means you as the user on your own machine can do whatever you want (and not an untrusted possibly "evil" web site!). When you say you can hack into the site, note that you just hack into the local version of the site that is loaded into your browser, others will not experience your changes. So I'm not sure I understand your security concern here. > > As I stated there is little if any help out there right how. I posted no > MozillaLine and have received no responses in 24 hours. Any assistance, > direction would be appreciated including what Mozilla documents are valide. All these information I shared here are available in some docs, but of course it's never easy to gather the exact piece of information you are looking for... As you can see sooner or later your questions are answered, but we must keep a balance between helping out people with questions and implementing actual features / fixing bugs. As a rule of thumb, it's better if you specify exactly what are you trying to achieve and not just throwing in some technical issue, because then we might able to help you to find a solution to your real problem. Finally this is completely off-topic please file another bug for this if you have more questions.

Wild cards would help the 1Password add-on. Currently, our content script is injected into every frame in order for us to provide support for login forms that are loaded via iframes such as Disqus or GetSatisfaction (to name just two off the top of my head). If we could have wild card access for cross-domain-content, we could inject our script only once at the top frame and still be able to provide the same functionality with a smaller memory footprint and theoretically better performance to boot.

My interest in wild cards would be that it could enable arbitrary monitoring of any frame's independent navigational history. My use cases for that are: 1) To develop a browser-in-a-browser--e.g., to build an alternative browser which was accessible from a URL (ala my AsYouWish add-on which allows websites to request SDK privileges) but could go full screen to handle tabs, browser history, etc. 2) To provide a workaround for Bug 618354 (to allow sites to add markup which would automatically add independent navigation controls around their iframes). One could use this, for example, to show wiki pages dedicated to a particular paragraph of a book (e.g., for commentary) whose (iframe-internal) links could be clicked in place to leave the wiki domain to visit those resources no matter the domain and then use independent back-and-forward buttons which were relevant to the specific iframe currently being navigated rather than to the whole window history (e.g., clicking "back" shouldn't send one back in some other iframe). I'm not 100% sure wildcards would be sufficient to listen in on the events enough to build an iframe history (e.g., listening for unload events, etc.), but I imagine it should at least be one step in that direction.

I have quite a few concerns about the wildcards approach to be honest. It is very difficult to do it right, based on what I read about the google chrome version, the implementation is error prone, and gives very little comfort to add-on reviewer in my opinion compared to a principal that let's you just access every origin but does not give you chrome privileges. Bobby: So this would be an intermediate principal between nsExpandedPrincipal and the system principal, that subsumes everything but the system principal. It's a flag for add-on reviewers to take their time with the review, but they don't have to worry about leaking out chrome privs. What do you think?

(In reply to Gabor Krizsanits [:krizsa :gabor] (moving to Berlin: in and out for a few weeks) from comment #31) > Bobby: So this would be an intermediate principal between > nsExpandedPrincipal and the system principal, that subsumes everything but > the system principal. It's a flag for add-on reviewers to take their time > with the review, but they don't have to worry about leaking out chrome > privs. What do you think? I'm not really wild (no pun intended) about it. IMO universal XSS is just as bad as remote code execution (a la http://xkcd.com/1200/ ). So any such principal just gives everyone a false sense of security ("it's not chrome, so we need to be less careful with it"). IMO people should either use system principal or an explicitly-enumerated nsEP. I might be ok with wildcards up to the eTLD (a la document.domain), but I'd need to see pretty compelling examples to justify the complexity cost.

(In reply to Bobby Holley (:bholley) from comment #32) > I'm not really wild (no pun intended) about it. IMO universal XSS is just as > bad as remote code execution (a la http://xkcd.com/1200/ ). So any such > principal just gives everyone a false sense of security ("it's not chrome, > so we need to be less careful with it"). IMO people should either use system > principal or an explicitly-enumerated nsEP. I might be ok with wildcards up > to the eTLD (a la document.domain), but I'd need to see pretty compelling > examples to justify the complexity cost. Wild card support scares me because of the exact same false sense of security problem. At lest the universal XSS gives the red flag for reviewers that something dangerous is going on. My problem is Comment 14. I don't see any sane way to wild card that... I do share your concerns I'm not too wild to jump into this project either, but it seems like a feature people want, others have it and we don't...

(In reply to Gabor Krizsanits [:krizsa :gabor] (moving to Berlin: in and out for a few weeks) from comment #33) > (In reply to Bobby Holley (:bholley) from comment #32) > > I'm not really wild (no pun intended) about it. IMO universal XSS is just as > > bad as remote code execution (a la http://xkcd.com/1200/ ). So any such > > principal just gives everyone a false sense of security ("it's not chrome, > > so we need to be less careful with it"). IMO people should either use system > > principal or an explicitly-enumerated nsEP. I might be ok with wildcards up > > to the eTLD (a la document.domain), but I'd need to see pretty compelling > > examples to justify the complexity cost. > > Wild card support scares me because of the exact same false sense of > security problem. At lest the universal XSS gives the red flag for reviewers > that something dangerous is going on. My problem is Comment 14. I don't see > any sane way to wild card that [*.yahoo.com, *.yahoo.net] would seem simple enough if we were allowing wildcarding. ... I do share your concerns I'm not too wild > to jump into this project either, but it seems like a feature people want, > others have it and we don't... Do we allow people to use system-principal-ed content scripts? If so, then we _do_ support it, just with all the associated red flags for reviewers.

(In reply to Bobby Holley (:bholley) from comment #34) > [*.yahoo.com, *.yahoo.net] would seem simple enough if we were allowing > wildcarding. Problem is yahoo might have quite a few domains all over the word like yahoo.hu, yahoo.de, etc. Also if they don't they can add any time breaking the addon anytime. Would be a big step forward though... > Do we allow people to use system-principal-ed content scripts? If so, then > we _do_ support it, just with all the associated red flags for reviewers. No we don't. The add-on can do XHR though, if it requires 'chrome' (that gives the sandbox access to Cu). But then you need to do continuous message based communication between the content-script and the chrome side of the add-on. But that still does not solve the problem that the content-script cannot access the inner iframe of the page.

(In reply to Gabor Krizsanits [:krizsa :gabor] (moving to Berlin: in and out for a few weeks) from comment #35) > No we don't. The add-on can do XHR though, if it requires 'chrome' (that > gives the sandbox access to Cu). Is anyone assuming that this is anything less than granting arbitrary code execution to the addon? I sure hope not, but I just want to make sure. > But then you need to do continuous message > based communication between the content-script and the chrome side of the > add-on. But that still does not solve the problem that the content-script > cannot access the inner iframe of the page. Yeah, IMO if we're going to support something like this (and I'm not saying we should), we should just have the content script run with system principal. Nothing else is really any safer.

(In reply to Bobby Holley (:bholley) from comment #36) > > Is anyone assuming that this is anything less than granting arbitrary code > execution to the addon? I sure hope not, but I just want to make sure. No, it's clear to everyone. > Yeah, IMO if we're going to support something like this (and I'm not saying > we should), we should just have the content script run with system > principal. Nothing else is really any safer. Interesting thought. Despite the xkcd comic I'm not fully convinced that giving full access to the system on top of universal XSS is a meaningless difference. But I see your stand point. In either case I would make COWs fully opaque. And let only structured cloning pass through the barrier. About the should part. Just to make it clear it's not that we are restricting anything currently... I mean old fashioned non-SDK based add-ons can just do whatever they want. Even jetpack add-ons once required chrome, can do whatever they want. We restrict content-scripts only, forcing add-on developer to be clever about these kind of problems, making reviewers job more difficult to decide if what these add-ons do are safe or not. The add-on itself can just enumerate all the windows and do whatever it wants with full chrome privs. The general concept is that only content-script 'should' interact with content directly. If we don't allow content-script to acquire more privs in these rare cases, some add-on will be forced to break this pattern. TL;DR: If we don't do anything, add-on developers will find a workaround, which will result a more complex code for the reviewers to judge about.

Sure. I understand we might want to provide a mechanism for content scripts to do privileged things to prevent people from hacking up their own solution in these situations. I'm just saying that I don't think there's enough added value to justify the code complexity (and, IMO, false sense of security) of a subsumes-content-but-not-system principal. If we allow this, we should just introduce a mechanism for system-principal-ed content scripts.

Yeah, I think you are probably right, thanks for the thoughts! I will suggest the system principal content-scripts as an option for these really-really extreme cases.

FWIW, jst and I discussed this today - if it would solve use cases, we think it would be fine to allow wildcarded nsEPs up to effective-TLD. People can enumerate [*.yahoo.com, *.yahoo.co.uk, *.yahoo.co.jp], etc.

(In reply to Bobby Holley (:bholley) from comment #40) > FWIW, jst and I discussed this today - if it would solve use cases, we think > it would be fine to allow wildcarded nsEPs up to effective-TLD. People can > enumerate [*.yahoo.com, *.yahoo.co.uk, *.yahoo.co.jp], etc. It certainly does, see Comment 26. Not sure how good is the value/complexity ratio of the feature... but I can imagine that it will be a valuable feature in some other cases too (apps). I assume *.yahoo.com is good for both http://yahoo.com and https://yahoo.com but not for other schemes, right?

(In reply to Gabor Krizsanits [:krizsa :gabor] from comment #41) > (In reply to Bobby Holley (:bholley) from comment #40) > > FWIW, jst and I discussed this today - if it would solve use cases, we think > > it would be fine to allow wildcarded nsEPs up to effective-TLD. People can > > enumerate [*.yahoo.com, *.yahoo.co.uk, *.yahoo.co.jp], etc. > > It certainly does, see Comment 26. Not sure how good is the value/complexity > ratio of the feature... but I can imagine that it will be a valuable feature > in some other cases too (apps). I assume *.yahoo.com is good for both > http://yahoo.com and https://yahoo.com but not for other schemes, right? I'd think so? Might be worth asking dveditz and blake what they think. Dan, Blake - Gabor is considering adding wildcarded nsExpandedPrincipals so that jetpack content scripts could subsume a wider set of content without using system principal. The wildcarding limit would be eTLDs, just like document.domain. I spoke with jst about this, and we think it'd be ok if it solved important use cases. What are your thoughts, both on the idea and the http/https issue?

Sorry, I'm not clear--does this proposal mean that a full-blown '*' will not be allowed? Please, please, say that it will! :)

(In reply to Brett Zamir from comment #43) > Sorry, I'm not clear--does this proposal mean that a full-blown '*' will not > be allowed? Please, please, say that it will! :) According to Bobby's proposal content-script would require chrome privilege for that. Which we might or might not want to support. Even if it will be supported there need to be a thorough review for the add-on, and a very good reason why it needs such a privilege. Personally, until someone can show me a very good reason why we should allow it I would stick to Bobby's proposal and not allow '*'. I'm not sure I understand your goals but the 'which allows websites to request SDK privileges' part sounds very scary to me. I don't think we ever want to let an add-on give extra privilege to random sites. In fact that's exactly what we always try to prevent on the first place. And I don't think that the chrome privileged content-script were a proper workaround for Bug 618354 either. Sounds very unsafe.

(In reply to Gabor Krizsanits [:krizsa :gabor] from comment #44) > According to Bobby's proposal content-script would require chrome privilege > for that. Which we might or might not want to support. Even if it will be > supported there need to be a thorough review for the add-on, and a very good > reason why it needs such a privilege. Personally, until someone can show me > a very good reason why we should allow it I would stick to Bobby's proposal > and not allow '*'. Yes. As explained above, '*' is tantamount to running the content script with system principal, which is its own discussion. > I'm not sure I understand your goals but the 'which allows websites to > request SDK privileges' part sounds very scary to me. I don't think we ever > want to let an add-on give extra privilege to random sites. In fact that's > exactly what we always try to prevent on the first place. And I don't think > that the chrome privileged content-script were a proper workaround for Bug > 618354 either. Sounds very unsafe. +1.

To clarify my two use cases (in comment 30): 1. While you may not wish to host such add-ons, I still hope you can allow developers to build restartless add-ons which do allow such as I am describing. As explained at https://etherpad.mozilla.org/ui-html , I would like to build my own browser using regular HTML--for prototyping, for providing a set of features that I'd like to see, in a manner I'd like to see, and which I know will be stable into the future, etc. If I can't do this directly, then I'd like to at least be able to build an add-on which allows sites to request to register themselves as extensions to my browser which can add HTML overlays and JavaScript which my add-on will cache and use to render its own browser. Yes, it could be potentially dangerous and requires trust of the developer--as with any full-featured browser--but in the spirit of Firefox being open-source and an open platform, I would hope I and other developers would not be prevented from building their own such browser, making use of the friendly SDK APIs for core functionality, but which did not require exe files, knowledge of C++, etc. to build the UI or its own custom functionality. If you don't want to host it at AMO, I can certainly accept that, but since you allow, in the spirit of openness, choice to your users to install third-party add-ons which could be risky, I'd hope you would allow the SDK to be as fully robust as the full XUL/XPCOM platform is, so developers are not forced to build non-restartless add-ons, use uglier APIs, or create their own custom loaders. 2. If you have multiple iframes on a page, and you click a link in one and then in the other, and then try to use Firefox's back button, it will always cause the 2nd clicked iframe to go back. There is no way to cause only the first one to go back (I listed my uses for this in no. 2 within comment 30). If I could listen in on any iframe with privileges, I'd be hopeful that I could monitor locationchange or unload events and such so as to build my own frame histories and thus be able to implement support for markup which could create independent navigation controls (such as frame-aware back and forward buttons) to surround each iframe. To be able to listen in on iframes within a document containing the markup requesting navigation controls and belonging to any domain, I'd need cross-domain privileges.

(In reply to Brett Zamir from comment #46) > To clarify my two use cases (in comment 30): > > 1. While you may not wish to host such add-ons, I still hope you can allow Oh... so if you don't want AMO to host your add-on I guess you have many options. While Mozilla is very open, you must understand that features that have use-cases only for you are not our highest priority, BUT there is nothing that holds you back to implement what you need yourself. You could just modify the SDK itself for example, or just implement your own SDK module, that can add chrome privileges to content-scripts. > If I can't do this directly, then I'd like to at least be able to build an > add-on which allows sites to request to register themselves as extensions to > my browser which can add HTML overlays and JavaScript which my add-on will > cache and use to render its own browser. I have no idea how to do this. > to install third-party add-ons which could be risky, I'd hope you would > allow the SDK to be as fully robust as the full XUL/XPCOM platform is, so The whole XUL/XPCOM platform is available from SDK based add-ons. You have to require chrome. There are no friendly API implemented for every XUL/XPCOM API but feel free to file a bug for request something you feel needed. Or you are also very welcome to implement them yourself. You must understand that we implement the APIs that are the most commonly used, if your use cases are not acceptable for security reasons, don't expect us to put time in implementing them. You also have to understand that while we let users make their choices, if you ever want to release an add-on on your own you, should keep in mind the safety of your users, you should feel responsible for them. > If I could listen in on any iframe with privileges, I'd be hopeful that I You can inject a content-script into every iframe independently that can listen to any events of that iframe and report back to the add-on in form of messages. Then the add-on itself can manage the rest. I think you should talk to SDK developers about the details on IRC in the #jetpack channel, I'm not an SDK developer myself and my knowledge about the SDK is limited.

The proposal to allow leading wildcards for expanded principals seems reasonable to me. About the http/https distinction, I don't see a way of enforcing it that won't simply result in forcing authors to add boilerplate to all of the uses without adding any additional value. So I think [*.yahoo.com,*.facebook.com] would give access to http{,s}://*{yahoo,facebook}.com -- does that match everybody else's expectations?

Seems reasonable, both to allow wildcard expanded principals (up to eTLD+1) and to assume the listed domains match http/https schemes and all ports. Not all schemes though. if you want to match something other than than http(s) ("the web") you should have to be explicit.

(In reply to Bobby Holley (busy) from comment #45) > (In reply to Gabor Krizsanits [:krizsa :gabor] from comment #44) > > According to Bobby's proposal content-script would require chrome privilege > > for that. Which we might or might not want to support. Even if it will be > > supported there need to be a thorough review for the add-on, and a very good > > reason why it needs such a privilege. Personally, until someone can show me > > a very good reason why we should allow it I would stick to Bobby's proposal > > and not allow '*'. > > Yes. As explained above, '*' is tantamount to running the content script > with system principal, which is its own discussion. What about adding an extended principal with [*]? Basically allowing access to all content but not to chrome.