justinschuh

> The network stack has been out of the content process for a super long time, it is not a new thing.

FWIW, Chrome's network stack doesn't live in the content process either. It's not currently sandboxed, but it's in a process that has no scripting runtime or other dynamic content, so it's still pretty high bar for exploit. The exact reasons for the current situation have to do with some legacy Windows support that has since been removed, which is why the sandboxing work is now moving forward. So, I definitely appreciate your situation with adding some sandbox exceptions for WebRTC.

> I suspect over time we'll see our respective sandbox models become more similar over time, especially on macOS.

Fair. But I will say that Chrome being cross-platform tends to naturally push us in the direction of eliminating sandbox attack surface. Our supported platforms just differ so much that it's easiest to lock down the OS as much as possible and implement narrower, origin-bound capability brokers inside Chrome. If I were more tightly bound to a given OS implementation, I expect I'd have a lot more fights about sandboxing, because it's easier for devs to just standardize on what the OS gives you.

I don't keep up too much on Safari these days, so congrats on moving the network stack out of the content process. But looking at the current WebProcess seat-belt policy and what gets initialized, it looks like there's still far too much attack surface relative to Chrome. Things like audio/video capture and other permissioned Web APIs appear to be permitted directly inside the sandbox. And the GPU attack surface alone is a giant vector for escape--plus all the other potential escape vectors posed by that very long list of mach services.

So yeah, the seat belt policies alone aren't determinative, which is why I called them "a rough analog". And it's hard to say what gets pulled in through warmup (which is why we'll be eliminating it with our v2 bootstrap sandbox). Accepting that, it's pretty clear that there's just dramatically less attack surface exposed from inside Chrome's sandbox versus Safari's.

Indeed. Fixed now, and thanks for letting me know.

Just to add some context, on macOS you can look at the seat-belt policy as a rough analog of for basic sandboxing guarantees, where the fewer exceptions you have the stronger your sandbox is. From that perspective, Chrome's policy has around 1/10th the exceptions of Safari.

* Safari SB policy: https://trac.webkit.org/browser/webkit/trunk/Source/WebKit2/...

* Chrome SB policy: https://cs.chromium.org/chromium/src/content/renderer/render...

And of course, that's before we get into more complex forms of isolation that Chrome implements, such as the sandboxed GPU process, or ongoing work into things like network sandboxing, the macOS bootstrap sandbox, and site isolation (origin-bound renderer sandboxing).

So, the thing we call "win32k lockdown" on Chrome is just a term for the various things we had to do to enable ProcessSystemCallDisablePolicy on our sandboxed renderer processes (the processes that handle Web content). ProcessSystemCallDisablePolicy is a very big hammer, because enabling it prior to process launch means the kernel blocks all GDI and NTUser calls, such that the process can't interact with the UI or graphics subsystems. Chrome can do this because our UI and graphics acceleration layer is split into our unsandboxed browser process and the more weakly sandboxed GPU process.

The difference with Edge and IE is that they run their UI and graphics stack in their content processes, which are an analog to Chrome's renderer processes. However, any UI on Windows requires win32k kernel support, so they can't disable it like Chrome does. Instead, Edge uses its win32k filter to limit the attack surface to only the calls that they need. So, where Chrome's architecture allowed us to make an aggressive cut, Microsoft is instead working to iteratively shut off the same attack surface in Edge.

And yes, the win32k whitelist is currently restricted to EdgeHTML processes by the kernel and signature enforcement. I know this because we currently sandbox our GPU process at about the same level as an IE content process, and we wanted to use the win32k whitelist get the same improvements as Edge. Unfortunately, Microsoft is still working on the capability, and is not ready to expose it to third-parties yet (but has given signs they may be willing to do so in the future).

Source: I lead engineering on Chrome security and am the original architect of Chrome's win32k lockdown.

Yup. Our only closed source bits at this point are Flash and the Widevine CDM (DRM), both of which can be disabled from: Settings -> Content Settings.

There's no reason for FUD. We've always listed all potential data transmission or collection in this regularly updated whitepaper: https://www.google.com/chrome/browser/privacy/whitepaper.htm...

Please don't spread misinformation. Here are the facts:

1. While the Hotword module was downloaded at startup, the feature was not activated without the user explicitly enabling it via the settings menu. <https://crbug.com/500922#c6>

2. Downloading the module in Chromium was a bug, and it was fixed after being reported. <https://crbug.com/50922#30>

3. The Hotword feature was dropped from Chrome not too long after, because it was an experiment that never really panned out (and was enabled by very few people).

Really? Repeatedly? So, I'm sure you can produce a citation to this effect?

> when riseup.net got an NSL to give access to the email accounts

This is simply not true. An NSL cannot be used to compel access to any communication content—and certainly not control of an account; they're limited solely to metadata (e.g. phone call records, IP addresses, billing metadata, etc.). I'm not a fan of NSLs, and strongly support repealing the section 505 expansion, but it behooves no one to lie about what an NSL is and what it can compel.

No worries. :)

