Google Lighthouse: Wegweiser für schnelle Websites

Vor Kurzem hat Google bekanntgegeben, auch in den mobilen Suchresultaten die Geschwindigkeit einer Website zu einem Ranking-Faktor zu machen. Für Desktop-Suchen ist das bereits seit 2010 der Fall, an und für sich also nichts Neues aus dem Hause Google. Und wie auch schon 2010 stellt die Ankündigung die Suchmaschinen-Welt nicht auf den Kopf. Website-Betreiber können also weiterhin nicht erwarten, nur aufgrund einer schnellen Webpräsenz auf den vorderen Rängen in den Suchmaschinenresultaten zu landen.

Nichtsdestotrotz ist mit der neusten Ankündigung aber wieder einmal klar definiert worden: Speed ist wichtig. Aber wie prüfe ich überhaupt, ob meine Website schnell ist? Dazu liefert Google, nebst dem altbekannten (und mit Vorsicht zu geniessenden) PageSpeed Insights, seit einer Weile ein weiteres praktisches Tool: Lighthouse.

Google Lighthouse: Wegweiser für schnelle Websites

Was ist Google Lighthouse?

Ursprünglich als Audit-Werkzeug für sogenannte «Progressive Web Apps» (PWA) entwickelt, lassen sich mit Lighthouse auch «herkömmliche» Websites (wenn man denn überhaupt von so etwas sprechen kann) auf Herz und Nieren prüfen. Die Checks sind mit der aktuellen Version in 5 Gruppen unterteilt: «Progressive Web App», «Performance», «Accessibility», «Best Practices» und «SEO». Die Namen der Gruppierungen verraten denn auch schon, welche Tests sie beinhalten.

Wie gut ist meine Progressive Web App?

So wird die aufgerufene URL in der Gruppe «Progressive Web App» nach Merkmalen geprüft, die eine gute «Progressive Web App» oder eben PWA ausmachen: Meldet die Website einen Service Worker an? Funktioniert die Website auch ohne Internetverbindung? Oder ist die Website für einen Splash-Screen konfiguriert?

Wer seine Website nicht als PWA konzipiert, kann auf den Progressive-Web-App-Check getrost verzichten. Die einzelnen Checks lassen sich dazu je nach Bedarf ein- und ausschalten.

Performance: Der heilige Gral der Website-Tests

In der Gruppe «Performance» werden zurzeit 5 Merkmale geprüft, die eine objektive Aussage darüber machen, wie gut die geprüfte Website im Browser des Besuchers performt. Wer mit seiner Website in dieser Kategorie einen Wert über 75 erhält das Prädikat «Gut». Die Performance-Gruppe setzt sich aus den folgenden 5 Kennzahlen zusammen:

  • First meaningful paint
    Misst die Zeit, bis der Hauptinhalt der aufgerufenen Seite sichtbar ist.
  • First interactive
    Misst die Zeit, bis der Besucher zum ersten Mal mit der aufgerufenen Seite interagieren kann.
  • Consistently interactive
    Misst die Zeit, bis der Besucher vollständig mit der aufgerufenen Seite interagieren kann.
  • Perceptual speed index
    Misst die Zeit, wie schnell die Inhaltselemente der Seite sichtbar mit den Inhalten befüllt sind. Das Konzept Speed Index stammt von den Machern von webpagetest.org und wurde dort 2012 eingeführt.
  • Estimated input latency
    Schätzt die Zeit, bis die aufgerufene Seite auf eine Eingabe des Besuchers (Mausklick, Tastendruck, Tap, etc.) reagiert. Ab mehr als 50ms Reaktionszeit kann die Website vom Besucher als träge wahrgenommen werden.

Die Tests aus der Gruppe «Performance» sollten Sie unbedingt genauer unter die Lupe nehmen. Hier schlummert gegebenenfalls riesiges Potenzial, das Ihre Website verschenkt. Und das wirkt sich direkt auf die Nutzung Ihrer Website aus.

Accessibility: Geprüft barrierefrei

In der Gruppe Accessibility wird die Barrierefreiheit der geprüften Website analysiert. Im Gegensatz zur Gruppe Performance können die Accessibility-Tests entweder bestanden oder nicht bestanden werden. Die zurzeit 35 Prüfungen werden gewichtet und aus den Ergebnissen wird ein Durchschnitt berechnet.

Best Practices: Das sollten moderne Websites können

In der Gruppe Best Practices werden zurzeit 16 Tests durchgeführt, wobei wie in der Gruppe Accessibility ein Test entweder bestanden oder nicht bestanden ist. Im Gegensatz zu Accessibility sind die Tests nicht gewichtet und beinhalten Fragen wie «Wird HTTP/2 verwendet?», «wird HTTPS verwendet?» oder «ist Copy & Paste in Passwortfeldern möglich?».

SEO: So wird Ihre Website sicher gefunden

Erst seit Kurzem beinhaltet Lighthouse auch Checks, die eine Website auf deren Suchmaschinenfreundlichkeit prüfen. Zurzeit sind Tests noch sehr rudimentär, dürften sich in Zukunft aber noch weiterentwickeln. Falls die geprüfte Website in der Gruppe SEO keine volle Punktzahl erreicht, sollten Sie als Website-Betreiber dringend handeln. Die SEO-Checks prüfen Merkmale, die auf keiner Website fehlen dürfen.

Beispiel-Report Google Lighthouse

So schneidet die Website pwa.rocks im Lighthouse-Test ab.

Wie nutze ich Lighthouse?

Google Lighthouse lässt sich auf verschiedene Arten nutzen. Allen Arten ist gemein, dass auf dem entsprechenden Rechner Google Chrome installiert sein muss. Die einfachste Variante ist der Weg über die sogenannten DevTools. Dort steht Lighthouse unter dem Tab «Audits» zur Verfügung.

Wer die immer neuste Version von Lighthouse nutzen möchte, installiert am besten das entsprechende Chrome-Plugin. So ist zum Beispiel die Testgruppe SEO vorerst nur im Plugin verfügbar und wird den Weg in die DevTools finden, sobald die Entwickler die Funktion auf «die grosse Masse» loslassen möchten.

Nebst den Audits direkt im Browser kann Lighthouse auch auf der Kommandozeile und damit programmatisch, zum Beispiel in Build-Tools, genutzt werden. Lighthouse steht dazu als Node-Modul zum Download.

Ein Drama in 7 Akten. Oder wie uns unser zentraler Datenspeicher die letzten Wochen auf Trab gehalten hat.

Ende November 2017 erreichten wir einen Meilenstein: Wir haben unseren zentralen Datenspeicher und damit alle Websites unserer Kunden auf superschnelle SSD umgestellt. Die Benchmarks waren fantastisch. Die Kunden überglücklich. Wir auch.

Kurz nach dem Jahreswechsel standen dann ein paar Updates unseres Datenspeichers auf dem Programm. Guter Dinge haben wir also losgelegt. Doch da tauchte wie aus dem Nichts ein Problem auf: Die Performance unseres Datenspeichers war plötzlich im Keller.

Erste Kunden haben sich bei uns gemeldet. Wir waren ahnungslos. Und ziemlich frustriert.

Vor wenigen Tagen (bzw. Nächten) dann die grosse Erlösung: Wir haben das Problem gefunden. Die volle Performance ist zurück. Entsprechend gross die Erleichterung. Doch was war das Problem?

In diesem Blogpost nehmen wir Sie mit auf eine Reise hinter die Kulissen und in die Tiefen eines zentralen Datenspeichers. Und möglicherweise hilft dieser Beitrag irgendwann und irgendwo einem anderen verzweifelten Ceph-Administrator.

Problemsuche im Datenspeicher. Ein Drama in 7 Akten.

Die Ausgangslage: Ein Update steht an

Ein zentraler Datenspeicher besteht aus zwei Komponenten:

  1. Der Hardware: Also aus den eigentlichen Festplatten. Diese Festplatten sind in Server eingebaut, was bei uns dann ungefähr so aussieht:

  2. Der Software, welche die Hardware steuert. In unserem Fall ist das Ceph.

