MS Publishes Papers For a Modern, Secure Browser

V!NCENT writes with an excerpt from a new publication by Microsoft: "As web sites evolved into dynamic web applications composing content from various web sites, browsers have become multi-principal operating environments with resources shared among mutually distrusting web site principals. Nevertheless, no existing browsers, including new architectures like IE 8, Google Chrome, and OP, have a multi-principal operating system construction that gives a browser-based OS the exclusive control to manage the protection of all system resources among web site principals. In this paper, we introduce Gazelle, a secure web browser constructed as a multi-principal OS. Gazelle's Browser Kernel is an operating system that exclusively manages resource protection and sharing across web site principals." Here's the full research paper (PDF).

Comments

Does it really

[Bromskloss]

...have to be this complicated?

Re:Does it really

[Nakoruru]

I have two answers.

The snarky answer is that when one writes a paper one has to make simple things sound as complicated as possible in order to make the paper look like you've discovered something interesting.

More likely it really does have to be this complicated considering that handling security when combining content from multiple sources cannot be made simple unless you make it trivial (no trust or complete trust).

Re:Does it really

[obarthelemy]

Basically, since the browser already runs on top of an OS, the surprising thing is that they want to reimplement another OS within the browser.

I assume that OS could run a browser which could run an OS which could... Do we really want that ? Why ?

Re:Does it really

[Anonymous Coward]

"Those who can, do. Those who can't, write papers."

Re:Does it really

[CodeBuster]

Using separate processes to render content on a single page causes significant latency due to process creation overhead.

It reminds me of the practical problems that were encountered in the Mach kernel implementations and which, despite great initial interest and subsequent effort, were never satisfactoraly resolved. In fact, many have concluded that the concept of independent kernel process cooperating via message passing, regardless of the tasks that they are attempting to perform, is inherently slower than single process monolithic designs and although object orientation allows greater flexability and abstraction it is always paid for in raw performance. In many cases, and particularly in user space application software, the price is worth paying. However, it turns out that OS kernels are probably NOT one of those cases. I would be highly skeptical that Microsoft has found a way around the performance problems that the Mach people missed when it comes to a "multi-prinicipal browser" operating system. In fact, it is more likely that this is yet another case of Microsoft leveraging monopoly power in the OS market to answer the renewed threat on the browser front and "cutt off the oxygen supply" of mozilla, opera, and other competing browsers.

Re:Does it really

[Firehed]

