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
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 that a
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?
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 would
On 4/10/15 2:09 PM, Seth Fowler wrote:
On Apr 10, 2015, at 8:46 AM, Ehsan Akhgari ehsan.akhg...@gmail.com 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;
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 new
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 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
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 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]
-
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
On Mon, Apr 13, 2015 at 10:40 AM, DDD david.a.p.ll...@gmail.com 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
On Mon, Apr 13, 2015 at 12:11 PM, Gervase Markham g...@mozilla.org 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
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,
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
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
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
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
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.
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
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
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
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 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
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
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 less
Richard,
Le 13 avr. 2015 à 23:57, Richard Barnes rbar...@mozilla.com 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
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 Mon, Apr 13, 2015 at 3:53 PM, Eugene imfasterthanneutr...@gmail.com 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).
* 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
* 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 pile
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 support,
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,
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 HTTP.
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
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 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 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
Lambda
On Mon, Apr 13, 2015 at 3:00 PM, Frederik Braun fbr...@mozilla.com 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
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
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
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
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
43 matches
Mail list logo
