DEV Community: Super Funicular

What Happens to a Phone's YouTube Live Stream When Mobile Data Drops? enableAutoStop, Stream Health, and the One-Minute Window

Super Funicular — Mon, 12 Oct 2026 07:14:43 +0000

If you stream a phone camera to YouTube Live over mobile data, the connection will drop at some point. A train goes past, the tower gets busy, the prepaid pack runs out, the power cuts and the router goes down with it. The phone usually reconnects within seconds or minutes.

The question this piece answers is narrower and more useful: what does YouTube do with your broadcast during that gap, and what decides whether you come back to the same live video or a new one?

Everything below comes from Google's own YouTube Live API reference and YouTube Help pages, quoted directly and linked at the end. Where the docs say nothing, I say that too, because a few of the answers people repeat on forums are not in any Google document.

What happens to a YouTube Live stream when the phone's data drops?

Short answer: YouTube stops receiving video, the stream is reported as inactive, and viewers see buffering. If the broadcast has auto-stop turned on, YouTube ends it "around one minute" after video stops arriving. After that, the live video is finished and a reconnect needs a new broadcast.

Whether a reconnect inside that minute continues the same broadcast is not documented by Google. Test it on your own channel before you rely on it (a 10-minute test is at the end).

If you use Background Camera RemoteStream: it records with the screen off to the phone's own storage, serves a live view to browsers on your own Wi-Fi, and can push to YouTube Live when you want to watch from outside. No account with us, no cloud of ours, no subscription. The YouTube behaviour below is YouTube's, and it applies to any app or encoder that streams to it.

Two objects, not one: the broadcast and the stream

Most confusion about drops comes from treating "the stream" as one thing. The YouTube Live API splits it in two, and we walked through how an app creates both in Streaming to YouTube Live From an Android Phone With the Screen Off:

A liveStream is the pipe. It holds the ingest address and the stream key. Your phone pushes video into it.
A liveBroadcast is the event viewers watch. It has a watch page, a privacy setting and, later, an archive.

The broadcast is bound to a stream. When the data drops, the pipe goes quiet. What happens to the event depends on settings on the broadcast.

The pipe usually survives. Google's reference for the isReusable property says a reusable stream "can be bound to multiple broadcasts. It is common for broadcasters to reuse the same stream for many different broadcasts if those broadcasts occur at different times." The broadcast guide says streams are reusable by default: "you can just reuse the stream ID for subsequent broadcasts."

So a drop does not mean you need a new stream key. It may mean you need a new broadcast.

What YouTube reports while the data is gone

The liveStream resource has a status.streamStatus field. Its documented values are:

Value	Google's description
`active`	"The stream is in active state which means the user is receiving data via the stream."
`inactive`	"The stream is in inactive state which means the user is not receiving data via the stream."
`ready`	"The stream has valid CDN settings."
`created`	The stream "does not have valid CDN settings."
`error`	"An error condition exists on the stream."

A dropped phone is the active to inactive case. Nothing in that list is "reconnecting".

There is also status.healthStatus.status, with four values: good, ok, bad, and noData, which Google describes as "YouTube's live streaming backend servers do not have any information about the stream's health status."

One thing I expected to be documented and is not: which health value you see during a gap. It would be easy to write "health turns red". No Google page says that. What the docs do give is a specific health issue for a weak connection, videoIngestionStarved:

"YouTube is not receiving enough video to maintain smooth streaming. As such, viewers will experience buffering."

That is the documented viewer experience of a starving stream: buffering. I could not find any Google text promising an "offline" card, a frozen last frame, or a slate. If you have seen one, that is observed behaviour, not a documented contract, and it may change.

The setting that decides it: enableAutoStop

The broadcast resource has a property called contentDetails.enableAutoStop. Google's reference describes it in one sentence:

"Indicates whether this broadcast should stop automatically around one minute after the channel owner stops streaming video on the bound video stream."

The broadcast lifecycle guide says the same thing from the other side: "YouTube will automatically end the broadcast around a minute after you stop sending video on the bound live stream."

Note the wording: "around one minute". Not 60 seconds exactly, and not a promise. Build in margin.

From YouTube's point of view, a phone that loses data and a person who deliberately stops streaming look the same. Both stop sending video. YouTube's own "Stream now" instructions say: "To end the stream, stop sending content from your encoder." That is fine for someone who means to stop. On mobile data, a dead zone does the same thing.

Once the broadcast ends, its lifeCycleStatus becomes complete, which the transition reference describes as "The broadcast is over. YouTube stops transmitting video." Moving a broadcast to live requires the stream to be active, and asking for a move YouTube does not allow returns an invalidTransition error. No Google page says in so many words "a complete broadcast can never go live again". But nothing documents a way back, and the safe plan is: after complete, a reconnect means a new broadcast, with a new watch URL.

That last part matters more than it sounds. If you sent a family member the link to watch the shop overnight, and the link pointed at a broadcast that auto-stopped at 2:14 a.m., that link now shows a finished video. The camera may be streaming again at 2:16 to a different URL.

What about enableAutoStart?

Its pair, enableAutoStart, "Indicates whether this broadcast should start automatically when you start streaming video on the bound live stream." The lifecycle guide gives its default as false. For enableAutoStop, the current reference documents no default, so check the value your app or encoder actually sets rather than assuming one.

Two more details from the docs, for anyone writing their own integration:

Per the lifecycle guide, auto-start and auto-stop "can't be set to true before the testing stage because the test would actually cause the broadcast to start."
enableAutoStop is listed as updatable. The exception is persistent broadcasts, where the invalidAutoStop error reads: "You cannot modify the enableAutoStop setting for a persistent broadcast."

Turn auto-stop off, then? Not so fast

If auto-stop ends broadcasts on every short drop, the obvious move is to switch it off. Then the broadcast stays in live while the pipe is inactive, and when the phone comes back the same event can carry on.

The cost is the other side of the same coin: if the phone never comes back (flat battery, a power cut that outlasts the backup, a prepaid pack that ran out at midnight), the broadcast stays "live" with nothing in it until someone ends it. For a camera nobody is watching, that is mostly harmless clutter. For a channel with subscribers, it is a live event showing buffering.

There is no right answer here. There is a choice that matches how your connection fails:

Short, frequent drops (moving vehicles, a weak signal at the edge of a tower, a busy cell in the evening): auto-stop off keeps one link working. Plan to end broadcasts yourself.
Long or final drops (power cuts, data packs running out, a phone left on a shelf for days): auto-stop on cleans up after itself. Accept that each reconnect is a new URL, and that anyone watching will need the new link.

We covered the power-versus-internet split in more detail in What Happens to a Phone Security Camera During a Power Cut or an Internet Outage?. The short version applies here: an internet outage and a power outage break different things, and a live stream needs both.

DVR: what viewers can do after a gap

One related setting is worth knowing. enableDvr "determines whether viewers can access DVR controls while watching the video", and Google says "The default value for this property is true." The Help Center puts it plainly: "Enabling DVR lets viewers pause, rewind, and continue during your stream."

For a camera stream, that means someone who opens the link late can scrub back a bit instead of only seeing "now". The reference also says the property "cannot be updated once the broadcast is in the testing or live state", so it is fixed before the stream starts.

Bitrate: make drops less likely in the first place

Many "drops" on mobile data are not total disconnects. The link gets too thin to carry the bitrate you asked for, and YouTube reports the stream as starved. YouTube's encoder settings page gives these H.264 figures:

Resolution	Minimum	Recommended
720p, 30 fps	3 Mbps	8 Mbps
480p, 30 fps	0.4 Mbps	4 Mbps

The gap between 720p and 480p minimums is large. On a weak or shared mobile connection, 480p sits much further inside what the link can hold. A bitrateLow health issue exists precisely for streams running under the recommended rate. If you see it often, dropping resolution is usually worth more than any reconnect setting.

The data side of this, including what a day of streaming costs on a prepaid pack, is in Should You Leave the SIM Card in an Old Phone Security Camera?.

The live stream is a view. The local file is the record.

A YouTube Live broadcast is a way to watch. It was never a good way to keep footage from a connection that drops. Anything that happened during a gap simply was not sent.

That is why a local recording on the phone matters more than any YouTube setting. It does not care whether the mobile network is up. Whether one phone can record to storage and stream at the same time depends on its camera hardware level. We explained how to check yours in One Camera, Two Consumers. Keeping recording running with the screen off is its own problem, covered in Why Does My Android Camera Stop Recording When the Screen Turns Off?.

A 10-minute test you can run today

Docs tell you what YouTube promises. A test tells you what your setup does. Use an unlisted broadcast so nobody else sees it.

Start a stream from the phone to YouTube and open YouTube Studio's live control room on another device.
Let it run for two minutes. Note the watch URL.
Turn on airplane mode on the phone for 20 seconds, then turn it off. Watch what the control room shows, and whether the same watch URL picks up again.
Do it again for 3 minutes. Check whether the broadcast has ended and whether a reconnect created a new one.
Write down both results. That is your real reconnect window, on your phone, your app and your network.

If the 20-second gap continues the same broadcast and the 3-minute gap does not, your setup is behaving the way the documented enableAutoStop description predicts. If both continue, auto-stop is probably off. If both end, something besides auto-stop is closing the session, and it is worth checking your app's own reconnect behaviour.

Summary

A dropped phone moves the YouTube stream from active to inactive. The stream key survives; reusable streams are the documented default.
The broadcast is what can end. With enableAutoStop on, YouTube ends it "around one minute" after video stops arriving.
After a broadcast is complete, plan on a new broadcast and a new watch URL.
The documented viewer experience of a starved stream is buffering. Nothing in Google's docs promises an "offline" screen.
enableAutoStop has no documented default. Check what your app sets.
Lower bitrate prevents many drops. A local recording covers the ones you cannot prevent.

Get the app on Google Play or read more at superfunicular.com.

Sources

All pages read on 12 October 2026.

YouTube Live Streaming API: LiveBroadcasts resource: enableAutoStop, enableAutoStart, enableDvr, lifeCycleStatus
YouTube Live Streaming API: Life of a Broadcast: auto-stop "around a minute", auto-start default, testing-stage restriction, stream reuse
LiveBroadcasts: transition: complete, invalidTransition, active requirement
LiveBroadcasts: update: invalidAutoStop
YouTube Live Streaming API: LiveStreams resource: streamStatus, healthStatus, isReusable
Live stream health status messages: videoIngestionStarved, bitrateLow
YouTube Help: Choose live encoder settings, bitrates, and resolutions
YouTube Help: Create a live stream with an encoder
YouTube Help: Live stream settings (DVR, auto-start and auto-stop)

The Camera-Trap Data Standard Starts With When the Camera Was Running, Not What It Saw

Super Funicular — Mon, 12 Oct 2026 05:07:18 +0000

Three raccoon visits in a week reads like a fact about raccoons. It is at least as much a fact about the camera: how many of those nights it was running, how far out it could make out movement, and whether the clock stamping each clip was right. Wildlife researchers who leave cameras out unattended share a data format that makes them write those things down, and it gives them a table of their own, ahead of anything the camera saw.

The format is Camtrap DP, maintained by the Camtrap DP Development Team under Biodiversity Information Standards (TDWG). I read its data specification and its FAQ for this piece. I build a camera app for old Android phones and I am not an ecologist, so nothing here is a survey method. What the standard offers a person with a phone pointed at a yard, a feeder or the gap under a fence is a checklist: what to record so that a count can later be read as a rate.

Three tables, and the first one describes the camera

The specification opens its data section plainly: "Data in Camtrap DP are organized as three related resources (CSV files): deployments, media and observations."

Media is the files. Observations are what a person, or a model, decided was in them. Deployments are the camera's own record: where it was, how it was set up, and for how long. Every media file and every observation carries a deploymentID that points back to that first table, so nothing the camera recorded can drift loose from the window it was recorded in.

Of the required fields in the deployments table, two are about time. The start is defined as "Date and time at which the deployment was started. Formatted as an ISO 8601 string with timezone designator", and the end gets the matching definition.

The timezone part deserves a pause. A clip stamped with a bare date and time names a moment only if you know which clock produced it. With a UTC offset attached it names one instant anywhere. A phone that crossed a time zone, or a folder of clips copied to a computer set to a different zone, is how a naive timestamp quietly moves by hours, and nothing in the file announces it.

The fields that describe what the camera could see

Beyond time, the deployments table has room for the physical setup. Among them:

cameraHeight, in meters.
cameraTilt, in degrees, from facing straight down to facing straight up.
cameraHeading, in degrees clockwise from north.
detectionDistance, defined as "Maximum distance at which the camera can reliably detect activity. Expressed in meters. Typically measured by having a human move in front of the camera."

