6 ms·

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 anymo

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.

mindslight 2y ago
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.
- devops99 2y ago
  > 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. Both of the responses above were already written in the parent comment here https://news.ycombinator.com/item?id=42557398 https://news.ycombinator.com/item?id=42557398 And also already written in a parent comment here https://news.ycombinator.com/item?id=42559741 https://news.ycombinator.com/item?id=42559741 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 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 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. edits: fixed some grammar

mindslight 2y ago

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.

devops99 2y ago
> 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. Both of the responses above were already written in the parent comment here https://news.ycombinator.com/item?id=42557398 https://news.ycombinator.com/item?id=42557398 And also already written in a parent comment here https://news.ycombinator.com/item?id=42559741 https://news.ycombinator.com/item?id=42559741 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 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 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. edits: fixed some grammar