DEV Community: Gabriele Pieretti

Sensitive Data in Your Logs: What Laravel 13.27's Binding Masking Fixes (and What It Doesn't)

Gabriele Pieretti — Tue, 01 Sep 2026 13:22:46 +0000

Originally published on gabrielepieretti.dev.

When a query fails, Laravel builds a QueryException whose message contains the SQL with every bound value interpolated into it. That's great while you're debugging. In production it means every failed insert copies customer data — an email, a name, maybe a national ID — into your logs, into the failed_jobs table, and into your APM traces. Laravel 13.27, released on August 26, finally ships a switch to turn that interpolation off. It's worth being precise about what it closes, and what it doesn't.

The problem: exceptions get written down

A QueryException message is designed to be read by a developer mid-debug: insert into users (email) values (?) tells you nothing about which row broke, the version with the value tells you immediately. The trouble is that the message doesn't stay on that developer's screen. It's a string attached to an exception, and exceptions get recorded everywhere:

in the log file or channel you configured in logging.php;
in the exception column of failed_jobs, because the failed-job provider casts the exception to a string and inserts it as-is;
in the spans of your APM or OpenTelemetry agent, if you run one;
in whatever error-tracking service your exception reporting ships data to.

Each of those places becomes an undeclared copy of the data you were writing to the database — with different retention, different access rules, and almost never accounted for when someone fills in a data-processing register. Across eleven years of building Laravel back-office systems, I've watched application logs get read by far more people than ever had database access. That's normal; logs exist to be read. The question is what ends up in them without anyone having decided it.

What Laravel 13.27 does

Version 13.27 introduces the per-connection option mask_bindings_in_exception_messages. The key ships in the framework's own config/database.php on all five default connections, so even an application that never published that file can enable it with a single environment variable:

DB_MASK_BINDINGS=true

With the flag on, the exception message keeps its placeholders:

SQLSTATE[23000]: Integrity constraint violation: 1062
Duplicate entry 'ada@example.com' for key 'users_email_unique'
(SQL: insert into `users` (`email`, `name`, `national_id`)
 values (?, ?, ?))

Notice the detail: the duplicate value still appears in the first line, because that part of the message comes from the database driver, not from Laravel. The flag masks the framework's interpolation — it doesn't rewrite what MySQL says. That's still a lot: the full insert with three columns of personal data is gone. But it's not a complete scrub of the message.

Why I'd turn it on almost everywhere

The cost of the flag is that when an exception fires in production you no longer see the values at a glance: you have to recover the bindings some other way — logging them separately to a channel with short retention and tight access, or reproducing the case in development. That's real friction. But the right question isn't "does this make debugging harder?", it's "who reads my logs, and how long do they stick around?". If the answer includes a third-party service, an APM, or months of retention, then binding interpolation is a category of personal-data processing you never declared to anyone — including yourself.

The threat model is bigger than one flag

This release matters to me because it touches a principle I built Miraviso around — it's my SaaS for hair salons: sensitive data has to be protected not just where you think you store it, but in every place your infrastructure re-copies it without asking. Logs, queues, traces, log backups, snapshots: every component that serializes state to help you debug is a potential shadow archive.

In Miraviso, the notes a salon keeps about its clients can contain allergies and scalp conditions, and there I took the conclusion all the way: those notes are encrypted with a key derived on the device, and the server stores envelopes it cannot open. I wrote about that design in a dedicated post. The property that's relevant here is that the envelope design makes the logging problem structurally impossible for those fields: if the plaintext never exists server-side, no exception, however verbose, can interpolate it into a message. There's no flag to remember to enable, no misconfigured APM agent that can betray you.

I'm not arguing every field deserves that treatment — the same segmentation I apply there applies here. Most data can live in plaintext on the server, and for that data Laravel 13.27's flag is the right move: cheap, immediate, reversible. A small set of fields is delicate enough that leaking them should be impossible rather than unlikely. The test for telling them apart never changes: does the server have a legitimate need to read this value? If not, make sure it can't.