That last definition is a procedure, and it is the most useful sentence in the document for anyone mounting a phone. Have someone walk across the frame at increasing distances, then open the recording and find the furthest point at which you can still tell that a body went past. For a phone that records continuously rather than on a trigger, that is my working reading of "detect": the reviewer can see it. Do the walk once in daylight and once after dark, because the answer changes with the light, and write down both.

A second field matters if your setup records on motion: cameraDelay, "Predefined duration after detection when further activity is ignored. Expressed in seconds." During that window a lingering animal is one clip and a second animal arriving behind it may be no clip at all. If your setup records continuously, the field stays empty. If it records on motion, the delay is a setting worth finding and writing down, because it shapes every count that follows.

Then there is timestampIssues, a flag for deployments whose media timestamps are "known to have (unsolvable) issues (e.g. unknown timezone, am/pm switch)". The standard keeps a place for a clock it cannot repair rather than dropping the data or pretending the clock was fine. That is a good habit on its own: if you are not sure the phone's clock was right, say so next to the data.

Gaps belong in the structure, not in a note

The deployments table has a start and an end, and I read the full field list for anything describing an interruption inside a deployment. There is a free-text deploymentComments field and nothing structured for downtime. So under this layout, a camera that stopped for a day and a half reads most cleanly as two deployments, not one deployment with a caveat. That is my reading of the schema rather than a rule the spec states, and it is the habit worth borrowing: when the phone was unplugged, the battery ran flat, or someone lifted it down to look at it, close the row, and open a new one when it is running again.

This matters because a gap is where false nulls live. A night with no clips is evidence that nothing came only if the camera was running that night. Count empty nights against a calendar and every night the camera was dark gets counted as a night nothing visited.

Blanks are observations too

The observations table has a required type with six allowed values: "animal, human, vehicle, blank, unknown, unclassified".

Blank is a category of its own. A clip set off by wind, a headlight sweep or a moth can be recorded as blank rather than deleted. Keeping blanks earns its space twice. They show the camera was alive at that hour, and their share tells you whether a placement is mostly wind and headlights before you spend evenings reviewing it. The standard also has a cameraSetupType field whose two values are setup and calibration, so the clips of you adjusting the mount are labelled as that instead of being counted as a visitor.

Count events, not files

The subtlest definition in the spec is observationLevel. Observations at the media level are tied to a single file and are "especially useful for machine learning and don't need to be mutually exclusive (e.g. multiple classifications are allowed)". Observations at the event level cover a group of files and "should be mutually exclusive, so that their count can be summed."

The practical version: a raccoon that ambles through over several minutes may land in more than one file, especially if a recorder splits long recordings into segments. Tally sightings per file and that single visit is counted as many times as there are files. Group the files into one event first, then count. The spec defines an event as a collection of media files and, in the fields I read, sets no time rule for how to group them, so pick a rule, write it down, and keep it.

A rate needs a denominator

Here is the whole idea in a small script. Two files, shaped like the standard's tables with only the columns needed. The first is the deployment log, kept by hand:

deploymentID,deploymentStart,deploymentEnd,cameraHeight,cameraTilt,cameraHeading,detectionDistance,timestampIssues,deploymentComments
yard-01,2026-10-01T18:00:00-04:00,2026-10-04T07:30:00-04:00,0.5,0,200,6.5,false,phone in fence-post box
yard-02,2026-10-05T19:15:00-04:00,2026-10-09T07:00:00-04:00,0.5,0,200,6.5,false,restarted after charger unplugged

The second holds event-level observations. Notice that o6 sits in the day and a half between the two deployments:

observationID,deploymentID,eventStart,eventEnd,observationLevel,observationType,scientificName,count
o1,yard-01,2026-10-01T18:02:10-04:00,2026-10-01T18:02:40-04:00,event,human,,1
o2,yard-01,2026-10-02T02:14:00-04:00,2026-10-02T02:15:30-04:00,event,animal,Procyon lotor,2
o3,yard-01,2026-10-03T23:40:00-04:00,2026-10-03T23:41:00-04:00,event,blank,,
o4,yard-02,2026-10-06T01:05:00-04:00,2026-10-06T01:06:00-04:00,event,animal,Procyon lotor,1
o5,yard-02,2026-10-07T21:30:00-04:00,2026-10-07T21:31:00-04:00,event,animal,Vulpes vulpes,1
o6,yard-02,2026-10-04T23:00:00-04:00,2026-10-04T23:01:00-04:00,event,animal,Procyon lotor,1

The script divides animal events by the hours the log says the camera was out, and refuses to quietly count anything that falls outside a logged window. Timestamps without an offset are rejected outright:

import csv
from collections import Counter
from datetime import datetime

def ts(s):
    t = datetime.fromisoformat(s.replace('Z', '+00:00'))
    assert t.tzinfo is not None, f'no UTC offset: {s}'
    return t

deps = {}
for r in csv.DictReader(open('deployments.csv')):
    start, end = ts(r['deploymentStart']), ts(r['deploymentEnd'])
    assert end > start, r['deploymentID']
    deps[r['deploymentID']] = (start, end)

days = sum((e - s).total_seconds() for s, e in deps.values()) / 86400
print(f'effort: {days:.2f} camera-days over {len(deps)} deployments')

hits, outside = Counter(), []
for r in csv.DictReader(open('observations.csv')):
    if r['observationLevel'] != 'event' or r['observationType'] != 'animal':
        continue
    s, e = deps[r['deploymentID']]
    if not (s <= ts(r['eventStart']) <= e):
        outside.append(r['observationID'])
        continue
    hits[r['scientificName']] += 1

for name, n in hits.most_common():
    print(f'{name}: {n} events, {100 * n / days:.1f} per 100 camera-days')
if outside:
    print('outside their deployment window:', ', '.join(outside))

Run with Python 3.10, it prints:

effort: 6.05 camera-days over 2 deployments
Procyon lotor: 2 events, 33.0 per 100 camera-days
Vulpes vulpes: 1 events, 16.5 per 100 camera-days
outside their deployment window: o6

Two things in that output are worth more than the rates themselves.

First, the rate uses 6.05 camera-days, not the calendar span. The same records counted from the first start to the last end cover 7.54 days, and dividing the two raccoon events by that gives 26.5 per 100 instead of 33.0, because 1.49 of those days had no camera watching. The calendar version is wrong in the comfortable direction: it makes a place look quieter than it is.

Second, o6 is reported, not counted. The log says the camera was off, and a record says it was on. One of the two is wrong: either the restart went unlogged, or the clip carries a bad timestamp, which is exactly what timestampIssues exists to flag. The script cannot tell which, and it should not guess. Counting it would lift the raccoon rate to 39.8 per 100 calendar days, with nothing in the output to show where the extra visit came from.

The count column holds individuals per event, and the script ignores it on purpose. Two raccoons in one clip is one visit; summing individuals answers a different question, and mixing the two inside one number is how a tally inflates.

Small numbers deserve a plain warning. Three events over six days is an anecdote with a unit attached. The unit is still the point: it is what lets you compare this month with next month, or the fence post with the shed, as long as both denominators are written down. Move the phone, change its height or heading, and that is a new deployment, since a rate from one setup says little about another.

What I did not establish

Whether rates from a phone camera can be compared with rates from a dedicated trail camera. Lens, trigger and night illumination all differ, and I have no data on how much that moves a count.
How researchers in a given study define an independent event. The standard leaves room for the rule; it does not supply one in the fields I read.
How any particular app names, splits or timestamps its files. I am describing a published data standard and a short script, not the internals of my own product or anyone else's.
Which version of the specification a future reader will see. I read the data page and FAQ as fetched for this piece, and both can change.

Try it: Background Camera RemoteStream on Google Play -- record with the screen off and keep the footage on the phone. Setup notes and other write-ups are at superfunicular.com.

Sources. Camtrap DP data specification and Camtrap DP frequently asked questions, both maintained by the Camtrap DP Development Team under TDWG. Quotations are verbatim from the data page as fetched. A count tells you what came; the deployment log tells you whether anyone was watching, and only the two together say how often.

Re-Muxing a Phone Video With ffmpeg Kept Where It Was Shot and Dropped When

Super Funicular — Mon, 12 Oct 2026 01:07:07 +0000

I copied a test clip with ffmpeg, changing nothing but the container, and the copy came out still saying where the clip was recorded while no longer saying when. That is the opposite of what most people want from a quick clean-up before sending a video to someone, and it is easy to miss, because the picture is identical and nothing on screen tells you the file's metadata moved.

This piece is about location data inside phone video files: where Android's recording API puts it, how to read it with ffprobe, and which ffmpeg commands remove it while keeping the recording time. I build a camera app for old Android phones. I am not describing how my app or any other app writes files; every result below comes from a clip I generated and tagged myself, with the commands shown so you can run them on your own footage.

Where the coordinates go

Android's MediaRecorder class documents a method for exactly this. Its reference page says setLocation will "Set and store the geodata (latitude and longitude) in the output file." It then says where and in what form: "The geodata is stored in udta box if the output format is OutputFormat.THREE_GPP or OutputFormat.MPEG_4, and is ignored for other output formats." And: "The geodata is stored according to ISO-6709 standard."

Three things follow from those sentences.

The location lives in the container, in a user-data box, separate from the video frames. You cannot see it by watching the clip, and you cannot remove it by cropping or trimming the picture.
It is written as text in a standard coordinate notation, a signed latitude followed by a signed longitude. Anything that can read container tags can print it.
Whether a particular recording carries it depends on the app that made it and on that app's settings. The API makes it possible; it does not make it automatic. The file itself is the reliable witness to what it contains.

A test clip with a known location

To have something to measure, I made two short clips, one MP4 and one MOV, both tagged with a recording time and with coordinates a short walk from the Royal Observatory in Greenwich. Using a public landmark keeps my own location out of the example.

for ext in mp4 mov; do
  ffmpeg -v error -f lavfi -i testsrc=size=320x240:rate=15 -t 2 \
    -c:v libx264 -pix_fmt yuv420p \
    -metadata location="+51.4779-000.0015/" \
    -metadata creation_time="2026-10-11T12:00:00Z" "clip.$ext"
done

The testsrc input is a synthetic colour-bar pattern, so the clips are tiny and contain nothing private. Everything below was run with ffmpeg 4.4.2 and Python 3.10.

Reading what a file says about itself

ffprobe prints container tags. Asking for just the two tags this piece is about keeps the output short:

ffprobe -v error -show_entries format_tags=location,creation_time -of default=nw=1 clip.mp4

TAG:creation_time=2026-10-11T12:00:00.000000Z
TAG:location=+51.4779-000.0015/

That is the whole story of the clip in two lines: when it was recorded and where. Point the same command at a real phone recording before you share it. If the location line is there, the coordinates of wherever the phone was standing travel with the file.

The quick copy that keeps the wrong half

The most common thing people do to a video with ffmpeg without re-encoding it is a stream copy into a new file, for example to rename the container or to trim it. Here is the plainest version, followed by the same tag check on the result:

ffmpeg -v error -i clip.mp4 -c copy remux.mp4
ffprobe -v error -show_entries format_tags=location,creation_time -of default=nw=1 remux.mp4

TAG:location=+51.4779-000.0015/

The location came through. The recording time did not.

The first half is documented. The -map_metadata section of the ffmpeg manual says: "By default, global metadata is copied from the first input file, per-stream and per-chapter metadata is copied along with streams/chapters." Location is global metadata, so a plain copy carries it forward.

The second half I can only report, not explain from the text I quoted. With ffmpeg 4.4.2 and no metadata options, creation_time was absent from the output in my runs. I have not checked whether newer releases behave the same way, so treat this as a thing to test on your own build rather than a rule.

For anyone keeping footage as a record, that combination matters. A copied clip that has lost its recording time but kept its coordinates is a worse record and a bigger privacy exposure at the same moment.

Removing everything

The manual also describes the switch that turns automatic copying off: "A negative file index can be used to create a dummy mapping that just disables automatic copying." In practice that is -map_metadata -1:

ffmpeg -v error -i clip.mp4 -c copy -map_metadata -1 stripped.mp4
ffprobe -v error -show_entries format_tags=location,creation_time -of default=nw=1 stripped.mp4 | wc -l

The second command counts the tag lines ffprobe prints for the two keys, and the count is zero. Both the location and the recording time are gone.

That is the right call for a clip headed somewhere public, where the time is as personal as the place. It is the wrong call for a clip you might need to rely on later, such as a recording of damage, a delivery or a dispute, where the time is the point.

Keeping the time, dropping the place

