Re: Intent to ship: CSP directive worker-src

[Christoph Kerschbaumer]

> On Oct 18, 2017, at 3:30 PM, Mike West  wrote:
> 
> We do have `worker-src` tests, FWIW: 
> https://github.com/w3c/web-platform-tests/tree/master/content-security-policy/worker-src/
>  
> .
>  We'll likely need to adjust things based on the fallback mechanism y'all are 
> running with (and Chrome will need to drop the weird contortions we 
> implemented for back-compat), but I'd hope you would be able to use those 
> rather than writing mochitests.

Quick update on worker-src:
- We are going to ship worker-src with the fallback to child-src, script-src, 
default-src within Firefox 58.
- There are some web-platform-tests, as pointed out by Mike, which we are going 
to extend within [1] to account for the fallback.

Thanks,
  Christoph

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1409706

> 
> -mike
> 
> On Wed, Oct 18, 2017 at 11:51 AM, Christoph Kerschbaumer  > wrote:
> 
> > On Oct 18, 2017, at 11:41 AM, James Graham  > > wrote:
> >
> > On 18/10/17 10:35, Christoph Kerschbaumer wrote:
> >>> On Oct 18, 2017, at 11:25 AM, James Graham  >>> > wrote:
> >>>
> >>> On 22/09/17 15:18, Christoph Kerschbaumer wrote:
>  Hey Everyone,
>  within CSP2 workers used to be governed by the child-src directive [0]. 
>  CSP3 introduces the worker-src directive [1] wich governs Workers, 
>  SharedWorkers as well as ServiceWorkers. Please note that the child-src 
>  directive has been deprecated within CSP3 in favor of worker-src as well 
>  as frame-src.
>  For backwards compatibility child-src will still be enforced for:
>    * workers (if worker-src is not explicitly specified)
>    * frames  (if frame-src is not explicitly specified)
>  We plan to ship the CSP directive worker-src within Firefox 58.
> >>>
> >>> Do we have cross-browser (i.e. web-platform) tests for this feature?
> >> Not yet. We just agreed with Chrome on the same fallback mechanism, see 
> >> [1].
> >> We are about to add mochitests for all the different fallback mechanisms 
> >> though.
> >
> > What's the reason for writing mochitests? It seems like this is something 
> > where we benefit from shared tests.
> 
> Reason is simple, I have already written the mochitests for it. But I agree, 
> we should have web-platform tests for it.
> 
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org 
> https://lists.mozilla.org/listinfo/dev-platform 
> 
> 

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visual Studio 2017 coming soon

[smaug]

And let's be careful with the new C++ features, pretty please.
We managed to not be careful when we started to use auto, or ranged-for or 
lambdas.
I'd prefer to not fix more security critical bugs or memory leaks just because 
of fancy hip and cool
language features ;)


-Olli



On 10/30/2017 05:27 AM, Jim Blandy wrote:

How will this affect the matrix of specific C++ features we can use?
https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code

(At the moment I'm dying for generic lambdas, which are C++14. I'd been
using std::function as a workaround, but I also need control over the
allocation policy, which std::function no longer offers.)


On Wed, Oct 25, 2017 at 2:48 PM, David Major  wrote:


I'm planning to move production Windows builds to VS2017 (15.4.1) in bug
1408789.

VS2017 has optimizer improvements that produce faster code. I've seen 3-6%
improvement on Speedometer. There is also increased support for C++14 and
C++17 language features:
https://docs.microsoft.com/en-us/cpp/visual-cpp-language-conformance

These days we tend not to support older VS for too long, so after some
transition period you can probably expect that VS2017 will be required to
build locally, ifdefs can be removed, etc. VS2017 Community Edition is a
free download and it can coexist with previous compilers. Installation
instructions are at:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_
guide/Build_Instructions/Windows_Prerequisites#Visual_Studio_2017

If you have concerns, please talk to me or visit the bug. Thanks!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visual Studio 2017 coming soon

[Simon Sapin]

