Comment by diggan | Hacker News Reader

Comment by diggan | Hacker News Reader

Parent Full thread

> I'd solve this by warning users who attempt to reuse consumed links that the link has been used already, and likely list broken email providers that I suspect are using software that breaks this. And then wait. Let them complain to their IT, or whomever is responsible for picking broken software.

The thing is, most websites already know how to workaround that particular issue (https://news.ycombinator.com/item?id=42804447), so when users notice that something breaks with just your service and not everyone elses, you can say "Outlook is shit" all you want, the users will blame you for it, since you weren't able to fix what others could, for better or worse.

> You could roll over and decrease your security so that MS can claim they increased theirs

What part of your security would decrease if you "roll over" and what exactly does "roll over" entail here? Websites who've dealt with this issue implemented what I linked to above, they're no more/less secure than the website who didn't manage to work around this issue, they're just less buggy for Outlook users, if anything.

Your description isn't a work around, it's the exact same buggy behavior, just implemented in JS, instead of a malware scanner. GET or POST is less important than user action, if your code consumes a token without user action, it doesn't matter if that's server side or client side, GET or POST.

If outlook is clicking on links or buttons that generate POST requests, then outlook is broken. If outlook is loading a page, and the page without further interaction is sending a POST, that's just as bad, if not worse than expiring the token on that same GET.

I wouldn't call that a work around, would you?

> If outlook is clicking on links or buttons that generate POST requests

It isn't though, it's loading URLs it finds in emails, and then runs scripts on those loaded websites, like many "modern" scrapers/crawlers.

So if your JavaScript on that URL automatically does POST requests on load, those will happen automatically when their scanner loads the website.

But if you instead don't do a POST request on JavaScript load, and do that request when the user presses an actual button on the loaded website, the scanner won't trigger that button automatically (that would be a whole new level of craziness, we're not there (yet))

So yes, it is a workaround. I've implemented this 10s of times already, because it's been an issue for a long time.

Edit: The submission article also makes it abundantly clear that this is the very problem they're suffering from:

> Microsoft’s security scanning will now not only visit the links you mail out, they will also run the JavaScript on your page, and will also send out any POSTs generated by that JavaScript:

The problem is that their JavaScript automatically issues POST request on load, not that Outlook loads and executes JavaScript on the page (although that sucks too, don't get me wrong).

My point was more, sending a POST request IFF a user interacts isn't a work around, but the expected and desired behavior. It's a bug otherwise. Fixing a bug shouldn't be called a work around. A work around is when you can't fix a bug somewhere else.

> you can say "Outlook is shit" all you want, the users will blame you for it, since you weren't able to fix what others could, for better or worse.

Personally, I'd happily blame Microsoft, but the practical significance of this fact is nil.

I am in the very small minority of users who will sometimes complain to our IT when Microsoft forces shit down our throats. But I do this because it feels good, not because I imagine any realistic probability that doing so will make a difference.

Reply on news.ycombinator.com