Sessions != Users. I have two or three active sessions at any point, Multiple browsers + mobile. Since the issue seems to be with cookies, we can probably discard mobile.

Also each time you login/ token refreshes is probably a new session. So they easily have million's of sessions daily. So in the one month period between 6th Feb and 5 March, you have

  **(DAU) * 35* (average sessions / user)** . 

So in the ballpark of 10M * 35 * 5 sessions ~ so anywhere between 700-1500 M sessions conservatively . That is in the ballpark of 15,000 users.

Also 0.001% is their belief of the impact. I don't see any evidence or statistical model or details supporting the statement.

I am deeply skeptical of this number without knowing the methodology , as you say it would quite impressive to narrow down a race condition to that level.

Good point, after re-reading I see the 0.001% does apply to sessions rather than users. That should elevate the total users affected, yeah.

It's a race condition, so it had to do with two operations happening in a certain incorrect order. I bet they are able to see the exact situations where it occurred with pretty great certainty by reviewing the logs of the two operations that raced and see where the incorrect operation won. They even say they are invalidating all sessions or of an abundance of caution, indicative that they are pretty sure about it.

You called it! Just another race condition that uses shared objects without protecting them.

But its talking specifically about sessions. There's plenty of inactive users on GitHub as well.

There are also potentially many sessions per user. (Different browsers, even automated tools perhaps)

Using 80:20 rules, and assume only 20% of those are active. We could be down to 120 user?