What to do today

If you run a Laravel application in production that handles personal data, the list is short. Upgrade to 13.27 and set DB_MASK_BINDINGS at least in production. Then open failed_jobs and look at the exception column of your old records: the flag protects the future, it doesn't clean up the past, and those rows have whatever retention you gave them — often forever. Finally, ask which other components of your stack cast exceptions to strings and keep them around. It's a less entertaining exercise than writing nonogram solvers, but it makes your next audit a great deal shorter.

Vue's Vapor Mode Is Almost Here. Writing Browser Games With No Framework Taught Me Why It Matters

Gabriele Pieretti — Tue, 25 Aug 2026 16:28:49 +0000

Vue 3.6 entered release-candidate stage in July, and with it Vapor Mode is finally feature-complete: single-file components that compile straight to direct DOM operations, skipping the virtual DOM entirely. A stable release is expected this autumn.

I use Vue daily in client work, so I care about this for the usual reasons - smaller bundles, faster updates. But I have a second, stranger reason to care: for the past while I've been hand-writing logic games for my personal site - a nonogram, a minesweeper variant, numberlink, mastermind, a 3D Rubik's cube with a built-in solver, a speedcubing timer. Each game is one page, no framework, no heavy libraries. Just state and direct DOM manipulation. And that experience is basically a preview of what Vapor Mode does - except I've been the compiler.

What you learn when there's no virtual DOM to hide behind

Take the nonogram. The board is a grid of cells; a click toggles one cell and possibly updates a couple of row/column clue indicators. In a naive framework mental model, the "view" is a function of the whole board state, and something diffs its way to the minimal change. Writing it by hand, you can't afford that mental model. You think in deltas: this click changes this cell's class and these two clue elements, nothing else. You write exactly those three DOM operations and you're done.

The minesweeper was the same lesson at higher stakes. Mine is a no-guess variant - every generated grid is verified by a solver so you're never forced into a 50/50. When a flood-fill reveals eighty cells at once, you feel every unnecessary DOM touch. So you batch: compute the full set of cells to reveal in pure JS, then apply the class changes in one pass. State first, DOM second, and only the DOM that actually changed.

The 3D Rubik's cube pushed this furthest. Animating layer turns and running solvers (layer-by-layer, CFOP, optimal) means the interesting work is entirely in the state model - the DOM/render layer is a thin projection of it. Once you structure things that way, "rendering" stops being the hard part of the app.

What this says about Vapor Mode

Three takeaways from doing manually what Vapor now does at compile time:

First, the virtual DOM was never primarily a performance feature. It's a developer experience feature: it lets you write view = f(state) and not think about deltas. The diffing is the price you pay for that mental model, not a speed trick. Vapor's bet is that a compiler can keep the declarative authoring model and emit the delta-based code I was writing by hand - the best of both.

Second, the discipline that no-framework code forces on you - keep state pure, treat the DOM as a projection - is exactly the discipline that makes components fast in any framework. If your component's state is tangled with its DOM, no rendering strategy saves you.

Third, there's a real ceiling on how much this matters. My games are the favorable case for direct DOM updates: high-frequency, localized mutations on large grids. A typical CRUD form re-renders so rarely that VDOM overhead is noise. If your Vue app is mostly forms and tables, Vapor will shrink your bundle more than it speeds up your interactions - still worth it, but know which benefit you're buying.

Would I still hand-write the games after Vapor lands?

Yes - but for a different reason than performance. Keeping each game dependency-free means the pages will still work untouched in ten years, and writing the update logic myself is half the fun. But for product work, Vapor is the right direction: it takes the rendering strategy that low-level code teaches you and makes it the default output of the declarative code you'd write anyway.

One caveat: 3.6 is still RC as I write this. Feature-complete is not stable - I'm not shipping it to client projects until the stable release, expected this autumn.

The games are all playable at gabrielepieretti.dev if you want to see the hand-rolled version of "vapor mode" in action.

