---
title: "What if parental controls worked like rooms, not locks?"
code: "RP-0107"
language: "en"
canonical: "https://regentspark.ai/RP-0107/"
html: "https://regentspark.ai/RP-0107/"
markdown: "https://regentspark.ai/RP-0107.md"
updated: "3 May 2026"
---
# Prior Art Survey: Screen Time, Digital Spaces & Children

*Supporting research for Brief 010 — Spaces as Namespaces*

**Date:** April 4, 2026  
**Purpose:** Map the landscape of children's digital environments — parental controls, walled gardens, policy frameworks, and capability-based security — to understand where the "Space as namespace" framing offers something genuinely new.

---

## 1. Current Landscape of Parental Controls

### 1.1 The Dominant Players

**Apple Screen Time** (built into iOS/iPadOS/macOS since 2018)
- Features: Downtime scheduling, per-app time limits, "Always Allowed" apps, content & privacy restrictions, communication limits
- Technical model: Operates at the OS level. Content filtering uses Apple's category database. Web content filtering applies to Safari and (since iOS 26) in-app browsers. Passcode-protected by parent.
- Key limitation: Everything starts *open* — the full device is available, and parents must carve restrictions out of an already-complete system.

**Google Family Link** (Android/ChromeOS)
- Features: App approval/blocking, screen time limits, device lock, location tracking, Chrome/Search filtering, Google Play content ratings
- Technical model: MDM-like profile on child's Google account. Parents can set content maturity ratings (e.g., apps rated "Teen" or below). Chrome can filter "mature sites" or operate in "approved sites only" mode.
- Key limitation: Controls expire at age 13 by default — Google recently adjusted this after high-profile criticism (Mashable, April 2026), but the model still treats 13 as a cliff edge from managed to unmanaged.

**Circle** (Axton, formerly Disney Circle)
- Technical model: Network-level filtering via ARP spoofing or router integration. DNS-based content categorization. Sets per-device or per-profile time limits and bedtimes. Mobile extension uses VPN.
- Key limitation: Router-based controls only filter home Wi-Fi — cellular data completely bypasses them. Kids switching to mobile data renders it ineffective.

**Bark** ($99/year)
- Technical model: Content monitoring via API access to social media, email, text. Screens 30+ platforms for concerning content (bullying, depression, sexual content, etc.). Also offers screen time management and web filtering.
- Philosophy: "Monitor rather than block" — alerts parents to concerning content rather than preventing all access. Provides advice from child psychologists.
- Key limitation: Reactive, not architectural. The environment is still fully open; Bark watches what happens in it.

**Qustodio**
- Technical model: Agent-based monitoring across devices. Detailed activity logs, content filtering by category, social media monitoring, call/SMS tracking, location.
- Key limitation: Most comprehensive surveillance tool, but fundamentally the same model — restrict/monitor a system that starts fully open.

### 1.2 The Technical Model: Blocklists on Open Systems

Every mainstream parental control operates from the same architectural assumption:

> **The system is fully open by default. Parental controls are restrictions subtracted from full access.**

This manifests as:
- **Blocklists** — Categories of content/apps/sites that are denied
- **Time limits** — Quotas subtracted from unlimited availability
- **Content filters** — Classifiers that attempt to categorize the entire internet into safe/unsafe
- **Activity monitors** — Surveillance of everything, with alerts on concerning patterns

The architecture is ACL-based (Access Control Lists): the child has an identity, the system has a global namespace of everything, and rules determine what the child can and cannot access within that global namespace. The child *knows* the restricted things exist — they see locked icons, "Ask Parent" prompts, and time-limit warnings.

### 1.3 Circumvention: The Arms Race

Circumvention is endemic and well-documented. Key patterns from multiple sources (PCMag, Guardian, KosherOS, Mobicip, Bitdefender):

- **"One More Minute" exploit** — Apple's Screen Time allows a "one more minute" extension indefinitely. Kids tap it repeatedly for hours. Apple has not offered a way to disable it (as of 2025).
- **VPN bypass** — Teens purchase VPN subscriptions using prepaid Visa cards, routing traffic outside parental filters. A $5 VPN defeats a $200 Circle device.
- **Factory reset** — Nuclear option: reset device to factory settings, wiping all parental controls.
- **Guest/secondary accounts** — Creating new user profiles that aren't linked to Family Sharing or Family Link.
- **Device borrowing** — Using a friend's unrestricted device. Architecturally impossible to prevent.
- **Apple ID recovery** — Resetting Screen Time passcode via Apple ID account recovery.
- **iMessage/AirDrop workarounds** — Using system services that bypass app-level restrictions.
- **Alternative browsers** — Downloading browsers not covered by web filtering rules.

**The Guardian** (March 2025) headline captures the reality: *"Kids can bypass anything if they're clever enough!"*

### 1.4 Parent Frustration Data

**FOSI/Ipsos Survey (2025)** — 1,000 parents, 1,000 children aged 10-17:
- Only **47%** of parents fully utilize parental controls on their children's devices
- Only **54%** feel their kids are safe online
- Less than half use controls on smartphones (47%), desktops (46%), laptops (43%), smart TVs (38%), game consoles (35%)
- "In a survey we did a couple of years ago, a lot of parents admitted they even ask their kids help in setting them up" — FOSI CEO Stephen Balkam

**MacbookJournal Survey (2024)** — 11,200 parents:
- **51%** use parental control apps
- **57%** report kids encountering inappropriate content despite controls
- **39%** find controls need improvement in usability
- **44%** worry controls invade child's privacy but use them anyway
- **73%** saw reduced screen time after implementation — but this measures compliance, not whether the architecture works

**Fewer than 10%** of parents have implemented parental control tools on Instagram (Social Media Today, January 2024).

**Common Sense Media (2025 Census):**
- Children ages 0-8 average **2 hours 27 minutes** daily screen time
- Teens average over **8 hours** daily (not including school use)
- 40% of 2-year-olds have their own tablets
- 46% of children encounter inappropriate content through YouTube's recommendation algorithm

The data paints a clear picture: the restriction-based model is failing. Parents find the tools confusing, children find them easy to circumvent, and the result is an arms race that strains relationships without achieving safety.

### 1.5 The "Forbidden Fruit" Problem

Multiple sources identify a fundamental psychological issue: restriction creates desire. The KosherOS guide (2024) articulates this as the "Forbidden Fruit Effect" — overly restrictive controls increase curiosity about blocked content. This isn't a bug in the implementation; it's a bug in the architecture. When a child sees "Access Denied" on a locked app, they know the app exists and is being withheld from them.

---

## 2. Walled Garden Approaches That Hint at Spaces

### 2.1 Amazon Kids+ (formerly FreeTime Unlimited)

Amazon's approach is the closest existing product to the "namespace" model:

- **Starts empty**: A child's profile on a Fire tablet begins with nothing. The tablet boots into a custom launcher (Amazon Kids) that shows only what's been made available.
- **Curated library**: Amazon Kids+ provides "tens of thousands of kid-friendly books, games, songs, and shows curated by age range" (Business Insider). Content is hand-selected and age-categorized.
- **Additive model**: Parents can add content to the child's library. The web browser, when enabled, operates in "approved websites only" (whitelist) mode or "curated websites" (Amazon-filtered list: PBS Kids, National Geographic Kids, NASA, etc.).
- **No awareness of the outside**: The child's interface doesn't show what they *can't* access. There's no "locked" app icon. There's no "Ask Parent" for unavailable content. The universe is exactly what's in their profile.

Amazon's VP described it as "a safe space in a walled garden for your child" (Fast Company, 2019). This is architecturally different from Apple/Google: the child's device doesn't start as a full computer with restrictions — it starts as an empty container with additions.

**However:** Amazon Kids+ is still a closed proprietary ecosystem. The parent can add Amazon content, but can't compose arbitrary capabilities. The "namespace" is Amazon's namespace, not the family's. And it's limited to Fire tablets — it doesn't extend to the child's broader digital life.

### 2.2 YouTube Kids — "Approved Content Only" Mode

YouTube Kids offers a mode that approaches the namespace model:

- **Default mode**: Algorithmic filtering of YouTube's full library (restrictive model — filter the open internet)
- **"Approved Content Only" mode**: Parent manually approves specific channels and videos. The child sees *only* what's been approved. No search, no recommendations, no algorithm.

The Family IT Guy blog captures the philosophy: "Start by approving 5-10 videos or a couple of trusted channels, then gradually build your child's library of parent-approved content over time."

**WhitelistVideo** (2026) identifies the gap: "YouTube Kids is too restrictive, but regular YouTube is too dangerous." The jump from curated-namespace to full-internet is discontinuous — there's no gradual expansion path.

