Robert O'Callahan wrote: > I thought we were going to rely on Rust's > isolation mechanisms for this kind of finer-grained isolation. I > thought that was a big part of the point of introducing Rust in the > first place
Let's make the assumption that some future web browser-like thing, intended for the general public to use as their everyday web access, will be based on Servo. I'm sure that these questions are FAQs, but I could not find the answers: 1. How much of that thing will be written in JS and the safe subset of Rust? What are the non-JS, non-Rust components that it would have? In particular, do we expect to rewrite all of the imported code that currently comprises browser like Chrome and Firefox, such as WebRTC, FreeType, sqlite, etc.? 2. What are the security goals for that first version of that thing? What is the end goal as far as security goals? 3. Will that thing support Flash or any other plugins? > true "process per origin" can't really scale to > large Web workloads because processes carry a lot of overhead, 4. What are the targeted minimum hardware requirements for the thing? 5. What is our model of the user's use of the thing? FWIW, not even the Chromium guys are trying "process per origin." Their current experiment is "process per site," where a "site" is same eTLD+1, e.g. *.google.com. Also, if you have 100 different sites open, that doesn't mean that you need to have 100 loaded processes, even in the process-per-site model. > but language-based isolation potentially can since the overhead > can be a lot lower. I thought that was a big part of the point > of Servo! I think there is no doubt that Rust on its own brings a lot of security advantages to a browser-like thing based on Servo. But, as the design document notes, there are things that Rust can't do. For example, Rust can't, in general, stop you from writing "if (!x)" instead of "if (x)" like I did in a recent NSS bug. > (Of course a big sandbox around the entire browser, or independent > browsing contexts, could still be useful as a second line of defense > to prevent the system from being persistently corrupted in case of a > Rust exploit.) I think access/modification of cookies, passwords, and other security-sensitive data within the browser will be (if not already) just as sensitive as access/modification of anything local to the computer for typical computer users. And, I think we can go further and say that the damage from allowing a violation of same-origin policy will approach (and, in some configurations, exceed) the damage done by escaping from a hypothetical whole-browser sandbox. Consequently, I think that we'd be best served by concentrating effort on guaranteeing the enforcement of same-origin policy (which subsumes protection of credentials and arbitrary code execution with the full rights of the user account running the thing based on Servo) in *some* useful way. I think there are several different reasonable alternatives for doing that, based on what our risk tolerance is in terms of security, and what our risk tolerance is in terms of overhead. I am very interested in, and supportive of, the idea that we can eventually write highly-secure, high-performance software without relying on sandboxing in the way that every other browser does it. Just, from all the things I've read and heard, it is very unclear that Servo will end up to be competitive in terms of security with competitors in a reasonable timeframe given a reasonable estimation of resources, especially if Google's process-per-site experiment is successful. That is why I think it is valuable to further explore how sandboxing could be used to increase security assurance and reduce risk for the project. And, my concern is that if we wait until after we've designed and implemented huge chunks of Rust, we'll find any work to attempt sandboxing to be a drag on the project, instead of an accelerant. Or, in other words, I think that if we have a good plan for sandboxing now, then there's a good chance that sandboxing could help us ship some thing based on Servo to r eal people faster. Cheers, Brian _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
