Sorry, but this really feels like hyperbole to me. For two reasons:
1) Before any action is shared back from the site to Facebook, the user has agreed to authorize that site (application) and add it to their timeline. Part of that dialog shows what's going to happen (https://developers.facebook.com/docs/beta/authentication/).
2) There are plenty of other examples around the web where submitting a HTTP GET request results in an action. For example, clicking an up arrow on Hacker News submits a GET request which increases the karma score on another author. What becomes more important is how you protect against XSRF and crawlers not accidentally changing state within your app.
Before any action is shared back from the site to Facebook, the user has agreed to authorize that site (application)...
That sounds great in theory.
I just looked at my Facebook "App Settings" page and found two applications/sites that I had supposedly authorized to interact with my Facebook profile. I don't know what they do, and I don't recall ever deliberately granting anyone or anything, especially the two sites in question, any permission to interact with Facebook on my behalf.
The App Settings page will tell you when last you used it, and when last they accessed information (once you click on "Edit").
If you are truly concerned about this happening behind your back (rather than making a comment about how easy it is to not recall adding something), you can contact me (neilblakeymilner at fb.com) and I will try connect you with someone who might be able to help you find out when you did it and whatever other information might be attached to that event (I don't really know what, if any, we keep on that event type).
Feel free to contact me as well if you are sure that you didn't authorize them. I am not sure I can help, but I will try.
There are only a select few applications that get authorized automatically when you use them (Instant Personalization - https://www.facebook.com/instantpersonalization/), but they only get read access to some basic information that you share with "Public", and they have to follow pretty stringent guidelines in terms of how they store and use the data, and they have to show you how to opt out of the experience when you visit.
This probably is not the case with you, but sometimes people find out that some browser plugins (even ones that do useful things, not just "show who viewed your profile" types) that they are using do malicious things, or discover that their credentials were compromised due to phishing or because of a password dump when they report weird things like this (although the team I'm on do try our best to prevent both of these sorts of things).
To be fair, that doesn't mean it is their fault you allowed them to do so. It is indeed your responsibility to look at what you allow to access your profile and what you deny that access to.
When I say "I don't recall," I guess I'm using understatement in a bad place for it.
One of the sites in question was Bing. I don't use Bing.
There is no way in hell I authorized these apps. And this isn't a case where two apps from a long list seem suspicious; I've never authorized any apps, ever.
The Facebook guarantee that authorization is required has no technical enforcing measure; it's toothless bullshit.
We're trusting the greater Facebook ecosystem to uphold such policies and guarantees out of the goodness of its collective heart. Ha. Ha. We're also trusting Facebook itself to accurately list such relationships on their Apps page. I don't see why such trust is warranted, at this point.
At least in Bing's case, it may have been automatically added as part of some sort of partnership. Not that it's any less sleazy to add (and authorize) apps on your behalf without your knowledge.
> ... clicking an up arrow on Hacker News submits a GET request
For the curious, (from peeking at the source) it's a anchor tag with onclick Javascript that overrides default behavior if js is active. Before checking, I thought it might be AJAX, but it's much simpler. The script simply loads a background image with the info in the link (but doesn't add it to the DOM, so there's no reference after the function returns.
The entire relevant server communication portion:
// ping server
var ping = new Image();
ping.src = node.href; // Where node is a ref to the clicked anchor
Breaking the HTTP GET having no side effects is important for page speed up utilities. Those try to predict what you will want to click next and GET a bunch of resources behind your back in anticipation. Stuff would show up in your news feed that you never clicked.
This is precisely why those kind of page speed up tools never took off. Chrome now has a mechanism for a page author to explicitly request this behavior, but in the general case, it has never worked.
1) Before any action is shared back from the site to Facebook, the user has agreed to authorize that site (application) and add it to their timeline. Part of that dialog shows what's going to happen (https://developers.facebook.com/docs/beta/authentication/).
2) There are plenty of other examples around the web where submitting a HTTP GET request results in an action. For example, clicking an up arrow on Hacker News submits a GET request which increases the karma score on another author. What becomes more important is how you protect against XSRF and crawlers not accidentally changing state within your app.