### 2.3 Kid-Specific Phones

**Gabb Phone:**
- "Screen alternative for kids" — no internet, no social media, no app store
- Ships with basic apps: phone, text, calculator, camera, Gabb Music
- More restrictive than a feature phone. Essentially a communication device.
- *Empty-ish by default*, but no mechanism for progressive addition. It's a fixed, minimal namespace.

**Pinwheel:**
- "App Boutique" — curated selection of apps that parents can enable
- "Allowed contacts" approach — child can only communicate with parent-approved contacts
- Progressive: parents can add apps from the boutique as the child grows
- Closest to "additive namespace" among phone products

**Bark Phone:**
- Samsung hardware with Bark monitoring baked in
- Parent approves each app. App reviews planned so parents understand what they're approving.
- Monitored usage rather than blocked usage
- Still a full Android phone underneath — the monitoring is a layer, not the architecture

**Troomi:**
- Curated app store. Parents approve individual apps from a safe list.
- "KidSmart" apps — Troomi-reviewed apps available for parent approval

**Key observation:** Pinwheel and Troomi are the most "additive" — they start restricted and parents add capabilities. But they're still operating within the phone paradigm. The "namespace" is the set of approved apps and contacts, not a composable space.

### 2.4 Assessment: Additive vs. Restrictive?

| Product | Starts Empty? | Additive Growth? | Child Awareness of Outside? | Composable? |
|---------|:---:|:---:|:---:|:---:|
| Apple Screen Time | ❌ Starts full | ❌ Subtractive | ✅ Sees locked apps | ❌ |
| Google Family Link | ❌ Starts full | ❌ Subtractive | ✅ Sees blocked content | ❌ |
| Circle / Bark / Qustodio | ❌ Starts full | ❌ Subtractive/surveillance | ✅ Encounters blocks | ❌ |
| Amazon Kids+ | ✅ Mostly | ✅ Add content | ❌ Mostly hidden | ❌ Amazon-only |
| YouTube Kids (approved mode) | ✅ | ✅ Add channels | ❌ Hidden | ❌ YouTube-only |
| Gabb | ✅ Minimal | ❌ Fixed set | ❌ | ❌ |
| Pinwheel/Troomi | ✅ Minimal | ✅ Add from boutique | ⚠️ Knows boutique exists | ⚠️ Limited |

Amazon Kids+ and YouTube Kids (approved mode) are the closest to the namespace model, but both are locked to a single vendor's content universe. None offer a general-purpose "empty space" into which arbitrary capabilities can be mounted.

---

## 3. Academic & Policy Work

### 3.1 The 5Rights Foundation & Age Appropriate Design Code

**5Rights Foundation** (founded by Baroness Beeban Kidron) has been the most influential advocate for children's rights in digital environments. Their key achievement: the **UK Age Appropriate Design Code** (AADC), a statutory code of practice since September 2021.

The AADC's 15 standards include:
1. **Best interests of the child** as primary consideration
2. **Data protection impact assessments** for services likely accessed by children
3. **Age-appropriate application** — different protections for different ages
4. **Transparency** — privacy information in child-friendly language
5. **Detrimental use of data** — don't use children's data in ways detrimental to their wellbeing
6. **Policies and community standards** — uphold your own rules
7. **Default settings** — settings must be "high privacy" by default
8. **Data minimisation** — collect only necessary data
9. **Data sharing** — restrict sharing of children's data
10. **Geolocation** — off by default
11. **Parental controls** — provide controls where appropriate
12. **Profiling** — off by default
13. **Nudge techniques** — don't use them to lead children away from privacy protections
14. **Connected toys and devices** — apply code to physical products
15. **Online tools** — easy-to-use tools for children to exercise data rights

**5Rights' "Celebrating 3 Years" report (January 2025):** Found 63 specific design changes by tech companies to strengthen children's protections — setting profiles to private by default, limiting harmful recommender content, prohibiting profiling-based advertising.

**Relevance to Spaces:** The AADC's principle of **"high privacy by default"** is philosophically adjacent to "empty by default." The code says settings should default to maximum protection — which is a step toward saying the namespace should default to minimal content. But the AADC doesn't question the underlying architecture of full-access-minus-restrictions. It mandates better defaults within the existing open-system model.

