Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

Browsers have an absolute insane level of relatively unchecked permissions to do whatever they want on a client.

There's a lot of effort by browser developers to scope creep the browser into essentially being an OS-agnostic tech stack (one where, conveniently, code can be shipped across the network "as necessary", removing a lot of user agency for the software being ran); Chrome being the biggest driver of this, while Firefox has an extremely weak spine in trying to limit it.

It's fairly dire and I wouldn't be surprised if there's a lot more of these side channel attacks in a lot of web APIs.

 help



Flash ended up getting blocked/banned by all browsers because it turned into a giant gaping security hole.

> By January 2021, all major browsers were blocking all Flash content unconditionally.

It looks like we-the-users need to be blocking any and every one of these parasites.

https://en.wikipedia.org/wiki/Adobe_Flash


I have a feeling they may have pushed for that more because it was controlled by a third party, and not the browser developers themselves.

Now that we have AI, can we go back to real apps and native tech stacks? And revert the browser to a text-display interface?

Unfortunately, real apps and native tech stacks can not only write data to your SSD, they can usually write data to the user directory however they want and they can read it as well!

Browsers are at least somewhat sandboxed


But you need relatively few native apps with those capabilities, in contrast to visiting many different websites for content consumption.

This is a Linux-centric take. It does not apply for example to iPadOS or to AluminiumOS (coming soon to a Googlebook near you). It applies less and less over time to MacOS.

Yes, if one is committed to the standard Linux desktop, then one must hope that any proprietary apps one might need will continue to be available through the browser, but I'm ready to let the standard Linux desktop go (not right now, but eventually).


It very much applies to macOS, or do you know of a way to know what permissions a sideloaded macOS application will have before opening it that's accessible to regular users?

The very fact that you've qualified your question with "sideloaded" suggests that you are already aware that a non-sideloaded MacOS app is installed into a sandbox that is much more secure than anything available on a standard Linux desktop excepting possibly Qubes and Secureblue, and hardly anyone uses Qubes or Secureblue -- probably for very good reasons.

Yes, and I'm also aware that most macOS apps are still only available as a sideload, where sandboxing is optional and importantly not user visible before the app runs.

Why not sandbox the process then?

I don't know, maybe something about backwards compatibility, maybe nobody can agree on how to do it correctly. It hasn't happened for decades, so I'm not going to hold my breath.

Sure, can you propose an equally mature and battle-tested sandbox, ideally one with multiple implementations on a wide variety of OSes?

> can we go back to real apps and native tech stacks

Please God, no. If you're worried about the invasiveness of browser-based apps, native is out of the frying pan and into the fire


Except you’re not going to install native apps for the vast majority of things you use a browser for. You’re going to use the browser for content consumption and native apps for a few things that need system access.

Are you arguing that it's better to install a small handful of highly privileged applications as opposed to none?

Sure, once we have equivalent strong sandboxing for third-party apps I'm down to install random ones rather than visiting a website.

It's also the technology that will allow software to run without a continuous connection to the server. If you want to break out of a world where companies own your data it's the tech that is needed.

The uncomfortable part is that each step is usually justified by a real use case



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: