E-Mail-Adressen per SVG schützen statt mit JavaScript

 (rouninmedia.github.io)
4 Punkte von GN⁺ 2024-05-14 | 1 Kommentare | Auf WhatsApp teilen
  • Eine Methode, um öffentliche E-Mail-Adressen vor der Erfassung durch Spambots zu verbergen und Besucher trotzdem direkt Kontakt aufnehmen zu lassen: E-Mail-Text und mailto:-Link werden innerhalb eines SVG platziert
  • JavaScript-basierter Schutz kann ausgefeilter sein, aber es ist nachteilig, wenn die Kontaktfunktion selbst eine JS-Abhängigkeit hat
  • Dieser Ansatz bindet ein externes SVG-Dokument per HTML-ein; der eigentliche Link liegt nicht im HTML, sondern in einem-Element innerhalb des SVG
  • SVG wirkt wie ein Bild und verbirgt den Inhalt dadurch teilweise, verwendet aber dennoch ein ``-Element, sodass Besucher die E-Mail-Adresse kopieren können
  • Es ist keine Lösung gegen ausgefeilte Spambots, hilft aber, das Risiko zu verringern, einfachen E-Mail-Harvesting-Skripten ausgesetzt zu sein

E-Mail-Adressen per SVG verbergen

  • Öffentliche E-Mail-Adressen sind leicht für E-Mail-Harvesting-Spambots sichtbar und benötigen daher Schutzmaßnahmen
  • Gängige Schutztechniken kombinieren HTML, CSS und JavaScript; der Einsatz von JavaScript bindet die Kontaktfunktion jedoch an eine zwingend notwendige Laufzeitumgebung der Seite
  • Der SVG-Ansatz übernimmt Anzeige der E-Mail-Adresse und Link-Verhalten ganz ohne JavaScript
  • Auch wenn JavaScript deaktiviert ist, können Besucher die auf der Seite angezeigte E-Mail-Adresse verwenden; für Spambots ist sie weniger direkt sichtbar als normaler HTML-Text
  • Wie andere Frontend-basierte Schutztechniken schützt auch diese öffentliche E-Mail-Adressen nicht vollständig vor hartnäckigen und ausgefeilten Spambots
  • Live-Demo: SVG-based Email Protection

Umsetzung in HTML und SVG

  • Das HTML-Dokument bindet eine externe SVG-Datei per `` ein
  • Dasselbe SVG-Grafikdokument kann ein- oder mehrfach in HTML eingebunden werden
  • Das Beispiel-HTML setzt für die Klasse .svg-email-protection die Styles width: 180px, height: 24px und vertical-align: middle und lädt die SVG-Datei im Body per ``
  • Die SVG-Datei ist ein ``-Dokument mit viewBox="0 0 200 24" und enthält intern den E-Mail-Text sowie den Link mailto:myemail@mydomain.tld
    • In befinden sich und ``
    • In `` wird myemail@mydomain.tld angezeigt
    • Bei rect:hover und a:focus ändern sich Hintergrundfarbe, Textfarbe, Schriftstärke, Unterstreichung und Schattenstil

