Skip to content

Instantly share code, notes, and snippets.

@jakearchibald
Created January 2, 2020 10:54
Show Gist options
  • Star 22 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save jakearchibald/6501e8334f6502094d0179978c27f5c0 to your computer and use it in GitHub Desktop.
Save jakearchibald/6501e8334f6502094d0179978c27f5c0 to your computer and use it in GitHub Desktop.

If you try to visit stadia.google.com in other browsers, you're told to download Chrome instead (see screenshot). This also happens in other Chromium-based browsers, such as Opera and Edge, which use Chrome's engine under the hood.

This has been spotted on Twitter https://twitter.com/tomwarren/status/1212496687949864961, and users report that stadia is fully usable in Edge if the user agent string is spoofed (I can confirm spoofing bypassed the error message, but I haven't done enough testing to confirm it's fully usable).

As you can see from that Twitter thread, this erodes public trust in Google, especially with developers, and feeds into the conspiracy theory that this is done deliberately to 'destroy' other browsers, and is very much against what we (the Chrome team) promote as good practice.

Possible next steps:

If Stadia does not depend on anything Chrome specific, and it works fine as suggested in other Chromium browsers, fix the user agent detection script so these browsers are not blocked.

For browsers that are missing functionality, continue blocking those browsers, but provide a 'technical details' page that provides reasoning, preferably with links to tickets in browser bug trackers for the missing features.

For browsers we're unsure about (features look ok, but maybe we haven't done enough testing), allow the block to be bypassed via a 'continue anyway' button, and make it clear that the experience might not be great.

@swyxio
Copy link

swyxio commented Jan 2, 2020

love the internal advocacy! thank you for setting a great example.

@ZanderBrown
Copy link

👍

@harisvsulaiman
Copy link

👍

@twistedfork88
Copy link

This is great, loved the "next steps" section too !!

@illblew
Copy link

illblew commented Jan 2, 2020

👍

@nikhil-thakkar
Copy link

💯

@rthangam
Copy link

rthangam commented Jan 2, 2020

👍

@espadrine
Copy link

espadrine commented Jan 2, 2020

For browsers that are missing functionality, continue blocking those browsers, but provide a 'technical details' page that provides reasoning, preferably with links to tickets in browser bug trackers for the missing features.

Disagree; could I try to change your mind?

Bugs are risks, and risks are inevitable.
Your car does not stop working when you go off a paved road with a warning: “Dirt road not supported.”
The world is wild, and people know that things won’t always work; they expect it.
But they much prefer a bike pump that they can try to use on unknown tires, than one that bricks itself into a weird baton if the brand is not whitelisted.

Of course, tire pump manufacturers were faced with the risk of incompatibility too.
Which is the purpose of standardization… Why else would you standardize?

So, has the Web failed as a standard?

Or should we instead always warn them the best we can, and let them go on their merry way, for the same reason that Windows 95 programs might just be compatible with Windows 10?

It is even OK to have 100% of functionality nowhere (95% on Chrome, 95% on Firefox, with a different 5%).
Browsers should be great in different ways, and webapps should not muzzle themselves in the way native apps do.

@jakearchibald
Copy link
Author

Your car does not stop working when you go off a paved road with a warning: “Dirt road not supported.”

I don't think this analogy works. Modern cars do present warnings when they think something is going wrong. Some will automatically apply the brakes if they think the user would otherwise crash. As technology improves, and false-positives decrease, you may encounter something similar to what you're dismissing. I can totally imagine a car refusing to do something, but providing the option to override on some condition ('this will invalidate your insurance' or whatever).

The override already exists - dev tools allow you to spoof the UA. But I think the bar may be too high in this case.

The world is wild, and people know that things won’t always work; they expect it.

If a website doesn't work, folks blame the web site. It seems bad to present the user an experience that the author knows will be broken. That's why I've recommended displaying warnings.

@espadrine
Copy link

The override already exists - dev tools allow you to spoof the UA. But I think the bar may be too high in this case.

I definitely agree with that.
I'd rather not the world become a hellish techscape where only hackers thrive.

(And just to confirm: I do advocate for warnings, just not outright barricade.)

@ZanderBrown
Copy link

Which is the purpose of standardization… Why else would you standardize?
So, has the Web failed as a standard?

No

You can standardise things as much as you like, but not all engines will get around to implementing them (or don't implement correctly/fully) because maybe something else is more pressing or the standard needs more work or they don't have manpower etc etc

Some browsers such as dillo are never going to support stadia but are still standards compliant, they just don't implement much of the overall web. In such cases it's perfectly reasonable to block with an unsupported message, the problem is when browsers are blocked purely based on ¬chrome instead of feature detection

@calebjenkins
Copy link

👍

@peteraritchie
Copy link

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment