Conversation

dropping CCs at request Anyway, all said I agree with you. But the concerns you mention here are also true of Android devices. I would rather have physically replaceable radio modules and then work on reveng or memory isolating the drivers. twitter.com/DanielMicay/st

This Tweet is unavailable.

Replying to

Big difference between a device with components that are strongly hardened, highly audited and have good ongoing security support vs. the complete opposite. Also, portraying it backwards by misinterpreting how DMA / IOMMUs work is just wrong.

Lance R. Vick ( @lrvick@mastodon.social )

@lrvick

Sep 11, 2020

Replying to

@DanielMicay

You can't claim hardware is secure you can't see the firmware for. Tomorrow's update could be hostile. You present a fair argument though. We either design to distrust the radios, or we might as well blindly trust their updates. I am convinced here.

Replying to

Devices you're talking about have entirely closed source hardware and firmware. If you choose components that are known to be insecure and also don't apply fixes to known security vulnerabilities, backdoors are a non-issue, because you have the front door wide open to attackers.

Replying to

and

You're also once again misrepresenting closed source software as a black box. It isn't, and in fact, if you're looking for malicious, hidden backdoors, I do not really see how you're any better off trying to find them hidden in source code vs. from the final assembly code.

Replying to

and

There is a whole compilation pipeline leading to that assembly code and all of the fancy language / compiler features, etc. are tools for the attacker to hide / generate their backdoor. Also, really, when it's full of unintentional vulnerabilities, how is any of this relevant?

Replying to

and

Why are you okay with using the Linux kernel when it's full of remote and local code execution backdoors? You talk about theoretical backdoors when there are real, unintentional (supposedly) backdoors called vulnerabilities which you don't seem in a rush to get fixed...

You’re unable to view this Tweet because this account owner limits who can view their Tweets. Learn more

Replying to

and

I don't think there's much of a useful conversation, and I don't agree with that take on it at all. Been going on forever from a previous mess of threads and it's clearly going nowhere and has pretty much no point. I've gotten no value from it and it's just a waste of time.

You’re unable to view this Tweet because this account owner limits who can view their Tweets. Learn more

Replying to

Interested to hear how GrapheneOS is a 'nightmare' to use as a downstream in a way that CalyxOS is not. Sounds like a load of bullshit to me. Also having a hard time understanding how that's relevant to this thread.

7:09 PM · Sep 11, 2020Twitter Web App

Replying to

If people want a hobbyist smartphone platform they can buy a Pinephone or something else along those lines instead of getting ripped off by scammers and the evangelists pushing their products based on their dishonest marketing claims and misinformation.

You’re unable to view this Tweet because this account owner limits who can view their Tweets. Learn more

Show replies

You’re unable to view this Tweet because this account owner limits who can view their Tweets. Learn more

Replying to

Lack of documentation? Funny. So you're doing what, building CalyxOS based on what you learned from the GrapheneOS documentation, which is how that project exists at all? Makes a lot of sense. You've never been a customer (we don't have any). Are you saying you reported bugs?

Show replies