The Answer Was in the First Reply

A shop, mobile traffic, and customers who screenshot the product card and send it on WhatsApp instead of ordering. The question put to a model was how to stop the screenshots.

Its first answer was correct and complete. Blocking screenshots entirely is not possible on the web. Watermark the images instead. And then the part that mattered: people screenshot for three ordinary reasons, as a wishlist, to send to whoever approves the purchase, or because checkout is longer than a screenshot, each with a fix that has nothing to do with blocking anything.

Then came a reply of mine: blurring the card at the moment of capture would be enough. From there the model worked inside that premise and produced running code. Blur on blur and on visibilitychange, a handler on the PrintScreen key, pagehide as an iOS safeguard, and the explanation that a phone briefly takes focus away from the browser to generate the screenshot preview. There was even a figure: eighty to ninety per cent of ordinary screenshots defeated.

None of it holds. A screenshot is taken by the system compositor from a frame that has already been drawn, and the page is never told. Neither blur nor visibilitychange fires. The key handler runs after the capture, not before it, because the system acts on the press. pagehide belongs to navigation. The percentage has no source. What the code does reliably is blur the product every time a notification arrives or the customer switches apps to check something.

A day went into trying it. The trap is not credulity, it is that the answer arrived as code that runs. It executes, something dims, the console stays quiet, and runs quietly stands in for works. While the thing moves, stopping feels premature.

The model did not fail. The question did. "How do I block X" already contains the claim that X can be blocked, and a model answers inside the premise it is handed. My restated wish read as a decision already taken, so the reasoning stopped and the implementation started. The first reply proves the capability was there: asked what to do about screenshots, it said the honest thing. Asked how to blur them, it complied.

Which leaves a rule that costs nothing. Before asking how, ask whether, and ask it in a form that lets the answer be no.

And underneath it, the thing the whole question was actually about, which took another conversation to surface. The screenshot is not a marketing loss. An order placed through the site prices itself, applies the options the customer picked, registers the loyalty points and reaches the kitchen as a ticket, and a notification goes out to everyone who needs it at once, the courier included, who sees the delivery the moment it exists. The same order arriving as a picture in a chat has to be read by a person, re-typed by a person and priced by a person before anyone downstream learns of it, and every one of those steps is a place to get it wrong or to lose ten minutes. What the owner wanted was not fewer screenshots. He wanted orders to come through the machine that already does the arithmetic.

One more fact settles how little an interface can do against a habit. The shop already had a save-as-image button on its receipt, built with a canvas library, and customers went on using the hardware screenshot anyway. The system shortcut is always there, always behaves the same and does not depend on the page. A button has to be noticed, understood and trusted, which is one step more than two fingers on the side of a phone.

Stated that way, blocking is obviously the wrong instrument, because a blurred card does not move anyone to the cart. It also explains why a design that forces a deliberate choice beats one that accepts free text: the cart knows what was chosen, a photograph does not.