Hacker News Reader

Comment by tannhaeuser | Hacker News Reader

A reality check to those who want to push apps and more workloads into the browser (via WASM, PWAs/excessive JavaScript, or whatever), with the browser becoming a gatekeeper. Not only is the browser a laughably complicated app runtime that isn't capable to do anything with local files (so you need "services" to store your eg. photos), it's also blatantly power-inefficient and a privacy catastrophe. Where has the idea of personal computing shared by a whole generation gone?

View on HN

    a privacy catastrophe

Much less so than a native application.

Native applications can access the web in less restricted ways than websites.

Native applications have more access to your local machine than websites.

Websites for the win!

What we need is a user friendly browser.

No, what we need is a proper permissions model for desktop applications. The idea of permissions being per-user is almost useless in this day and age where most desktop machines have one user (or a small number of users sharing files) and where most applications are downloaded from untrusted sources.

We need proper automatic sandboxing of native apps, restricting file, network and resource access without prior permission from the user.

That is being worked on. On many fronts. Linux containers are getting better. iOS is sandboxing applications to some extend. Android too and is slowly adding finer and finer sandboxing settings. ChromeOS also does sandboxing. I don't know about Windows, but I guess something similar is happening over there.

My money is on the Browser. Because it has proven (via survival of the fittest) that it is the best platform for the modern age. It has what, 100% market share? Everybody I know can use websites.

Even if one of the desktop or mobile operating systems adds sufficient sandboxing in the future, I would not want to develop applications for it. Because it would restrict my creation to the people who use that one platform. And it would give the power to censor it or mingle with it to the platform operator.

>ecause it would restrict my creation to the people who use that one platform. And it would give the power to censor it or mingle with it to the platform operator.

But that's exactly what's happening with browsers. Suddenly, Google wants to raze ad blocking, and everyone else follows. All the good points for browsers are restrictions and standardisations, which are fully present in exemplary containers. I don't see how you can get vendor locked-in via docker or kubernetes, I can see how webkit and DRM can.

There is no vendor lock-in if you use standard, battle tested web technologies with a few exceptions. If you use the browser as a UI platform, then OP is right.

DRM video is a pretty big exception, and Google is already a de facto gatekeeper there.

That was I was thinking about, but DRM is flawed anyways. I don't think there's anything on Netflix for example that isn't available on torrents or other file sharing methods.

Windows has been on the sandbox path since Windows 8.

Every release gets a bit more of that, regardless how many feel about the store or UWP API in general.

I don't want to only use trusted sources from any software store. If UWP had provided sensible deployment options, it wouldn't be as dead as it is.

Hell, personal firewalls provide a better sandbox solution, at least for network access, even if that is not really their intended function.

Be that as it may, I think good privacy laws and holding software manufacturers accountable is part of a solution. That software more and more behaves like worms regarding to user data is a more recent development.

UWP is not dead, every Windows release adds more API space, React Native for Windows uses UWP, Windows 10 drivers now use UWP APIs as well (Universal drivers), WinUI uses UWP, XAML Islands use UWP, ...

WinUI is also the official replacement for MFC, which triggered the rewritte of some UWP components into C++/WinRT from .NET Native.

Windows store supports side loading since Windows 8.1, and MSIX packages have replaced APPX and MSI as the future of Windows package formats.

Win32 APIs are frozen in amber since Windows 7.

Maybe. I am not really happy with it to be honest. Win32 is old and I thought WPF would be a real alternative. It did many things better than classical APIs, but I was never really into XAML and it was dropped just after a few years. I took a quick look at UWP which uses XAML in a different way, but I wasn't really convinced by it.

I am not interested in side loading anything. I have just no interest to use an API that is abused to promote a proprietary store and an OS because I only see disadvantages in that. UWP may have changed by now, but for me it is too late. I have switched to other technologies and are pretty happy with them. If windows continues to be SaaS, I will not develop for it. Even if its legacy might continue for a few decades.