Browser-based applications, while certainly not as powerful as most desktop apps (I've seen some web apps that are, but of course those tend to be the exception to the rule), are totally platform-independent*. When you write for the desktop, you're writing for a specific platform, and quite possibly a specific set of versions for that single platform. Web apps require no installation and will run on Windows, Mac, and Linux no problem. When someone creates an agreed-upon framework that's cross-platform, let me know; for now, that framework appears to be the haphazard combination of HTML, CSS, and JavaScript. Yes, there's always the Java VM option, but the web-based approach is still preferable for many things for a number of reasons. Maybe OpenCL or some derivative of it will take over eventually, but that day isn't today.

*Ignoring IE6 and earlier anyways. IE7 is usually close enough, and IE8 has behaved pretty predictably for me.

Re:Does it really

[pyrbrand]

The main issue right now is that a given web page often displays information from separate sources. The classic example at this point is that if I want to display ads on my web page, I have to bring in content from another source, and I essentially have to trust that content not to do tricky things with JavaScript to muck with my page - you know, display obnoxious, or worse, spoof UI, scrape user data, attack a browser vulnerability, all sorts of nastiness. Ads aren't the only example of this, the same is true of mashups ala housingmaps.com etc.

Relying on the OS is essentially what this paper is proposing as far as I can tell. They suggest that each part of a page that is relying on a different source for its content be sandboxed in its own process. However, doing this requires changes to the browser since current browsers don't do this (although Chrome and IE8 do work to isolate each tab in its own process). There are other proposals out there in the wild such as Web Sandbox discussed recently: http://tech.slashdot.org/article.pl?sid=09%2F01%2F28%2F188254&from=rss , which takes a different approach (sanitizing javascript for badness and restricting its access to the main page).

Re:Does it really

[kasperd]

Threads was havey in Linux due to bad implementation until kernel 2.6. Threads, until 2.6, was just a wrapper using process.

You are confusing the matters. The main problem with threads in earlier Linux versions were that they were not posix compliant. Threads in Linux actually offered a lot of features beyond those required by posix, and could be put to good use by programs written specifically for Linux. If you tried to make programs written for the posix thread API run on Linux things got messy. It wasn't actually performance that was the problem, but rather that the semantics of certain things were not exactly like they should be.

Saying that threads were a wrapper using processes is nonsense. If you created threads in Linux 2.4 they really were threads and performance was what you would expect from threads. In Linux 2.4 context switches between threads really were cheaper than between processes. However the naming of threads was not what you would expect from a posix system, each thread was assigned a pid, and you could get that with getpid(). In terms of process tree, signal handling, and various other aspects they behaved like processes, but in terms of shared address space and performance, they behaved like threads, because that is what they were. Having a nonstandard naming convention for threads doesn't mean that the performance goes down.

In Linux 2.6 the semantics of threads were changed to comply with posix. First of all each thread would now have both a thread id returned by gettid() and a thread group id returned by getpid(). In fact the id was assigned in exactly the same way as in 2.4, but just called a thread id instead of a process id, in addition to that the thread group id would be inherited from the parent. So when you create a process its process id and thread id are the same, but it can then create child threads, that inherit the process id and have a different thread id.

A few other things related to the thread ids were changed. For example the list of processes in /proc that used to list all threads on the system now only list the first in each group. (But you can still find a list of all threads elsewhere). And the semantics for signals changed, and there is a system call to terminate all threads in the group. But all of this is really just minor tweaks to the semantics of various system calls, it doesn't require any changes in how threads are actually implemented by the kernel.

There also were changes to improve performance, but those are completely unrelated to the semantic changes. Before those changes were made to Linux the performance was actually compared to Windows, and at the time processes in Linux were cheaper than threads in Windows. (Of course in each OS threads were cheaper than processes).

Microsoft promising a secure system?

[Stephen Samuel]

I still remember when they had the big PR to-do about how they were no longer going to treat security as a PR issue.

I don't think I'll be rushing to buy tickets to on this boat.

Dear MS,

[BitZtream]

If you can't secure your basic OS, why exactly do you expect me to believe, or in fact even read a paper you wrote about a domain in which you absolutely suck?

Re:Dear MS,

[ZouPrime]

"Dear MS"? Who's MS? Microsoft has close to 100k employees in more than one hundred countries, working on completely different products and technologies. Do you think they somewhat are a monolithic entity, that all these employees share the same skills and areas of expertise? That somehow, every security experts Microsoft ends up hiring turn into incompetents?

I can't believe this was moded insightful. Oh, wait, this is slashdot!

Re:Dear MS,

[ultranova]

That somehow, every security experts Microsoft ends up hiring turn into incompetents?

Why would Microsoft keep on releasing insecure products if it had competent security experts? Out of sheer malice?

Re:Princi-what?

[Divebus]

Fascinating. Microsoft murdered Netscape and Java for going in this direction a decade ago and now they're writing about it like they invented the notion.

Right idea, wrong source

[RichMan]

Thought #1:
Microsoft forced the registry, DLL hell, and activeX on the world when they started with a really the nice VMS security model as the basis for NT.

Thought #2:
Java is an application language with structured layered protections. And Java is pretty much now an open standard and embedded in modern browsers.

Summary:
Sure the idea is right. Why don't we all just work on making Java better?

Caution:
From Microsoft this message sounds like a joke. They fought against Java and invented all that other crap that led to the creation of the Viris protection industry. If they had done it right 10 years ago we would not be here now.

Re:Right idea, wrong source

[magamiako1]

#1. Registry is fine. What about "library hell" and "dependency hell" that other operating systems have? or "conf hell"? There are many "hells" we can talk about that exist in all systems. It's the complex nature of how the applications work.

#2. Java is not embedded in modern browsers. You need to download an extra java client to run java applications. If you're talking about javascript, that is a different story.

#3. Viruses predate Microsoft's modern operating systems. First virus/worm: The Creeper virus was first detected on ARPANET, the forerunner of the Internet in the early 1970s.[3] Creeper was an experimental self-replicating program written by Bob Thomas at BBN in 1971.[4] Creeper used the ARPANET to infect DEC PDP-10 computers running the TENEX operating system. Creeper gained access via the ARPANET and copied itself to the remote system where the message, "I'm the creeper, catch me if you can!" was displayed. - Wikipedia.

Re:Right idea, wrong source

[AceofSpades19]

#1. Registry is fine. What about "library hell" and "dependency hell" that other operating systems have? or "conf hell"? There are many "hells" we can talk about that exist in all systems. It's the complex nature of how the applications work.

The registry is a horrible idea, you make one mistake in the registry and your computer might not boot. At least with the configure file system, you can screw up a lot and you will still be able to boot at least into recovery mode

Re:Princi-what?

[Hurricane78]

No. They tried to murder them for power. Pure power. IE was the one browser to rule them all.
Fortunately they were too stupid to do anything useful with that power. They only saved the money to continue developing their web developer torture instrument called IE

Luckily, then the great Mozilla rose:

Mammon slept. And the beast reborn spread over the earth and its numbers grew legion. And they proclaimed the times and sacrificed crops unto the fire, with the cunning of foxes. And they built a new world in their own image as promised by the sacred words, and spoke of the beast with their children. Mammon awoke, and lo! it was naught but a follower.

-- from The Book of Mozilla, 11:9 (10th Edition)

And Java is as far from dead as possible. Sun won the lawsuit against MS, and Java is one of the most used server languages.

I see the good of it. Without this event, there would be no Firefox, maybe no XHTML as we know it, not such a big popularity of open source software, and not the freedom of add-ins like AdBlock Plus or Greasemonkey and Firebug.

But I do not thank Microsoft for that.

Re:the short version ..

[magamiako1]

My question to you is what parts of Internet Explorer were "embedded into the kernel", and more importantly, what exploits and viruses/worms have access to the "kernel" of the operating system through IE.

I'm no Windows kernel expert, but if you are I'd love to learn some more.

Most of the problems I've seen with IE have more to do with users installing ActiveX applications rather than flat browser exploits. While browser exploits do exist and are important to guard against, a vast majority of problems that exist out there are user-initiated.

What worms or trojans hook into the kernel of the OS?

and trashes Google Chrome ..

[viralMeme]

"Process models 1 and 2 of Google Chrome are insecure since they don't provide memory or other resource protection across multiple principals in a monolithic process or browser instance. Model 4 doesn't provide failure containment across site instances [32].

Google Chrome's process-per-site-instance model is the closest to Gazelle's two processes-per-principal-instance model, but with several crucial differences: 1) Chrome's principal is site (see above) while ">Gazelle's principal is the same as the SOP principal"

