Servo workweek security

• kmc: First, want to look at known bad areas. Second, want to talk about what we need to do before we can ship a product. Finally, we want to talk about how we should react to security issues and incent the community to help us.

Security issues

• kmc: Having a "security wall of fame" has been successful at EventBrite. Even not just for reporting bugs, but for helping analyze various modules of the project. That may turn into a Bug Bounty program later.
• jack: What does Rust do? Do they have a policy?
• kmc: I don't know.
• jack: Our SecCrit issues in Servo are issues in the Rust type system.
• kmc: You mean, unsoundness that gets triggered in our build.
• jack: Yes, but we're vulnerable to Rust bugs. So if they don't have anything for tracking these, we should get it on their agenda. Maybe they should have a Bug Bounty for 1.0.
• jack: For process, since we're not a product, we can probably just use the GitHub issue tracker - bugs don't need to be secret yet. Ones that we might are ones in Rust, and that's their problem.
• kmc: Or if we found a vuln in a dependency, like SM.
• cgaebel: What if Servo becomes part of a botnet? Like a HUGE vulnerability.
• kmc: I do sometimes worry that if I'm working on obscure alpha quality software that people can target me on it.
• zwarich: They can. And if that's a problem, you probably need to use a VM or otherwise isolate that work. There's a bunch of questions we normally have to answer PLUS what we have to do before we give people an alpha. With WebKit nightlies, Mozilla's nightlies, etc. (though Mozilla Betas have a security process, at least judging by the messages I get when using them?) in those alphas, the point is that the process isn't there. If we use the same standard, we would have no security process other than "try to be on the newest one." I don't think that's a problem, but the question is: is what we want to deliver with Servo really an alpha from other people? Or something that's more like a User Preview?
• jack: Pre-alpha?
• zwarich: Are we trying to deliver something to users so they can get a general experience and not be their "main browser" or are we inviting people to participate in active servo development by being a full user, filing bugs, etc. If it's the latter, then people should be using the latest version, but if it's meant to be a product used more long-term, though...
• jack: For a browser snapshot, it's akin to a Mozilla nightly and not for day to day use. But if we make progress on a UI tookit for Rust with Servo as the engine, we need to worry more.
• kmc: I think there is no process for FF nightlies, but it's on a basis for assuming things are somewhat secure, and we have NO basis.
• jack: Should at least have a wiki page. And find out what the Rust team is doing. That's most of what we need for incident reporting. If anything comes up, we'll figure it out.
• zwarich: Typically, you have a bug tracker with non-public-access for sec vulns. People file in that, you have to tell them what the requested embargo date is (regardless of action we take). In WebKit, you had to coordinate across many organizations, though that's easier for us since we have one delivery vehicle. Then, you find some way of fixing the bug and pull it into a branch. It's what other projects do, and that seems like what we should do. As far as congratulating people for sec vulns, we should treat it as normal in something like TWiS. Shout-outs are welcomed by the people who investigate security vluns.
• kmc: We will definitely want to have the information out to people about our interest in security.
• jack: Probably nothing special right now. Maybe Rust is at the stage where that kind of encouragement is needed.
• zwarich: Around the time 1.0 comes out, people will be interested in whether safe code is safe. Ramping up already - 4 soundness holes in the type system found in the last week.
• kmc: Those are important & severe from the perspective of Rust.
• larsberg: Scary because you can't just know where those bugs hit Servo without recompiling and seeing if we get an error.
• dherman: Naturally many of those soon, but they should disappear over coming months.
• kmc: So, if we update Rust and get a new error related to a security vuln, we'll have to check and see if that affected a Servo that's out "in the wild." Maybe need to be a bit less mindlessly mechanical about our Rust upgrades.
• zwarich: I think we don't need to go that deep right now.
• dherman: Yes, there are gradiations in claims on our security story for Servo. We're not talking about being post-beta in 2015. Most important thing should be adoption, not perfection.
• kmc: At this stage, I mostly want to describe/catalog our exposures right now. How can we get the community involved in that and get people looking at our code?

Known vulns

• jack: This is stuff we need to get nailed down on security for a nightly
• zwarich: Want to not look stupid - FIXMEs, 2 year old dependencies, etc.
• kmc: Still a few dodgy things we do...

old deps: spidermonkey stb-image -- replace with Rust-image; it is intentionally not designed to be secure no sandboxing yet all c/c++ (harfbuzz, freetype, etc)

Security in first nightlies