If the primary form of deployment is a store, I could as well use Apple. Although their store isn't really shining on Mac OS as well. I believe there are good reasons for that.

Windows as a platform had many advantages, but it seems to me that MS threw that away to emulate others. A futile strategy in my opinion.

Have you been paying attention regarding Apple platforms?

> Beginning in macOS 10.15, notarization is required by default for all software.

Taken from https://developer.apple.com/documentation/security/notarizin...

Web, iOS, watchOS, iPadOS, Android, ChromeOS all use some form of sandboxing.

So unless your alternatives are the 1% GNU/Linux desktop market, sandboxes are here to stay.

That will result in a lot less software for mac OS. Since there are many applications that certainly will not spend anything on developer ids, e.g. most open source software there will simply be less builds for the platform.

ChromeOS supports android apps, but yes, I would state that iOS, chromeOS and android are really bad operating systems.

Regarding ChromeOS:

"Linux for Chromebooks: Secure Development"

> Learn how Linux for Chromebooks (Crostini) gives you a secure sandbox for development. Through a variety of demos, this talk will explain the architecture underlying Linux for Chromebooks and the design decisions that keep it easy to use.

https://www.youtube.com/watch?v=pRlh8LX4kQI

And Android:

"Adopting the Arm Memory Tagging Extension in Android"

https://security.googleblog.com/2019/08/adopting-arm-memory-...

"https://developer.android.com/distribute/best-practices/deve...

https://developer.android.com/distribute/best-practices/deve...

"Improving Stability with Private C/C++ Symbol Restrictions in Android N"

https://android-developers.googleblog.com/2016/06/improving-...

"Android NDK Native APIs"

https://developer.android.com/ndk/guides/stable_apis

Great. Let me know when that fancy sandboxing tech works for applications I actually use though. Or when UWP catches up with the 1990s and supports portable applications.

Since the introduction of MSIX package format and infrastructure, sandboxing can also be applied to Win32 applications.

Didn't MSFT just announce they're moving away from UWP in favour of Win32?

Not at all.

That was press articles done by journalists without any clue what UWP is all about, and equate UWP with Windows Phone.

The BUILD 2019 sessions are freely available to anyone that cares to actually learn what the current state of Windows development actually looks like.

macOS Catalina is actually much more aggressive about this. Even in unsigned unsandboxed apps, the OS will pause the app and ask the user for permission when the app tried to access any directory it doesn’t have permission for, and this behavior is replicated across many other parts of the system too (webcam, mic, etc).

It’s a bit annoying initially but it’s nice knowing that the system will put control back into my hands whenever apps try to do something shady.

Good feature, kinda sad macOS isn't popular like Windows.

Linux apps supports permission management in flatpak, but the packaging can be a big headache.

Like iOS then?

Oh, evil golden cages, right?

False dichotomy. A cage restricting the rightful owner of a computer is not the same as a cage that the rightful owner can use to restrict untrusted software.

There is no reason why sandboxing needs to be evil. In fact this is already proven by the sandboxing efforts on linux where there is no mandatory repository and the user is always in control, its the applications that are not.

How do you think Apple are allowed to exist in China? Who gave you the impression that they're the exception to the rule for independence from the government's "oversight"?

Funny, but I can trust most of my locally installed apps. I trust Photoshop not to share my photos with Adobe, and so far it hasn't. It also doesn't share telemetry or any of that.

Same actually goes for most programs I use.

It's the browsers that have the habit of sharing sensitive information with the outside world, not other apps.

I'm talking desktop software. Mobile seems to have a lot more privacy invading apps.

https://www.organizingcreativity.com/2017/01/adobe-creativel...

The native applications I use are tamed in sandboxes, while offering much higher performance and better usage of hardware resources.

But then the browser is able to collect history across app usage though, which makes it more dangerous, not less.

We have to differentiate between platform (OS/Browser) and applicaion (native app/website)

The browser is the OS. The website is the application.

Browser and os can both track your history. An application / a website can not.

