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 ne

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 > encryptio

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 d

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 - could a government > restrict

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 20

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 bunch

Re: Intent to deprecate: Insecure HTTP

On Thu, May 7, 2015 at 12:43 AM, Adam Roach 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 announcements indicate

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 thi

Re: Intent to deprecate: Insecure HTTP

> On May 6, 2015, at 22:51, Eric Shepherd 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 features are gradually

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 viab

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 Wed, May 6, 2015 at 2:04 PM, Matthew Phillips 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 setting up a secure server yo

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 remai

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 l

Re: Intent to deprecate: Insecure HTTP

On Tue, May 5, 2015 at 12:03 AM, Daniel Holbert 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 be unfounded, t

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 mutua

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 informati

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 wr

Re: Intent to deprecate: Insecure HTTP

On Mon, May 4, 2015 at 1:57 PM, Xidorn Quan wrote: > On Tue, May 5, 2015 at 6:04 AM, Martin Thomson wrote: > > > On Mon, May 4, 2015 at 11:00 AM, Daniel Holbert > > wrote: > > > (I think there's a strong case for disabling *persistent* fullscreen > > > permission, for the reasons described in e

Re: Intent to deprecate: Insecure HTTP

On Tue, May 5, 2015 at 6:04 AM, Martin Thomson wrote: > On Mon, May 4, 2015 at 11:00 AM, Daniel Holbert > 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

Re: Intent to deprecate: Insecure HTTP

On Mon, May 4, 2015 at 12:59 PM, Florian Bösch wrote: > On Mon, May 4, 2015 at 8:06 PM, Eric Rescorla 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 >

Re: Intent to deprecate: Insecure HTTP

On Mon, May 4, 2015 at 8:06 PM, Eric Rescorla 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 over im

Re: Intent to deprecate: Insecure HTTP

On Mon, May 4, 2015 at 10:52 AM, Florian Bösch wrote: > On Mon, May 4, 2015 at 7:43 PM, Eric Rescorla 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 agree. But I don't get

Re: Intent to deprecate: Insecure HTTP

On Mon, May 4, 2015 at 11:00 AM, Daniel Holbert 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 little birdy told

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-HTT

Re: Intent to deprecate: Insecure HTTP

On Mon, May 4, 2015 at 9:39 AM, Florian Bösch wrote: > On Mon, May 4, 2015 at 6:33 PM, Adam Roach 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. > > >

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" wro

Re: Intent to deprecate: Insecure HTTP

On Mon, May 4, 2015 at 3:38 PM, Adam Roach 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. That's an amazing

Re: Intent to deprecate: Insecure HTTP

On Mon, May 4, 2015 at 6:33 PM, Adam Roach 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. Obviously it's not

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 > 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.

Re: Intent to deprecate: Insecure HTTP

On Monday, May 4, 2015 at 9:40:08 AM UTC-4, Adam Roach wrote: > 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 pige

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 make-or-bre

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 Sat, May 2, 2015 at 11:57 AM, Nicholas Nethercote 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 great advantages to doi

Re: Intent to deprecate: Insecure HTTP

On Fri, May 1, 2015 at 1:25 AM, Richard Barnes 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 caching on site-chos

Re: Intent to deprecate: Insecure HTTP

On Mon, May 4, 2015 at 10:04 PM, Gervase Markham 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 developers and

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 (f

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 th

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 blogs

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 wa

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 dro

Re: Intent to deprecate: Insecure HTTP

On Sun, May 3, 2015 at 2:46 PM, 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 the experie

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

On Sun, May 3, 2015 at 1:51 PM, 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. Internet is li

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 C

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, 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 a

Re: Intent to deprecate: Insecure HTTP

On Sat, May 2, 2015 at 2:20 AM, 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

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 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 intere

Re: Intent to deprecate: Insecure HTTP

On Fri, May 1, 2015 at 11:30 AM, Martin Thomson wrote: > On Fri, May 1, 2015 at 11:25 AM, Chris Hofmann > 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

Re: Intent to deprecate: Insecure HTTP

On Fri, May 1, 2015 at 12:40 PM, Eric Shepherd 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 fend for >> i

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 die.

Re: Intent to deprecate: Insecure HTTP

On Fri, May 1, 2015 at 10:13 AM, 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, I'm seeing lots of e

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 usi

Re: Intent to deprecate: Insecure HTTP

On Thu, Apr 30, 2015 at 9:50 PM, 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 sooner, given that we're t

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. - mho

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 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 content > she asked for

Re: Intent to deprecate: Insecure HTTP

On Fri, May 1, 2015 at 2:07 PM, 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 web content isn't wort

Re: Intent to deprecate: Insecure HTTP

On Fri, May 1, 2015 at 11:25 AM, Chris Hofmann 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 issues. This is defini

Re: Intent to deprecate: Insecure HTTP

+freaking1 On Fri, May 1, 2015 at 2:16 PM, Martin Thomson wrote: > On Fri, May 1, 2015 at 11:06 AM, Eric Shepherd 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 t

Re: Intent to deprecate: Insecure HTTP

On Fri, May 1, 2015 at 11:16 AM, Martin Thomson wrote: > On Fri, May 1, 2015 at 11:06 AM, Eric Shepherd > 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 Ri

Re: Intent to deprecate: Insecure HTTP

On Fri, May 1, 2015 at 11:06 AM, Eric Shepherd 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 believed to be corre

Re: Intent to deprecate: Insecure HTTP

Why encrypt (and slow down) EVERYTHING, when most web content isn't worth encrypting? I just don't see the point. This is the dumbest thing I've heard in a long while. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.

Re: Intent to deprecate: Insecure HTTP

lauren4...@gmail.com wrote: 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 the tone of the rest of this message was a little harsh, I agree with this. There are

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 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 https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

On Friday, May 1, 2015 at 7:03:32 PM UTC+2, Adam Roach wrote: > 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

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 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 are

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 incl

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 f

Re: Intent to deprecate: Insecure HTTP

On 2015-05-01 8:03 AM, Matthew Phillips wrote: Of course you know this is not true. There have been many petabytes of free speech floating around on the internet for the last 2 decades, despite not having mandatory https. There are some philosophical discussions to be had here around "freedom fr

Re: Intent to deprecate: Insecure HTTP

Of course you know this is not true. There have been many petabytes of free speech floating around on the internet for the last 2 decades, despite not having mandatory https. All mandatory https will do is discourage people from participating in speech unless they can afford the very high costs (

Re: Intent to deprecate: Insecure HTTP

On Thu, Apr 30, 2015 at 10:49 PM, Matthew Phillips 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 allows. Not > even s

Re: Intent to deprecate: Insecure HTTP

restriction might be: unless website is severing from local network, 1. you can't use a password input(treat it equal to normal text input). 2. you can't set cookie. 3. javascript is disabled. A header is provided to prevent a content from https being load to a http page. (maybe work like same-ori

Re: Intent to deprecate: Insecure HTTP

On Thu, Apr 30, 2015 at 5:57 PM, 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: > https://bugzilla.mozilla.org/show_bug.cgi?id=1

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 be

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 sho

Re: Intent to deprecate: Insecure HTTP

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 > globe icon, not the lock icon). This would allow website owners to choose to

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 i

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 feature

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

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 this

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 thi

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

Re: Intent to deprecate: Insecure HTTP

On 2015-04-24 1:02 AM, butrus.but...@gmail.com wrote: I think this is very very bad idea. There are many resources which are not worth being protected by HTTPS. This is about protecting people, not resources. I think an eight-year-old article about a hacked-up, homebrew 8-bit webserver is the

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 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 o

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

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 https://lists.mozilla.org/listinfo/dev-plat

Re: Intent to deprecate: Insecure HTTP

On Tue, Apr 21, 2015 at 9:56 AM, Mike Hoye 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 thinking

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 bu

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 certif

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 encry

Re: Intent to deprecate: Insecure HTTP

On Thu, Apr 16, 2015 at 5:16 AM, wrote: > - You don't want to hear about non-centralized security models. DANE > provides me with control over certificate pinning for people visiting my > websites. > ​[...] If you don't like DANE, explain why, and propose something else > that is non-centralized

  1   2   3   >