Comment by palata
10 days ago
I am not sure what you are trying to say.
Convincing a user to give their password will always be an issue, that's fundamental. But because phishing exists does not mean that security does not matter.
Without security, there is no need to phish, because the system does not protect anything. Once you have a good security, then the best attack is phishing because it's easier to trick the human than the system. This means that the security is good, not bad.
I think one of the points is that all this attestation stuff does not protect against the majority of the ways users are compromised. Its just remote control with real security benefits, just those benefits largely accrue to companies and at the expense of the user.
If my system is signed and verified at every boot, doesn't that guarantee that my system hasn't been tampered with? Meaning that no malware has found a way to get root access and modify it. I find this valuable.
If you can't use your own keys and verify the process yourself, then no, that is not a guarantee.
Malware developers just have their software signed by the gatekeepers your device is programmed to inherently trust, because the gatekeepers don't give a shit.
The App Store and Play Store are the largest vectors of malware out there, and every year they are responsible for letting their users get scammed to the tune of billions of dollars.
1 reply →
I do see the value in this and also note that this feature has largely been kept from users intentionally on most other platforms. Still, this offers very little protection for the vast majority of scams to which people fall victim.
1 reply →
That's the same fallacy as seeing that no one dies of certain diseases, so the vaccines against them don't work.
There are different vaccines from different manufacturers. Attestation from something like keybase should work just as well for banks or whatever.
This level of security exists on open as well as closed platforms, the problem is the closed platforms not allowing you to do things that aren't giving your password away (like installing fdroid or using beeper easily). I just have a hard time believing this is superior in any way.
I think you're confused.
I you run GrapheneOS, it is an open source platform built on top of AOSP (the Android Open Source Project). Part of the security model is that you don't run as root. I am an advanced user and I don't want to run as root on my phone, I am happy with GrapheneOS as it is distributed.
Now if you want to be root, you can install an OS that allows you to be root. Just like I unlocked my bootloader, installed GrapheneOS and relocked my bootloader, you can do that and install whatever you please. I will keep using GrapheneOS because that is the most secure OS I can find for my phone.
The problem, IMO, is not that "some OS are opinionated and don't give you root access while other OSes do give you root access". The problem is that on many phones, you are not free to install the goddam OS you want (e.g. because you can't unlock or relock the bootloader).
Root used to just mean knowing an admin password and rarely using it on desktop platforms for making local changes. It's changed definition for mobile if it now means just being able to run and auto-update apps from fdroid or run an app without the attestation of the company that supplies the OS, which in the worst cases takes away control completely from the user.
Mobile platforms and developers solely supporting their attestation should allow other forms of self attestation that the users want. I don't think I'm confused about anything, and I don't need to muddy the definition of security or root to argue having control over my data and apps on platforms I want to use.
1 reply →
Meh, I'm ok with not having root on my phone. What I'm not ok with is not being able to flash whatever I want to run on it later without unlocking and wiping. For this reason I have an automated script to verify Graphene's signatures and replace them with my own. This would give me the ability to extract data using root at a later date, for example.
2 replies →
You can't provide a passkey to a malicious site without writing your own web browser. And the "password" is a 128-bit integer.
It completely solves the phishing-password-stealing problem.
That was an example, I was talking about phishing in general. Phishing will always exist: as long as a human has a right to do something, someone else can trick this human into doing it for them.
Passkeys are great, and they do improve the situation. But they won't remove phishing as a concept.
I think a passkey is a good example of how, when the user has a trusted third party grant them limited instead of unlimited permission to do something (e.g. they can use a secret with the site that created it but they can't extract the raw secret from it to send to an arbitrary site), it is possible to make them immune to a particular type of phishing.
As an example of mitigating another type of phishing, if the user only has the ability to log in to a web site from a particular device or country, an attacker tricking them into providing their password gets a much less useful win.
You could argue they have the "right to do" less in that situation. Sure, that's a reasonable perspective. I'm not passing moral judgement here. But I think that it is a factually true statement that it is indeed possible to mitigate (and even entirely prevent) phishing vulnerabilities by giving end users devices that have stronger security policies - with those policies being written by the device creator, and not edited by the end user themself.
I think this principle applies to every single type of social engineering attack. Limiting the context of permissions lessens the risk of a confused deputy.
3 replies →