Re: Intent to deprecate: Insecure HTTP

On Thu, Apr 16, 2015 at 8:16 AM, wrote: > > > I think that you should avoid making this an exercise in marketing > Mozilla's "Let's Encrypt" initiative. > > > > Perhaps that's why Richard took the time to make a comprehensive list of > > all known sources of free certs, rather than just mentionin

Re: Intent to deprecate: Insecure HTTP

Hey Katelyn, Thanks for bringing up these considerations. On Thu, Apr 16, 2015 at 5:35 AM, Katelyn Gadd wrote: > I expressed my opinion on this subject at length on the Chrome lists > when they made a similar proposal. I'll summarize it here, though, > since I feel the same way about FF depreca

Re: Can we make try builds default to a different profile than Nightly/Aurora/Beta/Release builds?

On Wed, 8 Apr 2015 20:40:12 -0700, Nicholas Alexander wrote: > On Wed, Apr 8, 2015 at 4:06 PM, Mike Hommey wrote: > >> If >> running nightly screws up profiles for older versions, that's a serious >> problem imho. >> > > Really? Presumably not every forward DB migration can be reverted without >

Re: Intent to deprecate: Insecure HTTP

> > You're pretty far off in the weeds here. I'll try to help you with some > of your misconceptions. > I pretty much knew I was. Good luck with the project, I'm looking forward to at least no-passive attack encryption being on-by-default... I hope that you don't get abducted by people in

Reminder: Tree Closing Window, Sat April 18, 0600-1800 PT

tracker bug with details: https://bugzil.la/1151645 status at: https://treestatus.mozilla.org/ for trees status at: https://whistlepig.mozilla.org/en-US/detail/302/ for event IT will be performing maintenance work this Saturday. The work is expected to be invasive, and we will close the trees fo

Re: Intent to deprecate: Insecure HTTP

On Wed, Apr 15, 2015 at 9:13 PM, Karl Dubost wrote: > As Robert is saying: > > Le 16 avr. 2015 à 00:29, Robert Kaiser a écrit : > > I think we need to think very hard about what reasons people have to > still not use TLS and how we can help them to do so. > > Definitely. > The resistance in this

Re: New Developer Tools Feature: prettifying JSON

On Thu, Apr 16, 2015 at 4:36 PM, Boris Zbarsky wrote: > On 4/16/15 4:37 AM, Jan Odvarko wrote: > >> We are obviously trying to avoid C++ code in devtools >> > > Sure. We can add scriptable APIs as needed. For example, we already have > one for adding anonymous content, right?. > Yes, and it's p

Re: New Developer Tools Feature: prettifying JSON

On 16/04/2015 15:30, Boris Zbarsky wrote: On 4/16/15 4:52 AM, Gijs Kruitbosch wrote: but that would still require that application/json loads as text in the browser, which I think it currently doesn't? Totally does ever since https://bugzilla.mozilla.org/show_bug.cgi?id=667533 (so about 3.5 ye

Re: Intent to deprecate: Insecure HTTP

On 4/16/15 07:16, david.a.p.ll...@gmail.com wrote: For example: - You say "there is only secure/not secure". Traditionally, we have things like defense in depth, and multiple levels of different sources of authentication. I am hearing: "You will either have a Let's Encrypt certificate or you

Re: New Developer Tools Feature: prettifying JSON

On 4/16/15 4:37 AM, Jan Odvarko wrote: We are obviously trying to avoid C++ code in devtools Sure. We can add scriptable APIs as needed. For example, we already have one for adding anonymous content, right?. Not sure if there is yet another way how to manipulate content with a script that

Re: New Developer Tools Feature: prettifying JSON

On 4/16/15 4:30 AM, Frederik Braun wrote: Running our code in someone else's origin sounds undesired indeed. Not only because of CSP: What if someone puts this in a frame (or a popup) and interacts with this JSON viewer? So the way the XML viewer handles this is basically the following: 1) It

Re: New Developer Tools Feature: prettifying JSON

On 4/16/15 4:52 AM, Gijs Kruitbosch wrote: but that would still require that application/json loads as text in the browser, which I think it currently doesn't? Totally does ever since https://bugzilla.mozilla.org/show_bug.cgi?id=667533 (so about 3.5 years ago). ;) -Boris _

Re: Intent to deprecate: Insecure HTTP

> > I think that you should avoid making this an exercise in marketing > > Mozilla's "Let's Encrypt" initiative. > > Perhaps that's why Richard took the time to make a comprehensive list of > all known sources of free certs, rather than just mentioning LE? Yeah, that's what I thought when I firs

Re: Intent to deprecate: Insecure HTTP

I expressed my opinion on this subject at length on the Chrome lists when they made a similar proposal. I'll summarize it here, though, since I feel the same way about FF deprecating non-encrypted HTTP: I think HTTPS-everywhere is a great ideal if we can achieve it, but in the vast majority of dis

Re: New Developer Tools Feature: prettifying JSON

On 16.04.2015 11:04, Jan Odvarko wrote: > On Thu, Apr 16, 2015 at 10:30 AM, Frederik Braun > wrote: > > > Running our code in someone else's origin sounds undesired indeed. Not > only because of CSP: What if someone puts this in a frame (or a popup) > and i

Re: New Developer Tools Feature: prettifying JSON

On Thu, Apr 16, 2015 at 10:30 AM, Frederik Braun wrote: > > Running our code in someone else's origin sounds undesired indeed. Not > only because of CSP: What if someone puts this in a frame (or a popup) > and interacts with this JSON viewer? Why iteration with a frame with the viewer could be a

Re: New Developer Tools Feature: prettifying JSON

On 16/04/2015 09:37, Jan Odvarko wrote: If not, can you take the same approach here? We are obviously trying to avoid C++ code in devtools, but also XUL/XBL in favor of pure JS/HTML/CSS stack. Not sure if there is yet another way how to manipulate content with a script that is living outside t

Re: Intent to deprecate: Insecure HTTP

On 16/04/15 02:13, Karl Dubost wrote: > Definitely. The resistance in this thread is NOT about "people > against security", but 1. we want to be able to choose 2. if we > choose safe, we want that choice to be easy to activate. I'd have it the other way. If you even assume choice should be possibl

Re: New Developer Tools Feature: prettifying JSON

Thanks for the link, looks interesting indeed! Honza On Thu, Apr 16, 2015 at 3:23 AM, Karl Dubost wrote: > Jan, > > Le 16 avr. 2015 à 01:54, Jan Odvarko a écrit : > > One of the new features we'd like to have in DevEdition 40 is related to > > JSON rendering. > > Prettifying JSON is a good idea

Re: New Developer Tools Feature: prettifying JSON

On Wed, Apr 15, 2015 at 8:01 PM, Boris Zbarsky wrote: > How does our XML prettyprinter manage this? I seem to recall it > force-loads an XBL binding that provides all the scriptability. Yes, there is XBL [1] that implements expand/collapse and XSLT [2] transforming the document. All wired toget

Re: New Developer Tools Feature: prettifying JSON

On 15.04.2015 18:54, Jan Odvarko wrote: > … > This approach has one security implication, if the page uses "default-src > 'none'" (or other security restrictions?) - injecting JS into it generates > warnings: "Content Security Policy: The page's settings blocked the loading > of a resource at self