The version I would actually use asks for metadata to be copied, then overrides the one key that should not travel by setting it to an empty value. The MP4 file also had a language-suffixed copy of the same tag, so both names are cleared:

for f in clip.mp4 clip.mov; do
  out="nolocation.${f##*.}"
  ffmpeg -v error -i "$f" -c copy -map_metadata 0 \
    -metadata location= -metadata location-eng= "$out"
  echo "== $out"
  ffprobe -v error -show_entries format_tags=location,creation_time -of default=nw=1 "$out"
done

== nolocation.mp4
TAG:creation_time=2026-10-11T12:00:00.000000Z
== nolocation.mov
TAG:creation_time=2026-10-11T12:00:00.000000Z

Both containers keep their recording time and lose their coordinates. The explicit -map_metadata 0 matters here: it is what brings creation_time back in my runs, in contrast to the bare copy above.

Checking the bytes, not just the tags

A tag reader shows you what it knows how to parse. To be sure the coordinates were removed from the file and not just hidden from one tool, I searched the raw bytes for the two location boxes that turned up in these clips and for the latitude written as text:

import sys

# Byte-level check: does a location box or an ISO 6709 string survive?
MARKERS = {
    "loci box": b"loci",
    "©xyz box": b"\xa9xyz",
    "latitude text": b"+51.4779",
}

for path in sys.argv[1:]:
    data = open(path, "rb").read()
    found = [name for name, m in MARKERS.items() if m in data]
    print(f"{path}: {', '.join(found) if found else 'none of the markers'}")

python3 boxes.py clip.mp4 clip.mov remux.mp4 stripped.mp4 nolocation.mp4 nolocation.mov

clip.mp4: loci box
clip.mov: ©xyz box, latitude text
remux.mp4: loci box
stripped.mp4: none of the markers
nolocation.mp4: none of the markers
nolocation.mov: none of the markers

Two details from that output are worth keeping in mind:

The two containers stored the same coordinates differently. The MP4 that ffmpeg wrote used a loci box, and a text search for the latitude finds nothing in it even though the location is present, so the box evidently does not store the coordinates as readable text. The MOV used a ©xyz box with the coordinate string in plain text. A search for the digits alone would have reported the MP4 as clean when it was not.
The plain copy, remux.mp4, still holds its loci box, which agrees with the tag check above. The stripped and cleaned files hold none of the three markers.

Finally, I confirmed that none of this touched the picture. Extracting the video stream from three of the files and hashing it gives the same value each time:

for f in clip.mp4 stripped.mp4 nolocation.mp4; do
  ffmpeg -v error -i "$f" -map 0:v -c copy -f h264 - | md5sum | cut -c1-12
done

c1d2fe78b45f
c1d2fe78b45f
c1d2fe78b45f

Same frames, different envelope.

A short routine for clips you share

Run the ffprobe tag check on the file you are about to send.
If a location tag is present and the clip is going anywhere public, use the keep-the-time command above, or -map_metadata -1 if the time should go as well.
Re-run the tag check on the output, and for anything sensitive, the byte check too.
Keep the original, untouched, somewhere only you control. The cleaned copy is for sharing; the original is the record.

What I did not establish

What any particular camera app writes. The Android reference describes what the API can do. Some apps expose a setting for location tags and some do not; the file is the thing to check.
What happens on upload. I did not test whether any video site, messaging app or phone share sheet removes location from a video file, and I would not assume it does.
Per-stream tags and other metadata formats. I checked file-level tags and three byte markers. Some phones and editors write additional metadata blocks, and a thorough audit would look for those too.
Why the plain copy dropped creation_time. I observed it on one ffmpeg build and did not trace the cause.
How accurate the stored coordinates are on a real recording. A tag can only be as good as the position fix the phone had when it was written.

Try it: Background Camera RemoteStream on Google Play -- record with the screen off and keep the footage on the phone. Setup notes and other write-ups are at superfunicular.com.

Sources. The Android MediaRecorder API reference, setLocation section, and the ffmpeg command-line documentation, -map_metadata section. Quotations are verbatim from both pages as fetched. Test results come from the scripts above, run as shown.

The National Archives Will Take Phone Video as a Permanent Record. Its List Names the Codec, Not the File Extension

Super Funicular — Sun, 11 Oct 2026 16:54:41 +0000

Short answer: The U.S. National Archives publishes the file formats it accepts when a federal agency hands over records meant to be kept permanently. For digital video, the acceptable list includes the MPEG-4 wrapper with H.264 inside it, a combination many phone cameras can record. The list is written as wrapper plus codec, though, so a file ending in .mp4 is half an answer. HEVC, which many phones offer as a space-saving setting, does not appear in the digital video table at all. Beyond format, the same bulletin requires files that are valid against their specifications, no encryption standing between the archive and the content, and a retained copy until custody is confirmed. All three translate into checks anyone can run on a folder of recordings.

Nobody is going to accession your driveway footage. Still, the people whose job is keeping video readable for decades have written down, in plain tables, what they will take, and it is more specific than most advice about saving recordings. I read NARA Bulletin 2014-04, the appendix of tables it points to, and the Records Express post that announced the most recent change to the video rows. What follows is a close reading by someone who builds a camera app, aimed at developers and anyone else holding a large pile of phone video. I am not an archivist, and this is federal agency guidance, which governs agencies and nobody else.

What the bulletin is for

The bulletin defines the property it is screening for, and the definition is narrower than a general idea of a good format:

"Sustainability, as it relates to electronic file formats, is the suitability of a format to preserve encoded information over time."

Note what is absent. Picture quality, file size and popularity of a particular app are not in the sentence. The question is whether the bits can still be turned back into the picture by someone else, later, with software that exists then.

The appendix splits moving images into two groups. Digital cinema covers digitized film. Digital video is described as "including both video digitized from analogue sources and born digital video", and born digital video is what a phone produces.

The video table, read as a developer would

The bulletin explains why the table has more than one column, and this is the part I would put in front of anyone who has ever told someone to just save it as MP4:

"Many file formats, especially those used with digital audio and video, are composed of multiple parts, including a wrapper, which is the file format, and an embedded encoding stream or codec."

Then it attaches a requirement to both parts:

"Agencies must submit electronic records in files that are valid both according to the wrapper and any specified codec standards."

So the digital video table names a wrapper and a codec on each row. As fetched for this piece, its acceptable formats include uncompressed AVI and uncompressed QuickTime, Windows Media Video with VC-1, MPEG-2 video, MXF carrying losslessly compressed J2K, and the row that matters to phone owners: MPEG 4, with H.264 in the codec column.

That row is the good news in this reading. H.264 inside an MPEG-4 file is a common output of phone cameras and of most video tools, and it sits on the acceptable list for records the federal government intends to keep permanently. A phone owner may already be holding files in a format the archive would take. The way to know is to check a file, which the commands further down do.

What is not on the table is just as useful. I searched the fetched page for HEVC, H.265, VP9 and WebM and found none of them anywhere on the page. Many phones offer HEVC as a high-efficiency option, since it generally produces smaller files at similar quality. If that switch is on, the recordings are in a codec this table does not list.

Here is the honest limit of that observation. The table does not give a reason for any individual absence. The bulletin does say what NARA weighs:

"Criteria such as the availability of technical specifications and licensing restrictions will be used to determine whether a format is sustainable and appropriate for use with permanent electronic records."

I can tell you HEVC is missing from the list. I cannot tell you, from these pages, whether that reflects a judgment against it or a review that has not happened. Anyone who claims to know which, citing only these documents, is guessing.

The preferred row that looks like a typo

The single preferred format in the digital video table is listed as AV1 Image File Format, AVIF, with AV1 as the codec. AVIF is better known as a still image format, so the entry is worth a second look. The Records Express post that announced it gives one reason:

"To remain consistent with NARA's digitization and motion picture preservation labs, this update adds AVIF as a preferred format for Digital Video"

That is the whole stated rationale. It ties the choice to what NARA's own labs produce, not to anything about consumer recording. For a phone owner the practical reading is modest: the preferred row describes how an archive lab digitizes, and the acceptable rows are where ordinary camera output lands.

The tables also move. The bulletin says NARA "may add new formats as they are adopted for use with Federal records, or may remove those that become obsolete". A reading of this table is a reading of one date. The page I fetched says it was last reviewed in March.

Three requirements that are about files, not formats

Section eight of the bulletin lists steps agencies must take in all cases. Two of them apply cleanly to a home archive.

The first concerns locks:

"Deactivate passwords or other forms of file level encryption including digital rights management (DRM) technologies commonly used with audio, video, and some publications that impede access to record data"

The archive's position is that a lock on the file is a dependency on whoever holds the key. For a household this is a question to ask of any camera system: when footage leaves the device, is it a plain file any player opens, or is it encrypted so that it opens only inside the vendor's viewer and account? The rule is written against the second kind.

The second concerns copies:

"Retain a copy of all permanent electronic records transferred to NARA until receiving official notification that NARA has accepted legal custody of the records."

The rule has an end condition, and the end condition is confirmation from the receiving side, not completion on the sending side. Translated to a home setup: a recording copied to a laptop or a drive is not safe to delete from the phone because the copy finished. It is safe once the copy has been opened and played from where it landed.

The third requirement is the validity rule already quoted, and it is the one with a practical trap.

Checking a folder yourself

Two commands from FFmpeg cover most of this. The first prints the codec of the video stream, which tells you which side of the HEVC line a file sits on:

ffprobe -v error -select_streams v -show_entries stream=codec_name -of default=nw=1:nk=1 clip.mp4

On a test clip encoded with x264 it prints h264. On a test clip encoded with x265 it prints hevc. To sweep a folder of files without spaces in their names:

for f in *.mp4; do printf '%s ' $f; ffprobe -v error -select_streams v -show_entries stream=codec_name -of default=nw=1:nk=1 $f; done

The second command decodes every frame and throws the output away, which is the closest thing a household has to a validity check:

ffmpeg -v error -i clip.mp4 -f null - 2> clip.decode.log

Here is the trap, found by testing rather than assumed. I made a short clip with its index at the front of the file, cut off the last quarter, and decoded it. FFmpeg printed errors about invalid NAL unit sizes and a partial file, and then exited with status zero. A script that only checks the exit code would have reported that broken file as fine. A clip with its index at the end, cut in half, failed differently: it refused to open and exited non-zero.

So the check that matters is whether the log is empty:

test -s clip.decode.log && echo 'decode errors, read clip.decode.log'

Two honest limits apply. A clean decode shows that this build of FFmpeg could read every frame, which is a necessary condition for validity and not a proof of it. NARA's bulletin does not name a validation tool, and I will not invent one for it. And the behaviour I describe is from the FFmpeg build in my test environment; other builds may report differently, which is exactly why the log, not the exit code, is the thing to read.

What this reading does not cover

Audio. The bulletin has a separate audio table, and a video file's audio track is held to it. I did not check what codec phone recordings use for sound.
Metadata. NARA has a separate metadata bulletin. Timestamps and location data in a recording are outside this piece.
Whether anything here binds a household. It does not. The value is that an institution with a long time horizon wrote its criteria down where anyone can read them.
What any specific app writes. I am describing the published guidance and two FFmpeg commands, not the internals of my own product or anyone else's.

The tables were read as fetched for this piece, the bulletin as revised in its current online form, and the Records Express post as originally published. All three can change, and the bulletin says plainly that the tables will.

Try it: Background Camera RemoteStream on Google Play -- record with the screen off and keep the footage on the phone. Setup notes and other write-ups are at superfunicular.com.

Sources. NARA Bulletin 2014-04, Format Guidance for the Transfer of Permanent Electronic Records, Appendix A tables of file formats and the Records Express post on the updated transfer guidance tables. Quotations are verbatim from those pages as fetched. The archive asks for the same thing from every file it keeps: that a stranger with ordinary tools can open it later, and a folder of home video can be held to that standard without any agency involved.

California Wrote a Windshield Exemption for Dashcams, and a Phone That Records the Whole Drive Does Not Fit Its Definition

Super Funicular — Sun, 11 Oct 2026 12:54:26 +0000

Short answer: California bans almost anything stuck to a windshield, then lists exceptions. A phone used as a dashcam has to squeeze into one of two: the portable GPS exception, which covers navigation and nothing else, or the video event recorder exception, whose definition describes a device that loops and keeps only short clips around a jolt. A phone recording the whole trip to storage matches neither description. The mount that does not depend on matching a definition sits below the glass, on the dash or a vent, clear of your view.

I owe this piece to a correction. Our own roundup of Android dashcam apps talks about a sunlit windshield mount as if the windshield were simply where the phone goes, and an older list of ours suggests a vent or windshield mount in the same breath, as though the two were interchangeable. The heat advice in those pieces holds up. The placement advice skipped a question that the vehicle code answers before any battery or heat question gets a turn: is the thing allowed on the glass at all?

