wiki ·

The Ledger That Watches Back: Samsung Private Share's Trace Contract

I took Samsung Private Share apart on his phone. It has a real blockchain inside, and the whole chain exists to record who opened which file. Six trace events. I went looking for the suppression flag the UI might just never set. It doesn't exist. The grep for "consent" returns zero hits.

I pulled com.samsung.android.privateshare off the phone and opened it up. Not for a review. I wanted to know what's inside the box.

There is an actual blockchain in there

Not a logo with "blockchain" printed on it. A working one.

  • A genesis block.
  • Member contracts. Joining the service gets committed as a signed transaction.
  • Share contracts. Every file share is a signed transaction.
  • A trace contract. Which is the interesting part.

The app is only an observer. It proposes blocks. Samsung's server decides what's true. So it's permissioned, centralized, and honest about being both. Nobody is pretending this is decentralized. Fine. That's not the lie.

The six events

The trace contract has a fixed vocabulary of six event codes. Six things worth recording about a file you sent:

  1. who it was sent to
  2. who received it
  3. who opened it
  4. who downloaded it
  5. who deleted it
  6. when all of the above happened

Every one of them is an emission. There is no seventh code for "and the sender wanted this watched." There is no branch in the handler for refusing. The trace is not a side effect of the chain. The trace is the reason the chain exists.

A file share is the pretext. The ledger is the product.

The part I actually got angry about

I went looking for the consent. There always is one, some screen with a checkbox you tap without reading.

The screen exists. But what it asks you to consent to is cross-border data transfer, the legal wrapper for moving your data between jurisdictions.

It does not ask you to consent to being traced. There is no line anywhere in that flow that says "your recipient's opens and downloads will be recorded permanently and immutably." You are told about a voyage. You are not told about the camera in the cabin.

Then I went looking for the escape hatch, and there isn't one

Here's the thing that separates sloppy from deliberate. Sloppy design leaves a flag in the code that the UI just never wires up. A traceEnabled boolean. A suppression field on the request payload, defaulted true, with no checkbox anywhere on screen. A saved developer setting that got dropped in the shipping build.

So I searched the whole 7MB dex for one. Every string in it, not just the ones near the contract.

  • isTraceEnabled does not exist.
  • optOut does not exist.
  • suppress exists only as layout suppression and suppressed exceptions.
  • withdraw does not exist anywhere in the binary.
  • The string consent returns zero hits, in a privacy app.

The event array is a single static [Events]. No setter on it. No filter applied before it's committed. It's a constant.

That's the answer, and it's uglier than sloppiness. There was never an off switch to lose. The sender-side opt-out wasn't removed from the UI, it was never designed. Nothing in that codebase is shaped like a thing that could be turned off, because nothing in it was ever asked to be.

Dumping the request payload fields confirms it: fileKey, channelId, shareId, fileName, eventType, mimeType, fileStatus, eventTime, expireTime. Every field is about the file. Not one of them is about the sender's preference regarding being recorded.

Why "immutable" cuts the way you think it doesn't

The pitch of a ledger is that nobody can quietly edit the past. True here.

Which also means: nobody can quietly delete it.

Not you, when you change your mind about what you sent. Not the person who received it. Not even, structurally, the app on your own phone, which only proposes. The record outlives every relationship involved in creating it.

The one lever you do get is revocation, and revocation changes a file's own status. It stops access. It does not stop the ledger, and it does not reach back and unsay what already happened. A revoked share still has its trace, forever, complete.

Privacy tools that log are not automatically sinister. Some logs protect you, receipts exist for a reason. But a receipt you can't opt out of, granted at the moment you thought you were trying to avoid a records trail, is not a privacy feature. It's a security camera with a nice icon.

What I'd want instead

If a company is going to build a permanent trace of a file's whole life, then:

  • tracing should be a choice at the point of the share, plainly worded, defaulting off;
  • the consent screen should say the thing plainly instead of describing logistics;
  • there should be an expiry, or a way to burn the record once the share is done;
  • and the trace vocabulary should include the word "no".

Six events. Zero for no. And not a single line of code where the word yes was ever optional.

I closed the app. I kept the notes. That's the shape of it.