19 ms·

When I recently added 'click to unsubscribe' functionality to my emails, the URL got wrote out into some logs. Those logs got written to a Slack channel and Sla

• javajosh 8y ago
  It would be sufficient to GET a resource that uses a script to POST the side-effect. Slack's user-agent probably isn't sophisticated enough to mess this up (although heaven help us when they implement their preview with something like headless chrome).
  • poizan42 8y ago
    What would the problem be in just showing a button that says "Confirm unsubscribe" that sends a POST request? A lot of sites does something like that for their newsletter unsubscription.
    • beobab 8y ago
      That would comply with GDPR, and is a valid solution.
      • SoulMan 8y ago
        It is at least better than asking the email or something even to login to unsubscribe ("update communication preference")
        • astura 8y ago
          I believe asking to login violates the CAN-SPAM Act. That being said, there might be two links, one for "update commication preference" on top and "unsubscribe" in small text at the bottom. I always ignore the first and seek the latter.
    • dingo_bat 8y ago
      I like the one-click URLs though. It irritates me to no end to click unsub, then wait for a page to load then repeat my intention.
      • jimktrains2 8y ago
        I'm actually much more concerned when I don't have to click the link. It let's me know they haven't thought the problem through and what other errors and problems are there in their systems?
• thomasz 8y ago
  “Toggle” is by definition not idempodent, because you get a different result each and every time. “Open” and “close” are idempodent, but not safe. The result of a GET request should always be idempodent and safe.
  • dewiz 8y ago
    GET requests should have no side effects. In other words NOOP is idempotent
    • rusk 8y ago
      I'd just like to clarify that what you have described here is "safe" rather than "idempotent" [0]. Easy mistake to make, made the same mistake myself, idempotently (that is to say you only make it once ;) Get, and NOOP, are both "safe" and naturally "idempotent" since the former encompasses the latter. [0] https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
      • thomasz 8y ago
        GET must be safe and idempodent. In the context of http, idempodency basically means that you get the same result for each request with the same url and the same set of parameters. Toggle should be implemented as post, since it’s neither safe, nor idempodent.
        • rusk 8y ago
          yes
        • mpweiher 8y ago
          > get the same result for each request with the same url and the same set of parameters. I think the resource can change externally...so it means that your GET request doesn't change it, but it doesn't have to be the same result every time.
        • dalore 8y ago
• bjackman 8y ago
  Aren't you allowed to have your "click to unsubscribe" button lead to a page with a button that does a POST that actually unsubscribes? I feel like I've seen that approach in use.
  • StavrosK 8y ago
    What they do is load a page with a form redirect to do the POST, I believe, so link loaders won't follow it and you'll be safe.
  • criddell 8y ago
    Don't make your users jump through hoops to unsubscribe. That seems like a typical dark pattern to me.
    • mysterydip 8y ago
      Having a single confirmation step to prevent "oops" clicks doesn't seem like a dark pattern to me.
      • icebraining 8y ago
        Confirmation steps should only be used if the action can't be easily undone.
        • jimktrains2 8y ago
          And when a user receives an email saying they've been unsubscribed because an automated system prefetched the link, they won't be concerned or worried or confused at all. (Especially when this happens _every time_.
          • tedunangst 8y ago
            And then the automated system clicks the undo link... Problem solved!
• sean-duffy 8y ago
  Facebook Messenger has the same problem, for a while my friends and I couldn't figure out why our referral links for a service weren't working, turns out Messenger was "using them up" for us.
• zerostar07 8y ago
  same thing with games running on facebook's platform
• tialaramex 8y ago
  Actual public Certificate Authorities have done this too. You request a cert, it's authorized everything seems fine. Except, huh, the guy who was supposed to authorize is off sick today, how did that work? The email to the authorizer should just be sat in his INBOX until he gets back. Oh - the company's "Malware protection" system automatically dereferenced the "Do you want to issue this certificate?" link from the email and there was no second step. So for affected companies basically anybody could request any certificate in their domains and it would get issued. As far as I remember nobody has proof any bad guys ever used this, but grey hats posted some fun they had with it. Likewise for a CA that decided to OCR the images from an unco-operative DNS hierarchy that wouldn't provide machine readable data to them. Grey hats obtained domain names that confused the OCR into allowing them to get certs for other people's names. Did any black hats do it? We have no proof.
  • kingbirdy 8y ago
    Any chance you could provide articles on these grey hat activities? Sounds interesting
    • tialaramex 8y ago
      For the OCR one the combination of "WHOIS" and "OCR" found me this thread from 2016 with an incident report from Comodo's Robin Alden: https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg04654.html https://www.mail-archive.com/dev-security-policy@lists.mozil... Alas I wasn't able to bring to mind a combination of keywords that would find the other incident in public archives, and I know it's from my background reading so it will be before my personal archives of these discussions begin. Sorry.
• amatheus 8y ago
  If the unsubscribe link were unique for each subscriber would the law still be satisfied?
  • jimktrains2 8y ago
    I don't understand how that prevents an automated system from unsubscribing them?
  • wlll 8y ago
    I thought that initially, but then I considered that for users to be bulk unsubscribed then the link would surely have to be the same for every user, at which point the each user gets the same unsubscribe link, and then when they click on it it unsubscribes everyone. This doesn't seem very likely, so I guess that a whole load of unique unsubscribe links got dumped into slack which started following them.
• notheguyouthink 8y ago
  > Idempotence is not the problem here, by the way. That just means calling the method twice has the same effect. But GET should have no side-effect, in an ideal world. Of course, in the case of unsubscribe links, it needs to have a side-effect to comply with the law. Thank you! I felt like I was taking crazy pills with my understanding of idempotence. Calling GET /door/open is idempotent too, but it's still gross in my opinion. The author makes it sound like that would be fine.
  • YCode 8y ago
    Kinda seems like he really just wanted to use the word.
  • deleted 8y ago
    [deleted]
  • chaosmonkey 8y ago
    I think he only had GET /door/toggle, which cannot be idempotent.
    • notheguyouthink 8y ago
      Yea, but his point was that GET requests should be idempotent.. when that's not the important part of GET. That's why I used the example of GET /door/open, because that is idempotent, but it's still gross - it's causing a state change from a GET request while still being idempotent. GET being idempotent is not the issue the author was dealing with. State change from a GET is the real issue.
    • luma 8y ago
      He mentions later in the thread that he doesn't have a sensor to indicate door position, which is going to kill this project and absolutely prevents an idempotent approach. There are a bunch of ways to approach this, most of which are patented by Chamberlain, which is the specific reason you don't find many garage automation solutions sold as a bundle in the US. Typical bolt-on solutions would be a range finder pointing down from the ceiling near the door which can tell if the door is obstructing it, a tilt sensor mounted to the top door panel, or limit switches on the carriage way/tracks. With a door position sensor in place a simple momentary-contact dry relay can be used to trigger door motion. Once that is in place, you can add another WeMos D1 mini to your car to open and close the door with no interaction: https://github.com/aderusha/MQTTCarPresence https://github.com/aderusha/MQTTCarPresence
• athenot 8y ago
  I remember having a similar issue in 2000, before any (meaningful) client-side javascript. Solution: each link that did something also had a request_id parameter, which was a timestamp in milliseconds. Two requests with the same request_id meant the user had clicked something twice, so any action would NOT be performed multiple times if the same request_id came in more than once. This let users double click on links and have the action performed only once. In 2000, hyperlinks were still confusing to some users who were used to "double-click = open", especially for file icons. EDIT: added text in italics because initial wording was confusing.
  • ams6110 8y ago
    A not-small percentage of users double click links (and buttons, and anything else that needs clicking).
    • 0xcde4c3db 8y ago
      The wording is a little ambiguous, but I think the scheme was that the first request is honored and any subsequent requests are ignored, not that additional requests cancel or undo the action altogether.
      • athenot 8y ago
        Thanks! Yes I didn't word that properly. :(
• js2 8y ago
  At 13:45 in this interview with Sergey Brin and Larry Page, you can listen to them discuss the meaning of idempotent on the air with Terry Gross. Pretty amusing thing to hear on NPR. I wonder if the term has ever been mentioned on public radio before or since. http://www.npr.org/2003/10/14/167643282/google-founders-larry-page-and-sergey-brin-part-2 http://www.npr.org/2003/10/14/167643282/google-founders-larr...
• eddz 8y ago
  > But GET should have no side-effect I disagree. There are some ways in which GET can be non-idempotent, such as pageview counters and endpoints with a vast amount of constantly-changing content, for instance. One may argue that the first example may be possible with a GET followed by a POST, but any subsequent GET response (assuming it contains the counter) would still be different to its prior.
• thomasahle 8y ago
  > Idempotence is not the problem here, by the way. That just means calling the method twice has the same effect. But GET should have no side-effect, in an ideal world. Of course, in the case of unsubscribe links, it needs to have a side-effect to comply with the law. Could you have the page redirect to itself with POST? Like javascript redirect or metatag. Browsers would do this, and there wouldn't be any different for users, but bots, slack and Safari probably wouldn't.
• cryptonector 8y ago
  Consider link shortener services... It's perfectly fine to have certain side-effects, provided the GET is idempotent, but not others/most. Specifically, it's fine to idempotently have side-effects where it doesn't matter who is causing the effect, the side-effects are desirable, and the side-effect load won't be overwhelming. In the case of a link shortener one can pretend that the side effect did not happen the first time the service sees some particular link, that the shortening has already occurred (at the beginning of time!). There is definitely a side-effect, since it involves updating a persistent hash table, and it is idempotent (though one could construct a shortener where it's possible to get more than one shortened form for a given URI when racing to shorten it, but this is not a problem for this particular sort of service).
• edem 8y ago
  It should be a DELETE imho or a PATCH.
• RandomCSGeek 8y ago
  The problem is not that your endpoint had side effect. Rather, it didn't have any side effect(it is supposed to unsub, and it does exactly that). The problem is with lack of authentication. Slack's ability to unsubscribe people on their behalf, without their explicit permission seems to be the real issue here. Even a "I'm not a bot" check would provide some protection.