Hacker News new | ask | show | jobs
by sergiosgc 3437 days ago
This is another signal of an interesting development on the hardware front. What used to be decoupled, with some companies offering hardware, and different companies buying hardware, is now coupled and hidden within these mega-companies (Google, Amazon, FB).

Google is big enough to develop a trusted hardware solution for internal use only, it has no financial need to sell it. Worse, due to competitiveness in the cloud segment, it is dis-incentivized from selling the solution.

Amazon Glacier is another one. It's an interesting long-term storage solution, whose hardware implementation is unavailable to the market, since AMZN can better explore it as a service under AWS.

We are heading onto a more closed ecosystem than we are used to up until here. The cloud, which gave us the immense positive benefit of moving all capex to opex, is birthing this immense negative side effect of closing off hardware implementations in favour of exploring the added value in the form of services.

17 comments

It's not the cloud - it's the sad downside of the democratization of hardware design, as in fabs like TSMC and IP companies like ARM making it relatively cheap to make your own chips with competitive functionality in a wide range of areas. There's a lot of custom hardware outside the cloud, say in embedded electronics, that's just as closed as the stuff in server farms - closed specs and no way to program the thing, increasingly often no ability to run binaries unsigned by someone in a small set of vendors.

Moreover, the GPUs and more so, DSPs and ISPs in your phone or PC are hidden from you in that they run code written by a very small number of people. You don't even have an idea how many small DSP cores are scattered throughout a desktop-class chip, let alone what they do or how to program them. Effectively it's for internal use of a very small number of hardware and software vendors, and the software is very much tied to the hardware.

The reason computing hardware used to be open is that very few could make it and they only stood to gain from making it usable in as many applications as possible, or at least so they thought. Once (almost-)cloning hardware products became increasingly cheap with less and less vertically intergated hardware vendors (from fab to design), vertical integration moved to design+software because that's how you fend off competition today.

Another good example that I have experience with - closed firmware blobs in everyone's wifi chipsets and cell phone basebands. Early-standard ARM processors are cheap enough to embed in peripherals these days, making it easy to hide your functionality in hard-to-extract embedded software.
They are even embedded in micro SD cards...

https://www.bunniestudios.com/blog/?p=3554

Pretty sure this is nothing to do with Google manufacturing their own silicon. It's an open secret that standard Intel server chips contain "special silicon" with features which are only switched on for certain customers. I'm pretty sure this is what Google is referring to. Source: https://techreport.com/forums/viewtopic.php?t=118026
Google has been doing custom security hardware for 5 years in Chromebooks[0].

[0] https://chrome.googleblog.com/2011/07/chromebook-security-br...

Very much true. I don't think the two reasons are exclusive; it is probably a factor mix. Lowered development costs, economies of scale, need for competitive edge in a market that slopes into commoditization.
It seems a bit counterintuitive that open hardware results in less choice, so I disagree. I think that hardware is getting more and more open, also drivers for it. With FPGAs it is (relatively) straightforward for one to create it's own crypto processor and integrate it in the system. Also PCBs are getting easier and cheaper to make. I hope that also there will be some open PCB designs that incorporate some kind of crypto chips and functionalities outside of CPUs, so everyone can start creating their own servers, if desired.

Didn't also Facebook started some open server hardware initiative? I don't remember what happened with that...

I do agree that the current status is not great, and that we could all benefit from more open hardware design. I think that it would also benefit large companies as well.

> Didn't also Facebook started some open server hardware initiative? I don't remember what happened with that...

It's alive and well, but not newsworthy, thus phased out of public's attention span.

Could you link?
The fact that you're reading an article about a paper Google just published suggests it's not as closed as your doomsaying might suggest. Also the paper notes that Google is one of the largest contributors of bugs and CVEs to KVM, which is a security tide that will raise a lot of boats.
I don't think your use of "doomsaying" is fair, and detracts from a useful comment.
More ground is lost in the cold[1] civil war[2] for control of the General Purpose Computer. I hope that everyone choosing to centralize computing power likes the future they are creating.

[1] https://www.youtube.com/watch?v=nT-TGvYOBpI#t=2824 (sec. 10 - http://geer.tinho.net/geer.blackhat.6viii14.txt )

[2] http://boingboing.net/2012/08/23/civilwar.html

It's not a choice†, it's market forces. You'll never change the world effectively if you don't start by correctly diagnosing the problem.

†(as far as your objective is concerned. Yes, Google could choose not to have secure hardware, but that wouldn't change the end result that the market leaders in five years will have secure hardware — Google just wouldn't be among them.)

What is different about centralized compute power compared with centralized energy production?
Your centralised energy supplier can't monitor what you're doing with the energy, or exfiltrate your results, or even stop you from doing it.
Yes they can. See smart meters. With analytics, they can determine every appliance in your house, and know exactly when and where you come and go at all hours of the day.
> smart meters

