Qubes (used to? still has) issues with other graphic cards. Best would be to stay out of hardware recommendations for Qubes and leave that to Qubes.
the information might get outdated
the information might get contested (such as above). Time consuming to reason about, providing references.
it’s overextending the scope of Whonix project
The best place for Qubes hardware recommendations should be Qubes places, i.e. probably mostly Qubes website. If information on that website is bad, contribute to it. And if that’s not an option, well, bad luck but still not good to do that task for Whonix to maintain.
It’s dishonest to claim Kicksecure (even when all the hardening work is complete) is as secure as mobile platforms. Those have decades of work gone into hardening the security model.
Security is not just a checklist of features. Kicksecure’s sandboxing/MAC/verified boot/etc. isn’t even near iPhone/Android and there are numerous security enhancements in phones such as modern exploit mitigations or widespread memory safe languages that are not achievable with Kicksecure.
The claim that most Android devices have locked bootloaders is also dubious. Unlocking the bootloader and even using custom keys is part of the reference implementation.
I disagree and then you are going to say “I don’t have to to refute them”. I.e. no agreement will be reached. But it’s not necessarily you that has to refute them anyhow. GNU/FSF are popular. Meaning:
If GNU/FSF make libelous claims, it is likely that they will be on the receiving end of a defamation lawsuit. This didn’t happen yet to my knowledge.
The internet is big. Others would have made a rebuttal. If you can find a good one, that might be a a good alternative as rebuttal.
Any write-up is non-perfect and the GNU one was a comprehensive one.
Agreed. Who build the security and for what purpose. Benefit of user or maximizing profit at expense of privacy and security from vendor.
It’s besides the point. Please don’t cling on a single phrase “Level Security” and then view everything through that lens. That chapter has to be viewed in a bigger context.
The headline iPhone and Android Level Security for Linux Desktop Distributions is also bad for other more pragmatic reasons. Through conversations I’ve learned that many people know about how bad many phones/mobile apps are in their default configuration for privacy they equate this with security, and then intuitively discard the idea that iPhone / Android have any worthwhile security features worth porting to Linux desktop. I.e. even if iPhone and Android Level Security for Linux Desktop Distributions was fully possible in theory and even if madaidan would agree, it would still be bad self-representation of the project. Will change chapter title to Kicksecure Development Goals.
Big companies like Google or Apple don’t care about them.
I’m not clinging to that. I don’t really have much of an issue with the title.
Just look at the comparison table. It’s wrong to pretend that the full system MAC policy in Android and Kicksecure are similar. SELinux is ingrained into Android’s architecture and the entire ecosystem was shaped around it. Additionally, SELinux allows for far more restrictive policies (e.g. ioctl filtering or even just stricter permissions for files) than apparmor.
We’re slapping an apparmor policy on top of an OS that it wasn’t intended for. While this is good and we can make some great progress with it, it’ll never be as good as a strict policy on top of an OS that was designed for it.
Another example is the hardened kernel row. Our hardened-kernel is nice but it’s not the same as Android. Android kernels contain a lot of hardening patches including fine-grained forward-edge Clang Control-Flow Integrity and ShadowCallStack to prevent code reuse attacks (CFI/SCS is only on Pixels >=3 though). CFI isn’t in mainline or linux-hardened and won’t be for a long time. ShadowCallStack isn’t even possible on x86 due to the way it handles returns.
Although, I’m looking more into Android/Qualcomm’s hardening patches and might submit some to linux-hardened (I’ve been talking to Daniel Micay about this on Matrix).
The comparison table is also neglecting to mention all the advantages of Android over Kicksecure. One example is that Android has the majority of the system written in memory safe languages (Java). Another example is that Android/iPhone has modern user space exploit mitigations like CFI/PAC.
This subject is too complex to be a simple Yes/No comparison table which is why I removed it and expanded a bit below it. What I meant by “Security is not just a checklist of features” is that the implementation matters. Not the general topic. Sure, you can have a “sandbox” but that doesn’t mean it’ll actually restrict anything meaningful for example.
I don’t think it should mention mitigations specifically since it’s not just mitigations vendors introduce. They add tons of bloatware that contain their own security vulnerabilities. I’ve found Samsung to be particularly egregious in this regard although sane vendors like Google are usually fine.
I’m not. The comparison table just doesn’t make sense.
I missed those, misunderstood, disagreed etc. But anyhow. It’s too much of a detail for me to spend time on it. As said…
…unless there’s a better, similar write-up, the the current links are good enough and I won’t debate them further.
It’s still missing the purpose of that comparison table / chapter. It’s not an security from exploitation from third parties comparison table for Android AOSP vs Linux desktop/server distributions.
That’s good to know and valuable knowledge but again not an security from exploitation from third parties comparison table for Android AOSP vs Linux desktop/server distributions.
It would be a net benefit for the knowledge of the world if this information was documented somewhere. But not on whonix.org. Too time consuming and too far off-topic from the goals of Whonix project to get involved deeply involved into creating a perfect comparison table or write-up on that subject. Wikipedia might be interested to host this information or any other more general knowledge wiki / comparison site. I would certainly a minimum be a reader. Probably also add a link to it from Whonix wiki. Having this information well laid out could help to get these issues fixed. Without awareness of the issue it’s even less likely of getting fixed.
Hmm… ZeroNet various websites always results in this error: “Content.JSON Download Failed”. JS allowed on 127.0.0.1 and can see a number of peers so not sure what the problem is. Maybe like I2P you have to let it run for a long time beforehand?
Logs also show for various website attempts: “ContentDb not initialized, load files from filesystem…”
Have you succeeded in Qubes-Whonix @Patrick. Does about:config need some more tweaking perhaps? The home page works okay.
PS @madaidan Don’t waste all your talents & time on those reddit trolls. It’s like screaming into the void.
Spend more time over here doing your great development work!
Because it shows that others managed to implement these features and it’s realistic to re-implement in Kicksecure - without adding any privacy issues or user freedom restrictions. It’s to tease and encourage other developers to catch up implementing some of the iPhone/Android security features in Linux (desktop) distributions too. If it gets added to Kicksecure that’s great, but if others focus on other Open Source Linux distributions that’s a net benefit too.
And if you’re wondering why it lists some disadvantages of iPhone/Android are listed, that’s to show in how many ways others are messing up. Tor create awareness of these issues (precondition for fix) and to not mess up in similar ways in future. Illustrating project goals, values, awareness.
Concept of Open/Free/Libre Software is great. However, since the inception of the 4 original essential software freedoms, other issues came up sometimes called tivoization, malicious feature, antifeature, tyrant software, treacherous computing or DRM (digital restrictions management). Also data portability, open databases, open source hardware, first mover effects, network effects, and more.
We have enough walls of texts. Some like tables, some don’t. In this case I found a table to be looking good.
A clear credit is given up front to the author: “The description of this procedure draws heavily upon the following guide: The Complete Guide to Secure Communications with the One Time Pad Cipher [archive]; all credits go to the author.”