Onde os padrões da redação de PII no session replay deixam dados expostos

O que é a redação de PII no session replay?

O essencial da redação de PII no session replay é que ela acontece no navegador do visitante, antes de o gravador serializar o DOM e enviar qualquer coisa pela rede, e por isso uma regra que você adiciona hoje não faz nada por uma gravação capturada ontem. Um script de replay não filma a tela. Ele percorre o DOM, serializa cada nó e transmite mutações, então redigir significa decidir quais nós enviam valores reais, quais enviam caracteres de marcador e quais são descartados e reproduzidos como uma caixa vazia.

Três verbos cobrem os resultados, com nomes diferentes em cada biblioteca. Bloquear descarta o elemento e reproduz um marcador com as mesmas dimensões. Mascarar mantém o elemento e substitui o texto dele. Ignorar mantém o elemento visível, mas para de gravar o que o usuário digitou. Escolher errado entre mascarar e bloquear é o erro mais comum, porque elementos mascarados continuam carregando dados de interação e continuam carregando o comprimento.

O enquadramento de conformidade, incluindo retenção e consentimento, está no guia sobre mascaramento de privacidade do session replay. Esta página cobre a mecânica por baixo: nomes exatos das opções, padrões de fábrica e os pontos onde eles vazam.

Três verbos, um nó do DOM

BloquearRemove o elemento e reproduz um espaço reservado com as mesmas dimensões

MascararMantém o elemento, substitui o texto, ainda revela o tamanho e os dados de interação

IgnorarMantém o elemento visível, para de gravar o que o usuário digitou

Quais opções do rrweb controlam o que é gravado?

O rrweb, o gravador de código aberto por trás de uma longa lista de produtos comerciais de replay, expõe estas opções de privacidade em rrweb.record() com estes padrões documentados.

Opção	Padrão	O que faz
blockClass	'rr-block'	O elemento não é gravado e é reproduzido como um marcador das mesmas dimensões
blockSelector	null	Igual a blockClass, mas com correspondência por seletor CSS
ignoreClass	'rr-ignore'	O elemento é renderizado normalmente, mas os eventos de entrada dele não são gravados
ignoreSelector	null	Igual a ignoreClass, mas com correspondência por seletor CSS
maskTextClass	'rr-mask'	Todo o texto do elemento e dos filhos dele é mascarado
maskTextSelector	null	Igual a maskTextClass, mas com correspondência por seletor CSS
maskAllInputs	false	Mascara o conteúdo de cada entrada como *
maskInputOptions	{ password: true }	Mascara tipos específicos de entrada
maskInputFn	nenhuma	Substitui a lógica padrão de mascaramento de entradas
maskTextFn	nenhuma	Substitui a lógica padrão de mascaramento de texto

O guia do rrweb declara o padrão de fábrica em uma linha: input[type="password"] will be masked by default.

O que a lista não contém é uma opção de desmascarar. Nas opções de gravação do rrweb não existem unmaskTextClass nem unblockSelector, então uma máscara aplicada a um contêiner não pode ser removida de um único filho dentro dele. Os fornecedores que oferecem desmascaramento, entre eles Sentry e FullStory, construíram essa camada por conta própria.

O que o rrweb mascara por padrão?

Direto da caixa, o rrweb mascara exatamente uma coisa: o valor de input[type="password"]. Texto e todos os outros tipos de entrada são gravados literalmente, então campos de e-mail, nome, endereço, número de cartão e texto livre saem do navegador com o conteúdo real deles, a menos que você configure de outro jeito.

Dois detalhes no código-fonte do rrweb transformam esse padrão em armadilha. O primeiro é que maskInputOptions substitui o padrão em vez de mesclar com ele. Passe maskInputOptions: { email: true } porque você quer cobrir e-mails e terá desligado o mascaramento de senhas em silêncio. A forma segura escreve { password: true, email: true } todas as vezes.

O segundo é o formato do tipo MaskInputOptions. Ele aceita color, date, datetime-local, email, month, number, range, search, tel, text, time, url, week, textarea, select e password, e não aceita checkbox, radio nem file. Definir maskAllInputs: true se expande para todas as chaves dessa lista, então até a configuração máxima de mascaramento de entradas grava quais caixas de seleção e botões de opção um visitante marcou. Em um formulário de admissão médica, a caixa de seleção é o dado sensível. O FullStory resolve isso excluindo em vez de mascarar: o recurso Form Privacy dele "masks all form elements with the attributes input, textarea, select, and contenteditable, and exclude all form elements with the attributes radio and checkbox."

Como os fornecedores de session replay diferem nos padrões de mascaramento?

Os fornecedores ficam em extremos opostos da mesma caixa de ferramentas, e o padrão decide quanto custa uma regra esquecida.

