Re: Memory management in C programs

[Frederik Braun]

On 29.01.2015 21:32, ISHIKAWA, Chiaki wrote:
> On 2015/01/12 22:46, Philip Chee wrote:
>> ""
>> One large difference between C and most other programming languages is
>> that in C, you have to handle memory yourself rather than having a
>> garbage collector do it for you. Ensuring that memory is allocated at
>> the correct moment is not very difficult (and something that needs to be
>> done manually in pretty much every language); the hard part is to ensure
>> that enough memory is allocated, and to ensure that the memory is
>> deallocated when it is no longer in use.
>>
>> There are several techniques available for memory management in C. Many
>> of them are used in NetHack 3.4.3; and even more are used somewhere in
>> NetHack 4. In this blog post, I'd like to look at them and discuss their
>> advantages and disadvantages. I'm mostly concerned about correctness,
>> rather than efficiency, here; that means that unless the performance
>> difference is very large, I care more about clean code than I do about
>> fast code.
>> ""
>>
>> 
>>
>> Phil
>>
> 
> Nethack? That nethack?
> I looked at the web page.
> Yes, *that* nethack.
> 
> Do people still play it? It seems so
> and on a UTF-8 capable terminal (?)
> We have come a long way from vt100.

FWIW, Nethack4 is actually not the true nethack, which lives on
nethack.org and is still working fine (e.g. public telnet servers on
nethack.alt.org).

Shameless pitch: I am currently struggling (but making _some_ progress)
to port nethack to the web with emscripten :-)
https://github.com/freddyb/nethack-3.4.3-js

I'll now put on a dunce cap of +2 shame for allowing this thread to
diverge into off-topic and try not to comment any further :D
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group

[Anne van Kesteren]

On Thu, Jan 29, 2015 at 10:27 PM, Eric Rescorla  wrote:
> On Thu, Jan 29, 2015 at 12:56 PM, L. David Baron  wrote:
>> On Friday 2015-01-16 09:58 +0100, Anne van Kesteren wrote:
>>> Also, can we request that they adopt a public asynchronous decision
>>> policy? I think we should start making that request from any WG.
>>
>> What do the Mozillians involved in the WG think about this?
>
> It depends what this means. If it means that decisions have to be confirmed
> on the list then fine. If it means that they can't be made F2F or on calls
> and then confirmed the list, then not so fine.

I would phrase the latter as the people at the F2F or call proposing a
decision and the list asynchronously deciding on it. So I think we are
in agreement. I would not want to preclude discussion outside of the
list, that seems unworkable and also impossible.


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

Re: gecko-dev and Git replication will be broken for a little while

[Tim Guan-tin Chien]

On Fri, Jan 30, 2015 at 6:48 AM, Mike Hommey  wrote:
>
> People using Git for Gecko development can also try a new workflow that
> doesn't involve gecko-dev at all.
>
> http://glandium.org/blog/?page_id=3438
>
> Mike

This sure look promising!

Any support for Level 1 people for creating a patch-to-commit for
attaching on Bugzilla?
I tried :jlebar's moz-git-tools once but the exported patch was broken for hg.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group

[Anne van Kesteren]

Thanks David!

On Fri, Jan 30, 2015 at 7:32 AM, L. David Baron  wrote:
> I'm particularly interested in review of point (3) in what I've written;
> I feel that the argument I've written so far is weak, I think because I
> don't particularly understand the concerns about the powerfulfeatures
> draft.

So for what it's worth, I think I'm in disagreement with Eric about
what WebAppSec's role should/could be. Groups at the W3C that go at it
alone often make questionable choices when it comes to a number of
things that are not their expertise so having some amount of informal
oversight is definitely warranted. And the group of people that make
up WebAppSec definitely appears to have the competence.

I don't really see where else "powerful features" would go and we do
need it. (Now permissions API is another matter as that requires UX
expertise.)


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

Re: gecko-dev and Git replication will be broken for a little while

[陳侃如]

Tim Guan-tin Chien  writes:

> On Fri, Jan 30, 2015 at 6:48 AM, Mike Hommey  wrote:
>>
>> People using Git for Gecko development can also try a new workflow that
>> doesn't involve gecko-dev at all.
>>
>> http://glandium.org/blog/?page_id=3438
>>
>> Mike
>
> This sure look promising!
>
> Any support for Level 1 people for creating a patch-to-commit for
> attaching on Bugzilla?
> I tried :jlebar's moz-git-tools once but the exported patch was broken for hg.

I use this alias in ~/.gitconfig

  [alias]
hg-format-patch = !sh -c 'git format-patch -kp -U8 "$@"|tee 
/dev/stderr|xargs git-patch-to-hg-patch' git

Get git-patch-to-hg-patch from https://github.com/mozilla/moz-git-tools

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

Re: gecko-dev and Git replication will be broken for a little while

[Wander Lairson Costa]

On Thu, Jan 29, 2015 at 8:48 PM, Mike Hommey  wrote:
> On Thu, Jan 29, 2015 at 12:31:35PM -0800, Gregory Szorc wrote:
>> The steps within my control to potentially fix this issue have been
>> postponed until at least tomorrow due to the Firefox Beta build today.
>> tl;dr is people don't want to take on additional risk changing repositories.
>>
>> I hate to say this, but people using Git for Gecko development will have to
>> wait another day for replication to turn on again.
>
> People using Git for Gecko development can also try a new workflow that
> doesn't involve gecko-dev at all.
>
> http://glandium.org/blog/?page_id=3438
>

Does this work for reviewboard [1] too?

Cheers,
Wander

[1] http://reviewboard-hg.mozilla.org/gecko/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Evaluating the performance of new features

[Gabriele Svelto]

