What platform features can we kill?

[Gervase Markham]

Attack surface reduction works:
http://blog.gerv.net/2013/10/attack-surface-reduction-works/

Removing E4X broke the NSA's "EGOTISTICALGOAT" attack - a type confusion
vulnerability in E4X.

In the spirit of learning from this, what's next on the chopping block?

A quick survey of the security-group led to the following suggestions,
and I'm sure there are more:

* JS engine: Proxy.create, Object.prototype.watch, __noSuchMethod__,
legacy (pre-ES6) generators, __iterator__, non-ES6 let-blocks, pre-ES6
expression closures

* Editor (share a JS implementation with Servo instead)

* Most OOM recovery in the JS engine

* FTP (perhaps replace with JS implementation from FireFTP)

* Windows integrated auth

* XSLT (Chrome have already announced they will remove it:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/zIg2KC7PyH0
;
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/k8aIeI6BCG0
)

Gerv

[Boris Zbarsky]

On 10/9/13 12:01 PM, Gervase Markham wrote:
> In the spirit of learning from this, what's next on the chopping block?

RDF

> * XSLT (Chrome have already announced they will remove it:

We'd need to do the same extension thing they're proposing or something;
this is used in the wild for sites that people care about.

-Boris

[Benjamin Smedberg]

On 10/9/2013 12:18 PM, Boris Zbarsky wrote:
> On 10/9/13 12:01 PM, Gervase Markham wrote:
>> In the spirit of learning from this, what's next on the chopping block?
>
> RDF

I'm all for this, although the risk is probably quite small because we
don't expose RDF to content.

--BDS

[Brian Smith]

On Wed, Oct 9, 2013 at 9:01 AM, Gervase Markham <ge...@mozilla.org> wrote:
> * Windows integrated auth

I would love to kill Windows integrated auth. It seems like doing so
would mean almost the same thing as saying "we don't care about
intranets" though. That's something I would be very interested in
hearing about from the Product team.

We should remove the legacy window.crypto.* (MOZ_DOMCRYPTO_LEGACY)
stuff described at [1]. ("Warning: The features mentioned in this
article are proprietary Mozilla extensions, and are not supported in
any other browser.") I am working on sorting out the politics of doing
so on dev-tech-crypto [2].

[1] https://developer.mozilla.org/en-US/docs/JavaScript_crypto
[2] https://groups.google.com/d/msg/mozilla.dev.tech.crypto/FRmpYubnan4/DDiAtniVW-0J

Cheers,
Brian
--
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

[gNeandr]

On 09.10.2013 18:01, Gervase Markham wrote:

> * XSLT (Chrome have already announced they will remove it:
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/zIg2KC7PyH0
> ;
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/k8aIeI6BCG0
>

CON to remove XSLT support from platform!
XML/XSLT is used for printing ICS calendar data to get web page output
in form of agenda/dairy lists. This is the most flexible form a user can
get for his/her requirements. All can be configured by the user outside
of the extension code!
Removing XSLT would remove this flexibility. Not good ;(

[Chris Peterson]

On 10/9/13 9:49 AM, Benjamin Smedberg wrote:
>>> In the spirit of learning from this, what's next on the chopping block?
>>
>> RDF
> I'm all for this, although the risk is probably quite small because we
> don't expose RDF to content.

Bug 833098 - Kick RDF out of Firefox

Comments in the bug suggest a build-time flag because Thunderbird needs
on RDF.


chris

[Jonathan Kew]

On 9/10/13 17:18, Boris Zbarsky wrote:
> On 10/9/13 12:01 PM, Gervase Markham wrote:
>> In the spirit of learning from this, what's next on the chopping block?

>> * XSLT (Chrome have already announced they will remove it:

Have they? I admit I haven't made it through every post in their
discussion threads, but AFAICS, some people from Chrome have expressed
an interest in removing it, but this suggestion generated considerable
debate (including some definite opposition to the idea).

>
> We'd need to do the same extension thing they're proposing or something;
> this is used in the wild for sites that people care about.

It's used "in the wild" on the web, and I've also known it to be used
locally as a convenient tool to present views of data files that happen
to be maintained in XML format.

Moving it to an extension (so that it isn't available unless the user is
aware of it and explicitly installs support) would seem like a negative
step, though if usage is rare/specialized enough, perhaps it would be
OK. But I think we should be very hesitant to entirely remove XSLT
support from the platform.

JK

[Ehsan Akhgari]

On 2013-10-09 12:18 PM, Boris Zbarsky wrote:
> On 10/9/13 12:01 PM, Gervase Markham wrote:
>> In the spirit of learning from this, what's next on the chopping block?
>
> RDF

We use RDF in Firefox, in localstore.rdf among others I guess.

>> * XSLT (Chrome have already announced they will remove it:
>
> We'd need to do the same extension thing they're proposing or something;
> this is used in the wild for sites that people care about.

We use XSLT in our products in a few places I guess, including
<http://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/content/extensions.xml#l1373>
:(

Also, note that I don't think the Blink folks have reached a consensus
on whether they can remove XSLT or not yet.

Cheers,
Ehsan

[Ehsan Akhgari]

On 2013-10-09 12:01 PM, Gervase Markham wrote:
> * Editor (share a JS implementation with Servo instead)

I've been fantacizing about this for a while (not about the Servo code
sharing part per se of course.) This is hard because of a variety of
reasons, including the fact that there is no real spec for editing. But
I've also heard recent rumors that the Blink people want their editing
code out of their core code as well... So it would be interesting to
keep watching this space.

Cheers,
Ehsan

[Boris Zbarsky]

On 10/9/13 2:25 PM, Ehsan Akhgari wrote:
> On 2013-10-09 12:18 PM, Boris Zbarsky wrote:
>> On 10/9/13 12:01 PM, Gervase Markham wrote:
>>> In the spirit of learning from this, what's next on the chopping block?
>>
>> RDF
>
> We use RDF in Firefox, in localstore.rdf among others I guess.

Right. We should stop doing that. ;)

-Boris

[Neil]

Gervase Markham wrote:

>* XSLT
>

Doesn't the XML prettyprinter use XSLT?

--
Warning: May contain traces of nuts.

[Neil]

Gervase Markham wrote:

>* Editor (share a JS implementation with Servo instead)
>

By the time the editor works in Servo, you probably want to think about
reducing your attack surface by switching to Servo instead.

[Justin Dolske]

On 10/9/13 11:29 AM, Boris Zbarsky wrote:

>>> RDF
>>
>> We use RDF in Firefox, in localstore.rdf among others I guess.
>
> Right. We should stop doing that. ;)

Bug 559505 - localstore.rdf kills ponies

I got hung up on the (ancient) patch there because RDF is baked pretty
firmly into the XUL Tree API.

(Hey, I just thought of another thing to add to the chopping block.)

Justin

[Benjamin Smedberg]

On 10/9/2013 2:25 PM, Ehsan Akhgari wrote:
> On 2013-10-09 12:18 PM, Boris Zbarsky wrote:

>> On 10/9/13 12:01 PM, Gervase Markham wrote:
>>> In the spirit of learning from this, what's next on the chopping block?
>>
>> RDF
>

> We use RDF in Firefox, in localstore.rdf among others I guess.

This is not that hard to fix. AFAIK there's nothing that intrinsically
ties XUL persistence to localstore.rdf, and we already have an import
library for RDF written in JS. So it's mainly a question of hooking XUL
persistence up to something simpler (probably storage).

--BDS

[Brian Smith]

On Wed, Oct 9, 2013 at 9:01 AM, Gervase Markham <ge...@mozilla.org> wrote:

> Attack surface reduction works:
> http://blog.gerv.net/2013/10/attack-surface-reduction-works/
>

> In the spirit of learning from this, what's next on the chopping block?

Master password. The UI is prone to phishing, it causes all sorts of
problems because of how we use the log in to the NSS database to
implement it, it causes annoying UX for the people that use it, the
cryptography used is useless (bing FireMaster), there's hardly any
resources to do anything to actually fix any of these problems other
than remove it, and it slows down progress on important security
features.

Cheers,
Brian

[Axel Hecht]

On 10/9/13 6:18 PM, Boris Zbarsky wrote:
> On 10/9/13 12:01 PM, Gervase Markham wrote:
>> In the spirit of learning from this, what's next on the chopping block?
>
> RDF

Yes.

I think that localstore.rdf is the long pole. Not so much because we
abuse it for xul persistance, that's OK to fix. The thing that bothers
me most is all of those addons that probably still use it.

I'd love if we could get some data about that in particular, and RDF
usage in addons in general.

And then there's mailnews, of course. That one's sad. Close, but we
moved everyone off of mailnews "just" before it got rid of RDF, IIRC.

Axel

[Ehsan Akhgari]

On 2013-10-09 2:39 PM, Neil wrote:
> Gervase Markham wrote:
>
>> * XSLT
>>
> Doesn't the XML prettyprinter use XSLT?

It does:
<http://mxr.mozilla.org/mozilla-central/source/content/xml/document/resources/XMLPrettyPrint.xsl?force=1>

We also use it for about:memory apparently.

[Botond Ballo]

> Master password. The UI is prone to phishing, it causes all sorts of
> problems because of how we use the log in to the NSS database to
> implement it, it causes annoying UX for the people that use it, the
> cryptography used is useless (bing FireMaster), there's hardly any
> resources to do anything to actually fix any of these problems other
> than remove it, and it slows down progress on important security
> features.

I use master password. Is there something I can use instead that's
more secure?

Thanks,
Botond

[Philipp Kewisch]

On 10/9/13 6:01 PM, Gervase Markham wrote:
> Attack surface reduction works:
> http://blog.gerv.net/2013/10/attack-surface-reduction-works/
>
> Removing E4X broke the NSA's "EGOTISTICALGOAT" attack - a type confusion
> vulnerability in E4X.
>
> In the spirit of learning from this, what's next on the chopping block?

So you are saying, we should start removing features that could decrease
the attack surface? So then lets remove JavaScript, this could
definitely decrease the attack surface.

I think its the wrong conclusion, shouldn't we rather be fixing security
holes and analysing the code for vulnerabilities than removing random
things just because of their potential risk?

Removing features will definitely make people unhappy, and more work for
(extension) authors needing to adapt to the platform changes yet again.

Philipp

[Jim Porter]

Thunderbird doesn't really want RDF either. However, killing RDF in
Thunderbird has been a slow process. If there's anyone who wants to help
kill RDF in Thunderbird, go for it!

- Jim

[Joshua Cranmer 🐧]

On 10/9/2013 11:18 AM, Boris Zbarsky wrote:
> On 10/9/13 12:01 PM, Gervase Markham wrote:
>> In the spirit of learning from this, what's next on the chopping block?
>
> RDF

Having gone through some of the ancient security bugs, it looks like the
walking-security-hole aspect of RDF was limited mostly to mailnew's
horrific abuse of it for folders. That aspect I have a plan to
eliminate; the use of it for templated UI is, too my knowledge, not a
security issue per se.

Also, to those who believe that localstore.rdf is the only use of RDF
remaining in Firefox, I can only cock my head and laugh. MXR reveals
that charsets, mimetypes, and help (which is in toolkit, but may only be
in SeaMonkey these days) are still present uses in mozilla-central. And
I'm sure that a significant number of addons still use it. (I'd refer
you to an MXR results for addons, but this is the sort of thing where it
fails miserably since it doesn't let me search "only addons that work on
maintained versions of Firefox").

--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

[Zack Weinberg]

On 2013-10-09 12:01 PM, Gervase Markham wrote:
> In the spirit of learning from this, what's next on the chopping block?

In between "keep the C++ implementation" and "scrap entirely" is
"reimplement in JS", and I think that should be seriously considered for
things like XSLT where there's no question but what it increases our
attack surface, but there is also a strong (if small) constituency.
Where it is currently impossible to do something in JS, that points at a
weakness in the platform - whether capabilities or just speed.

In that vein, I think we should take a hard look at the image decoders.
Not only is that a significant chunk of attack surface, it is a place
where it's hard to innovate; image format after image format has died on
the vine because it wasn't *enough* of an improvement to justify the
additional glob of compiled code. Web-deliverable JS image decoders
could open that up.

The other thing that comes to mind is, if Web Components lives up to its
promise, perhaps it could be used for the built-in form controls?
That's also a big pile of hair, and form elements in odd places have
been an ongoing source of crasher bugs.

zw

[Boris Zbarsky]

On 10/9/13 8:36 PM, Zack Weinberg wrote:
> if Web Components lives up to its
> promise, perhaps it could be used for the built-in form controls?

For what it's worth, we've tried that with XBL. It died on the
"performance and memory usage" beach...

-Boris

[Gavin Sharp]

On Wed, Oct 9, 2013 at 4:28 PM, Philipp Kewisch <moz...@kewis.ch> wrote:
> I think its the wrong conclusion, shouldn't we rather be fixing security
> holes and analysing the code for vulnerabilities than removing random things
> just because of their potential risk?

Those options are not mutually exclusive; we should be doing both.

There's obvious value in thinking about ways to reduce our attack
surface, and that's all Gerv was suggesting we do. Obviously there are
tradeoffs involved, and we need to evaluate them when making any
decisions. Arguing that removing anything would be equivalent to
removing support for JS is not really useful.

I don't think anyone in this thread was actually mistaken into
thinking that removing RDF or XSLT was as simple as an "hg rm". That
removing them is harder than that doesn't mean it's not worth thinking
about (and indeed much thinking about it has been done, in e.g.
https://bugzilla.mozilla.org/show_bug.cgi?id=833098).

Gavin

[Nicholas Nethercote]

On Wed, Oct 9, 2013 at 2:36 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
>
> In the spirit of learning from this, what's next on the chopping block?

JSD. Firebug's the main consumer, AFAIK.

> * Most OOM recovery in the JS engine

In the past that has been left alone due to the preference of the JS
engine module owner. Perhaps the new JS engine module owners can say
what they think about it.

>>> * XSLT

>
> We also use it for about:memory apparently.

We do? Can you show me where?

> In that vein, I think we should take a hard look at the image decoders.

At the summit a few of us were talking about ways to promote Rust.
One idea was to rewrite a smallish, well-separated component of
Firefox in Rust, to (a) gain the benefits (parallelism, safety) of
Rust, and (b) promote Rust as a credible language in non-experimental
systems. Image decoders were the first component that came up as a
possibility.

Nick

[Mike Hommey]

On Wed, Oct 09, 2013 at 08:18:16PM -0700, Nicholas Nethercote wrote:
> At the summit a few of us were talking about ways to promote Rust.
> One idea was to rewrite a smallish, well-separated component of
> Firefox in Rust, to (a) gain the benefits (parallelism, safety) of
> Rust, and (b) promote Rust as a credible language in non-experimental
> systems. Image decoders were the first component that came up as a
> possibility.

The problem with that plan is that bootstrapping the rust compiler is kind
of a problem at the moment, both for trusting trust, and for shipping in
e.g. linux distros.

Mike

[Chris Peterson]

On 10/9/13 8:18 PM, Nicholas Nethercote wrote:
> On Wed, Oct 9, 2013 at 2:36 PM, Ehsan Akhgari<ehsan....@gmail.com> wrote:
>> >
>> >In the spirit of learning from this, what's next on the chopping block?
>
> JSD. Firebug's the main consumer, AFAIK.

The meta bug for removing JSD is bug 800200. I believe the primary
blocking issue is bug 716647 ("allow Debugger to be enabled with
debuggee frames on the stack"), which jorendorff is starting to work on.


chris

[Nicholas Nethercote]

On Wed, Oct 9, 2013 at 9:12 PM, Mike Hommey <m...@glandium.org> wrote:
>> At the summit a few of us were talking about ways to promote Rust.
>> One idea was to rewrite a smallish, well-separated component of
>> Firefox in Rust, to (a) gain the benefits (parallelism, safety) of
>> Rust, and (b) promote Rust as a credible language in non-experimental
>> systems. Image decoders were the first component that came up as a
>> possibility.
>
> The problem with that plan is that bootstrapping the rust compiler is kind
> of a problem at the moment, both for trusting trust, and for shipping in
> e.g. linux distros.

Yep. And Rust might not be available on all the platforms that
Firefox is. Having it as an opt-in configuration -- and one we would
enable in official releases on suitable platforms, assuming it all
worked well -- might be acceptable, though it would be added
complexity.

Nick

[Anne van Kesteren]

On Wed, Oct 9, 2013 at 6:01 PM, Gervase Markham <ge...@mozilla.org> wrote:
> * XSLT (Chrome have already announced they will remove it:

> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/zIg2KC7PyH0
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/k8aIeI6BCG0

What I watched Adam describe in a video of the architecture talk at
BlinkOn was that they want to implement certain features, including
editing and XSLT, in terms of lower-level primitives instead of
implementing as low-level primitives, to increase the amount of
sandboxing and robustness. I think they concluded that for now they
cannot actually remove XSLT.


--
http://annevankesteren.nl/

[Michael Lefevre]

I wouldn't disagree with any of the other reasons, but could you clarify
what you mean when you say the cryptography is useless? FireMaster
seems to just brute force passwords. Are you just saying that any
cryptography that relies on a password is useless, or that something is
more broken than that?

(For what it's worth, things like KeePass and LastPass can use
two-factor authentication, and have better UX I think, although the UX
is still rather clunky...)

Michael

[Gabriele Svelto]

On 10/10/2013 11:22, Michael Lefevre wrote:
>> Master password. The UI is prone to phishing, it causes all sorts of
>> problems because of how we use the log in to the NSS database to
>> implement it, it causes annoying UX for the people that use it, the
>> cryptography used is useless (bing FireMaster), there's hardly any
>> resources to do anything to actually fix any of these problems other
>> than remove it, and it slows down progress on important security
>> features.
>
> I wouldn't disagree with any of the other reasons, but could you clarify
> what you mean when you say the cryptography is useless? FireMaster
> seems to just brute force passwords. Are you just saying that any
> cryptography that relies on a password is useless, or that something is
> more broken than that?

There's been a fairly long discussion regarding the use of the master
password in bug 309807 [Integrate Password Manager with Gnome Keyring
Manager]. That didn't really reach a conclusion except for the fact that
the current password manager could probably use some improvements in
general; somebody even suggested to replace it entirely with the system
key-ring where available.

From my POV I'd like to see the master-password go because it's clunky
and doesn't really offer much protection but I'd also like to see
something more secure and more modern take its place. Secure and easily
accessible password storage is a sorely missing feature IMHO.

Gabriele

[Ed Morley]

On 10 October 2013 10:22:13, Michael Lefevre wrote:
> I wouldn't disagree with any of the other reasons, but could you
> clarify what you mean when you say the cryptography is useless?
> FireMaster seems to just brute force passwords. Are you just saying
> that any cryptography that relies on a password is useless, or that
> something is more broken than that?

Things like https://bugzilla.mozilla.org/show_bug.cgi?id=524403 mean
that brute force attacks take much less time than they ought (compared
to if we were we using a higher iteration count).

On 09/10/2013 22:35, Botond Ballo wrote:
> I use master password. Is there something I can use instead that's
> more secure?

I'd take a look at something like one of these:
https://lastpass.com/
http://keepass.info/
https://agilebits.com/onepassword

Best wishes,

Ed

[Gabriele Svelto]

On 10/10/2013 02:36, Zack Weinberg wrote:
> In that vein, I think we should take a hard look at the image decoders.
> Not only is that a significant chunk of attack surface, it is a place
> where it's hard to innovate; image format after image format has died on
> the vine because it wasn't *enough* of an improvement to justify the
> additional glob of compiled code. Web-deliverable JS image decoders
> could open that up.

Considering the performance profile of some of our low-end platforms
(most Firefox OS devices, low-end Android devices too) I don't think
that would be a good idea right now. Image decoding speed has a very
measurable impact there during page/application startup. The difference
between vectorized code-paths (NEON on ARM) and plain C is quite
significant so moving it to JS (even asm.js-enabled JS) would probably
lead to pretty bad performance regressions.

Gabriele

[Gervase Markham]

On 10/10/13 00:28, Philipp Kewisch wrote:
> So you are saying, we should start removing features that could decrease
> the attack surface?

...and that we don't need.

What I'm saying is: perhaps feature-ectomies (and driving the web or our
code to a position where we can make them) may be higher priority than
we thought. Unused but enabled code is not cost-free.

Gerv

[Till Schneidereit]

On Thu, Oct 10, 2013 at 12:00 PM, Gabriele Svelto <gsv...@mozilla.com> wrote:
> On 10/10/2013 02:36, Zack Weinberg wrote:
>>

>> In that vein, I think we should take a hard look at the image decoders.
>> Not only is that a significant chunk of attack surface, it is a place
>> where it's hard to innovate; image format after image format has died on
>> the vine because it wasn't *enough* of an improvement to justify the
>> additional glob of compiled code. Web-deliverable JS image decoders
>> could open that up.
>
>

> Considering the performance profile of some of our low-end platforms (most
> Firefox OS devices, low-end Android devices too) I don't think that would be
> a good idea right now. Image decoding speed has a very measurable impact
> there during page/application startup. The difference between vectorized
> code-paths (NEON on ARM) and plain C is quite significant so moving it to JS
> (even asm.js-enabled JS) would probably lead to pretty bad performance
> regressions.

Note that we'll have SIMD support in JS in the not-too-distant
future[1]. Once asm.js supports it, this idea might be more practical.

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

[Axel Hecht]

I agree with the sentiment, but not on the eample.

Having been a peer of the XSLT module back in the days, we started with
a rather js DOM like implementation, and moved over to a pure nsIContent
etc impl, and each step there won us an order of magnitude in perf.

I don't think that XSLT is a good candidate for implementing it in JS.

Axel

[Jeff Walden]

On 10/10/2013 02:27 PM, Axel Hecht wrote:
> I agree with the sentiment, but not on the eample.
>
> Having been a peer of the XSLT module back in the days, we started with a rather js DOM like implementation, and moved over to a pure nsIContent etc impl, and each step there won us an order of magnitude in perf.

But do we actually care about the perf of sites that use XSLT now, as long as perf isn't completely abysmal? A utility company showing billing statements, I think we can slow down without feeling guilty. But if, say, Google Maps or whichever used XSLT (I seem to remember *something* Google used it, forcing Presto to implement XSLT, back in the day -- maybe they've switched now, blink thread might say if I checked it), we might care.

Jeff

[Ehsan Akhgari]

On 2013-10-09 11:18 PM, Nicholas Nethercote wrote:
>>>> * XSLT
>>
>> We also use it for about:memory apparently.
>
> We do? Can you show me where?

Sorry, my bad, I meant to say addons manager:
<http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/content/updateinfo.xsl?force=1>

[Jason Orendorff]

On 10/10/13 2:54 AM, Chris Peterson wrote:
> The meta bug for removing JSD is bug 800200. I believe the primary
> blocking issue is bug 716647 ("allow Debugger to be enabled with
> debuggee frames on the stack"), which jorendorff is starting to work on.

Well, I tried it a year and a half ago. jandem and jimb are working on
it now though (see the dependency tree).

-j

[Mark Banner]

Maybe not quite platform features, but on the subject of removing or js
replacements, I offer up a couple of candidates:

http://mxr.mozilla.org/comm-central/source/mozilla/xpfe/components/directory/

I believe this is an rdf datasource for listing ftp directory pages.
AFAIK this might only be used by SeaMonkey now, so could be moved out.

http://mxr.mozilla.org/comm-central/source/mozilla/xpfe/components/windowds/

This appears only used in a couple of places, but I don't know enough
about it to fully make an assessment, but its pretty old code and rdf
based as well.

Mark.

[Axel Hecht]

My point is, the perf was completely abysmal, and the key is to use
nsINodeInfo for the xpath patterns instead of DOM localName and
namespaceURI string comparisons. There's also a benefit from using the
low-level atom-nsID-based content creation APIs.

Axel

[James Graham]

Nevertheless it seems worth trying — at least in an experimental way —
in case performance improvements of js and DOM APIs in the interim have
made the difference small enough not to matter. If they haven't, that's
interesting data on its own.

It may also be sufficient to adopt a presto-like XSLT implementation
where (iirc; I haven't tested and don't remember too well) you just
construct a string and feed it back through the HTML parser rather than
trying to work on the output tree directly.

[Boris Zbarsky]

On 10/10/13 10:28 AM, Axel Hecht wrote:
> My point is, the perf was completely abysmal, and the key is to use
> nsINodeInfo for the xpath patterns instead of DOM localName and
> namespaceURI string comparisons.

This may still be an issue, though I wouldn't be surprised if the speed
of .localName in JS nowadays (about 40ns on modern hardware, looks
like[1]) is faster than the XPCOM GetLocalName was back in the day.
That says nothing about speed of the string compares, of course...

-Boris

[1] Testcase, but you'll have to disable the CSE/loop-hoisting
optimization we have for .localName to get useful numbers out:

<!DOCTYPE html>
<script>
var div = document.createElement("div");
var span = document.createElement("span");
var count = 1000000;
var start = new Date;
for (var i = 0; i < count; ++i) {
// Switch back and forth between two elements to defeat
// the external string cache
div.localName;
span.localName;
}
var stop = new Date;
alert((stop - start) / count * 1e6);
</script>

For scale, on the same hardware I get about 40ns per get in a modern
nightly and 3600ns per get in Firefox 2. Times have changed a bit since
then.

[Brian Smith]

On Thu, Oct 10, 2013 at 3:43 AM, Till Schneidereit
<ti...@tillschneidereit.net> wrote:
> On Thu, Oct 10, 2013 at 12:00 PM, Gabriele Svelto <gsv...@mozilla.com> wrote:
>> On 10/10/2013 02:36, Zack Weinberg wrote:
>>>

>>> In that vein, I think we should take a hard look at the image decoders.
>>> Not only is that a significant chunk of attack surface, it is a place
>>> where it's hard to innovate; image format after image format has died on
>>> the vine because it wasn't *enough* of an improvement to justify the
>>> additional glob of compiled code. Web-deliverable JS image decoders
>>> could open that up.
>>
>>

>> Considering the performance profile of some of our low-end platforms (most
>> Firefox OS devices, low-end Android devices too) I don't think that would be
>> a good idea right now. Image decoding speed has a very measurable impact
>> there during page/application startup. The difference between vectorized
>> code-paths (NEON on ARM) and plain C is quite significant so moving it to JS
>> (even asm.js-enabled JS) would probably lead to pretty bad performance
>> regressions.
>
> Note that we'll have SIMD support in JS in the not-too-distant
> future[1]. Once asm.js supports it, this idea might be more practical.
>
> [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=904913

I'm not sure. Things like this seem like really good ideas:
http://blogs.msdn.com/b/ie/archive/2013/09/12/using-hardware-to-decode-and-load-jpg-images-up-to-45-faster-in-internet-explorer-11.aspx

Obviously, I am linking to somewhat of an advertisement of a
competitor but the idea sounds great, especially the bit about
significantly lower memory usage.

Cheers,
Brian
--
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

[Till Schneidereit]

On Thu, Oct 10, 2013 at 6:56 PM, Brian Smith <br...@briansmith.org> wrote:
> I'm not sure. Things like this seem like really good ideas:
> http://blogs.msdn.com/b/ie/archive/2013/09/12/using-hardware-to-decode-and-load-jpg-images-up-to-45-faster-in-internet-explorer-11.aspx
>
> Obviously, I am linking to somewhat of an advertisement of a
> competitor but the idea sounds great, especially the bit about
> significantly lower memory usage.

I agree, that's certainly something worth looking into*. It might not
necessarily mean that we can't implement decoding of some
less-frequently used media format in JS. Maybe even with parts of it
running in hardware**:
https://brendaneich.com/2013/05/today-i-saw-the-future/

*and for all I know, people might already be doing just that
** I really like how MS is pushing the concept of only the GPU being
hardware, as opposed to the CPU, which apparently is not

[Steve Fink]

On Thu 10 Oct 2013 10:07:53 AM PDT, Till Schneidereit wrote:
> On Thu, Oct 10, 2013 at 6:56 PM, Brian Smith <br...@briansmith.org> wrote:
>> I'm not sure. Things like this seem like really good ideas:
>> http://blogs.msdn.com/b/ie/archive/2013/09/12/using-hardware-to-decode-and-load-jpg-images-up-to-45-faster-in-internet-explorer-11.aspx
>>
>> Obviously, I am linking to somewhat of an advertisement of a
>> competitor but the idea sounds great, especially the bit about
>> significantly lower memory usage.
>
> I agree, that's certainly something worth looking into*. It might not
> necessarily mean that we can't implement decoding of some
> less-frequently used media format in JS. Maybe even with parts of it
> running in hardware**:
> https://brendaneich.com/2013/05/today-i-saw-the-future/

It seems like the optimal efficiency vs surface exposure vs frequency
of use tradeoff would be to do everything but the top formats (JPG,
PNG, GIF?) in JS. Then for the top three, try to do a hybrid
implementation where all of the core bit-slinging is done with
C/SIMD/GPU/quantum entangled cesium ions, but all of metadata and other
bits are done in JS. I don't know how awkward that is, but it just
seems like in general it's fine to do custom hyperoptimized code as
long as we're aware that we have to be very, very careful about
security vulnerabilities in it, and use a safe language for everything
else.

I don't know how messy that would be, though.

[Zack Weinberg]

On 2013-10-10 12:56 PM, Brian Smith wrote:
> On Thu, Oct 10, 2013 at 3:43 AM, Till Schneidereit
> <ti...@tillschneidereit.net> wrote:
>> On Thu, Oct 10, 2013 at 12:00 PM, Gabriele Svelto <gsv...@mozilla.com> wrote:
>>> On 10/10/2013 02:36, Zack Weinberg wrote:
>>>>
>>>> In that vein, I think we should take a hard look at the image decoders.

...

>>> Considering the performance profile of some of our low-end platforms (most
>>> Firefox OS devices, low-end Android devices too) I don't think that would be
>>> a good idea right now.

...

>> Note that we'll have SIMD support in JS in the not-too-distant
>> future[1].

...

> Things like this seem like really good ideas:
> http://blogs.msdn.com/b/ie/archive/2013/09/12/using-hardware-to-decode-and-load-jpg-images-up-to-45-faster-in-internet-explorer-11.aspx

To whatever extent we can't match C or even hand-tuned assembly
performance for image decoding with JS (using whatever combination of
JIT, explicit SIMD coding, explicit GPU shader coding, etc. is
necessary), I kinda think that points at a gap in "the Web platform"
that we should fix - maybe not today, or tomorrow, but soon. We are,
after all, pushing JS as the One True Virtual Machine for everything;
anytime _we_ have to drop down to compiled language for something,
that's a place where someone else might also find that JS did not meet
their needs.

This argument applies equally to XSLT, forms, editor, etc. as being
discussed elsewhere, although I imagine the solutions would be different
in each case :)

zw

[Henri Sivonen]

On Wed, Oct 9, 2013 at 7:01 PM, Gervase Markham <ge...@mozilla.org> wrote:
> * XSLT (Chrome have already announced they will remove it:

They said they'd remove H.264, too. I'm not a fan of XSLT, but we
shouldn't be the first one to remove it. I once had to fix a bug,
because XSLT was being used in Chrome Experiments demos and we were
failing at their shiny XSLT-dependent demos...

Implementing XSLT 1.0 in JS and changing the architecture to be
theoretically less pure than our current one but the same architecture
that other browsers have (having the XSLT engine serialize the tree
and then feed the serialization to the HTML parser) might be a way to
reduce attack surface, though. (Beware of accidentally upgrading to
XSLT 2.x when looking for existing JS implementation, though!)

--
Henri Sivonen
hsiv...@hsivonen.fi
http://hsivonen.iki.fi/

[David Rajchenbach-Teller]

I'd be happy if we could progressively kill FileUtils.jsm and make
nsIFile [noscript]. Don't know if this qualifies as "platform feature",
though.

Cheers,
David

[Axel Hecht]

Both are heavily used in the js build system for gaia, fwiw.

Axel

[David Rajchenbach-Teller]

I'd be happy to mentor someone to rewrite them using OS.File.

On 10/11/13 3:28 PM, Axel Hecht wrote:
> Both are heavily used in the js build system for gaia, fwiw.
>
> Axel

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform


--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla

[Bobby Holley]

On Fri, Oct 11, 2013 at 2:47 PM, David Rajchenbach-Teller
<dte...@mozilla.com> wrote:
> I'd be happy if we could progressively kill FileUtils.jsm and make
> nsIFile [noscript]. Don't know if this qualifies as "platform feature",
> though.

Given that this is privileged functionality and not web-exposed, I
don't think it qualifies as something that would reduce attack
surface.

bholley

[Ralph Giles]

On 2013-10-10 12:28 PM, Steve Fink wrote:

> It seems like the optimal efficiency vs surface exposure vs frequency
> of use tradeoff would be to do everything but the top formats (JPG,
> PNG, GIF?) in JS.

That's what we do today. We support those three image formats with
native code, and others can be supported by a js implementation, which
anyone can write. Unless you mean we should maintain a js library
supporting other formats?

> Then for the top three, try to do a hybrid implementation where all
> of the core bit-slinging is done with C/SIMD/GPU/quantum entangled
> cesium ions, but all of metadata and other bits are done in JS.

That sounds awkward to me. You're right that we have to be very careful
with native parsers, and we are, but formats popular enough to adopt
into the platform generally have widely-tested native implementations.

Some things, like scaling and colourspace conversion can already be done
with WebGL though, so the platform is making progress in this direction,
which is helpful for minority formats.

-r

[Zack Weinberg]

On 2013-10-11 1:08 PM, Ralph Giles wrote:
> On 2013-10-10 12:28 PM, Steve Fink wrote:
>
>> It seems like the optimal efficiency vs surface exposure vs frequency
>> of use tradeoff would be to do everything but the top formats (JPG,
>> PNG, GIF?) in JS.
>
> That's what we do today. We support those three image formats with
> native code, and others can be supported by a js implementation, which
> anyone can write.

*Can* anyone, though? Concretely, one would like to be able to write

<!doctype html>
<script src="//cdn.provider.com/mysite/s/libtiff.js"></script>
<img src="//cdn.provider.com/mysite/2002/02/20/giant-map.tiff">

Those are cross-domain references for both the script and the image,
just to be clear. Potential problems include:

- Getting the content of the image file
- Not triggering repeated downloads of the same image
- Informing layout of the dimensions of the image
- Acquiring a drawing context
- Integrating properly with repaint, such that we get all the nice
decode-on-draw, cache-and-discard-pixels optimizations
- Ensuring that we don't introduce cross-domain data leaks in
the process of enabling the above

I am fairly sure that this is *not* possible right now in full
generality; I think the best you can do from page script is issue an XHR
for the image data (so it probably gets retrieved twice, and won't work
cross-domain) and then manually replace the <img> with a <canvas> (and
do your own caching and memory management).

zw

[Boris Zbarsky]

On 10/11/13 7:42 PM, Zack Weinberg wrote:
> On 2013-10-11 1:08 PM, Ralph Giles wrote:
>> On 2013-10-10 12:28 PM, Steve Fink wrote:
>>
>>> It seems like the optimal efficiency vs surface exposure vs frequency
>>> of use tradeoff would be to do everything but the top formats (JPG,
>>> PNG, GIF?) in JS.
>>
>> That's what we do today. We support those three image formats with
>> native code, and others can be supported by a js implementation, which
>> anyone can write.
>
> *Can* anyone, though?

From an extension, to be clear.

As in, an extension can implement an image decoder for a new image
format, and imagelib will use it. All the rest of the image-loading
stuff will work as it already does and be handled by Gecko.

Doing that sort of thing from untrusted script is obviously a different
question altogether...

-Boris

[Kyle Huey]

Are you sure? I thought we killed pluggable decoders a while back.

- Kyle

> ______________________________**_________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/**listinfo/dev-platform<https://lists.mozilla.org/listinfo/dev-platform>
>

[Boris Zbarsky]

On 10/11/13 10:23 PM, Kyle Huey wrote:
> Are you sure? I thought we killed pluggable decoders a while back.

Hmm. I didn't realize that. In that case, I'm not sure. :(

-Boris

[Mike Hommey]

On Fri, Oct 11, 2013 at 10:23:20PM -0400, Kyle Huey wrote:
> Are you sure? I thought we killed pluggable decoders a while back.

Indeed. https://bugzilla.mozilla.org/show_bug.cgi?id=513681#c7

Mike

[alta88[nntp]]

---On 10/09/2013 05:30 PM, Jim Porter wrote:
> On 10/09/2013 12:37 PM, Chris Peterson wrote:

>> On 10/9/13 9:49 AM, Benjamin Smedberg wrote:
>>>>> In the spirit of learning from this, what's next on the chopping
>>>>> block?
>>>>

>>>> RDF
>>> I'm all for this, although the risk is probably quite small because we
>>> don't expose RDF to content.
>>
>> Bug 833098 - Kick RDF out of Firefox
>>
>> Comments in the bug suggest a build-time flag because Thunderbird needs
>> on RDF.
>
> Thunderbird doesn't really want RDF either. However, killing RDF in
> Thunderbird has been a slow process. If there's anyone who wants to help
> kill RDF in Thunderbird, go for it!
>
> - Jim

An attempt to remove a piece was thwarted here:
https://bugzilla.mozilla.org/show_bug.cgi?id=796234#c22

And while the goals of that patch were implemented elsewhere, Tb is
still building the unused rdf file, due to shared code:
https://bugzilla.mozilla.org/show_bug.cgi?id=797412

Expecting someone to come in and do this sort of maintenance coding,
into an environment without product management or drivers, and a
governance structure that prevents such, or even the possibility of a
timely review, I believe is wishful thinking. Tb's problems are best
evidenced by the patch (of any kind) rate submission over the last year,
since its 'decommissioning'.

[Anne van Kesteren]

On Sat, Oct 12, 2013 at 1:48 AM, Boris Zbarsky <bzba...@mit.edu> wrote:
> From an extension, to be clear.
>
> As in, an extension can implement an image decoder for a new image format,
> and imagelib will use it. All the rest of the image-loading stuff will work
> as it already does and be handled by Gecko.
>
> Doing that sort of thing from untrusted script is obviously a different
> question altogether...

We have to start thinking about it though. That's the direction we're
heading. Have everything be pluggable and implementable from untrusted
content. Maybe an isolated worker that can do image processing and
communicate a bitmap that might be tainted?

The idea behind http://extensiblewebmanifesto.org/ is pretty much
this. How you'd go about implementing <img> as web developer.


--
http://annevankesteren.nl/

[Robert O'Callahan]

On Sun, Oct 13, 2013 at 5:32 AM, Anne van Kesteren <ann...@annevk.nl> wrote:

> We have to start thinking about it though. That's the direction we're
> heading. Have everything be pluggable and implementable from untrusted
> content. Maybe an isolated worker that can do image processing and
> communicate a bitmap that might be tainted?
>

This is really tricky if you want the decoder to be able to handle
non-same-origin images. The problem is that although we can isolate the
worker at the API level, it's going to be almost impossible to prevent it
from leaking information back to its origin via timing channels.

If we restrict the decoder to only handling images with the same origin as
the decoder (or public via CORS), things are much better. I'd still want a
good level of isolation to prevent untrusted code from being easily able to
observe (and come to depend on) when/how often image decoding happens.

Rob
--
Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa
stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr,
'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp
waanndt wyeonut thoo mken.o w *
*

[Eric Shepherd]

On 2013-10-09 16:01:58 +0000, Gervase Markham said:

> In the spirit of learning from this, what's next on the chopping block?

As always, when filing bugs proposing removal of features from Mozilla
code (just like when adding them), please add dev-doc-needed if there
are any dev-facing changes possible as a result of the removal. Don't
be shy, and don't wait until the change lands!

--
Eric Shepherd
Developer Documentation Lead
Mozilla
Blog: http://www.bitstampede.com/
Twitter: @sheppy

[Henri Sivonen]

On Wed, Oct 9, 2013 at 7:01 PM, Gervase Markham <ge...@mozilla.org> wrote:

> A quick survey of the security-group led to the following suggestions,
> and I'm sure there are more:

* Character encoding detectors that are not enabled by default for
any locale (bugs are already on file).

* Multi-byte character encoding converters for encodings that are not
in the Encoding Standard (if we still have some of these in the tree;
I didn't check).

--
Henri Sivonen
hsiv...@hsivonen.fi
http://hsivonen.fi/