**5Rights' "Child Rights by Design" principles** explicitly address children's autonomy as fundamental to their digital rights. Their framework identifies age-appropriate design as needing to evolve with the child — which maps to the "progressive mounting" idea in the namespace model.

### 3.2 UN General Comment No. 25 (2021)

The **UN Committee on the Rights of the Child** published General Comment No. 25 in March 2021: *"Children's rights in relation to the digital environment."*

Key principles:
- Children's rights (privacy, safety, participation, non-discrimination, education, play, protection from exploitation) must be respected in digital environments
- States must ensure digital environments serve children's best interests
- Protection measures must be proportionate — must not unduly restrict children's access to information, freedom of expression, or participation
- Design of digital products should be child-centered

The tension the Comment navigates: protection vs. participation. Overly restrictive approaches violate children's right to information and participation; insufficient protection violates their right to safety. The Comment calls for balance but doesn't propose architectural solutions.

**UNICEF Innocenti** (January 2026) extends this with "Best Interests of the Child in the Digital Environment" — a working paper noting "a shift towards a more child-centred approach to digital policy and design." The European Commission's July 2025 Guidelines explicitly reference UNICEF's D-CRIA (Digital Child Rights Impact Assessment) Toolbox.

### 3.3 Joan Ganz Cooney Center (Sesame Workshop)

An independent research group within Sesame Workshop, focused on "advancing positive futures for kids in the digital world."

Key recent work:
- **"The Family Tech Cycle: Navigating Screens, Devices, and Social Media"** (Amanda Lenhart, March 2026) — how families actually manage technology
- **"Well-Being by Design" Fellows program** (2026) — funding researchers working on child wellbeing in digital spaces
- **"Building a Sandbox for Literacy Innovation"** — using curated digital spaces for early literacy

The "sandbox" language is notable — it's explicitly spatial and bounded. The Cooney Center's research consistently emphasizes **designed environments** over unrestricted access, aligning with the namespace philosophy even if not using that technical framing.

### 3.4 Oxford CCAI — Children's Autonomy

**"12 Ways to Empower: Designing for Children's Digital Autonomy"** (CHI 2023, ACM) is the most directly relevant academic paper. Key findings:

- Current digital designs overwhelmingly focus on **protection** (monitoring, restricting) at the expense of **autonomy** (children's ability to make their own choices)
- Most design patterns support cognitive autonomy (providing information for decision-making) or behavioral autonomy (nudging behavior change)
- Very little work addresses **emotional autonomy** — children's ability to understand their own motivations and develop intrinsic self-regulation
- Techniques identified: scaffolding of choices, gamification, storytelling, digital playgrounds

The Oxford CCAI blog (May 2024) proposes **seven principles for "Designing for Children's Autonomy":**
1. Support cognitive, behavioral, and emotional autonomy together
2. Consider developmental stages
3. Build contextual digital literacy
4. Use inclusive design for diverse children
5. Balance protection with empowerment
6. Design for evolving capabilities
7. Center children's rights

**Relevance:** The Oxford work identifies the key tension — protection vs. autonomy — and advocates for design that grows with the child. The namespace model potentially resolves this tension: a Space isn't restrictive (it doesn't say "no"), it's constructive (it says "here's what's here"). The child has full autonomy *within* the Space. Growth happens by expanding the Space, not by removing restrictions.

### 3.5 *Science* — "Digital child safety at the frontier" (2024)

This article in *Science* directly states: "Companies can be asked to design features that **expand autonomy with age** instead of implementing overly generalized access restrictions." This is the progressive-mounting principle stated in a top-tier scientific journal.

### 3.6 The "Digital Thriving Playbook"

The Digital Thriving Playbook (digitalthrivingplaybook.org) promotes age-appropriate design principles: "Younger children require simpler, more visual tools, while older ones benefit from more complex content and features that respect their autonomy." This maps directly to a growing namespace.

### 3.7 The Parental Mediation Literature

A rapid evidence review in the *Journal of Children and Media* (2023, Taylor & Francis) examined whether parental control tools fulfil family expectations. Key finding: policymakers promote parental controls as a mediation strategy, but evidence for their effectiveness is limited and context-dependent. Technical controls work better for younger children but fail for adolescents, and their use correlates with both reduced risk exposure *and* reduced digital competence.

---

## 4. Capability-Based Security Framing

### 4.1 Has Anyone Connected Capabilities to Children's Computing?

**Short answer: No.** This is a genuine gap in the literature.

