What happens when it breaks
A service that can lock users out of their own app is worse than no service at all. This page is the one to read before you ship Ripstop: it says exactly what your app does when ours is unreachable, wrong, or lying.
Failing open is the default
Every failure resolves to the last signedpayload the device holds, and if there isn’t one, to none. Your app runs, unrestricted. There is no state in which a Ripstop outage stops your users.
| Situation | What your app does |
|---|---|
| Network unavailable | Uses the last signed payload |
| No network and no cache | Runs normally (none) |
| Edge returns 5xx | Cache, then normal |
| Request times out | Cache, then normal. The budget is 5s by default |
| Signature fails to verify | Treated as a failure. The payload is discarded |
| Response is malformed JSON | Discarded, cache, then normal |
| Cache file edited on the device | Re-verified on read, so it grants nothing |
Walls are sticky, deliberately
The one asymmetry: a cached wall (maintenance, or a required update) stays in force until a fresh, signed payload clears it. This follows from failing open to cache, and it is intended. If losing the network lifted a wall, then aeroplane mode would be a way around it, and the feature would be decorative.
Why signatures, not HTTPS
TLS proves you are talking to our CDN. It does not prove our CDN is telling the truth. A compromised edge node, a misissued certificate, or a corporate proxy could all serve a payload that says “this app is dead”.
- Every payload is signed with Ed25519 at publish time, over the exact bytes that will be served.
- The public key is pinned in your app. It is never fetched, because a key you download is a key an attacker can replace.
- SDKs verify before parsing. Parsing first and re-serializing would change the bytes and break signatures on payloads that were perfectly genuine.
key_idselects between pinned keys, so we can rotate without every install updating first.
The result: the worst an attacker with full control of the network can do is stop your app from receiving new rules, which is the same as being offline, which fails open.
Latency and battery
- One request per launch at most, and not even that: a payload younger than
minFetchInterval(6 hours by default) is used from cache without touching the network. - Conditional requests. When nothing changed the edge answers
304with no body. - The check never blocks your first frame. The SDKs render your app immediately and show a wall when the decision arrives. A config service that adds a spinner to every cold start has made the app slower for everyone to catch a rare case.
What we can see
The config read sends your platform, app version, device model and a random install id the SDK generates on first launch. The connecting IP is turned into a two-letter country code at the edge and then discarded. It is never stored or forwarded.
If your code sets a user id, that id is stored so you can find one install in the Users view. That is your data about your user, set by you; we do not derive it.