Explain Permission Before the Prompt
A camera prompt can surprise someone who expected only a light effect. The invitation and participation page should explain why it appears before guests make a choice.
A useful explanation is: “Camera permission lets compatible phones use the flashlight. No camera footage is recorded or uploaded. If you prefer, join with screen light.”
The permission prompt appears after the guest taps Join, not simply because the page has opened. The browser remains responsible for granting or denying access.
What Camera Access Does
Some browsers make torch control available through the camera's media track. Luma Crowd uses that capability to operate the flashlight where supported. It does not capture still images, record footage, or send the camera stream to the server as part of the light show.
Declining permission does not need to exclude someone from the experience. Screen light provides a separate visual mode. Learn more about phone flashlight shows and app-free participation.
Be Precise About Data
Core participation does not require guests to provide a name, email address, phone number, or seat-based personal profile. The service still processes connection and device-state information needed to coordinate the session.
Avoid describing any connected web service as collecting “no data.” Explain the distinction between personal contact fields and operational information such as a connected participant count or readiness state.
The organizer should review its own privacy notice, retention practices, and any external analytics or integrations before launch. This product explanation is not a blanket privacy certification or a substitute for that review.
Separate Participation From Production Filming
Camera permission on a participant's phone is not consent to venue photography or video recording. If your production records crowd footage, communicate those arrangements through the event's normal filming policies and notices.
The same distinction applies to campaign measurement. A connected phone is not proof of a unique individual, an ad impression, or an identifiable customer.
Venue Checklist
| Check | Why it matters |
|---|---|
| Secure public page | Production browser permissions require an appropriate secure context |
| Readable permission explanation | Guests can make an informed choice |
| Permission refusal rehearsal | Screen fallback is verified before the live cue |
| Mixed-device rehearsal | Actual browsers and torch support are checked |
| Disconnect and session-end check | Lights and pending commands return to a safe state |
| Event safety review | Flashing effects and participant instructions suit the audience |
Include an Easy Way to Opt Out
Audience participation should be voluntary. Guests should be able to leave, and the production plan should remain workable without every phone joining. Avoid making phone use necessary to follow emergency instructions or essential event information.
Request a demo to inspect the actual permission prompt, screen fallback, and waiting states before your team writes its guest instructions.