Für Ceph werden regelmässig neue Versionen veröffentlicht, welche Fehler beheben und neue Funktionen bringen. So gehört es also zu den Routineaufgaben eines Ceph-Administators, alle paar Monate ein solches Update einzuspielen.

Am 2. Januar 2018 haben wir mit den vorbereitenden Arbeiten begonnen:

  • Wir haben das Betriebssystem aller Ceph-Nodes von RHEL 7.3 auf RHEL 7.4 aktualisiert – damit einher gehen viele Treiber-Updates, ein neuer Kernel etc.
  • Selbiges haben wir auf den sogenannten Hypervisors gemacht, also unseren Servern, die wiederum die (virtuellen) Kundenserver beherbergen.
  • Zeitgleich wurden die Sicherheitslücken Meltdown und Spectre bekannt und wir haben flottenweit Patches eingespielt.
  • Während den Updates wurde uns ein Bug bekannt: Sind HDDs und SSDs in einem Server (in diesem Kontext auch Node genannt) gemischt, können Daten, die aus Gründen der Redundanz zwingend auf verschiedener Hardware abgelegt werden müssten, auf dem gleichen Node gespeichert werden. Fällt ein Node aus (z.B. bei einem Neustart nach einem Kernel-Update), schaltet Ceph die davon betroffenen Daten in den Nur-Lesen-Modus, weil die Konsistenz der Daten nicht mehr gewährleistet werden kann.
    Unseren Kundenservern gefällt das natürlich gar nicht, wenn sie plötzlich nicht mehr Daten schreiben können. Die vorläufige Lösung für das Problem: Von drei Kopien auf vier Kopien erhöhen. So konnten wir sicherstellen, dass immer ausreichend Kopien aller Daten auf unterschiedlicher Hardware gespeichert ist.
  • Am 8. Januar dann haben wir mit dem eigentlichen Update der Ceph-Software begonnen. Das Update wird Stück für Stück ausgerollt und tangiert mehrere Stellen: Sowohl die Nodes wie auch die Kundenserver.

Und während all diesen Updates merken wir: Die Performance ist nicht mehr, wie sie sein soll.

Die Performance bricht ein. Was ist nun schuld?

Das Problem: Wir haben in der Vorbereitung mindestens fünf umfangreiche Änderungen in relativ kurzer Zeit vollzogen, was die Fehlersuche entsprechend schwierig gestaltete.

Mit vereinten Kräften, Beihilfe des Herstellers Red Hat und in unzähligen, zusätzlichen Nachtschichten haben wir uns akribisch vorgearbeitet. Dabei galt es nach dem Ausschlussverfahren herauszufinden, an welcher Stelle es genau klemmt. War es das Update des Betriebssystems? Die vierte Kopie? Das eigentliche Update von Ceph? Eine Konfigurationseinstellung in Ceph, die nicht (mehr) ideal ist?

Um jeweils einen Vergleich zu haben, führten wir vor und nach jeder gemachten Änderung Benchmarks durch. So auch am 30. Januar, als ein paar Änderungen an den Kerneleinstellungen vorgenommen wurden.

Zwei anschliessend ausgeführte Benchmarks im Abstand von ungefähr 30 Sekunden zeigten etwas Auffälliges: Die Ergebnisse lagen um Faktor 10 massiv weit auseinander.

Was schwankt hier so?

Das liess aufhorchen: Eine solche Diskrepanz innert so kurzer Zeit und bei etwa gleichzeitiger Auslastung war mehr als auffällig.

Ebenfalls interessant: Auf einigen Festplatten traten sogenannte Slow Requests auf – also Anfragen an die Festplatten, die über 30 Sekunden benötigen, um beantwortet zu werden. Das war jenseits von gut und böse und im Normalbetrieb absolut nicht erklärbar.

Ein Blick auf die Auslastung einer einzelnen Festplatte zeigte während des Auftreten der Slow Requests auch einen plötzlichen Sprung:

