Re: Intent to deprecate: Insecure HTTP

You're replying to a 4 year old thread. Don't do that: you're jumping over 4 years of other conversations, and tagged on the end of an old thread whatever arguments you're making will unseen by a lot of people depending on how their mail readers work. Your arguments about HTTPS overhead on poor

Re: Intent to deprecate: Insecure HTTP

On Monday, April 13, 2015 at 10:57:58 AM UTC-4, Richard Barnes wrote: > 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 >

Re: Intent to deprecate: Insecure HTTP

Steve Fink wrote: > On 12/20/2016 06:20 PM, Edmund Wong wrote: >> Richard Barnes wrote: >> >>> Broadly speaking, this plan would entail limiting new features to >>> secure >>> contexts, followed by gradually removing legacy features from insecure >>> contexts. Having an overall program for HTTP

Re: Intent to deprecate: Insecure HTTP

On 12/20/2016 06:20 PM, Edmund Wong wrote: Richard Barnes wrote: Broadly speaking, this plan would entail limiting new features to secure contexts, followed by gradually removing legacy features from insecure contexts. Having an overall program for HTTP deprecation makes a clear statement to

Re: Intent to deprecate: Insecure HTTP

Richard Barnes wrote: > 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. >

Re: Intent to deprecate: Insecure HTTP

On Tue, Dec 20, 2016 at 10:28 AM, Cody Wohlers wrote: > Absolutely! Let's Encrypt sounds awesome, super-easy, and the price is > right. > > But I'm thinking of cases like Lavabit where a judge forced the site > operator to release the private key. Or the opposite -

Re: Intent to deprecate: Insecure HTTP

Absolutely! Let's Encrypt sounds awesome, super-easy, and the price is right. But I'm thinking of cases like Lavabit where a judge forced the site operator to release the private key. Or the opposite - could a government restrict access to a site by forcing the CA to revoke certificates? I

Re: Intent to deprecate: Insecure HTTP

Can't people use Let's Encrypt to obtain a certificate for free without the usual CA run-around? https://letsencrypt.org/getting-started/ "Let’s Encrypt is a free, automated, and open certificate authority brought to you by the non-profit Internet Security Research Group (ISRG)." On Tue, Dec

Re: Intent to deprecate: Insecure HTTP

This is a good idea but a terrible implementation. I already need someone else's approval (registrar) to run a website (unless I want visitors to remember my IP addresses). NOW I will need ANOTHER someone to approve it as well (the CA authority), (unless I want visitors to click around a

Re: Intent to deprecate: Insecure HTTP

On Thu, May 7, 2015 at 12:43 AM, Adam Roach aro...@mozilla.com wrote: Which leaves us with a conundrum regarding your plea for more notice: it's a bit hard to seriously consider complaints that at some future date yet to be determined is too soon. ​My apologies. My reading of the

Re: Intent to deprecate: Insecure HTTP

On May 6, 2015, at 22:51, Eric Shepherd esheph...@mozilla.com wrote: would have been nice to have more notice The plan that has been outlined involves a staged approach, with new JavaScript features being withheld after some date, followed by a period during which select older JavaScript

Re: Intent to deprecate: Insecure HTTP

On 05/01/2015 01:50 PM, oli...@omattos.com wrote: When plans like this aren't rolled out across all browsers together, users inevitably come across a broken site and say Firefox works with this site, but Safari gives a warning. Safari must be broken. Better security is punished. Having this

Re: Intent to deprecate: Insecure HTTP

It's absolutely true for hosting yourself today. The only thing even slightly difficult is setting up dynamic dns. On Mon, May 4, 2015, at 06:01 AM, Gervase Markham wrote: On 01/05/15 19:02, Matthew Phillips wrote: You must have missed my original email: It's paramount that the web remain a

Re: Intent to deprecate: Insecure HTTP

On Wed, May 6, 2015 at 2:04 PM, Matthew Phillips matt...@matthewphillips.info wrote: It's absolutely true for hosting yourself today. The only thing even slightly difficult is setting up dynamic dns. And in a future where certificates are issued without cost over a protocol there's no reason

