NoBo Privacy Policy

Version: v2.4 Effective: 2026-08-11 Last updated: 2026-08-11

Plain-English summary. NoBo is becoming a source tool for recording and checking media. Its iPhone app and website include a narrow exact-file checker, and each has an experimental live scanner that compares camera frames locally with one registered public sample. Eligible unedited app recordings can also create private exact-byte evidence that compares the local original with NoBo's finalized stored copy. None of these tools proves that a depicted event is true, that a registered file is chronologically first, or that camera hardware signed a scanned copy. We do not run behavioral surveillance: we don't track your phone's motion for detection, taps, or swipes, and we don't build a behavioral profile of you. We keep only what's needed, never sell personal data, never share it with advertisers, and let account holders delete or export everything associated with their account. What changed in v2.4 (2026-08-11): We documented the private evidence created for eligible unedited app recordings: the original file's SHA-256 digest and byte count, a random capture-session identifier, an opaque per-publish operation identifier, whether App Attest covered the exact source claim, the server's independent finalized-file check, and the resulting comparison state. These records are available in the owner's data export and are deleted from the live service with the video or account. They are not public registry entries or signed receipts. We also documented the built-in iPhone source checker, private-chat storage, the media-free cleanup journal that makes explicit video, visibility, and account deletion survive crashes and delayed writes, and the complete owner-export boundary. We stopped attaching raw IP addresses to upload-failure, username-change, client-diagnostic, and account-deletion records. Short-lived abuse-rate-limit counters remain as described below. Behavioral-data deletion, corrected 2026-08-09: We removed the behavioral-detection system and its dedicated motion, gesture, fingerprint, and hand-tremor tables in June. An August audit found that older recording-time motion bundles had also remained inside 285 video metadata rows. The upload service now discards those legacy fields and all 285 live-database copies were purged on 2026-08-09. Supabase currently retains up to seven days of encrypted daily physical backups, with point-in-time recovery disabled, so a pre-purge recovery copy may remain until 2026-08-16. If one is restored, the purge and access-lock migrations must run before service resumes. We also stopped logging IP addresses against account activity. Authenticity now comes from prevention (how media is captured), not from watching how you behave.

1. Who runs NoBo

NoBo is run by Oliver Parelius (single founder, no investors, no advertisers, no third-party trackers).

Contact: oliverparelius@protonmail.com

For privacy-specific requests (data export, deletion, questions about this policy), the in-app Settings → Privacy screen is the fastest path.

2. What we collect, why, and how we keep it

We group every piece of data into one of these categories:

2.1 Account data

2.2 Content you publish

We never display or share your device data to other users. Only your published content is public.

2.2A Private chat

Chat is private to active conversation participants, but it is not end-to-end encrypted today: NoBo's server can decrypt a message to deliver it and to include the sender's own text in an authenticated export. Chat files live in a private bucket and are delivered with expiring links. A photo or video deliberately selected from Photos for chat is marked Not verified and never becomes a public-feed upload through that path. Another participant can still save or screenshot what you send; deleting it from NoBo cannot recall their copy.

2.3 How we prove authenticity (prevention, not surveillance)

NoBo proves a video is real by controlling how it gets in — not by analyzing your behavior afterward. The authenticity guarantee rests on four things, none of which is behavioral tracking:

What we deliberately do NOT do: We do not track your taps and swipes, build a per-account behavioral profile, or record/store phone motion for detection. The old behavioral system is gone; every known live-database copy of its data, including the legacy video-metadata bundles found in the 2026-08-09 audit, has been purged. The limited encrypted-backup window is stated above. (The one remaining accelerometer use is purely local and never leaves your phone: see "Motion sensor" in section 2.6.) Hard cases such as filming a high-resolution screen must be addressed with future hardware-backed provenance, never behavioral surveillance.

2.3A Private source-registration evidence

For an eligible unedited recording, NoBo calculates a SHA-256 digest and exact byte count from the durable original on your device and assigns a random capture-session identifier. If App Attest succeeds, its assertion can cover that exact digest, byte count, and session claim. After upload, NoBo independently reads the finalized stored master and records whether its SHA-256 digest and byte count match the device's claim.

