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
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
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
---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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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),
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
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
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
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;
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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.
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
60 matches
Mail list logo
