A shared tablet should not use a parent DNS profile because the device changes hands while DNS cannot identify who is holding it. Give the tablet its own neutral device profile, use child and adult accounts for person-specific controls, apply only shared domain boundaries, and make each handoff return the device to a known state.
A parent profile makes the wrong promise
A parent profile describes an adult context: broader browsing, private accounts, purchases, work services, and fewer content restrictions. When that profile follows shared hardware, the next child can inherit more than DNS. Saved sessions, autofill, email, photos, messages, open tabs, and payment access may remain available. Conversely, permanently applying a young child’s DNS policy to the tablet can frustrate adults and encourage them to disable protection rather than follow a predictable handoff.
The clean boundary is a tablet identity that says only what should remain true for everyone using that hardware. A family might block known malicious destinations across the device while leaving age, purchases, communication, screen time, and allowed apps to the signed-in account or supervised session. DNS becomes one layer in the handoff, not a substitute for knowing which person is active.
Separate the device from the person
| Decision | Device context | Person or session context |
|---|---|---|
| Known malicious domains | Useful shared DNS boundary | Optional additional boundary |
| Apps, purchases, and screen time | Cannot enforce through DNS | Child account or device control |
| Adult email and saved passwords | Lock and handoff hygiene | Adult account authentication |
| Website exception request | Device evidence may help diagnose | Named caregiver approval |
Platform tools are better suited to person-specific controls. Apple documents Content & Privacy Restrictions for apps, purchases, media ratings, web content, privacy permissions, and settings changes on a child’s iPhone or iPad.1 Google documents that Family Link can manage apps, screen time, Chrome and Search filters on supported supervised devices, while most supervision tools do not apply to iPhones and iPads.2 These platform differences are why a family should test the exact session rather than assuming a DNS profile supplies identity.
Build a handoff that survives real life
- Name the tablet as a shared device and decide which domain boundaries should apply regardless of the person holding it.
- Create distinct adult and child sessions where the platform supports them; otherwise define a visible sign-out, app close, and lock routine.
- Put age ratings, purchases, screen time, communication, and app permissions in the child or device controls that can enforce those decisions.
- Keep the tablet DNS profile neutral and narrow; do not copy the parent profile or make it carry every child-specific rule.
- Choose one required learning or entertainment journey and one destination that the shared DNS boundary should block.
- Write a short handoff card near the charging place without passwords: active session, required checks, exception owner, and return step.
- Review the routine when the device, operating system, browser, or family responsibility changes.
Do not turn the handoff into a platform setup guide. The operating system determines which account and supervision features exist, so follow its current documentation for the controls themselves. The durable family work is choosing the contexts, writing the transition, and testing it. A routine another caregiver can repeat is more reliable than a collection of settings only one person understands.
Verify both sides of the handoff
Start in the child context. Open one permitted service from start to finish, try one destination that should be blocked, confirm purchase and app boundaries, and check that another browser or in-app view does not silently use a different policy. Then complete the return: close the child session, remove any temporary exception, lock private child state, and confirm the adult account requires its own authentication.
Repeat the child handoff once more after the adult test. This catches the common failure in which an adult disables a restriction for a legitimate task but never restores it. Keep changes scoped to the tablet. If an allowed journey fails, identify whether the responsible layer is the app, account, device, network, or DNS response before broadening a rule across the family.
Read shared-device activity carefully
DNS filtering can act on domain lookups and record policy outcomes, but it cannot see page contents, search terms, in-app chats, voice audio, or full browser history. A lookup from the shared tablet does not identify the person who caused it; background updates and embedded services also make requests. RFC 9076 explains that DNS data can expose sensitive patterns.3 Use a short, named test window for diagnosis and never present device activity as a transcript of one family member.
Shared-tablet profile questions
Can a DNS profile switch automatically when a different person picks up the tablet?
Usually not from the DNS request itself. A resolver sees a governed device or network context, not the person holding the screen. Use operating-system accounts, supervised child accounts, browser profiles, and app controls for identity-sensitive choices, while the tablet DNS profile holds only boundaries that should follow the hardware.
Should the shared tablet use the strictest child policy?
Only if the tablet is genuinely dedicated to that child context. When adults and children share it, use a neutral device-level DNS boundary and put age-specific restrictions in the child account or session. Otherwise an adult may weaken the DNS rule for convenience, leaving the next child handoff less protected.
What is the most important shared-tablet test?
Test the transition in both directions. Confirm the child receives the intended account, app, web, and domain boundaries; then confirm the child session closes, private state is not exposed, and the adult can resume without disabling a protection that should still apply when the tablet changes hands again.
Give the tablet one resource in a family Space
If Veilty matches the routine, represent the shared tablet as its own resource inside one family Space.4 Reusable baseline and enforced policies can be assigned to Spaces: the tablet resource may override baseline policy where appropriate, but it cannot weaken enforced Space policy. Invite a caregiver to the account first, then grant the minimum Space role; invitation alone grants no Space access. Retained activity is Space-scoped, end-to-end encrypted, and available only when that role permits it, while live DNS requests still must be processed to apply policy.