
If you care about user privacy, don’t use Facebook JavaScript SDK - emmaglossy
https://simplelogin.io/blog/do-not-use-facebook-sdk/
======
tr33house
I thought this was more commonly known... In terms of understanding browser
history, The Facebook like button and Google's ad pixels and Chrome web
browser are perhaps the biggest offenders. I'd argue that they were
specifically created for the express purpose of collecting more user
information - for better ad targeting and whatever else

------
r_singh
Original article from Dev.to: [https://dev.to/simplelogin/if-you-care-about-
user-privacy-do...](https://dev.to/simplelogin/if-you-care-about-user-privacy-
do-not-use-facebook-js-sdk-1j3e)

I've recently implemented authentication for my project and I would just like
to say to all the relatively amateur programmers out there: for web based
authentication just stick with HTTPOnly SECURE cookies with DB backed sessions
that you can revoke.

The reason I'm saying this is that there's way too many posts talking about
JWT (which isn't suitable for newbies), Oauth (which is more useful if you
have separate authentication and resource servers) and other token based
mechanisms which are what cookies are except more suitable for non web based
clients.

~~~
mac_was
I don't think that storing creds is suitable for newbies either. All
authentication is complex and just using HTTPOnly and DB backend is not a
solution at all.

~~~
r_singh
Depends on what the project is and also doesn't change the fact that this
doesn't happen.

Most solo bootstrapped projects are not popular enough initially for someone
to spend money / effort to hack them. When they do become somewhat popular
though (very small minority of course), I suspect most founders bring experts
on board, as they absolutely should.

> just using HTTPOnly and DB backend is not a solution at all

My comment was not meant to be exhaustive and does not list all
vulnerabilities. Just in context of some of the suggestions in the article.
Using a mature framework like Django can protect you from other
vulnerabilities CSRF, XSS, SQL Injection to some extent.

~~~
some_random
>Most solo bootstrapped projects are not popular enough initially for someone
to spend money / effort to hack them.

Strong contender for Most Horrifying Thing I've Read This Morning.

~~~
mandelbrotwurst
It's good practice to consider the likelihood of attack in your threat model
if you care about the expected payoff associated with your security efforts.

~~~
Karunamon
When that threat model necessarily includes bored script kiddies and automated
APTs?

------
MobileVet
> If you care about user privacy, don’t use Facebook.

Fixed that for you...

~~~
dylan604
I was going to say the same thing, only in the form of "Duh". Also in the news
today, the sky is blue, grass is green, and fire is hot. How in 2019 would any
developer believe that any social platform cares about privacy is beyond me.
If a social platform is offering anything (the platform itself, SDKs, APIs,
etc) for free, then they are going to make money from you some other way. What
ever they are offering cost them money to develop, but they did not do that as
a charity. This maybe a bit preaching to the choir, but that's how you get the
choir to sing. Plus, maybe someone new reads this.

~~~
K0SM0S
Indeed obvious to some but necessary to hammer until everyone gets it —
especially the business types who make decisions, as new devs themselves would
quickly grow to learn this.

> What ever they are offering cost them money to develop, but they did not do
> that as a charity.

True! Yet... I keep thinking about `http` (the protocol), or Apache, IRC, and
countless other software techs that were just 'given' to (and are maintained
by) the world, courtesy of their makers, and/or bodies like IETF work groups,
etc.

Case in point: "social" is basic at an elementary level (it's just CRUD, over-
the-network), but at scale becomes insanely costly. The limitation/exclusivity
factor thus doesn't seem to be software magic but rather infrastructure, piles
of money, before sustainability or profitability come into play. This is what
the monopolies stem from, only compounded by some Meltcafe/"network" effect
(friction to switch, passive positive peer pressure inwards, passive negative
outwards).

So in thinking of an alternative future path for social tools (SDK) and meta-
tools (platforms, interop, work groups, etc), I think it's worth considering
the infrastructure problem first. My money is on distributed and (partially
but 'enough') decentralized systems (think bittorrent, tor, even DNS
fundamentally), but regardless it belongs to the wider category of
mutualization of resources (cloud vs on-prems debate, E2E crypt, etc). The
solution _must_ be preferable in terms of cost otherwise it's just not gonna
happen.