Searches for connections between capability-based security (or the object-capability model) and children's digital environments returned zero results. The two fields haven't talked to each other.

This is surprising because the conceptual alignment is tight:

| Capability Security Concept | Children's Digital Environment Analogue |
|---|---|
| Empty process with no capabilities | New child device with nothing on it |
| Capabilities explicitly granted | Parent adds apps/content to child's space |
| No ambient authority | Child doesn't "see" the full internet |
| Capability = unforgeable reference + permission | Approved app = access + limited scope |
| Principle of Least Authority (POLA) | Child has access to exactly what they need |
| Capabilities can be delegated | Child can share within their space |
| Revocation = removing capability | Parent can remove an app from the space |

### 4.2 The Principle of Least Authority (POLA) as UX

In security, POLA states: "every module must be able to access only the information and resources that are necessary for its legitimate purpose" (Wikipedia).

Applied to a child's digital environment: the child's device should contain exactly what serves their current needs and developmental stage — no more, no less. This isn't restriction (which implies a larger set being reduced); it's scoping (which implies a set sized to purpose).

The difference matters psychologically:
- **Restriction**: "You can't have TikTok" → "Why not? What are you hiding from me?"
- **Scoping**: TikTok doesn't exist in the child's digital universe → No conflict, no forbidden fruit

### 4.3 ACL vs. Capability: The Architectural Root of the Problem

The current parental control landscape is entirely ACL-based:
- There's a global namespace (the internet, the app store, all device features)
- The child has an identity
- Rules attached to the identity determine what they can access
- Everything not explicitly denied is available (deny-by-default at the category level, but the categories are visible)

A capability-based approach would invert this:
- There is no global namespace visible to the child
- The child's environment contains only what's been explicitly granted
- Nothing is "denied" — things either exist in the space or they don't
- Growth happens by granting new capabilities (mounting new things into the space)

This is exactly the Plan 9 namespace model applied to parenting:
- Each child process (child user) has their own namespace
- `/net`, `/dev`, `/srv` contain only what's been mounted
- The parent process (parent user) constructs the namespace
- The child process has no knowledge of unmounted resources

### 4.4 Prior Art: "Empty by Default" as UX

While nobody has used the capability framing for children, several design patterns gesture toward it:

**Montessori "Prepared Environment":**
The Montessori educational philosophy centers on the "prepared environment" — a carefully curated space containing exactly the materials appropriate for the child's developmental stage. Maria Montessori wrote: "If we want our children to be independent and feel that they can do it themselves, we must provide the environment that allows them this space." The Montessori classroom is *not* a restricted subset of the adult world — it's a purpose-built environment that grows as the child grows. This is the closest educational philosophy to the namespace model.

**Chromebook Managed Guest Session:**
ChromeOS's managed guest sessions can be configured with specific apps and extensions, with no access to anything outside the configured set. Used in schools and kiosks. This is technically a namespace but isn't framed as one for children.

**iOS Guided Access:**
Locks the device to a single app. Too restrictive for general use but demonstrates the "bounded space" concept.

---

## 5. Gaps and Opportunities

### 5.1 What's Missing

**No product offers a general-purpose, composable "empty space" for children.**

Amazon Kids+ comes closest but is locked to Amazon's content ecosystem. YouTube Kids (approved mode) works only for video. Pinwheel works only for phone apps. None offer:

- A Space that works across devices and platforms
- Composable capabilities (mix apps, content, communication, and activities)
- Progressive expansion that the child can participate in
- Spaces that can be different for different contexts (school Space, play Space, reading Space)

**Nobody frames the problem architecturally.**

Every parental control product, every policy document, every research paper operates within the assumption that the digital environment starts fully open and must be restricted. The 5Rights Foundation gets closest to questioning this with "high privacy by default," but they're working within the restriction paradigm — better restrictions, not a different architecture.

**The capability/namespace framing is entirely absent from children's computing discourse.**

This is the single biggest gap. Decades of security research on least privilege, capability-based systems, and namespace isolation — none of it has been applied to the most obvious human use case: a developing human who should gradually gain capabilities.

**The Montessori connection is unmade.**

There's extensive Montessori literature on physical prepared environments, and extensive digital safety literature on children's online environments, but nobody has connected the two. The philosophical alignment is striking: both argue for purpose-built, age-appropriate environments that grow with the child. The Montessori approach would never start with "give the child access to everything, then restrict" — it starts with "prepare a space with exactly what's appropriate."

