3 ms·

A user agent that refreshes parts of its profile at the end of a session and deletes data, hopefully, should be something a company like Google can pick up on a

A user agent that refreshes parts of its profile at the end of a session and deletes data, hopefully, should be something a company like Google can pick up on after enough attempts. "We can't expect the nonexistence of a persistent cookie means the user is using a new user agent because of a persistent history of successful authentication attempts without such cookie present" is not a tall order for a company like Google who is running these experiments on their users. It is odd you are pathologizing what I would expect to be normal behavior. It's not common behavior, but it doesn't seem abnormal for user agents to do this. Edit: for users who only access their Google accounts via shared machines like at a public library, not having a persistent cookie on every auth attempt is going to be the expected scenario.

minsc_and_boo 4y ago
User agents are remarkably easy to spoof at scale. Bad actors could cycle known user agents with a password until they hit the right non-2FA login agent. It also presents an attack vector to screw up everyone's logins and repeatedly force users to re-2FA every few minutes.
- photon12 4y ago
  I don't understand some of the ways you are using terms e.g. when you say "user agent" it sounds like you mean the User-Agent HTTP header, which is trivial to spoof, but that isn't how I'm using the word user agent, which I'm saying means the agent that a given user acts with. I also don't quite understand your threat model here and the details of what you're proposing is an attack. If you are a user who Google consistently knows has a persistent cookie at auth time, Google can expect that in the future and therefore use that as a data point in risk based authentication. If you are a user who Google consistently knows doesn't have a persistent cookie at auth time, Google can't rely on that data point providing any signal in risk based auth, and seems to be DoSing, or at least frustrating, users in that scenario. I can't quite respond to your comment because I don't fully understand it.
skybrian 4y ago
I agree that public library access for people who don't own a computer is an important and difficult problem, but you're talking about other people, not the case being discussed now. Bringing it up here is a distraction. For someone who is tech-savvy and owns a laptop, there is a simple solution: create a new, vanilla browser profile and use it only for logging into Google. (I do the same thing, but for Facebook.) You'd don't need any privacy extensions when you want them to know who you are.
- photon12 4y ago
  Bringing it up here isn't a distraction, it's central to my main point: the workflow of having a user agent refresh its persistent state is an expected use case, and therefore signal analysis should understand that for some users, the non-existence of a persistent cookie is no indication of elevated risk above baseline.
  - skybrian 4y ago
    It's possible to come up with different solutions for different people.

minsc_and_boo 4y ago

User agents are remarkably easy to spoof at scale. Bad actors could cycle known user agents with a password until they hit the right non-2FA login agent. It also presents an attack vector to screw up everyone's logins and repeatedly force users to re-2FA every few minutes.

photon12 4y ago
I don't understand some of the ways you are using terms e.g. when you say "user agent" it sounds like you mean the User-Agent HTTP header, which is trivial to spoof, but that isn't how I'm using the word user agent, which I'm saying means the agent that a given user acts with. I also don't quite understand your threat model here and the details of what you're proposing is an attack. If you are a user who Google consistently knows has a persistent cookie at auth time, Google can expect that in the future and therefore use that as a data point in risk based authentication. If you are a user who Google consistently knows doesn't have a persistent cookie at auth time, Google can't rely on that data point providing any signal in risk based auth, and seems to be DoSing, or at least frustrating, users in that scenario. I can't quite respond to your comment because I don't fully understand it.

skybrian 4y ago

I agree that public library access for people who don't own a computer is an important and difficult problem, but you're talking about other people, not the case being discussed now. Bringing it up here is a distraction. For someone who is tech-savvy and owns a laptop, there is a simple solution: create a new, vanilla browser profile and use it only for logging into Google. (I do the same thing, but for Facebook.) You'd don't need any privacy extensions when you want them to know who you are.

photon12 4y ago
Bringing it up here isn't a distraction, it's central to my main point: the workflow of having a user agent refresh its persistent state is an expected use case, and therefore signal analysis should understand that for some users, the non-existence of a persistent cookie is no indication of elevated risk above baseline.
- skybrian 4y ago
  It's possible to come up with different solutions for different people.