Tag: google

Web Environment Integrity Must Be Stopped title card

Web Environment Integrity Must Be Stopped: Enslavement By “Remote Attestation”

“Web Environment Integrity” is a specification being worked on by Google employees and prototyped into Chromium, the open-source core of Google Chrome on which most modern browsers are based (Microsoft Edge, Brave, Opera, Vivaldi, and many others). The short version of how it works is that your browser gets a permission slip from a big tech company like Google, Microsoft, or Cloudflare that certifies whether or not you’re “trustworthy” which websites can use to gatekeep access. It is supposed to help with spam, bots, and fake ad clicks, but the goals laid out by the project are in direct conflict and not possible to achieve as a result. One such goal is “for the web to be usable without this framework” but the entire point of the framework is to lock down the web, so which half will be the one that Google chooses to not achieve?

Let there be no doubt: if Google manages to get this “remote attestation” framework in use on most websites, they’ll have the power to unilaterally lock people out of most of the internet, and website owners will have no way to know that their users were locked out by the “trusted third party” that maliciously “attested” to the user actually being a spam bot to trick them into locking the user out.

Fortunately, the internet has decided to call them out on their nonsense, and in typical central authoritarian fashion, they’ve locked the thread so no one can keep burning them publicly on their own absurd proposal.

Google Stadia was guaranteed to fail, according to basic freaking math

If you don’t know what Google Stadia is, it’s basically a networked gaming console. It renders everything on big servers at Google so your tiny Chromecast or other wimpy smart TV or computer or phone or internet-enabled potato or carrier pigeon or whatever doesn’t have to do any of the rendering work, and it takes inputs and sends fully rendered video frames over your network connection in a similar manner to a video streaming service. The idea is that you plug in a control pad, download the Stadia app, and you can play games without buying any special hardware. It’s a revolution in video gaming! It’s the end of home consoles!

…and it was guaranteed to be dead on arrival…and anyone with the most basic knowledge could have figured this out, but Google somehow green-lit it.

Anyone who looks at a typical ping time on a home internet connection, even a good one, can easily figure out why Stadia was doomed to be trash from the outset. A game running at any remotely usable frame rate (I’d say 20fps is a minimum for pretty much anything at this point) needs to receive inputs, process inputs, do all the game logic calculations for the next frame, render the next frame, and blit the frame, and for a 20fps frame rate, a game on your normal system has 50ms total to completely turn that around. If you are playing a faster action game that requires real-time control, you need higher frame rates than that, meaning even lower total latencies than 50ms.

Now let’s look at ping times from my house on my otherwise completely unused connection to google.com:

Pinging google.com [] with 32 bytes of data:
Reply from bytes=32 time=33ms TTL=42
Reply from bytes=32 time=33ms TTL=42
Reply from bytes=32 time=32ms TTL=42
Reply from bytes=32 time=32ms TTL=42

OK, so a ping round-trip takes 32ms, leaving 12ms to do everything included above. BUT WAIT, THERE’S MORE: Stadia can’t send uncompressed frames, because that will take too long to arrive, so there’s compression overhead as well, meaning there’s also going to be added decompression overhead on the client side. Even with a hardware H.264 encoder/decoder combo, a finite amount of time is still required to do this. Let’s be INSANELY GENEROUS and say that the encode/decode takes 2ms on each side. Now, even before ALL THE STUFF I ALREADY MENTIONED is accounted for, we’re down to 8ms of time left to hit that 20fps frame rate goal. Remember, in the 8ms remaining, we must still process inputs, run game logic, and render out the frame to be compressed…and this is also an ideal situation assuming an otherwise completely unused connection with no or very minimal network congestion going on. This also assumes that input comes in as early as possible, which is basically never the case. There will almost always be at least one frame of input lag just because of this.

