On Tue, Apr 14, 2015 at 1:48 AM, wrote:
> - DANE for everyone
TLS through DNS is happening anytime soon, if ever:
http://sockpuppet.org/blog/2015/01/15/against-dnssec/
http://sockpuppet.org/stuff/dnssec-qa.html
https://www.imperialviolet.org/2015/01/17/notdane.html
--
https://annevanke
I'm planing to drop nsIDOMWindowUtils.sendKeyEvent() because:
* it's not aware of UI Events' (a.k.a DOM Level 3 Events) KeyboardEvent
* nsITextInputProcessor already has new API to synthesize KeyboardEvent
via widget
* I'm now working on rewriting all mochitests in bug 1134539
(https://bugzilla
On Tue, Apr 14, 2015 at 7:52 AM, Yoav Weiss wrote:
> Limiting new features does absolutely nothing in that aspect.
Hyperbole much? CTO of the New York Times cited HTTP/2 and Service
Workers as a reason to start deploying HTTPS:
http://open.blogs.nytimes.com/2014/11/13/embracing-https/
(And an
IMO, limiting new features to HTTPS only, when there's no real security
reason behind it will only end up limiting feature adoption.
It directly "punishing" developers and adds friction to using new features,
but only influence business in a very indirect manner.
If we want to move more people to
On Tuesday, April 14, 2015 at 1:16:25 AM UTC-4, vic wrote:
> On Monday, April 13, 2015 at 4:57:58 PM UTC+2, Richard Barnes wrote:
> > HTTP deprecation
>
> I'm strongly against the proposal as it is described here. I work with small
> embedded devices (think sensor network) that are accessed over
On Monday, April 13, 2015 at 4:57:58 PM UTC+2, Richard Barnes wrote:
> HTTP deprecation
I'm strongly against the proposal as it is described here. I work with small
embedded devices (think sensor network) that are accessed over HTTP. These
devices have very little memory, only a few kB, implemen
On Tuesday, April 14, 2015 at 12:27:22 AM UTC-4, commod...@gmail.com wrote:
> On Monday, April 13, 2015 at 1:43:25 PM UTC-7, byu...@gmail.com wrote:
> > Let 'em do this. When Mozilla and Google drop HTTP support, then it'll be
> > open season for someone to fork/make a new browser with HTTP suppor
On Monday, April 13, 2015 at 1:43:25 PM UTC-7, byu...@gmail.com wrote:
> Let 'em do this. When Mozilla and Google drop HTTP support, then it'll be
> open season for someone to fork/make a new browser with HTTP support, and
> gain an instant 30% market share.
Or, more likely, it'll be a chance for
On Monday, April 13, 2015 at 10:10:44 PM UTC-4, Karl Dubost wrote:
> Now the fact to have to rent your domain name ($$$) and that all the URIs are
> tied to this is in terms of permanent identifiers and the fabric of time on
> information has strong social consequences. But's that another debate
> * Less scary warnings about self-signed certificates (i.e. treat
> HTTPS+selfsigned like we do with HTTP now, and treat HTTP like we do with
> HTTPS+selfsigned now); the fact that self-signed HTTPS is treated as less
> secure than HTTP is - to put this as politely and gently as possible - a pi
Le 14 avr. 2015 à 10:43, imfasterthanneutr...@gmail.com a écrit :
> I don't think the current CA system is broken.
The current CA system creates issues for certain categories of population. It
is broken in some ways.
> The domain name registration is also centralized, but almost every website
On Monday, April 13, 2015 at 8:57:41 PM UTC-4, northrupt...@gmail.com wrote:
>
> * Less scary warnings about self-signed certificates (i.e. treat
> HTTPS+selfsigned like we do with HTTP now, and treat HTTP like we do with
> HTTPS+selfsigned now); the fact that self-signed HTTPS is treated as les
On Monday, April 13, 2015 at 7:57:58 AM UTC-7, Richard Barnes wrote:
> In order to encourage web developers to move from HTTP to HTTPS, I would
> like to propose establishing a deprecation plan for HTTP without security.
> Broadly speaking, this plan would entail limiting new features to secure
>
> * If we have to rely, cost of certificates must be zero. These for the simple
> reason than not everyone is living in a rich industrialized country.
Certificates (and paying for them) is an artificial economy. If I register a
DNS address, I should get a certificate to go with it. Heck, last
Richard,
Le 13 avr. 2015 à 23:57, Richard Barnes a écrit :
> There's pretty broad agreement that HTTPS is the way forward for the web.
Yes, but that doesn't make deprecation of HTTP a consensus.
> In order to encourage web developers to move from HTTP to HTTPS, I would
> like to propose establi
On Mon, Apr 13, 2015 at 3:53 PM, Eugene wrote:
> In addition to APIs, I'd like to propose prohibiting caching any resources
> loaded over insecure HTTP, regardless of Cache-Control header, in Phase 2.N.
This has some negative consequences (if only for performance). I'd
like to see changes like
I fully support this proposal. In addition to APIs, I'd like to propose
prohibiting caching any resources loaded over insecure HTTP, regardless of
Cache-Control header, in Phase 2.N. The reasons are:
1) MITM can pollute users' HTTP cache, by modifying some JavaScript files with
a long time cache
Late to the thread, but I'll use this reply to say we're very
supportive of the proposal at CDT.
On Mon, Apr 13, 2015 at 4:48 PM, wrote:
> I have given this a lot of thought lately, and to me the only way forward is
> to do exactly what is suggested here: phase out and eventually drop plain
>
On 4/13/15 5:11 PM, bryan.beic...@gmail.com wrote:
After loosing a few forum posts or wiki edits to this bug in Firefox, you
quickly insist on using unsecured HTTP as often as possible.
This is only done in cases in which the page explicitly requires that
nothing about the page be cached (no-
One limiting factor is that Firefox doesn't treat form data the same on HTTPS
sites.
Examples:
http://stackoverflow.com/questions/14420624/how-to-keep-changed-form-content-when-leaving-and-going-back-to-https-page-wor
http://stackoverflow.com/questions/10511581/why-are-html-forms-sometimes-clea
On 4/13/2015 3:29 PM, stu...@testtrack4.com wrote:
HTTP should remain optional and fully-functional, for the purposes of
prototyping and diagnostics. I shouldn't need to set up a TLS layer to access a
development server running on my local machine, or to debug which point before
hitting the TL
The argument for suggestion #1 seems irrefutable.
Rob
--
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao obor
On Monday, April 13, 2015 at 4:43:25 PM UTC-4, byu...@gmail.com wrote:
> These guys can go around thinking they're secure while trusting root CAs like
> CNNIC whilst ignoring DNSSEC and the like; the rest of us can get back on
> track with a new, sane browser. While we're at it, we could start t
I have given this a lot of thought lately, and to me the only way forward is to
do exactly what is suggested here: phase out and eventually drop plain HTTP
support. There are numerous reasons for doing this:
- Plain HTTP allows someone to snoop on your users.
- Plain HTTP allows someone to misr
On Monday, April 13, 2015 at 3:36:56 PM UTC-4, commod...@gmail.com wrote:
> Great, peachy, more authoritarian dictation of end-user behavior by the Elite
> is just what the Internet needs right now. And hey, screw anybody trying to
> use legacy systems for anything, right? Right!
Let 'em do this
HTTP should remain optional and fully-functional, for the purposes of
prototyping and diagnostics. I shouldn't need to set up a TLS layer to access a
development server running on my local machine, or to debug which point before
hitting the TLS layer is corrupting requests.
_
I would politely ask you how many users you think are
> both interested in, able to understand, and willing to take decisions
> based on _six_ different security states in a browser?
I think this thread is about deprecating things and moving developers onto more
secure platforms. To do that, yo
Great, peachy, more authoritarian dictation of end-user behavior by the Elite
is just what the Internet needs right now. And hey, screw anybody trying to use
legacy systems for anything, right? Right!
___
dev-platform mailing list
dev-platform@lists.moz
On Mon, Apr 13, 2015 at 12:11 PM, Gervase Markham wrote:
> Are you sure "privileged contexts" is the right phrase? Surely contexts
> are "secure", and APIs or content is "privileged" by being only
> available in a secure context?
There was a long-winded group bike-shed-painting session on the
pub
Summary: A property that makes it possible for web pages to tell which
element's scroll* attributes reflect the viewport scroll state. This is
needed because currently web pages have different codepaths (using
document.body vs document.documentElement) for different browsers based
on UA sniffi
On 13/04/15 18:40, DDD wrote:
> I think that you'll need to define a number of levels of security, and decide
> how to distinguish them in the Firefox GUI:
>
> - Unauthenticated/Unencrypted [http]
> - Unauthenticated/Encrypted [https ignoring untrusted cert warning]
> - DNS based auth/Encrypted
On 13/04/15 15:57, Richard Barnes wrote:
> Martin Thomson and I drafted a
> one-page outline of the plan with a few more considerations here:
>
> https://docs.google.com/document/d/1IGYl_rxnqEvzmdAP9AJQYY2i2Uy_sW-cg9QI9ICe-ww/edit?usp=sharing
Are you sure "privileged contexts" is the right phrase
On Mon, Apr 13, 2015 at 3:00 PM, Frederik Braun wrote:
> On 13.04.2015 20:52, david.a.p.ll...@gmail.com wrote:
> >
> >> 2) Protected by subresource integrity from a secure host
> >>
> >> This would allow website operators to securely serve static assets from
> non-HTTPS servers without MITM risk,
On 13.04.2015 20:52, david.a.p.ll...@gmail.com wrote:
>
>> 2) Protected by subresource integrity from a secure host
>>
>> This would allow website operators to securely serve static assets from
>> non-HTTPS servers without MITM risk, and without breaking transparent
>> caching proxies.
>
> Is t
On 4/10/15 4:26 PM, smaug wrote:
I'd say that is rather painful for reviewers, since both Move() (I
prefer .swap()) and lambda hide what is actually happening to the refcnt.
Wanna ban copy construction? ;)
Higher-level constructs inherently "hide" something, but I disagree they
make things ha
> 2) Protected by subresource integrity from a secure host
>
> This would allow website operators to securely serve static assets from
> non-HTTPS servers without MITM risk, and without breaking transparent caching
> proxies.
Is that a complicated word for SHA512 HASH? :) You could envisage a
> In order to encourage web developers to move from HTTP to HTTPS, I would
> like to propose establishing a deprecation plan for HTTP without security.
May I suggest defining "security" here as either:
1) A secure host (SSL)
or
2) Protected by subresource integrity from a secure host
This woul
>
> Note that Firefox does not presently support either DANE or DNSSEC,
> so we don't need to distinguish these.
>
> -Ekr
>
Nor does Chrome, and look what happened to both browsers...
http://www.zdnet.com/article/google-banishes-chinas-main-digital-certificate-authority-cnnic/
...the keys to
On 4/13/15 1:36 PM, Jan-Ivar Bruaroey wrote:
[2]
http://mxr.mozilla.org/mozilla-central/source/xpco/glue/nsThreadUtils.cpp?mark=164-168#164
working link I hope:
http://mxr.mozilla.org/mozilla-central/source/xpcom/glue/nsThreadUtils.cpp?mark=164-168#164
On Mon, Apr 13, 2015 at 10:40 AM, DDD wrote:
> I think that you'll need to define a number of levels of security, and
> decide how to distinguish them in the Firefox GUI:
>
> - Unauthenticated/Unencrypted [http]
> - Unauthenticated/Encrypted [https ignoring untrusted cert warning]
> - DNS based
On Mon, Apr 13, 2015 at 01:28:05PM -0400, Ehsan Akhgari wrote:
> On 2015-04-13 5:26 AM, Nicolas B. Pierron wrote:
> >On 04/10/2015 07:47 PM, Ehsan Akhgari wrote:
> >>On 2015-04-10 1:41 PM, Nicolas B. Pierron wrote:
> Also, what is the alternative? Acquiring a nsCOMPtr/nsRefPtr inside the
>
I think that you'll need to define a number of levels of security, and decide
how to distinguish them in the Firefox GUI:
- Unauthenticated/Unencrypted [http]
- Unauthenticated/Encrypted [https ignoring untrusted cert warning]
- DNS based auth/Encrypted[TLSA certificate hash in DNS]
- Ditto
On 4/10/15 2:09 PM, Seth Fowler wrote:
On Apr 10, 2015, at 8:46 AM, Ehsan Akhgari wrote:
I would like to propose that we should ban the usage of refcounted objects
inside lambdas in Gecko. Here is the reason:
Consider the following code:
nsINode* myNode;
TakeLambda([&]() {
myNode->Foo();
}
On 2015-04-13 5:26 AM, Nicolas B. Pierron wrote:
On 04/10/2015 07:47 PM, Ehsan Akhgari wrote:
On 2015-04-10 1:41 PM, Nicolas B. Pierron wrote:
Also, what is the alternative? Acquiring a nsCOMPtr/nsRefPtr inside the
Lambda constructor (or whatever it's called)?
Yes, another option would be to
Given that everyone else working in this area agrees that UTF-8 file
paths are the Right Thing and wants to desupport legacy encodings, I
would now vote for suggestion 1 (contra what I said last year in bug
960957, which amounts to a variation on your suggestion 2). However,
I think it might be a
There's pretty broad agreement that HTTPS is the way forward for the web.
In recent months, there have been statements from IETF [1], IAB [2], W3C
[3], and even the US Government [4] calling for universal use of
encryption, which in the case of the web means HTTPS.
In order to encourage web develo
On 04/10/2015 07:47 PM, Ehsan Akhgari wrote:
On 2015-04-10 1:41 PM, Nicolas B. Pierron wrote:
Also, what is the alternative? Acquiring a nsCOMPtr/nsRefPtr inside the
Lambda constructor (or whatever it's called)?
Yes, another option would be to ensure that the lambda cannot be used
after a spec
47 matches
Mail list logo
