5 ms·
But to be fair, 1-click unsubscribe is a very user friendly thing to do. As a user, if I have to jump through a bunch of hoops to unsubscribe, I'm just going to
by ShakataGaNai 5y ago
But to be fair, 1-click unsubscribe is a very user friendly thing to do. As a user, if I have to jump through a bunch of hoops to unsubscribe, I'm just going to mark your message as spam and move on with my life.
- justinator 5y agoI absolutely agree. That's why on the app I wrote, the default is one-click unsubscribe, but I still have to do it using a little bit of Javascript. If JS is disabled, you just have to click a button that POSTs the request. I'm not sure what else to do! There's a similar but different problem with the reader-supplied "unsubscribe" button. This usually uses information found in the header of the email message - "List-Unsubscribe", but guess what also gets prefetched sometimes? Enter RFC8058 and, "List-Unsubscribe-Post"and another email kludge to throw on the pile, https://datatracker.ietf.org/doc/html/rfc8058 https://datatracker.ietf.org/doc/html/rfc8058
- Silhouette 5y agoExactly. And it's not just one-click unsubscribe. Using a secret link sent to an account's email address as a way to implicitly log in instead of having to remember a password is increasingly common and also an interesting idea in terms of user experience and security. If it's OK for your mail service to open one secret link, where does it stop? Is it also OK for them to spider the content they can reach from that link? Now they are potentially gaining access to all kinds of possibly sensitive information that they would not have been able to reach except for spying on your email. And if that's not OK, why was it OK for them to open the secret link in the first place?
- kyleee 5y agoGross never thought of that. Lots of valuable data so no doubt someone will try it (if they aren't already)
- pwdisswordfish0 5y ago> to open one secret link "Secret link" is an oxymoronical concept. Resource identifiers are exactly that: identifiers. They're not private names, and any design that relies on keeping them secret is inherently flawed. If it's accessible on the openly resolvable web, then the content needs to be treated as if it's public. If your use calls for authentication or authorization, then actually use an authentication or authorization system.
- geofft 5y agoThey are in fact private names, because they're unknown to the public. This is in fact an authentication system. Yes, the public could guess a 128-bit random value and log in - but that's no different from the ability of the public to guess your password, or your session cookie, or your SSL session state, or whatever. Every authentication mechanism is based on "There is a high-entropy value, and nobody but the authorized user has it." It makes no difference from a theoretical standpoint - i.e., in terms of whether it's "actually" an authentication system" - whether the high-entropy value is sent to the server as part of the URL or via a header or via POST data. (It clearly makes a difference from a practical standpoint, because in order to have a secret link, the link must actually be kept secret. But that's no different from, like, the need to not expose your cookies to third-party requests or whatever.)
- hyperman1 5y agoI understand they are known to the public? Every MTA from any random site between the sender and receiver gets the mail, including secrets. They can all decide to scan the site, write them in a log,... Then, when you click the link, if you don't have https, anything between receiver and site also gets a copy of the link. And there are proxys, add injecting ISPs, etc.
- geofft 5y agoAre you claiming that the contents of emails are public? Which "random sites" see emails between sender and receiver? Yes, proxies and ad-injecting ISPs can see the contents of plaintext HTTP. But that's hardly a reason to say that logging into a website with a password or presenting a cookie doesn't count as an authentication system!
- rypskar 5y ago>>Using a secret link sent to an account's email address as a way to implicitly log in instead of having to remember a password is increasingly common and also an interesting idea in terms of user experience The user experience with this is terrible if email is not set up on the device you want to log in from
- Silhouette 5y agoThe user experience of lots of things is terrible if the relevant facilities aren't set up on the device you want to use at the time. It's a curse of our modern, highly-connected and always-online world. You get the same problem with logging into sites that require ID and password from a device that doesn't have your password manager on it. But the fact is, many systems do work like that and many users do prefer it. I'm taking a pragmatic stance here because assuming the messy, unpredictable real world always follows some theoretical standards at a scale of billions of people and millions of organisations is very predictably going to give bad results in a lot of cases.