On 30/10/17 15:05, smaug wrote:

And let's be careful with the new C++ features, pretty please. We
managed to not be careful when we started to use auto, or ranged-for
or lambdas. I'd prefer to not fix more security critical bugs or
memory leaks just because of fancy hip and cool language features ;)


Careful how? How do new language features lead to security bugs? Is new 
compiler code not as well tested and could have miscompiles? Are 
specific features easy to misuse?


--
Simon Sapin
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visual Studio 2017 coming soon

[Alex Gaynor]

I don't know about C++14 specifically, but a good example is C++17's
std::string_view, which allows an implicit cast from std::string&& and can
very easily lead to UAF:
https://github.com/isocpp/CppCoreGuidelines/issues/1038

Alex

On Mon, Oct 30, 2017 at 10:52 AM, Simon Sapin  wrote:

> On 30/10/17 15:05, smaug wrote:
>
>> And let's be careful with the new C++ features, pretty please. We
>> managed to not be careful when we started to use auto, or ranged-for
>> or lambdas. I'd prefer to not fix more security critical bugs or
>> memory leaks just because of fancy hip and cool language features ;)
>>
>
> Careful how? How do new language features lead to security bugs? Is new
> compiler code not as well tested and could have miscompiles? Are specific
> features easy to misuse?
>
> --
> Simon Sapin
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visual Studio 2017 coming soon

[Boris Zbarsky]

On 10/30/17 10:52 AM, Simon Sapin wrote:

How do new language features lead to security bugs?


By making unsafe behaviors easier or more tempting.

For example:

 [&]() { /* stuff */ }

is a huge footgun in a language without a borrow checker.  You _could_ 
still do something like that before lambdas by creating a functor 
object, but you had to explicitly give it reference-typed members for 
the things you wanted to use, which might at least make you stop and 
think about whether those references were referencing things that lived 
long enouhg.  With [&] you capture everything by reference by default, 
which is great if the lambda's usage has stack lifetime and horrible 
otherwise...



Are specific features easy to misuse?


This, imo.

-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visual Studio 2017 coming soon

[smaug]

On 10/30/2017 04:52 PM, Simon Sapin wrote:

On 30/10/17 15:05, smaug wrote:

And let's be careful with the new C++ features, pretty please. We
managed to not be careful when we started to use auto, or ranged-for
or lambdas. I'd prefer to not fix more security critical bugs or
memory leaks just because of fancy hip and cool language features ;)


Careful how? How do new language features lead to security bugs? Is new 
compiler code not as well tested and could have miscompiles? Are specific
features easy to misuse?




With auto we've managed to hide the ownership of some objects from 
reader/reviewer (and I guess also from the patch author),
and this has lead to both to security issues and memory leaks.

Ranged-for lead to security critical crashes when we converted some old style
for (i = 0; i < array.Length(); ++i) to use it, since ranged-for doesn't play 
well when the array changes underneath you.
These days we crash safely there.

With lambdas understanding who owns what becomes harder, and before some 
checks, we had (I think rather short while) issues when
there was a raw pointer to a refcounted object captured in a lambda and the 
lambda was then dispatched to the event loop.
Nothing guaranteed the captured object to stay alive.

Basically, some "new" features have hidden important aspects of the lifetime 
management of objects, and by
doing that, made it easier to write broken code and harder by the reviewers to 
catch the mistakes.



-Olli
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visual Studio 2017 coming soon

[Jim Blandy]

Okay, this is half the argument. The second half would be:

- Does auto cause such mistakes more often than it prevents them? The
benefit claimed for auto is that it usually makes code more legible.
Hopefully that prevents mistakes, on the balance.

- Is ranged-for more prone to iterator invalidation errors than the older
form? I believe I've seen .Length() calls hoisted out of old-form loop
conditions pretty frequently. The advantage of ranged-for is claimed to be
that it depends on the operand's iteration API, instead of requiring the
programmer to invent an iteration technique each time they write a loop.

