View, comment, and edit roles follow least privilege

What it is

Sharing is not only open versus closed. On one object, needed capability usually comes in rungs: view, comment, edit, sometimes share and manage. Least privilege means the default and the invite grant the lowest rung that finishes the other person’s job, not edit because “they’re a colleague.” The rungs must be distinct on the invite surface, described in task language. This is not where access is inherited from, and not how far a link travels.

Why it happens

Opening an object needs far less than changing it. A product with only “has access / not” can only send the top rung; commenters become co-authors, and mis-edits, deletes, and re-shares follow. Internal names (read-write, ACL, contributor) do not map to the job (check a number, ask in the margin, co-draft). The default rung is what most invites actually send: default edit, and least privilege never occurs. Raising a rung is easier to accept than lowering one; once edit is granted, taking it back reads as distrust, so the first grant is the long-term grant. If view cannot block download, nominal read-only becomes an editable copy outside the product—that belongs to revoke-cannot-recall, but it also undermines the view rung, so the invite has to say so.

Studying it

Three jobs: ask a colleague to check, to annotate, to co-edit. Watch which role is chosen, and which role is default.

Independent variables: whether roles split into view / comment / edit, the default rung, whether each rung is described in permission words or task words. Dependent variables: grants above what the job needs, edit accidents after over-grant, whether inviters can restate the difference.

A lab table of three rungs overestimates comprehension. Use the product’s own dropdown copy. Do not fold “will they pick link sharing” into role grading. In live logs, the rate at which the default is changed is the real policy: almost never changed means the default is the policy.

Where it stops holding

A two-person draft needs edit as the necessary rung; least privilege is not always read-only. A legally required “view without download” is a constraint inside view, not a fourth opaque role name unless that rung has a stable job (external review). More than four rungs turn the invite into a matrix and people pick at random. Org roles (department admin) and content roles are not one set; mixing them in a dropdown grants “can manage the folder” to someone who only came to read.

Applying it

• Offers view, comment, and edit on invite; default view or comment; edit is an active pick.
• Describe each rung with one thing the other person will be able to do: “can open, cannot change,” “can annotate, cannot change the body,” “can change the body.”
• If they must re-share, use a separate Can share switch; do not bundle re-share into edit.
• Verify: run the three jobs as three invites and compare chosen rung to the job. If default is edit and nobody changes it, grading never happened. Ask afterward what comment versus edit allows; a blank answer is a copy failure.

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.5 Link sharing spreads farther than named people · H8.08.6 Revoking access cannot recall copies already taken · H8.08.7 Org defaults vs personal share need a stated winner
• Adjacent: H8.09 Edit Mode vs View Mode · V3.07 Permissions and Sharing Scope
• Search terms: least privilege · viewer commenter editor · role grant