5 ms·

Reminds me of something that happened to a mate. He created a database for a project and while it was still in testing he generated a very long random number an

Reminds me of something that happened to a mate. He created a database for a project and while it was still in testing he generated a very long random number and made it into a URL to reset everything. It was not linked to from anywhere and he sent it once to the client over a Skype message. He gets a call from the client a few days later to ask if there is a problem as the database had emptied itself. He finds one visit to the page in his logs. From an IP located in Redmond. He reckons they were scanning URLs from Skype and using them to help populate Bing.

ambicapter 7y ago
Wow, that's...Redmond's fault in this case? You can't guarantee every URL you scan is going to be idempotent. That's a hell of an oversight on their part.
- lucideer 7y ago
  I completely agree with your comment but... automatically hitting URLs to create link previews in messenger apps is a common practice, and one that seems to have been (frustratingly) accepted by the mainstream of developers and users alike. This might be MS' fault, but it's also Facebook's, Slack's, pre-FB-WhatsApp's, to name just a small few of many. <aside> On the other hand, if you're putting up a GET endpoint that's not only not idempotent, but unauthenticated and wipes your whole DB. Even on a test site. Blaming MS for your troubles is a bit much.
  - Kalium 7y ago
    This is a practice that exposes the tension between protecting users from malicious use and privacy at scale. A lot of malicious links get sent over messenger systems, and loading them is often the only good way to find out which ones are or aren't. But wait! Surely there are other possible approaches. Can't users just report spam? Surely there are clear usage patterns that can be detected too! These are valuable and useful approaches, but have historically proven unequal to the task. It can be tricky to spot a spam campaign spread over N accounts - only the most basic forms of spam are really obvious. URLs are easily disguised and changed. Loading the URLs and checking the contents that come back is one of the better approaches. Users also don't tolerate a bunch of spam. They will migrate away. So, yes, anyone who makes a GET endpoint into an unauthenticated change-things URL deserves all the misery they get.
  - mort96 7y ago
    I don't even see the issue. Link previews are super useful, GET requests are guaranteed to not have side effects. There are privacy issues related to sending the requests from the user's device, but those don't apply if the servers instead of the app makes those requests. It's really not the messenger services' problem that someone's web app claims to speak HTTP but doesn't.
ceph_ 7y ago
He had an unauthenticated page open to the internet that wiped the database? That is entirely his fault.
- inflatableDodo 7y ago
  Oh, I completely agree. It was nevertheless interesting that Microsoft was apparently visiting URL's in personal skype messages.

ambicapter 7y ago

Wow, that's...Redmond's fault in this case? You can't guarantee every URL you scan is going to be idempotent. That's a hell of an oversight on their part.

lucideer 7y ago
I completely agree with your comment but... automatically hitting URLs to create link previews in messenger apps is a common practice, and one that seems to have been (frustratingly) accepted by the mainstream of developers and users alike. This might be MS' fault, but it's also Facebook's, Slack's, pre-FB-WhatsApp's, to name just a small few of many. <aside> On the other hand, if you're putting up a GET endpoint that's not only not idempotent, but unauthenticated and wipes your whole DB. Even on a test site. Blaming MS for your troubles is a bit much.
- Kalium 7y ago
  This is a practice that exposes the tension between protecting users from malicious use and privacy at scale. A lot of malicious links get sent over messenger systems, and loading them is often the only good way to find out which ones are or aren't. But wait! Surely there are other possible approaches. Can't users just report spam? Surely there are clear usage patterns that can be detected too! These are valuable and useful approaches, but have historically proven unequal to the task. It can be tricky to spot a spam campaign spread over N accounts - only the most basic forms of spam are really obvious. URLs are easily disguised and changed. Loading the URLs and checking the contents that come back is one of the better approaches. Users also don't tolerate a bunch of spam. They will migrate away. So, yes, anyone who makes a GET endpoint into an unauthenticated change-things URL deserves all the misery they get.
- mort96 7y ago
  I don't even see the issue. Link previews are super useful, GET requests are guaranteed to not have side effects. There are privacy issues related to sending the requests from the user's device, but those don't apply if the servers instead of the app makes those requests. It's really not the messenger services' problem that someone's web app claims to speak HTTP but doesn't.

ceph_ 7y ago

He had an unauthenticated page open to the internet that wiped the database? That is entirely his fault.

inflatableDodo 7y ago
Oh, I completely agree. It was nevertheless interesting that Microsoft was apparently visiting URL's in personal skype messages.