• zwarich: For first vehicle, could consider not persisting anything to the filesystem. Tricky with cookies (on OS10, there's a sandboxing mechanism, many on Linux, but maybe one is standardized now?). Could sandbox super hard.
• jack: Would we have to ship it in a container on Linux?
• zwarich: There are sandboxes based on syscall filtering, etc.
• kmc: Maybe on mobile? locked down android permissions.
• larsberg: jruderman recommended that we whitelist sites (reddit, wikipedia, imgur, twitter, facebook), upgrade everything to https, and require certs.
• kmc: Might want people visiting lots of sites to get more feedback on them. Maybe warn if you're off the trusted path.
• jack: I like simplified cert checking.
• kmc: It's a big ordeal to get any assurance.
• zwarich: Also, just disable SSL3.
• jack: Chrome's gonna do that. I was thinking after that attack, we should just disable all old protocols.
• dherman: Until we have to worry about web compat for known problematic things that we don't want support for...
• zwarich: Will people care we use OpenSSL?
• jack: Chrome is using it.
• dherman: We should talk with ekr about the politics. It's sensitive, but we're a research project so we may have some more flexibility.
• jack: AFAIK, we need either OpenSSL or NSS for FIPS certification.
• kmc: Can ship as a consumer product regardless, so it can be down the line.
• jack: Doesn't cost us anything to do the mandatory thing now.
• kmc: Fine for now, but I'd like to think about how we get on a Rust version of TLS.
• dherman: OK for research, but for a product path, it's a HUGE conversation. But until I'm told that we are going to get shut down for going down a path, I'd like to leave them open to us.

Whitelist, getting people to try stuff out on other sites

• dherman: Security is one part of this. I haven't been thinking about security implications of a nightly. But it's part of a larger question of the MVP of Servo and being compelling and courting adoption. For there, we want the emotional appeal, value adoption, and synergistic synergy . Competing constraints because on one had, something you can't do anything with seems terrible, but it's also important that we ship a thing that puts its best foot forward. That's all about performance (security, too). We don't want to look like morons with our first releases, but we also don't want to have tested it on a half-dozen sites, and we blow up on the long tail. It might ruin our chance at a first experience.
• larsberg: Easier to increase what we can see, but can't decrease it.
• jack: First thing is the wikipedia browser without an address bar. If we have an address bar...
• dherman: No address bar - dropdown.
• kmc: Looks like a toy otherwise. We can have a dropdown and ability to put an address bar.
• zwarich: Depends where we're at. If we are where we're at, we'd have to have a dropdown because we just don't have enough of the web ready yet. Servo cannot render the majority of the sites right now, much less the long tail.
• jack: First can either be fixed to wikipedia or dropdown. Our goal with that MVP is just tech demo so people don't have to build it themselves. As soon as what we want is feedback on bugs, etc. then we should not restrict it. We already know the problems with CNN, reddit, github, etc.
• dherman: We should not drive attention until it's an exciting item. You need to not just have it function, but it needs to be awesome.
• larsberg: My hope would be that it blows other Android browsers out of the water and ship that.
• dherman: Didn't mean to hijack the security discussion, but I think it intersects.
• zwarich: Bigger thing with security: are we trying to claim that because of Rust, the browser is secure modulo C/C++ libraries.
• kmc: People in InfoSec are skeptical of language-based security.
• dherman: Agreed. We do not want to make that claim at all.
• kmc: Just say that
• cgaebel: What guarantees will we give?
• zwarich: What guarantees does ANYONE give?
• larsberg: Seriously, handle chemspill/urgent updates. We will not do that.
• dherman: Yes. We may need such a disclaimer from the security people.
• kmc: There's nothing for nightlies...
• dherman: Don't want to be too strong. Rust's language about laundry-eating has hurt us.
• jack: We can just make it hard to use - no cookies, etc.
• zwarich: Would we put the claim that we make in our Introduction to Servo talks and put it on the site?
• jack: We have the breakdown pcwalton is working on (that about 48% of the modern security bugs are potentially handled by Rust).
• kmc: We are, eventually, going to get pwned and have to deal with a nasty blog post...
• dherman: zwarich is right that we have to have our technology story nailed down. Security is one small part our technology (which we talk about), but the rest of the stuff about the process, dependencies, etc. is on point. We have to say that we have an architecture that we believe is better for security and that in a final product we will be more secure, but that our current deliverables haven't met those goals. Too long - needs to be shorter. People - especially InfoSec - will use our words against us :-)
• kmc: Yes, we need to make sure that the words we've previously said are consistent with our product.
• jack: Our messaging has always been good in Servo.
• larsberg: We've even just said that we do not have use-after-free / buffer overruns.
• jack: The Rust message is much stronger than ours.
• dherman: The Rust message is just about safe code. Not the unsafe subdialect.
• cgaebel: Vec is unsafe! You can't write safe code that uses it and be sure it's safe!
• dherman: All languages have unsafe code at some point - it's 1s and 0s deep down. How Rust talks about itself is not how Servo should talk about itself. We don't want to say something that invites attacks and ridicule.
• pcwalton: Yes, I've always been very careful about interactions with security people, as they love to play GOTCHA if you do not carefully word your statements. I've been careful to say that we don't eliminate the vulns via Rust, just that we will reduce the surface area. I looked at the 515 SECCRIT bugs in FF that are public. Assuming based on what we intend to replace with Rust, Servo would address 48% of bugs via Rust. The rest were mostly JS-related - Chrome privilege escalation, SpiderMonkey, etc.
• dherman: That's consistent with what we want to say. That our model will reduce the surface area. Since we don't have chemspill, we don't want to start saying that we're more secure than others. Don't want to invite attacks.
• kmc: Want to invite attacks, but in a constructive way. Invite the attacks and exploits, be supportive of the InfoSec security.
• cgaebel: Super-rare secure Servo security stickers, given as a surprise before we have a bug bounty program?
• kmc: Yahoo got in trouble for that.