Disk-Auslastung SSD

Das muss soweit nicht aussergewöhnlich sein: Es ist durchaus denkbar, dass eine Festplatte plötzlich mehr zu tun hat und etwas abarbeiten muss.

Nur: Die Festplatte hatte während dieser Zeit gar nicht mehr Arbeit zu erledigen:

Input/Output Operations Per Second SSD

Die Anzahl Schreib- und Leseoperationen der Festplatte war in etwa konstant – ein plötzlicher Anstieg liess sich nirgends erkennen. Wie also konnte die Auslastung der Disk steigen, obwohl die anfallende Arbeit unverändert war?

In der Latenz, also der Reaktionszeit der Festplatte, war der Ausschlag dann wieder deutlich sichtbar:

Reaktionszeit SSD

Ein erstes Muster lässt sich erkennen

Das Spiel ging weiter. Betrachtete man die Auslastung der Festplatte über einen grösseren Zeitraum, zeigte sich dieses Bild:

Disk-Auslastung grösserer Zeitraum

Was auffiel: Die Sprünge in der Auslastung erfolgten mit verdächtiger Regelmässigkeit. Und das auf allen Festplatten in einem Node gleichzeitig. Dann wurde es ganz verrückt: Die Sprünge in der Auslastung waren nicht nur auf den Festplatten zu sehen, die in den zentralen Datenspeicher integriert sind, sondern auch auf den Festplatten, auf welchen das Betriebssystem der Nodes abgelegt ist und welche mit dem Rest überhaupt nichts am Hut haben.

Die heisse Spur: Ceph ist unschuldig

An dieser Stelle wurde klar: Das Problem hat gar nicht direkt mit Ceph zu tun.

Ein Blick zurück verriet dann auch, ab wann diese seltsamen Lastspitzen auftreten:

Disk-Auslastung 15.12.2017

Am 15. Dezember. Da war doch unsere Weihnachtsfeier. Und ein Freitag. Auch ein Blick in unser internes Änderungsprotokoll zeigte nichts Verdächtiges:

Internes Changelog

Dann noch einen Blick in den internen Chat. Die brennende Frage: Was ist am 15. Dezember geschehen? Und da. In der Historie tauchte dieser Code-Schnipsel auf:

Slack-Nachricht

Die Puppen tanzen

Wir verwenden für das Management unserer Server das Tool Puppet. Alle 30 Minuten prüft Puppet die Konfiguration eines Servers und rollt ggf. Änderungen aus.

Für Puppet gibt es ein kleines Helferlein namens Facter, dass vor einem sogenannten Puppet-Run Informationen aufbereitet, die dann anschliessend von Puppet genutzt werden können. Solche Informationen können z.B. der verfügbare Arbeitsspeicher oder der verwendete Prozessor sein.

Und das Helferlein lässt sich auch erweitern. So ist es für uns z.B. wichtig, in einem Node die sogenannten Festplatten-IDs zu kennen. Damit können wir beispielsweise das Status-Lämpchen einer bestimmten Festplatte blinken lassen. Ist eine Festplatte defekt und muss ersetzt werden, lassen wir das Lämpchen blinken und der Mitarbeiter vor Ort hat eine zusätzliche Kontrolle, sicher die richtige Disk in den Fingern zu haben.

Jetzt taute es: Am 15. Dezember hatten wir das Tool «Facter» erweitert, damit es für uns fortan auch die Festplatten-IDs einsammelt. Eine winzige und unscheinbare Änderung, möchte man meinen.

Aber jetzt war der Fehler gefunden: Das Auslesen dieser Festplatten-Informationen führte dazu, dass alle Disks fehlerhafterweise für ungefähr 5 Sekunden nicht mehr reagieren. Das Auslesen geschieht über den RAID-Controller und, wie sich herausstellte, ist dieses Fehlverhalten ein Bug des RAID-Controllers. Ein Update der RAID-Controller-Firmware behebt das Problem.

