Serve secure rectangles from the versioned pull buffer

[krassx]

Summary

• Route imperative secure rectangles through SecureRectRegistry with per-rect manual owner ids and push-on-write to native pull buffers.
• Android UnityWrapper.setSecureBuffer and iOS _bugsee_set_secure_buffer store the last packed mask; wrapper pull returns that buffer (or [1, 0] before any push).
• Remove legacy addSecureRectangle bridge paths and the unused BugseeWrapperProxy.

Test plan

• DOTNET_ROLL_FORWARD=LatestMajor dotnet test Tests~/WrapperPolicy/Bugsee.WrapperPolicy.Tests.csproj --filter "SecureRect" (15 passed locally)
• Full Bugsee.WrapperPolicy.Tests suite (151 passed locally)

Made with Cursor

[cursor]

Deep code review (PR #20, 30caf3d)

This correctly closes the leftover from #8: 7.x video redaction polls the wrapper pull path, and UnityWrapper.getSecureRectangles previously always returned [1, 0]. Imperative Add/Remove/RemoveAll now own per-LTRB manual: registry entries, snapshot with convert-then-outward-round, and push-on-write into the native cache.

I did not review the diff in isolation. Checked the public facade, SecureRectRegistry / SecureRectManualOwners, Android/iOS bridges, Java/ObjC wrapper caches, the deleted BugseeWrapperProxy, sample callers, and the actual native contracts:

• Android 7.3.0 AAR: BugseeWrapper.getSecureRectangles(int) packed [version, count, l,t,r,b,…]; BugseeSecureViewsManager clamps count, treats version 0 as unknown, and on count <= 0 clears wrapper rects and resets last-version to 0 (so Stop/Launch still reapplies a cached non-zero version).
• Android public Bugsee.addSecureRectangle also hardcodes display 0 — same as DefaultSecureRectDisplayId.
• iOS 7.0.0-beta5 BGSContracts.h: secureRectanglesForDisplay: is the same layout in little-endian int32_t; coordinates are points, origin top-left, exclusive r/b, outward round; iOS only polls display 0; stale version + changed rects is a documented privacy defect — Snapshot only skips the bump when the converted ints are equal.

No P0–P3 issues that I can back with a concrete failure scenario.

Checks that did not become findings

• JNI CallStatic("setSecureBuffer", display, packed): mixed int + int[] binds to params object[], so the int[] is not expanded into (I)(I)(I)… (that pitfall is CallStatic(name, packed) alone).
• iOS P/Invoke passes explicit packed.Length; native copies packedLength * sizeof(int32_t) under gLock and returns an immutable snapshot on pull (matches the SDK “engine thread must not mutate a live NSMutableData” rule).
• Last-remove publishes a version > last non-empty and ≠ 1, so native does not treat it as the initial empty [1, 0].
• RemoveAll only strips the manual: prefix, so a future HUD owner survives; that matches native (wrapper pull is merged with, not replaced by, addSecureRectangle).

Could not run dotnet test here (SDK not installed). Source tests lock the wiring; they do not execute JNI/PInvoke.

---

1. Overall risk: Low

2. Merge recommendation: Approve

3. Most important issues to fix

None required for merge.

Residual (not blocking): wrapper-policy tests are source greps; Tests~/Android still only checks that getSecureRectangles exists in the class pool, and iOS BridgeTests.mm never round-trips _bugsee_set_secure_buffer / secureRectanglesForDisplay:. A same-package Java test (setSecureBuffer → new UnityWrapper().getSecureRectangles) would catch a clone/cache miss without Unity.

4. Positive observations

• This is the right 7.x path: stop calling public addSecureRectangle / addSecureRectangle: and serve the versioned pull buffer, including deleting the dead BugseeWrapperProxy (never registered after #9).
• Scale split is correct against the SDK header (Android pixels / scale 1, iOS UIScreen.scale points) and matches SecureRectRegistry’s existing outward-round tests.
• Android clones on both put and get; iOS copies into NSData. ProGuard keep for setSecureBuffer matches the existing JNI keep list (channelLog, refineContext).

  

_{Sent by Cursor Automation: Bugsee code review}