I read three texts to find out: California's windshield section, Minnesota's, and the federal rule for commercial trucks. They disagree with one another in ways that are useful to see side by side. None of what follows is legal advice, and I am not a lawyer. It is a close reading of short statutes, aimed at people whose dashcam happens to be a retired phone.

California starts from a flat ban

The first sentence of California Vehicle Code section 26708 is about as broad as a traffic rule gets: "A person shall not drive any motor vehicle with any object or material placed, displayed, installed, affixed, or applied upon the windshield or side or rear windows." A second sentence then reaches past the glass to anything in the cabin that "obstructs or reduces the driver's clear view through the windshield or side windows". So there are two separate questions for a phone on a mount. Is it on the glass? And wherever it is, does it cut into what the driver can see?

Everything else in the section is a list of exceptions to the first sentence: mirrors, sun visors, a toll transponder in a small square at the top centre, certain stickers in the lower corners. Two of the exceptions are the ones a phone owner reaches for.

The GPS exception. A portable GPS may sit in a seven-inch square in the lower corner farthest from the driver, or a five-inch square in the lower corner nearest the driver and outside an airbag deployment zone, "if the system is used only for door-to-door navigation while the motor vehicle is being operated". That condition is the whole point. A phone mounted there and showing turn-by-turn directions is the case the paragraph was written for. A phone mounted there with the screen off, recording the road for the whole trip, is doing a different job, and the paragraph does not describe it.

The video event recorder exception. This is the paragraph people mean when they say California allows dashcams on the windshield, and it allows the same two lower-corner squares plus a five-inch square at the top centre. But it comes with its own definition. A video event recorder, for this section, is "a video recorder that continuously records in a digital loop, recording audio, video, and G-force levels, but saves video only when triggered by an unusual motion or crash or when operated by the driver to monitor driver performance". The same paragraph then caps what such a device may store at no more than thirty seconds either side of a triggering event, requires a notice posted where passengers can see it stating that "a passenger's conversation may be recorded", and adds: "The registered owner or lessee of the vehicle may disable the device."

Read that definition against how a phone is typically set up for dashcam duty. Most people start a recording when they pull out and stop it when they park, and the file is the trip. The definition describes something else: a rolling buffer that is thrown away unless a jolt, a crash or the driver's own button tells it to keep a short clip. Whether a phone app that does loop and trigger, and caps what it keeps, could fit the paragraph is a question I could not settle. I found no California guidance that applies the definition to a phone app either way. What I can say from the text is that a phone recording continuously to storage is not what the definition describes, so leaning on this exception for it is a bet, not a reading.

The phone law already names a better spot

California has a second statute that matters here, because it is written about phones rather than cameras. Section 23123.5 is the hands-free rule. It lets a driver operate a phone by hand only if the phone is mounted on the windshield in the same manner as the portable GPS above, or is "mounted on or affixed to a vehicle's dashboard or center console in a manner that does not hinder the driver's view of the road", and only for a touch made "with the motion of a single swipe or tap of the driver's finger".

That statute is about touching the phone, not about recording with it, so it does not settle the windshield question for a dashcam. What it does is name, in so many words, the place the legislature expects a phone to live in a car: on the dashboard or the centre console, out of the way of the road. A phone mounted there is off the glass, which takes the first sentence of section 26708 out of play, and leaves only the clear-view test, which any placement has to pass anyway.

Minnesota asks a different question

Minnesota Statutes section 169.71 is not built around things stuck to the glass. Its prohibition is on driving with "any objects suspended between the driver and the windshield", followed by a list of exceptions. Two of them look relevant. One covers "driver feedback and safety monitoring equipment when mounted immediately behind, slightly above, or slightly below the rearview mirror". Another covers "global positioning systems or navigation systems when mounted or located near the bottommost portion of the windshield".

So the Minnesota map is close to the reverse of California's. California's camera exception offers the lower corners and the top centre; Minnesota's monitoring-equipment exception points at the mirror, and its navigation exception points at the bottom of the glass. A phone recording the road from behind the mirror might count as driver feedback and safety monitoring equipment. The statute does not define that phrase in the subdivision I read, and I found nothing that applies it to a phone, so this is an open question rather than a permission.

The broader lesson is that a mount position that is fine in one state can sit outside the exception in the next. A suction cup moves easily. The statute it has to satisfy does not move with it.

Trucks get the clearest rule, and it names cameras

The federal rule for commercial motor vehicles, 49 CFR 393.60, is the most explicit of the three, and of the texts I read it alone names cameras in its definitions. Ordinary windshield devices on a truck have to sit high, outside the wiper sweep, and "outside the driver's sight lines to the road and highway signs and signals". Devices that qualify as vehicle safety technology get their own placement limits instead, measured from the wiper sweep: one reaching eight and a half inches down from its top edge, one reaching seven inches up from its bottom edge, and the same sight-line test on top.

The definition of vehicle safety technology, in 49 CFR 393.5, lists a "driver camera system" among its examples, and closes by saying it includes "systems and devices that contain cameras, lidar, radar, sensors, and/or video". California's own section borrows that federal definition for the commercial vehicles it lists elsewhere in its code. None of this governs a private car. It is worth reading anyway, because it shows what a regulator writes down when it sets out to permit windshield cameras deliberately: a band measured from the wipers, and a sight-line test that applies to every device regardless of what it is.

What I would check before the mount goes up

Read your own state's windshield section. Every state I looked at has one, and they are short. Search for your state's vehicle code together with the words windshield and obstruction, and read the list of exceptions in full rather than a summary of it.
Work out which exception your setup would claim, if any. If the answer is the GPS one, the phone has to be navigating. If it is a camera exception, compare the statute's definition with what your recording app is set to do, not with what the device is called on the box.
Prefer a dash or vent mount for recording. Off the glass, low, and outside the arc of road you scan while driving. In California that position is named outright in the hands-free statute, and it avoids the definitional question entirely.
Treat cabin audio as its own decision. California puts a passenger notice on its camera exception for a reason. If you leave the microphone on, the people riding with you should know.
Start and stop the recording before the car moves. In California a touch while driving is limited to a single swipe or tap, and a phone mid-setup on a mount invites more than that.

What I could not verify

Whether California enforcement treats a phone running a loop-and-trigger app as a video event recorder. The definition is functional and says nothing about the hardware; I found no ruling or guidance either way.
What Minnesota counts as driver feedback and safety monitoring equipment. The phrase appears in the exception without a definition in the subdivision I read.
The other forty-eight states. I read two states and one federal rule. I would rather say that plainly than imply coverage I did not do.

The texts quoted are the published versions I fetched: California's section 26708 as amended with effect from January 2026, its hands-free section as current at the start of this year, Minnesota's current statutes, and the federal regulation as shown on eCFR this month. Statutes change, and a mount usually outlives the version of the law that was in force when it went up.

Try it: Background Camera RemoteStream on Google Play -- record with the screen off and keep the footage on the phone. Setup notes and other write-ups are at superfunicular.com.

Sources. California Vehicle Code section 26708 on Justia, California Vehicle Code section 23123.5 on FindLaw, Minnesota Statutes section 169.71 from the Revisor of Statutes, the federal glazing rule at eCFR and the federal definitions section at Cornell LII. Quotations are verbatim statutory and regulatory text as published. The glass in front of the driver belongs to the driver first, and the statutes read as if they were written by people who had sat behind a badly placed mount.

Is My Phone Security Camera Exposed to the Internet on IPv6? A Local-Only, No-Cloud Check for Jio and Other IPv6 Networks

Super Funicular — Sun, 11 Oct 2026 07:17:51 +0000

Yesterday we published a guide on which SIM card to leave in an old phone security camera. One of its points was that on mobile data, people outside usually cannot connect in to the phone, because operators often share one IPv4 address between many customers.

That is true for IPv4. It is not the whole story, and for a lot of readers it is not even the main story. On Reliance Jio, APNIC Labs measures about 96% of users as IPv6-capable. Across India as a whole, Google's own statistics show about 68% of its users reaching Google over IPv6 (as of 9 October 2026). Many home broadband connections now hand out IPv6 too.

IPv6 changes one assumption that most "local-only camera" advice quietly depends on. This piece explains which assumption, and gives you a two-phone test that answers the question for your own setup.

Is my phone security camera exposed to the internet on IPv6?

Maybe, and you can check in a few minutes. On IPv4 home Wi-Fi, the thing that usually keeps a phone's camera page off the internet is the router's address translation (NAT): the phone has a private address like 192.168.1.42, and nothing outside can start a connection to it unless you forward a port. On IPv6 there is normally no NAT. The phone gets an address that is valid on the whole internet. What keeps it private then is your router's IPv6 firewall, and that may or may not be switched on.

So the honest answer is not "yes" or "no". It is: find the phone's IPv6 address, then try to open the camera page on it from outside. The steps are below.

If you use Background Camera RemoteStream: it records with the screen off to the phone's own storage and serves a live view from a small web server on the phone, for browsers on your own Wi-Fi. No account, no cloud, no subscription. The test below works the same for our app as for any other camera app with a built-in viewer. It gives you an answer about your network instead of a promise from a developer.

Why "local-only" used to work without anyone thinking about it

Here is the IPv4 picture, the one most of us learned:

Your router has one public address.
Every device inside gets a private address (192.168.x.x, 10.x.x.x). These are not routable on the internet.
When the phone opens a connection out, the router remembers it so the reply can find its way back.
When someone outside tries to open a connection in, the router has nothing to match it to, and drops it.

That last step is why a camera page "only works on my Wi-Fi" without you ever touching a firewall setting. We described it in more detail in how to watch your phone's camera from outside your home network without port forwarding.

NAT was never designed as a security feature. It was designed to stretch a shortage of IPv4 addresses. The protection was a side effect.

What IPv6 changes

IPv6 was built so that address sharing would not be needed. RFC 4864, the IETF document about protecting home networks on IPv6, opens by saying so:

"IPv6 was designed with the intention of making NAT unnecessary, and this document shows how Local Network Protection (LNP) using IPv6 can provide the same or more benefits without the need for address translation."

Google's Android team said the same thing more plainly in 2025: "When every device can get global IPv6 addresses, there is no need to use NAT for address sharing!"

So on an IPv6 network, your camera phone typically has an address that is reachable, in principle, from anywhere. Whether a connection from outside actually arrives depends on one thing: does the router filter unsolicited incoming IPv6 traffic?

RFC 4864 says the router should:

"...provide a default configuration where incoming traffic is limited to return traffic resulting from outgoing packets"

That is the same "only replies come back in" behaviour you got from NAT, now done on purpose by a firewall.

Does my router block incoming IPv6 by default?

Often, but you cannot assume it. The IETF's advice for home routers, RFC 6092, says a router should by default refuse unsolicited incoming connections. But RFC 6092 is an informational document, not a rule. It also requires an easy "transparent mode" that lets everything in, and says:

"The transparent mode of operation MAY be the default configuration."

And the main requirements document for home IPv6 routers, RFC 7084, "takes no position on whether such functionality is enabled by default."

In plain English: many routers ship with the IPv6 firewall on. Some do not. Some ISPs ship a router with their own settings. Some routers have the IPv6 firewall as a separate switch from the IPv4 one, and people turn one off while fixing something else.

The phone has more than one IPv6 address

Open your phone's IPv6 addresses and you will usually see several. On stock Android, tap your connected Wi-Fi network in Settings and look for a section called "IPv6 addresses". Menus differ between manufacturers, so on some phones you may need to look under "Advanced" or "Status".

Here is how to read the list:

Starts with	What it is	Reachable from the internet?
`fe80:`	Link-local. Only works on the same Wi-Fi.	No. Routers must not forward it.
`fd` (or `fc`)	Unique local. Like a private IPv4 address.	Not expected to be routed on the internet.
`2` or `3` (for example `2405:`, `2409:`)	Global. Valid on the whole internet.	Yes, unless something filters it.

Two more details matter:

Android uses temporary "privacy" addresses for outgoing connections. In Android's own source code, IPv6 privacy addresses are switched on and preferred for connections the phone starts. RFC 8981 sets the default for these at one day of use and two days of life. They rotate. That protects you when browsing.
A temporary address does not hide a server. The phone also has a stable global address. A web server on the phone can be reached on that one. The rotating addresses are for leaving, not for being found.

And a myth to drop: "IPv6 addresses are too long to guess, so nobody will find me." RFC 7707, the IETF's own study of how IPv6 networks get scanned, admits that brute-forcing a whole /64 network is infeasible, but warns that "the search space for such attacks is typically much smaller than the one traditionally assumed." Addresses also leak through logs and apps. Don't rely on being hard to find.

