Let's Encrypt’s subscriber agreement changes on Sept 21 | Hacker News Reader

Let's Encrypt’s subscriber agreement changes on Sept 21

letsencrypt.org

86 pointsTheBrokenRail46 comments

The site has a download for the differences, which is very useful. I wish every company would provide that with their TOS updates.

https://letsencrypt.org/documents/LE-SA-v1.2-v1.3-diff.docx

> I wish every company would provide that with their TOS updates

The companies for which you want that are probably the companies who don't want you to figure out what changed though, so little luck of that happening

Maybe someone could make a tool to generate such a diff automatically.

We could call it 'diff(1)'

Calling it exactly what it does... That's a bit 'on the nose', isn't it? Shouldn't we call it "gadget", or "razlika", or "moon beam" ? Something cool and confusing, with an available domain name for our flashy homepage and mascot. How else will we popularize and monetize it?

Don't forget to include a "Made with ♡ by ..." somewhere on the page.

dffr-bleed, but you forgot that we need a really good logo.

You can compare documents in Word - it won't help if the boilerplate changed that much but it can help with certain sections.

https://support.microsoft.com/en-us/office/compare-and-merge...

(It shows how to also "merge" but you don't have to merge, it will highlight the differences.)

You can find them for many companies here:

https://github.com/OpenTermsArchive/contrib-versions

Google Docs Viewer link if you don't want to download and look at it:

https://docs.google.com/viewer?url=https%3A%2F%2Fletsencrypt...

> I wish every company would provide that with their TOS updates.

Agree, now I remember that at least Google is doing it.

TOS: https://policies.google.com/terms/archive/20200331-20220105

The only real difference I spot in the diff is ISRG not storing your certificate in its repository anymore.

That's what I gathered.

Is that different from the certificate transparency log (CT)?

Yes, previously as part of audit requirements you are required to internally store all certificates you've issued for at least seven years. Seeing as CT is now here though (which is a much more robust system since it's tamper-resistant), storage on your own archives is no longer needed (as long as you can prove that you log them all in CTs).

Thanks!

In the email that they sent they said following:

The main updates are: we now link to instructions on choosing a revocation reason if you revoke a certificate. This is a requirement for Subscriber Agreements from all Certificate Authorities as of this year. Also, we've removed unneeded capitalization, removed a section that is redundant with our Certificate Policy (CP), and tweaked the wording of the requirement to "assure" control of your private key so it matches the Baseline Requirements (BRs).

We still store the certificate in the same ways we did, we just don't talk about it in the subscriber agreement any more as it's redundant with our CP/CPS documents.

I moved from letsencrypt over to AWS ACM, but the letsencrypt emails don't have an Unsubscribe :(

> the letsencrypt emails don't have an Unsubscribe

Yes and that is really stupid, especially from a group of people who are otherwise very clever.

Newsletters or notifications?

Irrelevant. Think of it this way, Let's Encrypt could be emailing a dead person and you can't tell them to fuck off.

Except that it does, just not via email. You have to unsubscribe the same way you subscribed.

That’s not enough. CAN-SPAM is nearly 20-years-old now, it’s not even a GDPR matter. The rule is pretty clear in having to provide an unsubscribe link in every email.

It’s really quite annoying that companies have taken this “you can’t unsubscribe from service emails” approach and I wish this act would get a refresh 20 years later.

CAN-SPAM explicitly exempts "transactional or relationship messages". This email would qualify.

I keep getting emails from them addressed to PERSON+ORG@MY_PERSONAL_DOMAIN. I've never heard of the person nor their org. I don't know why Let's Encrypt has their email the way they do. But I can't unsubscribe, nor do I want to invest the effort to track this person down.

As far as I recall, Let's Encrypt doesn't verify control of an email address before using it, so anyone can sign up with your personal domain. If you can, I'd set that address to be undeliverable in your MX, so their outgoing service will bounce it. Or mark as spam, because outside of sending verification mails, sending mail to unverified addresses is spam.

A while back I set a catchall address forwarding to my day to day gmail account, as part of a transition away from using my personal domain. TBH the only reason I noticed this. I've also been amused at some of the spam I receive now, messages to random nonexistent accounts telling them they need to log into DOMAIN.