On 30/01/2015 08:45, Jonas Sicking wrote:
> However, it would be cool if we fixed our IndexedDB implementation
> rather than told our own developers not to use it. Web developers are
> not so lucky as to have other options.

Yeah and we're making some pretty heavy use of it within Firefox OS.
I've spent some time trying to reduce its memory footprint (e.g.
including sending PRAGMA shrink_memory commands when low on memory or
when an app is sent to the background) but we really have no way around
using it. Any optimization effort for small & very small databases would
be very welcome as those are rather common AFAIK.

 Gabriele



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: gecko-dev and Git replication will be broken for a little while

[Trevor Saunders]

On Thu, Jan 29, 2015 at 01:28:48PM -0800, Eric Rescorla wrote:
> Thanks. Hopefully all will be back to normal soon.

Alternatively you can use the git-remote-hg glandium wrote and let
Alternatively you can take the excuse and switch to using the
git-remote-hg glandium wrote for everything and let mercurial just be a
memory you'd rather forget.

Trev

> 
> Best,
> -Ekr
> 
> 
> On Thu, Jan 29, 2015 at 1:27 PM, Gregory Szorc  wrote:
> 
> > On Thu, Jan 29, 2015 at 1:07 PM, Eric Rescorla  wrote:
> >
> >> On Thu, Jan 29, 2015 at 12:31 PM, Gregory Szorc  wrote:
> >>
> >>> The steps within my control to potentially fix this issue have been
> >>> postponed until at least tomorrow due to the Firefox Beta build today.
> >>> tl;dr is people don't want to take on additional risk changing
> >>> repositories.
> >>>
> >>> I hate to say this, but people using Git for Gecko development will have
> >>> to
> >>> wait another day for replication to turn on again.
> >>>
> >>> If you haven't tried Mercurial lately, you may want to. Read the
> >>> "Mercurial
> >>> for Mozillians" guide at
> >>>
> >>> http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/index.html
> >>> for some good pointers.
> >>
> >>
> >> Coming as it does in the middle of a git outage, this advertisement reads
> >> rather
> >> like "Dear git users, pound sand".
> >>
> >
> > Not my intent. Trying to make the best of a bad situation.
> >
> > I brushed up against 7+ years of technical debt around the way we manage
> > our Firefox repositories (the horrible "branching" model) and I lost. I'm
> > deeply sorry for any inconvenience that's caused and will cause.
> >
> ___
> 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: gecko-dev and Git replication will be broken for a little while

[kgupta]

On Friday, January 30, 2015 at 5:30:52 AM UTC-5, 陳侃如 Kan-Ru Chen wrote:
> 
> I use this alias in ~/.gitconfig
> 
>   [alias]
> hg-format-patch = !sh -c 'git format-patch -kp -U8 "$@"|tee 
> /dev/stderr|xargs git-patch-to-hg-patch' git
> 
> Get git-patch-to-hg-patch from https://github.com/mozilla/moz-git-tools
> 
> Kanru

That looks pretty complicated. I use something much simpler and it's never let 
me down:

[alias]
hgp = "show -M -C --binary --format=\"# HG changeset patch%n# User %an 
<%ae>%n%B\" -U8"

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

Re: Intent to implement and ship FormData on workers

[Boris Zbarsky]

On 1/30/15 1:30 AM, nsm.nik...@gmail.com wrote:

Well my work on getting FormData on workers was because Fetch uses it, and 
there doesn't seem to have been demand for it on workers before.


That's fair, but it seems like exposing it separately, if it's going to 
be ready before the rest of Fetch, reduces the risks and doesn't have 
much in the way of downsides that I see.



If there are no compat issues, I'm happy to just ship it.


I can't think of obvious compat issues here offhand.

-Boris

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

Re: Intent to implement and ship extended FormData methods

[Boris Zbarsky]

On 1/30/15 1:25 AM, nsm.nik...@gmail.com wrote:

https://bugzilla.mozilla.org/show_bug.cgi?id=1127703


Thanks.


The fetch spec states that FormData is immediately serialized when send() is called (send 
defers to Fetch's "extract body" routine) 
https://fetch.spec.whatwg.org/#concept-bodyinit-extract.

In Gecko, an nsFSMultipartFormData object serializes all entries to a multiplex 
stream immediately, so delete()/set()s called after a call to send() won't 
change the entries.


Excellent!

-Boris

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

Re: gecko-dev and Git replication will be broken for a little while

[Gregory Szorc]

On Fri, Jan 30, 2015 at 3:38 AM, Wander Lairson Costa 
wrote:

> On Thu, Jan 29, 2015 at 8:48 PM, Mike Hommey  wrote:
> > On Thu, Jan 29, 2015 at 12:31:35PM -0800, Gregory Szorc wrote:
> >> The steps within my control to potentially fix this issue have been
> >> postponed until at least tomorrow due to the Firefox Beta build today.
> >> tl;dr is people don't want to take on additional risk changing
> repositories.
> >>
> >> I hate to say this, but people using Git for Gecko development will
> have to
> >> wait another day for replication to turn on again.
> >
> > People using Git for Gecko development can also try a new workflow that
> > doesn't involve gecko-dev at all.
> >
> > http://glandium.org/blog/?page_id=3438
> >
>
> Does this work for reviewboard [1] too?
>
>
>
Not yet. Making Git work with MozReview is on my Q1 deliverables, assuming
someone else doesn't beat me to it.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: gecko-dev and Git replication will be broken for a little while

[Andrew McCreight]

On Fri, Jan 30, 2015 at 2:08 AM, Tim Guan-tin Chien 
wrote:

> Any support for Level 1 people for creating a patch-to-commit for
> attaching on Bugzilla?
> I tried :jlebar's moz-git-tools once but the exported patch was broken for
> hg.
>

The easiest way to attach a git patch to bugzilla is with
  git bz attach -e 
It automatically figures out what bug you want to attach to, based on the
commit description, and uses your browser cookie or something to actually
do the uploading.  It also formats it all correctly.

This is part of moz-git-tools, which we're actively maintaining at
https://github.com/mozilla/moz-git-tools

Please file any problems you have with it on Github.

Andrew


> ___
> 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

Web Workers full reference + tutorials

[Chris Mills]

Hi all,

We’ve had some web workers stuff on MDN for a while now, but it has been rather 
bitty and incomplete. I’ve added in the missing bits, updated stuff, and pulled 
it together underneath the following landing page:

https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API

Let me know if you notice anything wrong or misleading.

thanks!

Chris Mills
  Senior tech writer || Mozilla
developer.mozilla.org || MDN
  cmi...@mozilla.com || @chrisdavidmills



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

Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group

[Daniel Veditz]

On Thu, Jan 29, 2015 at 10:32 PM, L. David Baron  wrote:

> There are a number of problematic aspects to this charter to which
> we object:
>
> (1) The "Confinement with Origin Web Labels" deliverable is described
> in a way that makes it unclear what the deliverable would do.  It
> should be clearer.  Furthermore, the lack of clarity means we
> couldn't evaluate whether we are comfortable with it being in the
> charter.
>
> (2) The "Entry Point Regulation for Web Applications" deliverable seems
> to have serious risks of breaking the ability to link.  It's not
> clear that the security benefits of this specification outweigh the
> risks to the abilities of Web users.
>

​If something is in the charter and there's an initial draft spec, that
doesn't mean the final spec will be the same or that the WG has to
ultimately approve the spec at all, does it? Both of these ideas are
promising attempts to address particular security issues that are prevalent
on the web. They also both raise issues that may or may not be addressable
as the WG refines the specs. As long as we can object to the final specs if
they go off the rails these concepts are worth exploring.

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

Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group

[L. David Baron]

On Friday 2015-01-30 08:54 -0800, Daniel Veditz wrote:
> On Thu, Jan 29, 2015 at 10:32 PM, L. David Baron  wrote:
> 
> > There are a number of problematic aspects to this charter to which
> > we object:
> >
> > (1) The "Confinement with Origin Web Labels" deliverable is described
> > in a way that makes it unclear what the deliverable would do.  It
> > should be clearer.  Furthermore, the lack of clarity means we
> > couldn't evaluate whether we are comfortable with it being in the
> > charter.
> >
> > (2) The "Entry Point Regulation for Web Applications" deliverable seems
> > to have serious risks of breaking the ability to link.  It's not
> > clear that the security benefits of this specification outweigh the
> > risks to the abilities of Web users.
> >
> 
> If something is in the charter and there's an initial draft spec, that
> doesn't mean the final spec will be the same or that the WG has to
> ultimately approve the spec at all, does it? Both of these ideas are
> promising attempts to address particular security issues that are prevalent
> on the web. They also both raise issues that may or may not be addressable
> as the WG refines the specs. As long as we can object to the final specs if
> they go off the rails these concepts are worth exploring.

Regarding (1), it sounds like you know what it is and perhaps could
explain it?

Regarding (2), does it make sense for the charter to say that it's a
potential deliverable, but that the working group may choose not to
proceed depending on tradeoffs?

-David

-- 
𝄞   L. David Baron http://dbaron.org/   𝄂
𝄢   Mozilla  https://www.mozilla.org/   𝄂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: Digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: HEADS-UP: Disabling Gecko Media Plugins on older Linux kernels (bug 1120045)

[Randell Jesup]

>On Thu, Jan 29, 2015 at 06:57:30AM +0900, Mike Hommey wrote:
>> So, in practice, because the h264 code is not sandboxed on some setups,
>> we're disabling it so that vp8, which is not sandboxed either, is used
>> instead. We have about the same amount of control over openh264 and
>> vp8 code bases. What makes the difference?
>
>This is more a question for the WebRTC module leadership, but: assuming
>the attacker can choose the codec (do we always secure the media content
>at least as much as the script that set up the session?), the set of
>vulnerabilities is the union of the codecs' vulnerabilities, and adding
>a codec can only add more of them.
>
>Possibly also relevant: we already prefer VP8 over H.264 on desktop.

In theory VP8 is not inherently 'safer' than H.264.  In practice, the
OpenH264 codec is less mature, especially from a security perspective -
VP8 (due to our and Google's use and testing of it) has been pretty well
wrung out.  We could consider moving VP8 encode/decode to a sandbox;
there is a performance/memory cost to this.  I don't think we've had
many sec bugs in VP8 in recent years, so the risk/cost/reward tradeoff
may not be great.

An added concern for OpenH264 raised by various people has been that
OpenH264 is a 3rd-party download, which raises concerns about the
possibility of a compromised or evil plugin.  We are somewhat avoiding
that currently because we're doing the builds for Cisco, and we're also
looking for ways to create a bit-level reproducible build setup so
people can verify/validate that the binaries are what they say they are.

The other aspect here is that the same concerns will apply to any
EME/etc plugins using the GMP interface/sandbox; without seccomp-bpf, we
cannot ensure the plugins aren't doing something evil (or tracking
users), and those would be closed-source.  So there's even more reason
to disable GMP on these older linux systems.

-- 
Randell Jesup, Mozilla Corp
remove "news" for personal email
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group

[Eric Rescorla]

This seems satisfactory to me.

On Thu, Jan 29, 2015 at 10:32 PM, L. David Baron  wrote:

> Here are the comments I have so far on this charter, based on the
> thread.  I'd note that this is a relatively large set of demands to make
> in the charter review stage at the AC, especially for a recharter of a
> WG that we're involved in.  So it may come across to W3C staff as
> somewhat demanding.
>
> I'm particularly interested in review of point (3) in what I've written;
> I feel that the argument I've written so far is weak, I think because I
> don't particularly understand the concerns about the powerfulfeatures
> draft.
>
> I also haven't included anything about Brian's objection to the
> suborigin namespaces work because I don't understand the objection, and
> I don't see how to extract any actionable charter feedback directly from
> Brian's message.  (Or is it that the deliverable should be removed from
> the charter?  If so, I could use an explanation as to why.)
>
> In any case, here's the feedback I have so far.  Comments are
> welcome through roughly 5pm California time on Friday --
> particularly actionable ones that suggest how to revise this
> feedback or at least say how the charter should be different!
>
> (Sorry for not getting this gathered together sooner.)
>
> -David
>
>
> There are a number of problematic aspects to this charter to which
> we object:
>
> (1) The "Confinement with Origin Web Labels" deliverable is described
> in a way that makes it unclear what the deliverable would do.  It
> should be clearer.  Furthermore, the lack of clarity means we
> couldn't evaluate whether we are comfortable with it being in the
> charter.
>
> (2) The "Entry Point Regulation for Web Applications" deliverable seems
> to have serious risks of breaking the ability to link.  It's not
> clear that the security benefits of this specification outweigh the
> risks to the abilities of Web users.
>
> (3) In the scope section, the item "Application awareness of powerful
> features which may require explicit user permission to enable."
> It's not clear whether this part of the scope is intended to
> allow https://w3c.github.io/permissions/ to be a document in the
> working group (which may be comfortable with, although some of us
> have serious concerns about whether it is actually workable), or
> whether it's intended to put
> https://w3c.github.io/webappsec/specs/powerfulfeatures/ in the scope
> of the working group, which we believe should not be, because we
> don't believe the WebAppSec WG should be in the role of policing the
> specifications of other groups (which is not the role it has
> historically held), and we believe that in general specifications
> about how to write other specifications have not been successful,
> particularly if they attempt to have any mandatory status.
>
> At a minimum, it would be good to rephrase this item so that it
> doesn't use the term "powerful features".  It would probably be
> preferable to explicitly state that work like the powerfulfeatures
> draft is not in the scope of the working group.
>
> (4) We believe the charter should have provision for asynchronous
> decision making, perhaps as in
> http://www.w3.org/2012/webapps/charter/#decisions .
>
> --
> 𝄞   L. David Baron http://dbaron.org/   𝄂
> 𝄢   Mozilla  https://www.mozilla.org/   𝄂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group

