Google, alongside all of those that push Chrome wrapped in whatever kind of package, have managed to turn the Web into ChromeOS.
I expect job adverts for HTML 6 to be about years of experience developing ChromeOS applications.
Recent things like Zoom native app being incredibly insecure but the same company's webapp being much better kind of proves the point.
It shouldn't be difficult to see that GIMP and LibreOffice can run on this runtime with similar privacy.
We typically download native executables over HTTP. Then check for application updates over HTTP.
Privacy respecting WASM apps can do the same.
This is the new Java, not the new SaaS.
Spend some time learning about marketing solutions.
So native apps may use, Web uses it all the time.
Every horizontal line on the network tab in developer tools is yet another piece of telemetry information.
Native apps have access to whatever user they run under.
Again whatever native apps can do, web apps do all the time.
Another example: Microsoft Word can include a bug that makes opening a doc file run whatever command, including wiping the system. Google Docs can't do it.
It's much simpler to see telemetry in a web app - just open the Network tab. The fact that it's harder to do with a desktop app does not at all means it isn't there. Give wireshark a spin.
You don't get it, yes desktop apps can do telemetry, and many do.
Web applications not only have all your data, every page interaction is fed into marketing engines regardless of your opinion on that.
You keep making these bombastic statements with no data behind. Not all web applications store every page interaction into a marketing engine. For example, I have a web application - as you navigate no additional network requests are sent (it's SPA!), and anyway I don't really have access to those the server logs because they're hosted by some Netlify-like service. See? Web application without you data that doesn't feed your interactions into a marketing engine.
Some web apps track, some desktop apps track. But clearly and without any doubt an executable running in your operating system can potential do much more than a web app you open with your up-to-date browser. An executable can even... open a web app!
Discord web app has a track record from everyone you ever spoke with, where you where when each sentence was written, who the people you talk to were.
All Web apps track, there are no exceptions, unless you are talking about some hobby stuf written by yourself.
This isn't true. Yes, web apps have tons of telemetry, and every web request is logged server-side. But native apps do MORE:
- Native apps can look at what processes you're running. Web apps can't.
- Native apps can look at what software is installed. Web apps can't.
- Native apps can accurately determine exactly what operating system and browser you're using, while web apps either have to rely on a User-agent (which is trivially spoofed), or perform fingerprinting in order to come up with a guess.
- Native apps can see exactly what hardware you have. Web apps can't.
- Native apps have read/write access to every file on your system, subject to user-level permissions. Web apps require explicit selection from the user for file access. A native app can easily send your /etc/passwd file to a remote server, and can enumerate the local users.
--
Look, nobody is disputing that web apps have tons of telemetry, yet you keep responding as if that's what people are arguing with you about. What we're disputing is the exact statement I quoted. You implied that the telemetry of a native app is a subset or equal to the telemetry of a web app, and that's just plain false. It's very much the other way around. The telemetry of a web app is far less than a native app.
A native app may know which browsers I have installed, but how would it know which of the umpteen ones I have I actually regularly use (if I don't do so while running the app)? The Web app, OTOH, is running in that browser, so yeah, of course it has a better chance of knowing that.
Your "umpteen" browsers is very much an edge case.
It's at least possible (albeit potentially difficult) for a native application, should it have have such tracking, to have that tracking removed. Software "crackers" have shown, time and again, that so long as the code is present on a machine it can be made to run in whatever manner is desired.
The fact that I can see access log in my web server is just a helpful tool for me as a developer to improve my services. I think the majority of sites use this in good faith and keep products healthy.
If your threat model involves secret services tracking your activity down based on downloading favicon.ico, then you might have more serious problems than architectural choices of the web platform.
And they own your data as well.
At my day job, we make a web application for health records that can be deployed inside an air-gapped intranet. Surely you don't think that's feeding a marketing engine?
It's a separate question of how a patient can be sure of that fact. There's actually not a really reliable way a patient could even become aware of the existence of this product, since they would never see it or be informed of it. Patients are not users of this product. Users could ask their IT department for a log of outgoing internet-bound requests from the servers. Or ask whether those servers even have the capability of contacting arbitrary third parties.
I mean, one could also be running around in a supermarket in a balaclava without intending to rob the cashier -- but would you assume someone you saw doing that wasn't going to do exactly that?
In fact, that's pretty similar to the technique that you'd use to check on a local app too, except it's built into the browser.
I'm not particularly interested in convincing anyone that some app is or isn't leaking their data. If you don't want to use web stuff, don't use it. But I do take issue with assertions that 100% of all web apps must be doing that kind of stuff. It's obviously not true. You can develop your own web app from scratch that doesn't do it, which is sufficient to form a counter-example.
And one counter-example does not a summer make. As long as 99% (typical Internet statistic, i.e. pulled from my mether regions) of web apps harvest your data for sale, that last percent won't get the benefit of the doubt: it's far too difficult and uncertain to find out which percent that would be.
Bearded Man #1: But I have a beard.
Marshall: Well, then you're an alien.
Bearded Man #1: No I'm not.
Marshall: Yes you are.
Bearded Man #1: No, I'm not.
Marshall: Well, then you can't grow a beard.
Bearded Man #2: But he has a beard.
Marshall: Well, then he's an alien.
Bearded Man #3: He's not. He's from Pittsburg.
While local apps are getting sandboxed properly: https://docs.flatpak.org/en/latest/sandbox-permissions.html
It seems it need user to manually select a file/folder to be used, like Android or iOS does.
> While local apps are getting sandboxed properly: https://docs.flatpak.org/en/latest/sandbox-permissions.html
It looks good, but it seems many applications still require filesystem=host to run (https://flatkill.org/2020/). Also, its sandbox solution isn't going to work on Windows, Mac and BSDs.
please select your home directory for our super-awesome functionality
I'm sorry, but the likeliness of zero days in a c++ program that was too stupid to handle char arrays or multithreading is way off the charts vs heap spraying bugs in a VM.
I'd argue that native applications therefore are far more vulnerable than web applications.
Desktop applications can track your every click with HTTP requests to their server.
The runtime does not determine this.
And if by offline you mean PWAs, unless you are doing Hello World, that app cache is going to be cleared and then analytics can be updated.
Finally, there is very little a pure PWA can do without doing HTTP and Websocket requests.
Desktop code cannot be verified. Web code can be verified. This argument goes both ways.
If we're talking about the web-equivalent of Desktop Apps: There's electron, which can do far more than HTTP requests and WebSockets - but that on the other hand is also too bloated, right?
Sometimes I wish people would just make up their mind, stop complaining, and start trying to fix it. We had servo, and we had a nice modular and privacy respecting future for everybody; and then we messed it up because apparently nobody really cares about it.
Please explain the crowd how you verify the SaaS server side.
Electron is an abortion, that will eventually follow Active Desktop footsteps after its fashion hype curve dies out.
In any case, Electron based apps can do whatever user account they run under.
HTTP is simply the delivery mechanism for a self-contained WASM application. Just like it is the delivery mechanism for most native binaries now.
If it's in your browser, you can see the code it's running and the data it is transmitting. And you're only a single uBlock Origin (other other browser add-on) filter away from blocking it.
My gentoo install would like to have a word with you
That is a remarkable ability.
Do not let the crimes of Web 3.0 blind you to this.
Tracking and disrespect for privacy are utterly orthogonal.
It's rare that a self-hosted piece of software is not present on this list. As you can see, the coverage is pretty extensive.
I think in the end, it doesn't matter as much. These are meant to be deployed for a cohesive user base that numbers between a single geek and an entire region of a country or small org.
They most often use libre data formats and protocols to store and communicate data. In such a situation, the network effect is less pronounced, and measuring market share isn't as important. As long as the service works reliably and meets user needs, I don't think people will clamour to replace them with proprietary solutions.
Having an interface I can just stand up on a port and access locally through multiple different browser options, or even expose to remote if the user wants, and it will be the same across every OS for zero additional shipped library cost, and works in every programming language, is an amazing thing.
For RDP, clients are easy to come by (but not ubiquitous), but the server side tech is limited, and generally OS based and not application provided.
For VNC, client and server tech is easily available as a library to all, but it's still an additional layer on top of your application which you need to layer on and then communicate as a separate step to any client that needs remote access.
I'm not familiar with views, but I'm not sure how it could be any easier to use than VNC without limiting where it can be easily deployed.
Opening a port and taking a few commands is simple. There are myriad libraries to help handling requests, and in some languages rolling your own is a matter of tens of lines. The client requires nothing that every person that would want to use it doesn't already have, and if you want to support remote access, you literally just change the interface you bind to from localhost to 0.0.0.0 or the actual IP address. All additional firewall config is something you would likely have to deal with in every other technology as well.
Now, don't get me wrong, I'm not saying this is the best UI paradigm to target. There are many things better about specific UI libs, but none of them can even come close to the cross platform capability and simplicity of just using HTTP+HTML. Do I want major applications delivered this way? No. Do I think it should be the ultimate choice for most programs that have time and resources to do otherwise? Probably not. Do I appreciate that I can write a Perl/Python/Rudy/JavaScript script and package it with its runtime or ship as a script (or just use a compiled language) and it will just work on basically any platform I'd want to run it on, and a client (browser) exists for everything someone would want to use to configure it? Hell yes.
Web apps are still the most secure platforms to date, nothing widespread really came close in terms of sandboxing & safety.
There's a reason everybody asks you to download their native app, tracking is much easier there.
No one asks you to download native apps for desktop platforms, unless it is some Electron garbage for whatever reason, usually for stuff that is available to PWAs anyway.
All ask for native apps on mobile, because development just sucks less.
Whatever, it is great that people believe Web apps are so safe with their data, more fun when creating analytics rules.
They are not ephemeral. They are far more persistent than anything you could install locally, because all the data now resides on someone else's computer. The "ephemerality" paradigm of web apps has been a strong contributor to that trend.