This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Initially I have reported this here ( https://github.com/w3c-webmob/installable-webapps/issues/52 ) but since the group has closed I'm forwarding it to here. Here is a copy of the original report: At Mozilla's bugzilla a discussion woke up ( https://bugzilla.mozilla.org/show_bug.cgi?id=424875 ) to make XMLHttpRequest useable for web-applications on the file-protocol without requiring the server to enable CORS. At the end of the current discussion I got the idea of a system-wide configuration file to solve this issue: - It contains permissions it grants to web-applications (for example specific/all permissions on specific files/directories). - Installer invoked by the user can write the required permissions for their web-application to this file. Also the user can enter manually entries if he wants. - A site launched unintentionally on the file-protocol can't do evil things since it wouldn't be listed in this file. This would help to make web-applications launched on the file-protocol (for example installed by upstream-installers on desktop-PC's) to be more competitive.
We won't be adding new features to XMLHttpRequest. Certainly none that complex. Sorry.
It is not only about XMLHttpRequest (there was just no suitable component so I have choosen XHR from the list). This feature is about to make web applications more competitive to native applications as currently they are very limited. For example it is not possible to do network requests to fetch any data (and CORS does not solve this problem as it gives the control to the service provider).
That is intentional. Please study the web's security model.
Thats where this feature request comes in mind as it would securely give permissions to web-applications. Or is it not intended to make web-applications competitive compared to native system applications?
Sure, but there are limits on what we can do. There's no good UI answer or software for https://annevankesteren.nl/2015/02/same-origin-policy unfortunately.
I have now read the link but fail to see the problem here or why an UI to ask the user is needed. Let's say the user downloads some_fancy_webapp, executes its installer and it installs into /usr/share/some_fancy_webapp and registers itself in the file proposed by this ticket let's say in /etc/www/webapp-permissions.txt and gives itself all permissions. The user starts now the web-application in the browser as file:///usr/share/some_fancy_webapp/index.html and the web-application would now be able to do for example easily cross-origin XHR because of the entry its installer made into /etc/www/webapp-permissions.txt. Since the web-application was installed explicitly by the user he trusts it the same as he would with a native system application. There is no need to ask the user with an UI for extra permissions anymore and since he trusts the web-application it can safely do for example cross-origin XHR. Am I missing something specific here why this should not be possible? Because having the ability to write local web-applications that are cross-platform and run in managed code would be a nice opportunity compared to writing them in a language that compiles to machine code.
A small ping, since I would really like to try to enhance something here. Based on the post above can you give me a use-case why this would be a problem? So I could think about it and maybe propose another solution or give up if I don't see another one. Or have I maybe indeed found a way to make this at least for trusted file:// applications possible?
The problem with that model is that it requires installation. And if something requires installation and needs to be trusted it needs to be distributed through a store. And stores are antithetical to the web.
Shops are no requirements especially for desktop-PC's but I'm seeing what you are pointing to. But that means that you are telling me that there is no intention to make installable web-applications competitive to native system applications. This is a valid decision but I want to go sure that I'm not missing something here.
There's no such thing as an installable web application. Also, please stop reopening the bug. This is not an issue with XMLHttpRequest.
(In reply to Anne from comment #10) > There's no such thing as an installable web application. Applications written in HTML, JavaScript, etc. that are running in a webbrowser on the file:// protocol. Basically an interpreted application that gets installed by an installer. There is nothing that spectacular about it (except that such applications feel like being in a DRM-hell implied by SOP which tries this ticket to solve for this case which is unfortunately not wanted). (In reply to Anne from comment #10) > Also, please stop reopening the bug. I'm not reopening it anymore if this is a problem. I wanted just to avoid that this ticket stands in idle again for several months. I'm especially interested in solving this issue as I have developed a web-application as hobby the last few years but am hitting too much SOP limitations. I thought developing applications this way could be nice but I'm more and more inclined to port it to C as I see less hope here. (In reply to Anne from comment #10) > This is not an issue with XMLHttpRequest. Just to remember you on an older post: (In reply to sworddragon2 from comment #2) > It is not only about XMLHttpRequest (there was just no suitable component so > I have choosen XHR from the list).