Glimt — Child Safety
Last updated: 29 July 2026 · Policy version: 2026-07-29
Glimt has zero tolerance for child sexual abuse and exploitation (CSAE), and for any use of the app to send inappropriate content to minors. This page describes the standards and measures we have in place, as required by the Apple App Store and Google Play child-safety policies.
Everything below describes what the app actually does today. Where a protection is partial, or still being built, it says so in the same detail as the parts that are finished. A published policy that overstates its own product is worse than one that admits a gap, because a parent who relies on it has no way to know which sentences to trust.
Our structural protection: no contact with strangers
The single most effective safeguard is built into how Glimt works:
- Only from someone you said yes to. A glimt can only reach you from a friend you accepted, or from someone sitting at a bål you accepted an invitation to join. Both take a yes from you. There are no messages from strangers.
- No discovery, no public feed, no algorithm. Nobody can browse for, be recommended, or contact random users. There is no way for a predator to reach a child they don't already know and who hasn't accepted them.
- No open profiles. Users are found only by exact username, by people adding each other.
This removes the primary grooming vector that exists on open social platforms.
Age requirement
- Users must enter their date of birth at sign-up and be at least 13 years old (and meet any higher local minimum, e.g. 16 where required such as Australia).
- To be exact about the order this happens in: signing in creates an authentication record first, and the age check runs at the very next step, before a profile is created. An under-age date of birth stops the profile, so the person never gets a username. Without a username the account cannot be searched for, cannot send or accept a friend request, and cannot send or receive anything at all. So an under-age answer never becomes a usable account, but we would rather describe the mechanism than claim that nothing whatsoever is created.
Reporting and blocking
- Every user can block and report another user: from the friends list, from the inbox, and from the member list of any bål (group) they are part of.
- A block is enforced by the database, on every read and every write, so an old or modified app cannot get around it. It works both ways round and covers everything the two people could otherwise reach each other through: no glimt, no shared bål moment, no weekly vekeglimt, no reaction, and no notification, so a blocked person's name can never appear on the other's lock screen. It also applies to things already sent and not yet opened, and the two accounts cannot become friends again while the block stands.
- What a block does not do, said plainly for the same reason the ban section below says it: it does not remove either person from a bål they both belong to, and it does not stop either of them sharing with everyone else at that fire. Inside that bål each simply stops existing for the other: they are not in the other's roster, not lit at the fire, and nothing they post reaches the person who blocked them. Either of them can leave the bål, and its owner can remove a member.
- Every kind of content a user can post can be reported from the screen it plays on, by pressing and holding on it. That covers all three: the 1-to-1 glimt, the shared bål moment (which opens in the same viewer), and the weekly vekeglimt, whether it is a video, a photo, a voice message or a written reflection.
- Because content is end-to-end encrypted, a report attaches the decrypted media as evidence (uploaded by the reporter's own device to a private moderation store) so our moderators can actually review it, without weakening encryption for anyone else. Each report also records which kind of content it was about, so a moderator can find its context.
Moderation and response
- Every report alerts a moderator immediately, on their phone and in our moderation channel, so a single credible report can be acted on by hand well inside the required 24 hours.
- An account reported by three distinct users is banned automatically, with no wait for a human. The ban is enforced by the database on every write, so an old or modified app cannot get around it, and it stops that account posting anything new: no glimt, no bål moment, no weekly vekeglimt.
- What a ban does not do today, stated plainly because it matters more that this is accurate than that it sounds complete: a banned account's profile is still visible to people who already have them as a friend, they stay a member of any bål they had already joined, and a glimt they sent before the ban that nobody has opened yet can still be opened. Automatic banning stops the next piece of content, not the ones already in flight. Taking an account down completely, along with its content and its pending sends, is a manual step a moderator performs, and it is the step we take for anything CSAE-related. Making the automatic ban do all of this in one action is work in progress.
- Reports and evidence are reviewed via our moderation tooling. Confirmed CSAE results in immediate account termination and preservation + reporting to the relevant authority (NCMEC in the US, Kripos in Norway, and equivalents elsewhere).
- Ephemeral by design: glimt are deleted after viewing and unopened content is auto-deleted, limiting how long any material can persist.
On-device safety: blurring nudity before a child sees it
On-device sensitive-content detection is live. Glimt checks a photo or video for nudity on the phone itself and blurs it behind a warning the person has to choose to look past. It protects a child without sending anyone's content to a server and without breaking end-to-end encryption: no image is uploaded for the check, no result is stored, and nothing about it reaches us.
The check runs on the receiving phone, on open. That is deliberate and it is the invariant we protect above everything else in this area: the receiver's own check is the sole authority, and there is no path by which a sender can mark something as already checked and skip it.
Where it works, stated exactly:
- iPhone: yes, on iOS 17 or later, and only when "Sensitive Content Warning" is switched on in iOS Settings. Apple gates its analyser behind that switch, so we cannot turn it on for you. For a child's device a parent can set it through Screen Time, and on a child account it is usually on by default. If the switch is off, Glimt does not blur.
- Android: not yet. This is a planned later phase, not an oversight: it needs a bundled on-device model (TFLite) so that Android gets the same privacy-first, nothing-leaves-the-phone behaviour rather than a cloud check that would break end-to-end encryption. Until that ships, an Android phone does not blur or warn. We would rather say that plainly than let a vague sentence imply a protection that is not there.
Everything else on this page, above all the rule that a glimt only reaches you from someone you said yes to, protects a child on both platforms equally.
Contact
Child-safety concerns and law-enforcement requests: paal@dynni.no
We respond to credible reports of CSAE as our highest priority.