Alojamiento

uloggd abre en un frame la URL que registras, y nada más. El juego, sus archivos y sus APIs se quedan en tu alojamiento; uloggd nunca los descarga para los jugadores.

Un origen por juego

Dale a cada juego su propio origen, en la práctica su propio subdominio: https://orbit.example.com, no https://example.com/orbit.

Dos juegos en un mismo origen compartirían localStorage, IndexedDB, cookies y service workers dentro de uloggd: uno podría leer los tokens del otro, y aprobar uno sería responder por el otro. Por eso un origen pertenece a una aplicación.

• Una aplicación toma un origen la primera vez que la verificación de uno de sus lanzamientos supera la prueba de control descrita abajo.
• Un lanzamiento en un origen que ya tiene otra aplicación se rechaza con origin_in_use.
• Puedes pasar un origen a otra de tus aplicaciones, pero solo mientras ningún lanzamiento en él esté enviado, aprobado o en vivo.
• Los orígenes de una aplicación quitada siguen reservados para ti, y nunca pasan a otra persona.

Las reglas de la URL

La URL de entrada de un lanzamiento debe cumplir todas las reglas de abajo. El portal dice cuál falló: url_invalid, o url_denied para la lista de bloqueo y los nombres que uloggd nunca abre. Un url_denied sobre un nombre internacional o sobre la red trae también detail, que dice por qué (consulta Nombres internacionales y El dominio y la red).

La URL de eventos de datos sigue las mismas reglas, salvo que su origen y su ruta no tienen que coincidir con los de la entrada.

Estas reglas son para los lanzamientos, que abren los jugadores: puerto 443, nada de localhost y una lista de bloqueo que incluye los túneles temporales. La URL de desarrollo, que solo abres tú, tiene reglas propias: tu máquina en cualquier puerto, o un túnel, sin archivo de prueba y sin verificación.

Nombres internacionales

Una dirección con caracteres fuera del ASCII, como letras con tilde o de otro alfabeto, tiene una forma ASCII que empieza por xn--: jogo.ação.br es jogo.xn--ao-siap.br. Esa es la forma que uloggd guarda y muestra, a los jugadores y en el portal, para que ninguna dirección se haga pasar por otra.

• Envía la forma ASCII. La API solo acepta ASCII imprimible, y rechaza lo demás con url_invalid. El portal convierte lo que escribes y muestra bajo el campo la dirección que va a guardar.
• Aceptados solo mientras uloggd los permite. Si no, guardar, enviar y poner en vivo un lanzamiento que nombre uno (la URL de entrada, la URL de eventos de datos o un tercero) responden url_denied con detail idn, y field con el campo.
• Aun así, cada etiqueta debe ser un nombre honesto, o la respuesta es url_denied con uno de estos en detail:

La URL de desarrollo nunca acepta un nombre internacional.

El archivo de prueba

Sirve este archivo en la raíz del origen del juego, /.well-known/uloggd-arcade.json:

{ "apps": ["ID_DE_TU_APLICACION"] }

• Debe responder 200, ser un JSON válido, pesar hasta 4 KiB y listar el id de la aplicación que muestra el portal.
• Solo quien controla la raíz de un origen puede publicarlo. Esa es la idea: prueba que el origen es tuyo, y descarta alojamientos donde muchos clientes comparten un origen.
• La lista existe para un único caso, pasar el origen de una de tus aplicaciones a otra. Si no, deja un solo id.

Deja que uloggd lo abra en un frame

La URL de entrada debe responder 200 con text/html, directamente, y aceptar a uloggd como página contenedora:

Content-Security-Policy: frame-ancestors https://uloggd.com 'self'

• No envíes X-Frame-Options: cualquier valor suyo hace fallar la verificación.
• Una redirección (cualquier 3xx) hace fallar la verificación. Registra la URL final.
• 'self' permite que tus propias páginas abran el juego en un frame, para tus vistas previas.
• Sin ningún frame-ancestors, la verificación también pasa, siempre que no haya X-Frame-Options, pero entonces cualquier sitio puede abrir el juego en un frame. Enviar frame-ancestors https://uloggd.com 'self' sigue impidiendo que otros sitios lo abran.

Qué hace la verificación

Los servidores de uloggd verifican la URL cuando pulsas Verificar URL, antes del envío, antes de la aprobación, antes de que un lanzamiento pase a vivo, una vez al día (a una hora que varía unas horas) y después de que un jugador denuncie el juego.

• Las peticiones llevan el User-Agent uloggd-arcade-check/1 y ninguna cookie, no siguen redirecciones, se rinden tras 5 segundos y leen como máximo 512 KiB de una respuesta.
• El host debe resolver solo a direcciones públicas.
• Tres resultados bloquean el envío, la aprobación y el paso a vivo cuando fallan: el archivo de prueba, ninguna redirección y el frame permitido.
• Registra la huella de red: las direcciones, la cadena de CNAME, el emisor y la llave del certificado TLS, y el HSTS. También registra un hash del documento de entrada.
• Lee el documento de entrada y hasta 8 de sus scripts del mismo origen, registra un hash de cada script y extrae señales para quien revisa: los orígenes que carga la página, campos de contraseña y de pago, instrucciones para ejecutar comandos, rastreadores conocidos y cualquier cosa que imite a uloggd. Las señales se muestran a personas; nunca deciden solas.

