Homeroom Pictures

The mechanism

A copy is where a consent model goes to die

It is not made maliciously. Somebody exports a folder so the yearbook staff can work, and from that moment the school has two consent models: the real one, in the system, and the effective one, which is whatever state the folder was in on the day it was made.

What composing actually means here

A layout in the publications editor holds a reference to an item in the image library: which student, which collection, which frame. It does not hold the image bytes. When the layout is rendered — into the digital edition, into the online reader, into the file that goes to print — each reference is resolved, and resolving it means passing the consent gate.

So the permission is checked at the point of use, every time, rather than at the point of import, once. That single difference is the reason this site exists as something other than a page about a yearbook tool.

The honest bound. This is a records mechanism, not copy protection. It does not stop a photograph being screenshotted, re-photographed, or saved by somebody who was legitimately shown it, and nothing does.

What it removes is the routine copy: the export folder, the working drive, the layout full of pasted files. That is where the leakage a school actually experiences comes from, and it is the part that can be designed away rather than policed.

Three consequences, none of them cosmetic

Each of these is a thing that stops being a job somebody has to do. They read like small conveniences and they are the difference between a permission model that holds and one that holds until the busy week.

Three specific things follow from holding a reference rather than a copy, and none of them is visible in a feature list.

A retake propagates without a second job. When a replacement portrait supersedes an earlier one on the student record, every composition holding a reference to that student’s portrait resolves to the new one. Nobody re-imports, nobody diffs a folder, and the identification card and the directory get the same replacement at the same moment.

A permission change is retroactive over everything not yet printed. Because no layout owns its own copy, there is no set of already-imported images sitting outside the gate. The set of things a permission change has to reach is exactly the set of things the gate already governs.

An audit question has an answer. “Where has this student’s photograph been used?” is answerable when uses are references into one library. In the export arrangement, the honest answer is that nobody knows, because the copies left the system the moment they were made.

The failure this replaces, described precisely

It is worth writing out, because it is so ordinary that it does not look like a failure while it is happening.

In September a school collects publication permissions. In January somebody exports the picture-day take into a folder so the yearbook staff can lay out spreads. In March a family withdraws its permission, and the system dutifully removes the student from everything the system controls. In May the book is sent to print from the layout, which was built from the January folder. In July the family opens the book.

No individual step in that sequence is careless. The export was reasonable, the withdrawal was honoured, the layout was finished on time. The failure is structural: a copy was made under one permission state and then outlived it, and nothing in the arrangement was capable of noticing.

Four things that are copies, and do not look like it

Everybody agrees a copy is the problem once it is pointed out. The difficulty is that in practice a copy is made by an ordinary, reasonable action taken for a good reason, and none of the four below announces itself.

The export folder

The obvious one, made for the best reason there is: so the staff can work.

Somebody exports the year’s take into a shared folder in January. Everything in it is frozen at January’s permission state and nothing in the folder knows that. It is the single most common origin of a photograph appearing where it should not, and it is done by a helpful person on a Tuesday.

The pasted layout

A layout that holds image bytes rather than a reference.

It looks identical on screen to one that holds references. The difference only shows the day the state changes, at which point the referencing layout re-resolves and the pasted one does not. The pasted one also does not report that it did not, which is the part that matters.

The cropped re-save

An image adjusted and saved back as a new file.

This one is subtle because it starts inside the system. A crop or a colour adjustment saved as a new asset begins life outside the permission model and looks exactly like a legitimate library item. Holding adjustments on the composition rather than as new files is what stops this happening by accident.

The proof sent for approval

A spread sent out for someone to check.

Entirely necessary, and it produces a document containing images that now exists outside the gate. There is no version of publishing where this does not happen; what there is, is a difference between a proof that is understood to be a copy with a short life and a folder nobody ever deletes.

Fair questions about this design

Is this not just linking instead of embedding?

In shape, yes, and the shape is the whole point -- but the consequence is not a technicality. A reference is re-resolved against the permission state each time it is used, which means the permission is enforced at the moment of use rather than at the moment of import. An embedded copy enforces the permission that happened to hold on the day somebody dragged the file.

What if a designer wants to crop or retouch an image?

Adjustments belong to the composition rather than replacing the library item, so the reference survives them. That matters because a cropped export saved back as a new file is exactly the copy this design exists to avoid -- it starts life outside the permission model and looks identical to a legitimate asset.

Does this stop somebody taking a screenshot?

No, and nothing does. This is a records mechanism, not a copy-protection scheme, and claiming otherwise would be the kind of promise that gets repeated back to a family later. What it removes is the routine, invisible copy -- the export folder, the shared drive, the layout with pasted images -- which is where almost all of the real leakage happens.

What happens if the library item is deleted?

The composition resolves to nothing rather than to a stale copy, and the layout shows the gap where the reference was. A gap is an honest failure state: somebody sees it and asks. A silently retained copy is a dishonest one, because nobody sees anything and the image ships.

Where the portraits themselves come from, and how one lands on the right student, is on homeroom.pics. What gets made from this library is on what gets made.