I think you may be confused about who you're replying to and what subject you're replying on.

I think we've seen it once so far, for a Flash exploit that didn't have a sandbox escape in Chrome.

Obama's first term was a firehose of this kind of hate from Beck: http://www.cbsnews.com/news/beck-compares-obama-to-the-nazis...

I actually watch Fox with some regularity and follow various conservative news sources. I may not agree with the views, but I want to understand where people are coming from. And Beck's show was consistently so far beyond the pale.

No, all we have right now are projections, which put Clinton at ~2% lead in the popular vote. We won't have final vote counts until probably December, because many millions of outstanding votes are still uncounted.

The same thing happens every presidential cycle. Counts come in much slower for populous states with large volumes of absentee, provisional, and mail-in ballots. Clinton is going to win these votes by something like a 2:1 margin.

I wonder whether you actually read the article you linked, because here's how he tries to shift the blame and deny his own accountability:

>Now, I’ve got people on the left accusing me of creating Donald Trump. And I’m like, “But I’m against Donald Trump. I warned against a guy like Donald Trump.” Well, you created the conditions that grew Donald Trump. “No, I didn’t. I think it was the government — both parties that weren’t listening to the people, that the people got so frustrated they wanted to burn the whole thing down.”

And here's the only thing he apologizes for -- a bullshit non-apology for tone rather than substance:

> And so I’ve been ringing that bell. And I’ve been telling you, “This is going to end in disaster. It’s going to end in disaster.” No exits left. There’s a cliff coming. That’s what I want to apologize for. I still believe that: there’s a cliff coming. But that is such a hopeless message that I can barely survive. And it’s because I have gazed upon the problems. That which you gaze upon, you become.

I'm not going to waste more time debating this, because there's literally nothing to debate. Beck did tremendous damage to the political discourse, and he's never owned up to to it. And what he's doing now to normalize Trump's dangerous behavior is only making the situation worse.

A non-free pass would mean Beck actually took responsibility for his actions and apologized rather than than attempt to excuse himself with false equivalence.

Let's be clear, he baselessly demonized Obama's presidency while the man was actively trying to reach across the aisle and even brought numerous Republicans into his administration. Beck fed lies and hate to incite an angry mob, and was a key player in the last eight years of the bitterest partisan divide and obstruction that we've experienced in the modern era. And now he's minimizing Trump's vile words and actions -- arguably a direct product of the climate Beck helped create -- because somehow Beck's own insane apocalyptic fantasies about Obama should normalize them? That is the furthest thing from an apology. It's a gross insult to anyone familiar with the facts, a cynical attempt to abdicate his personal responsibility, and attempts to mainstream the worst of Trump's behavior.

No. What Glenn Beck is doing right now is just pandering to his own audience that he was at risk of losing entirely if he didn't eventually fall in line with Trump.

That video was posted back in March, during the Republican primaries. I have no idea why you think it's related to the protests this week.

Mentioning BadUSB very much implies confusion about the threat models at play. That is, the threat model for BadUSB is a malicious device that attacks the host OS, drivers, or applications. Whereas, the threat model for WebUSB is concerned with malicious sites attacking or abusing physical devices attached to the system.

So, the scenario you seem to be implying would require coordination between a malicious WebUSB site and a malicious device. While I can't claim that it would be impossible, it sure seems to approach de minimis if only given the extent of user interactions and preconditions.

This response just doesn't make sense given that modern OSes expose USB through much higher-level device management and communication APIs. Those are the APIs browsers use, and I've already explained that browsers shouldn't unbind and then expose a device that the OS or another native application has already bound. So, I really don't understand what argument you're trying to make here.

