Hacker News Reader

Comment by TekMol | Hacker News Reader

    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.

View on HN

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

Reply on news.ycombinator.com