Re: Intent to deprecate: Insecure HTTP

Gervase Markham wrote: For this edge case, I would say the solution is to use a proxy, run on one of your other (faster) computers. As noted elsewhere, that's what jwz did to get Netscape 1.0 (which only spoke HTTP 1.0) working again. That's a reasonable solution for one-offs, but not really

Re: Intent to deprecate: Insecure HTTP

On 5/4/15 3:03 AM, Gervase Markham wrote: On 01/05/15 20:40, Eric Shepherd wrote: In my case, the situation is that I have classic computers running 1-10 megahertz processors, for which encrypting and decrypting SSL is not a plausible option. For this edge case, I would say the solution is to

Re: Intent to deprecate: Insecure HTTP

On Tue, May 5, 2015 at 12:03 AM, Daniel Holbert dholb...@mozilla.com wrote: Without getting too deep into the exact details about animation / notifications / permissions, it sounds like Florian's concern RE browsers want to disable fullscreen if you are not serving the website over HTTPS may

Re: Intent to deprecate: Insecure HTTP

On 2015-05-05 4:59 AM, sn...@arbor.net wrote: Encryption should be activated only after BOTH parties have mutually authenticated. Why establish an encrypted transport to an unknown attacker? A web you have to uniquely identify yourself to participate in is really not open or free for an awful

Re: Intent to deprecate: Insecure HTTP

The additional expense of HTTPS arises from the significantly higher cost to the service owner of protecting it against attack, to maintain service Availability (that third side of the security CIA triangle that gets forgotten). Encryption should be activated only after BOTH parties have

Re: Intent to deprecate: Insecure HTTP

On 01/05/15 19:02, Matthew Phillips wrote: You must have missed my original email: It's paramount that the web remain a frictionless place where creating a website is dead simple. That is not true today of people who want to run their own hosting. So people who want frictionless use

Re: Intent to deprecate: Insecure HTTP

On 03/05/15 03:39, Xidorn Quan wrote: This has been happening in the Internet in China. I would suggest you use 360 Secure Browser, one of the major browsers in China. They completely consider the experience of developers and users. Their browser allows user to access a website even if the

Re: Intent to deprecate: Insecure HTTP

On 01/05/15 20:40, Eric Shepherd wrote: In my case, the situation is that I have classic computers running 1-10 megahertz processors, for which encrypting and decrypting SSL is not a plausible option. For this edge case, I would say the solution is to use a proxy, run on one of your other

Re: Intent to deprecate: Insecure HTTP

On Mon, May 4, 2015 at 10:04 PM, Gervase Markham g...@mozilla.org wrote: On 03/05/15 03:39, Xidorn Quan wrote: This has been happening in the Internet in China. I would suggest you use 360 Secure Browser, one of the major browsers in China. They completely consider the experience of

Re: Intent to deprecate: Insecure HTTP

On Fri, May 1, 2015 at 1:25 AM, Richard Barnes rbar...@mozilla.com wrote: 3. HTTP caching is an important feature for constrained networks. I think it important to emphasize that the affected case is shared caching in the form of forward proxies. https doesn't prevent caching in the browser or

Re: Intent to deprecate: Insecure HTTP

On Sat, May 2, 2015 at 11:57 AM, Nicholas Nethercote n.netherc...@gmail.com wrote: Please refrain from further discussion until you can avoid making crude personal attacks such as these. I now mandate that you (and everyone you know) shall only do ethernet trough pigeon carriers. There are

Re: Intent to deprecate: Insecure HTTP

On 5/2/15 05:25, Florian Bösch wrote: I now mandate that you (and everyone you know) shall only do ethernet trough pigeon carriers. There are great advantages to doing this, and I can recommend a number of first rate pigeon breeders which will sell you pigeons bred for that purpose. I will not

Re: Intent to deprecate: Insecure HTTP

