Live data from Hacker News

GrapheneOS – Break Free from Google and Apple

blog.tomaszdunia.pl

731–740 of 967 posts

Re: GrapheneOS – Break Free from Google and Apple

#731
post #333

Earlier quoted context omitted.

You can use labels for contact scope.

You might want to read my comment again. :) If you use labels, the app will have full access to the associated contacts, not just to their names & phone numbers.

So it's not about labels, but you want the ability to restrict the fields an app has access to rather than an all or nothing – full access to a contact or none at all?

Re: GrapheneOS – Break Free from Google and Apple

#732
post #611
post #344

Earlier quoted context omitted.

> It is wrong to claim that an unlocked bootloader completely breaks the android security model. You seem knowledgeable about this, so I'll take the opportunity to ask: if I install a malicious app and it manages to escape the sandbox and alter the system, my understanding is that it will be detected next time I boot it (because the image hash won't match). Isn't that true? > Signing keys for bootloaders might just n…

> You seem knowledgeable about this, so I'll take the opportunity to ask: if I install a malicious app and it manages to escape the sandbox and alter the system, my understanding is that it will be detected next time I boot it (because the image hash won't match). Isn't that true? They're misrepresenting what has been said by GrapheneOS and also lack a good understanding of it themselves. They're definitely not a goo…

Could you provide some insights there? That would be appreciated.

1. Is it correct that the secure boot protects again a malicious app escaping the sandbox and persisting into the system?

2. Is it correct that if the system is signed with the Google testing keys, then someone could sign an app with those keys and the app would get more permissions than it should (I believe it's called the "signature" permissions)?

Re: GrapheneOS – Break Free from Google and Apple

#735

Been using this for about a year on a p9 pro. It works very well. I hear the google tap to pay does not work, but I've never tried it. However Vipps with their tap to pay works fine. BankID works but not with biometric login, which some things require IIRC. And for some reason DnB private works fine, but you are not allowed in on the corp app. It's mind boggingly stupid that they lock down apps like this, when you ca…

A collegue of mine was tech lead at a large online bank. For the mobile app, the first and foremost threat that security auditors would find was "The app runs on a rooted phone!!!". Security theater at its finest, checkboxes gotta be checked. The irony is that the devs were using rooted phones for QA and debugging.

A lot of that is security theater at its best. However given the forced attack surface I would imagine that there is a hard push from authoritarians and the finance world to make a "secure chain" from service to screen.

My guess: They're afraid that the scammers are going to mirror the screen and remote control access to the app. (More orgs are moving to app/phone based assumptions because it saves the org money and pushes cost on the consumer) Instead of providing protections from account take over.. we're going to get devices we don't own and we have to to pay for, maintain and pay for services to get a terminal to your own bank account. Additionally, there are many dictatorships, like the UK, North Korea, etc, that are very adimate that you don't look at things without their permission. So they're trying to close the gap of avoiding age verification bypasses with VPNs.

Re: GrapheneOS – Break Free from Google and Apple

#736
post #680

Earlier quoted context omitted.

This is a contradiction. There is nothing "minimal" about a requirement that excludes every device but one. Also some people (me) value independence from Google more than the highest degree of security (which relies on Google hardware).

> This is a contradiction. There is nothing "minimal" about a requirement that excludes every device but one. I don't get your logic. Requirements are a choice. It's very easy to create requirements that exclude every device but one. Example: "It has to be the Samsung Galaxy S23". Done. Now you can disagree with those requirements, but that's completely different from saying that the requirements are wrong.

I disagree that such requirements are minimal. Nothing prevents running GrapheneOS on a device with lower requirements. It's a questionable choice by the developers restricting the choice for users.

Re: GrapheneOS – Break Free from Google and Apple

#738

It's very annoying that they restrict themselves to Pixels. I get they can't guarantee all the security features they want on other phones, but even a subset of those security features and the other advantages like the lack of cruft would make it very attractive to be able to run on other phones.

They are working with a partner to get their own phone hardware, hopefully by next year.

Re: GrapheneOS – Break Free from Google and Apple

#739
post #6

One of the only big downsides I've noticed with GrapheneOS is that several banking apps don't work with it at all thanks to being tied to Google's verification ecosystem. Luckily I have hardware 2FA keys from my bank so I can authenticate using that. It also slightly decreases the suck-factor from whenever the phone decides to fly off down a drain. This may not be the case for you, so do your research on what you nee…

Yup, also Google Pay doesn't work, though there are other providers which work fine (Curve Pay I think works in all of EU), but it just made me carry my wallet everywhere and I understood I don't mind that at all.

Since all of comments are about NFC payments, this should be higher. Can confirm Curve Pay works (pixel 9a) at least with one Greek bank and Revilut. Not affiliated in any way with them and don't know this service is actually works just Yeah I'm amazed too.

Re: GrapheneOS – Break Free from Google and Apple

#740

Earlier quoted context omitted.

As long as copying some numbers, printed on a piece of plastic, into an online order form is all the authentication that is needed for a transaction, anything more than that is inherently security theater.

That’s why for most transactions I do with a credit card in my country, you need an extra validation with the mobile app. It is mostly American websites that do not enable this functionality.

Because we have anti-fraud consumer potection rules and CCs operate on a make money first type of bais. The debit networks on the otherhand are a different story.
Post reply on HN