Single Point of Failure: The (Fictional) Day Google Forgot To Check Passwords

When YouTube comes back up again, I can recommend Tom Scott with "Single Point of Failure: The (Fictional) Day Google Forgot To Check Passwords" [VIDEO]

Single Point of Failure: The (Fictional) Day Google Forgot To Check Passwords - [VIDEO] is another, different topic, but still worth watching.

Even worse could be an RCE vuln in Chrome at the same time that the google.com search page gets compromised... Also I think the post you're talking about is this video by Tom Scott: [VIDEO]

As many comments in this thread have mentioned, the crash seems to happen when when logged in; youtube and other services seem to work when don't send the session cookie. This suggests something very fundamental related to user account/sessions is failing... Did Maria Christensen make a mistake when adding "return true;"? (This is a joke referencing Tom Scott's 2014 parable[1] about the danger of designing a system with a single point of failure . Tom's tells the fictional tale of a high level employee at Google adding "return true;" to the global "handleLogin()" function.) [1] [VIDEO] (you might need to open this link in a private window...)

It's basically the scenario Tom Scott laid out about what would happen if Google stopped checking passwords... except it happened to Parler. [VIDEO]

Just reading the title it sounded very much like "Single Point of Failure: The (Fictional) Day Google Forgot To Check Passwords": [VIDEO]

Google's entire business hinges on user privacy from everyone other than Google. If, tomorrow, either this Account Security scenario happened[0] or this South Park website happened[1] (everyone's internet history searchably by anyone), and it was done at the incompetence of Google, they would crumble overnight. They might recover within a year or two if they release a statement and fix it within a few hours or something, but it would be devastating and they would have to kiss their entire Google Cloud business (encompassing Cloud Platform and Workspace) goodbye. Once more, even for their ad business, they don't sell that data, they target based off of it. They would lose their competitive data advantage overnight if someone could pay them $100 per-user for every user's full advertising profile since they could then go behind Google's back and out-header-bid Google with lower margins. 0: [VIDEO] 1: [LINK]

So I have a service using openid and I use google to authenticate the person logging in. I do that, then that's done. Now I could simply issue a session cookie, or a permament cookie, to the client so we never have to use google again. Or I could make it so that cookie lasts 10 minutes before reauthentication. I can use a refresh token which means they don't need to reauthenticate but if google expires the connection (disabled user etc), I expire mine. Either way, that's my decision as the person running my site, and it's the clients decision as the person running the client to decide whether to send the blob, or to share that blob with other clients. The only information I know is that somebody authenticated with google at a specific time and I had proof of that, I have no control over what happens to that blob. Google has nothing to do with what I or the client do with the information. You're right that I can't audit the third party (google, microsoft, etc), but I don't pretend I can. Google could simply change their password checking to "if (true)", that's google's business. If I'm worried about the third party authenticator then I shouldn't use it, and I should roll my own. (There was an early Tom Scott video imagining a world where google just says "yes" to passwords[0]) I have an internal read-only blog site using our corporate openid service to ensure that someone accesses the site. Once they authenticate, I allow them access for 30 days before forcing a reauthenticati