Wouldn't you be able to deploy an app script website, which is hosted on "script.google.com" and make use of this?

your code do not run from that domain at all.

it does if I hack your dns server :)

It seems most if not all google domains are HSTS preloaded so no you can't: https://hstspreload.org/?domain=script.google.com

Does Chrome do certificate pinning checking in this case?

No it does not. Firefox does by default. But then again, you would need the user to install your cert. Good luck with that

If you mean can another domain trick Chrome into letting it access those APIs… probably not; it seems it’s based on the browser extension architecture which is already somewhat hardened and I believe doesn’t even load the code for the extension if you’re not on a matching domain (though the typical protection goes the other way around — preventing extensions from accessing website data without permission).

It seems bad enough that Google has access to it to justify ripping it out.

You just need to "register" a subdomain. So basically any google employee has potentially full access to your system?

You’re likely severely underestimating the amount of internal paperwork and review that is required to launch a new google.com subdomain.

I did one on my local network and didn't fill out anything

But only you have access to your local network.

Good thing all networks everyone connects to are always known by that user to be secure

Do these APIs not require https?

The case here was just injecting a domain. There's another thread for this post pointing out you would also need to inject a malicious root cert for https traffic, which is correct, but not impossible (and given some bad/lazy practices I've seen places do when they sign their own certs for internal infrastructure, not a far stretch)

If they can do that, they can spoof or proxy any website and collect your passwords, auth cookies, and anything else sent over the network. At that point, who cares if they can also see how much CPU you're using?

I've unlearned over my years that trying to come up with what malicious actors can do under what scenarios and conditions isn't worth the effort, because they are many, know more than me, have different goals than me, and I am one. There's endless permutations of environments and additional weakness or scenarios or a particular sensitivity of information that you don't or can't consider that make some attack really painful. For this case, maybe CPU usage or aggregate changes in CPU usage tips off an attacker on what someone is ramping up internally that can be used for espionage or even timing attacks.

What I have learned in place of that is plug holes to minimize attack vectors.

That's not necessarily true.

is your local network google.com ?

I can tell my pc what ca to trust, so yes i can make it to…

So if you can just trick someone into trusting a bogus root CA, take control of their DNS resolution, and get them to open an attacker controlled domain in Chrome then you can... Use this API to get information about their current CPU utilisation.

Wow some attack you got there.

Maybe they don't need a new subdomain, something unused could do the trick.

Probably a 'something.google.com'...

But you could have teams with DNS zone delegation who can.create.anything.like.this.google.com

Or anyone who controls your DNS resolution which has a number of paths (for example a local hosts file, possibly a router, changing your config or how you get your config to a malicious DNS server, etc)

Won’t work with https.

If that malicious actor can install a custom ca too, they can already install whatever spyware they want.

Not that easy with HSTS.

Also need a cert which is tricky

or public wifi access point

In what world does "system / tab CPU usage, GPU usage, and memory usage" mean "full access to the system"? Any Chrome extension can access this info easily, the point that the tweet makes is that there's a built-in Chrome extension that shares this info with Google's own websites without any confirmation.

What about anything on sites.google.com?

Is it really that easy? I just kind of assumed that devs could create subdomains under a dev TLD like googdev123.com, but not google.com until it was a fully-fledged product release.

Nothing at Google is that easy. It is a large and slow-moving bureaucracy.

Agree. I work at Google. I promise nothing happens quickly. It can take over a week to set up a new SQL database & client. Half coding (don't get me started on boq...) and half data integrity and criticality annotations for the data...

I don't know what setting up a new domain is like but I can't imagine it's something you "just do".

I have no idea what complaints you could possibly have about Boq. It makes you more productive, haven't you heard?

Drive.google.com links also work

If you could spoof google.com you have much bigger fish to fry.

Pretty much impossible, would need to defeat https/ct. You would have to spoof *.google.com within chrome.

So if you install your own certificate authority and then spoof the DNS it might be possible? Not so useful as an attack vector, but potentially useful for people who want to do fun things with the browsers they own.

You can just expose the data to all sites with your own extension if you have access to the device.

certificate pinning would prevent this for google related domains.

This. I think chrome is now using something called certificate transparency, but it has the same effect it won't trust your own installed CA for google.com

https://en.wikipedia.org/wiki/Certificate_Transparency

Don't have to spoof it - just put something on Google Docs and send people a link.

Google Docs is designed to not let you run arbitrary JS in a trusted (i.e. google.com origin) context, or else the author of any doc you visit could act as you on Google properties.