This article is so typically dork-disconnected-from-world that it's a bit sad, really.
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.
I agree with the rest of your comment but using SOAP-with-GET and non-javascript delete links as examples is a terrible argument. They're both stupid stupid ideas and can lead to bad things precisely because they violate HTTP. Comet is also a horrible hack but sometimes horrible hacks are needed.
But yeah, "it violates HTTP!" is hardly the best argument against "frictionless sharing" :)
Agreed. I can't imagine that any meaningful percentage of Facebook users care about the HTTP spec.
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.
Using POST would probably make non-geeks even more uneasy about this - i.e. if you try to reload an article you're reading and chrome gives you the ('are you sure you want to resend this content?') pop-up that you're used to seeing when you submit a form, I think any frequent web user would find that strange. Using GET instead (breaking HTTP protocol) lets them slip this by people unnoticed, and I agree with the OP that this is at least worth thinking about.
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).
The javascript would just have to create a form and submit it. Not a big problem at all. Alternatively, create an iframe in which the form is autosubmitted via javascript.
What makes you think that? CSRF vulnerabilities are possible precisely because cross-domain POST requests can be created without violating the cross-domain policy.
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..
"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."
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.
> 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.
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.
The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.
But 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.
using the word 'violates' makes it a bit dramatic but I don't really think hyperbolic. And I believe he's talking about a different definition of the word 'request' than in your comment.
If it's only a protocol violation, I guess Facebook can use JavaScript to generate a POST request instead. And in fact, they should be doing so.
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.
You're totally missing the point. The author points the fact that issuing "GET /interesting-article.html" should NOT have any side-effect. This is the GET that should not have any side-effect. The other GET or POST or whatever it is is the side-effect.
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.
I'm always happy for another article denouncing frictionless sharing, but I think it's a weak argument.
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.
Let's stop for a moment and consider how the web actually works. Your browser sends an HTTP GET request for a page. The response for this page contains HTML and JavaScript. The browser then executes the JavaScript, often making other requests (GET and/or POST) in order to do its work. In the case of most Facebook operations (I haven't looked at this one specifically), JavaScript executed by your browser makes these requests on your behalf to communicate with and display information from Facebook. Google Analytics works this way too, making additional requests to a different server from the page you directly requested.
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.
Agreed, but tracking is different than sharing. Nobody's going to complain that your web server logs GET requests (well, not from an HTTP standpoint, at least), but posting that information to your social networking profile is a little different.
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.
Please read the spec. The authors clearly said that the side-effects cannot be ones that the user is responsible for, not that there should not be side-effects at all. GA's logging is not something that should concern the end user.
As if the rest of the web plays by the protocol rules. How about Amazon (and most other e-commerce sites) showing you the list of last viewed items? User state is obviously changed by GET requests. That's the reality of modern dynamic sites and I don't see any practical problem in this.
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.
Maybe this will educate Users, the reality is that these actions have side effects already. They track you everywhere you go with cookies and create a profile of your surfing behavior.
The Facebook like button is so wide spread and they know every site you visit.
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.
For the last few years I've only browsed FB in incognito mode. The last few days of HN stories has confirmed that that wasn't a bad decision. Perhaps a better decision would be closing out my account altogether.
In regards to violating HTTP, Frictionless Sharing isn't in any way different from every other non-RESTful service/site on the internet. Facebook could have just as easily implemented the same service RESTfully (not violating HTTP), and it wouldn't be any different.
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.
A big reason for this is that it breaks a fundamental contract of web interaction, in place since the beginnings of the web, that users have come to rely upon.
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.
Does a URL shortener violate HTTP when it offers analytics on GET links to the public?
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.
What a bunch of nonsense. 'GET' must be idempotent, that is all.
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'?
Nice find, but I don't really think this is violating anything. It's against the HTTP Spec, sure, but you give it permissions to post stuff on your wall for you.
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.
Like it's so hard to differentiate between a GET that user was not responsible for and which didn't complete, to the one the user was responsible for. As long as facebook makes it easy for an user to turn off an app that's spammy or the one that knowingly posts "I read an objectionable content", I think we are fine. Agreed, apps have more power but as long as users and Facebook have more, they will behave and internet will become a better place.
Using this argument, essentially every website that uses Google Analytics violates HTTP. The GA javascript triggers a GET request every time you visit a page that it's installed on, and the GET request has the side effect of recording your visit.
Most web servers "violate http" in this way when they log the fact that they served the GET request. Very little is done on the web without some side effects.
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).
Maybe this will educate Users, the reality is that these actions have side effects already. They track you everywhere you go with cookies and create a profile of your surfing behavior.
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.