How Expo Is Fooling Everyone
What data does the Facebook SDK within Expo apps send to Facebook?
that is a question best answered by the Expo team or someone from Facebook.
Knowing their capabilities, the sky is the limit.
Excellent question, and we might be able to figure it out with some digging…I’m no expert, but here are my thoughts:
Now, let’s imagine you have an app that’s using every feature of Expo available. A “kitchen sink demo”, if you will. When you’re using this demo app, you can connect your phone to your computer, and not only can you debug the app, and see what sort of calls are being made – you can essentially “dump” all of the traffic going to and from your phone to a log file. This may be noisy, but with an app like Wireshark, you could filter the data and see exactly which bits and bytes are being sent from Expo itself.
Of course, this doesn’t take encryption into account…if they’ve encrypted the traffic (which I sure as hell hope they do!) then you have a new challenge: decrypting the traffic without the key. As shown by exploits such as those against WEP wifi encryption, this is feasible, but not really within the reach of an average dev just trying to snoop around. (Also this may be illegal, yada yada yada, neither I nor Hacker Noon condones illegal activity.)
So in theory it’s possible, but if they’re encrypting the traffic…well, it all depends. If they’re using AES in ECB or CBC modes, a freshman taking a cryptography course could break it. If they’re using something stronger…again, it all depends. A cryptosystem is only as strong as its weakest link.
Come to think of it, if you could debug the app, and catch the app sending data to Facebook before it’s encrypted…you’ve won. But this assumes a lot, especially assuming that the debug build of the Expo library will be used in development. I’m sure they’ve covered their asses to some extent – the question is, how much?
I could go on, but, just like that, you’ve nerd sniped me. Dammit. Back to the internet!
Hi, I’m one of the co-founders of Expo and have worked on it for several years and have the context for why Expo works the way it does. I found several parts of this article to be incorrect or to suggest poor intent, which has never been the case at Expo. Developer trust is one of our greatest values so I’d like to explain more about Expo in a way that hopefully feels clear and understandable.
If you’re interested more in the open-source aspect, check out our main GitHub repository at https://github.com/expo/expo! The GitHub repository contains the source code for the Android and iOS clients; dozens of libraries that provide support for the camera, A/V playback, custom fonts, and more; and the test infrastructure for the apps and libraries.
One part of Expo is the Android and iOS clients that assist you with development. These clients are optional but help manage part of the development workflow (we call this the “managed” workflow). They contain many different native libraries you can use in your projects, and when you are ready to submit to the App Store or Google Play, you can create standalone app binaries with the same native libraries.
Why does the Expo client contain the Facebook SDK? Most of the libraries we maintain are related to device functionality, like the camera, gyroscope sensors, screen brightness, and more. A small number of the libraries provide support for services like Facebook and Google Login — these libraries do include the services’ respective SDKs, including the Facebook SDK.
Expo supports Facebook Login (you can let your end users login with Facebook) and Facebook Ads (you can display mobile ads from Facebook in your app) because several developers needed the features and they are some of the most popular login and ad services. This is the sole reason why managed Expo apps contain the Facebook SDK. Facebook did not ask us to include the Facebook SDK in Expo.
Expo also supports Google Sign-In and Google AdMob for login and ads, respectively, as well as Google Maps. We also have a generic authentication library that works with a variety of OIDC and OAuth 2 services. In general, we prefer creating generalizable, company-agnostic libraries when we can.
To reaffirm, all of this source code is in a public GitHub repository, which is a great place to see our “cards,” to use the article’s metaphor. You don’t just get to see our hand — you can see just about the entire deck in our GitHub repos, where we do our development. And we’ll add an entry about the Google and Facebook libraries to our “Why not Expo?” page so it’s easier to see.
How can I exclude the Facebook SDK from an Expo app? Several Expo apps don’t include the Facebook SDK. You can do this with what we call the “bare” workflow, which gives you a high degree of control over bare Xcode and Android Studio projects.
In contrast with the managed workflow, with the bare workflow you can include and exclude libraries based on your needs. That is, if your Expo project is using the bare workflow and doesn’t include the Facebook Login and Facebook Ads libraries, your app won’t include the Facebook SDK unless you manually added it to your project some other way.
If you are using the managed workflow, the standalone apps will contain the Google and Facebook SDKs. This works for many developers and depending on your needs you can use the managed workflow or choose the bare workflow to customize and compile the app yourself.
Does Expo collect Advertising IDs? The vast majority of Expo apps do not collect advertising IDs, and Expo (the company) does not collect nor use these IDs ourselves. Android and iOS both have advertising IDs, as mentioned in the article. They are used by the libraries for displaying ads (Google AdMob and Facebook Ads) and the Branch library. If you don’t use these libraries in your project, the advertising ID never leaves the user’s device and no service collects it.
One thing I want to be clear on is that Expo does not make money from ads. The ads libraries are solely for developers who choose to display ads in their own apps. We do not display ads to developers nor end users.
How does Expo make money? Generally, our plan for the business is to build services that help developers make and operate their apps. We’ve started with Expo Developer Services, a monthly plan for some services for making apps.
One of the features of this plan is that you get priority access when building your app binaries with the managed workflow. As Expo has grown, more developers are now submitting more builds, which requires more servers that are fairly expensive to operate. We introduced priority builds as a way for business users to help cover the server costs for building apps, which lets us in turn buy more server capacity. Fundamentally, the server cluster is a finite, shared resource and we think it’s fair that those who are paying for it get priority when using it. If you find that your build is taking too long, you can use the bare workflow and build your app binaries on your own computer (you’ll need a Mac for iOS builds).
We strongly believe in keeping the Expo platform free — keeping it free to make an Expo app on your own computer, similar to how it is free to build a web app on your own computer. It’s important to us that students can use Expo for class projects and that developers at companies can try Expo without getting a budget approved up front. We believe this is the best way Expo can succeed.
Like the web platform, we want making Expo apps to be free. And like the web platform, we want developers to be able to use whichever hardware or service providers they want to use. And like the web, some of those service providers cost money if you choose to use them.
These services are optional and part of the managed workflow — Expo manages various parts of app development for you — but you don’t need to use them with the bare workflow. That said, operating services like the app builders and over-the-air updates costs a meaningful amount of money added up across all the apps that use our services. To offer these services in a sustainable way and deliver the high performance and high reliability that projects need, we have to charge for them. There are no disingenuous motives, it’s simply reality. A lot of developers we talk to actually understand this intuitively and tell us they’d feel even better about building with Expo if they could pay for the services they are using. Directionally speaking, Expo services will be more like AWS, for example — there’s a free tier for smaller apps and for larger apps you only pay for what you use.
In summary, the Expo platform is free and open source. You don’t need to pay Expo to make an app, nor do you need to use any of our services. We’ve invested, and will continue investing, much of our time into the bare workflow so you can build your Expo apps on your own computer, host your over-the-air updates on your own web server, use your own push notification service, and so on.
In addition to the Expo platform, we operate and are working on next-generation, optional Expo services to manage parts of your development workflow for tasks like building your app binaries, deploying high-efficiency over-the-air updates, and sending high-volume push notifications. The next generation of these services will take meaningful time to develop and we don’t have a pricing model yet, but we think that AWS’s pricing model works well for a lot of people by aligning our costs with developers’ and charging only for what people use.
Lastly, I want to be unequivocally clear that developer trust is incredibly important to us and we look to do our work with integrity and quality. We made Expo open source, are working on a sustainable business model, and write posts like this to build that trust over time. Our decisions may not resonate with everyone, but this is how we do our work on Expo.
Is it possible you can expand on the Expo managed apps include the Expo SDK?
On this page: https://docs.expo.io/versions/v35.0.0/sdk/facebook/ It says you’ll need to run
expo install expo-facebook. So does it include it by default or do you need to install it for it to be included?
Managed apps currently include the Facebook SDK. When you run
expo install expo-facebook, that command figures out the correct version of the
expo-facebook package for your project and just runs
npm install. The Objective-C and Java code for
expo-facebook is already in the Expo client (for development) and in managed apps (for production).
The Facebook SDK also has some new options to disable more parts of it by default, and then later re-enable those parts programmatically. Ideally an Expo app that doesn’t use Facebook Login nor Ads wouldn’t send any network requests to Facebook. We’ll need to look into these new options more to determine their actual behavior and we plan to do that in the next release or two.
@ide You are the man. That’s about all we need here to sum up the above article. I can’t thank you enough for building Expo—you’ve made my life a lot easier. Thank you for the in-depth response and keep going! Oh and one more thing: TAKE MY MONEY!
After reading all this, still don’t understand, why does expo managed workflow include FaceBook API by default and is not willing to make it an option? Speaking of building trust, writing all this goublety goo does not help to establish trust, making the framework more flexible based on the community feedback and needs would.