Hacker News Reader

Comment by deathanatos | Hacker News Reader

I'm not saying that native apps > web apps isn't true, but…

> * Request stuff from arbitrary URLs without a CORS proxy

CORS isn't a proxy; it's a browser policy/algorithm that allows a site the opportunity to say "yes (or no), other websites may (or may not) make AJAX requests here". The native app (unless you've informed it somehow, or it has done something malicious) doesn't have the user's cookies, whereas the browser does, and needs to be a bit more cautious.

> * 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…)

> * 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.) (and what would I want this for?)

View on HN

> CORS isn't a proxy;

I don't think the GP was implying that.

If you don't control the upstream content you don't necessarily control the CORS settings. Hence the need for CORS proxies to work around an ideal introduced by the major browsers in the last few years.

In the real world you may well have the right to access third party content, but in many cases you require them to expend engineering resource to perform the very simple task of enabling a simple set of headers, so end up having to proxy content.

Take Chromecast for example - it takes CORS to the extreme requiring it set on HLS manifests and .ts video files, meaning any proxy solution has to take the full cost of proxying the full video content. MP4 files don't have this restriction, nor do any browsers.

To me it very much feels like the web is splitting into two - Sites that you stumble upon and want completely sandboxed, and those you come back to repeatedly and provide enough value for you to click "yes, have my location"..

>> * 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.) (and what would I want this for?)

Most modern phones have a barometric (yes, air pressure) sensor included. Having semi-accurate altitude data helps the GPS receiver obtain a faster location fix, but it can be used for other things as well.

> Are there common devices out there with these?

Most Android devices since maybe late 2012 have had one. It's used for enhancing GPS lock, and whatever developers can dream up. All I've heard about it being used for is a distributed air pressure sensor network used for weather prediction, tracking, etc. [0[

0: https://www.pressurenet.io/

Yes. The barometric sensors in the iPhone 6 and most high-end Android phones of past 2 years are sensitive enough to determine +/-1 floor of building movement, among a whole lot of other things. Very useful if you're writing a hiking app, want to determine if the user is in an airplane or not, trying to do vertical geolocation in a vertical city like New York or Hong Kong (subtract user's barometric reading from the weather station and you'll have it accurate to +/-a few floors), and a whole lot of other endless possibilities.

> * Request stuff from arbitrary URLs without a CORS proxy

I think OP probably means a proxy server on your domain which can make arbitrary requests to a third party, in order to get around CORS restrictions:

  browser <--[XHR]--> my-server <--[HTTP]--> third-party

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_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/

(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!!

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.

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.

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-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.

You're right, there's a really good point here that I didn't acknowledge. The way I think of it is that the browser's security model, while not particularly secure from an academic or theoretical standpoint, is extremely widely deployed, widely studied, and well-understood, and in that very pragmatic sense is very well-trusted. Hence, every little thing that affects the security surface area must be exquisitely scrutinized, necessarily resulting in slow advancement in any such features.

Of course you don't want web pages opening TCP and UDP sockets. The web isn't for writing apps it's for publicly editable documents with hyperlinks.

Reply on news.ycombinator.com