The two-phone test (about five minutes)

You need the camera phone and one other phone that has mobile data.

Step 1. Note the camera page address. Open your camera app's live view address as you normally do on your Wi-Fi (for example http://192.168.1.42:8080). Write down the port number, the part after the colon. Use whatever port your app shows you; 8080 is only an example.

Step 2. Note the camera phone's global IPv6 address. In the Wi-Fi details, pick the address that starts with 2 or 3. If there are several, try them one at a time. If there is no address starting with 2 or 3, your Wi-Fi has no global IPv6 and this particular risk does not apply on Wi-Fi. Skip to the mobile data note below.

Step 3. Check the camera page on IPv6 at home first. On a laptop or phone that is on the same Wi-Fi, type the address into the browser inside square brackets, with the port after:

http://[2405:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx]:8080/

The brackets are required. RFC 3986 says an IPv6 address in a URL is "distinguished by enclosing the IP literal within square brackets." Without them the browser cannot tell where the address ends and the port begins.

If the page loads at home, the camera page answers on IPv6. Go to step 4.
If it does not load at home, the app's server is probably not reachable on that address. Step 4 will most likely also fail, but run it anyway for a clear answer.

Step 4. Make sure the second phone really has IPv6. Turn Wi-Fi off on the second phone, so it uses mobile data. Open ipv6.google.com. That name only has an IPv6 address, so it only loads over IPv6.

If it loads, the second phone can reach IPv6 sites. Continue.
If it does not load, stop. A failed test from this phone means nothing, because it could not have reached any IPv6 address. Try a phone on a different operator.

This step matters. A test that cannot succeed cannot tell you that you are safe.

Step 5. Try the camera page from outside. Still on mobile data, type the same bracketed address and port from step 3.

It loads: your camera page is reachable from the internet. Fix this before you do anything else (see below).
It times out: your router is dropping unsolicited IPv6 from outside, at least from this network. That is the result you want.

Do it again after any router reset, firmware update, or change of ISP. Those are the moments when settings return to their defaults.

If the page loaded from outside

Do these in order. Stop when the outside test times out.

Find the IPv6 firewall in your router. In the router's admin page, look for words like "IPv6 firewall", "IPv6 filter", or "inbound filtering". Turn on the option that blocks incoming connections that were not requested. Then repeat step 5.
Check for an IPv6 "pinhole" or exception. Some routers let you open a specific device and port to the internet. If there is one for the camera phone, delete it.
If you cannot reach the router settings (rented flat, shop, guesthouse, ISP-locked router), ask the person who controls it to switch IPv6 inbound filtering on. If that is not possible, consider turning IPv6 off for that Wi-Fi network on the router, if it allows it. Do not do this to a router you do not control.
Keep a password on the camera page, and change any default. This is true on IPv4 too. A password is the last line, not the first.

Mobile data is a separate question

Everything above is about your Wi-Fi router. If the camera phone itself is on mobile data, the operator's network sits in front of it instead. Mobile networks can run their own IPv6 firewalls. We could not find a reliable public source showing which operators block incoming IPv6 to phones and which do not, so we will not guess. You cannot assume either way.

This is one more reason for the advice in the dual-SIM guide: if you only watch on your own Wi-Fi, the camera phone does not need mobile data at all. If you do run it on mobile data, the same test works. Get the phone's IPv6 address from its mobile network status, and try it from a second phone on another network.

What about the link-local address?

You might think: "I'll just use the fe80: address. It can't leave the Wi-Fi." That is true of the address. But two problems:

Browsers will not open it. A link-local address needs a "zone" (which network card to use) written into the URL. The standard for that, RFC 6874, was withdrawn in 2025. The replacement, RFC 9844, says browser makers found it "impracticable to support."
Using a local address yourself does not stop the server answering on the global one. The test above is the only thing that tells you that.

For everyday viewing on your own Wi-Fi, the normal 192.168.x.x address your app shows is still the simplest choice.

Why this matters more for "no cloud" setups

A cloud camera sends its video out to a company's server, and you watch from there. Nothing needs to connect in to the camera. That is part of what you are paying for.

A local-only camera, like a phone with a built-in web viewer, does the opposite. Your browser connects straight to the phone. That is what keeps the video off other people's servers, and it is the whole point. But it also means the network around the phone has to do the job of keeping strangers out. On IPv4, NAT did that job by accident. On IPv6, a firewall does it on purpose, if it is on.

We made a similar point in the Kimwolf botnet piece: a camera should never need an open inbound port to be useful. IPv6 does not change that rule. It changes who is responsible for enforcing it.

The short version

On IPv4, NAT usually keeps a phone camera page private by accident.
On IPv6, there is usually no NAT. Your router's IPv6 firewall does that job, and it is not guaranteed to be on.
Check, don't assume: find the address starting with 2 or 3, confirm the second phone loads ipv6.google.com, then try http://[address]:port/ over mobile data.
Loads from outside? Turn on the router's IPv6 inbound filter, delete any pinhole, and keep a password on the camera page.
Watching only at home? The camera phone does not need mobile data.

Background Camera RemoteStream turns an old Android phone into a camera that records with the screen off, keeps recordings on the phone, and shows a live view in any browser on your own Wi-Fi. It can also push to YouTube Live when you want to watch from outside. No account, no cloud storage, no subscription. It is free on Google Play, and there is more at superfunicular.com.

Sources

Your Camera Phone Asks for Its Address Back Every Few Hours. Here Is the Conversation.

Super Funicular — Sat, 10 Oct 2026 04:28:58 +0000

A few weeks ago I wrote a practical guide for people running an old Android phone as a camera on a router they cannot log into: Every Guide Says "Reserve the Address on Your Router." What If the Router Is Not Yours?. Its advice boiled down to: read the address off the phone, keep the phone connected, and set a manual address only last.

A reader replied that the static-IP step felt risky if you can't see the whole network, and that the lease-renewal part sounded solid. Both instincts are right, and the reason is in the protocol itself. This is the companion piece: the actual exchange between the phone and the router, read from RFC 2131, with a camera that never moves in mind.

The lease is a clock with three marks on it

When the router lends your phone an address, it lends it for a fixed duration. The phone does not wait for that duration to run out. RFC 2131 gives the client two earlier deadlines:

"T1 is the time at which the client enters the RENEWING state and attempts to contact the server that originally issued the client's network address. T2 is the time at which the client enters the REBINDING state and attempts to contact any server."

And it gives defaults for both:

"T1 defaults to (0.5 * duration_of_lease). T2 defaults to (0.875 * duration_of_lease)."

Those are defaults. The router can send its own values, and the RFC also asks for some random "fuzz" around them so that every device on the network does not renew at the same moment. But the shape is fixed: halfway through, try the router that gave you the address; most of the way through, ask anyone; at the end, let go.

Halfway: the quiet renewal

At T1 the phone sends a single, ordinary request to the router it already knows:

"At time T1 the client moves to RENEWING state and sends (via unicast) a DHCPREQUEST message to the server to extend its lease. The client sets the 'ciaddr' field in the DHCPREQUEST to its current network address."

Note what this message is not. It is not "please give me an address." It is "I am already using this one; extend it." If the router answers, the clock starts again, and nothing about the phone's address changes.

If the router does not answer, the phone does not panic. It waits "one-half of the remaining time until T2 (in RENEWING state) and one-half of the remaining lease time (in REBINDING state), down to a minimum of 60 seconds, before retransmitting." It keeps asking, politely, at shrinking intervals.

This is why "keep the phone on the network" works. A device that stays connected starts asking to extend at the halfway mark. It has the entire second half of the lease to get a single yes. A camera that never leaves the room is about the best-behaved DHCP client there is.

The end: when the address really is gone

The failure case is stated just as plainly:

"If the lease expires before the client receives a DHCPACK, the client moves to INIT state, MUST immediately stop any other network processing and requests network initialization parameters as if the client were uninitialized."

From that point the phone is a stranger again. It starts the full request over, and nothing obliges the router to hand back the old address. This is the path that breaks your bookmark, and it needs the phone to have gone the whole second half of the lease without one successful renewal. On a phone that stays connected to a working router, that should not happen.

The other path: rejoining after being away

For a camera that stays put, the riskier moment is not the halfway renewal. It is the phone dropping off — Wi-Fi toggled, a power cut, the router restarting — and then coming back. Rejoining uses a shorter exchange the RFC calls INIT-REBOOT. In it, the "requested IP address" option is a MUST: the phone names the address it had and asks to keep it.

The router has three ways to respond:

Yes. It sends an acknowledgement and the address is unchanged. This is the common case.
No. If the phone's idea of its address is wrong, "the server SHOULD send a DHCPNAK message to the client." The phone then has to start over and take whatever it is given.
Nothing. This is the interesting one. The RFC says: "If the DHCP server has no record of this client, then it MUST remain silent."

Think about what case 3 means for a router that lost its lease table when the power went out. The phone asks for its old address. The router has no record of the phone, so — by the specification — it says nothing at all.

The phone retransmits; the RFC's example is "four times, for a total delay of 60 seconds." Then, if it still hears nothing, "the client MAY choose to use the previously allocated network address and configuration parameters for the remainder of the unexpired lease."

So after a router reboot, the phone is allowed to keep its old address for a while without any router having agreed to it. Often that is harmless, and the address survives. What happens later depends on how that particular router handles the next request, and the RFC leaves room for different implementations there. This is exactly why the anchor article suggests reading the address again after the next real power cut: it is the one situation where your router's behaviour is not predictable from the specification alone.

How the router knows it is the same phone

All of this depends on the router recognising the phone. The RFC says the lease "is implicitly identified by the 'client identifier' or 'chaddr' and the network address." chaddr is the client hardware address.

Modern Android presents a randomized hardware address by default, which sounds as though it should break this. On a normal network it does not, because the default type is persistent per network. The anchor article quotes the Android Open Source Project documentation on that in detail, including the developer setting that changes it. The short version: unless that developer setting is switched on, the phone shows the router the same identity each time, and the requests above work as intended.

Why the manual address is the step to be careful with

DHCP has a conflict check built in. After being given an address, the client "SHOULD perform a check on the suggested address to ensure that the address is not already in use," for example with an ARP request. If the address is taken, "the client MUST send a DHCPDECLINE message to the server," and the server must then "mark the network address as not available."

That check, and the router's bookkeeping, belong to DHCP. When you type an address into the phone's Wi-Fi settings, you leave DHCP for that network. The router's pool does not know you have claimed that address, and DHCP's decline-and-mark step is not part of what happens. If you cannot see the router's pool, you are picking a number without any of the bookkeeping that normally keeps two devices off the same one. That is the reader's instinct, stated in protocol terms.

What to take from it

A phone that stays connected renews its address from the halfway point of the lease, by unicast, to the same router. Continuous connection is the strongest tool you have that needs nothing from the router.
The rejoin path is where the address is at risk, not the renewal path, and a router that forgot its table is required to stay silent.
A manual address gives up DHCP's own conflict handling. Use it last, and only if your two readings show the address really moves.

The practical steps, including the two-reading test, are in the original guide: Every Guide Says "Reserve the Address on Your Router." What If the Router Is Not Yours?

Background Camera RemoteStream records with the screen off, keeps footage on the device rather than in anyone's cloud, and serves a live view from a built-in web server to any browser on your own network.

Google Play: https://play.google.com/store/apps/details?id=com.superfunicular.digicam
Site: https://superfunicular.com

Sources

RFC 2131, Dynamic Host Configuration Protocol — R. Droms, March 1997. §4.4.5 (T1/T2, RENEWING, REBINDING, expiry, retransmission), §4.3.2 (INIT-REBOOT; silence when the server has no record), §3.2 (reusing a previous address; retransmission and continued use), §3.1 and §4.4.1 (address-in-use check and DHCPDECLINE), §4.3.3 (server marks a declined address not available).
MAC randomization behavior — Android Open Source Project, as quoted in the original guide.

Should You Leave the SIM Card in an Old Phone Security Camera? A Dual-SIM Guide for Offline, Wi-Fi and Mobile Data Setups

Super Funicular — Sat, 10 Oct 2026 04:23:54 +0000

Most old Android phones that become security cameras still have a SIM card inside. Often it is the old number from before the upgrade. Sometimes it is a cheap prepaid SIM that came with the phone. On a dual-SIM handset there may be two.

Nobody decides to leave them there. They are just there. And those SIM slots change how the camera behaves: whether it spends money on data, whether it comes back after a power cut, and whether your bank's one-time passwords show up on a phone sitting on a shop shelf.