[Eric Rescorla]

On Fri, Jan 30, 2015 at 2:14 AM, Anne van Kesteren  wrote:

> Thanks David!
>
> On Fri, Jan 30, 2015 at 7:32 AM, L. David Baron  wrote:
> > I'm particularly interested in review of point (3) in what I've written;
> > I feel that the argument I've written so far is weak, I think because I
> > don't particularly understand the concerns about the powerfulfeatures
> > draft.
>
> So for what it's worth, I think I'm in disagreement with Eric about
> what WebAppSec's role should/could be. Groups at the W3C that go at it
> alone often make questionable choices when it comes to a number of
> things that are not their expertise so having some amount of informal
> oversight is definitely warranted. And the group of people that make
> up WebAppSec definitely appears to have the competence.
>

I think there's some competence there, certainly, but I'm not convinced
it represents a balanced set of the views on this topic. If there is to
be oversight, it should probably be at that TAG level, IMHO.

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

Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group

[L. David Baron]

On Friday 2015-01-30 10:18 -0800, Eric Rescorla wrote:
> I think there's some competence there, certainly, but I'm not convinced
> it represents a balanced set of the views on this topic. If there is to
> be oversight, it should probably be at that TAG level, IMHO.

For many topics, oversight from the TAG can mean oversight from the
one person on the TAG who's interested in the topic, which may be
less likely to be balanced...

-David

-- 
𝄞   L. David Baron http://dbaron.org/   𝄂
𝄢   Mozilla  https://www.mozilla.org/   𝄂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: Digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: gecko-dev and Git replication will be broken for a little while

[Wander Lairson Costa]

On Fri, Jan 30, 2015 at 2:24 PM, Gregory Szorc  wrote:
> On Fri, Jan 30, 2015 at 3:38 AM, Wander Lairson Costa 
> wrote:
>>
>> On Thu, Jan 29, 2015 at 8:48 PM, Mike Hommey  wrote:
>> > On Thu, Jan 29, 2015 at 12:31:35PM -0800, Gregory Szorc wrote:
>> >> The steps within my control to potentially fix this issue have been
>> >> postponed until at least tomorrow due to the Firefox Beta build today.
>> >> tl;dr is people don't want to take on additional risk changing
>> >> repositories.
>> >>
>> >> I hate to say this, but people using Git for Gecko development will
>> >> have to
>> >> wait another day for replication to turn on again.
>> >
>> > People using Git for Gecko development can also try a new workflow that
>> > doesn't involve gecko-dev at all.
>> >
>> > http://glandium.org/blog/?page_id=3438
>> >
>>
>> Does this work for reviewboard [1] too?
>>
>>
>
> Not yet. Making Git work with MozReview is on my Q1 deliverables, assuming
> someone else doesn't beat me to it.
>

I am looking forward :)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Windows performance tutorial videos

[ben turner (bent)]

Hi folks,

If you're a Windows developer I highly recommend watching these free videos 
that explain how to use the windows performance toolkit:

  
https://randomascii.wordpress.com/2014/08/19/etw-training-videos-available-now/

It requires a free signup and then the videos are time-limited, but they're 
totally worth it.

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

Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group