### 5.2 Where the Space Framing Offers Something New

**1. Eliminates the Arms Race**

If the child's digital Space contains only what's been mounted, there's nothing to circumvent. VPNs don't help because the Space doesn't have a "blocked internet" to tunnel past — it has no internet unless internet is explicitly mounted. Factory resets don't help because the Space is defined server-side/parent-side, not device-side.

**2. Eliminates the Forbidden Fruit Problem**

The child doesn't see what they can't have. There's no locked icon, no "Ask Parent" button, no awareness of what exists outside the Space. The absence of something you don't know exists creates no desire.

**3. Reframes Growth as Addition, Not Permission Removal**

"You're ready for YouTube" = mounting YouTube into the Space. It's a gift, a milestone, an expansion. Compare: "I'm removing the YouTube block" = acknowledging you were restricting something the child wanted. The emotional framing flips from adversarial to collaborative.

**4. Enables Context-Specific Environments**

A child could have:
- A **school Space** with educational apps, reference materials, and school communication tools
- A **play Space** with games, creative tools, and messaging with approved friends
- A **reading Space** with books and audiobooks, no distractions
- A **family Space** with shared photos, family chat, and family activities

Each Space is a different namespace. Switching Spaces isn't "changing permissions" — it's entering a different room.

**5. Aligns with Child Development**

The developmental psychology literature (Vygotsky's "Zone of Proximal Development," Piaget's stages, Montessori's planes of development) all describe growth as **progressive capability acquisition.** The namespace model mirrors this: a child's digital world grows by having new capabilities mounted into their spaces, matching their developmental readiness.

**6. Gives Children Real Autonomy Within Bounds**

Within their Space, the child has full autonomy. They're not being watched, restricted, or limited — they're exploring their world. The bounds are architectural (the Space's namespace), not supervisory (parental monitoring). This addresses the Oxford CCAI work's concern about protection undermining autonomy.

### 5.3 Honest Assessment: Challenges

**The "closed door" requires trust in the door-builder.** If parents construct the namespace, children must trust that the namespace is sufficient for their needs. A poorly constructed Space (too sparse) creates frustration; a richly constructed one achieves the goal.

**Transition is hard.** A 14-year-old who has used a fully open phone for years won't accept being moved to a namespace model. This works best as a first-computing-experience architecture.

**Social pressure is architectural.** If all of a child's friends are on TikTok, the absence of TikTok from their Space isn't "invisible" — it's conspicuous through social channels. The namespace model doesn't solve peer pressure; it solves device architecture.

**Implementation requires cross-platform cooperation.** A Space that only works on one device or one platform (like Amazon Kids+) is a walled garden, not a namespace. True Spaces would need to work across the child's entire digital life — which requires interoperability standards that don't exist yet.

**The "add vs. subtract" distinction may be overstated for older children.** A teenager knows the full internet exists. The namespace model works most cleanly for young children whose entire computing experience has been within Spaces.

---

## 6. Summary

The current parental control landscape is a $2B+ industry built on a flawed architectural premise: start with everything, subtract what's dangerous. This creates an arms race between parents (adding restrictions) and children (circumventing them), damages parent-child trust, and fails to prevent exposure to harmful content (57% of children encounter it despite controls).

A small number of products — Amazon Kids+, YouTube Kids (approved mode), Pinwheel — hint at an alternative: start with nothing, add what's appropriate. But these are all proprietary, single-vendor, single-context implementations.

The policy landscape (AADC, UN GC25, 5Rights) has established that children's digital environments should be designed with their best interests primary, with high privacy by default, and with age-appropriate protections. But the policy world hasn't questioned the architectural assumption of open-system-with-restrictions.

The academic literature on children's digital autonomy (Oxford CCAI, CHI 2023, Science 2024) has identified the protection-vs-autonomy tension and called for "features that expand autonomy with age." But this hasn't been connected to the capability-based security literature.

**The namespace model — Spaces as composable, empty-by-default digital environments that grow by capability addition — is the missing primitive.** It has strong prior art in systems security (Plan 9 namespaces, capability-based security), strong philosophical alignment with developmental psychology (Montessori prepared environments, Vygotsky's ZPD), and strong practical demand (parental frustration with restriction-based approaches).

No one has made this connection. That's the essay.

---

## Sources

See companion file: `notes/2026-04-04-screen-time-sources.md`