Comment by untog
5 years ago
You have to build these APIs before people use them, and a lot of what Google has been building into Chrome is stuff native apps can do, so the use-case is clearly there.
IMO native apps are capable of far more invasive privacy violations than the web is. But for some reason they're given a very free pass by comparison.
Native apps are not handling my bank account passwords. They're also not collecting data about my consumer behavior with the goal of displaying more ads. This is a big difference.
> Native apps are not handling my bank account passwords.
You're conflating browsers (Chrome, Firefox, etc) with user applications. User applications are still not handling your bank passwords.
> They're also not collecting data about my consumer behavior with the goal of displaying more ads.
lol? Absolutely wrong here.
> They're also not collecting data about my consumer behavior with the goal of displaying more ads
This is my original point. They 100% absolutely are. Look at some of the ad and tracking frameworks for native apps. Somehow no one cares.
They're given a very free pass because it's incredibly easy to block a native app from sending data back or even connecting to the internet at all.
You have a lot more control over something that's running locally than something running serverside that simply using the client to harvest data.
It's even easier to block a web app - just don't visit its web address.
A native app sits on your device, executing all kinds of code, sometimes without your knowledge. With PWAs, the code is more or less open source - all the JS is there for you to inspect - even after obfuscation, you can see the network requests being made in the dev tools of any browser.
I appreciate that and maybe didn't make my point as best as I could.
My point was essentially that you can run a native app without internet access most of the time (and can easily block the app making calls out by switching the internet off or blocking the calls its making) but a web app you have absolutely no control over, you just have to not use it.
1 reply →
Well, because native apps are intended to be trusted. They do not have a motivation to invade your privacy: proprietary apps are usually paid upfront and risk their future clients, open source can be inspected.
Instead, the overwhelming web business model is "free to use" (akin to f2p in games). That means ads and other monetization side channels become the priority of the app, not the app itself.
And that is for trusted web apps. Let's not even talk about the fact that you are executing random code every time you visit any webpage. That just does not happen with native apps.
That's not true at all! Free native apps abound. Web apps tied to subscriptions are also plentiful.
Open source is neither here nor there: both web sites and native apps can be open source. In fact, the web is unique in allowing you to actually inspect the source that is running on your machine, you have no way of verifying that the code in an open source repo is what actually runs inside your iOS app.
> In fact, the web is unique in allowing you to actually inspect the source that is running on your machine
To be fair, this is changing with WASM. On the other hand, there are tons of obfuscation opportunities with native executables that don't exist for WASM.
> Free native apps abound.
Yes? I haven't claimed there aren't free native apps.
> Web apps tied to subscriptions are also plentiful.
Fair, but most of the ones I know are usually technical apps or they offer something else that is not about software (for instance, storage more than the app).
> the web is unique in allowing you to actually inspect the source that is running on your machine
That is not unique, nor true.
Uniqueness: you have apps made in scripting languages everywhere. Even for compiled languages it is a decision not to give you the code, not a technical one.
Truthness: many webs are obfuscated on purpose like native apps are.
> you have no way of verifying that the code in an open source repo is what actually runs inside your iOS app.
False, you can definitely verify that a binary matches the source code in deterministic builds and even provide debugging symbols etc. The fact that many projects don't care about that does not mean there is "no way", it just means the overwhelming majority of users do not care.
1 reply →