[L. David Baron]

On Friday 2015-01-30 11:14 +0100, Anne van Kesteren wrote:
> On Fri, Jan 30, 2015 at 7:32 AM, L. David Baron  wrote:
> > I'm particularly interested in review of point (3) in what I've written;
> > I feel that the argument I've written so far is weak, I think because I
> > don't particularly understand the concerns about the powerfulfeatures
> > draft.
> 
> So for what it's worth, I think I'm in disagreement with Eric about
> what WebAppSec's role should/could be. Groups at the W3C that go at it
> alone often make questionable choices when it comes to a number of
> things that are not their expertise so having some amount of informal
> oversight is definitely warranted. And the group of people that make
> up WebAppSec definitely appears to have the competence.
> 
> I don't really see where else "powerful features" would go and we do
> need it. (Now permissions API is another matter as that requires UX
> expertise.)

My understanding is that the objections to powerfulfeatures are over
the possibility of powerfulfeatures defining what is and isn't a
powerful feature, because that should be decided primarily by the
group developing the feature.

Is that the part you think is important, or is the part that you
think is important the part that defines algorithms for whether a
context/origin is sufficiently secure or trustworthy?

-David

-- 
𝄞   L. David Baron http://dbaron.org/   𝄂
𝄢   Mozilla  https://www.mozilla.org/   𝄂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: Digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: HEADS-UP: Disabling Gecko Media Plugins on older Linux kernels (bug 1120045)

[Mike Hommey]

On Fri, Jan 30, 2015 at 12:33:55PM -0500, Randell Jesup wrote:
> >On Thu, Jan 29, 2015 at 06:57:30AM +0900, Mike Hommey wrote:
> >> So, in practice, because the h264 code is not sandboxed on some setups,
> >> we're disabling it so that vp8, which is not sandboxed either, is used
> >> instead. We have about the same amount of control over openh264 and
> >> vp8 code bases. What makes the difference?
> >
> >This is more a question for the WebRTC module leadership, but: assuming
> >the attacker can choose the codec (do we always secure the media content
> >at least as much as the script that set up the session?), the set of
> >vulnerabilities is the union of the codecs' vulnerabilities, and adding
> >a codec can only add more of them.
> >
> >Possibly also relevant: we already prefer VP8 over H.264 on desktop.
> 
> In theory VP8 is not inherently 'safer' than H.264.  In practice, the
> OpenH264 codec is less mature, especially from a security perspective -
> VP8 (due to our and Google's use and testing of it) has been pretty well
> wrung out.  We could consider moving VP8 encode/decode to a sandbox;
> there is a performance/memory cost to this.  I don't think we've had
> many sec bugs in VP8 in recent years, so the risk/cost/reward tradeoff
> may not be great.
> 
> An added concern for OpenH264 raised by various people has been that
> OpenH264 is a 3rd-party download, which raises concerns about the
> possibility of a compromised or evil plugin.  We are somewhat avoiding
> that currently because we're doing the builds for Cisco, and we're also
> looking for ways to create a bit-level reproducible build setup so
> people can verify/validate that the binaries are what they say they are.
> 
> The other aspect here is that the same concerns will apply to any
> EME/etc plugins using the GMP interface/sandbox; without seccomp-bpf, we
> cannot ensure the plugins aren't doing something evil (or tracking
> users), and those would be closed-source.  So there's even more reason
> to disable GMP on these older linux systems.

All GMP plugins don't need to be treated the same. The reason OpenH264
is one is bound to the fact that we can't ship it like we do vp8. And
iirc, It's already special cased in the GMP code anyways.

Moreover, we currently support h264 decoding with ffmpeg through
gstreamer. ffmpeg doesn't really have a great track record from a
security perspective, although I don't know how much of it affects the
h264 decoding code.


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

Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group

[L. David Baron]

Here's a revised set of comments, mainly changing:

 - describes the objection to powerfulfeatures (part of objection (3))
   more clearly, but also, I think, scopes the objection a bit more
   narrowly

 - makes objection (2) more explicit about being satisfied by an
   option not to complete the work

-David

There are a number of problematic aspects to this charter to which
we object:

(1) The "Confinement with Origin Web Labels" deliverable is described
in a way that makes it unclear what the deliverable would do.  It
should be clearer.  Furthermore, the lack of clarity means we
couldn't evaluate whether we are comfortable with it being in the
charter.

(2) The "Entry Point Regulation for Web Applications" deliverable seems
to have serious risks of breaking the ability to link.  It's not
clear that the security benefits of this specification outweigh the
risks to the abilities of Web users.

At the very least, the charter should be explicit that the group
may decide not to complete this item because of these tradeoffs.

(3) In the scope section, the item "Application awareness of powerful
features which may require explicit user permission to enable." It's
not clear whether this part of the scope is intended to allow
https://w3c.github.io/permissions/ to be a document in the working
group, or whether it's intended to put
https://w3c.github.io/webappsec/specs/powerfulfeatures/ in the scope
of the working group.  (I've heard separately that the powerfeatures
draft was intended to be in the charter as a deliverable but was
accidentally omitted.)  It seems like this probably refers to the
Permissions API spec, and if it does, it would probably be best to
avoid the use of the term "powerful features" to avoid confusion.

We may be comfortable with the Permissions API spec, although some
of us have concerns about it, and for that perhaps the charter
should be explicit about potentially abandoning the work as in point
(2).

We have more serious concerns about the scope of the
powerfulfeatures spec.  In particular, we don't believe the
WebAppSec WG should be in the role of policing the specifications of
other groups (which is not the role it has historically held) or
defining general (and likely overly-broad) rules to determine when a
feature has an important effect on a user's privacy or security.