> analytics

The smart grid requires a lot of General Purpose Computers gather that data. However, this risk has already been considered. From the link in my previous [1] (sec 7):

    ... privacy [is defined as]: the effective capacity
    to misrepresent yourself.

    Misrepresentation is using disinformation to frustrate
    data fusion on the part of whomever it is that is
    watching you. ... Misrepresentation means putting
    a motor-generator between you and the Smart Grid. ...
If smart meter monitoring becomes commonplace, there are solutions that can be deployed. In case of a pedantic reading of that quote, I'm sure Dan Geer was merely listing examples. Further isolation from the grid should probably include some amount of local energy storage to smooth out the usage rates in addition to electrical isolation.

In any case, as others have pointed out, the War isn't about centralization. The War is about the inability to turn a Turing complete system (the General Purpose Computer inside everything) into an appliance that doesn't run some programs. The universal nature of the computer puts a lot of power in the hands of the people, which scares some people and undermines many business models.

Thus there is a desire (possibly indirect) to wage war on this new threat by limiting how many General Purpose Computers end up in the end user's control and hobbling the rest with spyware/drm. If everyone has dumb terminals and "appliances" that only run authorized software, the threat of people actually using the power inherent in every General Purpose Computer is neutralized.

This war is ongoing right now, with small battles happening in every "appliance" or "service" that pretends a Turing complete computer is an appliance. The war is far from over, but we are losing a little bit more every time some piece of technology is centralized.

I never read the War On General purpose computing being about centralization as much as DRM restrictions on content and restricted developer support. In other words, it's not about deploying to the cloud versus deploying to a billion individual devices. It's about not deploying anywhere at all.
It's a sign of changing times indeed, but for the consumer's benefit.

It is absolutely in Google's best interests to externalize security for its customers as a differentiator of Google Cloud. The parent article itself links to the white paper that outlines how this is done for Google Cloud.

I understand how one may consider this a "closed ecosystem" from one perspective. However, from a customer point of view any startup or mom-and-pop can leverage these very complex and expensive world-class security developments, whereas in the past this access has been reserved to the very select few that could afford it. When the barrier to entry is lowered and access is commoditized, customer wins.

(work at Google cloud)

I've worked on both sides of the fence. My take on it is that the cloud is raising the security bar in many dimensions, but lowering it in otheres. Frankly, for-profit surveillance (and government conspirators) is at the top of my list of security concerns.

The good news is that the "evil" mega corps aren't so evil, and generally contribute back.

Also, the bar for custom hardware is dropping, and the recent moore's law stall means a good board design can live for 3-6 years instead of 1-2. In turn, this means that niche operating systems like BSD and opensource Solaris have increasingly stable hardware targets.

Taken together, this is great news.

> However, from a customer point of view any startup or mom-and-pop can leverage these very complex and expensive world-class security developments, whereas in the past this access has been reserved to the very select few that could afford it.

I don't expect startups or mom-and-pop's to build internal clouds. I do expect medium to large companies to do so. The current market turns innovations such as these into competitive advantages of Google, instead of directly exposing the innovation to the market and allowing incorporation of its advantage into anyone's product. It's a less liquid market. Either you buy all of Google's solution as a package, or you buy none. You can't pick, sort and mash a solution of your own from disparate parts.

Note that Google here is just an example. All companies of similar size in IT are doing the same, and strategically it is the correct option (for them). I'm just stating that the overall result is sub-optimal through a collusion of disparate factors.

> and strategically it is the correct option (for them).

I agree. Consider what's at stake for them. I can't even begin to wrap my head around how bad that would be if an entire server farm got rooted. At least defending a bank you know what the attacker's endgame is: steal money/SSN's. If a server farm were hacked, you'd see identity theft, blackmail, massive customer (and e-commerce) downtime, malware distribution, ddos/large botnets, market manipulation (if you started spreading false news about a particular company, at scale, on social media), perhaps brute-force RSA/SSL cracking. If those guys got hacked, it could be an absolute shitstorm. So I dont blame them at all for creating their own TPM or whatever.

> I understand how one may consider this a "closed ecosystem" from one perspective. However, from a customer point of view any startup or mom-and-pop can leverage these very complex and expensive world-class security developments, whereas in the past this access has been reserved to the very select few that could afford it. When the barrier to entry is lowered and access is commoditized, customer wins.

I don't understand why the customer can't get these benefits AND the ecosystem be open as well.

Pressure from governments to not supply consumers with hardware that is resistant to surveillance is one reason.

