Jetzt ist es offiziell: Das neue BÜPF (Bundesgesetz betreffend die Überwachung des Post- und Fernmeldeverkehrs) wurde von den eidgenössischen Räten verabschiedet und birgt zahlreiche, teils haarsträubende Verschlechterungen. So soll zum Beispiel neu auch das WLAN zu Hause unter das Gesetz fallen oder der Staatstrojaner legitimiert werden. Mit der Publikation am 28.03.2016 im Bundesblatt hat die 100-tägige Referendumsfrist begonnen. Während dieser Zeit müssen die Gegner des Gesetzes mindestens 50’000 Unterschriften zusammenbringen, um eine Volksabstimmung zu erzwingen.

BÜPF: Revision mit haarsträubenden Verschlechterungen (Bild: stopbuepf.ch CC BY 4.0)

Breit gestreute Gegnerschaft

Für einmal scheint sich die Debatte nicht zwischen den politischen Lagern abzuspielen. Viel mehr tut sich der Graben zwischen Jung und Alt auf. Mit einer Ausnahme gehören alle Schweizer Jungparteien zu den Unterstützern des «Stop BÜPF»-Bündnisses. Man könnte es auch den Kampf zwischen «Digital Natives» und den «Digital Immigrants» nennen.

Auch die Digitale Gesellschaft, der Chaos Computer Club oder die Piratenpartei gehören zu den BÜPF-Gegnern. Aus der Wirtschaft unterstützen unter anderem der ICT-Branchenverband Swico, der Messenger-Anbieter Threema oder der ISP Init 7 (über dessen Leitung sie möglicherweise auf diesen Artikel gelangt sind) für das Referendum stark. Alles Experten auf den Gebieten ICT und Internet.

Nutzen von Vorratsdatenspeicherung stark umstritten

Der Nutzen von Vorratsdatenspeicherung wird von Experten angezweifelt. Studien sind zum Schluss gekommen, dass eine Vorratsdatenspeicherung nicht zu höheren Aufklärungsraten führt. Und der Europäische Gerichtshof (EuGH) hat erkannt, dass die Vorratsspeicherung von Daten zu einem Eingriff in die Grundrechte fast der gesamten europäischen Bevölkerung führe.

Man kann sich darum fragen, warum in der Schweiz die Speicherung der sogenannten Randdaten/Metadaten massiv ausgeweitet werden muss. Immerhin wurde die vorgeschriebene Speicherdauer bei den bereits jetzt geltenden 6 Monaten belassen. Ursprünglich war eine Ausweitung auf 12 Monate vorgesehen. Doch das ist nur ein schwacher Trost.

Adieu Innovation

Tief vergraben im neuen Gesetz findet sich ein Artikel, der jedem Unternehmer, ob jung oder alt, die Haare zu Berge stehen lässt.

Der Verband Swico trifft mit seiner Stellungnahme den Nagel auf den Kopf:

Man muss sich als Schweizer Anbieter fragen, ob die Schweiz wirklich noch der beste Standort für die Erbringung und Entwicklung von Internetdienstleistungen ist. Und das zu Zeiten, in denen die «Digitale Transformation» das Buzzword des Jahres ist und die Schweiz als Partnerland an der CeBIT auftritt.

Zurück an den Absender

Keine Frage, das bestehende BÜPF ist nicht mehr zeitgemäss und muss überarbeitet werden. Die nun vorliegende, revidierte Version des Gesetz strotzt jedoch nur so vor Verschlechterungen, sowohl was Grund- und Freiheitsrechte als auch die Pflichten von ICT-Anbietern angeht. Die Forderungen des «Stop Büpf»-Bündnisses wurden praktisch durchs Band ignoriert. Bleibt also noch der Weg über eine Volksabstimmung, um dieses Gesetz zu stoppen.

Wir alle sind von diesem Gesetz betroffen. Unsere Unterschriften sind dem Referendumskomitee deshalb sicher. Ihre auch? Auf stopbuepf.ch finden Sie weitere Informationen sowie passende Unterschriftenbogen.

1 Million SSL-Zertifikate hat die offene und kostenlose Zertifizierungsstelle Let’s Encrypt seit ihrem Start Anfang Dezember 2015 bislang ausgestellt. Über 1% davon, zurzeit etwas über 12’000 Zertifikate, entfallen dabei auf Websites unserer Kunden.

