Slashdot Mirror
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).
I was told my browser can't be trusted to read PDF fils.
This issue is a bit more complicated than you think.
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?
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Highlights:
You can't legislate goodness. Let each to his own destiny, by will of his freely made choices.
i've done event-driven vehicle simulators; i've clean-room network-reverse-engineered MSRPC and NT domains protocols; i've ported freedce to win32; i've added glib bindings to webkit and on top of that, ported a port of GWT to python even _more_ into python by adding DOM manipulation to pywebkitgtk.
in amongst all that mindless drivel of alphabet soup you should be getting a pretty clear picture that i'm not a stranger to complexity.
i've learned that if someone says "surely it doesn't have to be as complicated as all that", it's time to run like stink as fast as possible, out of the conversation and the room, and never look back.
browsers are effectively desktop technology within a desktop (and damn good at displaying widgets), except you're letting the web site dictate what "programs" are allowed to be "run" on your desktop^H^H^H^H^H^H^Hbrowser.
browsers are no longer "just HTML displayers", they are actually executing applications - _real_ applications - that in many instances happen to be written in javascript. GWT, Pyjamas and RubyJS should all hammer that point home.
with that in mind, why is it so hard to then imagine that, given that the "browser" is doing everything that you can also do with desktop widget UI toolkits, why is it so hard to appreciate that you need the full range of OS technology to support that desktop^H^H^H^H^H^H^H^Hbrowser technology?
Grammar problems aside, TFA blurb is difficult to read and talks about MS offering a web browser that is an OS Kernel.... that is secure... and backward compatible!
I can only conclude that this website has been hacked, and this is a huge joke. Seriously, this sounds like MS PR machine trying to pour salt directly in the wounds of the boardmembers, or this was written by a person suffering delirium after being hit in the head by a flying chair. Well, perhaps it's just MS Marketing department trying reverse psychology?
In any case, it's rather surreal to read those words.
I'm off to check that there are no foreign substances in my coffee.
Support NYCountryLawyer RIAA vs People
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.
Most of the stuff on
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 ?
The Cloud - because you don't care if your apps and data are up in the air.
i've learned that if someone says "surely it doesn't have to be as complicated as all that", it's time to run like stink as fast as possible, out of the conversation and the room, and never look back.
So you've never encountered a situation where someone added complexity because they couldn't see a simpler way to do something? I sure have. Dismissing the idea that something is too complicated and could be made far simpler out of hand simply seems wrong to me.
why is it so hard to then imagine that, given that the "browser" is doing everything that you can also do with desktop widget UI toolkits, why is it so hard to appreciate that you need the full range of OS technology to support that desktop
I could see a case for it. I could also see a case for doing it WITHOUT modifying the full range of OS technology. Why is it so hard to see that a secure browser could be done using existing operating systems?
AccountKiller
> process creation overhead
Why does Windows have so much more overhead for creating processes? What is it about the Windows processes that makes them cost that much?
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.
Any sufficiently advanced intelligence is indistinguishable from stupidity.
What is it about the Windows processes that makes them cost that much?
License fees?
The kernel has to ensure processes are obeying any DRM and WGA restrictions
Same reason that thread creation is cheap in Windows but expensive in Linux - different designs to suit different usage methodologies. In the *nix world, its very common to fork off new processes to deal with tasks, whereas in Windows, the trend is to keep everything within the same process, with multiple threads handling various tasks. Either methodology will work in either OS, and Microsoft could redesign Windows to favour processes instead of threads, and Linus et al could redesign Linux to favour threads instead of processes, but due to the way the OS's are currently used, it would be pointless.
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.
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.
Most of the stuff on
" Tahoma doesn't provide protection to existing browser principals."
That's it. I'm switching to Comic Sans.
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).
why is it so hard to then imagine that, given that the "browser" is doing everything that you can also do with desktop widget UI toolkits, why is it so hard to appreciate that you need the full range of OS technology to support that desktop
I could see a case for it. I could also see a case for doing it WITHOUT modifying the full range of OS technology. Why is it so hard to see that a secure browser could be done using existing operating systems?
sorry, i assumed it would be clear. applications running within the browser are becoming more like _real_ applications - _real_ "desktop" applications, especially with downloadable-executable-code ( "plugins" such as as adobe ) having been thrown into the mix.
and you have multiple of "applications" running simultaneously.
therefore, you have security implications, application stability implications, and much more [i recently had firefox crash out-of-memory on linux, and i have 2gb of ram and 3gb of swap space].
therefore, you need to start looking at isolating the applications from each other, whilst also allowing them access across a common API to a central set of protected resources (screen, keyboard, mouse, other devices, memory, networking), to be able to communicate across that boundary without impacting any other applications or the central resource management layer itself.
and i think you'll find that if you look closely, that's pretty much the definition of an OS.
so, working from the requirements - the expectation that good, hostile, rogue or simply badly designed applications all need to be given a chance to run, you arrive naturally at the rather unfortunately-logical conclusion that the only decent way to fulfil the requirements is with an actual full-blown operating system.
to believe that anything else can fulfil the requirements, to provide multi-tasked application stability and security, really is sheer delusion, or is... like... expecting a 1980s apple mac OS with a 68000 CPU and no Virtual Memory support, to be "secure". ... actually, there _is_ one other possibility: Security-Enhanced Linux (specifically, the FLASK security model behind SE/Linux). and we know what people think of _that_, despite SE/Linux being incredibly good at its job.
short answer: the ACL-based security model, which is transparently networked onto "NT Domain Security".
the design comprises:
* the evaluation of the security descriptor, which is a binary blob that needs to be decoded
* the creation of a process, where the parent has a security descriptor "inheritance" chain to its parent, to its parent etc. etc.
* the possibility for evaluating an individual ACE that could be on a remote machine (a PDC)
* just the _possibility_ of having to contact the remote machine (the PDC) leaves a design where the creation even of a local process requires the use of MSRPC (on "local rpc" pipes - ncalrpc) in order to not drastically overcomplicate the code any more than it already is.
goodness knows what else is going on, but it's very very powerful but unfortunately with that power and flexibility of design comes a whopping great overhead.
and no you can't cache the results very much because someone might revoke a user's right to CREATE_PROCESS and they'd get a bit unhappy about that not being obeyed.
Linux threads were relatively heavyweight in early implementations, just about as much so as processes; the current implementation is much lighter weight. So some books still floating around contain that info, since it used to be true.
A sort of separate issue is that, for a variety of reasons, most Linux distros on x86 ship with a default 8MB pthread stack size, which is fairly high--- spawning a mere 50 threads gets you a nice 400MB of control stacks. You can set the stacksize smaller with pthread_attr_setstacksize, and the unused parts of those stacks can mostly live harmlessly in non-resident virtual memory, but it still makes threads seem heavier weight than they ought to seem.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
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.
/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.
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
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).
Do you care about the security of your wireless mouse?