AFAIK, the consumer systems that are most resistant to physical attack (and that lack spooky things like Intel's system management CPU) are game consoles. The hardening is a requirement for anti-piracy and anti-cheating, and in newer generations of consoles it's been quite successful. Recent iPhones are a distant second in terms of security architecture.

> Recent iPhones are a distant second in terms of security architecture.

Source? Apple does some pretty sophisticated stuff around hardware security mechanisms and software correctness.

(I genuinely want a technical description of the mechanisms consoles use these days so I can read it -- not trying to start an argument...)

I don't have any details but without a exploit a game console will never run a single line of code that isn't signed. It makes the attack surface rather smaller than an iPhone.
Without an exploit, how does one run unsigned code on an iPhone, exactly?
I would agree with you if they cannot be updated via an internet connection.
You can't have an open ecosystem when part of the ecosystem is hundreds if not thousands of full-time security experts and 24x7 opsec analysts. It is an integrated software and operations system. The software alone doesn't get you anywhere.
> any startup or mom-and-pop can leverage these very complex and expensive world-class security developments,

Until a random cosmic ray triggers Google to revoke access for mom and pop.

There's tradeoffs, and most people don't discover them until the random cosmic ray hits the fan. And, to be fair, most Google customers probably never encounter a RCR event.

Let's be clear: The customer never wins when the product is closed. Google used to understand that: https://googleblog.blogspot.com/2009/12/meaning-of-open.html

In realty, mom-and-pop don't need these security developments, because mom-and-pop have much less attack surface on a server running in their back room. The cloud necessitates it be possible to manage a server over the Internet, but for many situations that isn't necessary. And in many cases, the limited needs a mom-and-pop company has doesn't require their infrastructure be public facing on the Internet at all.

I'd argue the only reason one needs these "world-class security developments" is because Google itself is a world-class target. The sort of threats you're defending against would almost never be necessary for a smaller business with an on-premises solution to be concerned about.

Many small business internally need little more than a shared network drive, rudimentary user management, etc. And you'd be stunned how many businesses today still operate off a single AOL mail account.

Strongly disagree. Mom and pop businesses get owned all the time and close as a result (see Krebs On Security for cites). The economics of online attacks mean that even smallish targets are not obscure enough to be safe.

Disclosure: I work on security at Google.

People's Google accounts get owned all the time too. None of this excess security measures Google is talking about helps if you have bad security practices or your password is 123456.

Google's security measures here largely are a result of a security problem Google created in the first place. That isn't unusual, mind you. Web design is much the same way. We create new problems via added complexity, then have to solve them.

The whole threat model that requires you put custom silicon in your servers just doesn't apply or matter to smaller parties.

Your comment extrem bad. If totally and utterly false that nothing google does helps against bad passwords. Google has some of the best 2Fa system pretty much compared to everybody else. They support TOTP, SMS and U2F.
Your comment is extremely bad, because we aren't talking about TOTP (an open standard), SMS (an open standard), or U2F (an open standard).

This article is about the custom security silicon in Google servers, and Google Cloud employees selling the false concept that this is a must-have for anyone but themselves. This has nothing to do with 2FA, and 2FA, in case you're curious, works everywhere not powered by Google Cloud too.

Do not attack people when you do not know the topic of the conversation you are participating in.

> immense positive benefit of moving all capex to opex

Hmm. Is that really a benefit or Enron-ing yourself? I can see how it allows efficient ramp-up of small companies which can't afford a whole sysadmin for ops, but the big downside is that the return on capital goes to the megacompanies, to whom you are paying rent.

I can sort of see why it's happened, because it's very hard to capture the added value of software by selling it. Especially in this area, the value of software is driven to zero. Whereas restructuring as a service and putting up barriers to entry brings back the margins for the developer.

We almost need an update to Coase's Theory of the Firm to account for the disruptive effects of IP-heavy organisation.

It reduces the resources needed to bootstrap your own company. Of course once it reaches a certain size, it makes it more cost effective to host your resources internally. There are also many organizations who do not want to deal with a whole division dedicated to maintaining a reliable, distributed, secure computer network for their employees and would be more willing to pay for the cloud rather than the extra people required to maintain the in-house solution.
This is not really true. Not "once you reach a certain size", but once you move off the lowest-tier starter hardware, cloud quickly becomes much more expensive than owning hardware, and security solutions continue to depend on the individual administrators (most backups do too).

Cloud's biggest benefit is really convenience, because you don't need to go to the datacenter and put in another hard drive yourself when you need more space. That's absolutely not worth the price premium most of the time. Large companies could hire hardware jockeys in-house for a fraction of the cost and smaller companies can't afford such conveniences.

For "convenience" substitute "having the technical sophistication to manage it properly". How many companies know enough to hire and retain top-notch people to run a datacenter and keep upgrading it?
Renting a rack is not the same as running a data center. The technical sophistication is available. It can be hired on the employment market or contracted as an ad-hoc service. Many colos offer a hands fee to have their staff do things like install disks on your behalf, and there is always the traditional managed server.

Chasing the cloud has cost companies a massive amount of money. I'm familiar with companies that would've saved nearly a million bucks a year by staying on bare metal/in-rack hypervisor. They weren't forced into the cloud by a shortage of people who could perform hardware maintenance, they went because it was the hip thing to do.

That's not also strictly true. I can spin up redundant cloud server instances on three continents for roughly the same price as three instances in a data center physically near me. If I need to put a drive in a physical server on the other side of the world, I'm dead in the water. It's only a matter of convenience if there's a reasonable, cheaper alternative.
While I'm sure there are unique situations that for whatever bizarre reason work out where cloud is cheaper, they're pretty rare. Most of the time, if you have a server "on the other side of the world" you're in a data center where you can ask the datacenter's staff to install another disk for you and pay any associated fee. If you put it in a datacenter that doesn't offer such services and you're 5000 miles away, that was probably a bad call.

Cloud does have some benefits and there are specific applications that are smarter to run in the cloud than on colocated hardware, but they're almost never going to be cheaper to run in the cloud.

You can sometimes save money sort of indirectly. For example, if your MySQL application is struggling and you put it on Aurora and it runs fine there, then you've saved tons of labor costs in exchange for the cost of your Aurora instance, which isn't cheap, but is probably cheaper than consulting time, but even this is a short-lived benefit because at some point the monthly rent crosses the threshold, and it locks you into an application that can only run well on Amazon RDS.

>Is that really a benefit or Enron-ing yourself?

I read it as sarcasm. ;)

