Hi,
On Thu, Aug 04, 2016 at 02:25:26PM +0100, James Graham wrote:
> On 04/08/16 12:24, Olaf Buddenhagen wrote:
> > On Wed, Aug 03, 2016 at 06:22:51PM +0200, Till Schneidereit wrote:
> > > I'm not concerned about code complexity, but about memory usage. Memory
> > > usage in many-tab scenarios is
On 04/08/16 12:24, Olaf Buddenhagen wrote:
Hi,
On Wed, Aug 03, 2016 at 06:22:51PM +0200, Till Schneidereit wrote:
I'm not concerned about code complexity, but about memory usage. Memory
usage in many-tab scenarios is one of the measures where Firefox is still
vastly superior to the competition
On Wed, Aug 3, 2016 at 9:22 AM, Till Schneidereit wrote:
> On Wed, Aug 3, 2016 at 5:35 PM, Jack Moffitt wrote:
>
>> I asked ekr how much this mattered, and he thought it was important. I
>> don't think anyone has pointed me to a documented attack, but it
>> definitely seems like the kind of thin
Hi,
On Wed, Aug 03, 2016 at 06:22:51PM +0200, Till Schneidereit wrote:
> I'm not concerned about code complexity, but about memory usage. Memory
> usage in many-tab scenarios is one of the measures where Firefox is still
> vastly superior to the competition, and I think we should aim for roughly
Hi,
On Wed, Aug 03, 2016 at 10:53:39AM +0200, Till Schneidereit wrote:
> I wonder to which extent this matters. I'm not aware of any real-world
> instances of the mythical cross-tab information harvesting attack. Sure, in
> theory the malvertising ad from one tab would be able to read information
On Wed, Aug 3, 2016 at 2:37 PM, Robert O'Callahan
wrote:
> On Wed, Aug 3, 2016 at 4:10 PM, Michael Howell >
> wrote:
>
> > I can think of one advantage right now: by having script and layout in
> > separate processes, a compromised script thread doesn't automatically
> give
> > an attacker the a
On Thu, Aug 4, 2016 at 4:47 AM, Andrew McCreight
wrote:
> If you do want to think about it, I'd first read over the work that Chrome
> people have already put into thinking about this issue:
> http://www.chromium.org/developers/design-documents/site-isolation
>
> I'm not sure how much they have a
On Wed, Aug 3, 2016 at 12:38 PM, David Bruant wrote:
> Le 03/08/2016 à 18:47, Andrew McCreight a écrit :
>
> In a world where a sophisticated attacker can get root privileges, I
>> wouldn't spend too much time worrying about intraprocess attacks.
>
> If (safe) Rust holds its promises of preventin
On Wed, Aug 3, 2016 at 4:10 PM, Michael Howell
wrote:
> I can think of one advantage right now: by having script and layout in
> separate processes, a compromised script thread doesn't automatically give
> an attacker the ability to produce malformed display lists that draw
> outside the tab boun
Le 03/08/2016 à 21:38, David Bruant a écrit :
My undertanding of pwalton's email is that the parts written in unsafe
rust binding to complex C++ libraries should be bundled together in
their own process(es).
Were the JS and layout engines written in safe Rust, I don't think
process-as-a-sandoxi
Le 03/08/2016 à 18:47, Andrew McCreight a écrit :
On Wed, Aug 3, 2016 at 8:35 AM, Jack Moffitt wrote:
I asked ekr how much this mattered, and he thought it was important. I
don't think anyone has pointed me to a documented attack, but it
definitely seems like the kind of thing that could be do
On Wed, Aug 3, 2016 at 8:35 AM, Jack Moffitt wrote:
> I asked ekr how much this mattered, and he thought it was important. I
> don't think anyone has pointed me to a documented attack, but it
> definitely seems like the kind of thing that could be done somehow.
>
It seems like it will be importa
There will always be some single points of failure, e.g. the bhtml browsing
context, or the gfx context. The constellation is doing double duty, acting
as both the centralized message router, and the manager of browsing
contexts (e.g. navigation). We could try to separate out these two roles,
and h
On Wed, Aug 3, 2016 at 5:35 PM, Jack Moffitt wrote:
> I asked ekr how much this mattered, and he thought it was important. I
> don't think anyone has pointed me to a documented attack, but it
> definitely seems like the kind of thing that could be done somehow.
>
I guess I left out an important
I asked ekr how much this mattered, and he thought it was important. I
don't think anyone has pointed me to a documented attack, but it
definitely seems like the kind of thing that could be done somehow.
How we allocate domains to content processes is an open question. It's
not clear whether we wa
I wonder to which extent this matters. I'm not aware of any real-world
instances of the mythical cross-tab information harvesting attack. Sure, in
theory the malvertising ad from one tab would be able to read information
from your online banking session. In practice, it seems like attacks that
gain
I can think of one advantage right now: by having script and layout in
separate processes, a compromised script thread doesn't automatically give
an attacker the ability to produce malformed display lists that draw
outside the tab boundary.
On Tue, Aug 2, 2016, 20:43 Jack Moffitt wrote:
> Each p
Each process is a sandboxing boundary. Without security as a concern
you would just have a single process. A huge next step is to have a
second process that all script/layout threads go into. This however
still leaves a bit of attack surface for one script task to attack
another. How many processes
It's not a stupid question :) I actually think we should gather all script
and layout threads together into one process. Maybe two, one for
high-security sites and one for all other sites.
Patrick
On Aug 2, 2016 6:47 PM, "Paul Rouget" wrote:
> On Tue, Aug 2, 2016 at 6:47 PM, Jack Moffitt wrote
On Tue, Aug 2, 2016 at 6:47 PM, Jack Moffitt wrote:
>> First, is multiprocess and sandboxing actively supported?
>
> I tested this right before the nightly release, and it was working
> fine and didn't seem to have bad performance. Note that you can run -M
> or -M and -S, but not -S by itself (whi
We're currently testing -M but not -M -S, e.g. see:
https://github.com/servo/saltfs/blob/master/buildbot/master/files/config/steps.yml#L46
I don't think there's any great reason for not testing sandboxing as well
as multiprocess. We're testing multiprocess for Mac and Linux, not Windows
as multip
> First, is multiprocess and sandboxing actively supported?
I tested this right before the nightly release, and it was working
fine and didn't seem to have bad performance. Note that you can run -M
or -M and -S, but not -S by itself (which doesn't make sense). Also
note that -M and -S probably don
The constellation is the process manager; as far as Servo is concerned,
there is only one constellation in the entire universe.
What we have is one-process-per-Origin, since iframes within the same
Origin are able to share JavaScript objects directly.
On Tue, Aug 2, 2016 at 12:46 AM Paul Rouget
I'd like to have a better understanding of how sandboxing and multiprocess work.
First, is multiprocess and sandboxing actively supported?
Is Servo tested with the "-M -S" options?
What's the status of the sandbox?
Is there any reasons for these options to not be turned on by default?
Do we want t
24 matches
Mail list logo