You might think websites can via tracking scripts connecting to third parties. But applications can connect to third parties even easier. As a user, you have even less power to prevent that.

That's why I want to be able to trust my OS privacy-wise.

A native app might be able to violate my privacy. But an OS that can do so is much more dangerous. The reason is the volume of data that can be collected by the gatekeeper.

That's why I wrote

    What we need is a user friendly browser

A browser we can trust. That is built to serve the user and hands all power to the user.

Yeah except TFA shows this is exactly not what browsers are doing (with the possible exception of Safari)

That's why I wrote

    What we need is a user friendly browser

Firefox is a step in the right direction.

The next step would be for some open source initiative to do the work and de-google Firefox completely. If that fork of Firefox gains traction, it might bring Mozilla on the right track so they drop their ties with Google to survive.

> The browser is the OS. The website is the application.

No, that's wrong.

;)

How about the browser is an application, and the website is ... a website?

* Than

I am hoping that privacy and security concerns are about to push the local/remote pendulum back towards local again. An antidote to the Cloud madness is well overdue.

Of course, that does rely on having better security models and software installation and update systems in our desktop OSes, and particularly in the case of Windows, they are running at full speed in the opposite direction lately. :-(

> Not only is the browser a laughably complicated app runtime that isn't capable to do anything with local files (so you need "services" to store your eg. photos), it's also blatantly power-inefficient and a privacy catastrophe.

Yes, but there are no practical alternatives. No matter how inefficient it is, there is nothing to replace it. And the gatekeepers of the devices on which the browsers run won't let anything else replace it unless they are the ones controlling it.

> Where has the idea of personal computing shared by a whole generation gone?

I would say it was eaten by profit seeking corporations.

There are no practical alternatives for what? I've used local apps for everything on Linux and BSD for decades.

There are no practical alternatives for delivering appications especially for small companies.

Let's say you are small startup, which core business it not IT related, and you want to distribute an app your customers/partners. Are you gonna hire one person to write app for each platform? And how many platforms are you going to support?

How difficult that is depends on the framework(s) your app uses and how reliant on system APIs you are.

There are quite a few cross-platform frameworks in a number of different domains.

Ok, in that case I agree that browser-apps/database frontends are useful. I was thinking more about consumer apps.

In many cases there are no practical alternatives for slick UI/UX.

Bunk. This is entirely subjective and worthless to the argument. Compare: widget toolkits like Aqua, GTK3, Windows.Forms, etc. to the bedlam that is the web.

So let'say you use any of the toolkits you mention. How would you go about distributing your app to Windows, macos, android and ios? I am even leaving out the question that from all the toolkits mentioned none will let you do that.

How does Chrome get delivered to all these platforms?

It's not exactly rocket science.

well, it's already there when you buy/reinstall the device. Maybe not chrome but a web browser is preinstalled.

So then you only need to provide url to the users of your app, and they are ready to use it.

With distributing binaries it is much more complex story. And that's why projects using Electron get more and more popular, because they at least take part of this complexity away.

> And that's why projects using Electron get more and more popular, because they at least take part of this complexity away.

...no they don't. They're literally distributed the exact same was as native applications. They're developed differently, saving the developer time (theoretically), but they're distributed in the same old download-and-install (or just download and run) way that applications have been since forever.

I said "they at least take part of this complexity away."

They don't solve all of the problems, but they do solve two important ones. 1. The runtime is the same on all platform 2. They build installable binary packages for you

So only 2 is about distribution , and it is not a trivial task. If you have to make Installer for windows, DMG for macos and let's say deb and rpm for Linux.

I have a small opensource tool that I make, and I would say that building the installer for all the platforms have taken probably 20% of all the development time, and if you count in also the desktop integration code( like Explorer context menu for Windows) it's way more.

Installers for MacOS and Windows are piss easy. Hell, you don't even actually need installers for either, as both OSs support portable applications. I never even bother to make windows installers because you can just unzip to a folder and be done. If I ever distributed anything for Linux, I'd use AppImage to the same effect.

Reply on news.ycombinator.com