"We are heading onto a more closed ecosystem than we are used to up until here. "

It wouldn't be more open even if they didn't spin their own hardware. You won't ever see it nor have access to it on a low level - it's 'the cloud'. The only thing it tells us is that they have reached a scale where custom hardware makes things cheaper, more reliable and more manageable for them.

Google joined open compute last year.
> It wouldn't be more open even if they didn't spin their own hardware.

Of course. If the alternative is non-development, we are better off. However, my text states that the alternative is de-coupling: One company develops and markets the innovative hardware solution, other companies build services on top of that solution. This would be more open, it would present a more liquid market.

> We are heading onto a more closed ecosystem than we are used to up until here.

Not necessarily. Balancing forces always come up when this kind of things happen. The closing in of big players may give a big boost to open source hardware alternatives, which combined with the advent of 3d printing, may very well lead to the democratization of hardware...

I think we should limit companies to a maximum of N employees.

This will ensure more modularity in the market. And more competition as well, because barriers are lower.

I read a sci-fi story with this premise.

Companies could only be as large as X before starting to pay prohibitively large taxes in order to stay 'for profit entities' or become companies devoted to the public good.

So you'd end up with large telecoms who were non-profits dedicated to improving the level of global interconnectivity, and lots and lots of tiny 2-10 man companies that did research or sales.

Do you have a link to this? It sounds interesting, thanks.
I like this idea. Maybe we should limit governments to a population of N citizens for the same reasons.
interesting idea, impossible to enforce. we'd end up with even more contractors, and mega-conglomerates of hundreds of companies with ~N employees each.
Is it really any different in practice? TPM is installed in basically every computer used in basically none. Even though its been a uniquitous "standard" for two decades its effectively impossible to correctly do attestation.

Similar arguments could be made for UFI and similar. Just because some can write code for it only a handful of major suppliers actually do.

Are those any more accessible than this?

I think you would have a hard time showing this is any less closed than earlier days. For good and bad. IBM used to be at your door to replace hardware you didn't know was broken yet, and couldn't have fixed if you had known.
it's probably going to be just a cycle. Much like energy is very centralized with a lot of custom hardware ( think nuclear power plants) but tends to have decentralized alternatives ( solar panels ) for some advantages, you'll probably end up with the same cycle with computing power. Once a single affordable machine will be able to serve all your applications to all your customers with zero maintenance cost ( because innovation will keep going on), you'll probably switch away from the cloud.

it may be in a long time though..

http://opencompute.org proves the exact opposite
Thinking from another perspective, are those hardware just hardware? Not really, they are solutions, with tons of software supporting them. There is no point selling individual pieces, and they will not work out of box.
> gave us the immense positive benefit of moving all capex to opex

Isn't it more correctly stated moving fixed costs to marginal costs? capex is mostly fixed, and opex is mostly variable, so you are not strictly incorrect.

Looking at what's going on in Shenzhen[1] in regards to hardware hacking, I'm not worried.

[1] https://youtu.be/SGJ5cZnoodY

This is how things have always been. It's the reason for our patent system, to incentivize companies to open up their proprietary tech.
So basically what was assumed to be a linear trend is turning out to be a dialectic.