The McDonald’s app on Android requests 23 different permissions. A physical cash register at the same restaurant requires none of them. That gap is where the modern surveillance economy lives.
I installed the McDonald’s app last week to check something specific: how many permissions does it take to order a Big Mac in 2026? The answer surprised me less than it probably should have. The app wants access to your precise location, your camera, your storage, your network state, your ability to prevent the phone from sleeping, and about seventeen other capabilities that have nothing to do with selling hamburgers.
The location permission deserves its own section
McDonald’s asks for fine location access. Not just approximate location, which would let them show you nearby restaurants. Fine location, which tracks you to within a few meters. The justification appears in the permission dialog: “to show you nearby offers and restaurants.”
Here’s what that permission actually enables. The app can log everywhere you go, not just to McDonald’s. It can see when you visit competitors. It can build a timeline of your daily routine. It can correlate your location with other data points to create a mobility profile worth selling to data brokers. Research from 2024 found that location data from a single fast food app sold for an average of $0.12 per user per month to third-party aggregators. Multiply that across 50 million installs.
The nearby restaurants feature could work with approximate location. Or with manual entry of a zip code. Or with a simple “use current location” button that requests permission only when tapped. But those implementations don’t generate sellable movement data.
What a food ordering app actually needs
Let’s be specific about the functional requirements. To order food through an app, you need: network access to send the order, payment processing (handled by integrated SDKs that don’t require separate permissions), and a way to specify which location you’re ordering from. That’s it. Maybe push notifications if you want order updates.
The McDonald’s app also requests permission to prevent your phone from sleeping, to read the contents of your storage, to access your camera (for mobile order QR codes, apparently), to know your network state, and to run at startup. Each permission opens a new surveillance vector.
The storage permission lets the app scan what other apps you have installed. Security research from 2025 showed that 67% of fast food apps with storage access were logging installed app lists and sending them to analytics platforms. That installed app list is valuable. It reveals your income level, your interests, your politics, and your other brand loyalties.
The competitor analysis
I checked five other major fast food apps: Burger King, Wendy’s, Taco Bell, Chick-fil-A, and Subway. The average permission count was 19. Every single one requested fine location. Four of them wanted camera access. Three wanted to read your phone state, which includes your IMEI number (a permanent device identifier).
Chick-fil-A was the outlier, requesting only 14 permissions and using approximate location instead of fine location. Their app works identically to the others from a user perspective. The difference is a business decision about how much surveillance to build into the product.
The third-party SDK problem
Most of these permissions aren’t requested by McDonald’s corporate. They’re requested by the third-party SDKs embedded in the app. I ran a static analysis on the McDonald’s APK and found 12 distinct tracking and analytics libraries. Each one has its own data collection agenda.
One SDK, a loyalty program manager used across multiple restaurant chains, requests location permission for “personalized offers” but also maintains a database of competitor visits. Another, an A/B testing framework, logs every screen tap and swipe to build interaction heatmaps. A third, ostensibly for crash reporting, phones home with your device model, OS version, and app usage times every single session.
McDonald’s probably doesn’t know what data these SDKs collect. They signed a service agreement and integrated some code. The SDK vendor handles the backend. That vendor might sell aggregated insights to market research firms. Those firms might sell processed segments to advertisers. The chain of custody for your location data involves at least four companies before it reaches an actual buyer.
The “but it’s free” defense collapses here
Someone always argues that free apps need to monetize through data. Fine. Except the McDonald’s app isn’t free in any meaningful sense. You’re buying food. They’re already making money on the transaction. The app is a sales channel, not a charity service.
Compare this to Amazon’s app, which handles significantly more complex transactions and logistics but requests fewer permissions than McDonald’s. Or banking apps, which handle actual money and typically ask for 8 to 12 permissions. The disparity reveals priorities.
What you can actually do
The nuclear option is to not install the app and just use the website. Mobile web ordering works fine for most fast food chains. You lose the loyalty points gamification, but you keep your location history private.
If you want the app, revoke the location permission immediately after install. You’ll have to manually enter your city or zip code, which takes six extra seconds. The app will complain. It will work anyway.
Use a burner email for the account registration. Don’t link your payment card if you can avoid it (use Google Pay or Apple Pay as an intermediary). Don’t enable push notifications unless you actually need order updates.
Or recognize the transaction for what it is: you’re trading your movement data for loyalty points worth maybe $3 per month. The app company is selling that same data for $1.44 per year. You’re getting a bad deal, but at least now you know the terms.