> letsencrypt emails don't have an Unsubscribe

Technically, this is not true. You can "unsubscribe" (read "remove") your email via the Certbot client.

Nevertheless, I agree that this is far too complicated, and I do not understand why there is no form on their website. I wonder if this behavior is compliant with the GDPR.

I wonder if this is compliant with CAN-SPAM, let alone GDPR. Would like to see a web unsubscribe option added, though overall I'm not too upset about it.

It’s not. Providing an unsubscribe link is one of the main points of the act. On Wikipedia is the first point listed.

It doesn't fall under CAN-SPAM. This is a "transactional or relationship message".

Yeah, anyone can think of their emails as "relationship message". The point is that I don't want your relationship emails either, especially if I'm no longer actually using the service.

The problem is that this is junk messaging that no one reads nor needs.

If you can only subscribe via certbot or otherwise using you private keys then it should be fair to require the same to unsubscribe.

A justification could be that email notifications are a security feature and to disable them you need strong authentication (an unsubscribe link in the email could used by anyone you forward the email)

Sounds reasonable, but what if I lost the private key?

Speaking from personal experience: I received 7 emails from them, for various "tag" parts of my email (username+tag@server.example). Two of them - for when I was playing with Caddy server many years ago (well before COVID) - and its "auto-https" feature. There's no chance I still have these keys - I likely `rm -rf`'d whole caddy directory.

My guess would be that it should be a similar process to how you handle creating a new certificate if your private key is compromised / gets lost.

You probably would need to reauthenticate via DNS, create a new private key and then do what you wanted to do.

EDIT: this is just a guess.

That does not sound practical nor necessary. An authentication should be required to disable a service, but is never necessary to stop notifications.

In my view there’s only one thing to do when emails don’t contain an unsubscribe link: report spam — because it is, as described by CAN-SPAM.

There are many types of email notifications and for some read access is different than setup access.

Consider an outage email containing a diagnostic report. You might be the relevant person on call for that email and based on the diagnostic you forward it to who should be most competent to fix the issue. This person/team has now read access to the email, but they should not be able to unsubscribe you from these notifications.

In general unsubscribing should not be unduly harder than it needs to be.

For marketing email the effort required should be zero; for critical security issues (like certificates) it should be more.

You could reasonably have an unsubscribe form that needs a token from the email and requests the address to avoid unintentional unsubscriptions, or you could have a double confirmation sent by email. If it's a mailing list, it's still the case that anyone on the list could unsubscribe, but everyone would know it had been done.

> Consider an outage email containing a diagnostic report

So, here's the problem, I don't care. I left the company. I cannot access the account anymore. The project is dead. There are a million reasons why I just don't want your emails so there's no excuse to not add an unsubscribe link.

The only messages that don't have to include such link are those that if missed/ignored lead to fees, fines, death, imprisonment and other real-life consequences.

An update to your privacy policy does not fall into that category.

> there's no excuse to not add an unsubscribe link

My point was not that you should keep receiving those emails, it was an example of the necessity of having sometimes other mechanisms.

An unsubscribe email address could work better (assuming that if you can send arbitrary emails from an address then you control it).

If you are a current user, it's possible GPDR actually requires them to send you notices of changes to policy and practices (where relevant to GPDR), without an opt-out?

At any rate, it seems good practice to send such notifications. I don't believe you can usually opt out of "business communications" like this.

Now, letsencrypt is a free service, and they may not be as good as they should about identifying who is a current user? If you don't have have certs that haven't expired, and they're still including you in business communications, then perhaps something isn't as targeted as it could be.

Let’s encrypt doesn’t need to follow GDPR.

I think it happens automatically if you don’t have any active domains for a time, though I cannot recall where I read that.

To be fair they send less than 1 email a year (aside from notifying you if a domain is expiring because of incorrect configuration).

It does not have to be necessarily because of bad configuration. There are plenty of subdomains I abandonned and I am happy to see that LE cares enough to remind me that they will expire.

Reply on news.ycombinator.com