A solution in production today I am aware of is new to some (and very not new to others) and relatively still somewhat novel, but it is not really bespoke anymore, this pattern specifically was standardized many years ago. I am also aware of relatively young hackers implementing these things themselves.
An in-kernel binary blob, and untrustworthy binary blobs running on other "hidden cores", very similar to the Intel ME/AMT situation, is a problem that many acknowledge is very serious. Perhaps I am among few who attempted to solve this problem, and did solve this problem, but I am not at all in a minority who view it as a very serious, and intolerable problem. Anyone worth their salt does view the problem as intolerable, the difference on our side is we did something about it.
> the one problem you're focused on while creating many more.
What "many more" problems do you speculate have been created with this approach? This is what I was hoping you could contribute, but I don't see this in your response. I wish I could write that I am disappointed.
> So far, your allusions fit the all-too-common pattern of security through obscurity.
Eliminating binary blobs that run in kernel space on the compute board where the user's messages are decrypted and displayed is not "security through obscurity", this is a hard technical difference and is not obscurity.
I am rather disappointed that you spent the time to respond, yet either did not read my previous post, or did not comprehend it, or just didn't consider the implications ; I believe the third is the case.
As you implicitly acknowledge yourself, an ASUS KPGE with zero blobs, we CAN NOT run binary blobs in kernel space, or binary blobs in an Intel ME/AMT equivalent situation, and have a system we can -- if we are being honest with ourselves -- trust to be secure.
> I believe it's the best security I'm currently able to achieve with
Our "device" does not fit in the pocket, we don't at this time have the means to fit it in a pocket, so we did not attempt this. Users who value the pocket experience over an ipso facto secure device are not our audience (and we don't respect such users). What we have does have better battery life than a device intended for a pockete, better radio connectivity to cell towers, and is inherently meant to also communicate with the lowest common denominator.
What our device also does, is provide a fair playing field for open source software to achieve meaningful security with others who also acted on a better value system by making a choice to do so.
Yes, the network effect is small, but when the other users are your spouse, or your children, or your best friend, or the other board members of a corporation you oversee, or members of your congressional staff, or a journalist, the network effect although not quantitatively meaningful is qualitatively extremely meaningful.
> If you think you're a specific target of state/corpo attackers, then current best answer is "don't trust your phone".
Thank you for acknowledging the problem we solved, you arrived at the same answer we had already arrived at: do not trust the system-on-chip running binary blobs on hidden cores with a binary blob bootloader and also binary blobs in kernel.
> but I believe it's the best security I'm currently able to achieve
My camp, fortunately, has different capabilities.
> then please by all means share! I would love to see it.
I expect someone will be able to do this in a proper way this coming year. At this time I post what I can post here because I would like to see others who have the wherewithal -- which is a matter of willpower, not economic status -- do this.
As of today, the general software developer / IT admin but-not-actually-a-hacker crowd has no idea how fucked it really is.
You still have not described your answer in concrete terms, yet you continue to boast about it. This is the crux of the problem.
Piecing it together - it sounds like a larger piece of kit, the main application processor running deblobbed Graphene, with the radios isolated out over USB. Sure, that's always been possible... but what's the draw? Once you're larger than the fits-in-pocket form factor, your comparables include a straightforward deblobbable laptop with WWAN that can just run a libre OS that wasn't created by a surveillance company.
But sure maybe you're aimed at Graphene enthusiasts who are focused on its additional security features despite its adversarial lineage. But why not come right out and say that? Instead of focusing on the positive value, you're basically just shitting on everything else.
Then furthermore, this whole thing started with you condemning Signal itself [0]. If you're solving the treacherous hardware/firmware problem, then what the heck are you using as a messaging program if it's not Signal or similar? Which is why I'm talking about the worries of bespoke solutions...
[0] personally I don't really use Signal because the whole mobile-first trust-Google teetering-on-the-edge-of-proprietary thing has always left a bad taste in my mouth, and practically it's just unwieldy to tie myself to a program that's stuck on the phone I leave by my front door. But it's hard to argue that it isn't secure within the context it's carved out for itself.
> Once you're larger than the fits-in-pocket form factor, your comparables include a straightforward deblobbable laptop
To add some further clarity, some people use our solution at music festivals, the kinds of music festivals where people camp outdoors for a few days at a time.
Try "texting" your dad (who also has the same secure mobile solution), texting your girlfriend (who also has the same solution), and your buddy you met at another camp two days ago, while waiting to be served a drink while you're also half-way tripping balls. Not happening on a fuckin' laptop, brah.
> Once you're larger than the fits-in-pocket form factor, your comparables include a straightforward deblobbable laptop
A laptop is NOT a comparable user experience to something someone can hold in their hand while on foot:
a USB touchscreen that is smartphone-sized can be used. The culmination of all of this is a very small backpack
> maybe you're aimed at Graphene enthusiasts
Very rich people and their families already have these kinds of solutions. Other people who are rich in other ways (hacker's mind and motivation) also already have these kinds of solutions.
that has been demonstrated to work in production even for the most user-iest of users.
> with the radios isolated out over USB. Sure, that's always been possible...
And some people actually went ahead and did it. The core idea was not my original idea, it had been done already in one form or another (though not as refined as ours') quite long before. All my camp did was package it so that non-technical people could have something that "just works". Many of the users of these solutions are not technical at all.
A combination of USB and ethernet. In some of these setups the "radio" is a retail Android device that is connected to ethernet via USB.
> Then furthermore, this whole thing started with you condemning Signal itself
Nothing I wrote condemns Signal, but simply confronts the hard reality that Signal does not protect users because by virtue of the platforms Signal runs on de facto, Signal can not protect users. Signal can protect users on my camp's devices however, as was already explained here https://news.ycombinator.com/item?id=42556652
> because the whole mobile-first trust-Google teetering-on-the-edge-of-proprietary thing has always left a bad taste in my mouth
I appreciate that you landed on the some of the same answers that I and others near me did. The key difference is we went ahead and acted on these concerns.
> You still have not described your answer in concrete terms
I feel I have shared more than enough that a thinking person can put 2 and 2 together. I also already already wrote "I expect someone will be able to [release this information] in a proper way this coming year." here https://news.ycombinator.com/item?id=42560339
Your limits within reasonably expected reading comprehension have exhausted my available patience. That said, relative to the rest of the world, we likely have more in common than not.
Scattering tidbits around in different comments while including dodgy unsubstantiated appeals to authority like "Very rich people and their families already have these kinds of solutions" does not make for a compelling argument.
It sounds like you have something real, that solves a real problem while adding its own drawbacks, that works for your requirements. Focus on the specific value proposition, including the specific technical details in technical forums. Otherwise, you just sound like a crank. And the security field has a long history of cranks arguing against mainstream advice to sound edgy and authoritative (eg what you said regarding Signal) while then pushing their own bespoke solutions that survive through lack of scrutiny.
What I am showing you is I already answered your question, you fail at reading comprehension, or you fail at comprehending the very concepts themselves. Probably the latter.
> that could solve a real problem, while adding its own drawbacks.
It already solved a real problem. I have asked you repeatedly to specify a real-world drawback other than the physical profile (which the users find tolerable), you have not done this successfully.
> Focus on the specific value proposition
We already did this, and delivered.
> arguing against mainstream advice
Mainstream advice in the security world is, to consider a device secure:
- do not run binary blobs in kernel space
- do not run binary blobs in higher-privileged cores on the board
> (eg what you said regarding Signal)
The concept that something running in userspace can not protect users when 1.] the host OS is already compromised (binary blobs in kernel space) and 2.] underlying "hardware" is already compromised (via firmware on higher privileged cores, similar to Intel ME/AMT) is EXTREMELY MAINSTREAM.
> appeals to authority like "Very rich people and their families already have these kinds of solutions" does not make for a compelling argument.
Very rich people and their families already have these kinds of solutions. Other people who are rich in other ways (hacker's mind and motivation) also already have these kinds of solutions.
The authority that I did appeal to, ultimately, are Systems Administrators and relatively novice hackers equipped to prepare these solutions for themselves.
> their own bespoke solutions
The pattern was standardized over a decade ago. Our own implementation is already standardized with enough units in production that it's not bespoke anymore.
> that survive through lack of scrutiny.
If you were capable of implementing this solution on your own, which you have already effectively admitted you are not, then scrutiny from someone like yourself would be worth more than two rat shits, but you can not, so it is not.
At this point, you are clearly a midwit intelligent enough to comprehend what I have posted, but you still continue to post utter garbage. And ultimately I perceive you as a moderately mentally ill fucking moron.
You keep saying you have a device that solves the problem, but you don't provide any actual details above what everyone already knows. You keep insulting people when they call you out on it. Either show your hand or be more humble. The other options don't make you look good, trustworthy or competent at all.
The people (other than me) in this thread have provable track records talking about this field. They're asking for more details and you just keep insulting them.
What we did was put de-blobbed GrapheneOS on a compute board, put secure boot on another compute board, punt the radio onto a separate compute board, add a battery, and manage it all with a management board in a small backpack, with a USB touchscreen for user interface.
Then we productized it for select groups of people.
But, it's really not that complicated. Like it's really not. Many people have built these kinds of things before.
If you want to try to tell me that mindslight has a "provable track record" talking about this field, I have a very very hard time believing something like that because -- and I'm being honest here -- as any reasonable person will also conclude: his responses he has posted here are really fuckin' stupid.
I would at a later time directly link to you the next-generation builds that we do have permission (the previous was not my corp) to make public-facing in 2025, as I already wrote in another comment. However, your overall reply is kind of dumb. So, if you feel you are entitled to demand a "finished product", build it yourself.
And, yes, I will continue to look down my nose at you as someone who is grossly inferior to me.
As someone grossly inferior to you I welcome your constructive feedback and I hope that many others adopt your attitude and social behaviour. Only in this way can we truly improve our world.
All hail devops99 and may the platforms that you build be favoured by your subjects, as unworthy as they surely are.
I suggest you re-read the entire thread and try to see your replies from a perspective other than your own. I don't think you realise how terrible you look here. It's not just the general cringiness of over confident youth, it's the doubling down on false superiority, the stench of antisocial tendency and the immature claims of success without the slightest hint of any evidence.
I'd be pleasantly surprised, and believe you'd achieved a modicum of self awareness, if you just deleted everything you posted here. But I fear that would be out of character...
If everything you posted in this thread wasn't so demonsrably, and pathetically stupid, I might be able to take you somewhat seriously. But they are, so I can't.
What do you get out of attacking everyone who engages with you?
Sorry to be the one to break it to you, but your description isn't that technically interesting - no aspects of getting Graphene running on the devboard, or other difficulties integrating the parts. The idea of separating out the baseband isn't really novel either. A decade ago I gave a shot at using a mifi+tablet to move in that direction, and to see how far I could get without a proper voice plan. (I eventually got bored and moved on). You're not sitting on some super special idea here, and this vague passive voice "existence proof" style of writing is cagey and tedious to read. Which is probably how I ended up skipping over some actual details.
But do you know what is very interesting? That you've found a niche where the backpack form factor isn't a huge drawback, as well as group(s) of people who actually appreciate the threat model enough to keep spending extra effort doing a nonstandard thing. Those are all social factors that could actually sustain this type of device, rather than merely being passing curiosities that users eventually move on from. Basically it needs to be easy for people to piece together such a setup while mindlessly following a guide, as well as point other curious people to a description of it - the polar opposite of the trash elitist attitude you're pushing. (eg what specific dev boards straightforwardly run Graphene? I don't see any listed on the website)
And so if you actually care about widespread communications security rather than just being some combative wanker on a message board, please please please try to level up your wisdom for your next sockpuppet nym.
> of people who actually appreciate the threat model enough to keep spending extra effort
The "product" is already successful. Some spent effort, others spent money.
Those who did the latter include defense contractor or other government backgrounds, ""conservative"" (aka normal people) moms who were censored on Facebook and Twitter as early as 2019 and had enough pattern recognition to know the unlawful censorship reached all the way up into the federal government, journalists, and some are in the category of politician.
Think of what Tucker Carlson shared with the public "the NSA got into my Signal account, which I didn't know they could do". I don't expect our solution to stand up to NSA, but unlike a retail device the starting point of the digital playing field on my camp's solution doesn't let digital intrusion be a cakewalk for "glowies" like retail devices do. Glowies have to work significantly harder to compromise what we have.
Some of the "Instagram famous" gen Z stereotypical "hot girls" who are computer illiterate and generally aloof (vapid on the surface) were immediately willing to tolerate the overhead of "touchscreen cabled to a backpack" when they were told "when you do a call with mom or dad, that call does actually stay protected". Trashy aka "low socioeconomic status" people don't give a shit about family privacy/autonomy, but these people do give a shit about it.
All aforementioned categories of users have already experienced suffering abuse, or anticipate being abused, or they simply have enough dignity in their life that they're not going to just give it away like typical retards do ; they are not going to "eventually move on" from "this computer I carry on my person every day is not designed for me to get fucked over" and then downgrade to a retail device that is by design (in one way or another) positioned to fuck them over. Sans a "burner" device for some specific narrow purpose (Instagram presence) that has had its internal mic gutted and has hardware shutters on its cameras.
The technical concept is what I am allowed to post about so that's what I did. As I already wrote earlier (and also then later cited I had written), something cohesive will be posted later this year, and if the person I expect to do it doesn't then I'll do it myself. Or, one of the other existing players in the space will, or someone else entirely (and I'd be perfectly happy with that).
.
> You're not sitting on some super special idea here
I appreciate you acknowledging this point, a point that I had emphasized, and I feel I had done so rather clearly, several times above. Many Qubes users have been doing this since 2018.
The essential thing my camp did that was "special" was package it professionally in a way that "normie" users can succeed with it out-of-the-box.
Like with any specific operating system and hardware combination there are implementation specific bugs here and there, but nothing major.
.
> how far I could get without a proper voice plan.
Some use "2FA mule", like this https://kozubik.com/items/2famule/ ; though we advise to physically remove the microphone of the 2FA mule and presume any WiFi/Bluetooth traffic from it is hostile.
Those who need PSTN (legacy phone network) voice or 911 can use another device for that.
No one using our mini-backpack is missing out on any functionality they actually need.
.
> eg what specific dev boards straightforwardly run Graphene? I don't see any listed on the website
I do appreciate you bothering to look. I actually do. There are boards that can run with zero blobs, they are intended for production use as sold, so long as they can run a Linux kernel and have a GPU that Android can use, they can run GrapheneOS.
Our solution is not supported nor known about by the GrapheneOS project, we have our own branch and cicd and all that.
.
> Which is probably how I ended up skipping over some actual details.
Yeah, the performance (or lack thereof) of your reading comprehension has been rather noticeable.
.
> the polar opposite of the trash elitist attitude you're pushing.
Okay but no matter what happens, I will always get more money and more pussy than you.
An in-kernel binary blob, and untrustworthy binary blobs running on other "hidden cores", very similar to the Intel ME/AMT situation, is a problem that many acknowledge is very serious. Perhaps I am among few who attempted to solve this problem, and did solve this problem, but I am not at all in a minority who view it as a very serious, and intolerable problem. Anyone worth their salt does view the problem as intolerable, the difference on our side is we did something about it.
> the one problem you're focused on while creating many more.
What "many more" problems do you speculate have been created with this approach? This is what I was hoping you could contribute, but I don't see this in your response. I wish I could write that I am disappointed.
> So far, your allusions fit the all-too-common pattern of security through obscurity.
Eliminating binary blobs that run in kernel space on the compute board where the user's messages are decrypted and displayed is not "security through obscurity", this is a hard technical difference and is not obscurity.
I am rather disappointed that you spent the time to respond, yet either did not read my previous post, or did not comprehend it, or just didn't consider the implications ; I believe the third is the case.
As you implicitly acknowledge yourself, an ASUS KPGE with zero blobs, we CAN NOT run binary blobs in kernel space, or binary blobs in an Intel ME/AMT equivalent situation, and have a system we can -- if we are being honest with ourselves -- trust to be secure.
> I believe it's the best security I'm currently able to achieve with
Our "device" does not fit in the pocket, we don't at this time have the means to fit it in a pocket, so we did not attempt this. Users who value the pocket experience over an ipso facto secure device are not our audience (and we don't respect such users). What we have does have better battery life than a device intended for a pockete, better radio connectivity to cell towers, and is inherently meant to also communicate with the lowest common denominator.
What our device also does, is provide a fair playing field for open source software to achieve meaningful security with others who also acted on a better value system by making a choice to do so.
Yes, the network effect is small, but when the other users are your spouse, or your children, or your best friend, or the other board members of a corporation you oversee, or members of your congressional staff, or a journalist, the network effect although not quantitatively meaningful is qualitatively extremely meaningful.
> If you think you're a specific target of state/corpo attackers, then current best answer is "don't trust your phone".
Thank you for acknowledging the problem we solved, you arrived at the same answer we had already arrived at: do not trust the system-on-chip running binary blobs on hidden cores with a binary blob bootloader and also binary blobs in kernel.
> but I believe it's the best security I'm currently able to achieve
My camp, fortunately, has different capabilities.
> then please by all means share! I would love to see it.
I expect someone will be able to do this in a proper way this coming year. At this time I post what I can post here because I would like to see others who have the wherewithal -- which is a matter of willpower, not economic status -- do this.
As of today, the general software developer / IT admin but-not-actually-a-hacker crowd has no idea how fucked it really is.