~~~
dylan604
> True! Yet... I keep thinking about `http` (the protocol), or Apache, IRC,
> and countless other software techs that were just 'given' to (and are
> maintained by) the world, courtesy of their makers, and/or bodies like IETF
> work groups, etc.

The difference here is that the social platforms have been developed as a for
profit company. Granted, FB has improved some of their underlying
technologies, and released them back to the public in the way open source is
meant. I do give them credit for that. However, the SDKs and APIs etc are
direct work made by the platform. These tools are made specifically for
interacting with that platform. They have every right to monetize that work.
While some of us (at least I do) believe their method of making that money is
super shady/unethical/etc, it is their business model. Other companies like
Apache, Redhat, etc also offer us free things to use/play with while
monetizing their enterprise/support services. A much more ethical method in my
opinion.

~~~
K0SM0S
You're totally right. I agree, and wasn't disputing these facts indeed. Just
thinking out loud I guess...

> Other companies like Apache, Redhat, etc also offer us free things to
> use/play with while monetizing their enterprise/support services. A much
> more ethical method in my opinion.

Totally, this general business model can get as close as it gets to
_sustainable_ open-source. It seems hard to pull off though, lots of dead
startups and projects out there, despite a few resounding successes.

------
taneq
The last two words of the title seem rather superfluous.

~~~
emmaglossy
Sometimes you don't really have a choice if all your friends and family use
Facebook...

~~~
mikro2nd
No. Really. You _do_ have a choice. Exercising unpopular choices frequently
requires a spine.

~~~
thsealienbstrds
Individually, you have a choice. But not using e.g. WhatsApp needs to be a
collective decision or it won't work because everybody else is still stuck in
there.

~~~
mikro2nd
There is no such thing as a "collective decision". There is only the decision
of each person. Any movement to quit these sickness-inducing manipulators has
to start somewhere otherwise you end up like those Buddhists who won't enter
Nirvana until all other creatures are also ready to enter Nirvana, so they all
end up hanging about outside the gates (as it were...), forever waiting.

The decision to be the first,... to lead,... to tread without trepidation
where others fear to go,... that's what I called _growing a spine_. "Won't
work because everybody else is still stuck in there" is simply an expression
of that fear.

~~~
thsealienbstrds
Let's say you run your own mail server. How much privacy do you really gain if
99% of the mail that comes in and goes out passes through Google servers? It
doesn't matter what you do by yourself. You just can't expect everybody to run
their own mail server. I run my own mail server, and while I'm happy to be
self-reliant, it's hardly a win for my privacy (also, mail server
administration is a pita).

Same goes for every other communication tech. Just because your endpoint is
not spied upon, if every other endpoint is spied upon you gain nothing. If you
don't use WhatsApp, but all your friends use WhatsApp to talk about you then
you gained nothing.

If you really believe there is no such thing as collective decision-making
then imho you already gave up in the fight for privacy.

But even if we boycot Google and Facebook, they are not the main problem.
Their business model is the main problem. Spying on your users, training
predictive models, and using those models to exploit people is simply too
profitable, and therefore too attractive for any profit-seeking company to
ignore.

Until we solve that problem by deciding as a society that these business
models are not ok, this 1984-like world we currently live in will be our
reality.

------
valona
Why would any developer or engineer who has even an iota of consideration for
privacy, web standards, and, indeed, humanity want to work for such a
repugnant company as Facebook?

~~~
xrisk
Because a lot of people aren't privileged enough to be able to quit their job
on the spot.

~~~
Zelphyr
OP never said anything about quitting on the spot. The question was why would
one go to work for such a company knowing, as one must these days, how vile
that company is. Another facet to the question is why wouldn’t one look for
and take another job after they realize how disgusting a company like Facebook
is?

~~~
xrisk
Probably makes them more money I gues.

I wouldn't personally – I'm about as anti-Facebook as it gets, but a lot of
people (especially people not coming from a "tech" background) don't really
appreciate the kind of shit Facebook pulls.

------
z92
That brings up the question : does Facebook get any less information because
you used a 3rd party OAuth library to authenticate from FB, instead of using
FB's own SDK which injects an iframe?

~~~
iscoelho
The point of the article was that Facebook gets information on not only those
who are using Facebook to login, but those who aren't, because the "Login with
Facebook" button is an iframe when using the SDK.

