Why Facebook's 'Frictionless Sharing' violates HTTP
andothernoise.blogspot.com
andothernoise.blogspot.com
Any site that uses SOAP violates HTTP (use POST also for GET-style requests). Any site that has delete links (as opposed to buttons) violate HTTP (barring onclick ajax action, that is). The big mega bucketload of sites violating HTTP this way (GET having severe side effects) is the very reason offline browsing and prefetching never took off much. Every site that uses comet very much violates HTTP.
This is no "message to the future to Mark Zuckerberg". It's just using the available tools for the job to their limits.
Note, I'm just as much against the whole frictionless sharing thing as most people here. But the moment we allow geek nonsense like this to overtake the real arguments is the moment the world will stop taking it seriously. This is what happened to the net neutrality debate ("net neutrality"? who made up that term? how will i ever make my mom care about that?), let's not let it happen here.
Well said! I'm not against frictionless sharing myself (different can of worms, not for this thread) but I'm glad to see another person look at this objectively.
JavaScript in modern web apps has made the distinction between GET and other HTTP methods irrelevant to users. Simply changing these "frictionless sharing" apps to use POST instead of GET doesn't address anyone's concerns.
That said, at least FB requires you to approve this. Ads have been doing this kind of thing for a while now, and i'm not sure how I feel about it (I recently was browsing for pictures on art.com and didn't end up buying anything, but for the next month everywhere I went on the web was showing me the exact pictures I had been browsing).
But yeah, "it violates HTTP!" is hardly the best argument against "frictionless sharing" :)
The author points to something that we're going to loose (or perhaps that we already lost). Now, ads are the only nasty thing that break the guaranty of side-effect-free GET requests. And this is the only thing that matters for geeks and non geeks.
A human-oriented rant would say: "When you visit a page, you don't have to worry about other parties knowing it because it's guaranteed that way. This is about to change. Act now." As far as I'm concerned, it means the same thing. This is HN, not TechCrunch..
I'm not sure if you only mean "your friends" when you say "other parties", but there are plenty of people that already know when you visit a site (ad-tracking).
Besides, "it violates http get" is still a horrible argument.
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.
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.
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.
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).
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).
That doesn't mean it doesn't violate the HTTP spec. At all.
Maybe so, it just means it doesn't matter much in the grand scheme of things.
> ... clicking an up arrow on Hacker News submits a GET request
The entire relevant server communication portion:
// ping server
var ping = new Image();
ping.src = node.href; // Where node is a ref to the clicked anchorBut the user did request the side-effects, when he installed the app, and approved the TOS which specifically said that there would be "frictionless sharing".
Personally, I'm not interested in oversharing, so I'll avoid these apps; but, hypothetically speaking, if I were the kind of person who wanted his friends to know what he was listening to on Spotify, it would be a major pain in the ass to have to manually post a separate update to share the title of each song every three minutes. For this use case, it makes much more sense to install an app that will auto-post the songs, giving prior approval up front, and skipping the friction of asking again with each song.
To suggest that this violates HTTP seems more than a bit hyperbolic.
The permissions and responsibilities of a user should not be associated with the type of request. Although it's true that users should not be responsible for a GET request, but the retrieval is based on the web page itself. The Facebook SDK will generate other requests automatically because the permissions have already granted. The GET request is only the trigger. (Imagine you have already agreed to post everything on ReadWriteWeb to Facebook through their reader app by a POST request, all these are hidden until you read an article. The side effects were already generated.) So I think this is not a protocol violation.
That's exactly how it's implemented.
The author goes as far as criticizing other side-effects already in place; an example of which is ads. Because you see when you browse an article about Herpes, then you encounter ads about Herpes drugs on every website.
I got hit by this while looking for paid webmails. After a few searches on Google, I started to see ads for atmail on every single page.
There are people who believe it's a violation and I'm one of them.
EDIT: please don't point at Do Not Track or other work-arounds because that's all they are.
If you really GET the page and parse the HTML yourself, you won't get these ads, for sure.
If Facebook uses POST in their JavaScript, then what's wrong?
On one side you have the fact that this is not technically an HTTP violation, because it is not the GET request itself that is triggering anything. It's javascript running in a loaded page after the GET request is completed.
On the other side you have the fact that Facebook does not care about what some tiny group thinks. Even if it were a true technical violation, Facebook doesn't give half a fuck about what web purists think; they will only change their behavior when there is a massive uprising among a significant portion of their user base.
Attempting to make it a technical issue detracts from the social contract argument which is the real issue, and also one that can be explained to anyone: you read a page and Facebook posts it to your newsfeed. Even your mom understands that explanation, and it probably freaks her out. We need more people trumpeting this from the tree tops (outside of geek blogs too) because I think Facebook is ruining it for the rest of us who would like to use some of these techniques to provide actually useful services instead of shitting all over user's privacy to make a quick buck before the government decides to get involve and lock everything down.
Unless the website in question has a back channel directly to Facebook, through which it communicates information about the GET requests you've made, the initial GET request has nothing to do with the data sent to Facebook. Furthermore, because of browser security limitations, this back-channel approach is not always even possible, since the original site does not typically know your Facebook ID (this may not be true for some sites with which Facebook has special partnerships, e.g. Yelp and TripAdvisor). Only requests made to facebook.com would have the cookie information that identifies you.
In summary, the HTTP GET request you make to fetch a web page has nothing to do with the information sent to Facebook, and HTTP's recommendations about GET requests have nothing at all to do with these other requests.
Also, people have been senselessly abusing HTTP for years.
"GET requests should have no side-effects" was never supposed to mean "you can't log GET requests". This timeline thing just seems to be logging parts of your web activity: a privacy can of worms to be sure, but not a HTTP violation.
That said, there are certainly very similar cases out there already. For example, when you read a thread in many forums (vBulletin, at least), it updates your public (or semi-public) profile to say you were last seen reading that thread. I've never particularly cared for that either.
FoF (Fear of Facebook) is a really popular game these days :)
1. The implementors RFC 2616 is concerned with are: (i) of the server involved in a connection, (ii) of the client to that connection, and (iii) of the network that joins the two. Facebook's involvement as a server ended before these connections became live, and so is not one of (i)-(iii).
2. The notion of safety here is in the sense that inserting arbitrary get requests into a sequence of transactions between client and server will not change the semantics of those transactions. It does not have anything to do with what code the user might have asked the browser to run on receipt of the results of a GET request.
See, e.g., Mozilla's documentation of HTTP: A safe method is a method that doesn't have any side-effects on the server, from https://developer.mozilla.org/en/HTTP#Safe_methods
I would be very interested in my Facebook database dump.
I think that running around shouting "HTTP Protocol Violation!" will likely be counterproductive. The average user doesn't care about the purity of HTTP Protocol verbs. Heck, I'm a developer and I don't care that much.
Prefetching a webpage doesn't execute the JavaScript.
GET itself is still safe. But web browsing != GET requests
A quick look over the tutorial, it seems that a HTTP POST is actually made to declare that an "action" (e.g. read, watched, listened) took place.
You would also need to be authenticated into Facebook and the app would have to be authorized to post the action as others have pointed out.
GET requests have the stateless/idempotence constraint so that they're cacheable, and timing between requests, out-of-order requests, and multiple requests don't become an issue. The 'accountability' referred to in the post is about users of the API - they shouldn't be expected to be aware of server state/side effects, in the same way that users of a function call shouldn't be expected to be aware of its implementation/side effects. It's an engineering constraint - it's not about honorably keeping end-users unaccountable for reading your webpage.
How have users come to rely on GET? Ok, it makes a useful "Would you like to resubmit this action?" popup when you click the back button. And it can be useful to prevent XSF attacks. But neither of these is really relevant to frictionless sharing. Really the only thing I can think of that may be problematic is the possibility that spammers might be able to use it for spam. But then again, I'm pretty sure I violate HTTP on a daily basis. Maybe I'm one of the bad guys.
I think the OP should understand that HTTP is a leaky abstraction.
GET requests always have some side effect, either on the server end or the client end.
Server A and Server B.
A GETs B's data and and offers a mutated version of it, which B GETs, and further mutates. Side effects with no POSTS! This is natural too, in a distributed environment, since each agent should be responsible for mutating its own state, rather than have B POST something to A. You can't abstract this dynamics into HTTP, but you can use HTTP to handle the underlying communication mechanics, like caching and authorization.
Facebook is big enough that all sorts of sophists are going to come out of the woodwork and make plausible-ish arguments against everything they do. The motivation to do this isn't that it is good or something, it's because if you can say something bad about facebook, your comment can become news. That doesn't mean they shouldn't be scrutinized, but it also doesn't mean that we should pay attention to stupid articles like this. Or does the 'andothernoise' author think that collecting analytics 'violates http'?
This reminds me of this guy I met a few months ago who was freaking out about the fact that he saw his facebook profile photo and some of his friends' photos on some website and he was all like 'facebook has sold my information to this website'. Took me a while to convince him what was going on. Please let's try not to make non tech savy people freak out by this kind of allegations.