7 ms·

Why Facebook's 'Frictionless Sharing' violates HTTP

183 points by alexandros 15y ago

benwerd 15y ago
I bet it violates more than just a networking protocol.
michael_dorfman 15y ago
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.
- gerggerg 15y ago
  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.
jarsj 15y ago
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.
kevingadd 15y ago
This could matter in real life if prefetching web pages sets off frictionless sharing. Does anyone know if it does?
- zhoutong 15y ago
  No. Prefetching a webpage doesn't execute the JavaScript. GET itself is still safe. But web browsing != GET requests
ramen 15y ago
Next up: Why web server logs violate HTTP.
sek 15y ago
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.
- sage_joch 15y ago
  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.
  - deleted 15y ago
    [deleted]
- MartinCron 15y ago
  Maybe this will educate Users 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.
  - sek 15y ago
    I mean that their behavior has side effects, not the violation.
zhoutong 15y ago
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.
- natrius 15y ago
  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. That's exactly how it's implemented.
- nakkiel 15y ago
  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.
  - zhoutong 15y ago
    When you browse the web, you don't GET the pages. Your browser does much more than that. 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?
daveman692 15y ago
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/ 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.
- Lagged2Death 15y ago
  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.
  - kposehn 15y ago
    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.
    - Lagged2Death 15y ago
      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.
mattront 15y ago
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 :)
nightshift 15y ago
https://developers.facebook.com/docs/beta/opengraph/tutorial/ https://developers.facebook.com/docs/beta/opengraph/tutorial... 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.
hamidnazari 15y ago
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.
skrebbel 15y ago
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.
- fleitz 15y ago
  God forbid this guy figures out that Google changes their search results based on GET requests.
- kposehn 15y ago
  > 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.
- rberdeen 15y ago
  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.
eddieplan9 15y ago
So Google Analytics might be the biggest violator of HTTP. Those bastards.
- mooism2 15y ago
  This. "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.
  - georgefox 15y ago
    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.
- alexandros 15y ago
  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.
poona 15y ago
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.
chalst 15y ago
There is no violation of RFC 2616. Two points: 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 https://developer.mozilla.org/en/HTTP#Safe_methods
wandernotlost 15y ago
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.
T-R 15y ago
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.
dorkitude 15y ago
The worst HTTP violator by far is the little "up" arrow I didn't click to upvote this article.
jaekwon 15y ago
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.
spullara 15y ago
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.
dasil003 15y ago
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.
mikeocool 15y ago
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.
justin_vanw 15y ago
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'?
- sid0 15y ago
  But with frictionless sharing it isn't idempotent, right? If I refresh a page I'm reading it'll show up twice in the ticker.
j_baker 15y ago
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.
stretchwithme 15y ago
this is like complaining that someone is violating the "breathe in through nose and out through mouth" rule laid down by Mr Miyagi in The Karate Kid.
barbazfoobuzz 15y ago
facebook still isn't cool enough to support my browser. it's been years. this is a poor excuse since it's ultra-trivial to do so. it's RFC-compliant. no coolness required.
devraj 15y ago
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).

183 points by alexandros 15y ago

I bet it violates more than just a networking protocol.

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.

gerggerg 15y ago
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.

jarsj 15y ago

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.

kevingadd 15y ago

This could matter in real life if prefetching web pages sets off frictionless sharing. Does anyone know if it does?

zhoutong 15y ago
No. Prefetching a webpage doesn't execute the JavaScript. GET itself is still safe. But web browsing != GET requests

ramen 15y ago

Next up: Why web server logs violate HTTP.

sek 15y ago

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.

sage_joch 15y ago
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.
- deleted 15y ago
  [deleted]
MartinCron 15y ago
Maybe this will educate Users 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.
- sek 15y ago
  I mean that their behavior has side effects, not the violation.

zhoutong 15y ago

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.

natrius 15y ago
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. That's exactly how it's implemented.
nakkiel 15y ago
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.
- zhoutong 15y ago
  When you browse the web, you don't GET the pages. Your browser does much more than that. 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?

daveman692 15y ago

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/ 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.

Lagged2Death 15y ago
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.
- kposehn 15y ago
  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.
  - Lagged2Death 15y ago
    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.

mattront 15y ago

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 :)

nightshift 15y ago

https://developers.facebook.com/docs/beta/opengraph/tutorial/ https://developers.facebook.com/docs/beta/opengraph/tutorial... 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.

hamidnazari 15y ago

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.

skrebbel 15y ago

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.

fleitz 15y ago
God forbid this guy figures out that Google changes their search results based on GET requests.
kposehn 15y ago
> 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.
rberdeen 15y ago
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.

eddieplan9 15y ago

So Google Analytics might be the biggest violator of HTTP. Those bastards.

mooism2 15y ago
This. "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.
- georgefox 15y ago
  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.
alexandros 15y ago
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.

poona 15y ago

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.

chalst 15y ago

There is no violation of RFC 2616. Two points: 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 https://developer.mozilla.org/en/HTTP#Safe_methods

wandernotlost 15y ago

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.

T-R 15y ago

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.

dorkitude 15y ago

The worst HTTP violator by far is the little "up" arrow I didn't click to upvote this article.

jaekwon 15y ago

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.

spullara 15y ago

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.

dasil003 15y ago

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.

mikeocool 15y ago

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.

justin_vanw 15y ago

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'?

sid0 15y ago
But with frictionless sharing it isn't idempotent, right? If I refresh a page I'm reading it'll show up twice in the ticker.

j_baker 15y ago

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.

stretchwithme 15y ago

this is like complaining that someone is violating the "breathe in through nose and out through mouth" rule laid down by Mr Miyagi in The Karate Kid.

barbazfoobuzz 15y ago

facebook still isn't cool enough to support my browser. it's been years. this is a poor excuse since it's ultra-trivial to do so. it's RFC-compliant. no coolness required.

devraj 15y ago

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).