Como mascarar dados sensiveis durante o co-browse

O co-browse permite que um agente veja e oriente a tela do cliente em tempo real, mas esse mesmo poder cria um risco evidente: numeros de cartao, senhas ou dados de saude podem ficar expostos durante a sessao. Aprender a mascarar dados sensiveis durante o co-browse nao e um extra opcional, e o requisito que separa um recurso util de um problema de conformidade. Neste guia voce vera quais campos ocultar, como o mascaramento e configurado e quais praticas evitam vazamentos acidentais.

O que significa mascarar no co-browse

Mascarar significa que o conteudo de certos elementos da pagina nunca sai do navegador do cliente para o do agente. O agente ve a estrutura da pagina (o formulario, os botoes, o layout), mas o valor real do campo aparece substituido por asteriscos, um bloco cinza ou simplesmente vazio. O cliente digita normalmente; o agente o assiste sem chegar a ler o dado.

Isso e diferente de "cobrir" algo com uma camada visual. Um bom mascaramento acontece na origem: o dado e filtrado antes de ser transmitido, de modo que nem sequer trafega pela rede nem fica em registros ou gravacoes da sessao.

Quais campos voce deve sempre mascarar

Nem tudo e igualmente sensivel. Como ponto de partida, oculte por padrao:

• Dados de pagamento: numero do cartao, data de validade e CVV. O CVV nunca deve ser visto, nem parcialmente.
• Credenciais: senhas, PINs, tokens de uso unico e respostas de seguranca.
• Identificadores oficiais: numero de documento, CPF, passaporte.
• Dados de saude: diagnosticos, medicacoes, resultados de exames.
• Dados financeiros: saldos, numeros de conta completos, movimentacoes.

Uma regra util: se um campo nao e necessario para o agente ajudar voce, mascare-o. O agente nao precisa ver sua senha para orienta-lo ate a tela certa.

Como o mascaramento e configurado

Ha duas abordagens que vale a pena combinar.

1. Mascaramento por seletor

Voce define regras baseadas no HTML: por classe CSS, por atributo name, por tipo de input ou por um atributo dedicado como data-cobrowse-mask. E preciso e previsivel. Por exemplo, voce marca todo input[type=password] e todo elemento com a classe .sensitive para que fique sempre oculto.

2. Mascaramento por padrao

Como rede de seguranca, voce aplica regras que detectam formatos: sequencias que parecem cartoes (16 digitos), e-mails ou numeros longos. E menos exato, mas captura campos que voce esqueceu de etiquetar. Nao dependa dele sozinho, porque os falsos negativos custam caro.

O ideal e mascarar por padrao o critico e auditar cada tela nova antes de habilita-la para co-browse.

Boas praticas que evitam vazamentos

• Mascare desde o primeiro deploy, nao "depois". A divida de privacidade se paga com incidentes.
• Teste com dados ficticios realistas: preencha o formulario e confirme, do lado do agente, que nada e legivel.
• Registre e audite: guarde quem iniciou a sessao, quando e sobre quais paginas, mas nunca o conteudo mascarado.
• De controle ao cliente: que ele possa pausar o compartilhamento ou encerrar a sessao com um botao sempre visivel.
• Limite o alcance: co-browse restrito ao seu dominio impede que o agente veja outras abas ou o e-mail do cliente.

O equilibrio entre utilidade e privacidade

O erro comum e achar que mais visibilidade e sempre melhor. Na pratica, um co-browse bem mascarado costuma resolver igualmente rapido: o agente ve onde o cliente esta travado sem precisar do dado secreto. A confianca de saber que "o CVV nao aparece" reduz o abandono em etapas criticas como o pagamento.

Em plataformas omnicanal como o Omnifox, o co-browse foi pensado para nascer de uma conversa existente e com mascaramento configuravel de campos sensiveis, de modo que o agente assiste dentro do seu proprio dominio sem expor dados de pagamento nem credenciais. Assim o recurso se integra a caixa de entrada, ao CRM e ao historico do cliente sem abrir uma brecha de privacidade.

Checklist rapido

1. Identifique cada campo sensivel por tela.
2. Mascare por seletor o critico e adicione padroes como reforco.
3. Verifique, do lado do agente, que o valor nao e transmitido.
4. Restrinja o co-browse ao seu dominio.
5. De ao cliente um botao visivel para pausar ou encerrar.
6. Audite acessos sem registrar conteudo.

Mascaramento e gravacao de sessoes

Muitas empresas gravam as sessoes de suporte para treinamento ou auditoria. Aqui o mascaramento e duplamente importante: se o dado e filtrado na origem, tambem nao aparecera na gravacao. Confirme que sua ferramenta mascara ANTES de capturar, nao depois. Uma gravacao com um CVV visivel e um vazamento que fica arquivado.

Algumas recomendacoes:

• Grave apenas se tiver uma base legal clara e informe o cliente.
• Aplique retencao limitada: apague as gravacoes quando nao precisar mais.
• Restrinja quem pode reproduzi-las.

Mitos frequentes

"Se o agente promete nao olhar, basta." Nao. A protecao deve ser tecnica, nao uma promessa. "Mascarar quebra a experiencia." Pelo contrario: o cliente digita normal e o agente ve o contexto. "So o pagamento precisa de protecao." Falso: credenciais, saude e identificadores oficiais sao igualmente criticos. A regra e simples: mascare por padrao e exponha apenas o necessario.

Conclusao

Mascarar dados sensiveis durante o co-browse e o que transforma um recurso de suporte visual em uma ferramenta segura e confiavel. Com regras por seletor, padroes de reforco e controle do cliente, voce oferece assistencia em tempo real sem comprometer a privacidade. Se quer implementar co-browse com mascaramento desde o primeiro dia, dentro de uma caixa omnicanal, experimente o Omnifox e configure a protecao antes da sua primeira sessao.