" Chrome's decision is to allow a site to set document:domain to a postfix domain (ad.socialnet.com set to socialnet. com). We argue in Section 3 that this practice has significant security risks. 2) A parent page's principal and its embedded principals co-exist in the same process in Google Chrome, whereas Gazelle places them into separate processes"

" Tahoma doesn't provide protection to existing browser principals. In contrast, Gazelle's Browser Kernel protects browser principals first hand "

Classic bait and switch, compare Chrome running on Windows to Gazelle running on some imaginary secure other OS. MS.memo: Googles Chrome is eating our lunch, quick rush out a 'research paper' trashing it, and pretend Chrome is playing catch-up with Gazelle. Like, if Chrome was so bad, then why expend time in criticizing it.

Re:Princi-what?

[pyrbrand]

Actually, they murdered them for competition, as Corporations tend to do (I'm pretty sure there's no one on any side of these markets that would turn away market share).

Re:Princi-what?

[Divebus]

And Java is as far from dead as possible.

Only through the force of programmers who eventually detected what Microsoft was up to. Please yip in if you have experience in this era of Visual Studio 97 and Visual Studio 6.0 and what it meant to polluting Java.

Initially, Microsoft "partnered" with Sun to embrace and develop Java. They released Visual Studio which included tools to work with Java - on Microsoft's terms. Sun quickly realized that Microsoft was targeting the Java language and the JVM for destruction and sued. Microsoft was extending Java to include Windows-only system calls, violating the agreements.

By the next year (1998), Microsoft was ordered to stop producing tools which used Sun's Java - but they continued with their own implementation (J++) which essentially extended Java but stripped away all the cross platform functionality. That was a knife in Java as intended - write once, run anywhere. By that time too many developers were using Microsoft's tools and they went along for the ride.

This is why so many people run the other way when Microsoft wants to get on board the Open Source bandwagon. Your throats are scheduled to be slit next.

Re:Can't even get basic text right

[Anonymous Coward]

because your comment sucked ass.