Ferramenta	Mascarado sem configuração	Mecanismo de exclusão
rrweb	Somente input[type="password"]	Nenhum; não existe opção de desmascarar
PostHog	Todas as entradas (maskAllInputs vale true por padrão); o texto não é mascarado	Classe ph-no-capture
Sentry	Todo o texto (maskAllText: true), todas as entradas, toda a mídia (blockAllMedia: true)	.sentry-unmask, .sentry-unblock, nenhuma aplicada por padrão
Microsoft Clarity	Números e endereços de e-mail no modo Balanced padrão; entradas e menus suspensos em todos os modos	data-clarity-unmask="true"
FullStory com Private by Default	Todos os elementos, capturados mascarados	.fs-unmask
LogRocket	Nada; inputSanitizer e textSanitizer valem false por padrão	data-public

O Sentry declara a posição dele sem rodeios: "by default, the Session Replay SDK will mask all text content with * and block all media elements." O Clarity oferece o trade-off oposto por meio de três modos, em que o Strict mascara "the entire content", o Balanced mascara "numbers and email addresses" e o Relaxed não mascara nada além de entradas e menus suspensos. Dois comportamentos do Clarity não são configuráveis de jeito nenhum: "Content in the input boxes is masked in all modes and can't be customized" e "The drop-down menus are also masked in all modes." O Clarity marca o que escondeu com ▫ para um dígito, ▪ para uma letra e • para o modo Strict.

Por que o texto mascarado ainda vaza informação?

O texto mascarado vaza o comprimento daquilo que substituiu, porque os gravadores mais usados colocam um caractere de marcador para cada caractere original. A função de mascaramento do rrweb é literalmente text = '*'.repeat(text.length). A função de máscara padrão do Sentry é (s) => '*'.repeat(s.length). O FullStory é explícito: "This placeholder text blob will retain the size, color, and character length of the original text."

A própria documentação do FullStory torna o risco concreto para um campo como o saldo de uma conta: "if you were comparing the session replays of 2 different accounts, and one showed a placeholder string for account balance that was three inches long and the other had a placeholder string that was half an inch long, you now know more about these two accounts than you probably need to."

O comprimento não é o único canal. Elementos mascarados continuam gravando interações, e é por isso que o FullStory orienta clientes de saúde a excluir em vez de mascarar: "Because masked elements collect interaction data, it would be possible for someone with good working knowledge of the product to understand which health issues a user was checking the boxes for."

A correção é a mesma nos dois casos. Retorne uma string de comprimento fixo a partir de uma maskTextFn ou maskInputFn própria, em vez de uma que trabalhe caractere a caractere, e promova de mascarar para bloquear tudo o que permita inferência. A distância entre reduzir a identificabilidade e removê-la é a diferença entre pseudonimização e anonimização.

O que as regras de mascaramento deixam passar?

As regras de mascaramento valem para nós de texto do DOM e valores de entrada, então tudo o que carrega dados fora desses dois lugares fica na gravação. Cada fornecedor documenta o ponto cego dele.

• Folhas de estilo. O Clarity "doesn't mask content within style sheets or style tags. Hence, it is recommended not to host sensitive content within CSS."
• SVG embutido. Hotjar: "SVGs linked as the source for image elements can be suppressed, but inline SVGs cannot."
• Imagens na web. FullStory: "Images cannot be masked when capturing data on web sessions. If you wish to hide images from data capture, use .fs-exclude."
• URLs e cargas de rede. Uma página mascarada com um número de conta na query string envia esse número mesmo assim. O PostHog expõe maskCapturedNetworkRequestFn; o FullStory usa listas de permissão para corpos de requisição e resposta.
• Propriedades de eventos personalizados. A redação governa o fluxo de replay, não os eventos de analytics que o seu próprio código envia.

Dá para aplicar mascaramento a gravações que você já tem?

Nenhum fornecedor consegue redigir retroativamente uma sessão que já chegou aos servidores dele, e dois dizem isso por escrito. Clarity: "Changes to masking settings affect new recordings and could take up to one hour to be reflected. Masking changes can't be applied retroactively." Hotjar: "After a session is sent, there is no way to retrieve or suppress data, and updating suppression settings will not apply the updated settings retroactively."

O número de uma hora é a parte que as equipes deixam passar. Adicionar uma regra depois de ver números de cartão em um replay deixa até mais uma hora de gravações capturando esses números, além de tudo o que já está armazenado. Os remédios são apagar as gravações afetadas e encurtar a retenção, o que faz do prazo de retenção um controle de redação em vez de uma configuração de armazenamento. É também por isso que os autores nos processos de escuta ilegal por session replay discutem o que foi capturado, e não o que foi escondido depois na interface de replay.

Você deve mascarar tudo e desmascarar, ou o contrário?

Mascare tudo por padrão e desmascare o que você verificou, porque o modo de falha de uma lista de bloqueio é capturar dados que você nunca quis e o modo de falha de uma lista de permissão é um replay entediante. O FullStory construiu o Private by Default com base nesse raciocínio: "no text is captured or sent outside the user's browser unless it is explicitly allowlisted as safe to capture", de modo que "you won't accidentally capture unwanted data even if you fail to set specific data capture rules."

