Perhaps what is broken is not our operating systems, but the notion that a computer program running on one's own computer can be an untrusted agent of a third party. I don't the tools in my collection to be isolated from each other, dangerous creatures in a computerized zoo. I want them to be composable elements of a cohesive whole. I want them to share data so promiscuously that is difficult to tell where one progra…
I will take this into my fortune file!
I'm flattered! In that case do fix my typo: "I don't want the tools".
Right. Or where it matters less, VirtualBox or KVM. And where it matters more, hardware compartmentalization.
> And where it matters more, hardware compartmentalization. With the caveat that you need to use secure air-gapped communication, and you probably want to use Qubes on each of the separate machines as well [1]. [1] https://www.qubes-os.org/faq/#how-does-qubes-os-compare-to-u...
Right.
The Tinfoil Chat setup uses optocouplers to enforce one-way data transmission.[0] And one can use inexpensive CD-R and micro SD cards for single-use data transfer. But transferring anything but plain text is dangerous.
> And where it matters more, hardware compartmentalization. With the caveat that you need to use secure air-gapped communication, and you probably want to use Qubes on each of the separate machines as well [1]. [1] https://www.qubes-os.org/faq/#how-does-qubes-os-compare-to-u...
Right. The Tinfoil Chat setup uses optocouplers to enforce one-way data transmission.[0] And one can use inexpensive CD-R and micro SD cards for single-use data transfer. But transferring anything but plain text is dangerous. 0) https://github.com/maqp/tfc
Thanks for mentioning the octocouplers implementation, it looks very interesting and I'll look it. Other options I'm aware of to avoid USB and complex drivers/protocols:
Right. The Tinfoil Chat setup uses optocouplers to enforce one-way data transmission.[0] And one can use inexpensive CD-R and micro SD cards for single-use data transfer. But transferring anything but plain text is dangerous. 0) https://github.com/maqp/tfc
Thanks for mentioning the octocouplers implementation, it looks very interesting and I'll look it. Other options I'm aware of to avoid USB and complex drivers/protocols: - Scanning QR codes (for example https://air-gap.it/ ) - Audio codes (for example https://github.com/romanz/amodem )
I wonder if one could cut up QR codes, and store pieces separately. If that were done in Gimp or whatever, there could be multiple copies of each piece.
Thanks for mentioning the octocouplers implementation, it looks very interesting and I'll look it. Other options I'm aware of to avoid USB and complex drivers/protocols: - Scanning QR codes (for example https://air-gap.it/ ) - Audio codes (for example https://github.com/romanz/amodem )
Wow. That is very cool. Edit: https://air-gap.it/ seems down. But https://github.com/airgap-it is up. I wonder if one could cut up QR codes, and store pieces separately. If that were done in Gimp or whatever, there could be multiple copies of each piece.
Do you mean sharding them using something like Shamir Secret Sharing, splitting in order to be able to transfer/store a large blob, or something else?
Wow. That is very cool. Edit: https://air-gap.it/ seems down. But https://github.com/airgap-it is up. I wonder if one could cut up QR codes, and store pieces separately. If that were done in Gimp or whatever, there could be multiple copies of each piece.
Do you mean sharding them using something like Shamir Secret Sharing, splitting in order to be able to transfer/store a large blob, or something else?
I meant actually cutting them with a sharp knife, or scissors. So you could hide pieces in different places. For stuff like URLs, passphrases, wallet seeds, etc.
>Linux distros are behind on implementing modern binary exploit mitigations. Compile from source, use only trusted package managers, and sandbox and compartmentalize when possible. >Linux distros have no concept of sandboxing They may be inadequate or need improving, but these concepts are there, if rarely used by default. >Any app running under Xorg can see the contents of any other app runing under Xorg. There are…
What mitigations exists for the Xorg apps?
Qubes, running rootless helps but doesnt stop it, xephyr with selinux sandboxes, nothing that completely fixes the issue.
Well. The principle of Linux was and still is to give tools and have users use them. It gets out of the users way to use them. One can always use firejail or other sandboxing solutions to do that. Chrome itself is a security nightmare, always with the mic on and listening. Microsoft and Apple also have CVEs unattended. Binary checks before starting a program? Why I have a package-manager that does the checks. Untrust…
> Chrome itself is a security nightmare, always with the mic on and listening I can understand the mic being always on as a privacy nightmare, but how is this a security nightmare?
As the other guys said.
And it is not just that.
Chrome is, considering it's architecture and purpose, a minion in a botnet, working for google to harvest data.
They even got a lawsuit pending because they were even tracking users in privacy mode.
This stuff cannot happen with IE, or FF.
Brave, Vivaldi, I dunno, don't use them, but I am weary that they are using the same rendering-engine (and soon Redmond as well) (well depends where the G-men(what a pun) put their mischiveous code in).
Because it is a pipedream to expect a privacy-compatible product from a company that build it's empire on mining the users data to the bit.