On 2015-05-04 8:37 AM, Henri Sivonen wrote: I think without empirical evidence showing the *current* (as opposed to arguments from 20 years ago) importance of shared caching on the supposed constrained networks--i.e. empirical evidence showing that the shared cache hit rate is is a

Re: Intent to deprecate: Insecure HTTP

On 5/4/15 11:24, Florian Bösch wrote: On Mon, May 4, 2015 at 3:38 PM, Adam Roach a...@mozilla.com mailto:a...@mozilla.com wrote: others who want to work for a better future A client of mine whom I polled if they can move to HTTPs with their server stated they do not have the time and

Re: Intent to deprecate: Insecure HTTP

On Mon, May 4, 2015 at 6:33 PM, Adam Roach a...@mozilla.com wrote: You have made some well-thought-out contributions to conversations at Mozilla in the past. I'm a little sad that you're choosing not to participate in a useful way here. I think this is a pretty relevant contribution.

Re: Intent to deprecate: Insecure HTTP

On Mon, May 4, 2015 at 3:38 PM, Adam Roach a...@mozilla.com wrote: others who want to work for a better future A client of mine whom I polled if they can move to HTTPs with their server stated they do not have the time and resources to do so. So the fullscreen button will just stop working.

Re: Intent to deprecate: Insecure HTTP

I agree HTTPS makes information safer and protects it¹s integrity, making it (once again) safer. However; 1) are the benefits worth the millions of man-hours, and countless dollars this will cost? 2) why is Mozilla suddenly everyone¹s nanny? - Shawn On 5/1/15, 2:44 PM, Joseph Lorenzo Hall

Re: Intent to deprecate: Insecure HTTP

On Mon, May 4, 2015 at 9:39 AM, Florian Bösch pya...@gmail.com wrote: On Mon, May 4, 2015 at 6:33 PM, Adam Roach a...@mozilla.com wrote: You have made some well-thought-out contributions to conversations at Mozilla in the past. I'm a little sad that you're choosing not to participate in

Re: Intent to deprecate: Insecure HTTP

On 05/04/2015 09:39 AM, Florian Bösch wrote: Here is what I wrote that client: [...] For security reasons browsers want to disable fullscreen if you are not serving the website over HTTPS. Are you sure this is true? Where has it been proposed to completely disable fullscreen for non-HTTPS

Re: Intent to deprecate: Insecure HTTP

On Mon, May 4, 2015 at 11:00 AM, Daniel Holbert dholb...@mozilla.com wrote: (I think there's a strong case for disabling *persistent* fullscreen permission, for the reasons described in ekr's response to you here. I haven't seen any proposal for going beyond that, but I might've missed it.) A

Re: Intent to deprecate: Insecure HTTP

On Mon, May 4, 2015 at 10:52 AM, Florian Bösch pya...@gmail.com wrote: On Mon, May 4, 2015 at 7:43 PM, Eric Rescorla e...@rtfm.com wrote: This would be more useful if you explained what they considered the cost of converting to HTTPS so, so we could discuss ways to ameliorate that cost. I

Re: Intent to deprecate: Insecure HTTP

On Mon, May 4, 2015 at 12:59 PM, Florian Bösch pya...@gmail.com wrote: On Mon, May 4, 2015 at 8:06 PM, Eric Rescorla e...@rtfm.com wrote: I'm going to refer you at this point to the W3C HTML design principles of priority of constituencies

Re: Intent to deprecate: Insecure HTTP

Great! Without getting too deep into the exact details about animation / notifications / permissions, it sounds like Florian's concern RE browsers want to disable fullscreen if you are not serving the website over HTTPS may be unfounded, then. (Unless Florian or Martin have some extra

Re: Intent to deprecate: Insecure HTTP

