5 ms·

I think the parent knows exactly what CORS is and you're misunderstanding. There's no fundamental reason browsers can't be configured to not send the user's co

I think the parent knows exactly what CORS is and you're misunderstanding. There's no fundamental reason browsers can't be configured to not send the user's cookies when making XHR requests, and in fact there's already a mechanism for a webpage to ask certain kinds of CORS requests to be "anonymous": The "anonymous" keyword means that there will be no exchange of user credentials via cookies, client-side SSL certificates or HTTP authentication https://developer.mozilla.org/en-US/docs/Web/HTML/CORS_settings_attributes https://developer.mozilla.org/en-US/docs/Web/HTML/CORS_setti... Because of this arbitrary technical limitation, if a webpage wants to make a request to to an arbitrary URL equivalent to what a native app could ("anonymous"/cookies-free, of course), it'd have to make an AJAX (or WebSockets) call to an intermediary server running native code to do so, which is what the parent is referring to as a "CORS proxy". -- > > * Open TCP and UDP sockets > There are websockets, which aren't the same, I'll admit. Frankly, I'm not sure I want my web pages to be able to arbitrarily open TCP/UDP sockets. (I don't really want my native apps to be able to on whim, either…) Sure, whatever, you don't want arbitrary native apps being able to open arbitrary TCP/UDP sockets, but you're missing the point. We both agree that it should be possible to, somehow, download an FTP client and somehow configure security settings so that it can work, right? (Restricted ports and filesystem or chroot or whatever.) There's no fundamental reason browsers can't have the same security framework so that you can open an FTP client web app and somehow configure browser security settings so that it can work, right? -- > > * Barometric sensors > You mean like current air pressure? Are there common devices out there with these? (None of my computing devices have anything like this, for example.) According to XKCD, "a lot of new Android phones" have a barometer sensitive enough to "actually see the pressure difference between your head and your feet." https://what-if.xkcd.com/64/ https://what-if.xkcd.com/64/ (Obviously that's not an authoritative reference, but I think it's sufficiently addresses your question, and it's a fun article.) > (and what would I want this for?) What a great question, I'd love to know too!!

bzbarsky 11y ago
What you characterize as an "arbitrary technical limitation" is there for a good reason, unfortunately: even anonymous requests made by the _browser_ are not equivalent to anonymous requests made by the _server_ the web page came from. That's because the browser and the server have different routing tables. Or to put is more simply, the browser can see the stuff on your LAN, behind your firewall, while the server can't. The point of CORS even for anonymous requests is to prevent web pages from being able to exfiltrate stuff out from behind firewalls, so you don't have random data leaks just because someone in an organization visited some random website. (Yes, you also need them to not download and run random binaries, not have any unpatched exploits in their browser and OS, etc... security is hard.) Now obviously native apps _can_ exfiltrate stuff out from behind firewalls. Which means that if you really care about your LAN's security you have to assume or enforce that none of the phones connecting to it have any sketchy apps installed... Note that there is in fact discussion about having a concept of "installing" a web app that you trust sufficiently, which would relax the browser security sandbox such that you get more of the capabilities you're talking about here.
- dheera 11y ago
  IMHO the true point of a web app is to replace the native app and kill the need for developing every app twice (Android + iOS), as well as moving toward the vision of putting ALL apps "in the cloud" and fully OS-independent. In order for this to happen, those web apps need to have every capability a native app can have, including access to the local area network, if you want to do "things that native apps do". What if I want to write an HTML5 SSH client so that I don't have to rewrite it twice for iOS/Android? An SMB client? A custom streaming protocol? An HTML Arduino IDE that can flash code over the LAN? Ideally, a web app could simply have a manifest of permissions, present this list to the user at an appropriate time, and the user decide whether or not to grant them. Opening arbitrary TCP sockets should also be a permission, just like native apps need to add this to their manifest. Native apps already ask for permissions when installed; web apps should be required to do the same, and in return, be granted the same set of capabilities. The idea that "web apps should be restricted" is at odds with the vision of using web apps to realize a true cross-platform app programming ecosystem.
  - bzbarsky 11y ago
    Yes, this is why people are talking about having "installable" web apps. It sounds like you clearly agree that some sort of explicit user opt-in is needed to get out of the sandbox, which is good; I've seen some people argue that this is too high a bar. Now it might happen that this will effectively happen as a result of convergence and standardization of browser extension APIs. It'll be interesting to see what happens there. That said, the manifest of permissions idea is fundamentally broken in at least two related ways: 1) Most users have no rational basis on which to decide whether to grant the permission or not. In fact, I would argue this is all users, due to issue #2: 2) The permissions are either overbroad, such that pretty much any app that wants to do anything interesting asks for them (this is the "all my apps on want to be able to read my contacts and browsing history" syndrome) or there are so many of them that the list becomes way longer than any user would ever read at install time. You example of a permission for opening arbitrary TCP sockets is an excellent case in point. As a standalone permission, what fraction of users do you think would understand what is actually being granted? Even if you restrict to computer professionals, I suspect that most would not understand the implications without a somewhat lengthy explanation of what the permission actually allows. And even then, in practice it would be rolled into some other more broad permission that would likewise not indicate the security implications of granting it. http://robert.ocallahan.org/2011/06/permissions-for-web-applications_30.html http://robert.ocallahan.org/2011/06/permissions-for-web-appl... has some more in-depth discussion of the issues with this model. > Native apps already ask for permissions when installed Yes, and in practice everyone just grants whatever permissions are asked for without really even reading.

