Live data from Hacker News

Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking

arstechnica.com

161–170 of 372 posts

Re: Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking

#161
post #44

Earlier quoted context omitted.

It physically disables USB ports when locked which significantly reduces the attack surface + can be configured to automatically reboot.

The auto reboot is configured by default. Its quite a long window, every 18 hours or so from memory. It can be configured to be shorter than this. I experimented with one hour, but missed an alarm. Its good security practice to reboot your phone before going to bed, this puts it in the much harder to break in to BFU state.

Alarms work after reboot in the default system Clock app configuration. However, it does not work in all configurations since not everything is properly handled for the Clock app's Direct Boot mode. Google's Clock app works better since it diverged from AOSP Clock years ago. The main thing you'll miss are push notifications since the vast majority of apps do not have Direct Boot support for detecting there are notifications available. We aren't actually aware of any non-Google app supporting it.

Re: Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking

#162
post #3

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."

[deleted]

Re: Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking

#163

Earlier quoted context omitted.

You can actually get a prepaid travel eSIM before you leave on holiday.

Which are absolutely shit because your data exits out on the other side of the world with 150ms extra latency. Getting an (e?)SIM from a local carrier is always better and often cheaper too.

And you can buy an eSIM from a local carrier, which will then email you a code. It's unheard of for local carriers to mail physical SIMs to the other side of the world.

Re: Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking

#164
post #48

> 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.

Agreed, the rest of the comments are delusional. First, you have to contact customer service, which takes a few days to get a response. Then you have to have another device to display the QR code on, which you won't have if you're travelling. They'll send you a QR code you have to scan with the device you're currently on, AND you'll have to do it without an internet connection. Meaning it just doesn't work, at all.

An offline device can take a SIM card just fine. But if you're setting up a new device, or setting up an existing device on a new country on eSim, doesn't matter, you can never connect, because you have to already have internet, to get internet.

Esim was a good idea, implemented so horribly it's worse than the 30 year old predecessor.

Re: Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking

#165

Earlier quoted context omitted.

All iPhones were vulnerable according to the last available iOS support matrix.

That's not quite correct, but you're not a million miles off: https://www.documentcloud.org/documents/24833832-cellebrite-... To calibrate your sense of time, the iPhone 15 had been released in September 2023 and that doc is dated April 2024, so ~6 months. And just for completeness, here was the Android doc that leaked at the same time: https://www.documentcloud.org/documents/24833831-cellebrite-...

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...

Re: Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking

#166

Earlier quoted context omitted.

Without Google Pay, Google Wallet is practically a glorified card number vault. Which can still be useful, just not at card terminals.

True. This is an issue in America specifically. Where there is a Google Apple duopoly on tap-to-pay tech. Can be worked around though with smart watches like Garmin watch with Garmin Pay. In many other regions there are alternatives like Curve Pay or tap-to-pay functionalities in banking apps

Google Pay also works with a Pixel watch connected to a GrapheneOS phone, FWIW.

Re: Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking

#168
post #48

> 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…

eSIMs feel like a solution waiting for a problem. Consumers are happy with physical SIMs, you obtain one, you put it in your phone then you forget about it until you swap your phone. I'm sure eSIMs are a good idea if your aim is to gain even more control over our personal devices.

No, they're a huge improvement

Re: Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking

#169
post #13

Earlier quoted context omitted.

First I’m hearing Graphene causes issues with E911 - is this a setting?

Is it E911 or an A-GPS issue?

GrapheneOS provides PSDS, SUPL (which are enabled by default IIRC) and an optional Wi-Fi based location provider, so there shouldn't be any positioning issues with E911
Post reply on HN