N5.05.3shared object permissionsdesignresearch

Permissions on shared content must be clear

Aliases: object ownership · who can edit · access control in shared AR

What it is

A pins a drawing to the wall; B reaches in and drags or deletes it; A only sees their thing vanish. Space is already aligned and reference is already clear. What is missing is who is allowed to touch this object. Shared object permissions split visible, movable, deletable, and “may leave the room” into rights people in the room can read.

When permissions are unclear, people file someone else’s action as a system fault, or treat a private draft as common property.

Why it happens

Real objects carry social ownership: that is your cup, I will not just take it. Virtual objects have no weight and no grasp resistance, and the default is often “anyone present may edit,” so the social cue is hollowed out. Visible is not the same as editable: an exhibit needs to be seen and not moved; a joint build needs everyone to edit; a private object needs to be invisible to others. Fold those three into one “shared” and every reach is an undeclared overstep.

Permissions also have to be visible. A role that lives only in settings does not help at the moment of the reach. An owner mark on the object, and a refusal on an overstep, are the rules the room can actually read. A refusal must say whose it is and which right is missing, or it is filed as a miss.

Studying it

A two-person layout task: one placer, one visitor; objects pre-marked or not with an owner. Measure whether the visitor tries to move, whether the placer understands why something vanished, and time to repair after a conflict. CSCW access-control work splits “can they see who owns it” and “was the overstep blocked” as two dependent measures; do not collapse them into one satisfaction score.

Independent variables: whether permissions are visible, whether roles are asymmetric (owner / visitor), whether an overstep gets a refusal. Dependent variables: overstep attempts, mistaken deletes, the share of placers who attribute the disappearance to the system.

People who know each other in the lab restrain themselves more than strangers in the field. To test whether permissions were read, watch for a pause before the first reach, not for agreement on a post-hoc item that “permissions matter.”

Where it stops holding

A one-shot sandbox that openly says “anyone may grab” can keep permissions minimal — but that default still has to be spoken, not left undeclared. A single user has no shared object. Read-only spectating (watching someone else’s first-person feed) is about view permissions, not object permissions. Turning “who wins when two people grab the same thing” into locks and queues is control arbitration, not the permission statement of who is allowed to act.

Applying it

  • Show owner or role (mine / the room’s / read-only) on every object another person can touch, visible before the reach.
  • Do not default to “anyone present may delete.” Confirm delete or taking out of the room, and name whose it is.
  • On overstep, block and name the missing right. Do not let the hand pass through as if the point missed.
  • How to check: A places, B drags and deletes. Before acting, B should be able to say whether it is theirs. When it vanishes, A should be able to say who did it. If either sentence cannot be produced, the permission never made it into the room.

Related

  • Same groupN5.05.1 Several people need a shared coordinate reference · N5.05.2 Each has a different viewpoint, so reference must be made explicit
  • NearbyN5.10 Shared Space and Multi-user Collaboration · N3.08 World-locked, Body-locked, and Head-locked
  • Search termsshared object permissions · object ownership · access control

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/N5.05.3