> 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
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?
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.
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).
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
https://letsencrypt.org/documents/LE-SA-v1.2-v1.3-diff.docx