Was also ist genau passiert? Aktuell haben wir 34 Nodes in Betrieb. Wenn alle 30 Minuten Puppet bzw. Facter durchläuft, gerät durchschnittlich etwa alle 53 Sekunden ein einzelner Node für etwa 5 Sekunden ins Stocken.

Das gibt dann über den ganzen Datenspeicher gesehen (und Daten werden immer über den ganzen Datenspeicher verteilt) ca. 48 Sekunden Normalbetrieb, dann wieder 5 Sekunden stockender Betrieb und so weiter. Womit auch die unterschiedlichen Benchmark-Ergebnisse erklärt wären.

Die grosse Erlösung

Flink wurde also das Einsammeln der Disk-Informationen vorläufig abgeschaltet und voilà: Ein Blick auf einen Server zeigte Folgendes:

CPU-Auslastung eines Servers

Die Kurve ist wieder, wie sie sein soll: flach.
Man sieht hier den sogenannten I/O-Wait, also die Zeit, welche ein Prozess auf dem Server auf Antwort des zentralen Datenspeichers warten muss.

Erleichterung

Die Erleichterung ist riesig!

Besonders gemein an der Sache war, dass die Performance-Einbussen schon seit dem 15. Dezember bestanden hatten, in diesen Tagen aber niemandem etwas aufgefallen ist. Schliesslich war ja auch Weihnachten und generell herrschte weniger Betrieb als sonst.

Somit haben wir die Quelle des Übels am völlig falschen Ort vermutet: In den Änderungen, die ab dem 2. Januar durchgeführt wurden.

Inzwischen sind wir enorm erleichtert und glücklich darüber, das Problem gefunden zu haben. Wir gehen mit einem grossen Zuwachs an Erfahrung aus dieser nervenaufreibenden Zeit hervor.

Und natürlich tut es uns leid, dass die Performance-Probleme gerade bei datenbankintensiven Operationen auch auf Kundenseite zu spüren waren. Dafür und für die entstandenen Unannehmlichkeiten möchten wir uns bei Ihnen in aller Form entschuldigen.

15 Jahre cyon: Wir sagen Danke

37’233 Kunden. 65’234 gehostete Websites. 103’306 aktive Domains. 37 Mitarbeitende. 15 Jahre cyon. Die Zahlen beeindrucken mich jeden Tag aufs Neue. Ich bin stolz, was wir als Firma in den vergangenen 15 Jahren aufgebaut haben. Doch ohne eine ganz bestimmte Person wäre dieser Erfolg nie möglich gewesen: Sie. Deshalb möchte ich Ihnen im Namen des gesamten Teams meinen allerliebsten Dank aussprechen. Und Sie für einmal nicht aus, sondern in die Socken hauen. Dazu später mehr.

15 Jahre cyon

15 Stationen zum Erfolg