Therefore, we would like to see producing enforceable definitions of
what is a powerful feature as explicitly out of scope for the Web
Application Security WG, since that determination should be made
primarily by the working group developing the feature, perhaps in
consultation with the Web Application Security WG.

(4) We believe the charter should have provision for asynchronous
decision making, perhaps as in
http://www.w3.org/2014/06/webapps-charter.html#decisions .

-- 
𝄞   L. David Baron http://dbaron.org/   𝄂
𝄢   Mozilla  https://www.mozilla.org/   𝄂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: Digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group

[Eric Rescorla]

This seems good to me.

On Fri, Jan 30, 2015 at 3:20 PM, L. David Baron  wrote:

> Here's a revised set of comments, mainly changing:
>
>  - describes the objection to powerfulfeatures (part of objection (3))
>more clearly, but also, I think, scopes the objection a bit more
>narrowly
>
>  - makes objection (2) more explicit about being satisfied by an
>option not to complete the work
>
> -David
>
> There are a number of problematic aspects to this charter to which
> we object:
>
> (1) The "Confinement with Origin Web Labels" deliverable is described
> in a way that makes it unclear what the deliverable would do.  It
> should be clearer.  Furthermore, the lack of clarity means we
> couldn't evaluate whether we are comfortable with it being in the
> charter.
>
> (2) The "Entry Point Regulation for Web Applications" deliverable seems
> to have serious risks of breaking the ability to link.  It's not
> clear that the security benefits of this specification outweigh the
> risks to the abilities of Web users.
>
> At the very least, the charter should be explicit that the group
> may decide not to complete this item because of these tradeoffs.
>
> (3) In the scope section, the item "Application awareness of powerful
> features which may require explicit user permission to enable." It's
> not clear whether this part of the scope is intended to allow
> https://w3c.github.io/permissions/ to be a document in the working
> group, or whether it's intended to put
> https://w3c.github.io/webappsec/specs/powerfulfeatures/ in the scope
> of the working group.  (I've heard separately that the powerfeatures
> draft was intended to be in the charter as a deliverable but was
> accidentally omitted.)  It seems like this probably refers to the
> Permissions API spec, and if it does, it would probably be best to
> avoid the use of the term "powerful features" to avoid confusion.
>
> We may be comfortable with the Permissions API spec, although some
> of us have concerns about it, and for that perhaps the charter
> should be explicit about potentially abandoning the work as in point
> (2).
>
> We have more serious concerns about the scope of the
> powerfulfeatures spec.  In particular, we don't believe the
> WebAppSec WG should be in the role of policing the specifications of
> other groups (which is not the role it has historically held) or
> defining general (and likely overly-broad) rules to determine when a
> feature has an important effect on a user's privacy or security.
>
> Therefore, we would like to see producing enforceable definitions of
> what is a powerful feature as explicitly out of scope for the Web
> Application Security WG, since that determination should be made
> primarily by the working group developing the feature, perhaps in
> consultation with the Web Application Security WG.
>
> (4) We believe the charter should have provision for asynchronous
> decision making, perhaps as in
> http://www.w3.org/2014/06/webapps-charter.html#decisions .
>
> --
> 𝄞   L. David Baron http://dbaron.org/   𝄂
> 𝄢   Mozilla  https://www.mozilla.org/   𝄂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)
>
> ___
> 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: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group

[Martin Thomson]

Please note the need to liaise with the groups that are affected by the
permissions work.  Otherwise, this is good.

On Fri, Jan 30, 2015 at 3:20 PM, L. David Baron  wrote:

> Here's a revised set of comments, mainly changing:
>
>  - describes the objection to powerfulfeatures (part of objection (3))
>more clearly, but also, I think, scopes the objection a bit more
>narrowly
>
>  - makes objection (2) more explicit about being satisfied by an
>option not to complete the work
>
> -David
>
> There are a number of problematic aspects to this charter to which
> we object:
>
> (1) The "Confinement with Origin Web Labels" deliverable is described
> in a way that makes it unclear what the deliverable would do.  It
> should be clearer.  Furthermore, the lack of clarity means we
> couldn't evaluate whether we are comfortable with it being in the
> charter.
>
> (2) The "Entry Point Regulation for Web Applications" deliverable seems
> to have serious risks of breaking the ability to link.  It's not
> clear that the security benefits of this specification outweigh the
> risks to the abilities of Web users.
>
> At the very least, the charter should be explicit that the group
> may decide not to complete this item because of these tradeoffs.
>
> (3) In the scope section, the item "Application awareness of powerful
> features which may require explicit user permission to enable." It's
> not clear whether this part of the scope is intended to allow
> https://w3c.github.io/permissions/ to be a document in the working
> group, or whether it's intended to put
> https://w3c.github.io/webappsec/specs/powerfulfeatures/ in the scope
> of the working group.  (I've heard separately that the powerfeatures
> draft was intended to be in the charter as a deliverable but was
> accidentally omitted.)  It seems like this probably refers to the
> Permissions API spec, and if it does, it would probably be best to
> avoid the use of the term "powerful features" to avoid confusion.
>
> We may be comfortable with the Permissions API spec, although some
> of us have concerns about it, and for that perhaps the charter
> should be explicit about potentially abandoning the work as in point
> (2).
>
> We have more serious concerns about the scope of the
> powerfulfeatures spec.  In particular, we don't believe the
> WebAppSec WG should be in the role of policing the specifications of
> other groups (which is not the role it has historically held) or
> defining general (and likely overly-broad) rules to determine when a
> feature has an important effect on a user's privacy or security.
>
> Therefore, we would like to see producing enforceable definitions of
> what is a powerful feature as explicitly out of scope for the Web
> Application Security WG, since that determination should be made
> primarily by the working group developing the feature, perhaps in
> consultation with the Web Application Security WG.
>
> (4) We believe the charter should have provision for asynchronous
> decision making, perhaps as in
> http://www.w3.org/2014/06/webapps-charter.html#decisions .
>
> --
> 𝄞   L. David Baron http://dbaron.org/   𝄂
> 𝄢   Mozilla  https://www.mozilla.org/   𝄂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: gecko-dev and Git replication will be broken for a little while