On Tue, May 5, 2015 at 6:04 AM, Martin Thomson m...@mozilla.com wrote: On Mon, May 4, 2015 at 11:00 AM, Daniel Holbert dholb...@mozilla.com wrote: (I think there's a strong case for disabling *persistent* fullscreen permission, for the reasons described in ekr's response to you here. I

Re: Intent to deprecate: Insecure HTTP

On Mon, May 4, 2015 at 8:06 PM, Eric Rescorla e...@rtfm.com wrote: I'm going to refer you at this point to the W3C HTML design principles of priority of constituencies (http://www.w3.org/TR/html-design-principles/#priority-of-constituencies). In case of conflict, consider users over authors

Re: Intent to deprecate: Insecure HTTP

We're adding UX to clearly indicate http:// or https:// in fullscreen while still meeting the user desire for secure one-click-to-fullscreen. The latest and greatest proposal posted here: https://bugzilla.mozilla.org/show_bug.cgi?id=1129061 --Jet On Mon, May 4, 2015 at 2:04 PM, Eric Rescorla

Re: Intent to deprecate: Insecure HTTP

On Mon, May 4, 2015 at 1:57 PM, Xidorn Quan quanxunz...@gmail.com wrote: On Tue, May 5, 2015 at 6:04 AM, Martin Thomson m...@mozilla.com wrote: On Mon, May 4, 2015 at 11:00 AM, Daniel Holbert dholb...@mozilla.com wrote: (I think there's a strong case for disabling *persistent* fullscreen

Re: Intent to deprecate: Insecure HTTP

Richard Barnes wrote: Nobody right in the head is going to be plugging an antique with a 1mhz processor directly into an unfiltered, internet-facing network connection, but I guess people who aren't right in the head like that are still people whose concerns deserve consideration. The SE/30

Re: Intent to deprecate: Insecure HTTP

On Sat, May 2, 2015 at 2:20 AM, pya...@gmail.com wrote: In summary, you're batshit insane, power hungry, and mad, and you're using double speek at its finest. Please refrain from further discussion until you can avoid making crude personal attacks such as these. Nick

Re: Intent to deprecate: Insecure HTTP

You should never force HTTPS. The win's are rather subjective and hard to confirm. But using HTTPS give problems for regular webmaster. Website will be slower on average. Webmaster need better hardware or pay more to his hosting provider. HTTPS support is not always possible. For example some

Re: Intent to deprecate: Insecure HTTP

On Sun, May 3, 2015 at 1:51 PM, moff...@gmail.com wrote: My vote would be never use your browser if you will deprecate HTTP. That's very easy to find an alternative or to fork you code, so think yourself how much such decision can cost you. This phrase i want also to said to Chrome dev team.

Re: Intent to deprecate: Insecure HTTP

воскресенье, 3 мая 2015 г., 5:39:55 UTC+3 пользователь Xidorn Quan написал: This has been happening in the Internet in China. I would suggest you use 360 Secure Browser, one of the major browsers in China. They completely consider the experience of developers and users. Their browser allows

Re: Intent to deprecate: Insecure HTTP

воскресенье, 3 мая 2015 г., 6:06:08 UTC+3 пользователь Xidorn Quan написал: I don't think anyone will ever completely drop support of HTTP. What we probably will do, at very most, is to treat HTTP websites just like the websites provide a broken certificate. - Xidorn It's the same as drop

Re: Intent to deprecate: Insecure HTTP

On Sun, May 3, 2015 at 2:46 PM, moff...@gmail.com wrote: воскресенье, 3 мая 2015 г., 5:39:55 UTC+3 пользователь Xidorn Quan написал: This has been happening in the Internet in China. I would suggest you use 360 Secure Browser, one of the major browsers in China. They completely consider

Re: Intent to deprecate: Insecure HTTP

On Friday, May 1, 2015 at 3:06:18 PM UTC-4, Richard Barnes wrote: On Thu, Apr 30, 2015 at 9:50 PM, imfasterthanneutr...@gmail.com wrote: 1.Setting a date after which all new features will be available only to secure websites I propose the date to be one year after Let's Encrypt is

Re: Intent to deprecate: Insecure HTTP

On 5/1/15 05:03, Matthew Phillips wrote: All mandatory https will do is discourage people from participating in speech unless they can afford the very high costs (both in dollars and in time) that you are now suggesting be required. Let's be clear about the costs and effort involved. There

Re: Intent to deprecate: Insecure HTTP

Here we go again. Listen up, guys. There are vast numbers of legacy sites without the technical or financial means to convert to https:, nor are many serving material that fundamentally needs to be encrypted. While I've long been a proponent of opportunistic crypto -- particularly by leveraging

Re: Intent to deprecate: Insecure HTTP

On Monday, April 13, 2015 at 4:57:58 PM UTC+2, Richard Barnes wrote: There's pretty broad agreement that HTTPS is the way forward for the web. There is no such agreement, and even if there was, that doesn't mean you get to force people to agree. In order to encourage web developers to move

Re: Intent to deprecate: Insecure HTTP

On 5/1/15 02:54, 王小康 wrote: P.S.:And finally, accept Cacert or a easy to use CA. CAs can only be included at their own request. As it stands, CACert has withdrawn its request to be included in Firefox until they have completed an audit with satisfactory results. If you want CACert to be

Re: Intent to deprecate: Insecure HTTP

Martin Thomson wrote: There are two aspects to this: the software, and the content. If software cannot be updated, that a problem in its own right. The idea that you could release your server onto the Internet to fend for itself for 20 years was a dream of the 90s that has taken a while to

Re: Intent to deprecate: Insecure HTTP

On Fri, May 1, 2015 at 12:40 PM, Eric Shepherd esheph...@mozilla.com wrote: Martin Thomson wrote: There are two aspects to this: the software, and the content. If software cannot be updated, that a problem in its own right. The idea that you could release your server onto the Internet to

Re: Intent to deprecate: Insecure HTTP

On 2015-05-01 3:40 PM, Eric Shepherd wrote: In my case, the situation is that I have classic computers running 1-10 megahertz processors, for which encrypting and decrypting SSL is not a plausible option. These computers have a burgeoning retro fanbase trying to push them to do new and

Re: Intent to deprecate: Insecure HTTP

On Fri, May 1, 2015 at 11:30 AM, Martin Thomson m...@mozilla.com wrote: On Fri, May 1, 2015 at 11:25 AM, Chris Hofmann chofm...@mozilla.com wrote: Is there a wiki page or some other comprehensive reference that defines the issues and arguments around this central question? Richard was -

Re: Intent to deprecate: Insecure HTTP

On 2015-05-01 1:13 PM, lauren4...@gmail.com wrote: Here we go again. Listen up, guys. That's not going to be a winning approach here. - mhoye ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Intent to deprecate: Insecure HTTP

On Fri, May 1, 2015 at 11:06 AM, Eric Shepherd esheph...@mozilla.com wrote: There are a lot of things that don't need encryption, This assertion is made quite often in this context. It's been shown to be false in every example I've seen. I think Richard provided several citations where this was

Re: Intent to deprecate: Insecure HTTP

On Fri, May 1, 2015 at 11:25 AM, Chris Hofmann chofm...@mozilla.com wrote: Is there a wiki page or some other comprehensive reference that defines the issues and arguments around this central question? Richard was - I think - in the process of assembling an FAQ that covered this and other

Re: Intent to deprecate: Insecure HTTP

+freaking1 On Fri, May 1, 2015 at 2:16 PM, Martin Thomson m...@mozilla.com wrote: On Fri, May 1, 2015 at 11:06 AM, Eric Shepherd esheph...@mozilla.com wrote: There are a lot of things that don't need encryption, This assertion is made quite often in this context. It's been shown to be false

Re: Intent to deprecate: Insecure HTTP

On Fri, May 1, 2015 at 2:07 PM, scough...@cpeip.fsu.edu wrote: Why encrypt (and slow down) EVERYTHING I think this is largely outdated thinking. You can do TLS fast, and with low overhead. Even on the biggest and most latency sensitive sites in the world. https://istlsfastyet.com when most

Re: Intent to deprecate: Insecure HTTP

On Thu, Apr 30, 2015 at 9:50 PM, imfasterthanneutr...@gmail.com wrote: 1.Setting a date after which all new features will be available only to secure websites I propose the date to be one year after Let's Encrypt is launched, which is about mid-2016. I was hoping for something a little

Re: Intent to deprecate: Insecure HTTP

Whoopie... I can jump through hoops and make TLS fast. Why should I have to? The user should be the decision maker. If they want to visit an unsecured HTTP site of cat videos... let them. IF a hacker wants to edit those cat videos while in transit... LET THEM. Why strong-arm everyone into

Re: Intent to deprecate: Insecure HTTP

On Fri, May 1, 2015 at 10:13 AM, lauren4...@gmail.com wrote: Here we go again. Listen up, guys. There are vast numbers of legacy sites without the technical or financial means to convert to https:, Of course I agree that we should not be brushing aside the little guys. But from where I sit,

Re: Intent to deprecate: Insecure HTTP

Honestly, this is a terrible idea. The whole point of a browser is providing user access - this would take power away from users by deciding for them what is permissible. It also fails to account for the bulk of web traffic which does not require encryption (and is the reason HTTP exists in the

Re: Intent to deprecate: Insecure HTTP

On Fri, May 1, 2015 at 2:37 PM, Patrick McManus pmcma...@mozilla.com wrote: It is afterall likely stored in cleartext on each computer. This is an important distinction no matter the nature of the content because Firefox, as the User's Agent, has a strong interest in the user seeing the

Re: Intent to deprecate: Insecure HTTP

On Fri, May 1, 2015 at 11:16 AM, Martin Thomson m...@mozilla.com wrote: On Fri, May 1, 2015 at 11:06 AM, Eric Shepherd esheph...@mozilla.com wrote: There are a lot of things that don't need encryption, This assertion is made quite often in this context. It's been shown to be false in every

Re: Intent to deprecate: Insecure HTTP

You must have missed my original email: I understand that there are proposed solutions to these problems but they don't exist today and won't be ubiquitous for a while. Let's let these solutions prove themselves out first. There are no free wildcard cert vendors and, at least in my experience,

Re: Intent to deprecate: Insecure HTTP

On 2015-05-01 2:06 PM, Eric Shepherd wrote: There are a lot of things that don't need encryption, and sites that serve legacy purposes and/or audiences, and cannot be updated to https in the first place. Encryption is not about protecting data. Encryption is about protecting people. -

Re: Intent to deprecate: Insecure HTTP

When plans like this aren't rolled out across all browsers together, users inevitably come across a broken site and say Firefox works with this site, but Safari gives a warning. Safari must be broken. Better security is punished. Having this determined by a browser release is also bad. My

Re: Intent to deprecate: Insecure HTTP

On Thu, Apr 30, 2015 at 10:49 PM, Matthew Phillips phillip...@gmail.com wrote: I understand that there are proposed solutions to these problems but they don't exist today and won't be ubiquitous for a while. That *has* to come first. Nothing is more important than the free speech the web

Re: Intent to deprecate: Insecure HTTP

On Thu, Apr 30, 2015 at 5:57 PM, diaf...@gmail.com wrote: Here's two relevant Bugzilla bugs: Self-signed certificates are treated as errors: https://bugzilla.mozilla.org/show_bug.cgi?id=431386 Switch generic icon to negative feedback for non-https sites:

Re: Intent to deprecate: Insecure HTTP

1.Setting a date after which all new features will be available only to secure websites I propose the date to be one year after Let's Encrypt is launched, which is about mid-2016. By the way, I hope Mozilla's own official website (Mozilla.org) should move to HTTPS-only as soon as possible.

Re: Intent to deprecate: Insecure HTTP

I think this is a grave mistake. The simplicity of the web was the primary factor in its explosive growth. By putting up barriers to entry you are discouraging experimentation, discouraging one-off projects, and discouraging leaving inactive websites running (as keeping certs up to date will

Re: Intent to deprecate: Insecure HTTP

On Thursday, April 30, 2015 at 6:02:44 PM UTC-7, peter.e...@gmail.com wrote: On Thursday, April 30, 2015 at 5:57:13 PM UTC-7, dia...@gmail.com wrote: 1. Mid-2015: Start treating self signed certificates as unencrypted connections (i.e. stop showing a warning, but the UI would just show the

Re: Intent to deprecate: Insecure HTTP

Here's two relevant Bugzilla bugs: Self-signed certificates are treated as errors: https://bugzilla.mozilla.org/show_bug.cgi?id=431386 Switch generic icon to negative feedback for non-https sites: https://bugzilla.mozilla.org/show_bug.cgi?id=1041087 Here's a proposed way of phasing this plan

Re: Intent to deprecate: Insecure HTTP

Hey all, Thanks a lot for the really robust discussion here. There have been several important points raised here: 1. People are more comfortable with requiring HTTPS for new features than requiring it for features that are currently accessible to non-HTTPS origins. Removing or limiting

Re: Intent to deprecate: Insecure HTTP

On 24/04/15 23:06, Roger Hågensen wrote: On Tuesday, April 21, 2015 at 2:56:21 PM UTC+2, Gervase Markham wrote: This makes checking in with the browser maker a necessary prerequisite for secure connections. That has problems. How so? Certificates have to be checked today as well (if they

Re: Intent to deprecate: Insecure HTTP

On Thursday, April 23, 2015 at 11:47:14 PM UTC-4, voracity wrote: Just out of curiosity, is there an equivalent of: python -m SimpleHTTPServer in the TLS world currently, or is any progress being made towards that? openssl req -new -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem

Re: Intent to deprecate: Insecure HTTP

On Friday, April 24, 2015 at 1:03:00 AM UTC-4, butrus...@gmail.com wrote: On Monday, April 13, 2015 at 4:57:58 PM UTC+2, Richard Barnes wrote: 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

Re: Intent to deprecate: Insecure HTTP

On Tuesday, April 21, 2015 at 2:56:21 PM UTC+2, Gervase Markham wrote: Very briefly: On 21/04/15 12:43, Roger Hågensen wrote: 1. User downloads a browser (be it Firefox, Chrome, Opera, etc.) securely (https?) from the official download location. 2. Upon installation a private key is

Re: Intent to deprecate: Insecure HTTP

On Tuesday, April 21, 2015 at 3:56:31 PM UTC+2, Mike Hoye wrote: On 2015-04-21 6:43 AM, Roger Hågensen wrote: I know, not that well explained and over simplified. But the concept is hopefully clear, but in case it's not... For what it's worth, a lot of really smart people have been thinking

Re: Intent to deprecate: Insecure HTTP

This is a digression, but it touches on an important question that others are asking in response to this general push [1]. Fundamentally, better client authentication doesn't do anything to help make the web a more secure place (in any of the dimensions that we're primarily concerned about in

Re: Intent to deprecate: Insecure HTTP

Just out of curiosity, is there an equivalent of: python -m SimpleHTTPServer in the TLS world currently, or is any progress being made towards that? ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Intent to deprecate: Insecure HTTP

On Tue, Apr 21, 2015 at 9:56 AM, Mike Hoye mh...@mozilla.com wrote: On 2015-04-21 6:43 AM, skuldw...@gmail.com wrote: I know, not that well explained and over simplified. But the concept is hopefully clear, but in case it's not... For what it's worth, a lot of really smart people have been

Re: Intent to deprecate: Insecure HTTP

On Monday, April 13, 2015 at 4:57:58 PM UTC+2, Richard Barnes wrote: 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,

Re: Intent to deprecate: Insecure HTTP

Very briefly: On 21/04/15 12:43, skuldw...@gmail.com wrote: 1. User downloads a browser (be it Firefox, Chrome, Opera, etc.) securely (https?) from the official download location. 2. Upon installation a private key is created for that browser installation and signed by the browser's

Re: Intent to deprecate: Insecure HTTP

On 2015-04-21 6:43 AM, skuldw...@gmail.com wrote: I know, not that well explained and over simplified. But the concept is hopefully clear, but in case it's not... For what it's worth, a lot of really smart people have been thinking about this problem for a while and there aren't a lot of easy

Re: Intent to deprecate: Insecure HTTP

On Monday, April 13, 2015 at 4:57:58 PM UTC+2, 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. I think server side SSL certificates should be deprecated as a means to

Re: Intent to deprecate: Insecure HTTP

The latter question is a real concern, but we won't know until we go and collect some data. When we get measurements for these sorts of things, it's usually from services that have the resources to acquire the measurements. At the same time, those services likely have the resources to have

Re: Intent to deprecate: Insecure HTTP

On Tue, Apr 14, 2015 at 3:29 AM, Henri Sivonen hsivo...@hsivonen.fi wrote: I think we should make ​ ​ the UI designation of plain http undesirable once x% the sites that ​ ​ users encounter on a daily basis are https. Since users don't interact ​ ​ with the whole Web equally, this means

Re: Intent to deprecate: Insecure HTTP

On 18/04/2015 00:13, andrewneme...@gmail.com wrote: Meanwhile: Deprecate it?? Has anyone in the tech community used an English dictionary? To deprecate Http would mean to speak badly of it. Or disapprove of it. I think you mean you want to abolish it, pressure it out of existence, or create

Re: Intent to deprecate: Insecure HTTP

On Wed, Apr 15, 2015 at 3:33 AM, Karl Dubost kdub...@mozilla.com wrote: Le 14 avr. 2015 à 19:29, Henri Sivonen hsivo...@hsivonen.fi a écrit : Currently, the UI designation for http is neutral while the UI designation for mixed content is undesirable. I think we should make the UI designation

Re: Intent to deprecate: Insecure HTTP

On 04/17/2015 09:46 AM, Mike Hoye wrote: On 2015-04-17 12:20 PM, Anne van Kesteren wrote: On Fri, Apr 17, 2015 at 6:13 PM, andrewneme...@gmail.com wrote: As a non-tech person, the only thing I know is https means my browser runs even slower on DSL. This has already been addressed earlier in

Re: Intent to deprecate: Insecure HTTP

On Fri, Apr 17, 2015 at 6:46 PM, Mike Hoye mh...@mozilla.com wrote: I don't see where that document speaks to the impact of TLS on caching proxies, which I'm guessing is the source of the performance hit Andrew mentions. It's been a while since I've looked, but in Canada (and probably other

Re: Intent to deprecate: Insecure HTTP

As a non-tech person, the only thing I know is https means my browser runs even slower on DSL, which is all that is available in many rural areas. Would this not mean that I'd be back to dial-up times to load a story or post, all of which are larded up with ads and videos these days? At 7 mbps

Re: Intent to deprecate: Insecure HTTP

On 2015-04-17 12:20 PM, Anne van Kesteren wrote: On Fri, Apr 17, 2015 at 6:13 PM, andrewneme...@gmail.com wrote: As a non-tech person, the only thing I know is https means my browser runs even slower on DSL. This has already been addressed earlier in the thread. HTTPS has negligible

Re: Intent to deprecate: Insecure HTTP

On Fri, Apr 17, 2015 at 11:22 AM, Anne van Kesteren ann...@annevk.nl wrote: As I said early on in this thread, this claim often comes up, but is never backed up. Where is the research that shows we need public caching proxies? This is early days, but I'm working with a partner on two things:

Re: Intent to deprecate: Insecure HTTP

Karl Dubost schrieb: Henri, great points, about… Le 14 avr. 2015 à 19:29, Henri Sivonen hsivo...@hsivonen.fi a écrit : Currently, the UI designation for http is neutral while the UI designation for mixed content is undesirable. I think we should make the UI designation of plain http

  1   2   3   >