HN Theater @HNTheaterMonth

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 reauthentication, because it's low risk. OK if they log in from a compromised machine than a hacker gets to read some internal information, its very low risk.

I've also got a site where you can make major changes. You have to reauthenticate far more frequently to make those changes (every 30 minutes). It's a matter of risk.

[0] https://www.youtube.com/watch?v=y4GB_NDU43Q

⬐ mjg59

I, as the company paying for your service, have no direct ability to influence the policy that you apply to the tokens you issue. If you start issuing tokens that are good for decades, I have no trivial mechanism to detect that.

⬐ iso1631

Ask before you spend the money, stick it in the contract. If you don't like the answer don't sign the contract.

⬐ mjg59

There's no universe where a typical tiny customer is going to be able to impose policy on a large vendor, and there's just not that many vendors in this space. So, yes, I could go with "We're not going to use Github or Gitlab or any similar vendor because they don't meet our needs in this respect" but then I'm probably going to spend a bunch of time explaining to my board why we're reimplementing issue tracking and CI and that's likely to be some rough chuckles.

⬐ iso1631

Either github's systems are good enough for you to use, or they aren't.

If they aren't, you need to find or implement something that is good enough.

⬐ mjg59

That is, in fact, what I'm trying to do - this is the explanation for why I'm doing so.

⬐ spacemanmatt

> I, as the company paying for your service, have no direct ability to influence the policy that you apply to the tokens you issue

a) why would you want that burden b) you're never gonna get it

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: https://youtu.be/y4GB_NDU43Q

1: https://southpark.fandom.com/wiki/TrollTrace.com

⬐ slingnow

Are you kidding me? Crumble overnight? Have you not heard of the massive data breaches from the credit reporting industry? They got a minor slap on the wrist and everything is continuing as though it never happened.

I don't understand how people can have such naive views in this day and age. Google is FAR MORE important today than a credit reporting company. They wouldn't go anywhere.

⬐ Karunamon

As a consumer, you can make the choice to not use Google. You can not reasonably avoid dealing with the credit reporting industry.

⬐ hackerfromthefu

Maybe, but you can't easily stop Google using you. Or FB, etc etc

⬐ judge2020

Yes you can. You can disable cookies, or use ad blockers. Specifically, this is talking about Google Workspace customers, so all their customers can easily move off using them for hosted email.

⬐ hackerfromthefu

Do you watch youtube? Get email from people using Gmail. The list goes on, if you think outside your box.

My comment is not limited to workspaces, that's a strawman.

⬐ judge2020

Nobody affected by those breaches willingly worked with the credit reporting industry. Everyone with a Workspace subscription willingly works with it and moving all the stuff Google Workspace offers off to Office 365 can be done relatively quickly by downloading all drive data, syncing user email, contacts, and caldav, and exporting Sheets/Gdocs as their Office file format counterparts.

⬐ InitialBP

There are numerous other breaches of companies that people continue to shop/work with literally weekly if not daily.

Wikipedia might not be the best source but they have a list of companies that have had data breaches, but there is a huge list of companies that have had public breaches.

Just to name a few and their sources that you people everywhere still use because the majority of people don't care about privacy or security.

Apple - https://www.theguardian.com/technology/2013/jul/22/apple-dev... AT&T - https://www.theguardian.com/technology/2010/jun/10/apple-ipa... Barnes and Noble - https://www.nytimes.com/2012/10/24/business/hackers-get-cred... Capital One - https://www.cnn.com/2019/07/29/business/capital-one-data-bre...

There's plenty of other examples on here - but I agree with the parent, Google could implode and leak everything and the average person could not be bothered to change their emails or stop using Google.

Just reading the title it sounded very much like "Single Point of Failure: The (Fictional) Day Google Forgot To Check Passwords": https://www.youtube.com/watch?v=y4GB_NDU43Q

⬐ zinekeller

Fortunately (or not, depending if you have a Chromebook and store files locally there), the inverse has happened and it locked up your book (fail-deadly versus fail-safe).

⬐ utf_8x

> fail-deadly versus fail-safe

Speaking of... https://www.youtube.com/watch?v=TUKQfMFKfjk

⬐ jedimastert

I love Tom's speculative fiction talks. He tells such a good story.

⬐ 0x0

This actually happened for real with Dropbox about 10 years ago: https://techcrunch.com/2011/06/20/dropbox-security-bug-made-...

⬐ cmeacham98

That exact news article appears in the video.

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

https://www.youtube.com/watch?v=y4GB_NDU43Q

Reminds me of this incredible talk by Tom Scott: https://youtube.com/watch?v=y4GB_NDU43Q

⬐ __henil

This is one of the time having a short title limit sucks.

"Single Point of Failure" is a keyword that should have been highlighted.

⬐ ffpip

I tried submitting the exact link with the same title 2 minutes after you did . Couldn't fit in the '[video]' tag :)

⬐ lifthrasiir

"Single Point of Failure: (Fictional) Day Google Forgot To Check Password [video]" does fit in 80 characters limit. A typical headline trick.

⬐ __henil

I thought about it but the year is also required...

⬐ nayuki

It's funny how this other news item is on the front page: "Google outage – resolved" https://news.ycombinator.com/item?id=25415989

⬐ pdkl95

https://news.ycombinator.com/item?id=25416881

⬐ lifthrasiir

The 2011 Dropbox incident that Tom references: https://techcrunch.com/2011/06/20/dropbox-security-bug-made-...

⬐ sneak

It astounds me that people continue to use Dropbox after that incident. That day they burned 100% of their organizational credibility as reasonable adults with me.

It's not that they made that error; it's that making that error was possible given their organization's procedures.

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] https://www.youtube.com/watch?v=y4GB_NDU43Q (you might need to open this link in a private window...)

https://www.youtube.com/watch?v=y4GB_NDU43Q

Works fine once you log out.

⬐ ytch

opening it with Incognito mode works too

I'm not sure this is a reference this is relevant regardless: https://www.youtube.com/watch?v=y4GB_NDU43Q

Found the "article" I was talking about:

https://youtu.be/y4GB_NDU43Q

It's a talk by Tom Scott

⬐ gitgud

Years ago, when I first saw this talk, I wasn't paying attention at the beginning and thought this really happened.

These days it would surprise me if this kind of event happened tomorrow...

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: https://youtu.be/y4GB_NDU43Q

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

https://www.youtube.com/watch?v=y4GB_NDU43Q

⬐ acobster

Wow, thanks for the recommendation. Harrowing.

⬐ DonaldFisk

It's back up.

⬐ mito88

it's black!

:)

⬐ mito88

damn!!!

⬐ ateesdalejr

Yes! This video was what caused me to reconsider my use of Google services seriously.

⬐ scrollaway

I was wondering how to react if this happened to me while watching the video. If, like me, you use Google with your email on your own domain (eg. gsuite), you could, in an emergency, change your MX records to something non-google.

⬐ corobo

Worth noting that "In an emergency" also relies on your MX records' TTL being set to a low value

⬐ breakingcups

And the DNS not being managed by Google and the domain not being bought through Google.

⬐ jtokoph

Note: this is purely hypothetical and never really happened.