The GPU that says yes and does nothing: debugging real-time hair segmentation on mid-range Android

Gabriele Pieretti — Mon, 17 Aug 2026 13:14:55 +0000

We build a virtual mirror for hair salons: a tablet
camera feed where the customer's hair changes colour in real time while they move their head.
Two constraints shaped every decision.

The first is privacy: no frame ever leaves the device. Everything runs locally — the model,
the fonts, the runtime — with no CDN dependency, because a CDN request would both break
offline use and leak the salon's IP to a third party.

The second is hardware: salons don't buy flagship tablets. We had to work on whatever
mid-range Android is on the counter.

This is what we learned making it fast enough. All numbers were measured on real devices with
diagnostics built into the engine — none of them are estimates.

The bug that looked like slowness

Our starting point was bad in a confusing way. A Pixel 8 Pro ran at 9 fps — poor, but working.
A Samsung A56 (Exynos 1580, Mali GPU) showed no colour at all.

The cause took a while to find, and it's the most useful thing in this article:

MediaPipe's ImageSegmenter with the GPU delegate was created without throwing, ran in 5 ms,
and returned zero hair pixels. Both the confidence mask and the category mask came back
empty. Every time.

Our fallback to CPU only triggered on exceptions. There were no exceptions. So it never
triggered, and the app simply looked slow instead of broken.

A clean comparison, same scene minutes apart:

Delegate	Mask coverage	Time per frame
CPU	1.5–2.1 %	483 ms
GPU	0.0 %	5 ms

Note the trap in that table. The GPU path is 96× faster precisely because it isn't doing
anything. If you benchmark by timing alone, the broken path wins.

The lesson: don't assume that a delegate which constructs successfully actually works.
Check the output, not the exit code. We now measure mask coverage and surface it in the
diagnostics.

Detecting it at runtime

The fix is a fallback that rebuilds the engine on CPU. The rule matters more than it looks:

After five consecutive empty masks, having never seen a good one in the whole session,
rebuild on CPU.

The condition is "never seen a mask", not "empty right now". An empty mask right now is
completely normal — it happens whenever nobody is in front of the lens. We had to encode the
difference between broken and nobody's there.

On the A56 this took us from 2 fps to 14 fps with colour applied.

The field confirmed it, months later

We shipped that fallback on the strength of a coverage number, which is a slightly
uncomfortable place to be: we knew that the delegate returned nothing, not why. The answer
arrived from a beta tester, as a photo of their phone screen. MediaPipe was failing a
RET_CHECK on every single segmentForVideo call:

Confidence mask count mismatch, 0 vs 2

The GPU graph was asking for two masks and receiving zero — at runtime, on every frame,
while construction succeeded cleanly. That is exactly why an exception-based fallback can
never catch it, and it's why a plain "Retry" button wouldn't have helped either: retrying
rebuilds the same broken graph.

Two cheap safety nets came out of that, both costing nothing per frame. If nothing has been
drawn two seconds after start, fall back from requestVideoFrameCallback to
requestAnimationFrame — on some WebViews the former exists but never fires. And do a
one-pixel readPixels, once, to find out whether the canvas is coming out black. We
had shipped a version where the error line was written into an element that
display: none had already hidden, so a broken device showed a black mirror and said nothing
at all. Errors you can't see are errors you can't fix.

A diagnostic that costs more than what it measures

While chasing this, we left outputCategoryMask enabled from an earlier experiment. The
diagnostic itself became a significant part of the frame budget. Worth remembering when your
measurements start shaping the thing you're measuring.

It was never the model

With the GPU path honest, we profiled the Pixel 8 Pro's 9 fps. The model inference cost 6 ms.
The other 126 ms were ours:

66 ms in a JavaScript loop recolouring pixels one at a time
two GPU→CPU readbacks per frame, one of them costing 123 ms

That's the whole story of most "the ML model is too slow" complaints we've had since: the
model was never the problem. The problem was everything we did around it.

Fix 1 — recolour in a fragment shader (66 ms → 0)

