| HN Mirror

I think what you're saying is that I acted on incomplete information due to the fact that Google didn't publish much of it. Instead, I have to generate some mental model via fragments scattered among news stories, a few papers, tips in video presentations, and Twitter comments. Google publishing all their security methods in full in one place would certainly help. We know that ain't gonna happen. ;)

Now, let's look at it from my vantage point in high-assurance security: the kind that stopped nation-states regularly in the past from pen tests to the field. Obviously, any smart organization would do variations on what worked before or even hire people responsible for past successes, right? I saw this in action at Microsoft Research & some operations side where these things showed up when they tried to 180 their security:

1. Steve Lipner of VAX Security Kernel brought in to apply high security lessons to Windows, etc. Created a mini version of Orange Book lifecycle called SDL that knocked 0-days down across board.

2. Lampson and Lamport were brought in at some point to build on their strong methods for verifying software... especially protocols that were a pain point for Microsoft. I think this was independent of security effort with it more for correctness in general.

3. Microsoft encouraged as much Windows software as possible to be written in memory-safe languages on a cross-language runtime allowing best tool for the job. That cross-language concept, kernel architecture, and clustering scheme came from the ultra-robust OpenVMS.

4. Seeing driver errors, Microsoft created a formal model of the driver interface plus static analysis tools to ensure drivers couldn't crash the system due to interactions. I haven't seen a blue screen in forever due to this. My Linux desktops freeze from driver errors on occasion, though.

5. Things like VAX Security Kernel virtualized operating systems with strong, tiny TCB's that knocked out cover channels and other esoteric attacks. Microsoft helped third parties apply the successor, MILS model, to Windows via INTEGRITY-178B, LynxSecure, and VxWorks MILS. Each of these partitioning, 4-12Kloc microkernels were heavily pentested by NSA with two getting two years each.

6. Microsoft Research applied a combo of Design-by-Contract, static analysis, and formal verification to many areas of software. Tools include Abstract State Machines, Spec#, Dafny, a safe assembler, and separation logic to a number of components. Languages such as Dafny were designed from get-go to be amendable to static analysis and formal proof. Proved memory safety for a good chunk of Hyper-V. Their VerveOS was proved safe all the way to assembly. Independent team used those tools for ExpressOS in mobile space. Midori took lessons further at level of a production OS.

7. Seeing hardware issues, partnered with Trusted Computing Group to put whitelisting and integrity checking at or near CPU level. They and Beyond Trust built FDE and authentication systems on that. Fact that they also wanted DRM kept this from going anywhere past an option on PC's that many buyers ignored. Vendors for No 5 and academics utilized them when present for better schemes anyway.

8. Did a lot of what I call tactical stuff that has bypass potential such as No Execute, compiler tweaks, sandboxing, etc. Google does that, too.

9. Another Google did... with award-winning paper... was in browsers. OP Web Browser was high-assurance browser from CompSci that combined POLA architecture, formally-verified restrictions for plug-in interactions, and memory-safe language. Google, putting performance above everything, watered that down with very, clever scheme called NaCl for Chrome that raised the bar but got bypassed a lot. Microsoft's Gazelle Browser developed same year was a stronger design that combined memory-safe language, reference monitor with wider application, and fewer compromises that could hurt security. Also, what they used could tie-in to verification or isolation techniques I already mentioned since various teams intentionally reuse technology they know other teams are improving.

So, looking at what they were doing, I could tell that Microsoft Research & whoever brought in Lipner had knowledge of or experience in high-security or high-integrity software. They also knew what to invest in to get it both more productive and higher in assurance over time. This was applied from high-level languages to assembly, from CPU checks to browsers, and with whatever tactical improvements they could. Backwards compatibility (aka billions in profit) drastically reduced how much they could apply it but what applications they did hugely reduced risk. Being Microsoft, they ruined all that for me by loading up Windows 10 with surveillance features. (sighs)

So, I look at Google. I see a clever browser whose compromises predictably defeated its security goals. I saw no use early on of any high-assurance techniques for core infrastructure as above. I see a steady stream of tactical improvements like hardening of insecure platforms (OS/virtualization combos), authentication schemes, programming languages not designed for verification, and so on. No evidence they had people in key positions aware of what stopped nation states before and baking that wisdom into what they were doing. Eventually I saw them do some tamper-resistant something using a high-profile hacker (Mudge) who never designed a high-assurance system that I'm aware of. Meanwhile, IBM brought in legendary Paul Karger himself to design a CPU that enforced information flow security on its operations plus a smartcard OS (Caernarvon) that applied EAL7 lessons for bulletproofing on tamper-resistant hardware done by pros in that field.

I double down on my claim. There's no reason to believe Google can resist nation-states if they don't use the methods required to resist nation-states. They have resources to do a lot more review, testing, and monitoring than most where they might luck out. The problem is they have massive complexity + data throughput where 0-days and attackers have more room to hide. Pentetrate-and-patch with ad-hoc methods falls appart more often in such situations. Better to apply methods where economically feasible to provably eliminate entire classes of flaws like teams at Microsoft and IBM were doing. There were small-ish companies doing it, too, with some having products in about every category. Only way Google could consistently miss it is if their engineers never saw those techniques (common problem) and/or their management thought they didn't need third-party help given their people were so smart. Just a guess as in beginning of my comment I have no data to know why they didn't hire or contract the best of high-assurance field to get them a huge, head start on most-critical stuff.

Note: Don't let solipsis fool you. I'm a huge fan of Google's engineers for IT in general. The work from Google File System to F1 DBMS showed The Right Thing mentality where they learned from strong, past work plus industrial applicaiton. I also want a FOSS clone of F1 pronto. Business model I have strong hate for albeit it's understandable. I call out INFOSEC bullshit about stopping nation-states on the whole industry with Google being no exception. They did a bit better than a lot of IT companies, though. At least learned from one, high-assurance product in web space plus implemented strong tactics in ChromeOS.

EDIT to add: I'm also interested in anything Google has done that matches what's on this list. Provable correctness or security down to the assembly. Processors immune to code injection or info leaks at instruction level. Automatic or easy model-checking of correctness of protocols. I bet they do TLA+ on that one by now on top of Protobuf work.