These rows are private and cannot be read directly by other users or anonymous website visitors. They are included only in the authenticated owner's data export. Deleting the video or account deletes its live evidence rows; encrypted recovery backups age out under the seven-day window described above. While a comparison is pending, deferred, mismatched, unavailable, or not bound by App Attest, NoBo may retain the exact queue copy locally on your device so a real recording is not lost. That local copy is removed only after the stored bytes match and App Attest has bound the exact claim, or when you delete the video or account. After an explicit delete, the app may retain a tiny media-free operation marker on that device until account deletion so a late upload callback or crash recovery cannot recreate the deleted video.

A matched state means only that the device-observed digest and byte count equal the independently observed finalized stored bytes. It does not prove scene truth, authorship, device identity, chronological first origin, or absence of AI content. The evidence is not yet a signed or portable receipt, and it is not automatically enrolled in any public registry.

2.3B Source checks in the app and website

Live physical-screen scanner. The camera remains off until you tap Start camera. The iPhone app or mobile website then requests camera access without microphone access and downloads the registered public reference video from NoBo's Supabase Storage. The app derives temporary visual features inside an isolated native matcher; the website does so inside the browser. Each compares those features with live camera frames on the device. No camera frame, thumbnail, visual descriptor, audio, or recording is sent to NoBo or stored by NoBo. The camera stops when you stop, close or hide the scanner, leave the app or page, an interruption or error occurs, the 20-second scan ends, or a result is reached. Temporary frames and features are discarded. Your device or browser may remember the permission choice under its own controls. Supabase receives the ordinary network data needed to deliver the public reference, including the requesting IP address, as described in section 3.

Exact-file fallback. When you deliberately choose a file in the app or website exact checker, NoBo computes a SHA-256 digest on your device in small chunks. NoBo receives the 64-character digest and the file's byte count, not the photo or video. We use those two values for one exact equality lookup against the limited public demo register. The current register contains one build-pinned calibration image and two founder video masters whose stored objects were independently downloaded and checked before registration. We do not save or log the submitted digest. A short-lived, salted rate-limit token derived from the request's IP address may remain in one server process for about one minute to prevent automated flooding; NoBo does not use it for analytics or attach it to the lookup. Vercel processes the network information described in section 3, as it does for every hosted request.

If the live scanner obtains repeated feature matches with plausible geometric consistency, it links to that registered source candidate. This is visual-similarity evidence, not proof that the scanned copy came from that file. If the exact checker finds a match, the in-session result means the selected file has the same bytes as that registered file. The public registry page is not a standalone verification receipt. Neither result establishes scene truth, chronological originality, authorship, or hardware-level camera provenance. Private, under-review, non-opted-in, legacy, and not-independently-registered media are never returned. A missing result therefore does not mean that media is fake or AI-generated.

2.3C Deletion safety records

To make an explicit video, visibility, or account deletion survive a crash, a lost response, or a delayed upload, NoBo keeps a service-only cleanup journal. It contains the account identifier, the video identifier when applicable, exact NoBo Storage object paths and NoBo-controlled HLS/R2/CDN prefixes, the cleanup scope and generation, and bounded attempt, status, timestamp, and error fields. It contains no photo, video, audio, thumbnail, visual descriptor, or source digest.

An account-deletion request first creates a prepared, non-destructive journal entry. Account-wide media and credential cleanup cannot start unless deletion of the authentication identity commits. A video-delete or public-to-private transition records its cleanup target in the same database transaction as the row change, so either both facts commit or neither does. Pending entries remain until strict checks find the NoBo-controlled origins empty and the configured CDN prefix purge succeeds after a 28-hour delayed-write fence and a later clean pass. Completed operational journal results remain for up to 9 additional days; abandoned prepared account requests remain up to 7 days.