Barrierefreiheit und Referenzen

  • Das gesamte SVG-Dokument verwendet aria-labelledby, das auf verweist; das innerhalb des SVG enthält außerdem ein aria-label mit derselben Call-to-Action
  • Wenn der Tastatur-Tab-Fokus den Anker innerhalb des SVG erreicht, werden und gemeinsam hervorgehoben und machen so den Fokuszustand sichtbar
  • Zugehörige Materialien:

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-05-14
Hacker-News-Kommentare

  • Wirklich? Ich bin skeptisch.

    • Doch. Anfang der 2000er nahm Spam tatsächlich zu, wenn man eine E-Mail-Adresse ins Web stellte, und Techniken zur Obfuskation von E-Mail-Adressen halfen damals durchaus, soweit ich mich erinnere.
      Persönlich habe ich aber seit etwa 2015 überhaupt keinen Unterschied mehr bemerkt, nicht einmal mehr zusätzlichen Spam zum Herausfiltern.
      Heute kann man riesige E-Mail-Listen kaufen, die aus von Firmen verkauften Nutzerlisten oder aus Server-Leaks stammen, daher ist das Einsammeln von Adressen durch Web-Crawling fast die ineffizienteste denkbare Methode zum Spamversand.
    • Ich habe im letzten Jahr auf den Footern von zwei Websites meine E-Mail-Adresse im Klartext veröffentlicht, und auf beiden ist bisher nicht eine einzige Spam-Mail angekommen.
      Beide Seiten haben Tausende Besucher und werden von Suchmaschinen und AI-Bots gecrawlt.
    • Genau mein Eindruck. Umgekehrt bekommen die E-Mail-Adressen, die ich etwa 1999 bis 2001 bei Usenet verwendet habe, bis heute konstant Spam.
      An die auf Websites veröffentlichten Adressen kommt nicht einmal etwas, das im Spam-Ordner landet.
      Einige Mailinglisten scheinen Gmail-Adressen eher per Wörterbuchangriff zu erraten, etwa im Format FIRSTNAME.LASTNAME oder als Kombinationen aus 1 bis 10 Zeichen.
      Trotzdem bekomme ich auf die Adresse domain@domain.com nur etwa eine Spam-Mail pro Jahr, also sehr wenig.
      Insgesamt ist auch das Spam-Aufkommen stark zurückgegangen, und der heutige Spam wirkt wie eine Mischung aus 419-Betrügern und angehenden Betrügern, die auf 20 Jahre alten E-Mail-Listen hereingefallen sind.
    • E-Mail-Obfuskation wirkt auf mich wie ein Relikt aus der Vergangenheit. Methodisch war das nie wirklich solide, hat sich aber trotzdem verbreitet und als eine Art Cargo-Kult überlebt.
    • Auch wenn ich Spam nicht direkt sehe, ist mir persönlich lieber, wenn meine E-Mail-Adresse nach Möglichkeit nicht eingesammelt wird.
      Ich würde das nicht als ernstes Datenschutz- oder Sicherheitsproblem bezeichnen, es ist eher eine Präferenz.

  • Meine Domain ist eine seit 24 Jahren registrierte .com, und meine E-Mail-Adresse steht im H3 ganz oben auf der Startseite.
    Der Spam auf diese Adresse ist kein Problem. Selbst inklusive Junk-Ordner sind es etwa 15 pro Tag, und dank Purelymail ist das in Ordnung.
    Das eigentliche Problem sind transaktionale Mails ohne Bezug zu irgendeinem Geschäft, newsletterartige Werbemails und soziale Netzwerke, die mich ständig darauf hinweisen, dass ich sie nicht benutze.

    • 15 Spam-Mails pro Tag klingt schon nach ziemlich viel. Ich glaube, ich hätte die Adresse schon bei weniger aufgegeben.
    • Die „sozialen Netzwerke, die sich darüber beschweren, dass man sie nicht benutzt“, sind der größte Brocken. Facebook schickt mir fast mehr Mails mit der Bitte, mich einzuloggen, als anderer Spam.
      Ich habe den Account seit etwa sieben Jahren nicht mehr benutzt, das müsste ihnen inzwischen doch aufgefallen sein.
    • Ich habe ein paar alte Domains, die ich Ende der 90er registriert habe, und auf einigen steht meine E-Mail noch immer per mailto.
      Manche davon bekommen fast keinen Spam, andere Dutzende Nachrichten pro Tag. SpamAssassin filtert den Spam dabei sehr gut weg.

  • Entgegen der Aussage „Auch wenn Besucher JavaScript deaktiviert haben, können sie die auf der Seite angezeigte E-Mail-Adresse weiterhin verwenden“ funktioniert diese Technik mit den Standardeinstellungen von NoScript in Firefox nicht, weil dort der Tag nicht gerendert, sondern durch einen Platzhalter ersetzt wird.
    https://imgur.com/2tCAgAf

    • Mit uBlock Origin kann man JavaScript ebenfalls blockieren. Im Erweiterungsmenü gibt es dafür einen praktischen Button.
    • Das ist aber ein anderes Thema, daher verstehe ich nicht ganz, warum du diesen Punkt aufbringst.
    • In Chromium ist es genauso.

  • Es gibt keinen Grund, warum diese Technik an sich nicht barrierefrei sein könnte, aber das im Artikel gezeigte Beispiel ist wirklich schlecht.
    Dort werden svg und a mit „Email us!“ beschriftet, wodurch die eigentliche E-Mail-Adresse für Screenreader verborgen bleibt.
    Diese Art der Verwendung von aria-Labels ist eine sehr schlechte Praxis. Nutzer von Screenreadern sollten grundsätzlich dieselbe Erfahrung haben wie alle anderen, es sei denn, es gibt einen sehr besonderen Grund dafür, und wenn man glaubt, so ein Grund liege vor, liegt man meist falsch.
    Korrekt wäre es, im Label die tatsächliche E-Mail-Adresse anzugeben.

    • Geht es bei der ganzen Sache nicht gerade darum, die E-Mail-Adresse nicht in einem maschinenlesbaren Format in das Dokument einzubauen?
    • Das könnte sich auch auf Sprachdiktat-Software wie Dragon auswirken.
      Wenn ein Nutzer „Click myemail@mydomain.tld“ sagt, wird der Link womöglich nicht aktiviert, weil der Browser den Linktext als „Email us“ ausgibt.
      Ich weiß allerdings nicht, ob Dragon überhaupt Links in SVG aktivieren kann.

  • Ich mache es so: reanospaml@maisjsl.com
    Trotzdem bekomme ich „Spam“, aber eher passgenaue B2B-Angebote zum Thema der Website, also vermutlich manuell von Menschen gesammelt.

    • Wenn der Scraper einen Headless-Browser verwendet, lässt sich diese Methode vermutlich umgehen.
      Allerdings ist es vergleichsweise teuer, für das Sammeln von E-Mail-Adressen Headless-Browser einzusetzen, daher muss dieser Spam nicht unbedingt von der Website stammen.

  • Wie andere schon gesagt haben, ist das „Schützen“ von E-Mail-Adressen nicht nur sinnlos, sondern teilweise sogar schädlich.
    Die meisten Inhalte lassen sich ohne JavaScript problemlos lesen, aber es gibt einige Websites, auf denen dann Zeichenfolgen wie „1920x1080@60Hz“ wörtlich als „[email protected]“ angezeigt werden.

    • Gibt es dafür ein direkt sichtbares Beispiel? Klingt so absurd, dass ich das noch nie gesehen habe.

  • Ich bezweifle, dass das überhaupt einen echten Zweck erfüllt. Als interessantes Experiment taugt es, aber wenn es darum geht, Spammern aus dem Weg zu gehen, ist es reine Zeitverschwendung.
    Man veröffentlicht Informationen weltweit und hofft irgendwie trotzdem, dass nur „gute Leute“ darauf zugreifen können.
    Wenn man die E-Mail-Adresse nicht mindestens monatlich wechselt, reicht es völlig, dass jemand die Kontaktdaten weitergibt, in eine Datenbank oder ein CRM einträgt oder ein Dienst kompromittiert wird, und schon landet die Adresse auf Listen und verbreitet sich letztlich unter Spammern weltweit.
    Wenn man diese E-Mail regelmäßig nutzt, liegt die Wahrscheinlichkeit dafür faktisch bei nahezu 100 %.
    Wäre das Verstecken vor Scrapern wirklich wirksam, gäbe es keinen Spam. Ich habe meine private Kontaktadresse nie irgendwo öffentlich gemacht und bekomme trotzdem Dutzende Spam-Mails pro Woche, die aber alle zuverlässig als Spam gefiltert werden, also ist das kein großes Problem.

  • Ein Freund von mir ist wirklich ziemlich fit und baut mit JavaScript in SVG im Grunde responsive Bilder.
    Sie passen sich programmatisch an die Größe an, was ziemlich interessant ist.
    Allein die Tatsache, dass man JavaScript in SVG einbetten kann, wirkt auf mich immer noch wenig genutzt und zugleich etwas riskant.

    • Ist SVG nicht von Haus aus responsive? Ich verstehe nicht ganz, wobei JavaScript innerhalb von SVG helfen soll.
    • Sehr interessant. Falls dein Freund ein GitHub-Repo oder eine Website hat, auf der er das zeigt, könntest du einen Link posten?
      Ich bin Backend-Ingenieur, also technisch ziemlich weit von diesem Gebiet entfernt, aber es sieht wirklich cool aus.
    • Das ist in der Security-Community schon seit ziemlich langer Zeit bekannt.

  • Ich habe solche Methoden aufgegeben. Spamfilter sind inzwischen gut genug, dass die Veröffentlichung einer E-Mail-Adresse ohne Obfuskation den Spam bei mir anscheinend nicht erhöht.
    Eine andere Quelle von Spam sind miserable Unternehmen, die meine E-Mail aus legitimen Gründen haben und sie offenbar an Dritte verkaufen.
    Im Allgemeinen landet in meinem Posteingang weniger als eine Spam-Mail pro Tag, und damit kann ich leben.
    Natürlich kann das je nach E-Mail-Anbieter und Spamfilter unterschiedlich sein, aber für mich war es kein Problem.

  • Die E-Mail steht weiterhin im Klartext in einem XML-Dokument, auf das im Seitenquelltext verwiesen wird.

    • Wenn man aber mit document.querySelectorAll('a') oder ähnlich darauf zugreift, ist das etwas anderes. Viele Scraping-Techniken arbeiten genau so, daher ist das als erste Verteidigungslinie durchaus okay.
      Es gibt allerdings Headless-Browser für Scraping, und man könnte auf der Seite einfach die aktuelle URL per fetch laden, den Klartext abrufen und dann mit einem Regex nach E-Mail-Adressen suchen. Zugegeben, das ist ein ziemlich merkwürdiger Ansatz.
      [0]: fetch('./').then((res) => res.text()).then((text) => console.log(text))
    • Die Idee ist, dass Spam-Bots nicht extra SVG parsen, um darin E-Mail-Adressen zu finden, sondern nur das HTML der Seite ansehen.
      Wie wirksam das in einer modernen Anti-Spam-Umgebung tatsächlich noch ist, weiß ich allerdings nicht.
    • Wirkt wie etwas Nutzloses, das als clever verkauft wird.