Re: What platform features can we kill?
On Wed, Oct 9, 2013 at 7:01 PM, Gervase Markham g...@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 hsivo...@hsivonen.fi http://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On Sat, Oct 12, 2013 at 1:48 AM, Boris Zbarsky bzbar...@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/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On 2013-10-09 16:01:58 +, 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
---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'. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On Wed, Oct 9, 2013 at 7:01 PM, Gervase Markham g...@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 hsivo...@hsivonen.fi http://hsivonen.iki.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On 10/11/13 2:47 PM, David Rajchenbach-Teller 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. Cheers, David Both are heavily used in the js build system for gaia, fwiw. Axel ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
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-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On Fri, Oct 11, 2013 at 2:47 PM, David Rajchenbach-Teller dtel...@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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
Are you sure? I thought we killed pluggable decoders a while back. - Kyle On Fri, Oct 11, 2013 at 7:48 PM, Boris Zbarsky bzbar...@mit.edu wrote: 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 __**_ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/**listinfo/dev-platformhttps://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On 10/9/13 8:18 PM, Nicholas Nethercote wrote: On Wed, Oct 9, 2013 at 2:36 PM, Ehsan Akhgariehsan.akhg...@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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On Wed, Oct 9, 2013 at 6:01 PM, Gervase Markham g...@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/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Master Password (was Re: What platform features can we kill?)
On 09/10/2013 22:00, Brian Smith wrote: On Wed, Oct 9, 2013 at 9:01 AM, Gervase Markham g...@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. 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Master Password (was Re: What platform features can we kill?)
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Master Password (was Re: What platform features can we kill?)
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On Thu, Oct 10, 2013 at 12:00 PM, Gabriele Svelto gsve...@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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On 10/10/13 2:36 AM, Zack Weinberg wrote: 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 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
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. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On 10/10/13 2:43 PM, Jeff Walden wrote: 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 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On 10/10/13 15:28, Axel Hecht wrote: On 10/10/13 2:43 PM, Jeff Walden wrote: 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 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. 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. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
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 = 100;
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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On Thu, Oct 10, 2013 at 3:43 AM, Till Schneidereit t...@tillschneidereit.net wrote: On Thu, Oct 10, 2013 at 12:00 PM, Gabriele Svelto gsve...@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) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On 2013-10-10 12:56 PM, Brian Smith wrote: On Thu, Oct 10, 2013 at 3:43 AM, Till Schneidereit t...@tillschneidereit.net wrote: On Thu, Oct 10, 2013 at 12:00 PM, Gabriele Svelto gsve...@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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On Wed, Oct 9, 2013 at 9:01 AM, Gervase Markham g...@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) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
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 ;( ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
Gervase Markham wrote: * XSLT Doesn't the XML prettyprinter use XSLT? -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
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. -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On Wed, Oct 9, 2013 at 9:01 AM, Gervase Markham g...@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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
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. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On Wed, Oct 9, 2013 at 4:28 PM, Philipp Kewisch mozi...@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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On Wed, Oct 9, 2013 at 2:36 PM, Ehsan Akhgari ehsan.akhg...@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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
