Hospedagem

O uloggd abre num frame a URL que você cadastra, e nada além dela. O jogo, os arquivos e as APIs dele ficam na sua hospedagem; o uloggd nunca os busca para os jogadores.

Uma origem por jogo

Dê a cada jogo uma origem própria, na prática um subdomínio próprio: https://orbit.example.com, e não https://example.com/orbit.

Dois jogos na mesma origem dividiriam localStorage, IndexedDB, cookies e service workers dentro do uloggd: um leria os tokens do outro, e aprovar um seria responder pelo outro. Por isso uma origem pertence a um aplicativo.

• Um aplicativo toma uma origem na primeira vez que a verificação de um dos lançamentos dele passa na prova de controle descrita abaixo.
• Um lançamento numa origem que outro aplicativo já tem é recusado com origin_in_use.
• Você pode passar uma origem para outro aplicativo seu, mas só enquanto nenhum lançamento nela estiver enviado, aprovado ou ao vivo.
• As origens de um aplicativo removido continuam reservadas para você, e nunca vão para outra pessoa.

As regras da URL

A URL de entrada de um lançamento precisa cumprir todas as regras abaixo. O portal diz qual falhou: url_invalid, ou url_denied para a lista de bloqueio e os nomes que o uloggd nunca abre. Um url_denied sobre um nome internacional ou sobre a rede traz também detail, que diz o porquê (veja Nomes internacionais e O domínio e a rede).

A URL de eventos de dados segue as mesmas regras, só que a origem e o caminho dela não precisam ser os da entrada.

Essas regras valem para os lançamentos, que os jogadores abrem: porta 443, nada de localhost e uma lista de bloqueio que inclui os túneis temporários. A URL de desenvolvimento, que só você abre, tem regras próprias: a sua máquina em qualquer porta, ou um túnel, sem arquivo de prova e sem verificação.

Nomes internacionais

Um endereço com caracteres fora do ASCII, como letras acentuadas ou de outro alfabeto, tem uma forma ASCII que começa com xn--: jogo.ação.br é jogo.xn--ao-siap.br. É essa a forma que o uloggd guarda e mostra, aos jogadores e no portal, para que um endereço não se passe por outro.

• Envie a forma ASCII. A API só aceita ASCII imprimível, e recusa o resto com url_invalid. O portal converte o que você digita e mostra embaixo do campo o endereço que vai salvar.
• Aceitos só enquanto o uloggd os libera. Fora disso, salvar, enviar e tornar ao vivo um lançamento que cite um (a URL de entrada, a URL de eventos de dados ou um terceiro) respondem url_denied com detail idn, e field com o campo.
• Mesmo assim, cada rótulo precisa ser um nome honesto, ou a resposta é url_denied com um destes em detail:

A URL de desenvolvimento nunca aceita um nome internacional.

O arquivo de prova

Sirva este arquivo na raiz da origem do jogo, /.well-known/uloggd-arcade.json:

{ "apps": ["ID_DO_SEU_APLICATIVO"] }

• Ele precisa responder 200, ser um JSON válido, ter até 4 KiB e listar o id do aplicativo que o portal mostra.
• Só quem controla a raiz de uma origem consegue publicá-lo. É essa a ideia: ele prova que a origem é sua, e exclui hospedagens onde muitos clientes dividem uma origem.
• A lista existe para um caso só, passar a origem de um aplicativo seu para outro. Fora isso, deixe um id nela.

Deixe o uloggd abrir o jogo num frame

A URL de entrada precisa responder 200 com text/html, direto, e aceitar o uloggd como página-mãe:

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

• Não envie X-Frame-Options: qualquer valor dele reprova a verificação.
• Um redirecionamento (qualquer 3xx) reprova a verificação. Cadastre a URL final.
• 'self' deixa as suas próprias páginas abrirem o jogo num frame, para as suas prévias.
• Sem frame-ancestors nenhum, a verificação também passa, desde que não haja X-Frame-Options, mas aí qualquer site consegue abrir o jogo num frame. Enviar frame-ancestors https://uloggd.com 'self' continua impedindo os outros sites de abri-lo.

O que a verificação faz

Os servidores do uloggd verificam a URL quando você aperta Verificar URL, antes do envio, antes da aprovação, antes de um lançamento ficar ao vivo, uma vez por dia (num horário que varia algumas horas) e depois que um jogador denuncia o jogo.

• As requisições levam o User-Agent uloggd-arcade-check/1 e nenhum cookie, não seguem redirecionamentos, desistem depois de 5 segundos e leem no máximo 512 KiB de uma resposta.
• O host precisa resolver só para endereços públicos.
• Três resultados bloqueiam o envio, a aprovação e o ao vivo quando falham: o arquivo de prova, nenhum redirecionamento e o frame permitido.
• Ela registra a impressão de rede: os endereços, a cadeia de CNAME, o emissor e a chave do certificado TLS, e o HSTS. Registra também um hash do documento de entrada.
• Ela lê o documento de entrada e até 8 scripts dele da mesma origem, registra um hash de cada script e extrai sinais para quem revisa: as origens que a página carrega, campos de senha e de pagamento, instruções para rodar comandos, rastreadores conhecidos e qualquer coisa que imite o uloggd. Sinais são mostrados a pessoas; nunca decidem sozinhos.

