5 ms·

You make just visiting the URL not everything that needs to be done. So for example, the URL you visit then also runs a small bit of javascript behind the scene

You make just visiting the URL not everything that needs to be done. So for example, the URL you visit then also runs a small bit of javascript behind the scenes that does the actual unsub action - or the javascript just does a redirect. Or even simpler, you make it so the user has to click a button to POST the request. You've had to do this for years, now. I would assume though, that Gmail is smart enough to go, "oh hey, looks like a verification link, maybe I shouldn't touch it"

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 ago
  I 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 ago
  Exactly. 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 ago
    Gross 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 ago
      They 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 ago
        I 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.
akersten 5y ago
Well, the problem is at some point (maybe the can-spam act) there was a nebulous requirement for "one click unsubscribe." So rock, meet hard place. On mobile or I'd look up the law. I suppose a link and then a button press counts as two clicks.
- justinator 5y ago
  The CAN-SPAM act actually doesn't require one-click unsubscribe, but there needs to be a way to unsubscribe in any email you send out, and your physical address has to be listed in the email message.
justinator 5y ago
No need to downvote me - if there's a better practice, I'm absolutely happy to adopt it. Or I can give you the github details and you can send a PR.
modernerd 5y ago
This is what MailChimp does for its one-click unsubscribes. You visit a URL, and some JS POSTs to `https://[youraccount].us1.list-manage.com/unsubscribe/post https://[youraccount].us1.list-manage.com/unsubscribe/post` with a body containing your subscription and list IDs. I'm not sure what prevents crawlers executing JavaScript on that page and triggering the unsubscribe action anyway, though, unless it's just that email crawlers don't execute JS.
- mvolfik 5y ago
  it could do some checks on the environment - useragent, screen size etc?

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 ago
I 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 ago
Exactly. 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 ago
  Gross 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 ago
    They 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 ago
      I 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.

akersten 5y ago

Well, the problem is at some point (maybe the can-spam act) there was a nebulous requirement for "one click unsubscribe." So rock, meet hard place. On mobile or I'd look up the law. I suppose a link and then a button press counts as two clicks.

justinator 5y ago
The CAN-SPAM act actually doesn't require one-click unsubscribe, but there needs to be a way to unsubscribe in any email you send out, and your physical address has to be listed in the email message.

justinator 5y ago

No need to downvote me - if there's a better practice, I'm absolutely happy to adopt it. Or I can give you the github details and you can send a PR.

modernerd 5y ago

This is what MailChimp does for its one-click unsubscribes. You visit a URL, and some JS POSTs to `https://[youraccount].us1.list-manage.com/unsubscribe/post https://[youraccount].us1.list-manage.com/unsubscribe/post` with a body containing your subscription and list IDs. I'm not sure what prevents crawlers executing JavaScript on that page and triggering the unsubscribe action anyway, though, unless it's just that email crawlers don't execute JS.

mvolfik 5y ago
it could do some checks on the environment - useragent, screen size etc?