Link sharing spreads farther than named people

What it is

Handing content to someone else usually takes one of two paths: named people—only accounts on a list can open it—or a link—anyone who holds the URL can (sometimes limited to the org). Link spread does not pass through the sharer: forwards, chat history, search caches, a URL in a screenshot, all grow the audience where the sharer cannot see. The link path therefore needs a louder explanation: whoever gets this URL can enter. This is not the widening confirm dialog itself. It is the controllability gap between the two paths.

Why it happens

Named sharing locks the audience to identity: forwarding the URL to an outsider does not open it. Link sharing locks the audience to a secret: once the string is copied, access control becomes “who can get the string.” People treat a URL as a shortcut for a named invite—“I sent the link to Jia” is heard as “only Jia can open it,” while Yi succeeds from Jia’s chat history. Crawlers, unfurl previews, and meeting recordings carry the string out of the intended channel. Extra copy at link-creation time rewrites the model: this is not naming someone, this is photocopying a key. If Copy link is the default and looks as light as Invite Jia, the model never rewrites. Expiry, passwords, and org limits sleeve the key, but the sleeve has to be visible or people still plan as “only Jia.”

Studying it

On one object, ask people to “let only Jia see this.” Offer named invite and copy-link as equally visible entries. Watch which they pick, and whether they believe Yi with the URL still cannot open it.

Independent variables: whether the link path says “any holder can open,” whether it is default, whether it is visually equal to inviting Jia. Dependent variables: using a link when a named invite was required, judgment of Yi’s access, later turning the link off.

A lab that makes Yi vivid lowers the miss. Closer to the field: “drop it in the group so Jia can see it,” and whether the rest of the group is expected. Do not treat an exported file as link sharing. Measure org-restricted links and internet links separately; they differ by a rung of control.

Where it stops holding

Material that is meant to be published should use a link; the copy becomes “this will be searched and forwarded,” not a scare. When the named set is huge (the whole company), the audience is close to an org link, but still differs in whether a colleague without the URL can search it up. A passworded link moves the secret from URL to password; if the password rides with the URL, controllability did not return. A hostname that only resolves on the intranet is not named sharing; it may still open on phone data.

Applying it

• Make Invite someone and Create a link two distinct acts. Creating a link writes “anyone who gets this URL can open it,” or “anyone in the org who gets this URL” when restricted.
• Do not default share to copy-link; default to named people.
• Links can expire and can be turned off; the off entry is as findable as create.
• Verify: the job is only Jia. If someone copies a link and still asserts Yi cannot open it, the extra copy failed. Send the URL to Yi; actual access must match the copy.

Related

• Within the group: H8.08.1 Current sharing scope must sit beside the content · H8.08.2 Widening access needs an explicit confirm · H8.08.3 Permission inheritance must be understandable · H8.08.4 View, comment, and edit roles follow least privilege · H8.08.6 Revoking access cannot recall copies already taken · H8.08.7 Org defaults vs personal share need a stated winner
• Adjacent: H8.04 Copy, Share, and Export · H8.08.2 Widening access needs an explicit confirm
• Search terms: anyone with the link · named sharing · open link