For account-deletion response recovery, each deleting device creates a random UUID in the private app sandbox before the request. NoBo temporarily stores only its SHA-256 hash with the account while the request is prepared. If identity deletion commits, that account link is atomically removed and only the random hash plus commit time remains as a minimal recovery receipt. It contains no account identifier, path, media, error, IP address, or source evidence. The app deletes its raw UUID and asks NoBo to delete the receipt only after account-scoped local media/data cleanup and local sign-out are verified. If that device never returns, the unlinkable receipt may remain so an arbitrarily late recovery never has to guess whether destructive work committed.

While a resumable upload is incomplete, the app may store a local upload fingerprint, object path, and temporary resume URL in its private sandbox. The URL normally stops working after about 24 hours, although the local record can remain until the upload succeeds, is explicitly removed, or the account is deleted. New records are tagged locally to the account that created them; account deletion removes only that account's proven records. An older untagged record is never reassigned to whoever signs in next.

This process verifies removal from NoBo's current live origins and configured server/CDN caches. It cannot recall a copy that another person or device already downloaded, saved, screen-recorded, or retained in its own browser cache. It also cannot delete a cross-posted copy from another platform merely by deleting it from NoBo; that platform's controls and policy apply.

2.4 Device + environment

2.5 Usage analytics

We do not use third-party analytics (no Google Analytics, PostHog, Mixpanel, or Firebase Analytics). Everything in the table above is captured on our own servers. Android uses Firebase Cloud Messaging for notifications, not analytics. We do not store your IP address in your analytics record or use it to derive your location. A separate fixed-window abuse limiter may hold an IP address for up to 2 days, then deletes it automatically.

2.6 Sensors + data we mostly DON'T use

• Motion sensor (accelerometer). Read on your device only, for two small things: while you record, we check which way the phone is tilted so the video is saved right-side up; and anywhere in the app, a firm shake opens the "report a bug" screen. The reading stays on your phone in the moment it happens. It is never stored and never sent anywhere, and we do not use it to detect fakes, track behavior, or build any profile. We removed all of that motion detection in the 2026-06-25 prevention-only pivot.
• Gyroscope. Not used.
• Behavioral tracking (taps, swipes, scroll patterns). Not collected.
• GPS / precise location. We never request the iOS location permission, and we no longer derive even coarse location from your IP for analytics. The 05:00 recommendation-edition reset uses your phone's clock and timezone on the device; it does not use location services.
• Camera or microphone outside recording. In the app, recording uses the camera and microphone only while you actively record in Create. The app and mobile website source scanners request camera-only access after you tap Start camera. Neither scanner requests the microphone, uploads camera frames, or records a video.
• Contacts. We never read your contacts.
• Photos library. Existing files cannot be imported into the public feed. You may deliberately select a photo or video for a private chat, where it is marked Not verified, or for an exact source check. The exact checker reads the file locally and sends only its digest and byte count. Saving a NoBo recording to your phone's Photos is also optional and user-initiated.
• Health / HealthKit. Not used.
• Bluetooth. Not used.

3. Who we share data with

We share as little data as possible with as few third parties as possible. The full list:

We never sell data, share it with advertisers, or use it to train third-party AI models for general-purpose use.

3.1 Cross-posting to other platforms (only if you connect them)

NoBo lets you optionally connect your own accounts on other platforms — YouTube, TikTok, Instagram, and X — and choose, per video, to also publish that video there. This is entirely opt-in: nothing is sent anywhere unless you connect the account and turn on cross-posting for that specific video.

How it works and what we store:

• When you connect a platform, we store a secure access token for your account on that platform (kept encrypted in our server-side vault, never shown to other users) plus your public channel/handle name so we can display "Connected as @you".
• We only ever send a video you explicitly chose to cross-post. We never send your device signals or any authenticity data to these platforms — only the finished video and its caption.
• We send the finished frame without secretly cropping it. The destination platform controls how it displays that frame.
• Once a video reaches another platform, that platform's own privacy policy and terms govern it — it's on their servers under your account there. You can disconnect any platform at any time in Settings → Multi-upload, which deletes the stored token.

#### YouTube-specific disclosures

Because NoBo's YouTube cross-posting uses YouTube API Services, we want to be exact about what that means for you:

