Live data from Hacker News

HTTPS Everywhere will sunset in January 2023

eff.org

71–80 of 148 posts

Re: HTTPS Everywhere will sunset in January 2023

#71
post #4

This is the kind of sunset you love to see. Retirement because they succeeded and therefore became redundant, rather than due to failure. If there's one organization I love to see succeed, it's the EFF.

That’s how I used to feel until I found out they accepted millions in donations from companies like Google and Facebook/their executives/their executives’ charities. I’m just some guy on the Internet but IMHO their being OK with massive conflicts of interest means I no longer trust them.

What would you have them do? Not accept those donations, and be unable to work on as wide a range of issues that they do?

EFF works on a wide range of issues, ranging from anti-censorship, software patent reform, online free speech, just to name a few. Many of those areas are where their values align with those of the Facebook/Google executives which donate to them. That they are able to receive those donations in spite of the areas where they disagree speaks more to EFF's track record of being an effective and powerful force for good in tech.

Re: HTTPS Everywhere will sunset in January 2023

#72
post #67

Noob question: If I have a personal HTTP website running out of GCP cloud storage (without the load balancer, bells & whistles), is it possible to upgrade it to HTTPS so that visitors don't get warnings

Looks like you can either do this by referencing static pages with HTTPS directly or by putting a load balancer in front of your site:

https://cloud.google.com/storage/docs/troubleshooting#https

My shared hosting provider (Cooini) gives an HTTPS option out of the box. It used to be a paid option that required upgrading to dedicated hosting, but they changed it years ago to a simple cost-free toggle in their dashboard

Re: HTTPS Everywhere will sunset in January 2023

#74

Earlier quoted context omitted.

Debian ships with its own signing keys to authenticate the packages that it downloads. They are acting as their own CA. This isn't scalable to the web.

Whether or not it's scalable is orthogonal to the question. A browser would call Debian's repos insecure despite the fact that they are secure by other means. vv: whether it's authenticated by TLS or PGP is literally isomorphic except one is centralized to CAs and one is decentralized with web of trust. That's the only difference.

Just because you can separately verify that something is secure later does not mean that it's secure at the time of the download. Browsers show that a website is securely encrypted once they've been able to verify it. It's entirely proper for them to show that a download is insecure before they've been able to verify it.

If you get a phone call from an unknown caller, do you get mad at your phone for listing that as an unknown caller just because you could theoretically add that number to your contact list later? Or to talk directly about PGP, do you get mad when you see an untrusted/unknown key warning because theoretically you could add that key to your keyring later after verifying it yourself? Of course not.

The browser is telling you that at that moment, the code/download you are getting is insecure. If you take that code/download out of the browser and verify it separately, then great! But that doesn't mean the browser was wrong. If anything, insecure connection prompts should be a welcome reminder to you that you need to externally validate the data you're receiving.

> That's the only difference.

The difference is that one of them happens inside the browser, and one of them doesn't.

Re: HTTPS Everywhere will sunset in January 2023

#75

HTTPS Everywhere being available in browsers as an option is great. HTTPS Everywhere being promoted as something you should have on by default is bad. HTTPS, like much else, relies on incorporated entities as certificate authorities. And that's fine for commercial interactions and if browsers were only for interacting with businesses. But by a combination of centralization in a few CAs (everyone uses LetsEncrypt now)…

Again and again, even supposedly smart people are fine when what a dictator claims aligns with what they think is good while handwaving the long term issues of giving up control and power to them. Especially around security where techies have a tendency to shut down their brains whenever it is brought up, as if in the name of security everything else should be compromised.

Completely agreed.

Also, greetings from the Rome.ro forums!

Re: HTTPS Everywhere will sunset in January 2023

#76

HTTPS Everywhere being available in browsers as an option is great. HTTPS Everywhere being promoted as something you should have on by default is bad. HTTPS, like much else, relies on incorporated entities as certificate authorities. And that's fine for commercial interactions and if browsers were only for interacting with businesses. But by a combination of centralization in a few CAs (everyone uses LetsEncrypt now)…