bzbarsky 11y ago

What you characterize as an "arbitrary technical limitation" is there for a good reason, unfortunately: even anonymous requests made by the _browser_ are not equivalent to anonymous requests made by the _server_ the web page came from. That's because the browser and the server have different routing tables. Or to put is more simply, the browser can see the stuff on your LAN, behind your firewall, while the server can't. The point of CORS even for anonymous requests is to prevent web pages from being able to exfiltrate stuff out from behind firewalls, so you don't have random data leaks just because someone in an organization visited some random website. (Yes, you also need them to not download and run random binaries, not have any unpatched exploits in their browser and OS, etc... security is hard.) Now obviously native apps _can_ exfiltrate stuff out from behind firewalls. Which means that if you really care about your LAN's security you have to assume or enforce that none of the phones connecting to it have any sketchy apps installed... Note that there is in fact discussion about having a concept of "installing" a web app that you trust sufficiently, which would relax the browser security sandbox such that you get more of the capabilities you're talking about here.

dheera 11y ago
IMHO the true point of a web app is to replace the native app and kill the need for developing every app twice (Android + iOS), as well as moving toward the vision of putting ALL apps "in the cloud" and fully OS-independent. In order for this to happen, those web apps need to have every capability a native app can have, including access to the local area network, if you want to do "things that native apps do". What if I want to write an HTML5 SSH client so that I don't have to rewrite it twice for iOS/Android? An SMB client? A custom streaming protocol? An HTML Arduino IDE that can flash code over the LAN? Ideally, a web app could simply have a manifest of permissions, present this list to the user at an appropriate time, and the user decide whether or not to grant them. Opening arbitrary TCP sockets should also be a permission, just like native apps need to add this to their manifest. Native apps already ask for permissions when installed; web apps should be required to do the same, and in return, be granted the same set of capabilities. The idea that "web apps should be restricted" is at odds with the vision of using web apps to realize a true cross-platform app programming ecosystem.
- bzbarsky 11y ago
  Yes, this is why people are talking about having "installable" web apps. It sounds like you clearly agree that some sort of explicit user opt-in is needed to get out of the sandbox, which is good; I've seen some people argue that this is too high a bar. Now it might happen that this will effectively happen as a result of convergence and standardization of browser extension APIs. It'll be interesting to see what happens there. That said, the manifest of permissions idea is fundamentally broken in at least two related ways: 1) Most users have no rational basis on which to decide whether to grant the permission or not. In fact, I would argue this is all users, due to issue #2: 2) The permissions are either overbroad, such that pretty much any app that wants to do anything interesting asks for them (this is the "all my apps on want to be able to read my contacts and browsing history" syndrome) or there are so many of them that the list becomes way longer than any user would ever read at install time. You example of a permission for opening arbitrary TCP sockets is an excellent case in point. As a standalone permission, what fraction of users do you think would understand what is actually being granted? Even if you restrict to computer professionals, I suspect that most would not understand the implications without a somewhat lengthy explanation of what the permission actually allows. And even then, in practice it would be rolled into some other more broad permission that would likewise not indicate the security implications of granting it. http://robert.ocallahan.org/2011/06/permissions-for-web-applications_30.html http://robert.ocallahan.org/2011/06/permissions-for-web-appl... has some more in-depth discussion of the issues with this model. > Native apps already ask for permissions when installed Yes, and in practice everyone just grants whatever permissions are asked for without really even reading.