Um aplicativo tem 20 verificações de URL por dia, contando as que rodam no envio e no ao vivo.

Num jogo ao vivo, duas verificações reprovadas com pelo menos uma hora entre elas escondem o jogo até uma verificação passar de novo. Um provedor de hospedagem novo junto com uma chave TLS nova escondem o jogo até um moderador revisá-lo outra vez.

Depois da aprovação, cada verificação de um lançamento é comparada com a verificação que o aprovou. Quem revisa vê o que mudou entre as duas: os três resultados, as origens que a página carrega, formulários e campos sensíveis, o hash da página e de cada script, e o provedor de hospedagem e a rede.

No portal, uma verificação cujo documento de entrada é diferente do aprovado mostra Alterado desde a revisão. Não é uma recusa e não esconde nada: atualizações dentro do que foi revisado podem continuar na mesma URL, e o resto pede um lançamento novo (veja O que pode mudar atrás de uma URL).

O domínio e a rede

Toda verificação registra o domínio registrável do host do jogo: o nome que um registrador vende, encontrado na Public Suffix List, uma lista pública da qual o uloggd guarda uma cópia. orbit.exemplo.com.br fica sob exemplo.com.br; um host sob um sufixo compartilhado, como github.io, é um domínio próprio. Descobri-lo não consulta ninguém. Uma verificação devolvida pela API o traz em network.registrable_domain.

Quando o uloggd liga as consultas de rede, a verificação também consulta:

• o serviço RDAP do registro do domínio, para saber o registrador, as datas de registro, de expiração e da última alteração, o status e os servidores de nomes;
• o RIPEstat, do RIPE NCC, para saber a rede (ASN), o titular dela e o prefixo de até quatro dos endereços IP do host.

O uloggd nunca guarda o nome nem os contatos de quem registrou o domínio. O que ele descobre aparece para os moderadores e está na exportação de dados da sua conta. Uma consulta que falha ou não traz nada nunca reprova uma verificação.

Elas podem recusar um lançamento quando você o envia, quando um moderador o aprova e quando você o torna ao vivo:

• url_denied com detail network e field entry_url: a rede do host ou o registrador dele está na lista de bloqueio do uloggd. Algumas entradas só marcam o lançamento para quem revisa.
• domain_too_new (409 conflict): para uma conta que não foi convidada, o domínio foi registrado há menos tempo do que o mínimo que o uloggd define.

As duas dependem das consultas: enquanto elas estão desligadas, nada sobre a rede ou a idade do domínio recusa um lançamento. Para pedir que uma recusa dessas seja revista, escreva para o contato da página Sobre nós.

O que pode mudar atrás de uma URL

A mesma URL pode continuar servindo um jogo que evolui. Sem um lançamento novo, você pode publicar correções e atualizações de conteúdo que fiquem dentro da descrição, da classificação, dos escopos e dos terceiros declarados que foram revisados. Uma mudança de classificação passa pela página da loja, não por um lançamento novo.

Isto exige um lançamento novo, e uma revisão nova:

• coletar dados novos;
• um terceiro novo;
• qualquer monetização;
• fluxos de login;
• comunicação entre jogadores.

Cada um é julgado pelas proibições dos termos, que vetam alguns de vez: loot boxes, anúncios e rastreadores, e conversa livre entre jogadores (veja Política de revisão).

Servir a quem revisa, ou às verificações do uloggd, algo diferente do que os jogadores recebem (cloaking), ou trocar o comportamento do jogo depois da aprovação, encerra a conta.

URLs de publicação imutáveis

Prefira URLs cujo conteúdo nunca muda depois de publicado, uma por build. Uma mudança aparece então como um lançamento novo, e desfazer uma troca passa a significar alguma coisa.

• Um caminho por build na origem do jogo, como https://orbit.example.com/builds/1.4.2/, mantém uma origem só. Os jogadores guardam os dados que o jogo salvou no navegador, e o aviso do primeiro jogo não aparece de novo. O arquivo de prova continua na raiz da origem.
• Um host por build, como Vercel, Netlify e Cloudflare Pages dão a cada publicação, também funciona, com três consequências. Cada host novo é uma origem nova, que o seu aplicativo toma na primeira verificação aprovada, então o arquivo de prova precisa estar em todo build. O armazenamento que os jogadores tinham na origem anterior não vai junto, então guarde os progressos no seu servidor. E os jogadores veem o aviso do primeiro jogo de novo, porque ele aparece para cada origem nova.

Tornar um lançamento ao vivo compara o provedor de hospedagem com o visto na aprovação: os dois últimos rótulos do destino final do CNAME, ou o emissor do TLS quando não há CNAME. Levar um jogo para outro provedor exige um lançamento novo.