Sorry, you seem to have misread my statement. Everything you just listed are devices that the OS already natively binds. I'm not aware of anyone considering WebUSB implementations that would unbind native devices and expose them to the Web. Rather, the device-level risks for WebUSB primarily center around devices/interfaces that are not in well-known classes or otherwise are not natively bound and may expose dangerous interfaces (e.g. security credentials, unsigned firmware flashing, etc.).

Sorry, but I'm at a loss for what you believe you're responding to here. I made a clear, factual statement regarding the handling of bound USB devices for known devices and classes. Specifically, HID and other native device classes that are already bound by the OS should not be exposed to WebUSB -- the reasons for and robustness of that guarantee should be self-evident to anyone moderately familiar with USB in modern OSes.

Now, if you have a specific argument to make against my statement, then please share it. I have direct experience with the subject here, and ideally can provide context to address such arguments or clear up confusion. However, I really don't think it's productive to respond with non sequitur arguments and personal attacks.

That's not at all an accurate framing. I'm not aware of any implementation that plans to allow access to HID devices (keyboard, mouse, etc.) or other device classes that are already handled natively by the browser/OS. Even ignoring security, just think of what a mess the user experience would be if sites could unbind and override native devices.

This particular restriction is intended to address things like authentication devices (e.g. gnubby) where you basically destroy the entire security model if a user accidentally allows a malicious website to connect to it.

That stated, the last round of discussions gave me the impression that browsers generally (and in particular Chrome) are leaning towards implementing this as a very alerting warning rather than an outright block.

No. We currently mostly do process-per-tab, but it gets complicated depending on how exactly a given window/tab was opened and certain resource heuristics. We're moving to process-per-origin[1], largely for the security improvement. But, that's been a huge, multi-year engineering effort that's only now approaching fruition.

[1] https://www.chromium.org/developers/design-documents/site-is...

Here's my stock response to these vulnerability counting reports:

https://plus.google.com/+JustinSchuh/posts/CNEgtJWYTb5

Ars just put up a decent article with some background, and explained how to reset your recovery keys (even on the Home edition): http://arstechnica.com/information-technology/2015/12/micros...

I have a lot of sympathy for Microsoft here, given some professional history with Chrome's Sync feature. Originally Sync data was always encrypted locally with either your Google password or a custom passphrase, and recovery wasn't possible (well, practical) absent that passphrase. The result was a bit of a support nightmare, as people would lose their sync data because they changed their account password and forgot the old one, or upgraded their machine and had forgotten the password years before, because it was being autofilled.

To solve the problem we ended up changing the way we managed the encryption, so we could recover the data for the default case, and kept the custom passphrase as an opt-in for local-only encryption. That's not to say I think we did everything we could to promote and support the use of a custom passphrase, but I am thoroughly convinced that it's not something the majority of users are concerned about or want to hassle with. If the average user forgets their password they still want to be able to get their data back (and there's no good way to forewarn or explain away why it won't work).

I think people misperceive "security fixes" as a binary thing when it's really a sliding scale. The choice to backport is often not a clearcut decision, and you need to balance the risk of the underlying issue against the potential conflicts with a legacy platform and its dependencies. Otherwise, your security update might cause quite a bit of collateral damage. So, Microsoft is understandably cautious and afaict backports only fixes for major issues.

Of course, that gets complicated when you consider something like Chrome's sandbox, which can depend on system guarantees that Microsoft may consider esoteric or just low-priority. To their credit, Microsoft is responsive when we find these kinds of issues and report them. However, it's not uncommon for the issues to not be considered important enough to backport to legacy OSes (or for the task to just be too arduous). That's why we also tend to focus our work on the most current supported versions, which also offer increasingly better mitigation technologies with each release.

That's exactly what we do. In this case it will start showing up in Chrome 48 with a link to the support page.

Tavis' work isn't enough to significantly improve the quality of any of these "security" products -- that would take a big investment that isn't really feasible for a third-party. Honestly, he's just demonstrating that these products are all littered with trivially found and exploited vulnerabilities, and that they generally make their users less safe.

Microsoft Defender is the only product that Tavis didn't repeatedly knock over in a matter of days. If I were to venture a guess as to why, I'd say that Microsoft's incentives are more in line with their users here. They understand secure development process and aren't selling Defender. So, they're starting from a better security baseline and have no reason to add tons of attack surface in the name of market differentiators.