11/17 Reviews - Gazelle
4 views
Skip to first unread message
Rodrigo
Nov 16, 2009, 6:21:09 PM11/16/09
to CSCI2950-u Fall 09 - Brown
Second to last chapter: Browsers!
Please post your reviews here.
Please post your reviews here.
qiao xie
Nov 17, 2009, 12:08:29 AM11/17/09
to brown-cs...@googlegroups.com
Paper Tile: The Multi-Principal OS construction of the Gazelle Web Browser
[Date] 2009 [Author] Helen J. Wang ,..
[Novel Idea]
Make the browser behave like an operating system. Gazelle's browser kernel sits between OS and web site principles. It isolates princeples from each other and manages system resources among them.
[Main Results]
Current Browsers are not safe in that errors in one web site principle may affect other principles or the whole Browser application. Gazelle's browser kernel functions like an OS kernel which manage all system resources among different processes. Different principles communicate with each other through the browser kernel. An IE-based prototype is built to show that it is feasible to turn existing browsers into a multi-principle OS using backward-compatible approach.
[Impact]
Gazelle is moving towards the right direction. As web service becomes more and more popular, browsers will need similar security guarantees as OS. This paper showed us how to do that in a practial way.
[Evidence]
The author states the problem and presents Gazelle's security model. Then it analysize cross-origin vulnerabilities, display vulnerabilities and plugin vulnerabilities respectively.
[Reproducibility]
Not easy. Gazelle is not an opensource project. Although the design idea is clear, there are a lot of engineering details missing and one must be experienced in OS layer development.
[Comparative Work]
No existing browser has the exclusive control to mange system resources among web site principles. Chrome's principle is site. IE8's principle is tab. Gazelle's principle is the same as the SOP principle. Therefore Gazelle has more fine-grained isolation. In the OP web browser, interactions between browser components must use IPC which provides no additional security protection.
[Question]
How to make Gazelle faster?
[Criticism]
No discussion of how to improve its performance.
[Ideas for further work]
Solve memory realted vulnerabilities.
2009/11/17, Rodrigo <rodrigo...@gmail.com>:
joeyp
Nov 16, 2009, 11:49:36 PM11/16/09
to CSCI2950-u Fall 09 - Brown
The Multi-Principal OS Construction of the Gazelle Web Browser
Wang et al
This paper presents a prototype of a new web browser architecture. It
is based on the idea of identifying the *principals* responsible for
the different pieces of web sites and pages, and isolating them from
one another, similar to the treatement of processes in modern OS.
The main new idea is identifying which parts of the browser's
functionality, from pages to frames to cookies, can be accessed by
which entities, and what the mechanism is for identifying these
entities. Tha paper primarily appeals to the analogy of the browser
providing operating-system like functionality for the web programs
that run within it.
The challenge of scoping out exactly *what* constitutes the agent in a
web program is a valuable one. Most browser security vulnerabilities
seem to come up from confusions about privilege and access to the DOM
when in contact with malicious other web programs. There is simply
too much sensitive data in one place, with controls on its access only
in somewhat unprincipled software. Some formal separation does need
to be made, and implementing in the way this paper suggests is at
least a first step in that direction.
Based on the widespread use of IE because of its presence in Windows
distributions, it seems like the work in this paper could have a huge
impact if it makes it as Microsoft's browser.
A comment about the presentation of the software. I, as a reader, am
not generally interested in debugging efforts, nor how hard it was to
write these programs. I know that it is really difficult to write
successful, robust software, and people struggle with it. However,
the bugs that are found during the "evaluation" of visiting a few web
pages seem like the early steps of debugging - not a research
acheievement. This paper was probably under a deadline, but still it
strikes me as a weakness of this paper (aside from the fact that the
evaluation is totally hand waving and not really there).
And if a key result is browsing 19 out of 20 sites, why not at least
tell us which one was failed on? Also - the fact that some iframes
broke is far from trivial. Maybe the ones they ran into were small
cases, but in making an argument for compatibility, I wonder how GMail
would fare if it had different processes for all of its iframes
(there's more than a few), and how well Gazelle would keep track of
all their communication, both semantically and performance-wise. This
could even be a problem outside of their prototype, in a production
version.
A lot of pages follow the pop-up to get some information, reading it
back on the main page afterward. It's a good question how much
reimplementation would be involved to make all of these things work
with only postMessage() and sendEvent() (which are in the HTML 5
specification, or at least postMessage() is). I'm not sure that this
is necessarily a bad thing, as the current way of doing it - handing
around access to things about your parent and child windows - can be
have really weird complexity, bugs, and security vulnerabilities.
The paper mentions that some sites set their document.domain to a
different origin, but disallowing this might not actually "break the
operation" of these sites. It would be interesting to know why they
do that. One example that springs to mind is using authentication
data between different subdomains on their site, say mail.google.com
and calendar.google.com. It would be interesting to see how many of
these do or don't break when denied this ability.
This paper also makes me think about how to define "breaking" or "not
functional" for web pages. None of the major browsers implement these
things in the same way, even for a reference implementation. And IE,
which this paper works from, is notoriously standards-uncompliant.
So to test a new browser, you check if everything works more or less
as expected, and doesn't look any worse than it does in firefox.
There's a need for some more formal verification strategies here.
Wang et al
This paper presents a prototype of a new web browser architecture. It
is based on the idea of identifying the *principals* responsible for
the different pieces of web sites and pages, and isolating them from
one another, similar to the treatement of processes in modern OS.
The main new idea is identifying which parts of the browser's
functionality, from pages to frames to cookies, can be accessed by
which entities, and what the mechanism is for identifying these
entities. Tha paper primarily appeals to the analogy of the browser
providing operating-system like functionality for the web programs
that run within it.
The challenge of scoping out exactly *what* constitutes the agent in a
web program is a valuable one. Most browser security vulnerabilities
seem to come up from confusions about privilege and access to the DOM
when in contact with malicious other web programs. There is simply
too much sensitive data in one place, with controls on its access only
in somewhat unprincipled software. Some formal separation does need
to be made, and implementing in the way this paper suggests is at
least a first step in that direction.
Based on the widespread use of IE because of its presence in Windows
distributions, it seems like the work in this paper could have a huge
impact if it makes it as Microsoft's browser.
A comment about the presentation of the software. I, as a reader, am
not generally interested in debugging efforts, nor how hard it was to
write these programs. I know that it is really difficult to write
successful, robust software, and people struggle with it. However,
the bugs that are found during the "evaluation" of visiting a few web
pages seem like the early steps of debugging - not a research
acheievement. This paper was probably under a deadline, but still it
strikes me as a weakness of this paper (aside from the fact that the
evaluation is totally hand waving and not really there).
And if a key result is browsing 19 out of 20 sites, why not at least
tell us which one was failed on? Also - the fact that some iframes
broke is far from trivial. Maybe the ones they ran into were small
cases, but in making an argument for compatibility, I wonder how GMail
would fare if it had different processes for all of its iframes
(there's more than a few), and how well Gazelle would keep track of
all their communication, both semantically and performance-wise. This
could even be a problem outside of their prototype, in a production
version.
A lot of pages follow the pop-up to get some information, reading it
back on the main page afterward. It's a good question how much
reimplementation would be involved to make all of these things work
with only postMessage() and sendEvent() (which are in the HTML 5
specification, or at least postMessage() is). I'm not sure that this
is necessarily a bad thing, as the current way of doing it - handing
around access to things about your parent and child windows - can be
have really weird complexity, bugs, and security vulnerabilities.
The paper mentions that some sites set their document.domain to a
different origin, but disallowing this might not actually "break the
operation" of these sites. It would be interesting to know why they
do that. One example that springs to mind is using authentication
data between different subdomains on their site, say mail.google.com
and calendar.google.com. It would be interesting to see how many of
these do or don't break when denied this ability.
This paper also makes me think about how to define "breaking" or "not
functional" for web pages. None of the major browsers implement these
things in the same way, even for a reference implementation. And IE,
which this paper works from, is notoriously standards-uncompliant.
So to test a new browser, you check if everything works more or less
as expected, and doesn't look any worse than it does in firefox.
There's a need for some more formal verification strategies here.
小柯
Nov 16, 2009, 11:38:35 PM11/16/09
to brown-cs...@googlegroups.com
Paper Title: The Multi-Principal OS Construction of the Gazelle Web Browser
Authors: Helen J. Wang
Chris Grier
Alexander Moshchuk
Samuel T. King
Piali Choudhury
Herman Venter
Date: 2009
Novel Idea:
Facing the similar problem of isolation between web program, Gazelle presented a more sophisticated architecture. It works as a OS platform to manage the resource and protect each other among web site principals. To interact with other principals, one must call IPC and be identified as valid by Gazelle.
Main Result:
Gazelle is built and provides even more granularity in web principal isolation. It's later evaluated to show that doing this doesn't severely affect the performance.
Impact:
As Gazelle works as a browser OS kernel to complete this management task, there might be more complicated platforms proposed to deal with the same problem. This is because the complexity of web application today causes the browser to become a new platform and needs more management mechanisms.
Evidence:
Authors compare thier work with other browsers and explain the differnce and why they decide to do the isolation on this granularity. They also introduce their test result to show it won't affect the efficiency a lot.
Prior Work:
Competitive work:
Chrome
Reproducibility:
Yes.
Question:
About the isolation granularity, Gazelle separate them not just based on domain name.
This seems to make sense; however, sometimes it's also convenient for the resource to be shared between different site in same domain to decrease the efficiency overhead. There should be a tradeoff, is there any performance comparison between these two method?
Criticism:
Ideas for further work:
Authors: Helen J. Wang
Chris Grier
Alexander Moshchuk
Samuel T. King
Piali Choudhury
Herman Venter
Date: 2009
Novel Idea:
Facing the similar problem of isolation between web program, Gazelle presented a more sophisticated architecture. It works as a OS platform to manage the resource and protect each other among web site principals. To interact with other principals, one must call IPC and be identified as valid by Gazelle.
Main Result:
Gazelle is built and provides even more granularity in web principal isolation. It's later evaluated to show that doing this doesn't severely affect the performance.
Impact:
As Gazelle works as a browser OS kernel to complete this management task, there might be more complicated platforms proposed to deal with the same problem. This is because the complexity of web application today causes the browser to become a new platform and needs more management mechanisms.
Evidence:
Authors compare thier work with other browsers and explain the differnce and why they decide to do the isolation on this granularity. They also introduce their test result to show it won't affect the efficiency a lot.
Prior Work:
Competitive work:
Chrome
Reproducibility:
Yes.
Question:
About the isolation granularity, Gazelle separate them not just based on domain name.
This seems to make sense; however, sometimes it's also convenient for the resource to be shared between different site in same domain to decrease the efficiency overhead. There should be a tradeoff, is there any performance comparison between these two method?
Criticism:
Ideas for further work:
2009/11/16 Rodrigo <rodrigo...@gmail.com>
Dan Rosenberg
Nov 17, 2009, 12:03:07 AM11/17/09
to brown-cs...@googlegroups.com
Paper Title
The Multi-Principal OS Construction of the Gazelle Web Browser
Authors
Helen J. Wang et al.The Multi-Principal OS Construction of the Gazelle Web Browser
Authors
Date
2009
Novel Idea
The authors present Gazelle, "a secure web browser constructed as a multi-principle OS".
Main Result
Gazelle enforces stronger separation of web principles than existing browsers, at some cost in performance.
Impact
The ideas in this paper are fundamentally good, and may provide the groundwork for future multi-process browser implementations.
Evidence
The authors analyze Gazelle's performance by measuring the time required for several common tasks and the memory footprint and comparing to IE7 and Chrome. Network latency is real, so that adds an element of unpredictability that they might have eliminated.
Prior Work
The article refers to and expands upon previous work in multi-process browsers, especially OP, Chrome, and Internet Explorer.
Reproducibility
Neither the application nor its source code are available, so good luck reproducing this.
Criticism
I take issue with any solution claiming to be the "future of browsing" that doesn't even attempt to provide any sort of cross-platform capability. In addition, measuring the performance of a stripped-down implementation against other fully developed browsers that offer a much richer feature set seems a bit unfair. Also, 19 out of 20 sites rendering successfully is just not good enough compatibility to be considered for adoption by users. Finally, the memory overhead required is many times that of Chrome, and relying on the fact that memory is generally plentiful these days seems like a poor design decision.
Questions/Ideas for Further Work
There are a lot of "except for OP" statements in this paper. Comparing Gazelle to OP seems like a logical step...and if OP already handles all of the concerns addressed by Gazelle, why did it need to be built? Also, I would be interested in a study that actually ported some plugins and analyzed their performance in Gazelle.
Steve Gomez
Nov 16, 2009, 7:14:24 PM11/16/09
to CSCI2950-u Fall 09 - Brown
Author: H. J. Wang et al.
Paper Title: "The multi-principal OS construction of the Gazelle web
browser"
Date: MSR Tech Report, February 2009
This paper presents Gazelle, "the first web browser that qualifies as
a multi-principal OS for web site principals." Gazelle stands apart
from other multi-process web browsers because its browser kernel
exclusively provides process isolation and resource sharing for all
system resources. One big contribution of Gazelle is how it isolates
principals (web origins) into separate protection domains that can
only fail or waste resources in isolation. At the same time,
processes can communicate through the browser kernel, so there is no
loss of flexibility with this scheme.
Prior work includes multi-process browsers, like IE 8, Google Chrome,
and OP. Of these, OP provides a browser kernel with similar
protection guarantees about plugin content as Gazelle, but still lacks
the cross-principal protection (e.g. display delegation) needed as an
OS.
One distinction this paper draws is a design goal in Gazelle - inter-
principal security - that differs from Chrome's and IE8's goal of host
protection from web content. By moving this security concern toward
the principals, Gazelle is one step closer to being a true OS than
previous work.
This paper is very detailed about principal/security analysis and
implementation, and could be reproduced.
The authors evaluate Gazelle on responsiveness, page load latency,
memory overhead and process creation. It was nice to see they
compared against both a popular monolithic browser (IE7) and a multi-
process browser (Chrome). At couple criticisms about this section are
that
1) the authors could have used better presentation of their results
(e.g. some plots, instead of two tables and other results scattered
through the text), and
2) if there "numerous optimizations" that might really prove the
performance is on par with production browsers, why weren't they
implemented for these experiments?
Overall, I liked the presented approach to security in browser
kernels, and think this paper brings browser technology a step closer
to performing as a true OS.
Paper Title: "The multi-principal OS construction of the Gazelle web
browser"
Date: MSR Tech Report, February 2009
This paper presents Gazelle, "the first web browser that qualifies as
a multi-principal OS for web site principals." Gazelle stands apart
from other multi-process web browsers because its browser kernel
exclusively provides process isolation and resource sharing for all
system resources. One big contribution of Gazelle is how it isolates
principals (web origins) into separate protection domains that can
only fail or waste resources in isolation. At the same time,
processes can communicate through the browser kernel, so there is no
loss of flexibility with this scheme.
Prior work includes multi-process browsers, like IE 8, Google Chrome,
and OP. Of these, OP provides a browser kernel with similar
protection guarantees about plugin content as Gazelle, but still lacks
the cross-principal protection (e.g. display delegation) needed as an
OS.
One distinction this paper draws is a design goal in Gazelle - inter-
principal security - that differs from Chrome's and IE8's goal of host
protection from web content. By moving this security concern toward
the principals, Gazelle is one step closer to being a true OS than
previous work.
This paper is very detailed about principal/security analysis and
implementation, and could be reproduced.
The authors evaluate Gazelle on responsiveness, page load latency,
memory overhead and process creation. It was nice to see they
compared against both a popular monolithic browser (IE7) and a multi-
process browser (Chrome). At couple criticisms about this section are
that
1) the authors could have used better presentation of their results
(e.g. some plots, instead of two tables and other results scattered
through the text), and
2) if there "numerous optimizations" that might really prove the
performance is on par with production browsers, why weren't they
implemented for these experiments?
Overall, I liked the presented approach to security in browser
kernels, and think this paper brings browser technology a step closer
to performing as a true OS.
Kevin Tierney
Nov 16, 2009, 7:48:51 PM11/16/09
to brown-cs...@googlegroups.com
Paper Title: The Multi-Principal OS Construction of the Gazelle Web Browser
Author(s): Wang, et. al.
Date: USENIX 2009
Novel Idea:
Inspired by operating system ideas, Gazelle provides a browser kernel
that separates websites and manages sharing between them. The kernel
provides a set of principals to web-pages to use in their execution,
and ensures fair sharing of resources. In addition, Gazelle enforces
"SOP" (same-origin policy) on plugin content to provide for safer
browsing.
Main Result(s)
The authors conclude that incorporating OS principals into the browser
adds security and stability to the browser (one rogue website should
not be able to crash the browser).
Impact
If implemented correctly, a browser using these ideas could provide an
incredible leap in security.
Evidence
The authors perform some tests against firefox and IE7 in which
Gazelle doesn't fare terribly well. Perhaps this is simply due to
their implmentation, but using 88MB of RAM vs. Google Chrome's 19.4 MB
to load nytimes.com is not very good.
Prior Work
This work builds mainly on Google chrome, providing a stricter
approach to multi-process browsers.
Competitive work
Google Chrome is the main competitive work, and seems to perform
faster with less memory usage.
Reproducibility
No, I would need access to Gazelle's code which doesn't seem to be available.
Question
Why does this browser use so much memory? How is it possible to use
88MB on nytimes.com??
Criticism
I hope the slowness and memory usage in the evaluation are
implementation details that can be improved, since the security
benefits of this browser are potentially great.
There are billions of websites on the net. They evaluated their
browser for memory usage and latency on two of them.
Ideas for further work
No
Juexin Wang
Nov 17, 2009, 12:05:04 AM11/17/09
to brown-cs...@googlegroups.com
Paper Tile:
The Multi-Principal OS construction of the Gazelle Web Browser
Date:
2009
Author:
Helen J. Wang ,...
Novel Idea:
Gazelle is a OS like browser which has the exclusive control to manage the protection of all system resources among web site principals.
Main Results:
Gazelle's browser kernel runs in a independent OS process and talk to the OS directly. Web site principles are put into seperate protection domains and communications among them must go through browser kernel.
Impact:
It is a big step of browser evolution. The web browsers is shifting to web OS. More OS design ideas will be applied to the browser development.
Evidence
The author first illustrated the security problem of current browsers. Then it showed Gazelle's security model. After that it described in categories different protection strategies.
Reproducibility
Yes. Applied these design ideas into some open-source web browsers, such as Chrome.
Comparative Work
Various process models supported by Chrome. In Chrome, a web site principle and its embeded principles(such as iframe) are put in the same process. In Gazelle, they are in different processes. Gazelle has a finer granularity. IE8's granularity is browser tab which is also not sufficient.
Question
How to make Gazelle faster?
Criticism
Gazelle is much slower than popular web browsers and cannot browser all popular sites.
Ideas for further work
Gazelle is only a prototype now. It has bad performance comparing to current mainstream browsers and cannot browser all common websites. These flaws must be eliminated before putting into actual use.
J.W
Happy to receive ur message
The Multi-Principal OS construction of the Gazelle Web Browser
Date:
2009
Author:
Helen J. Wang ,...
Novel Idea:
Gazelle is a OS like browser which has the exclusive control to manage the protection of all system resources among web site principals.
Main Results:
Gazelle's browser kernel runs in a independent OS process and talk to the OS directly. Web site principles are put into seperate protection domains and communications among them must go through browser kernel.
Impact:
It is a big step of browser evolution. The web browsers is shifting to web OS. More OS design ideas will be applied to the browser development.
Evidence
The author first illustrated the security problem of current browsers. Then it showed Gazelle's security model. After that it described in categories different protection strategies.
Reproducibility
Yes. Applied these design ideas into some open-source web browsers, such as Chrome.
Comparative Work
Various process models supported by Chrome. In Chrome, a web site principle and its embeded principles(such as iframe) are put in the same process. In Gazelle, they are in different processes. Gazelle has a finer granularity. IE8's granularity is browser tab which is also not sufficient.
Question
How to make Gazelle faster?
Criticism
Ideas for further work
Gazelle is only a prototype now. It has bad performance comparing to current mainstream browsers and cannot browser all common websites. These flaws must be eliminated before putting into actual use.
Second to last chapter: Browsers!
Please post your reviews here.
-- Please post your reviews here.
J.W
Happy to receive ur message
Sunil Mallya
Nov 16, 2009, 10:35:25 PM11/16/09
to CSCI2950-u Fall 09 - Brown
Paper Title
The Multi-Principal OS Construction of the Gazelle Web Browser
Author(s)
Wang, Helen J., Grier, Chris, Moshchuk, Alexander, King, Samuel T.,
Choudhury, Piali, and Venter, Herman
Date
Proceedings of the 18th USENIX Security Symposium 2009-08
Novel Idea
Transform the browser into a browser kernel which has the exclusive
control to manage the protection & fair sharing of all system
resources. Basically borrow OS concepts to build a robust and feature
rich browser
Main Result(s)
The authors propose a research browser which essentially is an
operating systems of sorts which can manage resources and isolate web
content. They create a prototype that turns the existing browser into
a multi principal OS that is more secure and robust with acceptable
performance.
Gazelle has a robust security model which protects respective
resources into OS enforced protection domains and segregating their
access to resources. The browser kernel runs in a separate protection
domain and interposes between browser principals and the traditional
OS. Their architecture borrows a lot from os model and abstraction
interms of applications (processes) very similar to google chrome, but
gazelle unlike chrome doesn’t consider the registrar controlled domain
name to be the same and also when a site embeds another principal’s
content, these are put in different instances. Essentially, the
browser kernel functions as an operating system to browser principals
and manages the protection and sharing of system resources for them
It also addresses the challenges faced by cross principal and cross-
process events protection.
Finally we can say that this type of browser construction exposes
more design changes and challenges but also is more robust.
Impact & Ideas for further work < may be featured on Bad ideas! >
Imagine booting to a browser! We could have machines that would just
have a browser which could provide us all the functionalities of OS &
still be a browser. With lot of the applications on the web mimicking
the apps on our standalone machines we could just have a browser on
our machines which could double up as both!!
Evidence
Gazelle prototype’s performance is evaluated by measuring page load
latencies, memory overhead and responsiveness with other browsers( IE7
& chrome).
Though gazelle doesn’t outperform the other browsers, it certainly
performs on par. But we must remember that this is a prototype and
further research & tweaking could make this a out performer.
Prior Work
Chrome, IE 7 & 8 , OP browser
The Multi-Principal OS Construction of the Gazelle Web Browser
Author(s)
Wang, Helen J., Grier, Chris, Moshchuk, Alexander, King, Samuel T.,
Choudhury, Piali, and Venter, Herman
Date
Proceedings of the 18th USENIX Security Symposium 2009-08
Novel Idea
Transform the browser into a browser kernel which has the exclusive
control to manage the protection & fair sharing of all system
resources. Basically borrow OS concepts to build a robust and feature
rich browser
Main Result(s)
The authors propose a research browser which essentially is an
operating systems of sorts which can manage resources and isolate web
content. They create a prototype that turns the existing browser into
a multi principal OS that is more secure and robust with acceptable
performance.
Gazelle has a robust security model which protects respective
resources into OS enforced protection domains and segregating their
access to resources. The browser kernel runs in a separate protection
domain and interposes between browser principals and the traditional
OS. Their architecture borrows a lot from os model and abstraction
interms of applications (processes) very similar to google chrome, but
gazelle unlike chrome doesn’t consider the registrar controlled domain
name to be the same and also when a site embeds another principal’s
content, these are put in different instances. Essentially, the
browser kernel functions as an operating system to browser principals
and manages the protection and sharing of system resources for them
It also addresses the challenges faced by cross principal and cross-
process events protection.
Finally we can say that this type of browser construction exposes
more design changes and challenges but also is more robust.
Impact & Ideas for further work < may be featured on Bad ideas! >
Imagine booting to a browser! We could have machines that would just
have a browser which could provide us all the functionalities of OS &
still be a browser. With lot of the applications on the web mimicking
the apps on our standalone machines we could just have a browser on
our machines which could double up as both!!
Evidence
Gazelle prototype’s performance is evaluated by measuring page load
latencies, memory overhead and responsiveness with other browsers( IE7
& chrome).
Though gazelle doesn’t outperform the other browsers, it certainly
performs on par. But we must remember that this is a prototype and
further research & tweaking could make this a out performer.
Prior Work
Chrome, IE 7 & 8 , OP browser
yash
Nov 17, 2009, 12:28:16 AM11/17/09
to CSCI2950-u Fall 09 - Brown
Paper Title: The Multi-Principal OS Construction of the Gazelle Web
Browser
Novel Idea: The paper introduces a new model for browsers (Gazelles)-
Browser
such that to make them behave as an OS. The model proposes the browser
to have a kernel which takes care of the website principals- isolating
it from each other and managing the system resources.
Main Result: The paper talks about the drawbacks of the current
browsers and proposes Gazelle as the solution. Gazelle's browser
kernel functions like an OS kernel which considers each web program as
a separate process and manages all system resources among different
processes. Kernel also manages the inter-process/principal
communication.
Impact:
This architecture presents a robust and secured environment for
accessing modern websites which are more like applications rather than
web-pages.
Reproducibility:
Difficult to reproduce from the information in the paper and moreover
no open-source project available. There is an IE-based prototype built
to demonstrate the model and to show that existing browsers can be
turned into multi-principal OS and is backward-compatible.
Xiyang Liu
Nov 16, 2009, 11:50:33 PM11/16/09
to brown-cs...@googlegroups.com
Paper Title
The Multi-Principal OS Construction of the Gazelle Web Browser
Author(s) The Multi-Principal OS Construction of the Gazelle Web Browser
Helen J. Wang, Chris Griery, Alexander Moshchukz, Samuel T. Kingy, Piali Choudhury, Herman Venter
Date
February 2009
Novel Idea
Gazelle is also a multi-process browser like Chrome. It has more concern on security and access control which acts as an operating system for web programs. It adheres to SOP model and uses delegation policy to handle cross-origin events.
Main Result(s)
The authors built a prototype based on IE7 and tested it on the top 20 Alexa-reported popular sites. However there was no clue how it achieves the design goals.
Impact
This is a deeper research on multi-process browser - extending it with OS-like functionalities, such as cross-process interaction, access control and security concern. It is hard to say how the architecture applies to practical because it introduces heavy memory and latency overhead and most of the Internet surfing do not require this fine-grained control.
Evidence
There was no direct evidence showing that the implementation achieves the design goals. The authors evaluated the performance of their prototype but did not demonstrate its functionalities.
Prior Work
The principal model was based on SOP.
Competitive work
Gazelle was compared to Chrome and OP, two other multi-process browsers. Gazelle was aimed to provide exclusive protection for resources thus it had complex cross-process interaction and strict security policy.
Reproducibility
No.
Question
Is the architecture vulnerable to malicious script? For example, a site on the top-level domain can change its document.domain DOM property to any with the same host name which passes the SOP check.
Criticism
Separating web pages/contents to different domains is straightforward. But the implementation may be extremely difficult. DOM specifications and scripting languages can flaw the design which result in great compromise.
On Mon, Nov 16, 2009 at 6:21 PM, Rodrigo <rodrigo...@gmail.com> wrote:
Andrew Ferguson
Nov 17, 2009, 12:10:47 AM11/17/09
to brown-cs...@googlegroups.com
Paper Title
"The Multi-Principal OS Construction of the Gazelle Web Browser"
Authors
"The Multi-Principal OS Construction of the Gazelle Web Browser"
Wang, Helen J., Grier, Chris, Moshchuk, Alexander, King, Samuel T.,
Choudhury, Piali, and Venter, Herman
Date
USENIX Security Symposium 2009
Choudhury, Piali, and Venter, Herman
Date
Novel Idea / Main Results
Like in Chrome, Gazelle uses multiple OS processes to isolate parts of
the web browser. However, Gazelle enforces stricter isolation than
Chrome in a way that provides a cleaner model but breaks backwards
compatibility. All communication between Gazelle processes must go
through the browser kernel, which can control the flow of information.
The paper also proposes a landlord/tenant relationship between cross-
domain parts of a window. The authors discuss how their prototype
implements possibly ambiguous actions such as clicks or keystrokes in
the landlord/tenant model.
Impact
As yet unknown, since this has not been released. Since the Gazelle
model is not 100% backwards-compatible, the Chromium work has had a
greater impact.
Evidence
The authors evaluate Gazelle in a spirit similar to the Chromium work,
by visiting popular websites and looking for visual changes or broken
functionality (1 out of 20 was affected), as well as measuring the
total latency when browsing. Gazelle was slower and more memory
intensive than both IE7 and Chrome, but the authors detail how the
latency costs are driven by the prototyping techniques.
Prior Work
Like with the Chromium paper, the prior work includes the research
browsers OP, Tahoma, and SubOS.
Competitive Work
This work is currently competitive with Chrome/Chromium and will
presumably be competitive with the Firefox response.
Reproducibility
I don't think the Gazelle prototype or source has been released, so
no, not reproducible.
Question
None.
Criticism
On the first page, the authors claim that "a significant portion of
the overhead comes from IE instrumentation" but never over proof of
that claim. In fact, later evidence suggests that the performance
overhead is due to prototyping with unoptimized components. I found
the argument in section 4.2 about whether the script source should be
visible or not confusing -- I couldn't tell if the vulnerabilities
mentioned were due to the failure (like Gazelle) to provide the
protection, or whether the vulnerabilities broke the protection. Even
if the vulnerabilities broke the protection, the argument seemed to
suggest that we should use locks because they can be picked. During
the evaluation, the authors claim that parts of the page-loading
overhead are start-up costs -- the authors should have then visited a
second page in order to prove that the claimed start-up costs were
truly start-up costs.
Ideas for further work
None.
Spiros E.
Nov 16, 2009, 9:52:40 PM11/16/09
to CSCI2950-u Fall 09 - Brown
The paper presents Gazelle, a multi-process browser archicture whose
goals is above all else security. Gazelle takes a similar approach to
isolation as Chrome, though their architecture more faithfully
reflects SOP.
From the first page of the paper: "With our prototype, we successfully
browsed 19 out of the top 20 Alexa-reported popular sites that we
tested. The performance of our prototype is acceptable, and a
significant portion of the overhead comes from IE instrumentation,
which can be eliminated in a production implementation." The former
statement seems to say that the prototype met a criterion for failure
(especially given the paper's concern for compatibility with existing
web sites), while the latter merely casts doubt on 1. whether the
prototype's performance is prohibitive of actual use; or 2. Microsoft
engineers lack the gumption to demonstrate that their products are
usable. Another great quote "This architecture _can_ be
efficient." (Emphasis my own.)
Though this browser architecture has been implemented, the work in
this paper does not strike me as something that should, for the
present, be considered a feasible alterantive to existing browsers.
The claims parrotted throughout the paper is that it _can_ be
efficient, or it _can_ be made reverse-compatible, though little
effort towards these two goals have has been demonstrated.
goals is above all else security. Gazelle takes a similar approach to
isolation as Chrome, though their architecture more faithfully
reflects SOP.
From the first page of the paper: "With our prototype, we successfully
browsed 19 out of the top 20 Alexa-reported popular sites that we
tested. The performance of our prototype is acceptable, and a
significant portion of the overhead comes from IE instrumentation,
which can be eliminated in a production implementation." The former
statement seems to say that the prototype met a criterion for failure
(especially given the paper's concern for compatibility with existing
web sites), while the latter merely casts doubt on 1. whether the
prototype's performance is prohibitive of actual use; or 2. Microsoft
engineers lack the gumption to demonstrate that their products are
usable. Another great quote "This architecture _can_ be
efficient." (Emphasis my own.)
Though this browser architecture has been implemented, the work in
this paper does not strike me as something that should, for the
present, be considered a feasible alterantive to existing browsers.
The claims parrotted throughout the paper is that it _can_ be
efficient, or it _can_ be made reverse-compatible, though little
effort towards these two goals have has been demonstrated.
Rodrigo Fonseca
Nov 17, 2009, 8:33:57 AM11/17/09
to brown-cs...@googlegroups.com
---------- Forwarded message ----------
From: James Tavares <james....@gmail.com>
Date: Mon, Nov 16, 2009 at 10:16 PM
Subject: Re: [csci2950-u] 11/17 Reviews - Gazelle
To: Rodrigo <rodrigo...@gmail.com>
*Gazelle*
Paper Title: The Multi-Principle OS Construction of the Gazelle Web Browser
Author(s): Helen J. Want, Chris Grier, Alexander Moshchuk, Samuel T.
King, Piali Choudhury, Herman Venter
Date: Proceedings of the 18th USENIX Security Symposium. August, 2009.
Novel Idea: First, Gazelle claims to be “the first web browser that
qualifies as a multi-principle OS for web site principals.” Security
is Gazelle’s principle goal; therefore all principle protection logic
is located the Gazelle kernel, and nearly all cross-site references
(such as IFRAMEs, Images, and plugins, to name a few) are isolated in
site-specific processes, strictly adhering to the Single-Origin-Policy
rule. Second, Gazelle achieves this partitioning by dividing the
rendering area into windows: parent pages act as landlords and rent
successively smaller blocks of pixels to children tenants for their
manipulation. Gazelle allows landlords to overwrite their tenant’s
pixels, but prevents landlords from adding transparent layers.
Otherwise, it would be possible for landlords to, for example, overlay
a transparent button over the tenant’s space, breaking an implicit
contract with the user about the target of a user’s click.
Main Result(s): The paper discusses the security concerns and
justifications for going to an all-SOP approach. Further, it describes
the basic architecture of Gazelle, addresses some of the tradeoffs
Gazelle made to retain backwards compatibility with existing websites
(e.g., embedded scripts still run as their hosts) and discusses a
prototype implementation of Gazelle on .NET.
Impact: A browser like this could certainly cause web developers to
think twice about using cross-site scripting & content. This paper
(along with Google’s Chrome) suggests a great deal of research is
still needed in the area of web security, and perhaps points to the
need for a next-generation web architecture which is
application-centric and security-focused by design, as opposed to by
accident.
Evidence: The authors point to the large number of vulnerabilities
found in IE7 and Firefox 2 as justification for isolating web
principles, as well as make a number of the same arguments made in the
Chrome paper (such as increased fault tolerance). In their evaluation
of their prototype, the authors look at memory consumption and load
time for five (5) different scenarios across Gazelle, IE7 and Chrome.
Much the overhead is explained as poor prototype implementation. In
evaluating the impact of their increased security measures, the
authors looked at compatibility across the top 100 websites, as judged
solely by any visual differences in rendering.
Prior/Competitive Work: The authors compare their work primarily to
IE8 and Google Chrome, each of which use multiple processes to some
degree. Chrome is closest to Gazelle in its
One-Process-Per-Site-Instance mode, but differs from Gazelle in that
it does not provide isolation for embedded objects. The authors argue
that Chrome and IE8 seek to gain failure containment and performance
gains out of multiple processes, which is opposite Gazelle’s goal of
attaining additional security.
Reproducibility: As far as I know, Gazelle is not available outside of
Microsoft. One could certainly create a web browser with the same
architecture and security constraints, but even if you did, there’s
really nothing worthwhile in their results to reproduce. I get the
feeling that authored a prototype and performed an evaluation only
because they felt obligated too.
Question: None
Criticism:
1.) It seems to me that they took the isolation and protection
mechanisms of Google’s Chrome and went overboard with them. It
ridiculous to me that it could take 25 or more heavy-weight processes
communicating via IPC to render just one web page! Unless you want to
distribute rendering across a cluster, this is just overkill.
2.) The paper was abusively long for the author’s contributions. The
authors spent pages describing Gazelle, yet the second paragraph of
section 4.1 tells you pretty much all you need to know in a few short
sentences.
3.) The sites chosen for Table 4 are weak: blank page, google.com, and
google.com/ads – are there any simpler web sites in the world? Perhaps
the authors should have expanded the effort to the top 100 pages to
get more aggregate statistics.
4.) In section 3.2, the authors decide against a more fine-grained
security model than <protocol, domain, port> because they claim that
web programmers wouldn’t want to maintain code bases for multiple
browsers. First, I think a simple wrapper library which chooses the
most specific security context available would very easily solve that
problem. Second, the irony here from a Microsoft paper is incredible:
IE’s bugs and lack of standardization over the years have essentially
demanded that programmers develop custom CSSs and JavaScript to
properly support those browsers.
Future Work: None.
From: James Tavares <james....@gmail.com>
Date: Mon, Nov 16, 2009 at 10:16 PM
Subject: Re: [csci2950-u] 11/17 Reviews - Gazelle
To: Rodrigo <rodrigo...@gmail.com>
*Gazelle*
Paper Title: The Multi-Principle OS Construction of the Gazelle Web Browser
Author(s): Helen J. Want, Chris Grier, Alexander Moshchuk, Samuel T.
King, Piali Choudhury, Herman Venter
Date: Proceedings of the 18th USENIX Security Symposium. August, 2009.
Novel Idea: First, Gazelle claims to be “the first web browser that
qualifies as a multi-principle OS for web site principals.” Security
is Gazelle’s principle goal; therefore all principle protection logic
is located the Gazelle kernel, and nearly all cross-site references
(such as IFRAMEs, Images, and plugins, to name a few) are isolated in
site-specific processes, strictly adhering to the Single-Origin-Policy
rule. Second, Gazelle achieves this partitioning by dividing the
rendering area into windows: parent pages act as landlords and rent
successively smaller blocks of pixels to children tenants for their
manipulation. Gazelle allows landlords to overwrite their tenant’s
pixels, but prevents landlords from adding transparent layers.
Otherwise, it would be possible for landlords to, for example, overlay
a transparent button over the tenant’s space, breaking an implicit
contract with the user about the target of a user’s click.
Main Result(s): The paper discusses the security concerns and
justifications for going to an all-SOP approach. Further, it describes
the basic architecture of Gazelle, addresses some of the tradeoffs
Gazelle made to retain backwards compatibility with existing websites
(e.g., embedded scripts still run as their hosts) and discusses a
prototype implementation of Gazelle on .NET.
Impact: A browser like this could certainly cause web developers to
think twice about using cross-site scripting & content. This paper
(along with Google’s Chrome) suggests a great deal of research is
still needed in the area of web security, and perhaps points to the
need for a next-generation web architecture which is
application-centric and security-focused by design, as opposed to by
accident.
Evidence: The authors point to the large number of vulnerabilities
found in IE7 and Firefox 2 as justification for isolating web
principles, as well as make a number of the same arguments made in the
Chrome paper (such as increased fault tolerance). In their evaluation
of their prototype, the authors look at memory consumption and load
time for five (5) different scenarios across Gazelle, IE7 and Chrome.
Much the overhead is explained as poor prototype implementation. In
evaluating the impact of their increased security measures, the
authors looked at compatibility across the top 100 websites, as judged
solely by any visual differences in rendering.
Prior/Competitive Work: The authors compare their work primarily to
IE8 and Google Chrome, each of which use multiple processes to some
degree. Chrome is closest to Gazelle in its
One-Process-Per-Site-Instance mode, but differs from Gazelle in that
it does not provide isolation for embedded objects. The authors argue
that Chrome and IE8 seek to gain failure containment and performance
gains out of multiple processes, which is opposite Gazelle’s goal of
attaining additional security.
Reproducibility: As far as I know, Gazelle is not available outside of
Microsoft. One could certainly create a web browser with the same
architecture and security constraints, but even if you did, there’s
really nothing worthwhile in their results to reproduce. I get the
feeling that authored a prototype and performed an evaluation only
because they felt obligated too.
Question: None
Criticism:
1.) It seems to me that they took the isolation and protection
mechanisms of Google’s Chrome and went overboard with them. It
ridiculous to me that it could take 25 or more heavy-weight processes
communicating via IPC to render just one web page! Unless you want to
distribute rendering across a cluster, this is just overkill.
2.) The paper was abusively long for the author’s contributions. The
authors spent pages describing Gazelle, yet the second paragraph of
section 4.1 tells you pretty much all you need to know in a few short
sentences.
3.) The sites chosen for Table 4 are weak: blank page, google.com, and
google.com/ads – are there any simpler web sites in the world? Perhaps
the authors should have expanded the effort to the top 100 pages to
get more aggregate statistics.
4.) In section 3.2, the authors decide against a more fine-grained
security model than <protocol, domain, port> because they claim that
web programmers wouldn’t want to maintain code bases for multiple
browsers. First, I think a simple wrapper library which chooses the
most specific security context available would very easily solve that
problem. Second, the irony here from a Microsoft paper is incredible:
IE’s bugs and lack of standardization over the years have essentially
demanded that programmers develop custom CSSs and JavaScript to
properly support those browsers.
Future Work: None.
Reply all
Reply to author
Forward
0 new messages