On 16.04.2015 11:04, Jan Odvarko wrote:
On Thu, Apr 16, 2015 at 10:30 AM, Frederik Braun fbr...@mozilla.com
mailto:fbr...@mozilla.com 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)
On Wed, Apr 15, 2015 at 8:01 PM, Boris Zbarsky bzbar...@mit.edu 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.
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 possible
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
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
On Thu, Apr 16, 2015 at 10:30 AM, Frederik Braun fbr...@mozilla.com 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
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
Thanks for the link, looks interesting indeed!
Honza
On Thu, Apr 16, 2015 at 3:23 AM, Karl Dubost kdub...@mozilla.com wrote:
Jan,
Le 16 avr. 2015 à 01:54, Jan Odvarko odva...@gmail.com a écrit :
One of the new features we'd like to have in DevEdition 40 is related to
JSON rendering.
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 first posted
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
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
On Thu, Apr 16, 2015 at 4:36 PM, Boris Zbarsky bzbar...@mit.edu 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
On Wed, Apr 15, 2015 at 9:13 PM, Karl Dubost kdub...@mozilla.com wrote:
As Robert is saying:
Le 16 avr. 2015 à 00:29, Robert Kaiser ka...@kairo.at 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.
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
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)
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
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
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
Hey Katelyn,
Thanks for bringing up these considerations.
On Thu, Apr 16, 2015 at 5:35 AM, Katelyn Gadd k...@luminance.org 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
On Thu, Apr 16, 2015 at 8:16 AM, david.a.p.ll...@gmail.com 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
On Wed, 8 Apr 2015 20:40:12 -0700, Nicholas Alexander wrote:
On Wed, Apr 8, 2015 at 4:06 PM, Mike Hommey m...@glandium.org 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
21 matches
Mail list logo
