Linux desktop is more viable than ever.
Zigbee/Matter/... are widely adopted open standards without vendor lock in.
Things like Home Assistant are getting serious attention and funding.
Could be much worse.
8,865 karma · joined May 17, 2016
Zigbee/Matter/... are widely adopted open standards without vendor lock in.
Things like Home Assistant are getting serious attention and funding.
Could be much worse.
Used to be even worse.
No further insights on the design rationale, but yeah, that's exactly what's going on.
Project Zero treats Google like any other vendor (much to the annoyance of other internal teams).
I've been wondering about this - are they really?
[1]: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
Their security teams are industry-leading and they have done a lot of important work over the past decade (Project Zero, a very well-done bug bounty program, Advanced Protection, FIDO/hardware security keys, large-scale fuzzing and AFL, tons of behind the scenes sandboxing work, Linux kernel hardening...). They have a fine track record keeping their users safe (...from anyone but themselves and the US government).
> Given the embedded browser is not secure
It's a standard web view, which uses the same engine and is sandboxed the same way the standalone Chrome browser is. There's a few extra APIs injected into it, but chances are that they require authentication or simply check the origin. What makes you think they didn't take this into account when triaging the report?
There's hundreds of these web views with plenty of opportunities to "escape".
> Now, Google only fixes security bugs only after they've combined into a severe remote exploit
[citation needed]
Things like Chrome entirely rely on multiple layers of protection and, like any sensible vendor, they will absolutely fix a bug in, say, the renderer process even if there's no full-chain exploit.
> In some contexts (especially as high-stakes test settings, but also some military/prison/finance/medical/legal/etc. settings) this IS a direct security risk
In a kiosk or proctoring environment, you wouldn't be able to browse Google account settings in the first place. It's a non-issue.
Google does not have their own app. Exposure Notifications is the cross-vendor low-level API which apps like Germany's is (...was) using.
It insists on copying the entire repository into the Nix store (which makes all of its content world-readable!). Even if your flake.nix is in a subdirectory of a monorepo, the entire monorepo will be copied into the store every time!
Firejail is a setuid binary with tons of attack surface and has had a number of privescs itself[1], unlike something like the lower-level Bubblewrap tool.
I'm glad it exists, though - it's the only mature solution other than Flatpak that has proper dbus filtering, among other things.
[1]: https://www.cvedetails.com/vulnerability-list/vendor_id-1619...
Sounds like you want Chromium OS :-) Fully open source, Linux-based, and it's hardened to the point where neither the user, nor an attacker, can execute any abitrary code outside a sandbox without a Chrome and/or Linux 0day. You even get VMs with seamless Wayland-based desktop integration with a normal Linux distro inside, and you can create multiple VMs if you have different security levels.
If you enable crash reporting, Google will find and triage crashes for you and would quite possibly catch buggy exploits, and maybe tell you about it.
But, this is very far from what most people want in a Linux distro.
The protocol does not trust the server. Android has reproducible builds, iOS doesn't.
Getting access to the host OS won't give you much other than some internal binaries and config.
go mod init mymodule
- Vendoring dependencies using "go mod vendor" is not a good default workflow - it bloats the repo, the checked in code is impossible to review, and is generally a pain to keep up to date. Don't, unless you really have to.
- There's no point in stripping a binary or even using UPX on it unless you're targeting extremely low memory environments (in which case Go is the wrong tool anyways), all it'll do it make it harder to debug.
- Google's gVisor[1] (a re-implementation of a significant subset of the Linux syscall ABI for isolation, also mentioned in the article).
- USBArmory's Tamago[2] (a single-threaded bare-metal Go runtime for SOCs).
Both of these are security-focused with a clear trade off: sacrifice some performance for memory safety and excellent readability (and auditability). I feel like that's the sweet spot for low-level Go - projects that need memory safety but would rather trade some performance for simplicity.
gVisor is a very fun project - they're really pushing the boundaries of what's possible in Go. Typical overhead is <10% thanks to a number of new features (systrap[3], directfs, in-process overlay...), all while maintaining a well-documented and super clean code base.
[1]: https://github.com/google/gvisor