Last updated: August 17, 2026

Why this page is public

A privacy policy tells you what a company collects. It very rarely tells you why the software was built that way, and it almost never admits what the company decided not to build.

This page does both, because the thing we built is a wish list that children use and that grandparents open. If you are a parent deciding whether to let your kid make one, the policy will not answer your actual question. Your actual question is "what can a stranger learn about my child from this page". This page answers that one.

1. What the question really is

A wish list has to be public to work. The entire purpose is that you send a link to an aunt in another state and she opens it without an account. Anything that makes it private to the point of needing a login makes it useless, and families will go back to a screenshot in a group chat.

So the design problem is not "how do we keep this page secret". It is:

The page has to be openable by anyone with the link. Given that, what should the page be allowed to contain?

Our answer is that it should contain a first name or a made up handle, and a list of toys. Nothing else. Everything below follows from that one decision.

2. What a stranger can learn from a wish list page

Here is the complete list of what appears on a public wish list, and it is short on purpose:

  • A one word display name, up to 20 characters, chosen by the user. It can be "Ellie" or it can be "BlasterKid".
  • A short intro note, up to 240 characters, written by the user, with contact details automatically stripped out.
  • Up to 12 products, each with a title and an optional short note.
  • An optional cover image the user uploaded.
  • Whether each item has been claimed.

And here is what is not on the page, because it is not in the database at all:

Not collected Notes
Surname The display name field accepts one word only, and rejects around 115 common surnames outright
Age or date of birth Asked once, on its own screen, before any other field. Turned into an age bracket on our server and never stored, never in a database row, a log line, or anywhere else
School Rejected: school, elementary, highschool, academy, college, university, campus, kindergarten, preschool, daycare, district and more
Address Rejected: street, avenue, boulevard, lane, drive, road, court, apt, apartment, suite, zip, address, and any text shaped like a house number plus a street suffix
Phone number Any run of nine or more digits and dashes is stripped from free text
Email address in public text Stripped from free text automatically
Photograph of a person We do not ask for one, and the rule against publishing one is in the Terms
Precise location No field exists
Gender No field exists
Wish list price total We deliberately do not store prices at all
Who claimed a gift Only a timestamp is stored, never an identity

The filter is not advice in a help panel. It runs on save. If a child types their full name into the note, the note is saved without it.

3. The three tiers

Counsel's framework, in plain language, live in the product.

Tier 1, under 13. The parent holds the account.
A child under 13 does not have an account here. Sign-up starts with a birth-date question on three plain dropdowns, before any other field exists on the page, and answering under 13 sends no request to our server at all: the fields clear and nothing about the visit persists. The child exists only as a nickname-only profile inside the parent's account, with the parent's email, and the parent decides what goes public. The child picks the blasters, and can be handed a read-only, no-login view of the list to browse. This is the design that avoids the whole problem of collecting personal information from a child online, because the only person whose information we hold is an adult.

Tier 2, 13 to 17. Own account, with the protections on by default.
One word display name, no personal detail accepted anywhere, no search engine indexing until a human has reviewed the list, a private mode available instantly, and no advertising anywhere on the page.

Tier 3, 18 and over. Ordinary adult account.

The age bracket itself is computed on our server from the three raw numbers you enter, the moment you enter them, and neither the birth date nor the bracket is written to any option, meta row or log line anywhere in the system. A spoofed device clock cannot buy a different tier, because the server never trusts a client's claimed age, only the birth date it was given.

What the design does on top of the age gate itself is limit the damage further: the form after it asks for four things, none of which identify a child, and the filters reject the things that would.

4. What we deliberately did not build

Every one of these was possible and several are normal in this category. We left them out.

  • No price tracking on lists. The extension can read a price on a shop page and it does not send it to us. A saved price history is a shopping profile of a household, and we do not want one.
  • No purchase confirmation. We never learn whether an item was actually bought, only that somebody marked it. That is a worse product and a much better privacy position.
  • No buyer identity on a claim. No name, no email, no cookie, no account, no IP. One timestamp. It means we cannot resolve a duplicate purchase, and we accepted that.
  • No profile page. An account is not a social identity here. There is no bio, no avatar of a person, no following, no messages between users.
  • No comments, likes or reactions on a wish list. A public page with a comment box is a page where a stranger can talk to a child.
  • No email address collection from list visitors. A relative opens a list, claims an item and leaves. We never learn who they were.
  • No ads on wish list pages. Enforced in code, not left as a setting.
  • No open or click tracking in our newsletter. Not a pixel, not a wrapped link.
  • No raw IP retention on lists. One way hash only.
  • No third party social scripts on list pages. The sharing widget that runs on articles is deliberately removed from wish list pages.
  • No AI training on anything you write.