OAuth does not have this issue.

If you choose to login with Facebook, it is implicit that Facebook receives
information.

------
nguyenkims
Article author and SimpleLogin creator here. Surprised and happy that my small
rant at Facebook got so much attention from HN!

I wanted to give a bit of context on this article, the story is a bit long
though and there was no TLDR.

Here it goes: I wanted to protect my online privacy and having worked in
advertising before, I know that user email, in addition to the cookie, is
usually the common denominator to cross-reference user data. I tried,
therefore, to generate a random email whenever I signed up on a new website
via temporary email services like temp-mail but there are 3 issues: a. I can't
remember which email I used. This problem is alleviated with password manager
though. b. No way to reset password later as the email is already expired.
This is also not fair if the website happens to be a good (aka not spammy) one
and just want to contact me. c. The flow is unbearable: I need to go to temp-
mail, generate a random email, go back to the website, check temp-mail for the
activation email, etc.

I dreamt to have a universal login button, like the "Login with
Facebook/Google" one but without all the tracking and that can generate a
random email at runtime. So SimpleLogin was born.

When creating SimpleLogin SDK, I tried to reverse-engineer popular SDKs like
Facebook and Google to learn from them and discovered their not-very-ethical
approaches. I haven't found any article talking about these practices so I
decided to write one up.

Voilà.

I want to be as transparent as possible about the technology I'm using so if
anyone has any questions, please feel free!

------
allovernow
Tangentially related: is there any reason to be suspicious of/careful with
react/redux? We've been using it internally for front end stuff, would be nice
to know if there's any weird default tracking going on, however unlikely...

~~~
pricci
I don't think so. If you serve the library yourself (don't use an external CDN
to load it) there shouldn't be any connections to 3rd parties, at least I've
never seen one in the 'network' tab of my browser's dev tools.

Also, I want to believe that, being open source, people would already
discovered something fishy.

------
AndrewStephens
The moral of the story is that any time your page requests resources or
javascript from a third-party source, you are handing over some information
about your users to that third-party.

Did you get your user's consent to do that? Probably not.

------
dep_b
I've always tried to get rid of it in the native apps I built in favor of the
web based login. It's absurdly big in terms of added download size for a login
screen and usually used once. Even with the native SDK it's still a jarring
experience in most apps and if you pre-cache the screen it's about as instant
as the native implementation. And you app starts don't get tracked every time.

------
Tepix
Heise offers a privacy friendly alternative (German) called socialshareprivacy
:

[https://www.heise.de/extras/socialshareprivacy/](https://www.heise.de/extras/socialshareprivacy/)

------
tomaszs
Never used it. As much as i don't like user account as a concept, and don't
like implementing it either, implementation of any Oauth, Facebook login or
any other is just nightmare. No users no problem i guess :)

------
buboard
Alternatively, only use SDK in login page, and keep the login page separate,
or use a click even to load it. And after login is done, you no longer need to
load the SDK ever again.

------
taormina
If you care about user privacy, don’t use <any> Facebook SDK.

------
diminoten
Who cares what _I_ care about, the real question is what do my users care
about.

It all depends on what users will tolerate in the name of convenience.

~~~
falcolas
As pointed out in the article, not using the SDK does not preclude
authenticating with a Facebook account. It just requires a bit more work on
your end to protect your non-Facebook users.

So it _does_ come down to what you care about.

~~~
diminoten
"Don't use" and "only use for people who actively opt-in" are two separate
things, so _no it doesn 't_ come down to what you care about.

I'm saying give people choice, let _them_ figure out what they care about.
Making the choice for them is bad business and bad ethics. You don't know
better than your users.

~~~
falcolas
Non-Facebook users are unable to opt out of Facebook tracking if you use the
Facebook sdk. That’s the point of using the oauth standard, it allows those
users a choice not available with the sdk.

~~~
diminoten
You can choose to load the SDK or not, e.g. only when the "Log In With
Facebook" button is pushed.

~~~
falcolas
A little bit of research indicates that this is still a non-trivial amount of
work from the developer; that the developer has to _make the choice_ to
protect the privacy of their non-Facebook users by dynamically loading the
Facebook SDK.

