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
I love Tom's speculative fiction talks. He tells such a good story.
Google broke a conditional statement that verifies passwords on Chrome OS
111–120 of 276 posts
Re: Google broke a conditional statement that verifies passwords on Chrome OS
#112Earlier quoted context omitted.
Look, I know that this is an enormously bad bug, but... Google has a codebase that numbers multiple billions of lines. Using := means typing multiple billions of extra characters. That adds up. And it wouldn't even have prevented this bug! All checks have costs. As Emerson said, "A stitch in time saves nine. So we make 1000 stitches, that by doing so we may save nine."
Once more I hope this is satire, but as so often on the Internet it is surprisingly hard to tell.
This reminds me of Silicon Valley’s main character preferring tabs to spaces because they use less bytes, despite his own product being for... compression!
I personally prefer spaces so that under any circumstances, the code reads the same as the author intended (whether you’re in an editor or viewing a file with a CLI tool). Are we really counting bytes in this day and age?
Re: Google broke a conditional statement that verifies passwords on Chrome OS
#113This has happened so many times in recent years to high profile services and OSes. You'd think it'd be a test case.
Re: Google broke a conditional statement that verifies passwords on Chrome OS
#114I haven't touched C++ in forever, but as a C programmer it looks insane that you can do dot operator and -> operator on the same variable and not cause compiler error...
The latter is the dereference operator, it's commonly overridden for single element container types.
Re: Google broke a conditional statement that verifies passwords on Chrome OS
#115Earlier quoted context omitted.
Once more I hope this is satire, but as so often on the Internet it is surprisingly hard to tell.
This reminds me of Silicon Valley’s main character preferring tabs to spaces because they use less bytes, despite his own product being for... compression! I personally prefer spaces so that under any circumstances, the code reads the same as the author intended (whether you’re in an editor or viewing a file with a CLI tool). Are we really counting bytes in this day and age?
The argument for tabs really goes that time is spent much more on reading code than authoring, so it should be optimized and customizable (tab width) for the reader.
Re: Google broke a conditional statement that verifies passwords on Chrome OS
#116Earlier quoted context omitted.
Bitwise & versus logical && is a classic, right up there with an assignment in a comparison (when an equality check is intended), = for ==. That this was missed is pretty surprising, given that it's Google and the stakes involved in the encryption/key management code in a secure platform device. I wonder if we'll even get a postmortem, as this simply cannot happen unless several someones all Seriously Fucked Up simul…
"Heads should probably roll here..." Google has a blameless post-mortem process (see https://sre.google/sre-book/postmortem-culture/ ) which essentially boils down to: 0) We want to fix the situation. By the time the post-mortem happens, that should already be done. 1) We want to make sure this never happens again. In order to do that we need to understand as much as we can about what happened. 2) We want everyone to…
Everyone should support blameless postmortems. I'm more ruing the impending "oh we're soooo sorry" PR babble where it reads as a subtle "** off pleb".
Re: Google broke a conditional statement that verifies passwords on Chrome OS
#117Earlier quoted context omitted.
the problem is that bitwise & and | are routinely used for their non-shortcircuiting behaviour in boolean expressions, so it is hard for the compiler to flag this as an error. Many linters and static analysis tools do flag them though as these days it is not considered good practice.
> & and | are routinely used for their non-shortcircuiting behaviour in boolean expressions Really? I can't recall a single case of this with 'bool' in any codebase in my recent memory. I only see it with integers. And even if it's somehow routine for your codebases with bool (why?!), surely it's not routine inside a conditional expression , so at least they can prohibit it there?
Whenever I see it I assume it's a typo. If it was truly intentional I would expect a comment pointing out why it's needed.
Re: Google broke a conditional statement that verifies passwords on Chrome OS
#118Earlier quoted context omitted.
Ahhh, so it was a problem with lazy evaluation (and the lack thereof when using &), and not type coercion, like I initially thought.
I think this is a unpopular opinion, but I consider taking advantage of short-circuiting in boolean operations to be a code smell. At least for me, it seems very fragile and I'd much rather break the conditional logic out explicitly. But I like to write as much like assembly as I can in every language. Each line of code should do one and only one thing.
Short circuiting boolean operators are very useful, and not something I would consider a code smell. They let constructs like this work, which are very common in most codebases:
if (foo && foo->bar) {
// whatever
}
Re: Google broke a conditional statement that verifies passwords on Chrome OS
#119The reason this happened is that it wasn't followed by "Google hit by 143 defective product lawsuits".
I don't think they could possibly be sued for this. They would just be responsible for fixing or refunding the product. In this case they issued a "fix". It is the same as when a car is defective. They don't get sued, they do a recall and fix it.
>They don't get sued, they do a recall and fix it
Are you kidding? Major (car, drug, you name it) companies have hundreds, if not thousands of lawsuits going at any given moment.
Public companies will sometimes list major lawsuits in their annual report, but most of them don't get mentioned because the amount at stake is trivial for them.
Re: Google broke a conditional statement that verifies passwords on Chrome OS
#120Earlier quoted context omitted.
This reminds me of Silicon Valley’s main character preferring tabs to spaces because they use less bytes, despite his own product being for... compression! I personally prefer spaces so that under any circumstances, the code reads the same as the author intended (whether you’re in an editor or viewing a file with a CLI tool). Are we really counting bytes in this day and age?
The argument for tabs really goes that time is spent much more on reading code than authoring, so it should be optimized and customizable (tab width) for the reader.
Tabs for indentation, spaces for alignment.