5. Public by default, invisible to Google by default

These two facts sound contradictory and they are the crux of the design.

A new list is published immediately, because a link that does not work yet is a broken product. The same list is marked no index immediately, because a nine year old's wish list appearing in Google search results is a thing nobody asked for.

The only way that no index flag comes off is a human review, and that human cannot approve a list unless the owner has confirmed the email address on the account and the list is a real list rather than an empty test. Adding an item captured from a shop puts it back into review. Marking a list private removes the flag again.

The result: a wish list is shareable in seconds and searchable never, unless a person decided it should be.

6. The trending page, and the smallest number that makes it safe

We publish an aggregate page of the most wished for products. Aggregates leak when the population is small, so:

  • No list is named, linked or counted individually. Only product totals appear.
  • Private lists are excluded from the count entirely.
  • Nothing renders at all unless there are at least three public lists to aggregate. With one list, a totals page is that one child's list with a different heading.

7. Items captured from shops

The extension and the paste box both accept product links only from Amazon, Walmart, Target, Best Buy and Hasbro Pulse, and both throw away the entire query string on any link they accept. That single step deletes any session identifier or foreign affiliate tag that was riding along on a URL a family member copied out of their own logged in shopping session.

Product images are the interesting case. We keep the image address so a moderator can see what an item is, we never show it on a public page, and where we do show it to a moderator we tell the browser not to send a referrer. Our server never fetches it. The plugin makes no outbound requests at all.

8. Where the honest tension is

Three places where two good principles pull against each other. We would rather name them than have counsel find them.

Archive versus delete. A retired list shows "this list has moved on" instead of disappearing, because grandparents bookmark URLs and a dead link is a real harm to the product. A deletion request always wins over an archive. For the ordinary end-of-season case where nobody has asked for anything, the archived list is anonymised: the URL stays alive, the display name and the link back to the owner's account come off, and the item list stays, which is the middle ground counsel confirmed is acceptable.

A self-serve delete button. Deletion by email is honoured, and a button in the dashboard does the same thing immediately, without an email round trip, because that is what people actually expect.

Advertising on a site children read. Wish list pages carry no ads, which is the part that mattered most. Articles do, and a proportion of our article readers are minors. Toy-review and buying-guide pages are treated as directed at that mixed, partly-young audience, with personalized ad targeting limited there; modification, battery-safety and competitive-play pages are treated as general-audience content.

9. The other systems, briefly

Newsletter. Double opt in, so an address that somebody typed as a prank never receives anything. No pixel, no click tracking. One click unsubscribe that works from inside the mail app, no login, no survey. We store the address, the status, the consent time and the source page, and nothing else. No IP.

Chrome extension. Runs on five shops' product pages only, sends nothing until you click, talks to exactly one server which is ours, and holds no analytics of any kind. Its own page at /extension-privacy/ is the authoritative description.

Comments. This blog started in 2009 and carries comments from an earlier era, with the email addresses WordPress stored at the time. Those records exist, they are not published, and anybody who wants theirs removed can have it removed. Going forward, commenting requires a name and an email address, and carries its own separate, unticked consent tickbox for site updates, which does nothing on its own beyond recording that you asked.

10. The principles, so you can hold us to them

  1. The best protection for a piece of information is not to have it.
  2. A page a child shares should carry a first name and a list of toys, and nothing that a stranger could use.
  3. Public to a family, invisible to a search engine, is the default and not a setting somebody has to find.
  4. We never learn who bought what.
  5. No advertising where children's families are looking at a child's page.
  6. When a claim on this page stops being true, we change the page, not the claim.

11. Review

This page is rewritten whenever the product changes in a way that makes any sentence on it wrong. The DOB-first, PII-never-first age gate described in section 3 is already live, not pending, so this page reflects the current build. The next revision is due the next time that flow changes.

Contact: info@nerfguns.net

Postal address: 4001 S Pine St, #110542, Tacoma, WA 98411-9994