- Are closures more prone to ownership mistakes than the pre-closure
technique? How does this compare with their benefits to legibility?

When evaluating the impact of new features, we should not let the
familiarity of the mistakes we've been making in C++98 for twenty years
cause us to focus only on the risks from change. That misjudgment would
hurt the quality of the code.



On Mon, Oct 30, 2017 at 8:03 AM, smaug  wrote:

> On 10/30/2017 04:52 PM, Simon Sapin wrote:
>
>> On 30/10/17 15:05, smaug wrote:
>>
>>> And let's be careful with the new C++ features, pretty please. We
>>> managed to not be careful when we started to use auto, or ranged-for
>>> or lambdas. I'd prefer to not fix more security critical bugs or
>>> memory leaks just because of fancy hip and cool language features ;)
>>>
>>
>> Careful how? How do new language features lead to security bugs? Is new
>> compiler code not as well tested and could have miscompiles? Are specific
>> features easy to misuse?
>>
>>
>
> With auto we've managed to hide the ownership of some objects from
> reader/reviewer (and I guess also from the patch author),
> and this has lead to both to security issues and memory leaks.
>
> Ranged-for lead to security critical crashes when we converted some old
> style
> for (i = 0; i < array.Length(); ++i) to use it, since ranged-for doesn't
> play well when the array changes underneath you.
> These days we crash safely there.
>
> With lambdas understanding who owns what becomes harder, and before some
> checks, we had (I think rather short while) issues when
> there was a raw pointer to a refcounted object captured in a lambda and
> the lambda was then dispatched to the event loop.
> Nothing guaranteed the captured object to stay alive.
>
> Basically, some "new" features have hidden important aspects of the
> lifetime management of objects, and by
> doing that, made it easier to write broken code and harder by the
> reviewers to catch the mistakes.
>
>
>
> -Olli
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Default Rust optimization level decreased from 2 to 1

[Markus Stange]

On 2017-10-25 1:34 PM, Gregory Szorc wrote:

Adding --enable-release to your mozconfig (the configuration for builds we
ship to users) enables -Copt-level=2. (i.e. we didn't change optimization
settings for builds we ship to users.)


I've added a note about this to our benchmarking instructions at 
https://developer.mozilla.org/en-US/docs/Mozilla/Benchmarking#Rust_optimization_level 
.


-Markus
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visual Studio 2017 coming soon

[Kris Maglione]

On Mon, Oct 30, 2017 at 11:04:10AM -0400, Boris Zbarsky wrote:

On 10/30/17 10:52 AM, Simon Sapin wrote:

How do new language features lead to security bugs?


By making unsafe behaviors easier or more tempting.

For example:

[&]() { /* stuff */ }

is a huge footgun in a language without a borrow checker.  You _could_ 
still do something like that before lambdas by creating a functor 
object, but you had to explicitly give it reference-typed members for 
the things you wanted to use, which might at least make you stop and 
think about whether those references were referencing things that 
lived long enouhg.  With [&] you capture everything by reference by 
default, which is great if the lambda's usage has stack lifetime and 
horrible otherwise...


Our static analysis tools are pretty good at catching a lot of 
lambda capture bugs at this point, though. I'd be much less 
comfortable using them if they weren't.


It's probably worth considering whether we need to write static 
analysis tools for a new feature before we turn it on, though...

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How can I get SOCKS settings params of Firefox?

[nmago]

понедельник, 23 октября 2017 г., 11:52:19 UTC+3 пользователь Karl Tomlinson 
написал:
> I don't know how well GConf is supported by more recent GNOME
> versions.  I assume GSettings support was added to
> nsUnixSystemProxySettings because GConf was to be no longer
> supported, but the crash reporter uses separate code.
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1388897
> 
> http://searchfox.org/mozilla-central/rev/8a6a6bef7c54425970aa4fb039cc6463a19c0b7f/toolkit/system/unixproxy/nsUnixSystemProxySettings.cpp#445
> 
> A potentially better solution is proposed in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1333125