• By connecting your YouTube account, you agree to be bound by the [YouTube Terms of Service](https://www.youtube.com/t/terms).
• Google's own handling of any data it receives is governed by the [Google Privacy Policy](https://policies.google.com/privacy).
• What we access: with your permission, NoBo requests exactly two YouTube permissions and no others: the ability to upload videos to your channel (youtube.upload), and read-only access used only to look up your own channel's name and ID (youtube.readonly) so we can show you "Connected as @your-channel" and attach uploads to the right channel. We do not read your existing videos, comments, subscribers, analytics, watch history, or anyone else's data.
• How we store it: we keep an encrypted authorization token for your YouTube account in our server-side vault, plus your channel name and ID. We store nothing else from YouTube.
• How we use it: the token is used for one purpose only — to upload a video you explicitly chose to cross-post, to your channel. It is never used in the background, never shared, never sold, and never used to build a profile of you.
• Revoking access: you can disconnect YouTube at any time in Settings → Multi-upload (which deletes the stored token on our side), and you can independently revoke NoBo's access from your [Google security settings](https://myaccount.google.com/permissions) at any time.
• We do not transfer YouTube data to any third party, we do not use it for advertising, and we do not use it to train AI models.

4. Your rights

Under GDPR (EU/EEA users), CCPA (California users), and Apple App Store guidelines, you have the right to:

• Access all data we have about you. Use Settings → Privacy → Export my data. The JSON includes your authentication/profile state, videos and downloadable NoBo-owned media, social actions, source evidence and registrations, retained analytics and diagnostics, Met and cross-posting state, messages you sent, and attachment rows you created. It does not expose another person's received chat text, private decision to block or report you, or live OAuth, push, pairing, nonce, challenge, or attestation credentials. Media links expire after about 26 hours; request a new export after the 24-hour export window to refresh them.
• Delete your account data. Use Settings → Privacy → Delete my account. The account identity is removed after the required live database cleanup succeeds. NoBo then keeps retrying NoBo-controlled media origins, OAuth credentials, and configured CDN invalidation until the strict deletion checks described in section 2.3C pass. Supabase's encrypted recovery backups age out under the seven-day retention above; if a backup is restored, deletion and privacy-purge migrations must run before service resumes. Copies already downloaded or held by another platform remain outside NoBo's control.
• Correct inaccurate data. Profile fields you control (username, bio, avatar) are editable in-app. For anything else, contact oliverparelius@protonmail.com.
• Withdraw consent at any time. Same path as Delete.
• Lodge a complaint with your local data protection authority (e.g. Datatilsynet in Norway).

The in-app export and deletion requests are automatic. Account identity removal normally happens during the request; strict media-cleanup verification deliberately continues through the delayed-write fence described above. For email requests we aim to respond within 7 days.

5. Children

NoBo is not intended for children under 13. We don't knowingly collect data from children under 13. If you believe a child under 13 has created an account, contact us and we'll delete it.

For users 13–17, NoBo treats your data with the same protections as adult users. Parental consent rules vary by jurisdiction; consult your local rules.

6. Security

• All traffic uses HTTPS.
• Our iOS app pins its server's TLS certificate (an attacker can't intercept your data even if they compromise a Wi-Fi network).
• Authenticity-related data (device records, prevention diagnostics, and private source-registration evidence) is stored in service-role-only database tables. It is not directly accessible from the public app. An authenticated owner can receive their own rows through the data-export function.
• Apple App Attest cryptographically ties each upload to your specific iPhone.
• Supabase physical database backups run automatically and are encrypted at rest. NoBo's current Pro project exposes the last seven days of daily backups and has point-in-time recovery disabled (checked 2026-08-09).

7. Changes to this policy

The website always links to this current policy. If we update it in a way that materially changes what an account holder accepts, NoBo will:

1. Bump the version number at the top.
2. Present it in a compatible app release.
3. Ask you to accept it before relying on that new version for continued account use. An older installed build remains under the version last accepted until the update is presented.

Old data captured under a previous policy version stays tagged with that version — we can't retroactively change the rules under which it was collected.

8. Contact

Oliver Parelius Email: oliverparelius@protonmail.com

We're not too big to read every email. Reach out.