
Why Facebook's 'Frictionless Sharing' violates HTTP - alexandros
http://andothernoise.blogspot.com/2011/09/why-facebooks-frictionless-sharing.html
======
skrebbel
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.

~~~
rberdeen
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.

~~~
cousin_it
Implementing "frictionless sharing" with POST doesn't look trivial to me,
because browsers treat cross-domain POST requests more strictly than GET.

~~~
fleitz
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.

~~~
cousin_it
Doesn't that break the back button, making it no longer "frictionless"?

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

~~~
Lagged2Death
_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.

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

~~~
cousin_it
I just went to my App Settings page and also found multiple apps that I know
for certain I didn't authorize.

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

------
michael_dorfman
_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
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.

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

~~~
nakkiel
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
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?

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

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

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

~~~
mooism2
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
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.

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

------
chalst
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>

------
ramen
Next up: Why web server logs violate HTTP.

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

~~~
MartinCron
_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
I mean that their behavior has side effects, not the violation.

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

~~~
zhoutong
No.

Prefetching a webpage doesn't execute the JavaScript.

GET itself is still safe. But web browsing != GET requests

------
nightshift
[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.

------
T-R
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.

------
benwerd
I bet it violates more than just a networking protocol.

------
j_baker
_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.

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

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

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

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

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

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

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

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

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

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