Even if you reduce the goal frame rate to 15fps, the total time available between frames only rises from 50ms to 66ms. While that does constitute a tripling of the time available to run game logic and render a frame, it’s still a really short time frame, and any network usage by any device on the same connection or other households on the same shared network node will essentially render this work pipeline unusably slow. Multiplayer gaming with client-side rendering has the advantage of only sending extremely small packets of data that transmit quickly and act as “commands” for the client software, meaning all existing multiplayer network gaming is sort of like a specialized computing cluster for that game, with the heavy lifting done where the latencies have to be the lowest. Stadia combines all of the horrible problems of live video streaming with the problems of multiplayer latencies. It was dead on arrival. It is destined to fail.

Anyone with simple networking and gaming knowledge can figure this out.

But a multi-billion dollar international corporation that snarfs up the best and brightest minds somehow missed it.

Let that sink in.

Google Chromebooks: You don’t own your data and can’t recover it if the laptop dies

A user came into my computer repair shop with an Acer laptop that happened to be a Google Chromebook. This laptop was dead. It simply doesn’t work. The hard drive works, and under Linux I can mount the filesystems on the hard drive, but the rest of the laptop is shot. We wanted to move the user’s drive to an external hard drive enclosure so that he could at least retrieve his family photos and other data stored on the computer. Obviously, the data would need to be copied off of the Linux filesystems and the drive reformatted to Windows’ NTFS so that it could be read on a Windows PC, and then the data would be copied onto the newly formatted hard drive. The user gets an external hard drive plus all his data, and everyone is happy.

Except for one tiny little problem.

Google Chromebooks encrypt all of the user’s data.

With a key stored in the computer’s Trusted Platform Module (TPM).

If the computer was stolen by someone, this would be a good thing, because that someone wouldn’t have access to the user’s private files. That’s what encryption is supposed to be for, after all…but this laptop wasn’t stolen. The owner had it in his possession, knew the login password, and that should mean that the owner can get into the computer and retrieve his data.

Except the password for that data is stored away in a chip that won’t hand it out unless the computer works and Google’s Chrome OS is what asks for it.

Where does that leave my customer? Simple! With absolutely nothing. A failure of the computer in this case has become equivalent to a total hard drive failure. All of his data is lost forever. There is simply no way I can retrieve it for him without the encryption key locked away in a chip I can’t extract it from. Because the encryption key is not available to the user, the user can’t give it to me to decrypt his information.

Thus, you simply don’t own your own data when it’s on a Chromebook. The maker of the computer and the writer of the operating system do. Please don’t waste your money on a Chromebook…but if you do, back up your stuff.

(To a real external hard drive, not “the cloud.”)

Google semi-censors “Chromebook Sucks” searches, uses “Chromebook review” as substitute

As you know, Google Chromebooks are out, and Google advertises their existence underneath the search box on the Google home page.  However, I tried typing out a search, without quotes, for “Chromebook sucks” and was greeted with nothing but search results were “review(s)” was substituted for the term “sucks.”

Go to Google and try it yourself.  I’ll still be here when you get back.

To get actual results for “Chromebook sucks” you must enclose the words in double quotes instead.  I’m willing to give Google somewhat of the benefit of the doubt here, because usually someone who types “sucks” after something is looking for reviews about that something, and primarily negative ones, so the substitution may make sense in that regard; however, the fact that it happens when you’re trying to find negative information about a Google product presents a conflict of interest, in my opinion, and I think that they shouldn’t “help steer you in the right direction” when it’s something that they are selling and you happen to be using the search engine they also control to see what the downsides of the pitched product may be.

If you work for Google and know the reason this works the way it does, feel free to comment!

Google Chrome OS: Why it will suck, and why I don’t want it

Ah, yes, the much-speculated Google Operating System. Rumors about a possible OS from Google have been floating about for years now, and it seems that Google has finally delivered the cornucopia of computing goodness to your door. Coming soon to a netbook near you: Google’s new operating system. The news is practically flooded with articles about why Google’s fancy new OS is so important and interesting.

I’m here to tell you why it sucks, and why it isn’t really that special at all.