[Gregory Szorc]

I figured people would like an update.

There were multiple, independent failures in the replication systems (there
are 2 systems that replicate Mercurial to Git).

At least one system wasn't DAG aware. It was effectively using the "tip"
commit of the Mercurial repositories (the most recently committed
changeset) to constitute the Git branch head when it should have been using
the latest commit on the "default" branch. It is a minor miracle this
hasn't broken before, as all anybody needed to do was push to an older head
to create a non-fast-forward push.

The other system got in a really wonky state when processing some merge
commits in mozilla-central. Instead of converting a handful of commits in
the 2nd merge parent, it converted all commits down to Mercurial revision 0
and merged in an unrelated DAG head with tens of thousands of commits! It's
a good thing GitHub rejected a malformed author line, or the gecko-dev
repository would be epically whacky right now and would almost certainly
require a hard reset / force push to correct.

Both systems are replicating Firefox Mercurial commits to Git. And the
SHA-1s need to be consistent between them. We're capable of fixing at least
one of these systems now. But we're hesitant to fix one unless we are
pretty sure both systems agree about SHA-1s. We have obligations with
partners to not force push. And, you don't like force pushing either. So
caution is needed before bringing any system back online.

There is currently no ETA for service restoration. But people are working
on it. I wish I had better news to report.

On Thu, Jan 29, 2015 at 1:06 AM, Gregory Szorc  wrote:

> Git replication is currently broken due to a mistake of mine when mass
> closing branches earlier today.
>
> Don't expect restoration before 1200 PDT.
>
> Bug 927219.
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: HEADS-UP: Disabling Gecko Media Plugins on older Linux kernels (bug 1120045)

[Bobby Holley]

I think the point here is that we want to free ourselves from needing the
chemspill over OpenH264 memory hazards if we find them (since the code is
relatively new).

With gstreamer, I think we just blacklist vulnerable versions.

On Fri, Jan 30, 2015 at 3:15 PM, Mike Hommey  wrote:

> On Fri, Jan 30, 2015 at 12:33:55PM -0500, Randell Jesup wrote:
> > >On Thu, Jan 29, 2015 at 06:57:30AM +0900, Mike Hommey wrote:
> > >> So, in practice, because the h264 code is not sandboxed on some
> setups,
> > >> we're disabling it so that vp8, which is not sandboxed either, is used
> > >> instead. We have about the same amount of control over openh264 and
> > >> vp8 code bases. What makes the difference?
> > >
> > >This is more a question for the WebRTC module leadership, but: assuming
> > >the attacker can choose the codec (do we always secure the media content
> > >at least as much as the script that set up the session?), the set of
> > >vulnerabilities is the union of the codecs' vulnerabilities, and adding
> > >a codec can only add more of them.
> > >
> > >Possibly also relevant: we already prefer VP8 over H.264 on desktop.
> >
> > In theory VP8 is not inherently 'safer' than H.264.  In practice, the
> > OpenH264 codec is less mature, especially from a security perspective -
> > VP8 (due to our and Google's use and testing of it) has been pretty well
> > wrung out.  We could consider moving VP8 encode/decode to a sandbox;
> > there is a performance/memory cost to this.  I don't think we've had
> > many sec bugs in VP8 in recent years, so the risk/cost/reward tradeoff
> > may not be great.
> >
> > An added concern for OpenH264 raised by various people has been that
> > OpenH264 is a 3rd-party download, which raises concerns about the
> > possibility of a compromised or evil plugin.  We are somewhat avoiding
> > that currently because we're doing the builds for Cisco, and we're also
> > looking for ways to create a bit-level reproducible build setup so
> > people can verify/validate that the binaries are what they say they are.
> >
> > The other aspect here is that the same concerns will apply to any
> > EME/etc plugins using the GMP interface/sandbox; without seccomp-bpf, we
> > cannot ensure the plugins aren't doing something evil (or tracking
> > users), and those would be closed-source.  So there's even more reason
> > to disable GMP on these older linux systems.
>
> All GMP plugins don't need to be treated the same. The reason OpenH264
> is one is bound to the fact that we can't ship it like we do vp8. And
> iirc, It's already special cased in the GMP code anyways.
>
> Moreover, we currently support h264 decoding with ffmpeg through
> gstreamer. ffmpeg doesn't really have a great track record from a
> security perspective, although I don't know how much of it affects the
> h264 decoding code.
>
>
> Mike
> ___
> 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: Intent to implement and ship FormData on workers

[Tantek Çelik]

On Fri, Jan 30, 2015 at 7:13 AM, Boris Zbarsky  wrote:
> On 1/30/15 1:30 AM, nsm.nik...@gmail.com wrote:
>>
>> Well my work on getting FormData on workers was because Fetch uses it, and
>> there doesn't seem to have been demand for it on workers before.
>
>
> That's fair, but it seems like exposing it separately, if it's going to be
> ready before the rest of Fetch, reduces the risks and doesn't have much in
> the way of downsides that I see.

Yes it makes sense to expose a building block that Fetch uses, before
exposing Fetch.

>> If there are no compat issues, I'm happy to just ship it.
>
>
> I can't think of obvious compat issues here offhand.

Same here. +1 no pref.

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

Re: Evaluating the performance of new features

[Vladan Djeric]

