Earlier quoted context omitted.
They're increased, and some things are just obviously slow at least without extra effort to setup things like gpu pass-through. But is it worth basically turning back the clock on your computer's performance a few years to live in a world where a random click from HN or reddit can't quietly compromise your entire computer? I think so. Probably the biggest thing is to have a lot of ram, because if you're really using…
> "obviously slow at least without extra effort to setup things like gpu pass-through." AFAIK unless you have a desktop computer filled with gpus on pciexpress slots there is no way you can use GPU passthrough on multiple VMs. That kind of defeat the purpose of qubes os no?
Mozilla fixes Firefox zero-day actively exploited in attacks
121–130 of 151 posts
Re: Mozilla fixes Firefox zero-day actively exploited in attacks
#122Earlier quoted context omitted.
They're increased, and some things are just obviously slow at least without extra effort to setup things like gpu pass-through. But is it worth basically turning back the clock on your computer's performance a few years to live in a world where a random click from HN or reddit can't quietly compromise your entire computer? I think so. Probably the biggest thing is to have a lot of ram, because if you're really using…
> a world where a random click from HN or reddit can't quietly compromise your entire computer Doesn't Flatpak also solve this?
Re: Mozilla fixes Firefox zero-day actively exploited in attacks
#123Earlier quoted context omitted.
> This vulnerability affects Firefox https://nvd.nist.gov/vuln/detail/CVE-2024-9680
CVE affected range is always far too wide. It obviously can't affect anything before ~75 or so because firefox didn't have the timeline api before then. It's annoying that they don't distinguish an unknown lower bound.
But I agree it’s appears lazy because it would have been easy to determine in that case, if I understood you correctly. Someone would have had to test it though, at the very least.
Re: Mozilla fixes Firefox zero-day actively exploited in attacks
#124Earlier quoted context omitted.
No, that's not what I'm talking about. C# and Java have nothing like the Send and Sync traits, and they don't have & and &mut.
C# doesn't have Send and Sync that is true. It frequently does not need either because it uses GC instead of affine types for automatic memory management. Synchronization is indeed "just don't write bugs", where Rust offers a massive upgrade, but .NET CoreCLR's memory model is more strict than C one, like object reference assignment having release semantics, so quite a few footguns are luckily avoided: https://github…
With traditional mutex APIs it's just far too easy to get it wrong. I think you just have to structure your thread-related APIs to be misuse resistant. As humans we're just not good enough at not making mistakes.
Re: Mozilla fixes Firefox zero-day actively exploited in attacks
#125Earlier quoted context omitted.
So is .net
You've clearly never tried to use .net on a non-MS OS. Sure, it's possible . But it's also a royal pain, at least last time I checked.
Things changed after core
Re: Mozilla fixes Firefox zero-day actively exploited in attacks
#126Earlier quoted context omitted.
> "obviously slow at least without extra effort to setup things like gpu pass-through." AFAIK unless you have a desktop computer filled with gpus on pciexpress slots there is no way you can use GPU passthrough on multiple VMs. That kind of defeat the purpose of qubes os no?
I dunno about that? do you use more than one gpu intensive task at a time?
Also it is not only about doing these tasks at a time, but if you need to shut down to be able to start another VM context because they can't be used concurrently it makes it very tedious user experience.
Re: Mozilla fixes Firefox zero-day actively exploited in attacks
#127We need a browser written in managed lang Even if it means some perf drop, modern hardware will get it back in X years, but safety will be significantly improved
Re: Mozilla fixes Firefox zero-day actively exploited in attacks
#128Earlier quoted context omitted.
They already are partly in JS so there's a smooth path. (Wasm isn't safe but could be a building block too)
I can't find the link right now but I seem to remember that Firefox already replaced some internal native subsystems with the same code compiled to WASM - or maybe even compiled to WASM and then translated back to C, which basically adds a runtime memory safety layer to unsafe C code at the cost of some performance (I think it was a couple of media codecs, but not sure). Not sure why you think that WASM is less secur…
java applets promised a sandbox and then we had years of continuous vulnerabilities of escaping said sandbox.
Re: Mozilla fixes Firefox zero-day actively exploited in attacks
#129Earlier quoted context omitted.
You've clearly never tried to use .net on a non-MS OS. Sure, it's possible . But it's also a royal pain, at least last time I checked.
I had .net on prod linux since 2018 and it works very fine seamlessly, web apps. Things changed after core
(I've tried [and failed/given up after about 2 weeks] to get a .net desktop application to build on Linux.)
Re: Mozilla fixes Firefox zero-day actively exploited in attacks
#130Seems bad. "An attacker was able to achieve code execution in the content process by exploiting a use-after-free in Animation timelines. We have had reports of this vulnerability being exploited in the wild." See: - NVD page for CVE-2024-9680: https://nvd.nist.gov/vuln/detail/CVE-2024-9680 - Mozilla security advisory: https://www.mozilla.org/en-US/security/advisories/mfsa2024-5...
Ticket in Tor Browser: https://gitlab.torproject.org/tpo/applications/tor-browser/-... It seems to be JavaScript-free from the description, which makes it even scarier. Imagine the libwebp decoder bug except embedded media blocking doesn't really work (who blocks CSS?).
I think it would be a labor of love and craftsmanship to exploit a content process today without using JavaScript.