Sharing must name what will be exposed
Aliases: share preview · exposed fields · share payload
What it is
Share moves a piece of content from this person’s context into someone else’s: the system share sheet, a link, a chat card, a mail paste. What arrives is often neither the author’s full screen nor the one picture they had in mind—it may carry comments, the author’s name, internal state, unpublished attachments. Naming what will be exposed means spreading those fields in front of the sender before they leave this device or account. This is the payload of one content operation. Who can open the link, whether the role is view or edit, and whether a revoke pulls the file off the other disk belong to sharing permissions.
Why it happens
Senders estimate “what they will see” from the screen in front of them. Share is often one icon; the payload is assembled off-screen: thumbnail, title, deep link, Open Graph card, attachments, a token. When estimate and payload diverge, comments, a draft badge, or a client’s real name travel along. A preview turns inference into a check: seeing an avatar and unread comments on the card is what makes someone pick “body only” or cancel. With no preview, people adopt a harsher strategy—don’t share, or copy into a notes app first—which is a bypass for a field list the product never laid out.
Studying it
Give an item with hidden fields (comments, internal tags, author email). Ask people to share it with a named recipient, then list what the recipient can see, and compare to the real payload.
Independent variables: whether a payload preview appears before send, whether fields can be stripped, whether channels (system sheet / in-app link / mail) carry the same payload. Dependent variables: missed sensitive fields, post-send recall or repair, copy-as-bypass counts.
Labeling the session as a privacy task makes people unusually careful. Nest share inside another job (“send these notes to whoever missed the meeting”) and see who opens the preview. Clicking Share is not success—that only shows the entry was findable.
Where it stops holding
A public marketing page is meant to be forwarded; the field list can be short, but still mark UTM or referrer identity if those ride along. On an end-to-end channel the app cannot see, the preview should say “this will send what you selected on screen; the app cannot list a server copy”—inventing a field list is worse than none. The OS renders the system share sheet; the app still controls the metadata it hands over, and an in-app confirm can list those extras. Audit logs kept for law are not the share payload; they do not belong in “what they will see.”
Applying it
- Before send, show the card or field list the other party will get: title, body range, comments, author, attachments, expiry.
- Let people strip non-essential fields (comments, internal state) before send. Default to least necessary, not “everything.”
- If channels differ, name the channel: “mail includes the attachment; the chat card does not.”
- Verify: bury a comment the sender would not want public, then ask them to “share with a colleague.” If the preview omits it and they still send, or the preview shows it and nobody changes the options, inspect whether the default is too wide. After send, capture the real payload and tick it against the preview.