Über 1% der Let’s Encrypt-Zertifikate sind für Domains von cyon-Kunden ausgestellt. Quelle: EFF

Mehr als nur kostenlose SSL-Zertifikate

Vor Let’s Encrypt stand man als Website-Betreiber vor der Entscheidung, ob man sich die Mühe machen sollte, seinen Besuchern eine verschlüsselte Verbindung anzubieten. Kostenlose SSL-Zertifikate sind keineswegs die Erfindung von Let’s Encrypt. Anbieter wie StartSSL, Cacert oder WoSign versorgen Kunden bereits seit Jahren mit kostenlosen, domainvalidierten, also sogenannten DV-Zertifikaten. Auch kostenpflichtige SSL-Zertifikate sind bereits für weniger als CHF 20.- pro Jahr zu haben und kosten damit nicht die Welt.

Die grosse Hürde lag vor Let’s Encrypt in der Beschaffung und der Installation eines Zertifikats. Der Vorgang war aufwendig und meist wenig benutzerfreundlich. All das hat sich zum guten Glück geändert. Die Let’s Encrypt-Initiative zeigt jetzt auch in der Branche der Zertifikateanbieter Wirkung. Vergangene Woche hat die Nummer Zwei der Branche, Symantec, das Programm «Encryption Everywhere» angekündigt. Bis 2018 sollen 100% aller Websites verschlüsselt ausgeliefert werden. Mit Sicherheit werden weitere kommerzielle Anbieter dem Beispiel folgen.

Was in der ganzen Diskussion um kostenlose Zertifikate unterzugehen droht: Die wahre Leistung von Let’s Encrypt liegt nicht (nur) im Angebot von kostenlosen SSL-Zertifikaten, sondern fusst im Grunde auf drei Pfeilern.

1. Der Let’s Encrypt-Client erlaubt es Systemadministratoren, SSL-Zertifikate automatisiert anzufordern und auf dem eigenen Server zu installieren.
2. Dabei macht sich der Client das ACME-Protokoll (Automated Certificate Management Environment) zu Nutze, das ebenfalls aus der Feder der Internet Security Research Group (ISRG), der Organisation hinter Let’s Encrypt, stammt.
3. Schlussendlich wird die Zertifizierungsstelle Let’s Encrypt mit der ACME-basierten Software Boulder betrieben, die wie der Let’s Encrypt-Client quelloffen ist.

Damit deckt Let’s Encrypt von der Bestellung über die Ausstellung bis hin zur Installation eines SSL-Zertifikats sämtliche nötigen Schritte mit Open-Source-Software und einem zukünftigen IETF-Standard ab. Die Software kann, wie bei Open-Source üblich, angepasst, erweitert und für eigene Zwecke genutzt werden. Dank des offenen Standards ACME kann jeder seinen eigenen passenden Client schreiben und so dazu beitragen, dass das Internet ein wenig sicherer wird.

Cartoon-Fans haben es bereits erkannt: ACME und Boulder sind Anspielungen auf die Serie Road Runner. Meep meep.

Schon dabei?

Für rund 15% der bei uns gehosteten Websites wurde bereits eine kostenloses SSL-Zertifikat von Let’s Encrypt ausgestellt. Damit profitieren Besucher dieser Websites nicht nur von einer verschlüsselten Verbindung, sondern auch automatisch vom schnelleren HTTP/2-Protokoll. Ausserdem bevorzugt Google per HTTPS erreichbare Adressen.

Haben Sie für Ihre Websites noch keine kostenlosen SSL-Zertifikate beantragt? Loggen Sie sich jetzt in Ihr my.cyon-Konto ein und aktivieren Sie die Let’s Encrypt-Zertifikate mit nur einem Mausklick. Um die Erneuerung der Zertifikate brauchen Sie sich übrigens keine Sorgen zu machen, unser System erledigt das ohne Zutun. Kostenlos, versteht sich.

Mithilfe von Cross-Site-Scripting (XSS) lässt sich Böses mit einer Website anstellen. Eine ganze Menge Massnahmen helfen, XSS auf der eigenen Website zu verhindern. Eine dieser Möglichkeiten nennt sich Content Security Policy (CSP). Wir zeigen heute, was CSP ist, wie Sie für Ihre Website eine Policy definieren können und welche Stolperfallen lauern.

Helm auf! Eine Content Security Policy schützt vor Cross-Site-Scripting

Wie es zur Content Security Policy kam

