Estrutura XML

O SVG se destaca de todos os outros formatos deste site porque não é binário: é apenas texto XML. Você pode abrir um SVG em um editor de texto e ler tudo. Isso torna a remoção de metadados mais simples em teoria, mas também significa que há mais lugares onde uma informação pode se esconder.

Os metadados podem aparecer como elementos dedicados, como atributos de qualquer elemento, como comentários XML ou como instruções de processamento. Os editores vetoriais adoram enfiar seus próprios dados nos arquivos SVG.

Estrutura básica de um SVG

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg"
     xmlns:xlink="http://www.w3.org/1999/xlink"
     width="100" height="100" viewBox="0 0 100 100">

  <!-- Elementos de metadados -->
  <title>My Drawing</title>
  <desc>Created by John Doe</desc>
  <metadata>
    <rdf:RDF xmlns:rdf="...">
      <!-- Metadados RDF/Dublin Core -->
    </rdf:RDF>
  </metadata>

  <!-- Conteúdo vetorial -->
  <circle cx="50" cy="50" r="40" fill="red"/>
</svg>

Elementos principais

<svg>:elemento raiz, com o viewBox e as dimensões
xmlns:declarações de namespace
<defs>:definições reutilizáveis (gradientes, padrões)
<g>:elemento de agrupamento

Elementos de metadados

A especificação do SVG define várias formas de anexar metadados, e cada ferramenta usa uma abordagem. Algumas são óbvias (existe literalmente um elemento <metadata>), outras são mais sutis.

<metadata>

Contêiner de metadados estruturados, normalmente RDF/Dublin Core. Pode conter o nome do criador, a data de criação, os direitos e mais.

<metadata>
  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
           xmlns:dc="http://purl.org/dc/elements/1.1/">
    <rdf:Description>
      <dc:creator>John Doe</dc:creator>
      <dc:date>2024-01-15</dc:date>
    </rdf:Description>
  </rdf:RDF>
</metadata>

<title>

Título legível do SVG ou de elementos específicos. Muito usado para acessibilidade, mas pode revelar a finalidade do documento.

<desc>

Elemento de descrição. Pode conter informações detalhadas sobre a imagem, o criador ou a finalidade do arquivo.

Comentários XML

 pode conter anotações do autor, datas de criação, informações do software ou dados de depuração.

Namespaces de editores

É aqui que o SVG vira uma bagunça. Todo editor vetorial acrescenta seus próprios atributos com namespace para guardar recursos que o SVG não suporta nativamente. Abra um arquivo do Inkscape e você vai ver atributos inkscape: e sodipodi: por toda parte. Eles não são um risco de privacidade em si, mas identificam qual software você usa.

inkscape:* / sodipodi:*

O Inkscape acrescenta atributos com namespace para nomes de camadas, posições de guias, configurações do documento e histórico de edição.

<svg xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
     xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
     inkscape:version="1.2"
     sodipodi:docname="my-drawing.svg">
  <sodipodi:namedview inkscape:current-layer="layer1"/>
</svg>

Adobe Illustrator

O Illustrator embute metadados extensos, incluindo a versão, as configurações das pranchetas e, às vezes, dados completos do formato AI.

xmlns:i="http://ns.adobe.com/AdobeIllustrator/10.0/"
xmlns:x="http://ns.adobe.com/Extensibility/1.0/"

Sketch / Figma

As ferramentas de design modernas podem embutir nomes de camadas, IDs de componentes e configurações de exportação em atributos personalizados.

Instruções de processamento

As instruções de processamento XML (<?...?>) no começo dos arquivos SVG podem identificar o software usado.

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="style.css"?>
<!-- Criado com o Inkscape (http://www.inkscape.org/) -->

Preservado x removido

• declaração <?xml ...?>:preservada (obrigatória)
• <?xml-stylesheet ...?>:preservada (funcional)
• demais instruções de processamento:removidas

Processamento baseado em DOM

Como o SVG é XML válido, podemos analisá-lo em uma árvore DOM e remover cirurgicamente o que não queremos. Isso é mais preciso do que abordagens baseadas em regex e não corre o risco de quebrar conteúdo válido por acidente.

Analisar o XML

Interpretar o SVG como documento XML, preservando a estrutura

Remover os elementos de metadados

Excluir os elementos <metadata>, <title> e <desc>

Eliminar os atributos dos editores

Remover inkscape:*, sodipodi:* e outros namespaces de editores

Remover os comentários

Eliminar todos os comentários XML do documento

Limpar os namespaces

Remover as declarações de namespace não utilizadas do elemento raiz

Serializar

Gravar o XML limpo de volta como arquivo SVG

Resumo do processamento

Preservado

• Todos os gráficos vetoriais (paths, formas, texto)
• Estilos e CSS
• Gradientes e padrões
• Filtros e efeitos
• Imagens embutidas (referenciadas)
• viewBox e dimensões
• Namespaces padrão do SVG

Removido

• Elemento <metadata>
• Elemento <title>
• Elemento <desc>
• Comentários XML
• Atributos inkscape:*
• Atributos sodipodi:*
• Namespaces da Adobe e do Sketch
• Declarações de namespace não utilizadas

Imagens embutidas

Aqui vai uma pegadinha que pega muita gente de surpresa: os arquivos SVG podem embutir imagens raster como data URIs em base64. Esses JPEGs ou PNGs embutidos podem ter metadados EXIF próprios escondidos lá dentro.

Limitação atual

Por enquanto, o PicScrub remove os metadados no nível do SVG, mas não decodifica nem processa as imagens raster embutidas:

<image href="data:image/jpeg;base64,/9j/4AAQ..." />

O PicScrub ainda não processa as imagens raster embutidas nos arquivos SVG. Para uma privacidade completa, extraia e processe essas imagens separadamente.

Formato SVG