In den letzten 15 Jahren ist unheimlich viel passiert. Jedes einzelne Ereignis, jede Neuerung, jede Änderung hat die Geschichte mitgeschrieben. Mit etwas Mut zur Lücke nehmen wir Sie nun mit auf eine kleine Reise vorbei an 15 prägenden Stationen:

  • 01.02.2003: David Burkardt und Tobias Byland gründen cyon und schalten die erste Website auf.
  • 2004: Wir beziehen das erste Büro, das seinen Namen verdient.
  • 2005: Die erste Version des my.cyon geht online, in welchem persönliche Daten wie Adressen, Verträge etc. bearbeitet werden können. Die Verwaltung der Webhostings ist zu diesem Zeitpunkt noch separat und wird über das sogenannte «Control Panel» erledigt.
  • 2006: Das erste Büro ist bereits zu eng. Wir verlegen, mit inzwischen bereits sechs Mitgliedern, das Domizil an den Leonhardsgraben in Basel.
  • 2007: Frische Früchte im Anmarsch: Unsere Produkte tragen auf der neu lancierten Website das Kleid einer Frucht.
  • 2008: Schon wieder platzt das cyon-Büro aus allen Nähten. Der Firmensitz wird an die Gerbergasse im Herzen von Basel verlegt.
  • 2009: Eine komplett selbstentwickelte Verwaltungssoftware wird in Betrieb genommen. Sie übernimmt zahlreiche Automatisierungsaufgaben und ist für Kunden in Form einer neuen my.cyon-Version sichtbar.
  • 2010: Wir durchbrechen die magische Grenze von 10’000 Kunden und nehmen ein umfangreiches Supportcenter in Betrieb.
  • 2011: Im Sommer erneuern wir die komplette Infrastruktur durch Geräte der neuesten Generation. Als erster Webhosting-Anbieter in der Schweiz sind wir unter einer kostenlosen 0800er-Nummer erreichbar.
  • 2012: Das my.cyon und das Control Panel verschmelzen zum neuen my.cyon. Ab nun erledigen Sie sämtliche Aufgaben zentral in einer Oberfläche. Die bereits vierte Generation der cyon-Website geht online.
  • 2013: Wir lancieren drei neue Hosting-Produkte basierend auf der Cloud-Technologie. Der Speedserver ist für Websites mit hohem Besucheraufkommen konzipiert, der Agencyserver erfüllt die Hostingbedürfnisse von Webagenturen und mit dem Geekserver bringen wir einen frei konfigurierbaren Server auf den Markt.
  • 2014: SWITCH gibt die Rolle als Registrar ab und 1.2 Millionen .ch-Domains brauchen ein neues Zuhause. Mit dem praktischen Transfer-Automaten ist der Umzug mit einem Klick erledigt. Wir führen mit EUR, USD und GBP drei neue Währungen ein.
  • 2015: Dank kostenlosen SSL-Zertifikaten von Let’s Encrypt werden verschlüsselte Verbindungen zum Standard und Websites sind über das schnellere Protokoll HTTP/2 erreichbar. Wir unterstützen als erster europäischer Sponsor das Let’s-Encrypt-Projekt.
  • 2016: Der neue Website-Baukasten Sitebuilder macht das Erstellen einer Website, eines Blogs oder eines Online-Shops zum Kinderspiel. Wir schreiben erstmals eine Lehrstelle aus und werden damit zum Lehrbetrieb.
  • 2017: Wir unterziehen unsere Server-Infrastruktur einer Kompletterneuerung. Dank 100% SSD landen Ihre Websites in bisher unerreichten Geschwindigkeitssphären.

Dahin geht die Reise

Wir freuen uns schon jetzt, auch viele weitere Jahre wieder mit wichtigen Stationen zu füllen. Als erstes steht für uns in den kommenden Wochen ein Umzug in neue Büroräumlichkeiten an. Daneben haben wir unsere Ideenkiste stets rappelvoll gefüllt und sind voller Tatendrang, Ihnen daraus stets Neuigkeiten und Verbesserungen präsentieren zu dürfen. Wir halten Sie in gewohnter Weise hier im Blog und den weiteren Kanälen auf dem Laufenden.

Unser Dankeschön an Sie: exklusive cyon-Socken

Wie eingangs erwähnt, möchten wir Sie heute für einmal nicht aus den Socken, sondern in die Socken hauen. Mit einem kleinen Geschenk in Form eines exklusiven Paar cyon-Socken möchten wir Ihnen herzlich danken. In Ihrem my.cyon-Konto können Sie sich Ihre neuen Fusswärmer bestellen – selbstverständlich kostenlos und solange der Vorrat von 1’000 Stück reicht.

Update 02.01.2018, 09:41 Uhr: Wow, wir sind überwältigt. Die 1000 Paare sind bereits vergriffen.

Exklusive cyon-Socken

Sichern Sie sich Ihre exklusiven cyon-Socken. «S’het solang’s het.»

Die exklusiven cyon-Socken sind vorerst jenen cyon-Kunden vorbehalten, die bereits einmal eine Rechnung beglichen haben, ein zurzeit aktives Produkt besitzen und deren Adresse in der Schweiz, Liechtenstein oder Deutschland liegt. Die Stückzahl ist auf ein Paar Socken pro Kunde limitiert und «s’het so lang’s het».