Content Security Policy (CSP) ist ein Konzept, um das Einschleusen von fremden Daten auf einer Website zu verhindern. Damals noch unter dem Namen «Content Restrictions» wurde das Konzept im Jahr 2004 erstmals von Robert Hansen vorgeschlagen. Als erster Browser unterstützte Firefox 4 die Content Security Policy, andere Browserhersteller zogen bald nach. Im Jahr 2012 wurde dann die erste Version, Content Security Policy 1.0 genannt, als «Candidate Recommendation» vom W3C publiziert. Mittlerweile wird bereits an der dritten Version, der Content Security Policy Level 3, gearbeitet.

So give it another year or so and we should have a workable defense against XSS on pages that must allow user submitted HTML and JavaScript – think eBay, MySpace, and so on.

— Quelle: ha.ckers.org via archive.org

War zu den Anfägen von CSP das Problem Cross-Site-Scripting noch ein Ding von Anbietern wie eBay oder MySpace, ist heutzutage praktisch jede Website potentiell anfällig auf Cross-Site-Scripting. Mit einer Content Security Policy lässt sich sehr genau definieren, aus welchen Quellen Inhalte geladen werden dürfen. Das schafft Sicherheit, führt früher oder später aber in eine Zwickmühle, wie sich gleich zeigen wird.

Wie definiere ich eine Content Security Policy?

Die CSP einer Website wird vorzugsweise im HTTP-Header definiert, kann aber auch als Meta-Tag direkt im Markup hinterlegt sein. Die Meta-Tag-Methode eignet sich vor allem für einzelne Seiten, für die spezielle Regeln gelten sollen. In unseren Beispielen wählen wir die HTTP-Header-Methode, die sich dank mod_headers bequem über die .htaccess-Datei steuern lässt. Alternativ können HTTP-Header auch direkt mithilfe von PHP-Code definiert werden.

Eine simple Content Security Policy liesse sich zum Beispiel mit folgender Anweisung in der .htaccess-Datei definieren:

Header set Content-Security-Policy "default-src 'self';"

Mit dieser CSP sind auf der entsprechenden Website nur noch Inhalte erlaubt, die auch über die aufgerufene Domain geladen werden. Externe und Inline-Scripts werden so verboten. Nutzen Sie auf Ihrer Website Scripts wie Google Analytics oder haben mit <script> im HTML-Markup Funktionen definiert, würden diese mit der gesetzten Policy nicht mehr funktionieren. Eine Lockerung der Regeln muss also her.

Mit

Header set Content-Security-Policy "default-src 'self' www.google-analytics.com;"

erlauben Sie zusätzlich zur eigenen Domain Inhalte, die über den Hostnamen www.google-analytics.com eingebunden sind.

Google Analytics generiert selbst Inline-Scripts. Erweitern wir die Regel noch mit 'unsafe-inline' sind auch Inline-Inhalte wieder erlaubt:

Header set Content-Security-Policy "default-src 'self' 'unsafe-inline' cdn.example.com;"

Aber Achtung: Der Befehl 'unsafe-inline' hebelt den Hauptnutzen einer Content Security Policy aus. Damit ist nämlich das Einschleusen von Code, also Cross-Site-Scripting, wieder möglich. Und hier beginnt die oben erwähnte Zwickmühle, denn Tools wie Google Analytics funktionieren nur, wenn Inline-Scripts erlaubt sind. In vielen Fällen kann man damit das Thema CSP bereits abhaken.

Doch nicht nur Inline-Scripts machen in Verbindung mit einer Content Security Policy Probleme. Viele Scripts wie z.B. Widgets von Facebook oder Twitter sind darauf angewiesen, dass Code aus Drittquellen geladen werden darf. Die Adressen dieser Quellen müssen wiederum in der eigenen Policy freigeschaltet sein, damit der Browser den angeforderten Code zulässt. Da sich diese Hostnamen aber immer wieder einmal ändern und die Anbieter nur selten alle eingesetzten Adressen kommunizieren, wird eine strikte Content Security Policy früher oder später dazu führen, dass eingebundene Scripts nicht mehr wie gewünscht funktionieren. Im schlimmsten Fall wird eine Website damit unbenutzbar.

Zwischenschritt Reporting