Una aplicación tiene 20 verificaciones de URL al día, contando las que se hacen al enviar y al poner en vivo.

En un juego en vivo, dos verificaciones fallidas con al menos una hora entre ellas ocultan el juego hasta que una verificación vuelva a pasar. Un proveedor de alojamiento nuevo junto con una llave TLS nueva lo ocultan hasta que un moderador lo revise otra vez.

Tras la aprobación, cada verificación de un lanzamiento se compara con la verificación que lo aprobó. Quien revisa ve qué cambió entre las dos: los tres resultados, los orígenes que carga la página, formularios y campos sensibles, el hash de la página y de cada script, y el proveedor de alojamiento y la red.

En el portal, una verificación cuyo documento de entrada es distinto del aprobado muestra Cambiado desde la revisión. No es un rechazo y no oculta nada: las actualizaciones dentro de lo revisado pueden seguir en la misma URL, y el resto requiere un lanzamiento nuevo (consulta Qué puede cambiar detrás de una URL).

El dominio y la red

Toda verificación registra el dominio registrable del host del juego: el nombre que vende un registrador, encontrado en la Public Suffix List, una lista pública de la que uloggd guarda una copia. orbit.example.com está bajo example.com; un host bajo un sufijo compartido, como github.io, es un dominio propio. Averiguarlo no consulta a nadie. Una verificación que devuelve la API lo trae en network.registrable_domain.

Cuando uloggd activa las consultas de red, la verificación también consulta:

• el servicio RDAP del registro del dominio, para saber el registrador, las fechas de registro, de vencimiento y del último cambio, el estado y los servidores de nombres;
• RIPEstat, de RIPE NCC, para saber la red (ASN), su titular y el prefijo de hasta cuatro de las direcciones IP del host.

uloggd nunca guarda el nombre ni los contactos de quien registró el dominio. Lo que averigua lo ven los moderadores y está en la exportación de datos de tu cuenta. Una consulta que falla o no trae nada nunca hace fallar una verificación.

Pueden rechazar un lanzamiento cuando lo envías, cuando un moderador lo aprueba y cuando lo pones en vivo:

• url_denied con detail network y field entry_url: la red del host o su registrador está en la lista de bloqueo de uloggd. Algunas entradas solo marcan el lanzamiento para quien revisa.
• domain_too_new (409 conflict): para una cuenta que no fue invitada, el dominio se registró hace menos tiempo que el mínimo que fija uloggd.

Las dos dependen de las consultas: mientras están desactivadas, nada sobre la red o la edad del dominio rechaza un lanzamiento. Para pedir que se revise un rechazo así, escribe al contacto de la página Sobre nosotros.

Qué puede cambiar detrás de una URL

La misma URL puede seguir sirviendo un juego que evoluciona. Sin un lanzamiento nuevo, puedes publicar correcciones y actualizaciones de contenido que se mantengan dentro de la descripción, la clasificación, los permisos y los terceros declarados que se revisaron. Un cambio de clasificación pasa por la página de la tienda, no por un lanzamiento nuevo.

Esto exige un lanzamiento nuevo, y una revisión nueva:

• recoger datos nuevos;
• un tercero nuevo;
• cualquier monetización;
• flujos de inicio de sesión;
• comunicación entre jugadores.

Cada uno se juzga según las prohibiciones de los términos, que vetan algunos de plano: loot boxes, anuncios y rastreadores, y chat libre entre jugadores (consulta Política de revisión).

Servir a quien revisa, o a las verificaciones de uloggd, algo distinto de lo que reciben los jugadores (cloaking), o cambiar el comportamiento del juego tras la aprobación, termina la cuenta.

URLs de despliegue inmutables

Prefiere URLs cuyo contenido nunca cambia una vez desplegado, una por build. Así un cambio aparece como un lanzamiento nuevo, y deshacer un cambio significa algo.

• Una ruta por build en el origen del juego, como https://orbit.example.com/builds/1.4.2/, mantiene un único origen. Los jugadores conservan los datos que el juego guardó en su navegador, y el aviso de la primera partida no vuelve a aparecer. El archivo de prueba sigue en la raíz del origen.
• Un host por build, como el que dan Vercel, Netlify y Cloudflare Pages a cada despliegue, también funciona, con tres consecuencias. Cada host nuevo es un origen nuevo, que tu aplicación toma en su primera verificación superada, así que el archivo de prueba debe estar en cada build. El almacenamiento que los jugadores tenían en el origen anterior no los acompaña, así que guarda las partidas en tu servidor. Y los jugadores ven otra vez el aviso de la primera partida, porque aparece para cada origen nuevo.

Poner un lanzamiento en vivo compara el proveedor de alojamiento con el visto en la aprobación: las dos últimas etiquetas del destino final del CNAME, o el emisor del TLS cuando no hay CNAME. Llevar un juego a otro proveedor exige un lanzamiento nuevo.