GrapheneOS Sandbox – Which Permissions You Should Actually Grant

In this video I walk you through the sandbox principle and how to set permissions intelligently.

A False Sense of Security

An app launches. Five popups appear. Most users reflexively tap "Allow". That's exactly where the false sense of security begins. The sandbox only protects you if you know how to make decisions. GrapheneOS is not a magic shield. It doesn't make decisions for you. It just ensures that bad decisions cause less damage.

What Does "Sandbox" Actually Mean Under GrapheneOS?

Under GrapheneOS, every app runs in isolation:

• No silent cross-access to other apps
• No hidden system privileges
• No special rights running in the background

Even Google Play Services are ordinary apps under GrapheneOS. No god mode. No system-wide omnipotence.

Important:

• Sandbox does not mean an app is automatically harmless
• Sandbox means damage is contained

The responsibility for making sensible decisions stays with you.

The Most Important Rule

The core rule for every permission:

An app gets only what it strictly needs for its core function.

Everything else is optional convenience – and that's exactly where most problems originate.

How to Read Typical Permissions

Network Access

Typical claim: "The app won't work without network access"

Assessment:

• Messenger, browser, maps → makes sense
• Flashlight, calculator → red flag

Decision logic:

• Core function online? → allow
• Convenience only? → weigh it up
• No connection? → deny

Location

Location data is among the most sensitive information there is.
Distinction: Precise / Approximate / Never.

Recommendations:

• Navigation → precise (temporarily)
• Weather → approximate
• Social apps → usually no

GrapheneOS lets you enable location on demand and disable it again immediately.

Microphone and Camera

Clear rules:

• Only while actively in use
• Never permanently
• System toggles show live access instantly

Microphone and camera are high-risk permissions. When in doubt, grant less rather than more.

Files and Storage

Distinction: Full storage / Individual files / Media only.

Recommendation:

• Always granular
• Never blanket access unless absolutely necessary

Notifications

Notifications are convenience, not security.

• Push is not a requirement
• Many apps abuse notifications
• Fewer push notifications means more calm and control

Background Activity and Battery Optimization

Background activity means permanent presence.

Risks: Increased tracking potential, higher battery drain.

Recommendation:

• Messengers and security-relevant apps → allowed
• Everything else → restrict

Google Play Services in the Sandbox

A common misconception:
Google Play Services have no special privileges under GrapheneOS.

• They run in isolation
• They are optional
• Many apps work fine without them

A pragmatic approach:

• Install when needed
• Isolate them
• Decide functionally, not ideologically

Practical Tip: Separation

If you need Google Play Services but don't want them mixed into your daily workflow, there are two clean options:

1. Separate user profiles: Move Google-dependent apps entirely into a dedicated profile
2. Shelter in the main profile: Isolate Google Play Services and related apps into a work profile while keeping notifications reliably functional

Both approaches significantly increase separation. The details go beyond the scope of this article and are covered separately.

Common Concerns

• Will an app break if I deny something?
  → Usually no
• Can I change permissions later?
  → Anytime
• Does GrapheneOS make everything more complicated?
  → No. More honest.

Practice: Make Deliberate Decisions

The most effective approach is to consciously review permissions at first launch:

• What is core functionality?
• What is just convenience?
• What can I grant later if needed?

Two or three real apps are usually enough to internalize the principle.

Conclusion

GrapheneOS doesn't give you security.
It gives you control.
Security only emerges from your decisions.