Sie sehen, eine sinnvolle Content Security Policy benötigt etwas Arbeit. Es empfiehlt sich, die geplanten Regeln ausführlich zu testen, bevor sie im Livebetrieb eingesetzt werden. Zum Glück liefert CSP eine dazu passende Funktion mit. Mit Content-Security-Policy-Report-Only ahndet der Browser allfällige Policy-Verstösse nicht, sondern gibt entsprechende Fehlermeldungen in der Browserkonsole aus. So liesse sich also mit der Regel

Header set Content-Security-Policy-Report-Only "default-src 'self' 'unsafe-inline' cdn.example.com;"

die geplante Policy zuerst einmal auf Herz und Nieren prüfen.

CSP-Verstosse werden in der Browserkonsole angezeigt.

Content-Security-Policy-Report-Only kann nicht nur Meldungen im Browser ausgeben, sondern auch Policy-Verstösse im JSON-Format an einen Endpunkt melden. Wer sich nicht die Mühe machen will, einen eigenen Endpunkt zu programmieren, findet unter report-uri.io einen tollen, kostenlosen Service, der nebst anderen praktischen Tools zum Thema CSP einen solchen Reporting-Endpunkt zur Verfügung stellt.

Einmal Upgrade bitte

Seit verschlüsselte Verbindungen zunehmend zum Standard werden, rückt eine CSP-Direktive ins Scheinwerferlicht. Mit upgrade-insecure-requests lassen sich unsichere, über HTTP eingebundene Quellen automatisch auf die sichere Variante HTTPS upgraden. Wird mit Header set Content-Security-Policy "upgrade-insecure-requests;" die Direktive gesetzt, lädt der Browser sämtliche Inhalte über HTTPS, selbst wenn diese «nur» über HTTP eingebunden sind. Zurzeit unterstützen Chrome, Firefox und Opera diese Funktion. IE-, Edge- und Safari-Nutzer bleiben vorerst aussen vor.

Browserunterstützung von «upgrade-insecure-requests». Quelle: caniuse.com

Sicherheit für Besucher

Eine ausgeklügelte Content Security Policy bietet umfassende Möglichkeiten, Besucher Ihrer Website vor bösen Angriffen zu schützen. Sie schützt jedoch nicht, wenn Angreifer Zugriff auf Ihr Webhosting erlangen. Die CSP ersetzt also nicht die Pflege des eingesetzten Content-Management-Systems und das Schliessen von allfälligen Sicherheitslücken.

Möchten Sie eine Content Security Policy für Ihre Website implementieren? Im Netz finden Sie viel interessante Lektüre dazu. Als Startpunkt empfehlen wir die Website content-security-policy.com, das Mozilla Developer Network (MDN), html5rocks.com oder diesen Blogbeitrag von Diogo Mónica.

Über Flat-File-CMSe haben wir an dieser Stelle bereits mehrmals geschrieben. Sie sind eine gute Alternative zu den bekannten Content-Management-Systemen, die auf eine Datenbank angewiesen sind. Einen Schritt weiter als Flat-File-Systeme gehen Static Site Generators.

Static Site Generators: Schnelle und sichere Websites

Wie funktionieren Static Site Generators?

Im Gegensatz zu einem datenbankbasierten CMS, bei dem Inhalte in der Datenbank gespeichert sind und mittels einer Scriptsprache (wie z.B. PHP) als HTML aufbereitet werden, findet die «Herstellung» einer Website bei Static Site Generators in der Regel auf dem eigenen Computer statt. Alle nötigen Teile der Website sind in einem lokalen Verzeichnis gespeichert und werden vom Static Site Generator aufbereitet. Als Produkt spuckt der Generator dann fixfertige HTML-Dateien aus, die nur noch auf einen passenden Webhosting-Account kopiert werden müssen. Damit entfällt die Rechenarbeit für den Webserver, was sich sehr positiv auf die Ladezeiten einer Website auswirkt.

Static Site Generators werden auf der Kommandozeile bedient und Inhalte in der Regel in Markdown geschrieben. Anhand von Meta-Daten am Anfang einer Datei, «Front Matter» genannt, baut der Generator die Website auf.

Wann macht der Einsatz eines Static Site Generators Sinn?

Der Einsatz eines Static Site Generators bietet sich in vielen Fällen an. Allen voran fürs Bloggen. Die meisten der erhältlichen Generatoren sind denn auch für den Aufbau eines Blogs entwickelt worden und bieten entsprechend umfassende Optionen an. Nicht nur Blogs, auch Websites für KMU lassen sich mit Static Site Generators problemlos umsetzen. Nicht zuletzt eignen sich Dokumentationen und Hilfetexte ebenfalls sehr dafür, mit einem Generator gepflegt zu werden. Schliesslich ändert sich der Inhalt solcher Texte nicht allzu oft und auch für Hilfesuchende ist ein schneller Seitenaufbau ein wichtiger Faktor.

