Comment by palata

Comment by palata 4 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.

pluralmonad 4 days ago

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.

Reply View 7 replies

palata 4 days ago

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.

Reply View | 4 replies
- heavyset_go 4 days ago
  
  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.
  
  Reply View | 1 reply
  
  palata 3 days ago
  
  > If you can't use your own keys and verify the process yourself
  The thing with security is that it is a gradient. Too many people try to win arguments on security by saying a variant of "anyway you have to trust somebody, so it will never be secure". This is exactly what you are doing here.
  Say I trust GrapheneOS, the security model guarantees what I said. Obviously I have to trust something, I won't audit every single line of code and assemble billions of transistors myself.
  > every year they are responsible for letting their users get scammed
  Second tactic for winning a security argument: "but the users get scammed anyway". Sure they do. Because they have to. If you have a system that popular with zero scam, it probably means that the attackers don't even need to attack the human because the system itself is insecure.
  
  Reply View | 0 replies
- pluralmonad 4 days ago
  
  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.
  
  Reply View | 1 reply
  
  palata 3 days ago
  
  Phishing will always exist. If a system is very secure, the easiest way to attack it is to phish the human that has control over it. Complaining about that is weird... what do the people who complain want? One of those two:
  - "Please make the system less secure, so that the attackers don't have to attack the human because they can just compromise the system directly"
  - "Please keep making the system secure, and keep removing rights from the users, because the users prove over and over again that they cannot be trusted with anything"
  You see where I am going. If you only optimise for security, then you remove all the freedom. But we obviously want freedom. So it's a compromise.
  Now this compromise is a choice, and different systems can make different compromises. The freedom I want is the freedom to choose my system. I want to be able to install GrapheneOS on my phone. Complaining about macOS not being Linux would be weird: if I want Linux, I use Linux. If I use macOS, well then I have to live with the design choices of Apple.
  
  Reply View | 0 replies
gf000 4 days ago

That's the same fallacy as seeing that no one dies of certain diseases, so the vaccines against them don't work.

Reply View | 1 reply
- ece 3 days ago
  
  There are different vaccines from different manufacturers. Attestation from something like keybase should work just as well for banks or whatever.
  
  Reply View | 0 replies

ece 4 days ago

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.

Reply View 6 replies

palata 4 days ago

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

Reply View | 5 replies
- ece 3 days ago
  
  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.
  
  Reply View | 1 reply
  
  palata 3 days ago
  
  Respectfully, I genuinely don't understand what you are talking about.
  
  Reply View | 0 replies
- digiown 4 days ago
  
  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.
  
  Reply View | 2 replies
  
  palata 3 days ago
  
  > What I'm not ok with is not being able to flash whatever I want to run on it later without unlocking and wiping.
  The wiping is a security feature: if someone installs a new random system ("random" being defined as "not signed by the same entity"), then they can modify the system in order to attack it. The whole secure boot idea is worthless if you allow that.
  
  Reply View | 1 reply
  
  digiown 3 days ago
  
  I don't disagree. I just don't want the trusted entity to be other than me.
  Note that secure boot doesn't become worthless just because you can flash something different. The TPM should notice SB is turned off, and should refuse to decrypt, but there should be a way for the user to back up the key and use it to recover the data later.
  
  Reply View | 0 replies

Borealid 4 days ago

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.

Reply View 5 replies

palata 3 days ago

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.

Reply View | 4 replies
- Borealid 2 days ago
  
  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.
  
  Reply View | 3 replies
  
  palata 2 days ago
  
  I am not sure what you are trying to say.
  Security is a gradient. At some point, adding security means reducing freedom. It is a societal choice where you stop. If you put all the humans in your country in a jail, each in a separate cell, never let them go out and just bring them food, then there will be no crime in your country. But nobody wants that.
  > 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.
  A confused deputy is a computer program. We're talking about phishing.
  
  Reply View | 2 replies