Thank you, Karl!
It seems like solution that you proposed gets proxy from OS settings (or I'm 
wrong), but I would like proxy params from Firefox native settings (Preferences 
=> Advanced => Network => Connection settings => Manual proxy configuration).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visual Studio 2017 coming soon

[Kris Maglione]

On Mon, Oct 30, 2017 at 08:28:39AM -0700, Jim Blandy wrote:

Okay, this is half the argument. The second half would be:

- Does auto cause such mistakes more often than it prevents them? The
benefit claimed for auto is that it usually makes code more legible.
Hopefully that prevents mistakes, on the balance.


My feeling is that these features generally prevent more errors 
than they cause.


The case for `auto` probably isn't as strong as the cases for 
other features, but I don't think the case against it is as 
strong either. And there are places where, without `auto`, the 
extra qualified type noise spreads a simple assignment across 
multiple, dense lines, and makes the code much more difficult to
follow. And makes refactoring the specific types of (e.g.,) 
smart pointer arrays more complicated, and somewhat more dangerous.


Also, I'm quite looking forward to the time when I can write:

 GetString(char*, nsContentUtils::PropertiesFile aBundle = 
auto::eBRAND_PROPERTIES)

rather than:

 GetString(char*, nsContentUtils::PropertiesFile aBundle = 
nsContentUtils::PropertiesFile::eBRAND_PROPERTIES)


- Is ranged-for more prone to iterator invalidation errors than the older
form? I believe I've seen .Length() calls hoisted out of old-form loop
conditions pretty frequently. The advantage of ranged-for is claimed to be
that it depends on the operand's iteration API, instead of requiring the
programmer to invent an iteration technique each time they write a loop.


Again, my feeling here is that the opposite is true. If we have a single, de 
facto way of writing for loops, it makes it much easier to make sure we have 
the correct behavior everywhere. The alternative is separate, ad-hoc 
implementations everywhere we iterate over a collection, many of which will 
make their own sets of mistakes.



- Are closures more prone to ownership mistakes than the pre-closure
technique? How does this compare with their benefits to legibility?


I think this is the clearest case where the benefits far outweigh the risks. 
There are definitely easy-to-overlook lambda capture footguns, but our static 
analysis tools are good at preventing those. But there are also huge benefits.


The ScopeExit class is the best example I can think of. Before we had that 
helper, in the best cases, we wound up writing tons of special-purpose RAII 
helpers that were hard to think about and maintain. In the worst cases, we 
wound up with tons of code that either did not handle early return correctly 
at all, or added fragile, duplicated cleanup code in every failure check `if`. 
ScopeExit makes our code much safer and more maintainable.


And in the more general case, our pre-lambda code tends to wind up with logic 
and data ownership spread across multiple methods and special-purpose classes 
(e.g., Runnables), that often get separated in the source, and become 
difficult to follow and reason about. Post-lambda, we have abstractions like 
MozPromise that make async code much easier to follow, and the data it owns 
much more obvious.


For example, this code that I wrote fairly recently:

   RefPtr self(this);
   RunOnMainThread(FUNC, [=] {
 self->mChannel->Resume();

 RunOnActorThread(FUNC, [=] {
   if (self->IPCActive()) {
 self->CheckResult(self->SendResumed());
   }
 });
   });

Pre-lambda, in the best case would have expanded to something like:

IPCResult
StreamFilterParent::RecvResume()
{
 RunOnMainThread(
   NewRunnableMethod("StreamFilterParent::Resume1",
 this,
 StreamFilterParent::Resume1));
 return IPC_OK();
}

void
StreamFilterParent::Resume1()
{
 mChannel->Resume();
 RunOnActorThread(
   NewRunnableMethod("StreamFilterParent::Resume2",
 this,
 StreamFilterParent::Resume2));
}

void
StreamFilterParent::Resume2()
{
 if (IPCActive()) {
   CheckResult(SendResumed());
 }
}

