unhrpetby @ unhrpetby @sh.itjust.works Posts 0Comments 134Joined 5 mo. ago
I really like to get some feedback. Have fun everyone!
Remove the "MILITARY-GRADE" stuff. It doesn't relay any useful information and has been used as a phrase in countless crappy products.
...saying what newsom or allred said.
I don't know about allred, but if this is the Gavin Newsom statement you're referring to:
I think it’s an issue of fairness, I completely agree with you on that. It is an issue of fairness — it’s deeply unfair...
Then I don't understand how it goes from that to:
...cheering on as trans people are murdered in camps...
- Remote didn't work as well for the company.
- Remote didn't work as well for any number of people at that company.
matrix is cooked
...that proved that the algorithms/protocols work.
You can use a perfect algorithm and still be insecure because the implementation was bad. You are trusting the SimpleX Chat devs to a degree.
matrix is cooked
I wouldn't trust encryption made by anti-vaxer more than...
Important to note: SimpleX Chat has gone through two security audits.
matrix is cooked
The SimpleX Chat is AGPL. If the founder is problematic, one can fork it and avoid reinventing what has already been made.
matrix is cooked
It is forkable if necessary. I do think SimpleX is a great piece of software that shouldn't be reinvented because of the founder.
There was this recent attack to XZ utils, which shows that more attention is needed on the code being merged and compiled.
XZ was made possible largely because there was unaudited binary data. One part as test data in the repo, and the other part within the pre-built releases. Bootstrapping everything from source would have required that these binaries had an auditable source, thus allowing public eyes to review the code and likely stopping the attack. Granted, reproducibility almost certainly would have too, unless the malware wasn't directly present in the code.
Pulled from here:
Every unauditable binary also leaves us vulnerable to compiler backdoors as described by Ken Thompson in the 1984 paper Reflections on Trusting Trust and beautifully explained by Carl Dong in his Bitcoin Build System Security talk.
It is therefore equally important that we continue towards our final goal: A Full Source bootstrap; removing all unauditable binary seeds.
Sure you might have the code that was input into GCC to create the binary, and sure the code can be absolutely safe, and you can even compile it yourself to see that you arrive at the same bit-for-bit binary as the official release binary. But was GCC safe? Did some other compilation dependency infect the compiled binary? Bootstrapping from an auditable seed can answer this question.
...has a message for protesters in Brevard County...
You mean the "kill" message is for protesters who:
...throw a brick, a firebomb, or point a gun at one of our deputies...
Most entry points are through various other ways...
With encryption, the data is changed so that only the key could decrypt it. If there are no encryption backdoors, then the key is the only end goal of attack. Compared to a physical lock, where, even if the lock was perfect, you still need to secure the structure it locks.
Most entry points are through various other ways, which is also why i find GrapheneOS for the average user stupid.
I still appreciate defense against the less common. Easier to focus on the more common.
Just because stuff is sandboxed and you have some Ad-Blockers on, doesn't mean shit these days.
Sandboxing and Ad-blockers are quite different. One gives restricted permissions, so a program has less tools to be able to cause harm, and less visibility into the system to violate privacy. Ad blockers need only to stop an ad from displaying. The security and privacy gain would likely only come from stopping you from clicking them (since they're blocked), or stopping the resources from being networked to in the first place.
Sandboxing I would consider much better for security and privacy. That's why its a valuable tool for security researchers.
They support 3 devices under the "main" branch.
I've used quite a lot of software in a "community" repo. It can certainly work. Will of course depend on the device you are using.
some will never see further updates after getting them to work once.
For it to be in community, their wiki states in needs to be actively maintained. Granted, I'm sure there is a window of time before something goes back to "testing" or "archived"
...binary blob for as driver and not the source code.
Just as I want free firmware in the desktop, laptop, and server Linux space, I hope we can move toward that in the mobile space as well.
...won't meet the security requirements of the Graphene OS team.
I'm sure it doesn't. I've read their statements on such things. Simply change the requirements.
There is a fairly all-or-nothing-security group of people within the GrapheneOS community. They will defend using a Google device on the claim of enhanced security.
Security is nice, but I'll take a hit to security if it means I get to support the growth of an ecosystem that respects the user.
...for the entire hardware...
Referring to Pixel hardware? I also don't think they should be building on top of Pixels.
...would take years until you have an even halfway working device.
PostmarketOS seems to support many devices. So its doable. I would prioritize something like the Pinephone though.
frankly i just laugh at the concept of safe and secure, anyone who seriously wants into your device will get into it.
This is paranoia.
it's the same as physical locks.
Encryption works very differently. A user can encrypt a machine with an Argon2id password that requires 1GB of ram per parallel attempt, requires an average of 1s per attempt, and would take every computer on earth billions of years for a 0.1% chance to crack it if they all worked in parallel.
It's not even close to as insecure as a physical lock.
...if the US government wants into your phone they will get into it eventually.
The US government doesn't have magic word to break into every device. That is paranoia, unless you're talking about "if given an infinite amount of time...".
Should've built upon straight Linux rather than Android.
Malware would explicitly have to be executing a terminal for a window to popup. They can just call a shell directly.