Acerte a regra de precedência antes de escrever o primeiro seletor. O FullStory resolve conflitos a favor da privacidade: "if an element matches both a masking rule and an unmasking rule, it would be masked rather than unmasked, as the stricter rule will always apply." O Clarity vai para o outro lado nos atributos: data-clarity-unmask="true" desmascara um nó e os filhos dele e "overrides anything set on the Clarity website." Dois produtos, duas respostas opostas.

Mantenha as regras no código, não em um painel. O FullStory chama a abordagem que começa pelo código de "a less brittle and more future-proof approach than handling these rules through the UI using CSS selectors", porque um seletor escrito numa tela de configurações quebra em silêncio quando uma biblioteca de componentes lança novos nomes de classe.

O Flowsery roda sem cookies e grava sessões sem amostragem. Se você ainda está decidindo o que o replay captura, comece por o que é session replay e depois defina a política de mascaramento, antes de a primeira tag de script entrar no ar.

Perguntas frequentes

O mascaramento no session replay acontece antes ou depois do envio dos dados?

Antes, em todos os produtos documentados aqui. O Clarity "never captures anything that is masked or sent over the wire", e o Hotjar descreve a supressão como a remoção de dados pessoais "before sending a session from your website's Document Object Model (DOM) to Hotjar". Mascaramento aplicado no momento da reprodução é um filtro de exibição, não redação.

maskAllInputs: true cobre todos os campos de formulário no rrweb?

Não. Ele se expande para todas as chaves do tipo MaskInputOptions do rrweb, que omite checkbox, radio e file, então o estado de caixas de seleção e botões de opção continua sendo gravado. Bloqueie esses elementos em vez disso, do jeito que o Form Privacy do FullStory faz.

Posso desmascarar um campo dentro de um contêiner mascarado?

Depende do produto, e o rrweb sozinho não consegue. As opções de gravação do rrweb não incluem classe nem seletor de desmascaramento, então uma máscara no elemento pai cobre todos os filhos. FullStory e Sentry acrescentam desmascaramento por cima, com o Sentry entregando .sentry-unmask e .sentry-unblock sem aplicá-los a nada por padrão.

Qual é a diferença entre mascarar e bloquear um elemento?

Mascarar mantém o elemento e substitui o texto dele; bloquear remove o elemento e reproduz um marcador. O FullStory traça a linha pelo risco de inferência e recomenda exclusão para dados regulados, para identificadores como números de conta bancária e para qualquer elemento em que só a interação já revele algo pessoal.

Gravações mascaradas ainda contam como dados pessoais?

Trate-as como dados pessoais até provar o contrário. Um mascaramento que preserva comprimento de caracteres, coordenadas de clique e estrutura de elementos reduz a identificabilidade sem removê-la, o que é pseudonimização e não anonimização, e dados pseudonimizados continuam dentro do escopo do GDPR.

Quanto tempo leva para uma regra de mascaramento recém-adicionada entrar em vigor?

No Clarity o número documentado é de até uma hora, e só para gravações novas. Regras do lado do cliente no rrweb, no Sentry, no PostHog e no LogRocket passam a valer no próximo carregamento de página que servir o script atualizado, então um bundle em cache ou um TTL de CDN longo estende a janela em que as regras antigas ainda valem.

Qual ferramenta de session replay mascara mais por padrão?

O Sentry tem o padrão mais rígido entre as ferramentas cobertas aqui: mascara todo o texto (maskAllText: true), mascara cada input e bloqueia toda a mídia (blockAllMedia: true). O rrweb fica no extremo oposto, mascarando por padrão apenas input[type="password"] enquanto nada mais for configurado. Escolher um fornecedor sem checar esses padrões é decidir o quanto fica exposto antes mesmo de escrever uma regra própria.

O PostHog mascara texto por padrão?

O PostHog não mascara texto por padrão. Ele mascara todos os inputs, já que maskAllInputs vem como true por padrão, mas os nós de texto são gravados como estão sem regras adicionais. A classe ph-no-capture permite tirar elementos específicos da gravação, que passam a aparecer como um bloco do mesmo tamanho.

Dá para mascarar SVGs inline ou folhas de estilo no session replay?

As regras de mascaramento se aplicam a nós de texto do DOM e a valores de input, então tudo fora desses dois lugares fica fora do alcance delas. O Clarity não mascara conteúdo dentro de folhas de estilo ou tags style, por isso recomenda não hospedar conteúdo sensível em CSS. O Hotjar observa que SVGs usados como origem de uma imagem podem ser suprimidos, mas SVGs inline não.

As regras de mascaramento devem ficar no código ou em uma tela de configuração?

O ideal é mantê-las no código. O FullStory chama a abordagem código primeiro de menos frágil do que gerenciar regras pela interface com seletores CSS, porque um seletor definido numa tela de configuração quebra silenciosamente assim que uma biblioteca de componentes muda os nomes das classes. Versionar as regras junto com a aplicação permite publicar e reverter uma mudança como qualquer outro código.