Wasn’t it a couple years ago the intelligence community was arguing for backdoor mandates, and now the FBI recommends Signal for safe chats? Such a farce. Hopefully the new admin goes through their emails and text messages over the last 4 years. Privacy for me, not for thee, I suppose…
"...implies that the attack wasn't against the broadband providers directly, but against one of the intermediary companies that sit between the government CALEA requests and the broadband providers"
Yup. The attack hit the CALEA backdoor via a wiretapping outsourcing company.
Which one?
Thank you for posting this. The search term "calea solutions"[1] also brings up some relevant material, such as networking companies advising how to set up interception, and an old note from the DoJ[2] grumbling about low adoption in 2004 and interesting tidbits about how the government sponsored the costs for its implementation.
where from ""...implies that the attack wasn't against the broadband providers directly, but against one of the intermediary companies that sit between the government CALEA requests and the broadband providers" comes from ? from schneier ?
because if you go to the actual reporting in wsj for example, it doesn't imply that attack was against TTP providers. also TTP providers are optional
wiretap systems are on the telecom provider side and it a bunch of different and in many cases ordinary networking equipment that can be easily misconfigured.
TTP (aka companies listed above) are optional and usually used by companies that don't have their own legal department to process warrants/want to deal with fine details of intercepts
Nothing contradictory (in philosophy), really: they said American law enforcement should be able to break encryption when they have warrants and they now say Chinese spies should not be able to.
This is obviously technically impossible, but the desire for that end state makes a ton of sense from the IC’s perspective.
Whatever method is available to American law enforcement is eventually going to become available to Chinese spies. The record of keeping this kind of secret is abysmal. If by no other means, then by social engineering the same access that local police departments were supposed to have.
Salt Typhoon - which this discussion is about - is an example. Tools for tracking people that were supposed to be for our side, turn out to also be used by the Chinese. Plus the act of creating partial security often creates new security holes that can be exploited in unexpected ways.
Either you build things to be secure, or you have to assume that it will someday be broken. There is no in between.
The FBI has a weird mandate in that it's both counter-espionage and counter-crime, and those are two quite different missions. Unsurprising to know that counter-espionage want great encryption, and counter-crime want backdoorable encryption.
You want the new anti democratic/authoritarian administration to look through the FBIs emails to find something to frame them for? You sure that's wise? Even if they don't respect privacy like they should?
It seems like every few years law enforcement puts out statements about how good encryption is for criminals, and then they have to walk it back as data breaches happen.
It doesn't take much to read between the lines on those two statements. Feds have access to Signal if they want it, but are using it as filter paper against most attacks against the public etc.
The "feds" do not have access to Signal, except by CNE attacks against individual phones. Signal's security does not rely on you trusting the Signal organization.
What are you talking about? Signal is open source, and its cryptographic security is trivially verifiable. If you don't trust the nonprofit behind it for whatever reason, you can simply compile it yourself.
> and its cryptographic security is trivially verifiable
That's going quite far. Even with all the details of it documented and open, there's a relatively small number of people who can actually verify that both the implementation is correct and the design is safe. Even though I can understand how it works, I wouldn't claim I can verify it in any meaningful way.
Sure, there are teams who have done it. But it's not trivial. The fact there's a price for it shows it's not trivial. If I choose a random developer, it's close to guaranteed they wouldn't be able to reproduce that. The chances go to 0 for a random Signal user.
Alternatively: it's trivial for people sufficiently experienced with cryptography. And that's a tiny pool of people overall.
The idea isn't that you do formal verification of the protocol every time you run it. It suffices for the protocol to be formally verified once, and then just to run that one protocol. If you thought otherwise, you might as well stop trusting AES and ChaCha20.
It is possible for the core protocol to be tightly secure, while a bug in a peripheral area of the software leads to total compromise. Weakest link, etc. One-time formal verification is only sufficient in a very narrow sense.
It is also possible for a state-level adversary to simply hijack your phone, whatever it is, and moot everything Signal does to protect your communications. Cryptographically speaking, though, Signal is more or less the most trustworthy thing we have.
In some sense, no - the protocol protects the contents of your messages. In another sense, yes - a compromised server is much easier to collect metadata from.
Metadata, yes. Of course, the protocols, and thus all the inconveniences of the Signal app people constantly complain about, are designed to minimize that metadata. But: yes. Contents of messages, though? No.
If Signal, the service, was designed to minimize metadata collection, then why is it so insistent on verifying each user's connection to an E.164 telephone number at registration? Even now, when we have usernames, they require us to prove a phone number which they pinky-swear they won't tell anyone. Necessary privacy tradeoff for spam prevention, they say. This isn't metadata minimization, and telephone number is a uniquely compromising piece of metadata for all but the most paranoid of users who use unique burner numbers for everything.
This is the most-frequently-asked question about Signal, it has a clear answer, the answer is privacy-preserving, and you can read it over and over and over again by typing "Signal" into the search bar at the bottom of this page.
The answer is not privacy-preserving for any sense of the word "privacy" that includes non-disclosure of a user's phone number as a legitimate privacy interest. Your threat model is valid for you, but it is not universal.
The question you posed, how Signal's identifier system minimizes metadata, has a clear answer. I'm not interested in comparative threat modeling, but rather addressing the specific objection you raised. I believe we've now disposed of it.
I don't believe there has been any such disposition in this thread. There have been vague assertions that it's been asked and answered elsewhere. Meanwhile, the Signal source code, and experience with the software, clearly demonstrates that a phone number is required to be proven for registration, and is persisted server-side for anti-spam, account recovery, and (as of a few months ago, optional) contact discovery purposes.
I don't know, a lot? They could with the same amount of effort just get Google to ship a backdoored operating system. Or the chipset manufacturer to embed a hardware vulnerability.
The cryptography is not where Signal is vulnerable. What Signal is running on, as in operating system and/or hardware that runs other embedded software on "hidden cores", is how the private keys can be taken.
Anything you can buy retail will for sure fuck you the user over.
Retail hardware actually has a better track record at the moment than bespoke, closed market devices. ANOM was a trap and most closed encryption schemes are hideously buggy. You're actually better off with Android and signal. If we had open baseband it would be better, but we don't, so it's not.
Perfect security isn't possible. See "reflections on trusting trust".
Bespoke but-not-really-bespoke closed-market devices made by the right people are very secure, but they are not sold to the profane (you).
> ANOM was a trap
Yes, ANOM was intended to be a trap.
> and most closed encryption schemes are hideously buggy
Yes they are. Hence some of us use open encryption schemes on our closed-market devices.
> You're actually better off with Android and signal.
I am better off with closed-market devices than I am with any retail device.
> If we had open baseband it would be better
And the ability to audit what is loaded on the handset, and the ability to reflash, etc. In the real-world all we have so far is punting this problem over to another compute board.
> Perfect security isn't possible.
Perhaps, but I was not after "perfect security", I was just after "security" and no retail device will ever give me that, but a closed-market device already has.
> Unfortunately there is no practical way to verify it either.
discuss an exceedingly clear assassination plot against the President exclusively over signal with yourself between a phone that's traceable back to you, and a burner that isn't. if the secret service pays you a visit, and that's the only way they could have come by it, then you have you answer.
I think the bar for paying such a visit would be infinitely high (they would find a way to defend in a more clandestine manner) to keep the ruse going.
Not all other messengers require a mobile phone number in order to get access, meaning not all other messengers have a view of users' social networks - some of them are anonymous, and Signal is not. It's a fundamental difference. But we've been here before.
We believe that all of the vulnerabilities we discovered have been mitigated by Threema's recent patches. This means that, at this time, the security issues we found no longer pose any threat to Threema customers, including OnPrem instances that have been kept up-to-date. On the other hand, some of the vulnerabilities we discovered may have been present in Threema for a long time.
For what it's worth, and obviously I could have been clearer about this: what's interesting about that link is the description of Threema's design, not the specific vulnerabilities the team found.
While the statments are contradictory I wouldn't take it as sign of some vast conspiracy. I would just take it as a sign they are stuck needing to give out some kind of guidance to prevent foreign access. While they are a domestic police service they are also a counterintelligence service and thus need to provide some guidance there.
US Military has atleast privately switched away from any Signal usage within the past few months – it’s undoubtedly compromised in some way. If the FBI is recommending it it’s for exploitative purposes & a false premise of safety.
Yeah, if a nation-state thinks you are a bad enough actor, they might use a high power way to get at you. See Pegasus, for instance
But those exploits are rare, expensive and can be blown.
No one has ever said Signal is perfect security.
But it is damn good. Your SMSes aren't sitting in plaintext on your mobile ISPs network. You aren't going to have them intercepted by a fake mobile tower. And if you and your recipients use disappearing messages, good luck to any prosecutor trying to get them off a device.
And as for Apple sending a fake update? Might could happen but 1) Apple fought this once and 2) it'd be hard to do in any widespread way without being detected
Saying Signal protects you from fuck all is not just wrong, it's irresponsible AF.
It's like saying that locks, firewalls, alarm systems, curtains and network monitoring don't work because some people know how to defeat them.
Signal is a great security upgrade for almost anyone. I love seeing more people use it.
The amount of one-off work this would take is quite high, so the amount of motivation for a company like Apple to say “No, you can’t legally compel us to to allocate engineering resources to this” is also quite high.
My point is that they (and other tech companies) would be highly incentivized against implementing something like a malicious update targeting a single device/user based purely on capitalistic motivations, rather than philosophical/ethical ones.
I wish I could agree with you but the real world doesn't work this way. Companies that don't play ball get broken up with anti-trust. Or what happened to the CEO (former CEO) of Qwest happens.
The "infrastructure" for the targeted updates is implemented by compartmentalized teams, who will be comprised of the clearance community, and the "external" people who work with them are a part of the clearance community.
>I wish I could agree with you but the real world doesn't work this way.
The real world does work this way. Businesses make business decisions based on bottom-line impact, and businesses generally push back very strongly against governments whenever a government asks them to do things that will cause them to make less money and/or waste money.
>The "infrastructure" for the targeted updates is implemented by compartmentalized teams, who will be comprised of the clearance community, and the "external" people who work with them are a part of the clearance community.
I agree that would be how it would work if it actually happened, but I think you overestimate the appetite (and even ability) of big tech to have any desire to do this kind of thing.
If you are implying that there are teams within big tech companies who secretly do this kind of thing, even against the wishes of other engineering teams (including security engineering teams) within the company... well that seems like a recipe for getting some of the company's most talented and highly paid security engineers incredibly pissed off if they ever find out — and it's very likely they would eventually find out, because it would be extremely difficult to hide this kind of thing over time.
How about you tell the former CEO of Qwest, or William Binney, or Jacob Applebaum how it is you are so sure you think the world works. I implore you, respectfully, to consider what they have told the world and give some time, on top of the time you have probably already given this topic -- give some extra time to this topic, after seeing what they have shared with us.
> and businesses generally push back very strongly against governments whenever a government asks them to do things that will cause them to make less money and/or waste money.
Did Facebook and Twitter do this when the federal government told them to censor?
What did Mike Benz' interview with Tucker (whether you dislike or like Tucker is neither here nor there so let's not get distracted by that) in February of this year (2024) reveal to all of us?
> of big tech to have any desire to do this kind of thing.
Apple is and always will be subservient to NSA, CIA, and the State Department. If you believe today -- after taking a moment to really, truly, seriously think about it -- that it is the other way around, you have a very special kind of stunted personal development.
> (including security engineering teams) within the company...
I respectfully implore you to look into the publicly available information about how many people at Facebook, Google, Twitter (pre-Musk), and Apple have NSA or other "glowie" backgrounds.
> well that seems like a recipe for getting some of the company's most talented and highly paid security engineers incredibly pissed off
You are correct here.
> if they ever find out
They won't, not unless they already have the appropriate clearance, and once they do they will take those secrets to the grave, or else -- unless they can make it to Moscow instead of a black site operated on foreign soil.
> and it's very likely they would eventually find out
Provided they can get into parts of buildings, buildings that aren't even on the same campus, that they aren't authorized to get into, which will never happen. So..
If your core value/goal is security, then it is tantamount to eliminate the potential for software that is not device owner-controlled to undermine Signal's security by stealing private keys. This means 1.] no closed source OS and 2.] no closed source software somewhere else on the system-on-chip either in the form of a closed source bootloader or "baseband firmware" or other "firmware" running on "hidden cores". This disqualifies all iPhones, Pixel handhelds, and Samsung handhelds.
If something else such as some kind of "user convenience" supersedes the core value/goal of security, then the below is not for you. But rich people and the economically less advantaged alike can all have this solution, one way or another.
The only way to achieve the goal is to run a modified "libre" (zero binary blobs) branch of GrapheneOS on a compute board that can load and run Linux without requiring any binary blobs to do so itself. This rules out any compute board (that I am aware of) that has a 5G radio on it. We could use a 5G radio as a WWAN card, but these all require closed firmware and we don't really have a way to protect a host system from them.
So, running another separate compute board that does have a 5G radio on it is necessary.
Another way to achieve the goal is a system-on-chip that is 100% libre and trustworthy, but good luck with that. Maybe the Librem 5 is (honest speculation) a viable candidate.
The secure boot problem is also not easy to solve. One way is a read-only SD card, but this has limitations. Another way is, and you might have guessed: another compute board. This isn't an uncommon pattern already, see F-Secure's Armory MK II device (which has a wireless chip on it that can be removed via heatgun).
Since we are already running more than one compute board, we can use additional separate compute boards for encryption and decryption, if we want to.
To interface with the board that runs GrapheneOS, a USB touchscreen that is smartphone-sized can be used. The culmination of all of this is a very small backpack containing the compute boards, battery, maybe antenna, etc.
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.
You're trying to step away from the mainstream thought for some very real reasons. But you have not developed good models to guide you once you're out in the woods.
I want to emphasize, I do want you to tell me how my approach is wrong, because if you can successfully do that then everybody wins. But if all you can contribute is this model is wrong but without specifying meaningful substance as to how then all you're really doing is sharting with your keyboard.
So, please do enlighten us to what you think the flaws are, or point out actual flaws, or some major gap. At the very least you'll be able to highlight what floating working assumptions I didn't manage to preempt. And, I'll honestly appreciate it a lot.
The "mainstream thought" is more concerned about what Steam games they can play than real-world InfoSec.
My "mainstream" is those who attend DEF CON, Blackhat, CCC, or FOSDEM, and also possess technical competency.
Ask anyone worth their salt if they can and should trust binary blobs.
Ask anyone worth their salt if they can and should trust retail system-on-chip that remain effectively undocumented, sans before the hardware source files hit the ODM.
If you believe "just trust me bro" regarding the kernel space binary blobs shipped with GrapheneOS or elsewhere on the system-on-chip is in the category of a "good model", those of us with seeking more than "just trust me bro" tier security are not your audience.
But the actual hackers in the world agree 1,000% with my mindset.
> But you have not developed good models to guide you once you're out in the woods.
I have GrapheneOS with zero binary blobs, and a solution based on compartmentalization that has been demonstrated to work in production even for the most user-iest of users.
If you believe you have something to contribute to improve it, please do.
I tried to keep my message brief and non-specific in hopes that you wouldn't jump on me. But alas.
The type of "model" I'm talking about are threat models that create practical security for yourself, without them "proving too much" and making you fall into the trap of designing bespoke solutions that solve the one problem you're focused on while creating many more.
> If you believe "just trust me bro" regarding the kernel space binary blobs shipped with GrapheneOS or elsewhere on the system-on-chip is in the category of a "good model"
No - but I believe it's the best security I'm currently able to achieve with a device that fits in my pocket, has long battery life, is in frequent contact with cell towers, and is inherently meant to communicate with other people running similar devices.
> I have GrapheneOS with zero binary blobs, and a solution based on compartmentalization that has been demonstrated to work in production even for the most user-iest of users.
If you think you've got a better approach for secure hardware to run Android on, then please by all means share! I would love to see it. So far, your allusions fit the all-too-common pattern of security through obscurity.
For perspective, my main desktop/server is an Asus KGPE with zero blobs in the main processor domain. I just don't see the point of fixating on this for the mobile ecosystem dumpster fire - over there mitigating mass surveillance is the best one can hope for. If you think you're a specific target of state/corpo attackers, then to me the current best answer is "don't trust your phone".
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.
