# Política de privacidad — NEXRIDEBAY > **BORRADOR. No ha pasado por revisión legal humana.** > Lo escribió el equipo técnico leyendo el código, no un abogado. Describe con precisión > lo que el sistema hace hoy. No sustituye la revisión de un abogado antes de publicarlo > en una tienda de aplicaciones ni antes de enseñárselo a un pasajero. Última revisión del código: 28 de agosto de 2026. Versión del documento: v1 (borrador). --- ## 1. Quién es quién NEXRIDEBAY es la plataforma. El transporte no lo presta NEXRIDEBAY: lo presta un negocio de transporte suscrito, con sus propios vehículos y sus propios conductores. En el código eso no es una frase de marketing, es la estructura de los datos. Cada registro —cada reserva, cada conductor, cada pasajero— lleva escrito el identificador del negocio dueño (`business_id`), y toda consulta se filtra por ese dueño. El filtro exige el dueño de forma obligatoria: si una consulta lo omite, devuelve vacío en vez de devolverlo todo. Un negocio no puede ver los viajes de otro. - **El negocio que reservas** es el responsable del viaje y de los datos de ese viaje. - **NEXRIDEBAY** opera la infraestructura donde esos datos viven. Si reservaste con un negocio concreto, ese negocio y el conductor que te asignó ven tus datos de ese viaje. Ningún otro negocio de la plataforma los ve. --- ## 2. Qué datos se recogen, y por qué ### 2.1 Correo electrónico **Se recoge siempre.** Es tu identidad en el sistema: no hay contraseña. Cuando escribes tu correo, se envía un código de seis dígitos; al escribirlo correctamente queda probado que la dirección es tuya, y ahí queda creada tu cuenta. Del código de acceso se guarda un **hash con sal** (scrypt), nunca el código en claro. Caduca a los **10 minutos**, admite un máximo de **5 intentos**, y es de un solo uso. Cuando lo verificas o caduca, deja de existir. Tu correo también es la llave para encontrar tus viajes: la lista "mis viajes" es literalmente la búsqueda de las reservas cuyo pasajero tiene ese correo. ### 2.2 Nombre **Se recoge siempre.** Es obligatorio al crear una reserva (mínimo 2 caracteres, máximo 80). El conductor tiene que saber a quién recoge. ### 2.3 Teléfono **Opcional al reservar.** La regla del sistema es que exista *al menos una* vía de aviso: correo o teléfono. Con el correo verificado ya basta para crear la reserva. El teléfono se guarda si lo das (máximo 32 caracteres) y sirve para el día del viaje, cuando nadie lee correo esperando de pie en una acera. ### 2.4 Idioma Español o inglés. Se guarda en tu perfil y decide en qué idioma te llegan los correos. ### 2.5 Direcciones de origen y destino, y coordenadas **Se recogen siempre.** Sin ellas no hay viaje. De cada extremo del trayecto se guarda: | Campo | Qué es | |---|---| | `formatted_address` | La dirección tal como quedó escrita (máx. 200 caracteres) | | `latitude` / `longitude` | Las coordenadas del punto | | `zone` | La zona del corredor de servicio a la que pertenece | | `precision` | Si el punto viene del GPS, de la zona, o de un pin que confirmaste en el mapa | | `unit` | Apartamento o número de unidad, si lo escribes (máx. 40) | | `access` | Cómo entrar: portón, entrada lateral, etc. (máx. 200) | | `note` | Nota libre sobre el punto (máx. 200) | Si no das coordenadas, el sistema no las inventa a partir de tu unidad ni de tu nota: usa el ancla de la zona y lo marca como precisión `ZONE`. **Ubicación del dispositivo del pasajero:** las aplicaciones y la web solo leen tu posición cuando **pulsas el botón "usar mi ubicación"**, y únicamente para rellenar la dirección de recogida. No hay lectura continua, no hay lectura en segundo plano, y no se guarda una traza de por dónde andas. Lo que se guarda de esa lectura es lo que acaba en la dirección de recogida de la reserva. Para convertir texto en coordenadas y coordenadas en texto se consultan proveedores de geocodificación externos (Photon, Nominatim/OpenStreetMap, LocationIQ según configuración). A ellos les llega el texto de la dirección o el par de coordenadas que estás resolviendo. No les llega tu correo, tu nombre ni tu reserva. ### 2.6 Detalles del viaje Número de pasajeros, número de maletas, fecha y hora, tu zona horaria, notas para el conductor (máx. 400 caracteres), y el precio cotizado con su moneda, distancia y duración estimada. ### 2.7 Ubicación del conductor Esto es del conductor, no tuyo, pero afecta a lo que ves y conviene decirlo aquí. La aplicación del conductor envía su posición **solo con la aplicación abierta y en primer plano**. Hoy no hay envío en segundo plano ni con la app cerrada. El envío al servidor está limitado a **uno cada 15 segundos como máximo**. El GPS se lee con dos cadencias según lo que el conductor esté haciendo: - **Navegando hacia ti:** precisión alta, cada 4 segundos o cada 15 metros de movimiento. - **Disponible, sin navegar:** precisión equilibrada, cada 8 segundos o cada 40 metros. De cada lectura se guarda la posición cruda tal como la reportó el teléfono: latitud, longitud, precisión, rumbo, velocidad y la hora de la observación. **Tú solo ves esa posición cuando se cumplen dos condiciones a la vez:** que el viaje esté operativamente activo (el conductor va en camino o ya te recogió) y que el compartir esté encendido. Al cancelar el viaje, y en las transiciones de estado, el compartir se apaga y la última posición guardada en la reserva se borra. ### 2.8 Mensajes de chat El chat vive dentro de la reserva. De cada mensaje se guarda: un identificador, el identificador de la reserva, quién lo escribió (pasajero o conductor), el texto y la hora. - Máximo **600 caracteres** por mensaje. Uno más largo se rechaza; no se corta en silencio. - Máximo **10 mensajes por minuto** por cada lado. - Se conservan los **últimos 200 mensajes** de la reserva. Los anteriores se descartan. - **No hay mitad privada:** pasajero y conductor leen exactamente los mismos mensajes. - El chat se cierra cuando el viaje llega a un estado terminal (completado o cancelado), y **desaparece con la reserva**. ### 2.9 Evidencia de pago (recibos) Si el pago se hace por Zelle, puedes adjuntar una captura del comprobante. - Solo imágenes: JPEG, PNG, GIF, WebP o HEIC. El tipo se determina leyendo los **bytes reales del archivo**, no lo que diga la cabecera. Un PDF o un script disfrazado de PNG se rechaza. - Entre 64 bytes y **5 MB**. Máximo **5 evidencias** por reserva. - La imagen **sube directamente a un almacén privado** (Vercel Blob) con una autorización válida para un solo objeto y unos minutos (10 por defecto). Los bytes no pasan por el servidor de la aplicación. - **Dentro de la reserva no se guarda la imagen**, solo una referencia: identificador opaco, tipo de contenido, tamaño y un resumen criptográfico. Así una captura de tu banco no acaba en cada lectura, cada copia de seguridad ni cada volcado de depuración. - El almacén es privado. No hay URL adivinable. Sabemos lo que suele haber en esa captura: tu nombre completo, un saldo y parte de un número de cuenta. Son datos de un tercero (tu banco) que NEXRIDEBAY no pidió y no necesita. Por eso están donde están y no en el documento de la reserva. ### 2.10 Atribución y marketing Al llegar desde un enlace o un QR se guardan los parámetros de campaña (`utm_source`, `utm_medium`, `utm_campaign`, `utm_content`, `utm_term`, variante de aterrizaje, referente) y, si venías del enlace de un conductor, su identificador público. Sirve para saber qué canal trae viajes. Si marcas la casilla de promociones, se guarda un **registro de consentimiento**: si lo diste, cuándo, en qué idioma, la versión del texto que leíste, el propio texto, y en qué punto del recorrido estabas. Cinco datos, porque un permiso que no se puede probar no sirve de nada. La casilla viene **desmarcada**, y el botón no se activa sin correo válido *y* casilla marcada. Cualquier valor que no sea un sí explícito cuenta como no. ### 2.11 Token del dispositivo (notificaciones push) **Hoy solo la aplicación del conductor registra tokens push.** El token es de Expo Push Service, se guarda asociado al identificador del conductor y al dispositivo físico, y se revoca al cerrar sesión. Si el proveedor responde que el token ya no sirve (`DeviceNotRegistered` y similares), se desactiva. Una notificación push lleva lo mínimo: identificadores y los pocos datos que el conductor necesita para decidir si abre la app. **Nunca lleva coordenadas exactas, ni bytes de recibo, ni ningún dato bancario** — cae en una pantalla de bloqueo que puede leer cualquiera que esté al lado. ### 2.12 Sesión Al verificar el código se crea una sesión. En el teléfono se guarda en el llavero del sistema (Keychain / Keystore), protegido por el desbloqueo del dispositivo. Cada reserva tiene además su propia llave de acceso (`access_token`, 32 bytes aleatorios) que es lo que permite abrir el enlace privado del viaje. --- ## 3. Con quién se comparten | Con quién | Qué recibe | Por qué | |---|---|---| | **El negocio que presta tu viaje** | Todo lo de tus reservas con ese negocio | Es quien te transporta | | **El conductor asignado** | Tu nombre, tu contacto, origen y destino, notas de acceso, el chat | Tiene que recogerte | | **Otros negocios de la plataforma** | Nada | El aislamiento por dueño lo impide | | **Resend** (correo) | Tu dirección de correo y el contenido del mensaje | Entregar el correo | | **Expo Push Service** | Token de dispositivo y el aviso (hoy solo conductores) | Entregar la notificación | | **Upstash Redis / Vercel KV** | Todos los datos, cifrados en tránsito | Es la base de datos | | **Vercel Blob** | Las imágenes de comprobante | Almacén privado de evidencia | | **Photon / Nominatim / LocationIQ** | El texto de dirección o las coordenadas a resolver | Convertir direcciones en puntos | | **Stripe** | Datos del negocio suscriptor, no del pasajero | Cobrar la suscripción del negocio | **No se venden datos personales. No se comparten con anunciantes ni con corredores de datos.** No hay ninguna integración de ese tipo en el código. El dinero del viaje va **directo del pasajero al negocio** (hoy por Zelle). NEXRIDEBAY no recibe ese pago y no ve tus datos bancarios: del cobro solo se publica el nombre del destinatario, su identificador de Zelle, las instrucciones y el prefijo del memo. Números de cuenta y de ruta no se leen ni se exponen en ninguna parte del código. --- ## 4. Correos operativos y correos promocionales **Esta distinción está implementada, no es una promesa.** El sistema tiene una lista cerrada de correos operativos y una función que decide, por cada envío, si esa persona puede recibirlo. **Operativos — salen siempre, aunque te des de baja de las promociones:** - `OTP` — tu código de acceso - `RESERVATION_CREATED` — tu reserva quedó creada - `PAYMENT_PENDING` — falta el pago - `PAYMENT_REPORTED` — reportaste el pago - `PAYMENT_CONFIRMED` — el pago se confirmó - `DRIVER_ASSIGNED` — tienes conductor asignado - `TRIP_STARTED` — el viaje empezó - `TRIP_COMPLETED` — el viaje terminó - `RECEIPT` — tu recibo - `SAFETY` — avisos de seguridad de tu viaje Son parte del servicio que contrataste, no publicidad. Dejar de mandarte un aviso de seguridad porque no quieres ofertas sería como no avisarte de que tu conductor llegó. **Promocionales — solo si diste permiso, y hasta que lo retires:** Ofertas, novedades y campañas. Requieren tu consentimiento explícito. Puedes retirarlo cuando quieras. La baja pesa más que el permiso: si aceptaste en agosto y te diste de baja en septiembre, la respuesta es no. **Darse de baja de las promociones no corta ninguno de los correos operativos.** Está escrito así en el código y así aparece en la pantalla donde das el permiso. --- ## 5. Cuánto tiempo se conservan Hay que decirlo tal como está, porque suena peor de lo que la gente espera: **Hoy no existe ningún proceso automático que borre datos pasados N días.** No hay un cron de purga, no hay caducidad por antigüedad, y prometerla sería mentir. Lo que existe es esto: | Dato | Cuánto dura de verdad | |---|---| | Códigos de acceso | 10 minutos, o hasta que se usen. Después dejan de existir | | Mensajes de chat | Los últimos 200 de la reserva; se borran con la reserva | | Autorizaciones de subida no usadas | 10 minutos; luego se retiran y el objeto se borra del almacén | | Ubicación del conductor en la reserva | Se borra al cancelar y en las transiciones de estado | | Tokens push muertos | Se desactivan cuando el proveedor los rechaza | | Cuenta, reservas, evidencia adjunta | **Hasta que se borren a petición.** Sin plazo automático | Los registros de una reserva pagada se conservan de forma indefinida por razones fiscales y de defensa ante disputas de pago: son la prueba de que hubo un cobro y de que a alguien se le pagó por conducir. Ver `ELIMINACION_DE_CUENTA.md`. Si esto tiene que cambiar —y probablemente deba— es una decisión de negocio con consecuencias técnicas, no un párrafo que se añade a este documento. --- ## 6. Cómo se ejerce el borrado El detalle completo está en **`ELIMINACION_DE_CUENTA.md`**. En resumen: - **Se borra** todo lo que te identifica: cuenta, perfil, sesiones abiertas, códigos pendientes, registro de marketing, y tu nombre, correo, teléfono, direcciones, coordenadas, notas y mensajes de chat dentro de cada reserva. - **Se conserva** el hecho del viaje: que ocurrió, cuándo, cuánto costó y quién lo condujo. Sin ninguna dirección y sin ningún dato de contacto. **Estado de implementación, dicho claro:** la lógica de borrado y anonimización existe en el código (`backend/account_deletion.py`) y hace exactamente lo descrito. Está expuesta en el servidor como `DELETE /api/public/passenger/account`, que exige una sesión de pasajero iniciada y **solo borra la cuenta de quien la pide**. La respuesta enumera campo por campo lo que pasó, en vez de un "listo" que esconde la mitad. Lo que queda por confirmar antes de publicar es que **la opción esté visible dentro de las aplicaciones**, que es lo que exigen Apple y Google. Mientras eso no esté verificado, la petición también se atiende por correo. --- ## 7. Tus otros derechos - **Acceso:** puedes pedir copia de lo que hay sobre ti. - **Rectificación:** tu nombre e idioma los cambias tú en tu perfil; para lo demás, escribe. - **Retirar el consentimiento de marketing:** en cualquier momento, sin perder los correos operativos. - **Oposición y limitación:** escribe y se atiende caso por caso. **Estado de implementación:** no hay hoy un botón de "descarga mis datos". Las peticiones se atienden a mano. --- ## 8. Menores El servicio no está dirigido a menores de 13 años y no se recogen datos de menores a sabiendas. Un menor puede viajar acompañado; en ese caso la reserva la hace y la firma la persona adulta, con sus propios datos. --- ## 9. Seguridad Lo que está implementado, sin adornos: - No hay contraseñas de pasajero que robar: no existen. - Los códigos de acceso se guardan con hash y sal (scrypt), caducan y se limitan a 5 intentos. - La sesión en el teléfono va en el llavero del sistema. - Las imágenes de comprobante van a un almacén privado, con autorizaciones de un solo objeto y unos minutos, y sin URL adivinable. - El aislamiento entre negocios falla cerrado: ante la duda, no hay acceso. - Los tipos de archivo se comprueban por sus bytes, no por lo que declaren. - Los datos dinámicos se escapan antes de entrar en el HTML de los correos. - Las claves de los proveedores viven en el entorno del servidor y nunca llegan al navegador. Ningún sistema es invulnerable, y este documento no va a decir lo contrario. --- ## 10. Cambios y contacto Si esta política cambia de forma sustancial, se avisa por los canales operativos. **Contacto:** _[PENDIENTE — una persona tiene que decidir la dirección de contacto de privacidad y la razón social que aparece aquí. Ver `docs/store/PENDIENTE_HUMANO.md`.]_ --- ### Anexo: cosas que este documento NO promete Escritas aparte para que nadie las lea por error como si estuvieran hechas. 1. Borrado automático a los N días. **No existe.** 2. Que la opción de eliminar cuenta esté visible dentro de la app. **El servidor ya la implementa; que se vea en pantalla está sin verificar. Y no hay equivalente para la cuenta del conductor.** 3. Exportación de datos en un clic. **No existe.** Se atiende a mano. 4. Cifrado en reposo gestionado por nosotros. Depende de lo que ofrezcan Upstash y Vercel; no hay una capa de cifrado propia en el código. 5. Notificaciones push al pasajero. **Hoy solo el conductor registra tokens.** 6. Ubicación del conductor en segundo plano. **No existe hoy**; requiere una compilación nativa.