Wann macht ein Content-Management-System Sinn?

Genauso, wie ein mächtiges Content-Management-System nicht für jeden Einsatzzweck geeignet ist, sind auch Static Site Generators nicht immer die richtige Wahl. Publizieren Sie mehrmals täglich neue Beiträge auf Ihrem Blog, sammeln sich mit der Zeit eine Menge Inhalte an. Ein Site Generator muss so mehrmals am Tag die Webdateien neu generieren. Aufgrund der grossen Anzahl an Beiträgen dauert dieser Vorgang zudem immer länger. In vielen Fällen ist dann die Wahl eines Systems wie WordPress empfehlenswert. Wird Ihr Blog ausserdem von technisch weniger versierten Personen mit Inhalten gefüllt, macht der Griff zu einem System mit grafischer Oberfläche meistens mehr Sinn.

Sind die Inhalte Ihrer Website in einer komplexen Struktur organisiert, müssen verschiedene Benutzerrollen definiert sein oder viele verschiedene Sprachen abgedeckt werden, empfiehlt sich fast immer ein Content-Management-System. Für solche Aufgaben sind Static Site Generators schlichtweg nicht vorgesehen. Was aber natürlich nicht heisst, dass mit Site Generators keine komplexen Websites machbar sind.

Static Site Generator oder CMS?

Schlussendlich lässt sich mit ein paar wenigen Fragen schnell eruieren, ob es für das nächste Projekt ein Generator oder doch ein umfangreicheres CMS sein soll:

• Wird die Website mehrmals täglich aktualisiert?
• Werden Funktionen benötigt, die nicht durch einen Drittanbieter zur Verfügung gestellt werden (Kommentare, Formulare, Suche) oder ist der Einsatz von Drittanbietern z.B. aus Datenschutzgründen ausgeschlossen?
• Wird die Website von technisch weniger versierten Benutzern verwaltet oder sind verschiedene Benutzerrollen und Workflows vorgesehen?

Lautet die Antwort auf eine dieser Fragen «Ja», ist ein Content-Management-System die bessere Wahl. In allen anderen Fällen lohnt sich der Blick auf einen der zahlreichen Static Site Generators.

Für jeden Einsatzzweck der passende Generator

Die Auswahl an Static Site Generators ist unglaublich gross. Die Website StaticGen bietet einen Überblick über die bei GitHub erhältlichen Open-Source-Generatoren. Wir stellen hier einige Vertreter kurz vor:

• Jekyll
  Der vom GitHub-Gründer ins Leben gerufene Generator ist in Ruby geschrieben und setzt auf die Template-Engine Liquid. Jekyll ist das WordPress unter den Static Site Generators, was die Verbreitung angeht.
• Exposé
  Das Bash-Script Exposé verwandelt Fotos und Videos in wunderschöne Foto- bzw. Videoessays.
• Middleman
  Middleman ist äusserst vielseitig einsetzbar, bietet zahlreiche Plugins und ist ebenfalls in Ruby geschrieben. Der E-Mail-Marketing-Anbieter MailChimp verwendet Middleman für seine Website.
• Metalsmith
  Metalsmith ist in JavaScript geschrieben und eigentlich viel mehr als «nur» ein Static Site Generator. Bei Metalsmith sind alle Funktionen als Plugins konzipiert, die sich dann auf ein Verzeichnis und die darin enthaltenen Inhalte anwenden lassen. Die Möglichkeiten sind damit fast unbegrenzt.
• Hugo
  Hugo, in der von Google entwickelten Sprache Go geschrieben, ist auch auf Windows-Computern sehr einfach zu installieren und generiert Websites, Blogs, Dokumentationen oder Portfolios in Windeseile.
• Sculpin
  Sculpin ist in PHP geschrieben und eignet sich damit vor allem für PHP-Entwickler, die Sculpin in der beliebten Skriptsprache erweitern möchten.
• Pelican
  Der Vertreter für alle Python-Liebhaber setzt auf die Template-Engine Jinja2 und kann Inhalte aus WordPress oder RSS-Feeds importieren.