Which is much more difficult to follow (which function runs on which thread? 
what data is kept alive across the entire event chain? where do we check for 
errors?) and maintain (what happens when I want to add a new event in the 
middle of the chain? do I renumber everything and add a new method declaration 
to the header?). And that's for a fairly simple case where the only object 
held alive is `this`.



When evaluating the impact of new features, we should not let the
familiarity of the mistakes we've been making in C++98 for twenty years
cause us to focus only on the risks from change. That misjudgment would
hurt the quality of the code.


+1


On Mon, Oct 30, 2017 at 8:03 AM, smaug  wrote:


On 10/30/2017 04:52 PM, Simon Sapin wrote:


On 30/10/17 15:05, smaug wrote:


And let's be careful with the new C++ features, pretty please. We
managed to not be careful when we started to use auto, or ranged-for
or lambdas. I'd prefer to not fix more security critical bugs or
memory leaks just because of fancy hip and cool language features ;)



Careful how? H

PSA: Retiring Bugzilla Socorro Lens

[Anthony Hughes]

This is a heads up that I am shutting down further development of my
Bugzilla Socorro Lens add-on. If you're currently using the add-on I
recommend that you uninstall it and please file issues at
https://github.com/ashughes1/bmo-bsl.

Over the past few weeks I've been working to integrate the functionality it
provides natively with bugzilla.mozilla.org. These changes should be live
as of Tuesday, October 31, 2017. You can read more about this at
https://ashughes.com/?p=453.

Thank you

-- 
Anthony Hughes
Senior Quality Engineer
Mozilla Corporation
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Visual Studio 2017 coming soon

[smaug]

On 10/30/2017 10:03 PM, Kris Maglione wrote:

On Mon, Oct 30, 2017 at 08:28:39AM -0700, Jim Blandy wrote:

Okay, this is half the argument. The second half would be:

- Does auto cause such mistakes more often than it prevents them? The
benefit claimed for auto is that it usually makes code more legible.
Hopefully that prevents mistakes, on the balance.


My feeling is that these features generally prevent more errors than they cause.


My gut feeling while having my reviewer's hat on, is that I haven't really seen 
them preventing issues, but they have definitely caused issues.



The case for `auto` probably isn't as strong as the cases for other features, 
but I don't think the case against it is as strong either. And there are
places where, without `auto`, the extra qualified type noise spreads a simple 
assignment across multiple, dense lines, and makes the code much more
difficult to
follow. And makes refactoring the specific types of (e.g.,) smart pointer 
arrays more complicated, and somewhat more dangerous.

Also, I'm quite looking forward to the time when I can write:

 GetString(char*, nsContentUtils::PropertiesFile aBundle = 
auto::eBRAND_PROPERTIES)

rather than:

 GetString(char*, nsContentUtils::PropertiesFile aBundle = 
nsContentUtils::PropertiesFile::eBRAND_PROPERTIES)


- Is ranged-for more prone to iterator invalidation errors than the older
form? I believe I've seen .Length() calls hoisted out of old-form loop
conditions pretty frequently. The advantage of ranged-for is claimed to be
that it depends on the operand's iteration API, instead of requiring the
programmer to invent an iteration technique each time they write a loop.


Again, my feeling here is that the opposite is true. If we have a single, de 
facto way of writing for loops, it makes it much easier to make sure we
have the correct behavior everywhere. The alternative is separate, ad-hoc 
implementations everywhere we iterate over a collection, many of which will
make their own sets of mistakes.


- Are closures more prone to ownership mistakes than the pre-closure
technique? How does this compare with their benefits to legibility?


I think this is the clearest case where the benefits far outweigh the risks. 
There are definitely easy-to-overlook lambda capture footguns, but our
static analysis tools are good at preventing those. But there are also huge 
benefits.

The ScopeExit class is the best example I can think of. Before we had that 
helper, in the best cases, we wound up writing tons of special-purpose RAII
helpers that were hard to think about and maintain. In the worst cases, we 
wound up with tons of code that either did not handle early return
correctly at all, or added fragile, duplicated cleanup code in every failure 
check `if`. ScopeExit makes our code much safer and more maintainable.

