
Expanding Google Cloud’s Confidential Computing Portfolio - caution
https://cloud.google.com/blog/products/identity-security/expanding-google-clouds-confidential-computing-portfolio
======
throwaway93382
Is there anything else to these confidential machines other than feel-good,
security theater or certification checkmarks?

Maybe I'm overly cynical, but I don't quite understand the target audience.

For basic security and isolation between tenants as well as intrusion
prevention from third parties, I'd personally trust Google's SRE team more
than any other cloud provider in the world. They seem to have a great
historical record and if they had any slip ups there, their business would be
impacted for years.

For access to state actors, I'd trust these machines not any bit more than
conventional ones. If the key is held in memory, it's accessible. Even if it
wasn't, the data would be captured at the storage layer boundary if it was of
any interest.

~~~
woofie11
I wouldn't trust Google for security of MY data. I'd trust them for security
of THEIR data. Examples:

* Planned obsolescence for most Google devices (Chromebooks, Android device, etc.) where security updates disappear after a few years. Contrast Linux, Windows, MacOS, etc.

* The number of Android devices silently running without security updates

* Google using basic security features as an upsell on GSuite. Pay us money, or your data will be compromised.

* Android app versus iPhone app security. Android apps scarf up all sorts of information about you, and you can't make it stop.

* Chrome versus Safari/Firefox privacy/security. Chrome makes tracking/ad/etc. blocking neigh impossible.

Good B2B companies take the attitude that if my business fails because of
something they've done or could have prevented, they've failed. They're
trusted partners. Azure and AWS operate somewhat this way. For GCE, I'm a
statistic. If they do something which costs me $1,000,000 and saves them
$1000, that's good business. That comes out of their consumer-as-a-product
business lines, but it makes them nearly useless for B2B.

It's hitting their bottom line long-term; very little repeat business, and
their reputation is in the gutter for B2B, but it's great for short-term
metrics.

~~~
jeffbee
> Planned obsolescence for most Google devices (Chromebooks

Google has only EOLd two Chromebooks ever, the Cr-48 that was supported from
2010-2015 and the Pixel, from 2013-2018. The current model is guaranteed to
get updates through 2026. What's wrong with this?

~~~
ocdtrekkie
The main issue is that it's a huge step backwards from PCs to treat laptops
like phones that require model-specific updates. There are tons of Chromebook
models that Google has abandoned, just not ones they themselves manufactured.
The list is here:
[https://support.google.com/chrome/a/answer/6220366?hl=en](https://support.google.com/chrome/a/answer/6220366?hl=en)

And yes, it's Google's choice to kill these, not OEMs: Chromebooks are built
according to certain platform specifications Google hands down, upon which
they then support for a given amount of time. So claiming Google has only
dropped updates for two Chromebooks ever, ignoring all of the third party
manufactured ones, is dishonest.

Meanwhile, Windows, Linux, and macOS machines generally can run the latest
version long past when the manufacturer supports it heavily. (Less true with
Apple, but Apple's lifecycle is insanely long anyways.) You can actually take
machines built to run Windows XP and install the latest release of Windows 10
on many of them. (It sometimes even runs decently too, if you use an SSD!)

Ironically, you can run the latest version of Chrome, via Windows 10, on PCs
built for XP, but plenty of Chromebooks sold since then can't.

Additionally, Google has, like phones, positioned Chromebooks as disposable
computing devices. $200-300 price point devices that you'll end up replacing
in two or three years. Which is a massive e-waste problem, particularly given
Google's push to get schools to force every student to buy/use them. For a
supposedly green company, the entire Chromebook initiative should be seen as
an embarrassing gap in good stewardship.

Note that this entire subthread is pretty off-topic to the original article
though.

~~~
jrockway
The underlying problem is Linux's driver model. To support new features, you
have to support a new kernel. To support a new kernel, you have to port the
device drivers to that kernel. Vendors don't like to maintain their code and
changes in the kernel often break drivers, so vendors often just give up. That
is basically the end of life for anyone that chooses hardware with bad
drivers, which I guess some OEM Chromebook manufacturers did.

I did a 20% project on Chrome OS when I worked at Google. At the time, I
happened to use a Wacom tablet as a mouse and Chrome OS as my primary OS, and
so I backported all the upstream Wacom drivers to the various kernels used by
the variety of Chrome OS devices. It was a ton of work, and I really only did
it because I needed it myself and there was one really nice person on the bug
tracker who supported the tablets at his school. But it doesn't scale -- this
was the easiest and most trivial porting job imaginable, and it took me
several hours each patch; not because applying the patch was hard, but because
validating that it worked as expected took a long time. It was a 15 minute
build per device, then I had to reflash, then I had to try all the Wacom
devices I had laying around. Now imagine doing that with WiFi -- where your
laptop has to work with hundreds of craptastic access points. It's a multi-
week effort for every (device, patch) combination.

I don't work there anymore so I have no idea what the official policy is...
but understand that it's, to some extent, the OEM's problem. They choose a
WiFi chipset that breaks every kernel upgrade, and only they use it -- that's
their validation to do. If they don't want to do it anymore they say "hey we
saved three cents on the WiFi chipset, now throw away your laptop."

As to why this doesn't affect Windows... Microsoft has spent years building in
compatibility for binary blob drivers. On my fresh install of Windows 10 I
have drivers from 2008 that are running (for my USB webcam, sadly). The code
hasn't changed, so they don't have to revalidate it. It just works, forever.
But with Linux there is no such option; you have to make your code compile
against the latest kernel, or your device stops working. Hardware vendors (and
OEMs) are very lazy, and you can see that in action -- Android and Chrome OS
devices stop getting updates because nobody will maintain the code. This, I
suppose, is the cost of building atop a GPL-based operating system. Hardware
is "design once and forget". Linux is "evolve and grow forever". The impedance
mismatch between hardware vendors and software engineers leads to a bad user
experience.

~~~
woofie11
I guess I've never had that problem on my Linux desktop. I've had it for
around a quarter-century now. There's a philosophical question whether it's
the same desktop, since it has none of the original parts. I guess I've
reinstalled the OS too, probably twice in the time.

I'm sorry, but the problem here is Google. You're looking at this at a 10 foot
engineer's view. I'm looking at this at a 10,000 foot view. Google has all the
power in the world in this ecosystem. If it requires you to use one particular
type of hardware... it can do that. If it requires you to open source all
drivers... it can do that too. If it requires 20 years of support... that's
within it's power.

And if it was a Linux problem, you couldn't get around it by installing Linux
on some of the now-deprecated devices; I've seen people do that too. So Google
doesn't just break the devices that are no longer supported. It's 100%
planned.

~~~
jrockway
Remember that Google has to convince OEMs to get behind their experimental
free OS instead of Windows. They can't say "hey, you can have the OS for free,
but now you need to keep specialty embedded engineers on staff until we say
it's okay to stop maintaining drivers, which will be never" when Microsoft
will probably happily negotiate down the cost of a Windows license to near $0
and pick up the driver maintenance as well.

The question then is, why bother with OEMs? But it's necessary to drive
adoption: nobody wants to get fired over their choice of laptop vendor, and
nobody ever got fired for picking Dell / HP / Samsung. But if you pick the
weird upstart OS and anything goes wrong, you'll be blamed. So the OEMs exist
to attach their credentials to the transaction -- "we'll be happy to sell you
whatever laptops you want; you can have our Windows laptops for $2000 each or
Chromebooks for $200 each". Now you at least have some excuse if things go bad
-- "HP misled me! But we saved $1800 per student" or whatever.

When taking on a huge established incumbent, price and technical merits are
not enough, and you can't go it alone. I don't think I'm looking at things
from a "10 foot engineer's view" when I say that it will be very difficult to
take on a company with 80% market share and 40 years of industry experience
with your new Linux thingie. The OEMs are crucial there -- they have sales
contacts, they have a brand that people trust, and people need to gradually
warm up to the fact that there's a new OS in town that might save them some
money. The cost there is that OEMs don't always do everything you want -- they
have their own business to run and don't really need you to stay alive.

~~~
ocdtrekkie
> Remember that Google has to convince OEMs to get behind their experimental
> free OS instead of Windows.

I think this argument held for the first year or two of Android, where they
were a small player in the market.

...It simply doesn't hold today, where Google is a monopoly in mobile and one
of the largest platforms in the education laptop space. OEMs live or die on
Google working with them. Sales reps from major PC OEMs try to convince me to
buy Chromebooks when I call them about Windows machines I need to buy.

There's no realistic claim today that Google doesn't have the clout or
leverage to ensure their OS is supported properly. It's a choice.

------
carlosf
If one can give strong proof that everything done in a VM is encrypted, then
would it be possible to create a "decentralized cloud provider", in which data
center owners agree to a common spec for services?

~~~
luizfelberti
Not really, physical access to the machine violates pretty much any chain of
trust you can conceivably have for most (all?) security models.

Federated distributed computing relates to what you're thinking of, but it is
an extremely difficult topic, and veers into the realm of blockchains and
things like that. There is also the whole area of Zero-Knowledge
Proofs/Compute that deals with these matters:
[https://eprint.iacr.org/2013/229.pdf](https://eprint.iacr.org/2013/229.pdf)

If your threat model falls under the uber-paranoid category, you have to on-
prem everything, preferrably inside your very own bunker. There is no getting
around this afaik, and if there is there will probably be major tradeoffs
(like the blockchain thingy) instead of a "drop-in" replacement for
traditional compute.

~~~
joshuamorton
Fully Homomorphic Encryption does also work. But there's other issues that
make it infeasible outside of very specific niches (an explosion in the
compute cost).