The per-pixel JavaScript loop moved into a fragment shader. This is the obvious one, and it's
free: the pixels are already on the GPU.

Fix 2 — decouple the mask from the draw

Hair does not move at 60 Hz. We were segmenting every frame for no reason.

segmentForVideo is synchronous, and on an Exynos it costs 437 ms of blocked main thread.
Now we segment one frame in every PASSO_SEG, and draw the video on all of them using the
most recent mask. The step adapts to the device.

This is the change that fixed the A56, and it's worth stressing: we expected to need a Web
Worker and we didn't. Decoupling cadence was enough.

Fix 3 — share the WebGL context with MediaPipe (123 ms → 0)

This was the big one. We were copying the mask out of MediaPipe and back into our own
pipeline, round-tripping through the CPU.

MediaPipe accepts a canvas in its options. Pass it the same canvas you're drawing on, and
you can take the mask with getAsWebGLTexture() — it never leaves the GPU.

One catch, learned the hard way: MediaPipe recycles that texture under your feet. Binding
it directly made the colour flicker. We copy it into our own texture with a shader, which is
still enormously cheaper than a CPU round trip.

Fix 4 — drop `preserveDrawingBuffer` (5 ms per frame)

preserveDrawingBuffer: true costs real time on every single frame. We only needed it to
capture a still of the current look, which is a rare user action.

We defer the capture to the next draw call, within the same task, and read it there. Verified
on device.

Two more things worth knowing

MediaPipe will not start inside a type: "module" worker. It dies with
ModuleFactory not set, because its WASM loader registers the factory via importScripts(),
which doesn't exist in module workers. If you want MediaPipe in a worker, you need a classic
worker — or you don't get one.

Freeze the frame in a texture before you segment. If you segment first and draw after,
the video has already advanced, and the hair lags behind the head permanently. Not
occasionally. Always.

Pick the specialised model. We were running selfie_multiclass, which segments six classes
when we needed one. Switching to the dedicated hair_segmenter: 780 KB instead of 16 MB, and
the official Pixel 6 figures are 58 ms vs 217 ms on CPU, 52 ms vs 71 ms on GPU. Our consumer
APK dropped from 40.7 MB to 25.8 MB.

Where we landed

132 ms → 17 ms per frame. 9 fps → 15 fps on the Pixel 8 Pro, and 2 → 14 on the A56.

You'll notice 17 ms per frame should mean roughly 58 fps, and we get 15. That's honest and
worth explaining: the remaining ceiling is no longer in our code. It's in how the WebView is
composited inside Flutter, and we haven't opened that front yet.

We also kept the old CPU 2D path as a fallback for devices without WebGL2. That's not
nostalgia — a canvas has exactly one context. If you request WebGL and it fails, you can't
fall back to 2D on the same canvas. You have to decide before you commit.

The takeaway

Four of the five wins here came from removing work we had added ourselves, not from making the
model faster. And the single largest discovery — the silently empty GPU delegate — wasn't a
performance problem at all. It was a correctness bug wearing a performance costume, and it was
invisible until we measured the output instead of the duration.

If you're building anything similar: instrument mask coverage, not just milliseconds. The
frame that takes 5 ms might be the one doing nothing.

The engine described here ships in Miraviso, a consultation tool for hair salons: the customer sees the colour and the haircut before the stylist starts.

If you'd rather look at it than read about it, the same engine is in a free consumer app — Miraviso Colore on Google Play. No account, no sign-up, and the camera pipeline runs entirely on the device, which you can check by putting the phone in airplane mode: the mirror keeps working. Tap the "Miraviso" header inside the colour screen and the status line turns into the live diagnostics described above — frame budget broken down by stage, the delegate in use, and the mask coverage number that this whole article is about. Each tap cycles: off → automatic → force GPU → force CPU. If you want to see the empty-mask failure for yourself, force GPU on a mid-range device and watch conf sit at 0.0 %.

Happy to answer questions about the WebGL side in the comments.