We do need a performant key-value store implementation. This has been
discussed before and various people have come up with proposals
(myself included), but no one has had the time & focus to see it
through to the end :/
I suspect part of the problem is that different use cases (IndexedDB
re-implementation, prefs, simple storage, etc) have different
requirements so no single solution satisfies everyone. I doubt I'll
have time in Q1 but this is definitely something I want to do, or help
out with, if some one else would like to step up.

On Fri, Jan 30, 2015 at 8:44 AM, Gabriele Svelto  wrote:
> On 30/01/2015 08:45, Jonas Sicking wrote:
>> However, it would be cool if we fixed our IndexedDB implementation
>> rather than told our own developers not to use it. Web developers are
>> not so lucky as to have other options.
>
> Yeah and we're making some pretty heavy use of it within Firefox OS.
> I've spent some time trying to reduce its memory footprint (e.g.
> including sending PRAGMA shrink_memory commands when low on memory or
> when an app is sent to the background) but we really have no way around
> using it. Any optimization effort for small & very small databases would
> be very welcome as those are rather common AFAIK.
>
>  Gabriele
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Evaluating the performance of new features

[Chris Peterson]

A 2013 dev-platform thread ("Storage in Gecko") spawned bug 866238:

Implement simple key-value store module on top of indexedDB for storing 
small amounts of data.


https://groups.google.com/forum/#!topic/mozilla.dev.platform/vYbQqkqGzlo


chris


On 1/30/15 10:03 PM, Vladan Djeric wrote:

We do need a performant key-value store implementation. This has been
discussed before and various people have come up with proposals
(myself included), but no one has had the time & focus to see it
through to the end :/
I suspect part of the problem is that different use cases (IndexedDB
re-implementation, prefs, simple storage, etc) have different
requirements so no single solution satisfies everyone. I doubt I'll
have time in Q1 but this is definitely something I want to do, or help
out with, if some one else would like to step up.

On Fri, Jan 30, 2015 at 8:44 AM, Gabriele Svelto  wrote:

On 30/01/2015 08:45, Jonas Sicking wrote:

However, it would be cool if we fixed our IndexedDB implementation
rather than told our own developers not to use it. Web developers are
not so lucky as to have other options.


Yeah and we're making some pretty heavy use of it within Firefox OS.
I've spent some time trying to reduce its memory footprint (e.g.
including sending PRAGMA shrink_memory commands when low on memory or
when an app is sent to the background) but we really have no way around
using it. Any optimization effort for small & very small databases would
be very welcome as those are rather common AFAIK.

  Gabriele



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

Partial restoration: gecko-dev and Git replication will be broken for a little while

[Hal Wine]

  
  
[typo on address first time]

  
   Forwarded Message 
  

  
Subject:

Partial restoration: gecko-dev and Git replication will
  be broken for a little while
  
  
Date: 
Fri, 30 Jan 2015 22:30:18 -0800
  
  
From: 
Hal Wine 
  
  
To: 
dev-g...@lists.mozilla.org, dev-...@lists.mozilla.org,
  VCS devs ,
  dev-planf...@lists.mozilla.org, Bhavana Bajaj
  
  
  
CC: 
Laura Thomson , Releng
  community 
  

  
  
  
  tl;dr: branches for all b2g version up through 2.2 for partner facing 
gecko.git have been re-enabled; work continues on developer 
gecko-dev.git development branches.

This translates to all b2g gecko development efforts up through version. 
Work continues to re-enable both:
 a) those branches in the gecko-dev.git repo used by both b2g & FF 
developers
 b) the newer mozilla-central and inbound branches, including 
gecko-projects.git

Note: only the gecko conversion from hg -> git has been affected. All 
other conversion (l10n, gaia, other) continue to operating correctly.

More details in https://bugzil.la/927219#c45


On 2015-01-29 07:12 , Hal Wine wrote:
> FYI, recent commits to gecko on hg.mozilla.org will be delayed in 
> arriving at github.com:mozilla/gecko-dev.git This likely includes 
> anything landed after approximate 2000PT Wednesday.
>
>
>  Forwarded Message 
> Subject: gecko-dev and Git replication will be broken for a little while
> Date: Thu, 29 Jan 2015 01:06:30 -0800
> From: Gregory Szorc 
> To: dev-version-cont...@lists.mozilla.org, dev-platform 
> 
> Newsgroups: mozilla.dev.platform
>
> Git replication is currently broken due to a mistake of mine when mass
> closing branches earlier today.
>
> Don't expect restoration before 1200 PDT.
>
> Bug 927219.
>
>


  


  

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

Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group

[Brian Smith]

L. David Baron  wrote:
> Is the argument you're making that if the site can serve the ads
> from the same hostname rather than having to use a different
> hostname to get same-origin protection, then ad-blocking (or
> tracking-blocking) tools will no longer be able to block the ads?

Yes.

Anyway, my point isn't to suggest that Mozilla should ask for this
item to be removed from the charter. Rather, my point is that this
item has some pretty big, non-obvious ramifications (not just related
to tracking) that Mozilla should understand. I think what you said
about it being described in an unclear way is a good response. Joel
Weinberger from the Chrome Security Team already explained a lot of it
to me privately. I recommend talking to him about it, if you want to
understand it better.

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

Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group

[Anne van Kesteren]

On Sat, Jan 31, 2015 at 12:15 AM, L. David Baron  wrote:
> My understanding is that the objections to powerfulfeatures are over
> the possibility of powerfulfeatures defining what is and isn't a
> powerful feature, because that should be decided primarily by the
> group developing the feature.

It's not clear to me that other groups have done a good job of that,
historically. Delegating this to the TAG instead could be done I
suppose, except that a) the TAG has no security experts (although one
is elected now) and b) the TAG has endorsed this approach already.


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