Post

SwiftOnSecurity

@swiftonsecurity.com

Something completely underappreciated in how Google Chrome revolutionized the web and security and software in general — was the silent background auto-update + and non-admin user-level installs. It set a bar that changed everything on ability to make progress & address threats. Broke IT paradigms.

SwiftOnSecurity

@swiftonsecurity.com

When Chrome came out, IT admins kept asking how it was possible users were installing it without admin? That's because they did not really understand the system. Developers and attackers in XP days were so used to users having admin they rarely bothered trying to make anything work without it.

SwiftOnSecurity

@swiftonsecurity.com

However, Chrome was happy to install its files in the user's own profile, not the system level-level directories needing admin. You can do anything you want in your own profile. Chrome set up shop, slapped shortcuts on Desktop and Start Menu, there's no user-exposed difference in the end result.

20/12/24, 3:45 am3 reposts129 likes

SwiftOnSecurity

@swiftonsecurity.com

Omg commentary from someone who was there at Google! I was going to get around to Omaha but it's possibly too in-the-weeds. It's unfortunate so many rely on weaker less mature and secure update system alternatives to it, but they are dumb-simple. bsky.app/profile/h.ol...

Joe Beda@h.olysh.it

We actually started this with the Windows Google Talk client. We wanted a native app that had a lifecycle similar to the web. The update code got pulled out as a project called Omaha (github.com/google/omaha) and was then used in Chrome.

github.comGitHub - google/omaha: Google Update for WindowsGoogle Update for Windows. Contribute to google/omaha development by creating an account on GitHub.

SwiftOnSecurity

@swiftonsecurity.com

Yes! How Google taking absolute end to end ownership of update results was an incredible bar to raise. No more blaming users they hit the update button when something breaks, or didn't when they were hacked. You have to own the entire lifecycle including breaking changes. bsky.app/profile/h.ol...

Joe Beda@h.olysh.it

Of course! More lore: Auto update is *hard*. If you get it wrong you either strand users on old versions or turn it into a DDOS against your update servers.

SwiftOnSecurity

@swiftonsecurity.com

Most people talking about Chrome's innovations would first highlight the security sandboxing and V8 JavaScript, but it was truly a revolutionary epoch in ecosystem norms. Or, why don't you hear about PDF hacks much anymore? ~Adobe adopted Chrome sandbox code. (Fun fact IE7 had sandbox long story)

Dave LaFontaine

@davelf.bsky.social

If you had said something nice about IE6, legions of grizzled web designers would have shrieked like Alderaan

@engineer.sitereliability.best

Chrome also gets some credit later on for using their dominance in the browser market to force sites toward ssl adoption. and at the time drew flak for such a hardline stance on not tls.

Neovagina Evangelion

@gammarae.design

Making me fondly remember the days of Google being good and a force for good changes.

@voradams.bsky.social

This is a real problem with Linux as a whole as you need to act and use super user access to do updates. Still, the updates are more comprehensive and faster and generally the different distro tools can do it with simple clicks or CLI prompts. You do have to choose communism though

I remember when it came out and so many fellow engs being indignant that they would take control away from users that way. No one cares about what version of Gmail they are running tho. Auto updates were such a big deal

@kageneko.bsky.social

I loath how Chrome (and later Teams) decided it was a good idea to install themselves into $UserData$; It breaks the paradigm of separating code and data. It also opened a whole new vector of attacks - Don't crack the OS, just pwn the user, and run your backdoors in $UserTemp, leeching their data.

It traded one vector for another, which it then mitigated with other security features that it could then keep updated. It was a pragmatic decision that would have been unreasonable under other conditions, but it solved the giant problem.

@seegras.bsky.social

$HOME has been that for decades on every OS but Windows. You could always install binaries there. So no, only (rather modern) Windows decided this was a thing in the first place.

Dillon "Back to making games again"

@6sidedgames.bsky.social

Dumb simple is awesome for most people. Especially large orgs. You're only as strong as your least tech savvy coworker, after all.

@shetalksabout.tech

unlesssss...

@pengrondor.bsky.social

Funny story: Years ago my high school bought a ton of thin clients for all the classrooms. They ran some mini-remote Windows thing with basically nothing installed. Obviously no way for students to install programs on them *except*:

@pengrondor.bsky.social

I found out I could of course install programs *in* my Start Menu folder. Which ended up being genuinely useful to get WinRAR installed for some school stuff, but also allowed me to install a clock program because they had disabled the taskbar clock. ☹️

@zorinlynx.bsky.social

I blame the Windows 3.1/95 days for this. Users had access to the entire system, so developers got lazy and plonked their files anywhere they liked, especially places like C:\WINDOWS\SYSTEM32 and such.

@zorinlynx.bsky.social

Then NT-based Windows came along, and people wanted to install that same software on systems that had user-level security. OOPS, now we need admin to write those DLLs and such. Took a LONG time for developers to just stop assuming they'd have admin access to install. It's a good trend.