1. Purpose and Scope
This Notice explains how Velvet Room location, Radar, proximity, and related discovery features are intended to work and the privacy and safety rules that govern them. It supplements the Privacy Policy and Community Guidelines.
Location and proximity data can create physical-safety risk. Velvet Room therefore treats location as purpose-limited sensitive information and does not treat device permission as permission for unlimited use or disclosure.
2. Adult-Only Service
Velvet Room is an 18+ platform. Location, Radar, proximity, and private location-sharing features are available only within that adult eligibility boundary.
3. Radar Location Authority - Current Source-Backed Design
The current Radar implementation includes an authenticated location-update route and an authenticated nearby-discovery route. Radar presence records are geospatially indexed, are associated with an account and mode/persona, and include an expiresAt field enforced by a TTL index.
Nearby discovery computes distance from presence data and returns distance measurements within a configured radius. A profile also carries Radar-enabled/radius configuration. Before publication, the exact default-on/default-off behavior must be verified against the founder privacy rule that location use is intentional and user-controlled.
4. Permission and User Choice
- Velvet Room should request device/browser geolocation only when a user intentionally uses a location-enabled feature or an already-authorized feature needs a fresh location.
- A profile-level Radar eligibility setting and a device-level geolocation permission are separate controls. Both must be documented accurately.
- Disabling a device permission prevents future device-location access by the application, subject to ordinary device/browser behavior.
- Disabling Radar or other location visibility should stop new visibility as implemented; previously created records may remain briefly until expiry, deletion, security retention, or another lawful retention basis applies.
5. What Radar May Process
- Precise latitude/longitude supplied by the device for the purpose of creating or refreshing a Radar presence.
- Persona/mode context associated with the presence record.
- Presence timestamps and expiry state.
- Configured discovery radius and computed proximity/distance.
- Operational/security events reasonably necessary to deliver, protect, and troubleshoot the feature.
6. What Other Users Should See
Radar should reveal only the discovery information authorized for the exact persona and feature. Internal root-account identity must not become a public sibling-persona enumeration key.
- Ordinary Radar discovery should not expose another user's raw precise coordinates.
- Distance/proximity information should be presented at the level necessary for the feature rather than as an unauthorized exact-location disclosure.
- Discovering one Social/Friends/Work persona through Radar does not authorize discovery of sibling personas.
7. Separate Explicit Location Sharing
Velvet Room/Velvet Wayz may contain separate one-way or explicit location-sharing capabilities. Those permissions are not the same thing as Radar proximity discovery. A specific location-share grant must authorize only the person, direction, purpose, and time/state actually granted.
A Radar presence must never be treated as blanket permission for another user to track, follow, confront, or monitor the person.
8. Safety Rules
- Do not use Radar or proximity to stalk, ambush, repeatedly approach, pressure, threaten, or monitor another person against their wishes.
- Do not infer, publish, redistribute, or sell another person's precise/live location without an authorized feature and lawful basis.
- Do not manipulate location, presence, radius, device state, or access controls to create a false safety/discovery state.
- Do not combine Radar data with outside data to expose a hidden sibling persona or private address.
- Location features are not emergency services and are not guaranteed to be continuous, exact, fresh, or suitable for emergency response.
9. Retention and Expiry
Current RadarPresence records include an explicit expiresAt field and a TTL index, supporting automatic expiry of stale presence. The public notice should not publish an exact retention interval until the live route's expiry duration and operational behavior are re-verified immediately before publication.
Security, abuse, moderation, dispute, or legal records related to location may follow different retention rules. Those periods remain subject to the final data-retention matrix.
10. Accuracy and Technical Limits
GPS and network-derived location can be delayed, imprecise, stale, unavailable, or affected by device, environmental, network, operating-system, browser, or third-party conditions. Velvet Room does not guarantee that a displayed distance or presence reflects a person's exact real-time position.
11. Enforcement and Emergency Limits
Credible stalking, unauthorized tracking, location exposure, coercion, or abuse may lead to rapid restriction of Radar/location functionality or broader account action under the Safety, Enforcement & Appeals Policy.
Velvet Room is not a 911/emergency-dispatch service and does not promise continuous human monitoring of location activity.
12. Publication Requirements
- Verify explicit user-consent flow and current default Radar configuration.
- Verify current Radar presence expiry interval and stale-presence cleanup.
- Verify the exact fields returned to nearby viewers and remove any raw coordinate exposure not required by the product.
- Ensure persona privacy is enforced at the backend, not only hidden in the UI.
- Wire a canonical public /location or /radar-location-notice route before launch.
13. Operator and Contact
Operator: GGIRL Technologies LLC, New Hampshire, United States.
Privacy contact: [PRIVACY CONTACT] | Safety contact: [SAFETY CONTACT / SUPPORT PATH] | Legal notice address: [LEGAL NOTICE ADDRESS]