And in the more general case, our pre-lambda code tends to wind up with logic 
and data ownership spread across multiple methods and special-purpose
classes (e.g., Runnables), that often get separated in the source, and become 
difficult to follow and reason about. Post-lambda, we have abstractions
like MozPromise that make async code much easier to follow, and the data it 
owns much more obvious.

For example, this code that I wrote fairly recently:

   RefPtr self(this);
   RunOnMainThread(FUNC, [=] {
 self->mChannel->Resume();

 RunOnActorThread(FUNC, [=] {
   if (self->IPCActive()) {
 self->CheckResult(self->SendResumed());
   }
 });
   });

Pre-lambda, in the best case would have expanded to something like:

IPCResult
StreamFilterParent::RecvResume()
{
 RunOnMainThread(
   NewRunnableMethod("StreamFilterParent::Resume1",
 this,
 StreamFilterParent::Resume1));
 return IPC_OK();
}

void
StreamFilterParent::Resume1()
{
 mChannel->Resume();
 RunOnActorThread(
   NewRunnableMethod("StreamFilterParent::Resume2",
 this,
 StreamFilterParent::Resume2));
}

void
StreamFilterParent::Resume2()
{
 if (IPCActive()) {
   CheckResult(SendResumed());
 }
}

Which is much more difficult to follow (which function runs on which thread? 
what data is kept alive across the entire event chain? where do we check
for errors?) and maintain (what happens when I want to add a new event in the 
middle of the chain? do I renumber everything and add a new method
declaration to the header?). And that's for a fairly simple case where the only 
object held alive is `this`.


When evaluating the impact of new features, we should not let the
familiarity of the mistakes we've been making in C++98 for twenty years
cause us to focus only on the risks from change. That misjudgment would
hurt the quality of the code.


+1


On Mon, Oct 30, 2017 at 8:03 AM, smaug  wrote:


On 10/30/2017 04:52 PM, Simon Sapin wrote:


On 30/10/17 15:05, smaug wrote:


And let's be careful with the new C++ features, pretty please. We
managed to not be careful when we started t

nsAutoConfig

[Nicholas Nethercote]

Hi,

I was just looking at the extensions/pref/autoconfig/ directory and trying
to understand what it does.

As far as I can tell, the code is there to allow custom deployments with
particular prefs set, as described at
https://developer.mozilla.org/en-US/Firefox/Enterprise_deployment#Configuration

It's initialized by modules/libpref/Preferences.cpp if a
"general.config.filename" pref is found:
http://searchfox.org/mozilla-central/rev/1ebd2eff44617df3b82eea7d2f3ca1b60cc591a0/modules/libpref/Preferences.cpp#3907-3920

There is also some MozHarness code relating to it here:
http://searchfox.org/mozilla-central/source/testing/mozharness/mozharness/mozilla/firefox/autoconfig.py

Just to check: is this still supported functionality?

Thanks.

Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Security Principles for coding secure IPC

[Paul Theriault]

With tighter sandbox restrictions hitting release in 57, I thought it might
be a good time to provide some tips on writing IPC in a safe way. Our
sandbox is less effective if we punch holes in it through due to IPC bugs
or overly permissive APIs. This document highlights some of the common
issues we have come across during our work to audit Firefox IPC mechanisms
for sandboxing escapes. These type of bugs aren't very common, but the
anti-patterns that lead to these type of bugs fall into a few categories,
and hopefully this document will help you avoid them.

https://wiki.mozilla.org/Security/Sandbox/IPCguide

NB: these are general guidelines - often its Not That Simple (tm). Help is
at hand - either my team, or the Content Isolation team (Jim Mathies) are
always interested to talk sandboxing.

Big thank you to Julian Hector for writing this, and to the Content
Isolation team and others for their input and review.

Feedback, corrections, suggestions all welcome.

Regards,

Paul Theriault
Firefox Security Assurance
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform