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.

Any chance you could provide articles on these grey hat activities? Sounds interesting

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/[email protected]...

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.

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.

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.

How about just having, near the unsubscribe link in the email, a link that says "click here to ignore up to one unsubscribe link press within two minutes of clicking this link", so that the automated process that clicked the unsubscribe link by mistake will also click that link.

The page in question could also have a "actually, I do want to unsubscribe, I just clicked the wrong link by accident" button as well, in case a human reader is confused.

---

Or, one link that says "unsubscribe immediately" and another that says "unsubscribe only after confirmation", and the first one unsubscribes immediately, unless they also click the second link immediately before or after, while the second link only unsubscribes them if they click a confirm button on the page?

---

Or, maybe the unsubscribe link could have a confirmation button, but would also have some javascript to confirm the unsubscribe after a few moments of the page being fully loaded (the button being used if they have javascript disabled, for example)

Don't make your users jump through hoops to unsubscribe. That seems like a typical dark pattern to me.

Having a single confirmation step to prevent "oops" clicks doesn't seem like a dark pattern to me.

Confirmation steps should only be used if the action can't be easily undone.

It can't be easily undone if it was "clicked" by an automated process rather than a human being.

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_.

And then the automated system clicks the undo link... Problem solved!

Which fires off a new email thanking them for re-subscribing.

Soon your inbox is full.

You are right, it doesn't seem like one, but to pissed off users it doesn't matter. If you, for any reason, piss people off to the point where they complain to your registrar or your hosting provider it is bad news. Doesn't matter why. So, the answer is to make it as easy as possible to get removed, which is why people use GET.

I have seen this with spam, and I have seen it with DMCA requests. My hosting provider will issue me a warning for any DMCA request that they will shut me down within 48 hours if I don't comply. Even when it is clearly not a valid request. Even when the content has already been removed. They don't even check, they just say "do it or else". And I pay them thousands per month. Godaddy is the same way, I have had people complain to them, and then they threaten to shut down the domain.

When you have been threatened repeatedly to be shut down for operating normally you don't take any chances. It isn't worth it.

Have a single "I clicked by mistake" button that resubscribes instead.

Yes, the automated system prefetching links will always click said button.

Not if the button issues a POST request.

The button I was responding about was an "undo unsubscribe". A bot won't click that button, but may follow a link.

Right, I assumed the button would be linked from a subsequent email confirming the unsubscription. You're right, a button in the unsubscription page doesn't help.

The majority of people who clicked on the link did it on purpose, so a better pattern would be to make it unsubscribe immediately with a "didn't meant to unsubscribe? click here to undo" link afterwards.

You're making the mistake that this very article is highlighting: it's not just "people" who click links. An overzealous mail client or browser preloading links would force unsubscribe you without your knowledge or ability to undo.

A single step, a button push, to confirm an unsubscription is fine.

> A single step, a button push, to confirm an unsubscription is fine.

No, it really isn't.

Lots of mailing lists operate exactly as the person you replied to mentioned where after unsubscribing you are given a chance to undo that action. That's a far more respectful way to operate.

The user isn't going to see the "Oops! I need to undo" button when their email client helps themself behind the scenes.

Yet somehow lots of places use the click-one-link-to-unsubscribe method and it seems to work. What are they doing differently?

The follow up confirmation screen feels slimy to me like some kind of cable company retention tactic. That's why I called it a dark pattern.

I don't think it's slimy. They could provide a simple, complete unsubscribe button in addition to a list of subtopics to check/uncheck. Maybe I only want to unsubscribe from their blog, or I still want to receive feature update news but not their sales catalog.

As a person who ends up clicking a lot of unsubscribe links: I definitely see it as slimy.

I would rather companies just didn't subscribe me, so having to click an unsubscribe link is already a problem. The more confirmation they have, the more I take it as biased and manipulative.

If I click a link to claims to unsubscribe me, then that's exactly what it should do. I have no problem with a page to manage account preferences, but don't label the UI element that leads there as unsubscribe.

Do you also not like links called "Contact"?

None of your responses acknowledge or challenge the very real problem that automated systems and expected behavior of GET reqeusts impact your desired behavior of click-to-unsubscribe.

In the spectrum of "buttholedesign", using proper web standards to make sure an action is being taken deliberately is far lower than "intentionally low-contrast skip buttons" and "call to cancel subscription".

Are we all going to just ignore the fact that lots of mailing list operators seem to be able to present a link to unsubscribe without triggering the bot problem?

I think having a URL that unsubscribes people just via a GET request is far more likely to cause problems, 'respectful', 'legal', or otherwise.

What definition of fine are you using?

I don't want to be presented with a confirmation box every time I change something. Nobody reads them - they just click the button that will make it go away.

> I don't want to be presented with a confirmation box every time I change something.

That's much broader scope than what's being discussed here.

> Nobody reads them - they just click the button that will make it go away.

That statement is false. Many people read and care about confirmations.

What you're talking about is very specific personal preferences, not what is generally considered "fine".

It's not all that specific. What I'm describing isn't that far off from what Microsoft found when Windows Vista was presenting a lot of UAC elevation prompts.

The thread is talking about situations where an automated system would 'click' the link though. The automated system is probably not going to go "oh oops, resubbed"

You could probably automate the POST action though. Equivalent of $('#unsub-button').click() on the unsubscribe page load

Github also does it for their logout button for good reason. Is that a dark evil pattern to keep you logged in to their ecosystem? Or just something someone would say who doesn't understand it?

I trust Github. If it were up to me, I'd remove the logout confirmation from Github but having it there doesn't particularly bother me.

When Facebook does it, I do have a problem with it because I don't think their motives are as pure.

> 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.

Kinda seems like he really just wanted to use the word.

I think he only had GET /door/toggle, which cannot be idempotent.

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.

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

I wasn't looking forward to running cable for sensors (I need two reed switches per door, as the doors can stop half-open). The D1s are at the back of the garage, so maybe 8m of cable per switch and two doors = 30-ish metres of cable? (90 feet?)

Range finder seems like the best idea. I was thinking of mounting it on the door motor and pointing horizontally down the track at a reflector attached to the chain/handle.

I love the idea of putting a D1 in the car. Thanks for the link!

You can get commercial Z-Wave tilt sensors for approx ~20USD a piece that will last a year or two on a single battery. With those you can mount them directly to the door (because wireless) but obviously you need a Z-Wave radio on your automation platform for that to work.

In either event, are you sure you need two sensors per door? The garage door can stop at any point, but (to my thinking) it's still only open or closed. If it's open by only a bit, open half way, mostly open, etc... it's all open in my system, meaning someone can get in or out if they want. So limit switches (or whatever) at the closed position can tell you if it's all the way closed or "not closed", which is suitable for automation purposes.

My opener runs a tiny little garage door in parallel with the big door in front of my garage, and monitors the position of the little garage door with simple switches. This is all in the plastic housing that holds the motor. If yours is the same, you might be able to steal the same signal.

Sadly, the little garage door doesn't look like a dollhouse garage door; that'd be too cool. It looks like a wire on a track.

Why not simply have your webserver remember what state the door _should_ be in? Maybe don't rely on that from a security standpoint (eg. GET /garage/status => "closed, everything is secure"), but I suspect it would work for most situations.

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.

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).

“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.

GET requests should have no side effects. In other words NOOP is idempotent

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

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.

> 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.

No not the same result. How would the front page of any news site work then?

yes

IIRC, the rfc uses “safe” instead of “side effect free”, which is very similar, but not exactly the same.

Get should be safe, but that's not the same as indempotent. Delete requests are also indempotent as the final state will always be the same.

Reading from a database isn’t “side effect free”, neither is reading from a mutable variable.

Given that HTTP requests are supposed to trigger database reads that may return a different result after some time, then “side effect free” would indeed be incorrect.

The litmus test is ... does it always return the same output given the same input? If that can change, the it’s not describing a pure function, but a side effectful one.

And the output of a GET request can and does change.

Speaking of which people here aren’t talking of idempotency in a mathematical sense:

f(f(x)) == f(x)

If you really think about it, GET requests aren’t even idempotent ;-)

Having no side-effects means it doesn't cause side-effects, not that it can't be "victim" to them. It's no the same as purity.

> 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.

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).

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.

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.

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?

That would comply with GDPR, and is a valid solution.

It is at least better than asking the email or something even to login to unsubscribe ("update communication preference")

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.

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.

A not-small percentage of users double click links (and buttons, and anything else that needs clicking).

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.

Thanks! Yes I didn't word that properly. :(

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-larr...

> 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.

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.

If the unsubscribe link were unique for each subscriber would the law still be satisfied?

I don't understand how that prevents an automated system from unsubscribing them?

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.

It should be a DELETE imho or a PATCH.

same thing with games running on facebook's platform