zlacker

>>screen+(OP)
AKA: The shadow war on bot traffic continues humming along.

>>Klonoa+Mc
Bot traffic? Anyone using Linux will get blocked because "they can't be trusted". Only people running an "approved" operating system from a billion dollar corporation will be allowed to access.

This is already what is happening with SafetyNet on Android. For now most applications don't require hardware attestation so you can pass by spoofing an old device that didn't support hardware attestation but I'm sure that will change within a decade.

>>kevinc+xf
You don't have to be a billion dollar corporation to become Play Protect certified.

Being able to trust the security of a client can protect against many attacks and it is up to web sites to evaluate what to do with into information that a client is proven to be secure.

>>charci+Ph
Fair. Two questions:

- What is the least expensive device that can be certified like that? The least expensive process?

- What is the highest level of openness such a device can offer to the user, and why?

To my mind, it would be best to have an option of a completely locked down and certified hardware token, a device like a Yubikey, that could talk to my laptop, desktop, phone, or any other computing device using a standard protocol. As long as it's unforgeable, the rest of the system can be much. much less secure, without compromising the overall security.

>>nine_k+Mm
>What is the least expensive device that can be certified like that?

I don't know. I haven't personally gone through the process.

>What is the highest level of openness such a device can offer to the user, and why?

You have to follow the CDD. https://source.android.com/docs/compatibility/13/android-13-...

and you of course must pass the compatibility tests. So it can be as open as you would like as long as you do not break the android security model.

>it would be best to have an option of a completely locked down and certified hardware token, a device like a Yubikey

That approach is limiting since secrets can't be passed to the host operating system and compute with secrets have to happen on the secure device.

>>charci+yv
> as long as you do not break the android security model.

AKA as long as you don't give control to the user.

>>kevinc+5P1
>AKA as long as you don't give control to the user.

A system being secure doesn't mean that the user doesn't have control. The operating system should allow the user to control it, but only in a secure way that doesn't compromise the rest of the security of the system. The Windows way of having an administrator account or Linux of having a root account given to the user has been proven over time to be worse for security. Windows has been trying to roll back this mistake, but most Linux distributions don't do anything because they don't care that much about security compared to an operating system like Android.

>>charci+IU2
Sure, in theory it doesn't but in practice it does.

I wanted to extract some data files from an app I was using and Google's Android told me that I was not allowed to do that. That was the apps data not my data.

It doesn't really matter root/fine grained permissions. The fact is that on stock Pixel phones the user can't access whatever data they want. So in practice they don't have control.

>>kevinc+yV2
That same ability makes it possible for 2FA apps to exist since the secrets can't be copied, turning the factor into something you know instead of something you have. Additionally just because someone is using a device that doesn't mean that the current user is the owner of the device.

>>charci+io3
2FA apps will never be perfect and allowing careful access is not going to undermine them.

And the alternative is taking a picture of the QR code.

> Additionally just because someone is using a device that doesn't mean that the current user is the owner of the device.

Yeah that's why you make the owner authenticate. It would be ridiculous to use that as a reason to make escalation impossible.