This guide is for one question: which SIM, if any, should stay in the phone you use as a camera? It is written for the common case: a budget or older Android phone, a home or small shop, data that is prepaid and not unlimited, and no wish to pay a monthly fee for a camera.

Do I need a SIM card to use an old phone as a security camera?

No. A phone with no SIM at all still joins Wi-Fi normally. If the camera app records to the phone's own storage and serves its live view on your local network, the SIM does nothing for either job.

That is how Background Camera RemoteStream works. It records with the screen off to the phone's storage. A small web server on the phone itself serves the live view to any browser on the same Wi-Fi. No account, no cloud, no subscription. You only need the internet, through Wi-Fi or a SIM, if you want to push a YouTube Live stream that can be watched from outside the building.

So the real question is not "does the camera need a SIM?" It is "what does each SIM do while it sits in the camera phone?"

What a SIM can do to a camera phone (that you did not ask for)

Four things, in rough order of how often they cause trouble.

1. It can spend mobile data. If mobile data is switched on, Android can use it when the Wi-Fi is weak, has no internet, or is a shared network that needs a login. We explained why in why your phone security camera uses mobile data on shared Wi-Fi. With no SIM, or with mobile data off, that cannot happen.

2. It can lock itself after a restart. If the SIM has a SIM PIN turned on, Google's help page is direct: "You'll be asked for your SIM PIN whenever you turn on your device." After a power cut drains the battery and the phone restarts, that SIM has no mobile network until someone types the PIN by hand. If your camera depends on that SIM for internet, it stays offline until you visit it.

3. It receives calls and messages. A phone on a shelf still rings. It still lights up for SMS. And if the SIM is your main number, those messages include bank and app one-time passwords (OTPs), shown on a screen you are not holding.

4. It may be quietly deactivated. Prepaid SIMs that are never used do not last forever. In India, TRAI's 2013 rule says a prepaid connection "shall not be deactivated for any period of non-usage less than 90 days". That is a minimum, not a promise of more. Rules differ in Bangladesh, Iraq, Algeria and elsewhere, so check with your operator. A data SIM you set up once and forgot can stop working months later.

None of this is a fault in the camera app. It is the phone still being a phone.

Which SIM should stay in the phone? Four common setups

Setup 1: Home or shop with Wi-Fi, you watch on the same Wi-Fi

Take the SIM out. You lose nothing. Recording and the local live view both run without the internet. This is the true offline security camera: no SIM, no cloud, and nothing that can spend money.

If you cannot remove it (a tight tray, a glued back), turn mobile data off for that SIM instead, and turn off any option that switches to mobile data when the Wi-Fi is poor.

Setup 2: No router at all, using another phone's hotspot

The camera phone still needs no SIM for local viewing. Two phones on the same hotspot talk to each other directly; the live view is local traffic and does not need the internet, so mobile data can stay off. Either phone can make the hotspot. If the camera phone is the one making it and refuses to turn the hotspot on with no SIM inside (some phones behave this way), let the viewing phone make the hotspot instead and have the camera phone join it. The full setup, and what to check, is in how to use an old phone as a security camera without a Wi-Fi router.

Setup 3: You want to watch from outside, over mobile data

This is the one setup where a SIM in the camera phone earns its place. Keep one data SIM and set it up on purpose:

Choose it as the data SIM. Google's Pixel help says: "Only one SIM can be the default for data." On a Pixel the setting is under Settings > Network & internet > SIMs > Mobile data. Samsung, Xiaomi, Realme and others put it in different menus. Look for "SIM manager", "Dual SIM" or "Mobile data SIM".
Set a data limit. On a Pixel it is under Settings > Network & internet > SIMs > Data warning & limit. When the limit is reached, mobile data turns off and you get a notification. Google also warns that "some carriers measure usage differently," so set the limit below your real plan, not equal to it.
Turn the SIM PIN off on this SIM, or accept that every restart needs a visit. A camera that cannot come back online by itself after a power cut is a camera you will find dead.

There is one more thing to know before you pay for data. On mobile data, people outside usually cannot connect in to the phone. One reason is that an operator can put many customers behind one shared address, using its own network address translation. There is even an address range set aside for that kind of sharing (100.64.0.0/10, in RFC 6598). Whether your operator does this, and how, is up to your operator. The same RFC notes that some applications "cannot seed content due to the inability to open incoming ports". So the local web viewer that works on your Wi-Fi does not normally become reachable from across town just because there is a SIM inside.

What does work over mobile data is a connection the phone makes outward, like pushing a YouTube Live stream. That is why Setup 3 usually means YouTube Live.

And that uses real data. YouTube's own encoder guidance gives a minimum and a recommended bitrate for each quality. Converted to data per hour:

Quality (H.264)	YouTube minimum	Data per hour at minimum	YouTube recommended	Data per hour at recommended
480p, 30 fps	0.4 Mbps	about 180 MB	4 Mbps	about 1.8 GB
720p, 30 fps	3 Mbps	about 1.35 GB	8 Mbps	about 3.6 GB

A 720p stream at YouTube's minimum, left on for a full day, is about 32 GB. On most prepaid plans that is not a 24/7 setup. Stream when you need it, at a low quality, and let the phone record locally the rest of the time. The figures above are calculated from YouTube's numbers. Your own phone's data usage screen is the real measure, and we wrote about measuring it yourself rather than trusting anyone's estimate.

Setup 4: The SIM holds a number you still need for OTPs

Do not put it in the camera phone. Move it to the phone you carry. A camera phone sits in one place, often where customers or visitors can reach it. If it is picked up, your OTPs go with it.

If you truly have no choice, at least stop the lock screen from showing message text. On a Pixel: Settings > Notifications > Notifications on lock screen, then turn off Show sensitive content. Other brands have a similar "hide content" option under lock screen or notification settings. Also set the phone to silent, so it does not ring in an empty room at night.

Dual-SIM phones: what to do with the second slot

Many budget dual-SIM phones have two physical slots. The usual mistake is to fill both "because they are there". For a camera phone:

Empty is best unless you are using Setup 3.
One data SIM, chosen on purpose, if you are streaming out. Leave the second slot empty so nothing else can receive calls, messages or data.
Never your main number, for the reasons in Setup 4.

Newer phones add options such as using mobile data from both SIMs during calls, or switching data between SIMs automatically. These depend on your phone model and your operator. On a camera phone, turn off anything that lets data move to a SIM you did not choose.

A five-minute check after you set it up

Restart the phone on purpose. Does it come back to the network without you typing anything? If a SIM PIN prompt appears, you have found your power-cut problem today instead of later.
Unlock it once and open the camera app. If you use a screen lock, Android does not run most apps after a restart until the phone is unlocked once. Its developer documentation says: "By default, apps don't run during Direct Boot mode." Plan to unlock the phone after any restart, and check that recording has started again.
Open the live view from another device on the same Wi-Fi. That confirms the local path, which needs no SIM.
Check mobile data usage the next day. If the camera phone has no SIM, it should show nothing. If it has a data SIM, compare the number with what you expected from the table above.
Send the camera phone's number a test SMS (if it has a SIM) and look at the lock screen. If you can read the message without unlocking, so can anyone at the counter.

What the documentation does not tell you

Google's help pages describe each of these settings on a Pixel. They do not describe the same menus on Samsung, Xiaomi, Realme, Tecno or Infinix phones, which are most of the phones in this situation, so we have not printed paths for those brands. We have also not tried to say how long any particular operator keeps an unused SIM active outside India. And whether data from both SIMs can switch automatically depends on the phone and the operator, not only on Android. Test on your own phone before you rely on it.

If your stream drops but recording continues, that is a different problem with its own fixes, covered in live view stopped, recording did not.

The short version

Watching on the same Wi-Fi? No SIM.
Using a hotspot? No SIM in the camera phone.
Streaming out over mobile data? One data SIM, no SIM PIN, a data limit below your plan.
Your main number? Never in the camera phone.

Background Camera RemoteStream records with the screen off to the phone's own storage, serves a live view from a web server running on the phone itself, and can push to YouTube Live when you want a stream that reaches outside the building. No account, no cloud storage, no subscription. It is free on Google Play, and there is more at superfunicular.com.

Sources

This week on @Digital_Nomad_Media — 13 new clips (2026-W39)

Super Funicular — Sun, 27 Sep 2026 14:04:28 +0000

Quick weekly digest from my YouTube channel — every clip below is fresh in the last 7 days.

Oops

62s

No children taller than red line allowed! ✌️🤠

68s

Every Time I try to go fishing........

70s

Digi Snippets ✌️🤠

64s

Aww it was just an ol'aligator ✌️🤠

63s

How de do dat? ✌️🤠

67s

#DreamScreenAI

64s

My new box truck!

67s

They brought him a phone. He messed with it for an hour and then........🤣

78s

Plow a Trail

69s

How I saved a damsel in distress in Grand Rapids Part 3.5

62s

Fish Guarding their nests photography filmed underwater w/ my Insta360 Go 2 in Grand Rapids Michigan

62s

Elite K9 River Patrol

77s

I also built an app — DigiCam

I also made DigiCam, listed as Background Camera RemoteStream on Google Play. It's the world's first screen-off YouTube live streaming app: stream live with the screen off for ~10× the battery life, plus background recording, remote web console control, file-based YouTube Live, and playlists. Privacy-first, all local storage. Free with ads or Pro for the full feature set:
https://play.google.com/store/apps/details?id=com.superfunicular.digicam

Watch the full channel: @Digital_Nomad_Media

Tags: #SuperFunicular #DigiCam #DigiNomad #YouTubeShorts #ContentCreator #LadyThePitbull #travel #trixietheterrible #DreamScreenAI #travelshorts

Which Faults Actually Disqualify an Old Phone From Camera Duty? A Triage List, Including the One We Get Wrong

Super Funicular — Mon, 21 Sep 2026 12:56:09 +0000

Short answer: The fault that quietly ruins the picture is the one nobody inspects: a scratch or hairline crack on the small window over the rear lens. It is filed as cosmetic because a phone lives in a pocket, and it turns every bright object in the scene into a permanent smear of scattered light in the same place in every frame. The fault that actually retires phones is the front display, and that is the one this job cares least about — though not for the reason we used to give here: what a setup session needs is a live touch layer, not a readable screen, and we corrected that ourselves. Below is a triage table for every common fault, a five-minute inspection you can do before committing a handset, and an honest note about the line we have been repeating that skips all of this. Apps like Background Camera RemoteStream run with the display off, which is exactly why the front-glass question turns out to be the easy one.

Almost every article about reusing an old handset as a camera says some version of "any old phone will do." Almost every article about buying one says "check for damage." Neither one tells you which damage, and the two are not the same list. A fault that makes a phone useless in a pocket can be irrelevant on a bracket, and a fault that nobody would return a phone for can wreck a picture permanently.

Here is the triage I would actually run.

The fault that ends a phone's life is the one this job does not use

A phone gets retired for its display more than for anything else. It is the largest, most exposed, most expensive-to-repair part, and once it is unreadable the device is unusable as a phone. So the pile of candidate camera handsets is heavily weighted towards cracked fronts.

For this job that is close to the best possible news. A camera setup runs with the display off — that is the entire premise of leaving a phone recording for weeks — so the condition of the front glass stops mattering the moment setup is finished. What you need is:

Enough of the touch layer alive to complete setup once — which is the binding requirement, not legibility.
Nothing loose enough to fall out of the frame or short something.

That is it. Cracks, dead pixels, colour shifts, a dim backlight, burn-in from a previous life as a dashboard: none of them affect a single frame of recorded video, because none of them are in the optical path. The picture is made by a sensor behind a different piece of glass entirely.

There is one distinction inside this that matters more than the crack itself: broken glass and a dead touch layer are different faults. Spiderwebbed glass that still registers taps is fine. A panel that shows an image but ignores your finger, or a panel that is simply black, is a phone you cannot configure by hand — but it is not a dead end. A wired mouse through a USB-OTG adapter gives you a pointer: Android has supported USB host mode since 3.1, no drivers, and it works on a locked phone. We walked that through, case by case, in a separate piece on setting up a handset you cannot touch.

The piece of glass nobody inspects

Now the other side. There is a small protective window over the rear camera, and it takes exactly the same impacts as the rest of the device. When it chips, scratches or crazes, three things happen at once:

Bright objects smear. Any strong light source in the scene — a bulb, a bright doorway, headlights turning in — gets scattered by the damage instead of passing cleanly through. You get a haze, a streak or a starburst radiating from that light.
It happens in the same place every time. Unlike a smudge you can wipe, the damage is fixed relative to the sensor, so the artefact lands on the same part of the frame in every single frame, all day, for as long as the setup runs.
Contrast falls across the whole image. Scattered light does not only make a streak; it lifts the dark parts of the picture towards grey, which is precisely where the detail you wanted was hiding.