Im vergangenen Oktober hat Google das Projekt Accelerated Mobile Pages (AMP) vorgestellt, das die Performance im mobilen Web dramatisch verbessern soll. Plattformen wie Twitter, LinkedIn oder Pinterest haben zur gleichen Zeit ihre Unterstützung angekündigt. AMP-Inhalte sollen ab Februar 2016 in den mobilen Suchresultaten von Google auftauchen. Wir erklären was AMP ist und für wen die Technik interessant ist.

Was ist AMP?

Das AMP-Projekt wurde von Google ins Leben gerufen, um Webinhalte schneller an Benutzer liefern zu können. Das Projekt macht sich dabei eine Light-Version von HTML zu Nutze, dem sogenannten «AMP HTML». AMP soll für statische Inhalte wie News-Artikel oder Blogbeiträge zum Einsatz kommen und gilt damit als Antwort auf Facebook Instant Articles. Im Gegensatz zu Facebook Instant Articles ist AMP open-source und wird von weiteren Plattformen wie Twitter, Pinterest oder LinkedIn unterstützt.

Facebook hat gestern angekündigt, dass das Instant Articles-Programm ab 12. April 2016 für alle Facebook-Seiten geöffnet wird.

Wo kommt AMP zum Einsatz?

Google will AMP nutzen, um Inhalte direkt in den Suchresultaten der eigenen Suchmaschine einzubinden. Die Vorschau von AMP-Inhalten wird dabei vor allen anderen Resultaten in Form eines Karussells angezeigt. Ähnlich werden sich Plattformen wie Twitter verhalten. AMP-Inhalte können damit ohne Weiterleitung direkt in der entsprechenden App angezeigt werden. Ein Segen für das Nutzererlebnis.

Seit 20. September 2016 erscheinen AMP-Inhalte in den Suchresultaten von Google.

Zusätzlich betreibt Google das AMP CDN, ein Content-Delivery-Network, das AMP-Inhalte weltweit verteilt und bereithält, um die Ladezeiten für Besucher weiter zu optimieren. Im Gegensatz zum restlichen Projekt ist AMP CDN nicht open-sourced und Informationen zum System sind noch spärlich gesät. Ob Twitter und Co. eigene CDNs für AMP-Inhalte bereitstellen werden, ist noch offen.

Strikte Diät, mehr Performance

Um die Performance von AMP-Inhalten hoch zu halten, sind die Möglichkeiten von AMP HTML und der zentralen JavaScript-Bibliothek AMP JS begrenzt. So sind in AMP-Dokumenten neben AMP JS externe Scripts nur erlaubt, wenn diese asynchron geladen werden. Zudem sind nicht alle CSS-Anweisungen erlaubt, müssen inline eingebunden sein und dürfen eine Gesamtgrösse von 50 kB nicht überschreiten. AMP-Inhalte unterliegen also einer strikten Diät.

Soll ich meine Inhalte als AMP anbieten?

Der zunehmenden Konzentration von Inhalten auf Plattformen wie Facebook, Twitter oder Google stehen vor allem jene Unternehmen kritisch gegenüber, die mit Online-Werbung ihr Geld verdienen. Die Möglichkeit, eigene Inhalte zu monetarisieren, ist sowohl bei Facebook Instant Articles als auch bei Accelerated Mobile Pages ein zentraler Bestandteil.

AMP macht für Websites Sinn, die Inhalte wie News-Artikel oder Blogposts anbieten. Wer jetzt schon AMP-Versionen seiner Inhalte bereitstellt, erhält die Chance, zuoberst in den Google-Suchresultaten aufzutauchen und schafft sich (zumindest vorerst) einen Vorteil gegenüber der Konkurrenz.

Die populärsten Content-Management-Systeme sind daran, AMP zu integrieren. Für WordPress sind bereits einige Plugins erhältlich, die die eigenen Blogpost in einer AMP-Version verfügbar machen. Das von Automattic mitentwickelte Plugin AMP kommt auch auf unserem Blog zum Einsatz. Und so sieht dieser Beitrag im AMP-Format aus.

Tutorial und weiterführende Lektüre

In der Dokumentation des Projektes finden Sie ein Tutorial, das Sie durch die Erstellung Ihrer ersten AMP-Seite führt. Weiterführende Informationen zu AMP finden Sie ausserdem auf der offiziellen Projekt-Website, dem GitHub-Repo und in der offiziellen Dokumentation.