HTML sanitization, CSP, nsIContentPolicy, ServiceWorkers (was: Re: How to efficiently walk the DOM tree and its strings)
On 03/05/2014 01:52 AM, nsm.nik...@gmail.com wrote: On Tuesday, March 4, 2014 1:26:15 AM UTC-8, somb...@gmail.com wrote: While we have a defense-in-depth strategy (CSP and iframe sandbox should be protecting us from the worst possible scenarios) and we're hopeful that Service Workers will eventually let us provide nsIContentPolicy-level protection, the quality of the HTML parser is of course fairly important[1] to the operation of the HTML sanitizer. Sorry to go off-topic, but how are ServiceWorkers different from normal Workers here? I'm asking without context, so forgive me if I misunderstood. Context in short: Thunderbird does not use an HTML sanitizer in the default case when displaying HTML emails because it can turn off JavaScript execution, network accesses, and other stuff via nsIContentPolicy. iframe sandboxes let the Gaia email app which runs in content turn off JavaScript but do nothing to stop remote image fetches/etc. We want to be able to stop network fetches by for both bandwidth reasons and privacy reasons. I am referring to the dream of being able to skip sanitization and instead just enforce greater control over the iframe through either use of CSP or ServiceWorkers. ServiceWorker's onfetch capability doesn't actually work for this purpose because of the origin restrictions, but the mooted allowConnectionsTo CSP 1.1 API Alex Russell's blog post http://infrequently.org/2013/05/use-case-zero/ (about CSP and an early NavigationController/ServiceWorker proposal) would have been perfect. In the event CSP grew an API like that again in the future, I assume ServiceWorker is where it would end up. It doesn't seem super likely since it seems like CSP 1.1 generally covers the required use-cases. If we are (eventually) able to specify a more strict CSP on an iframe than the CSP in which the e-mail app already lives, we may able to use img-src/media-src/etc. for our fairly simple stop this iframe from accessing any resources control purposes. More context is available at the https://groups.google.com/d/msg/mozilla.dev.webapi/wDFM_T9v7Tc/_yTofMrjBk4J thread. Andrew ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Column numbers appended to URLs recently
On 2014-03-03, at 18:54, Jan Honza Odvarko odva...@gmail.com wrote: URLs in stack traces for exception objects have been recently changed. There is a column number appended at the end (I am seeing this in Nightly, but it could be also in Aurora). For my gratification, why is this information not also provided as an object? This demonstrates just how brittle it is to rely on string formats. Java once only provided access to stack traces in string form. They fixed that by adding a new accessor for the stack trace that was structured. We should too. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Consensus sought - when to reset try repository?
On 05 March 2014 06:07:28, Gregory Szorc wrote: I wouldn't have such a big issue with Try resets if we didn't lose information in the process. I believe every time there's been a Try reset, I've lost data from a recent (1 week) Try push and I needed to re-run that job Whilst it doesn't help with being able to refer to the diff, fwiw bug 721152 means that TBPL now supports accessing the results of a Try run even after repo-reset, so long as you use the single-revision URL form that appears in the thank you for your try push email. Note that TBPL data is purged for all trees after 30 days (in line with when the logs are purged from ftp.m.o). Ed ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Column numbers appended to URLs recently
On Tuesday, March 4, 2014 10:33:47 PM UTC+1, Jason Orendorff wrote: On 3/3/14, 12:54 PM, Jan Honza Odvarko wrote: URLs in stack traces for exception objects have been recently changed. There is a column number appended at the end (I am seeing this in Nightly, but it could be also in Aurora). Code that parses error.stack now needs to handle the case where both a line number and a column number appear after the URL. This should be easy to fix. What's affected? Just Firebug? Firebug yes. I don't know about other places. Honza ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Column numbers appended to URLs recently
On 3/5/14 3:50 AM, Martin Thomson wrote: For my gratification, why is this information not also provided as an object? It is, for XPConnect/DOM exceptions. Just not for built-in JS ones... -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
u me
My wife will never, let it happen... ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: u me
On 03/05/2014 11:42 AM, Ronnie McCutcheon wrote: My wife will never, let it happen... Whatever happened to... https://blog.mozilla.org/it/2012/10/24/future-of-discussion-forums/ https://blog.mozilla.org/it/2012/12/02/discussion-forums-redux-paths-forward/ I'm all for moving forward with option #4. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: u me
On 3/5/14 12:10 PM, WaltS wrote: I'm all for moving forward with option #4. As long as #4 will have a way to subscribe to a list and get in the right mail folder the old mails as well, correctly threaded with new ones, sounds good. The problem is, doing that with SMTP is rocket science. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
