You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
16 KiB
16 KiB
Revisión de especificaciones de plataforma — 5 de octubre de 2026
Alcance: modelo de plataforma, API/eventos y su encaje con el motor. Durante la revisión el usuario añadió protección transversal del menor, SMS obligatorio para chat y confirmó chat desactivado para menores. Esos requisitos se desarrollan en protección del menor, con comparación de políticas publicadas.
Esta revisión identifica defectos de diseño documental, no vulnerabilidades explotadas ni correcciones desplegadas. «Corregido» significa que la propuesta ya expresa la regla; aún faltan implementación, esquemas y pruebas de comportamiento.
Hallazgos y resolución
P1: riesgo de privacidad, doble efecto o estado inconsistente. P2: ambigüedad o falta que impide implementar/comprobar correctamente.
| ID | Prioridad | Fallo del borrador anterior | Resolución incorporada y comprobación pendiente |
|---|---|---|---|
| F01 | P1 | Retirada/cierre comprobaban solo revisión de sala; una jugada no necesariamente la cambia. No se fijaba frontera transaccional sala-motor. | Revisión adicional de partida, orden de bloqueo común y transacción compartida. Probar jugada frente a retirada/cierre y rollback de setup. |
| F02 | P1 | Se podía considerar corrupta una sala/partida por recibir sus eventos en orden inverso. | Barrera minimumRevision, estados independientes y recuperación del flujo atrasado. Probar ambas órdenes de entrega. |
| F03 | P1 | Moderar reemplazando un mensaje sin una secuencia nueva no actualizaba a clientes; páginas retrasadas podían reponer el texto. | Flujo de eventos de chat, redacción con nueva secuencia, historyEpoch y rechazo de páginas antiguas. Probar moderación concurrente con historial. |
| F04 | P1 | Idempotencia HTTP de 24 h sin límite de antigüedad permitía repetir una creación al purgar el recibo; faltaban colisión concurrente y propietario anónimo. | Fecha de emisión, ventana de admisión, restricción única, registro común por principal y contexto anónimo para altas. Probar repetición tardía y simultánea. |
| F05 | P1 | Invitación «token una vez/solo hash» era incompatible con recuperar una respuesta perdida. | Respuesta secreta cifrada temporal con alcance, caducidad y rotación explícita fuera de ventana. Probar pérdida de respuesta y cambio de anfitrión. |
| F06 | P1 | Exigir membresía para consultar cualquier operación impedía recuperar el recibo de una salida ya aplicada. | Recibo mínimo por principal emisor, sin devolver vista privada ni recuperar membresía. Probar salida y consulta desde otra sesión propia. |
| F07 | P1 | Autorización y revocación no contemplaban sesiones o publicaciones ya preparadas, ni protección infantil. | Política común, safetyRevision, cancelación de suscripciones y reautorización antes de entrega; menores/edad desconocida sin chat incluso en v1. Probar varias pestañas y outbox pendiente. |
| F08 | P2 | La matriz confundía invitado/cuenta con miembro/anfitrión y producía permisos contradictorios. | Ejes independientes y requisitos por operación; invitado puede ser anfitrión, pero no eludir edad/SMS. |
| F09 | P2 | Faltaban cancelar/configurar, revocar/rotar invitación, revocar condiciones/sesión y recuperar envíos de chat. | Operaciones y consulta común de recibos explícitas. Las credenciales/proveedor de edad permanecen señalados como pendientes, no simulados. |
| F10 | P2 | Solo podían jugar solos paquetes con min=max=1; inicio/fijación de versión aparecía en dos momentos. |
Capacidad dentro del rango; pin exacto al crear, congelación de configuración al iniciar, invalidación de listo y setup atómico. |
| F11 | P2 | La política de inactividad no decía qué actividad contaba ni cómo evitar cierres obsoletos o reglas acopladas a state.turn. |
Política versionada, progreso del motor, actores internos, generación y revalidación bajo bloqueo. No cuentan chat ni presencia. |
| F12 | P2 | Negociación dentro de room.sync no cubría clientes sin sala; faltaban recibos de baja, cursor de chat y límites de buffers. |
Negociación de conexión, tipos correlacionados, sincronización acotada, cursores y backpressure. |
| F13 | P2 | La sincronización de chat retenía eventos mientras se paginaba un historial sin operación de continuación definida. | Snapshot de cola reciente con barrera; historial HTTP aparte, sin bloquear flujo vivo hasta leerlo entero. |
| F14 | P2 | Dedupe de avisos omitía destinatario; leerlos en una pestaña no tenía revisión. Un aviso de lobby podía revelar actividad privada. | Dedupe por destinatario/transición, revisión de bandeja al leer y señal solo por cambios públicos. |
| F15 | P2 | «Todos los IDs son UUID» contradecía gameId/asientos del motor. Campos de autoridad prohibidos también podían confundirse con destinatarios válidos. |
Excepciones tipadas y distinción actor/objetivo. |
| F16 | P2 | 428 se reutilizaba para condiciones de uso; caché, errores, cursores y campos desconocidos eran ambiguos. | 403 para falta de aceptación, 409 para versión cambiada, revisiones de dominio y política separada de solicitud/respuesta. Referencia RFC 6585. |
| F17 | P1 | No se había especificado protección del menor ni diferencia entre teléfono, identidad, edad y consentimiento. | Requisito nuevo confirmado: no chat para menores; comprobación independiente de edad/SMS, restricciones en todo contenido/medio, reportes sin SMS y pruebas de evasión. |
| F18 | P2 | Recursos retirados parecían volverse privados; faltaban cuarentena, propiedad/validación de avatares y autoridad de publicación. | Política de distribución separada de contenido inmutable, publicación de confianza, medios propios validados y presets seguros. |
| F19 | P2 | Inmutabilidad de historial podía interpretarse como conservación personal indefinida; outbox y auditoría estaban mezcladas. | Finalidades/retenciones independientes, enmiendas auditables, anonimización y reaplicación de borrados tras restaurar. |
| F20 | P2 | SLO sin punto de medida/carga, migración sin autoridad única y recuperación/rollback no verificables. | Métricas servidor/exterior separadas, carga por definir, expansión/contracción, mapeo de IDs y cero doble escritura autónoma. RPO/RTO siguen pendientes. |
Carencias que no resuelve editar Markdown
Actualización posterior por encargo del usuario: políticas de producto desarrolla P1–P8 y compara fuentes oficiales; arquitectura separa las tres capas y evalúa Go. Publicación de juegos exclusivamente propios confirmada. Ya no faltan todos los valores de producto, pero sí evidencia de proveedores, capacidad operativa, contratos ejecutables e implementación.
| Pendiente | Entregable necesario |
|---|---|
| Credenciales y recuperación P6 | Correo/contraseña, estados y sesiones ya propuestos; faltan esquemas, proveedor, migración PIN y pruebas de emisión/recuperación. |
| Edad y acceso de menores P7 | Perfil España/tutela/salas protegidas definido; faltan evaluación territorial, proveedor de edad, procedimiento de evidencia de responsabilidad y validación real. |
| SMS | Plazos y límites definidos; faltan proveedor, precios/presupuesto autorizado, dedupe/conciliación y pruebas de webhooks. |
| Moderación | Roles, acciones y objetivos definidos; faltan consola, personal/cobertura, procedimiento de escalado y revisión independiente operativa. |
| Conservación/operación P8 | Matriz y objetivos RPO/RTO/carga definidos; faltan responsables, fundamento por finalidad, ejecución de purgas y ensayos medidos. |
| Contratos ejecutables | Fuente común de tipos, OpenAPI, esquemas de eventos, fixtures válidos/negativos y comprobación CI. |
| Integración del motor | Unidad de trabajo compartida, cancelación de núcleo, configuración de preparación/asientos y mapeo de versiones antiguas. |
| Dirección Go | API Go fijada; servidor Go recomendado. SDK nativo, binding de transporte, paquete versionado y equivalencia de reglas pendientes antes de portar producción. |
| Validación real | Concurrencia, privacidad, reconexión, abuso, SMS, pruebas móviles/accesibilidad y ensayos con PostgreSQL/proxy. |
Los requisitos confirmados de protección no dependen de aprobar una excepción de chat infantil: esa excepción no existe. Mientras falten pruebas de edad/mecanismos operativos, no se habilita comunicación por suposición.
Hallazgos de la ampliación de políticas y arquitectura
| ID | Problema o riesgo de diseño | Resolución documental / aceptación pendiente |
|---|---|---|
| F21 | «Publicador de confianza» podía interpretarse como apertura a autores externos. | Solo equipo y juegos propios; flujo interno, sin API pública de publicación. |
| F22 | Tres capas podían convertirse en dos escritores independientes de sala/partida. | API y servidor modular Go recomendado, unidad de trabajo común; puente Node con autoridad única si se necesita. |
| F23 | Confundir formato/protocolo JSON con compatibilidad ejecutable del SDK TS en Go. | Diferenciar datos, firmas y runtime; perfil de paquete versionado y fixtures de equivalencia antes de portar. |
| F24 | Sustituir Socket.IO por WebSocket sin adaptar handshake/cliente/recuperación. | Transporte actual preservado en su contrato; nuevo binding requiere especificación y pruebas, sin compatibilidad fingida. |
| F25 | SMS, correo, edad adulta o token podían interpretarse como evidencia de tutela o recuperación suficiente. | Evidencias y finalidades separadas, recuperación suspende capacidades sensibles, contactos autorizados y recurso. |
| F26 | Las políticas de desconexión podían sancionar fallos del servicio o ejecutar cierres vencidos durante una caída. | Sin penalización por presencia, ventanas de incidente y reconciliación de trabajos antes de reactivar cierres. |
| F27 | Historial de chat sin límite inferior y purga sin invalidación podían divulgar conversaciones previas o resucitar texto. | Intervalo por membresía, purga a 30 días y aumento de epoch/invalidación; pruebas de páginas retrasadas. |
| F28 | Objetivos de moderación/seguridad sin personas, presupuesto o backups medidos podían presentarse como capacidad existente. | Dependencias de activación, perfiles de ensayo y distinción entre objetivo y resultado observado. |
Las limitaciones observadas al comparar políticas de otras plataformas se distinguen de incidentes demostrados; no se ha auditado su implementación. Las fuentes y decisiones propias están junto a cada comparación en las políticas.
Fuentes y criterio de revisión
- Socket.IO: delivery guarantees: sustenta la necesidad de recuperación a nivel de aplicación.
- PostgreSQL: explicit locking: orden consistente y transacciones acotadas.
- RFC 6585, sección 3: significado de 428.
- RFC 9457 y RFC 8785: errores HTTP y JSON canónico.
- OWASP: session management: sesión y revocación servidor.
- Las fuentes de edad, SMS y la comparación con Lichess, ChessKid, Roblox y Discord figuran junto a las afirmaciones en protección del menor.
La revisión toma estos textos como referencias técnicas y políticas publicadas, no como prueba de cumplimiento de Juegoland ni auditoría de terceros.