Wir freuen uns über Ihre Stimme

Heute steht Ihnen nicht nur die Kommentarfunktion in diesem Blog zur Verfügung, wenn Sie uns und weiteren Lesern Ihre Meinung kundtun möchten. Anlässlich unseres Jubiläums haben wir eine «Wand» entworfen, auf welcher Sie sich mit einem Zitat verewigen können: https://www.cyon.ch/15/

Gibt es ein Erlebnis, dass Sie gerne teilen möchten? Sind Sie glücklich bei uns? Haben Sie einen Wunsch? Wir freuen uns sehr, wenn wir auf unserer Jubiläumswand darüber lesen können. In Ihrem my.cyon finden Sie das entsprechende Formular dazu.

Kampf dem Spam: Tägliche Angriffe auf die Inbox

Spam nervt – in jeder Hinsicht. Beim Empfänger, dessen E-Mail-Postfach im einfachsten Fall mit unerwünschter Werbung, betrügerischen Angeboten oder Phishing-Mails und im schlimmsten Fall gar mit Schadsoftware gefüllt wird. Aber auch für uns als Webhosting-Anbieter ist Spam ein Problem. Die Zunahme der Spam-E-Mails erhöht nicht nur den Abwehr- und Supportaufwand, sondern sorgt auch für eine höhere Belastung der technischen Infrastruktur.

Kampf dem Spam

Bereits die schiere Anzahl der eingehenden E-Mail-Nachrichten ist enorm: Allein im Monat Dezember 2017 haben uns beispielsweise 20’754’405 E-Mails erreicht. Das entspricht 669’497 E-Mails pro Tag. Allerdings: Nur knapp 44% davon sind echte, also erwünschte E-Mails. Der Rest wurde als unerwünschte E-Mails markiert oder von unseren Mailservern direkt abgelehnt.

Schwarze Liste: Ein bekannter Spammer?

Um Ihnen als Kunde so wenig wie möglich Spam in Ihr E-Mail-Postfach zu liefern, gehen wir in mehreren Stufen gegen unerwünschte E-Mail-Nachrichten vor. Das beginnt damit, dass wir bei einem Verbindungsversuch eines externen Servers im Hintergrund abklären, ob dessen IP-Adresse auf einer «schwarzen Liste» (sogenannte Realtime Blackhole Lists, RBL) eingetragen ist. Ist das der Fall, lehnen unsere Mailserver die Annahme des E-Mails ab. Allein mit dieser Massnahme wenden wir bereits über 53% der Spammails ab.

Greylisting: Schicks mir noch ein zweites Mal!

Im nächsten Schritt lehnen wir den Zustellversuch ab, wenn die ankommende E-Mail von einem unbekannten Absender geschickt wird. Beim sogenannten Greylisting wird der Umstand genutzt, dass legitime Mailserver in so einem Fall später erneut versuchen, die E-Mail zuzustellen. Etwas, das Spam-Versender äusserst selten versuchen.

Last but not least: Der gute alte Spamfilter

Damit bleiben noch 8’083’177 E-Mails, die als nächstes von SpamAssassin unter die Lupe genommen werden. SpamAssassin analysiert die eingehenden E-Mails und verteilt für Merkmale, die auf Spam hindeuten, Strafpunkte. Liegt die Anzahl Punkte über 5, wird der Betreff der E-Mail mit [SPAM] markiert und ist so beim Abruf des Posteingangs leicht als verdächtig erkennbar (und lässt sich mit einem passenden Filter in einen Ordner verschieben). Liegt die Anzahl Punkte gar über 20, wird die E-Mail vom Server abgewiesen.

Zulassen oder Blockieren – Sie haben es in der Hand!

In Ihrem my.cyon können Sie erwünschte Absender jederzeit zu Ihrer Whitelist hinzufügen. E-Mails von einem Absender auf der Whitelist werden dann von der Spam- und Virenüberprüfung ausgenommen. Das Umgekehrte gilt, wenn Sie einen Absender auf die Blacklist setzen: In diesem Fall werden die E-Mails des Absenders automatisch gelöscht.