HTTP is not ok. Anyone can ready / modify what is being sent. This privacy intrusion will definitely happen, whereas the risk of being banned by "some external corporation" is low. And, you always have the option of self-signing your own certificate, which is at least as secure as using HTTP, and much more secure if you can verify the certificate via a side channel.

We've had more security alerts from OpenSSL and other cert-related software than the man-in-the-middle attacks.

Re: HTTPS Everywhere will sunset in January 2023

#77

Earlier quoted context omitted.

You need HTTPS to even begin trusting remote code. For instance, you download uMatrix to setup a whitelist. Where did uMatrix come from? If you downloaded it over HTTP, then you could be running anything. Even if you have a checksum for uMatrix, you can't trust it if you got the checksum over HTTP. Now let's say you installed uMatrix and you want to trust a script. Well, how do you know that the script you downloaded…

> Where did uMatrix come from? But is uMatrix to trust? Can you trust uMatrix developers? I have bought a pair of shoes from an HTTPS only web sites, shoes never arrived, HTTPS apparently can't fix everything. Trusting trust is a problem since computing was invented. [1] [1] WARNING! PDF! https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...

Without some kind of baseline for secure connections you can't even start approaching the problem of trusting trust.

Yes, it's hard to figure out whether or not to trust uMatrix. But I'd rather not make that even harder by allowing basically anyone to intercept and modify the code that uMatrix is sending at any time.

Re: HTTPS Everywhere will sunset in January 2023

#78
post #4

This is the kind of sunset you love to see. Retirement because they succeeded and therefore became redundant, rather than due to failure. If there's one organization I love to see succeed, it's the EFF.

That’s how I used to feel until I found out they accepted millions in donations from companies like Google and Facebook/their executives/their executives’ charities. I’m just some guy on the Internet but IMHO their being OK with massive conflicts of interest means I no longer trust them.

Would you turn down millions of dollars in no-strings-attached donations if you were running a charity? What was the negative result of those donations that you can point to?

I'm not a fan of Google or Facebook, but I also don't outright boycott everything that they've ever touched. They donate money and developer time to tons of projects that I use regularly (including Linux), and it would be hypocritical of me to look down on the EFF for benefiting from the companies that I also benefit from.

I don't like the bad behavior from Google or Facebook, but I don't think donating millions to the EFF is bad behavior, nor do I think getting tens of thousands of pull requests merged into public FOSS projects from Google and Facebook employees is bad behavior. Black and white guilt-by-association doesn't work when you have companies of this size, with hundreds of thousands of employees, and tons of varying internal cultures.

Re: HTTPS Everywhere will sunset in January 2023

#79

Earlier quoted context omitted.

That's a thing for local software to decide. It's also something that can be done with a level of reliability that will impress incredulous people. But that there will always be somebody to complain that is not following the standard recommendations.

In that case you don't need a certificate. Just check that the .local FQDN's IP is on a local network. 1. Look up all local interfaces' networks (IP & subnet mask) 2. Determine if .local IP is within subnet range of one of the interfaces 3. If .local IP is not on a subnet of a local interface, drop the connection This is still "host-based networking" and there's always the possibility a rogue network could be attache…

Indeed that's much better.

It's probably better if we terminate the trust at a TLS certificate or something similar to DANE. So there isn't any specialized registry to maintain.

Re: HTTPS Everywhere will sunset in January 2023

#80
post #69

Earlier quoted context omitted.

You do realize Firefox is going to V3 as well?

Firefox is adding V3 support for compatibility with Chrome but not removing V2 support: https://blog.mozilla.org/addons/2022/05/18/manifest-v3-in-fi...

That's what they say now, they don't exactly have a good extension record themselves.

I operate some popular extensions and I now maintain a v2 and v3 build (make file). I'd love to nuke the v2 build tasks and only operate in v3. Most users are on Chrome anyway.

If you're lucky, v2 will be kept around for legacy extensions that are rarely if ever updated.

Post reply on HN