None of this shows up in the way people usually check a phone. A quick snapshot in even indoor lighting can look completely normal. It shows up when there is a strong light in view, which describes most of the situations a camera is pointed at: a door onto daylight, a window, a driveway at dusk, a room with a lamp in the corner.

And crucially, nobody who later looks at that footage says "the lens window is chipped." They say the camera is bad.

Triage table

Fault	Verdict for camera duty	Why
Cracked or shattered front glass, touch still works	Fine	Display is dark the whole time. Needs to survive one setup session.
Display black or touch layer dead	Workable	Not in the optical path. Setup runs off a wired mouse on a USB-OTG adapter, which works even on a locked phone.
Scratch, chip or crack on the rear camera window	Usually disqualifying	Permanent scattered light in a fixed place in every frame; kills contrast around any bright object.
Greasy or hazy rear window, no physical damage	Free to fix	A wipe. Do this before judging any picture, including one you are using to judge a phone you are buying.
Known water exposure in its history	Treat as unknown, not as a pass	Corrosion is slow and cannot be inspected from outside. It may run for years. It is not a device to put somewhere that matters and forget.
Battery will not hold a charge	Less decisive here than elsewhere	The device lives on a cable for this job. There is a lot written about phone batteries already and I am not going to re-run it here.
Missing SIM tray, no service, carrier-locked	Irrelevant	The network story for this setup is Wi-Fi. A handset with no service is still a computer with a camera in it.
Dead speaker or microphone	Depends entirely on whether you want sound	Silent video is a complete answer for many uses and useless for others. Decide before, not after.
Dead power button	Real nuisance	A device you cannot restart by hand is a device that needs a plan for the day it needs restarting.

The five-minute inspection

1. Wipe the rear window with a soft cloth. Do this FIRST — half of
   what looks like damage is a fingerprint from years in a pocket.
2. Hold the rear window at an angle under a bright light and rotate it.
   Scratches are almost invisible face-on and obvious at a glancing angle.
3. Open any camera app and point it at a lit bulb from a few metres away,
   with the rest of the room dim. Damage that hides in daylight is
   unmissable here: streaks and haloes radiating from the light.
4. Take one frame of the actual scene you plan to watch, and look at it
   on the largest screen you own — not on the phone. A phone display
   flatters everything.
5. Only now check the front: can you read enough of it, and does it
   respond to touch, to get through a setup once?

Step three is the whole test. If a phone passes step three, the rest of its cosmetic history is mostly irrelevant to this job.

An honest note about our own line

The line we have repeated more than any other is that the broken old phone somebody was told to recycle still films better than a cheap camera. I still think it is broadly right, and it is true of the specific break that put most of those phones out of service — the front one.

It is not true of all of them, and we have never said which. A phone with a chipped rear window will produce a worse picture than a cheap dedicated camera in exactly the situations you bought a camera for, and no software fixes it, ours included. Repeating a cheerful generalisation without the exception is how people end up disappointed by the right idea.

The exception is one sentence long and it belongs next to the claim every time it is made: check the small window, not the big one.

What this list deliberately does not settle

It does not tell you whether a given handset is fast enough, has enough storage, or will get warm where you want to put it. Those are real questions with real answers and they are not damage questions. This is only the triage for a device that has already been dropped, which is most of the devices anybody is considering for this.

It also cannot tell you about corrosion, board-level damage, or anything else that lives under the case. Nobody can, from the outside. The honest handling of that is not a confident verdict but a placement decision: a device with an unknown internal history goes somewhere you will notice it stopping, not somewhere you are relying on it silently for months.

Two questions usually come right after triage, once a handset has passed: whether to leave the SIM card in an old phone security camera, and whether a local-only camera phone is exposed to the internet on IPv6 even when you never set up remote access. Both are worth answering before the device goes on the shelf.

What to do this week

If there is a retired handset in the house you have been meaning to put to work, do step one and step three above tonight. Five minutes with a cloth and a lamp will tell you whether you have a good camera or a permanently hazy one, and it will tell you before you have chosen a spot, run a cable and started trusting the thing.

More at superfunicular.com, and the app is Background Camera RemoteStream on Google Play.

The Loopback Line: Why a Phone Serving Its Own Camera Page Gets Fewer Browser APIs Than localhost

Super Funicular — Mon, 21 Sep 2026 07:18:34 +0000

You set up an old Android phone as a camera. It records with the screen off, and it runs a small web server so you can open the picture in a browser on your laptop. You type http://192.168.1.42:8080, the feed comes up, and everything works.

Then you notice three things that don't.

The page cannot keep your laptop screen awake while you watch. It cannot register a service worker, so it re-fetches its own shell every single time. And if you try to embed that feed in any dashboard you host over HTTPS, the frame stays empty — not slow, not broken, empty.

None of these are bugs in the server. They are not bugs in the browser either. They are all the same decision, made once, in a specification that never mentions your phone, your network, or private IP addresses at all.

I went looking for the sentence that causes it. The interesting part turned out to be a sentence that isn't there.

The line itself

The W3C Secure Contexts specification defines whether an origin is "potentially trustworthy." Browsers use that one boolean to gate a large set of web APIs. The algorithm is short. In order, an origin is trustworthy if:

Its scheme is https or wss.
Its host matches the CIDR notations 127.0.0.0/8 or ::1/128.
Its host is localhost, localhost., or ends in .localhost / .localhost. — but only "If the user agent conforms to the name resolution rules in [let-localhost-be-localhost]."
Its scheme is file (a SHOULD, not a MUST).
Its scheme is one the user agent considers authenticated, such as chrome-extension:.
It "has been configured as a trustworthy origin."

Otherwise: Not Trustworthy.

Two details in that list are worth slowing down for, because most summaries get them wrong.

The loopback CIDR is unconditional. 127.0.0.1 is trustworthy, full stop. The name localhost is not — it depends on the user agent following particular name-resolution rules, and §5.2 softens it further to a MAY. People say "localhost is a secure context" as if the two were the same rule. They aren't.

And the spec is explicit that the usual levers don't apply: "Neither origin's domain nor port has any effect on whether or not it is considered to be a secure context." Moving your server from 8080 to 8443 changes nothing. It was never about the port.

The sentence that isn't there

Here is the part I actually went to check, because I expected to find a carve-out and an argument about why it was narrow.

There is no carve-out. There is no argument.

I searched the Secure Contexts document for 192.168, 10.0.0.0, RFC1918, "private IP", "private network", "intranet", and 169.254. Every one of them returns zero occurrences. The only CIDR notations in the entire specification are 127.0.0.0/8 and ::1/128.

Private network addresses are not excluded by a rule. They simply fall off the end of the algorithm into its final step, Not Trustworthy, alongside every plain-HTTP address on the public internet. The spec does not discuss them, does not note them as a known gap, and does not leave an issue open about them.

The one remaining route is §7.2, and it is a manual one:

"In order to support developers who run staging servers on non-loopback hosts, the user agent MAY allow users to configure specific sets of origins as trustworthy"

That is a per-user, per-browser, per-machine setting intended for development. It is not something a device on your network can earn, negotiate, or opt into. Every person who ever opens the page would have to set it themselves, in their own browser.

So there is a line, and it runs in a strange place. I've started calling it the loopback line: the boundary between a server talking to itself and the same server talking to the machine next to it.

A phone that serves its camera page to itself is on the trusted side. The instant that identical page — same code, same server, same process, same device — is served to a laptop one hop away, it lands on the untrusted side. Nothing about the software changed. The only thing that changed is that the bytes left the device.

Which is, of course, the entire point of a camera.

What lands on the untrusted side of the line

"Not a secure context" is abstract until you list what it costs. MDN maintains the list of features restricted to secure contexts. For a LAN camera page, these are the ones that bite:

Service workers. Gone. The Secure Contexts spec is blunt: "Only secure contexts may register them." No offline shell, no cached UI, no graceful behaviour when the phone briefly drops off Wi-Fi. Every load is a cold load.

Notifications. Gone. The viewer page cannot raise a desktop notification, which rules out a whole category of "tell me when the feed drops" built in the page itself.

crypto.subtle. Gone — and here is a precision worth keeping, because it's easy to overclaim in either direction. "Web Crypto needs HTTPS" is too broad: crypto.getRandomValues() carries no secure-context requirement and keeps working. But don't under-claim either — both crypto.subtle and crypto.randomUUID() are marked [SecureContext] in the Web Cryptography IDL, so random UUIDs go with the subtle interface, not with getRandomValues().

getUserMedia(). Gone. MDN lists it separately from the main table, under methods that "require a secure context (even if the associated API does not)." So the LAN page cannot open a camera of its own — relevant the moment you imagine two-way anything.

Screen Wake Lock. Gone. And this is the one I keep turning over.

The Screen Wake Lock API is how a web page asks the browser not to let the display sleep. It exists almost entirely for pages you watch without touching: recipes, dashboards, sheet music, live feeds. It is precisely, exactly the API a camera viewer wants.

A LAN camera page cannot have it. The page whose entire job is to stay visible is denied the one API about staying visible.

There's a symmetry here that I find funny, in a bleak way. On the recording end, the thing that makes screen-off capture work at all is an Android partial wake lock held by a foreground service — keep the CPU running, let the display die. The viewer end has its own fight over attention, which I've written about separately: what Chrome does to a camera tab you walk away from — throttled, then frozen, then discarded.

The recorder fights to keep the CPU awake while the screen sleeps. The viewer would like to keep the screen awake so the tab is never backgrounded in the first place — and is told it hasn't earned the right to ask.

Two wake locks, opposite goals, and only one of them is available to you.

Mixed content, and the trap in the middle of it

The second symptom — the empty iframe — is a different mechanism with the same root.

If you serve any page over HTTPS and it tries to pull a subresource over plain HTTP, that's mixed content. Current browser behaviour splits it into upgradable and blockable content. Scripts, fetch(), XMLHttpRequest, stylesheets, fonts, <object>, sendBeacon and <iframe> sources are all blockable — they fail, they are not retried over HTTP.

Images, audio and video are the upgradable category. The browser rewrites the request to HTTPS and tries again. Which sounds like a loophole: serve an MJPEG snapshot as an <img> and let it upgrade.

It doesn't work, and the reason is a carve-out that's easy to miss. From MDN's mixed content page:

"Mixed content requests that would otherwise be upgraded are blocked if the URL's host is an IP address rather than a domain name."

An upgrade to HTTPS only makes sense if there's a name that could plausibly have a certificate. 192.168.1.42 is an IP literal, so <img src="http://192.168.1.42/snapshot.jpg"> on an HTTPS page is blocked, not upgraded. The category that was supposed to be the lenient one is, for your camera specifically, the strict one.

One piece of vocabulary, since the old term is still repeated as though it were current. The upgradable category used to be called optionally-blockable. Both the Level 1 Candidate Recommendation and Level 2 now use the newer upgradeable wording, and note that it "was previously referred to as optionally-blockable" in earlier versions. So if you find a source leaning on "optionally-blockable" as live terminology, it predates that change — the behaviour it describes is the same, the name isn't.

And a confirmed absence, because I looked: Mixed Content Level 2 contains zero occurrences of the word "iframe." It reaches iframes through its algorithm — it permits a request whose "destination is 'document', and request's target browsing context has no parent browsing context", i.e. top-level navigations only. A framed document falls through to blocked. MDN says "iframes are blocked" in plain words; the spec never does.

What replaced the fix everyone was waiting for

For a few years the expected fix for all of this was Private Network Access — a scheme where a public page wanting to reach a private address would send a CORS preflight carrying Access-Control-Request-Private-Network: true, and the local device would answer with Access-Control-Allow-Private-Network: true.

Two corrections, because I nearly wrote this section as current behaviour and it isn't.

First, PNA is a WICG Draft Community Group Report. In its own words: "It is not a W3C Standard nor is it on the W3C Standards Track."

Second, and more importantly: Chrome does not enforce it. From Chrome's own PNA on hold post, published October 2024: "PNA preflights are not currently enforced," the Chrome 130 rollout having been halted over compatibility problems. Anything you read describing that preflight as live browser behaviour is out of date.

What replaced it is Local Network Access — "Local Network Access replaces that effort, after PNA was put on hold." That post went up in June 2025 and now carries an update saying the permission prompt is launching in Chrome 142. It is a permission prompt rather than a preflight, so no Access-Control-Request-Private-Network header is involved at all.