Übrigens: In Ihrem my.cyon-Konto finden Sie unter «E-Mail» > «E-Mail-Log» aktuelle Informationen zum Status Ihrer ein- und ausgehenden E-Mails.

Screenshot E-Mail-Log

Transparenzbericht 2017

2016 haben wir unseren ersten Transparenzbericht veröffentlicht und damit über an uns gestellte, rechtliche Anfragen informiert. Mit dem heutigen Bericht informieren wir Sie über Anfragen, die wir 2017 erhalten haben.

Transparenzbericht Ausgabe 2017

Während Transparenzberichte bei US-Internet-Unternehmen wie Google, Facebook oder Twitter seit längerem zum Standard gehören, sind Berichte dieser Art unter Schweizer Fernmelde- und Internet-Unternehmen noch nicht verbreitet. Zurzeit sind uns mit Tresorit und Threema zwei Unternehmen mit Sitz in der Schweiz bekannt, die aktuelle Zahlen veröffentlicht haben. Mit unserem eigenen Transparenzbericht möchten wir Ihnen zeigen, wieviele Anfragen rechtlicher Natur wir erhalten haben und wie wir damit umgegangen sind.

Auskunftsersuchen von Behörden

Im Zeitraum 01.01.2017 – 31.12.2017 haben wir 13 Auskunftsersuchen von Behörden erhalten. Dabei handelte sich um Anfragen der folgenden Instanzen:

Behörde Art der Anfrage Anzahl erhaltener Anfragen Anfragen, bei denen Daten geliefert wurden
Staatsanwaltschaft, Polizei Editionsverfügung
(Art. 263/265 StPO)
10 10
EJPD, ÜPF Rückwirkende Verkehrsdaten, Überwachung des Fernmeldeverkehrs
(Art. 24b Bst. b VÜPF)
3 0

Bei Anfragen durch den Dienst ÜPF haben wir nach rechtlicher Prüfung keine Daten geliefert. Bis zum Inkrafttreten des revidierten BÜPF am 1. März 2018 ist cyon diesem nicht unterstellt, weshalb wir lediglich verpflichtet sind, Daten im Zusammenhang mit einer Editionsverfügung der zuständigen Staatsanwaltschaft herauszugeben.

Anfragen zu unzulässigen Inhalten

Anfragen zu unzulässigen Inhalten stammen in der Regel von Privatpersonen und Unternehmen und werden von uns nach dem Code of Conduct Hosting der simsa – Swiss Internet Industry Association behandelt. Wir haben im Zeitraum 01.01.2017 – 31.12.2017 13 Anfragen zu unzulässigen Inhalten erhalten:

Anfragesteller

Anfragesteller Anzahl Anfragen
Privatperson 5
Unternehmen 8

Land des Anfragestellers

Land Anzahl Anfragen
Schweiz 7
Deutschland 1
USA 2
Grossbritannien 1
Italien 1
Kosovo 1

Grund der Anfrage

Rechtsgebiet Anzahl Anfragen
Urheberrecht 3
Markenrecht 2
Persönlichkeitsrecht 3
Spam 2
Phishing 2
Unlauterer Wettbewerb 1

Verfahren nach Code of Conduct

Verfahren Anzahl Anfragen
Notice-and-Notice 9
Notice-and-Takedown 4

Fazit

Im Vergleich zu 2016 haben Auskunftsersuchen von Behörden deutlich zugenommen. Wir erwarten, dass dieser Trend auch 2018 anhalten wird. Zum einen wird immer mehr Kommunikation online abgewickelt, zum anderen werden Behörden versierter im Umgang mit digitaler Kommunikation. Anfragen, die wir nach dem Code of Conduct Hosting behandeln, sind praktisch konstant geblieben.

Sie haben Fragen zu diesem Bericht? Hinterlassen Sie uns einen Kommentar.

Seite 1 von 10712345...102030...Letzte »