OVERBURDEN — privacy policy
last reviewed · 2026-09-22
The short version
OVERBURDEN does not collect any data.
Installed from the App Store or Google Play, the game runs entirely on your device. It has no accounts, no sign-in, no analytics, no advertising, no crash reporting and no third-party SDK that phones home. It does not ask for your location, your contacts, your photos, your microphone or your camera, and it has no code that could use them.
On both stores this is the label “Data Not Collected”. That is a claim about what the app does, and the rest of this document is the evidence for it.
What the app stores, and where
Four values, in the web view’s own local storage on your device. Nothing leaves the device and nothing is readable by the developer or by anyone else:
| What | Why |
|---|---|
| Your best score | So a run has something to beat |
| The pace curve of that best run | So the game can tell you mid-run whether you are ahead |
| Whether the sound is off | So the choice survives a restart |
| A display name, if you set one | Web version only — it cannot be set in the app; below |
Deleting the app deletes all four. This app never sends them anywhere, there is no account to sync them to, and the developer cannot read them. What your own PHONE may do with them is a separate question, and the honest answer is not the same on both platforms:
Android — nothing is copied off the device at all. Two explicit settings, rather than an accident:
android:allowBackup="false"switches off Android’s Auto Backup. Left at the platform default, Auto Backup would have copied the app’s private storage — which is where these four values live — to the user’s Google Drive and restored it onto a new device. It is off.android:dataExtractionRulesexcludes every one of the app’s storage domains from device-to-device transfer as well. On Android 12 and higher the first setting does not necessarily cover that — the flow that copies an old phone onto a new one is a separate path, and it would have carried the same four values across. Both are now excluded, so a new phone starts this game at zero.
iOS — they are inside your own iPhone backup, and this app does not change that. The four
values sit in the web view’s storage inside the app’s container, and iOS includes that container
in an iCloud backup and in an encrypted computer backup. Restoring such a backup onto a new iPhone,
or transferring an old iPhone onto a new one, therefore carries a best score across. There is no
Info.plist setting that opts an app out of this; the only mechanism Apple offers is for the app
to mark specific files as excluded while it runs, and this app does not do that — see “What is
still owed”.
That copy is yours, not the developer’s: it goes to your Apple account, under your own backup encryption, and nobody here can request it or read it. It is spelled out because this document used to say flatly that there was no copy anywhere else, and on iPhone that sentence was not true.
Network
The app makes no network requests at all.
It is a web game packaged in a native shell (Capacitor). The shell serves the game’s own files
from inside the app bundle. The one piece of code in the tree that can reach the network is the
leaderboard client, and it is gated on the hostname the page is served from: it only acts on
vibezilla.games and its subdomains. Inside the app that hostname is localhost, so the
leaderboard is switched off before anything is fetched — the script that would talk to the score
service is never even requested.
The game’s sound files are fetched, and are not a network request. When the game’s recorded
sounds and music are shipped, the game loads them with fetch from its own bundled files: the same
origin the page itself came from, a path under audio/. This happens only after you have made a
gesture with the sound ON. While the sound is off, nothing under audio/ is requested at all, the
music file included. Inside the app those files are served from inside the app package, so the
request never leaves the device (this is an assumption until the installed app has been checked on a
device). On the website they come from the same site as the page. No file is ever fetched from
anywhere else, and nothing about you is sent with them.
The app’s own code is only half of that sentence, and the other half is the web view itself, which is a part of the operating system rather than a part of this app. On Android, web views have a reputation check (“Safe Browsing”) switched on by default for apps of this vintage, and it is the one piece of the shell that could have contacted a server without any code here asking it to. It is switched off in the app’s manifest. The app navigates to nothing but its own files, so the check had nothing to protect anybody from, and switching it off is what makes the sentence above true of the installed app and not merely of its source code. On iPhone the equivalent default does not exist.
The website is different, and this is the honest boundary
The same game is playable on the web at vibezilla.games. There, and only there, it submits
your score and reads the top of the board through that site’s own embedded score service. What is
sent is the score, and the display name if you chose one. That name is whatever you typed; it is
shown publicly on a leaderboard, so do not put anything private in it. The web version is covered
by the vibezilla.games privacy policy, not by this one.
The installed app has no way to set a display name at all — the name is read from a URL query parameter, and the app’s own page has no query string. So the app shows no user-written content, shares none, and offers no way to create any.
Permissions
Android. The app’s own manifest declares one permission, INTERNET, which is what a web view
needs in order to exist; as described above, the app does not use it to contact anything.
Two more permissions are added to the shipped package by libraries, not by this app’s code:
android.permission.VIBRATE, from the@capacitor/hapticsplugin. The game uses it: six moments in a run — a committed cut, a refused drag, a column welding, a crater, a new best and a burial — play a short vibration, and the mute control silences them along with the sound. This paragraph used to say the plugin was declared and never called, which was true until 2026-09-25. Either way the permission grants access to nothing and reads nothing: vibrating is an output, it has no sensor and returns no value, and nothing about it leaves the device.<applicationId>.DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION, added by AndroidX. It is a private, app-local signature permission that Android uses to keep the app’s own internal broadcasts from being visible to other apps. It has no relationship to any data.
iOS. The app declares no privacy-sensitive usage keys at all — no camera, microphone,
location, photo library, contacts, tracking or local-network description, because it has no code
that would need one. It declares ITSAppUsesNonExemptEncryption as false: the app ships no
cryptography of its own.
Children
The game has no chat, no user-to-user contact, no purchases, no advertising and no external links inside the app. Nothing about it is directed at collecting information from anyone, of any age.
Changes
This document is versioned in the game’s source repository. A change to what the app does is a change to this file in the same commit; the “last reviewed” date above is the date of the last time it was checked against the tree rather than the last time it was edited.
Contact
This app is published by Ori Iscovici (isco-tec), who operates vibezilla.games as a sole venture, based in Israel.
Privacy questions: hi [at] vibezilla [dot] games .
No contact channel inside the app collects anything, because there is no contact channel inside the app.