231–240 of 372 posts
Earlier quoted context omitted.
https://xkcd.com/1200/
this is actually not the case on modern android lol
Earlier quoted context omitted.
GrapheneOS releases patches very quickly, often even faster than OEMs do. But patches are only useful for fixing individual known vulnerabilities. GrapheneOS additionally focuses on defending against whole classes of vulnerabilities. [1] For example, in addition to fixing memory corruption bugs in individual system components, GrapheneOS has deployed memory protections for the entire OS in the form of hardened_malloc…
> GrapheneOS is fully open source Not really. There is a bunch of proprietary firmware running on those phones, which can be exploited with or without the help of the manufacturer.
> Notably, the Pixel 10 series is moving away from physical SIM cards. Is it? I hadn't followed news of the new Pixels. I don't like the idea of modernizing this and going full eSIM. It will introduce a lot of new friction, somehow I don't doubt it. Just now arrived to Mexico for a quick trip and grabbed a prepaid SIM from a 7-11 in the airport. All quick and simple. I doubt things would be so seamless when not havin…
The process for migrating eSIMs for me has never been easy and has always taken 1-2 days and repeated contacts with customer service agents to actually work. Compared to the 10 seconds of swapping a physical SIM. I'm sure there isn't an inherent technical reason why eSIM couldn't be just as easy if not more, but I assume it's another case of enshittification.
eSIMs are designed around "the user is the attacker". So you can't do things like transfer profiles from one eSIM to another offline, by design. What the "transfer" really does is kill the old profile and issue a new one for a new eSIM.
It still could be designed for less user friction. But the whole ordeal could be avoided if eSIM wasn't designed to be user hostile in the first place.
Earlier quoted context omitted.
GrapheneOS isn't made by volunteers. They have a team of around 10 paid developers. They are a nonprofit foundation that receives donations and uses those to pay developers, infrastructure etc. Ars Technica has update its article to rectify that mistake. It doesn't mention that anymore.
It’s still a valid question. We have this huge corporation that’s doing so many things, constantly lobbying for policy, obscene revenue all while people are exploiting the apk out of their OS. In fact, looking at the news this week, the same question applies to Microsoft and Apple as well. Are they too big and distracted to care about security?
Google generally has the reputation of doing much better in those areas.
Not sure what would be objective measures to compare.
Earlier quoted context omitted.
“By a truly unbelievable coincidence, I was recently out for a walk when I saw a small package fall off a truck ahead of me” Hahahha. Also is this a common expression “fallen of the back of a truck”?
In France it is indeed a popular expression that means 'stolen' or 'acquired by non-disclosable means'
Earlier quoted context omitted.
For iOS there's a slightly newer one released in July 2024 which indicated iPhone 15 support too: https://discuss.grapheneos.org/d/14344-cellebrite-premium-ju...
Honestly seems like if you just stay on the latest-and-greatest you'll stay ahead of Cellebrite long enough. I'll be amused when Apple finally drops a portless iPhone as the next step ahead. (Apple already has their Qi2/Magsafe setup, and they already have been using 60GHz wireless USB for quite some time now internally with the Apple Watch for diagnostics and service management since Series 7.)
I don't know, even the latest and greatest is eventually cracked, or they can just hold your device in evidence until the capability is there a few weeks (or months) later.
Furthermore by using an official OS from a vendor like Apple (or Google, Samsung) there's always the possibility that they could target your device with a specially crafted update, especially if you're in really big trouble.
Earlier quoted context omitted.
GrapheneOS releases patches very quickly, often even faster than OEMs do. But patches are only useful for fixing individual known vulnerabilities. GrapheneOS additionally focuses on defending against whole classes of vulnerabilities. [1] For example, in addition to fixing memory corruption bugs in individual system components, GrapheneOS has deployed memory protections for the entire OS in the form of hardened_malloc…
Reminds me of that one case a few weeks back where Graphene wasn't allowed to release a patch because Google wasn't planning on releasing a patch for it for a few more months.
They couldn't answer the question most on my mind: "We’ve reached out to Google to inquire about why a custom ROM created by volunteers is more resistant to industrial phone hacking than the official Pixel OS. We’ll update this article if Google has anything to say."
If GrapheneOS skips contacting remote servers like that, they would not be vulnerable.
It would be a story of Google prioritizing tracking over security.
Earlier quoted context omitted.
Now in grapheneosin the updates settings it allows you to apply Google's upstream security patches, but grapheneos is forbidden from releasing the source code for these until a certain time later. You can read more about it on their blog. I have them enabled. At least I can rest easy knowing the Grapheneos Devs are able to inspect the code on users behalf even if they can't yet release it.
Will Graphene release the patches concurrently with Google? If there's a lag, then then Graphene is a tiny bit less safe in terms of one-day/n-day bugs. Not having the source of the patch adds some friction to all attackers, but reversing vulnerabilities from binary patches has a long history.
Earlier quoted context omitted.
Two fixes that would be trivial to backport to mainline Android.
You can configure USB port for charging only in the developer options.