There's something kinda beautiful about this.
12 karma · joined November 27, 2024
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
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.
But this WAS NOT MY ARGUMENT. My argument, as posted here https://news.ycombinator.com/item?id=42557398, was:
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.
> 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.
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.
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
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.
And also already written in a parent comment here https://news.ycombinator.com/item?id=42559741
that has been demonstrated to work in production even for the most user-iest of users.
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.
edits: fixed some grammar
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.
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.
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.
https://www.usenix.org/conference/osdi21/presentation/fri-keynote
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.
Isolate Firefox traffic and observe it some time.
> 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.
> See "reflections on trusting trust".
Already saw it. You're welcome to see:
- https://guix.gnu.org/blog/2020/reproducible-computations-with-guix/
- https://reproducible-builds.org
- https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/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.
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.
Hence the security afforded by Signal is very weak in-practice and questionable at best.
Anything you can buy retail will for sure fuck you the user over.
We must implement as LAW that a SIM card can provide and only provide a Zero Knowledge Proof of "this SIM is valid for this cellular/data plan up to a specific date".
If they want to track us all the time, whatever, if they can't keep that data safe from the Chinese Communist Party, then they aren't competent enough to have it.
To any of Apple's lawyers that may ever happen to read this:
- lick my butt
- you can't stop usBut it's not a problem for me. It's also not a problem for most people. And it's not at all a problem next to the dumpster fire of closed source OS ; so ultimately there is no real problem.
Yet, all of that is moot, because someone already solved the problem. But I'll wait until they publish their work to talk about it.
I think we're all in agreement with this part.
While I empathize with these novice Linux users (who may not be self-aware they are as novice as they are), I do so to consider what a distro that avoids all of their problems would look like.
And, a big part of that is a huge colorful chart about what hardware is supportable and is not supportable during the install, along with the user typing out something like:
"I understand this hardware is not supportable and this is the fault of the vendor of the hardware. I understand that if I want a supported system I can buy one at https://ProductionLinuxInc ; furthermore, I understand and agree that by typing this acknowledgement and clicking "Accept" that I am legally bound to this agreement and legal penalties apply if I bitch about this operating system and my bitching either by its contents or what my bitching alludes to are factually wrong".These same billions, sans a very small fraction, don't even have "operating system" in their vocabulary. And as far as they are concerned, Chrome browser on one operating system is just as good as Chrome/Chromium on another operating system.
> Try installing a Linux program from 2005 with a UI made in any toolkit of your choice.
Personally I would not have difficulty doing this with containers. But there is no reason to do this at all. No sane and sober person wants this.
Containers have been around for over a decade now. This "no backwards compatibility" meme is utter horse shit.
Looking back on how things panned out, going all in on illumos a bit over ten years ago is something I wish I had done.
addendum: by "all in" I mean as an operating systems developer.
NOT GEEK SQUAD> because they come with all the dependencies starting with glibc
Good, because my system doesn't have glibc, by choice.
> Yeah, that will totally work
It's already working.
> And they weigh in hundreds of megabytes
My home connection is 2-gigabit symmetrical and the internal NVMe in my laptop is 4TB. So cry more poorfag.
We have already had this on Linux for years, it's called AppImage.
Total trash. Employee morale at absolute zero.