Now look at the shape of it, because the shape is the whole story. LNA is a permission that a page asks for in order to reach into your local network. And "the ability to request this permission is restricted to secure contexts."

So the direction of travel is: an HTTPS page, already trusted, may ask your permission to reach your camera. Your camera's own page, serving from your own network, gains nothing. It is still not a secure context, still cannot register a service worker, still cannot hold a screen wake lock.

The platform is building a door for traffic coming in from the public web. It is not building one for a device on your LAN that wants to be trusted by the machine next to it. If anything, the asymmetry is widening: the capability now flows toward origins that already have certificates.

(This is the browser's half of the story. The operating system has its own, separate story about apps reaching LAN devices — different mechanism, different gate, and not what any of the above describes.)

So why not just serve HTTPS?

Because the certificate model and a phone on your living-room Wi-Fi were designed for different worlds, and a public CA will not issue a certificate for a private IP address. I've written that argument out properly in the LAN threat model for a phone-as-camera server, including why a self-signed certificate trades one problem for a worse habit, so I won't re-run it here.

The relevant point for this article is narrower: even if you solved the transport question, you would be solving it to recover browser APIs, not to protect an already-local link. That's a strange thing to spend a user's trust on.

The design consequence

Once you accept that the viewer page lives permanently on the untrusted side of the loopback line, a lot of architectural decisions stop being decisions.

You build the console as a self-contained page with no secure-context dependencies. No service worker, so no offline shell — the page has to be small enough that a cold load is cheap. No wake lock, so if a user wants the screen to stay on while they watch, that's a setting on their own device, and the honest thing is to say so rather than to ship a button that silently fails. No notifications from the page, so status has to be visible in the page.

And the transport has to be something a plain, unprivileged browser context does natively and well: direct HTTP, an MJPEG or similar stream for live view, and ordinary byte-range requests for recorded files. That last one is less boring than it sounds — the Range header does most of the work of seeking in a recording, which is exactly the kind of capability that survives on the untrusted side because it was never gated in the first place. The embedded-server side of this, on Ktor, I've taken apart separately.

The result looks austere next to a cloud camera's web app. That austerity isn't a shortcut. It's the shape of what remains after you remove everything a non-secure context isn't allowed to touch.

This is the architecture behind Background Camera RemoteStream — an Android app that records with the screen off and serves its own feed over your LAN from a built-in web server, with no cloud account in the path. The design constraints above are not incidental to that; they're most of why the viewer looks the way it does.

The honest trade

A vendor camera with a cloud dashboard has none of these problems, and it's worth being clear about why: their dashboard is served from a domain they own, over HTTPS, with a certificate they renew. It's a secure context. It gets service workers, notifications, wake lock, the lot. That's a real advantage and there's no point pretending otherwise.

What it costs is that the picture goes to their server so that their page can be trusted by your browser. The trust is real, and it's rented.

A phone on your own network keeps the picture where it is and pays for it in browser capabilities — a page that must be simple, stateless between loads, and unable to ask your laptop for much of anything.

I don't think that's a bad trade. But I'd rather explain it as a trade than let someone discover it as a series of small unexplained failures, which is how almost everyone meets the loopback line for the first time.

Background Camera RemoteStream — record with the screen off, stream to YouTube Live, view remotely over your LAN from a built-in web server, with local-only storage.

Google Play: https://play.google.com/store/apps/details?id=com.superfunicular.digicam
Site: https://superfunicular.com

Specification text quoted above was read from the linked primary sources: W3C Secure Contexts, W3C Mixed Content Level 2, the WICG Private Network Access draft, MDN, and Chrome's developer blog. Where a document is a draft rather than a standard, I've said so inline, because the status turned out to matter more than once.

The Offence Is the Listening, Not the Recording: A Real Estate Commission's Own Answer on Cameras During a Showing

Super Funicular — Mon, 21 Sep 2026 06:56:11 +0000

Short answer: The federal wiretap chapter defines its central verb around acquiring a conversation, not around saving one. A state licensing regulator has published what that means for a house on the market: a seller may run video with the microphone off, and a seller who listens live has intercepted the conversation even where no file was produced. Switching off recording is a smaller fix than it sounds, because it is aimed at the wrong half of the device.

A spare handset running as a camera is set up for an empty house. That is the assumption underneath most advice about it: nobody is home, the interesting event is an intrusion, and the useful output is a file you look at afterwards.

Putting the house on the market inverts each of those in the same week. The house is occupied, by appointment, by people the owner has not met. The owner is the one who is out. And the interesting event is no longer an intrusion; it is two people walking from room to room talking to each other about the place, and about what they might pay for it. The camera has not changed. Everything around it has.

Two documents carry most of the weight here, and they point the same way.

The federal definition is built around acquisition, not storage

The definitions section of the federal wiretap chapter, 18 U.S.C. § 2510, says that to intercept means "the aural or other acquisition of the contents of any wire, electronic, or oral communication through the use of any electronic, mechanical, or other device."

Read the first four words before the rest of it. Aural acquisition. Hearing is a way of acquiring. There is no mention of a file, a copy, a disk, a retention period, or a duration. The verb the whole chapter is built on describes something that is finished at the moment a person understands what was said.

The word order is not an accident of drafting, and the statute's own amendment history says so. As enacted in 1968 the definition read aural acquisition and stopped there. The words or other were inserted eighteen years later, by the Electronic Communications Privacy Act of 1986, in the same amendment that added electronic to the list of communications it covers. Hearing was not one option among several that a later Congress trimmed down to. Hearing was the whole of it, and the rest was added on top. The findings published with the 1968 Act use the plainer word: intercepting devices, Congress wrote there, were being used "to overhear oral conversations made in private".

The definition of the device that does the acquiring is drawn just as wide, which you can tell from what had to be written out of it. The list of things that are excluded runs to ordinary telephone equipment used in the ordinary course of business, and then to "a hearing aid or similar device being used to correct subnormal hearing to not better than normal". Congress had to carve out a hearing aid. That is the size of the net a drafter thought they were casting, and a phone on a shelf sits well inside it.

None of that makes hearing your visitors unlawful on its own. The chapter turns on consent, and state statutes differ in how many parties have to agree; the one below describes its own Act as requiring the consent of at least one party to the conversation. The question is therefore not whether a device recorded. It is whether the person listening was a party, or had a party's agreement.

A licensing regulator answers the question directly

The North Carolina Real Estate Commission is the body that issues and removes the licences of brokers in that state, so its bulletins are written to be followed rather than debated. In a September 2023 bulletin for brokers, it walks through the federal prohibition at 18 U.S.C. § 2511 and notes, in its own words, that "This federal statute also prohibits the interception of oral communication, whether it is recorded or not." It then adds the carve-out that the rest of the piece depends on: a person is not in breach where state law permits hearing an oral communication and a party to the conversation has consented.

Then it asks the question a seller would ask, and answers it without hedging. Is it permissible for a seller to either listen to or record a conversation between a potential buyer and their agent?

"No. It is not permissible for a seller to listen in or record a conversation between a potential buyer and their agent because the seller is not a party to the conversation and they have not obtained the written consent of one of the parties."

The reasoning is the part worth carrying away, because it survives the trip to other states even though the conclusion might not. The seller is absent from the conversation. The seller is therefore not the party whose consent a one-party state would accept. And the buyer's own agent, who is a party, has not been asked. A statute that would have been satisfied by one person in the room agreeing is left with nobody who agreed.

The sentence that reaches a phone

The bulletin then does something documents of its kind mostly avoid. It names hardware:

"Although baby monitors and walkie-talkies do not record the conversation, the conversation is still being intercepted by the seller without the consent of the parties."

The bulletin has just told brokers that sellers should not use non-recording audio devices like walkie-talkies or baby monitors. A baby monitor stores nothing. A walkie-talkie stores nothing. They are named anyway, because the thing the statute describes has already happened by the time the sound reaches a speaker somewhere else.

That sentence is written about a nursery gadget from a previous decade, and it lands on a category of software feature that did not exist when the gadget did. A live view with sound, a listen button, a talk-back channel, a remote stream you can hear as well as see: whatever a given app calls it, the described behaviour is the same one. Sound leaves a room the owner is not standing in and arrives somewhere the owner is. The bulletin does not have to mention phones to have described what a phone does.

The video half is left standing

This is not an argument for taking the camera down, and the Commission's own answer to the video question is yes, with conditions: "the seller should exercise caution regarding the placement of the device to ensure a person's privacy is not violated and the audio is turned off". Its own summary of the state Electronic Surveillance Act is that the Act is addressed to oral and electronic communications rather than to video surveillance, which is why the two halves of the same handset land in different places.

The conditions are not decorative. Placement is doing real work in that sentence, and the bulletin gives the obvious example of a room a camera has no business pointing into, a bathroom. It also warns brokers that a seller who tries to gather confidential information about a buyer by listening to their conversation is exposed to criminal or civil liability, which is a different and larger hazard than a tidy question about consent.

And the Commission goes further than the conclusion this piece is heading for. Having said that video without audio is permissible, it recommends that brokers advise their sellers not to use any device as a means to attempt to gain information about potential buyers or their agents. That is a recommendation about the purpose the hardware is put to, not about which of its two inputs is switched on, and it is wider than the fix described below. It should be said plainly rather than left out: the regulator's advice goes past the line this piece stops at.

Why the obvious fix is the wrong one

Somebody who has read this far and is selling a house will reach for the same control that everyone reaches for. Turn off recording. Keep the live view so the house is still watched, and stop writing files while strangers are inside.

On the reading above, that control is pointed at the wrong half. It stops the artefact and leaves the acquisition running. The federal definition is satisfied by the aural acquisition itself, and the bulletin says out loud that a device which stores nothing is still intercepting. A setting that makes the evidence disappear and leaves the conduct in place is worse than no setting at all, because it feels like having done something.

The control that matches the documents is the microphone, and it is a different switch. Sound off, video on, and the two halves of the handset are once again in the two different places the Act puts them.

What this does not settle

One state's regulator reading one state's statute is not a national rule, and it would be dishonest to present it as one. The federal chapter is generally read as a floor that a state may build on, and states differ on how many parties to a conversation have to agree before somebody else may listen. The definition of an oral communication in the federal chapter itself turns on whether the speaker was exhibiting an expectation that the words would not be intercepted, and under circumstances that justify it, which is a question about the room rather than about the statute.

What travels is the distinction, not the verdict. Wherever you are, the question the documents ask is who was party to the conversation, and the question they do not ask is whether a file exists.

What to do with this

Read the two halves of the handset as two different legal objects, because that is what the documents do. We have made the same split from the Android side, where the camera and the microphone are separate permissions and the audio one is the stricter: why the microphone is a different permission from the camera. What is new here is the direction of travel. That piece reasons outwards from the operating system; a regulator writing about somebody's living room arrives at the same line inwards from a statute.
The consent count is a state-by-state fact, and it is the fact everything above turns on. Settle it before a showing is booked rather than during one, and settle it from a real estate commission bulletin rather than a forum, because a regulator publishes what it is prepared to act on.
Tell the listing agent, in writing, what devices are on the property and where they point. The agent has professional exposure of their own here, and a written note converts a surprise into a disclosure.
Point the lens where the people you meant to watch would actually be. The doors and the perimeter were the reason the camera went up; the room where two visitors stand talking was not.
Resist watching a showing live. The temptation is the point of the feature, and it is also the conduct the bulletin describes.

What I could not verify

Whether any enforcement has actually followed from a seller listening during a showing. I found the regulator's position; I did not find a disciplinary case turning on it, and I would rather record the gap than imply a body of precedent I did not read.
How the other states come out. I read one state's regulator and the federal definitions section, and I did not work through the rest. I am not going to point you at a survey I have not opened.
Whether a house being shown commercially weakens the expectation of privacy that the federal definition of an oral communication rests on. It is the obvious counter-argument to everything above, the text does not resolve it, and I found nothing that settled it either way.

None of this is legal advice and I am not a lawyer. It is a reading of two public documents, aimed at people whose camera happens to be a phone and who are about to let strangers walk past it.

Try it: Background Camera RemoteStream on Google Play -- record with the screen off, keep footage on the device, watch it over your own network. More of these readings live at notes on running an old phone as a camera.

Sources. the North Carolina Real Estate Commission on audio and video equipment during showings, and the definitions section of the federal wiretap chapter on Cornell LII. Quotations from the definitions section are verbatim statutory text as published, and the 1986 insertion of or other and the 1968 congressional findings are quoted from the editorial and statutory notes on that same page; quotations from the bulletin are the Commission's own words, including its answers to its own questions. Consent is the hinge, and it swings on whether anyone in that room grasped that somebody outside it was within earshot.