Was ist ein VPN?

Ein Virtual Private Network (VPN) erstellt eine private Verbindung über ein öffentliches Netzwerk, häufig das Internet. Es ermöglicht Benutzern, Daten zu senden und zu empfangen, während die Sicherheit, Funktion und Privatsphäre eines privaten Netzwerks beibehalten wird. VPNs nutzen Verschlüsselung und andere Sicherheitsmechanismen, um sicherzustellen, dass nur autorisierte Benutzer auf das Netzwerk zugreifen können und dass die Daten nicht abgefangen werden können.

Wie funktioniert ein VPN?

VPNs verbergen die tatsächliche IP-Adresse eines Benutzers und ersetzen sie durch die IP-Adresse des VPN-Servers. Dies kann auch dazu verwendet werden, geografische Beschränkungen zu umgehen, indem eine Verbindung zu einem Server in einem anderen Land hergestellt wird. Die Daten, die zwischen dem Benutzer und dem VPN-Server gesendet werden, werden verschlüsselt, um sicherzustellen, dass sie privat und sicher bleiben.

Warum wird ein VPN benötigt?

Die Notwendigkeit eines VPNs ergibt sich aus drei Hauptgründen: Datenschutz, Sicherheit und Freiheit. VPNs schützen die Privatsphäre, indem sie die Internetaktivitäten eines Benutzers vor Neugierigen, einschließlich Internetdienstanbietern, verbergen. Sie erhöhen die Sicherheit, indem sie Daten verschlüsseln und so sicherstellen, dass sie nicht abgefangen oder gestohlen werden können. Und sie ermöglichen die Freiheit, indem sie es Benutzern ermöglichen, geografische Beschränkungen zu umgehen und auf Inhalte zuzugreifen, die sonst blockiert oder eingeschränkt wären.

Auswahl eines VPN-Anbieters

Bei der Auswahl eines VPN-Anbieters sollte auf eine Reihe von Faktoren geachtet werden. Dazu gehören die Qualität der Verschlüsselung, die Anzahl der verfügbaren Server und deren Standorte, die Geschwindigkeit der Verbindung, die Preisgestaltung und die Datenschutzrichtlinien des Anbieters. Es ist wichtig, einen Anbieter zu wählen, der eine starke Verschlüsselung und eine klare Datenschutzrichtlinie bietet und keine Benutzerdaten protokolliert.

Risiken und Grenzen von VPNs

Obwohl VPNs viele Vorteile bieten, haben sie auch ihre Grenzen und Risiken. Einige Websites und Dienste blockieren den Zugriff von VPN-Servern, was zu eingeschränkter Funktionalität führen kann. Es ist möglich, dass die Nutzung eines VPNs die Verbindungsgeschwindigkeit negativ beeinflusst. Darüber hinaus sind nicht alle VPN-Anbieter gleich und einige können riskant sein, insbesondere kostenlose Dienste, die oft Benutzerdaten sammeln und verkaufen.

Alternativen zu VPNs

Proxy Server

Proxy-Server können in einigen Fällen als Alternative zu VPNs dienen, sie bieten jedoch in der Regel nicht das gleiche Maß an Sicherheit und Datenschutz.

Ein Proxy-Server fungiert als Vermittler zwischen dem Benutzer und dem Internet, ähnlich wie ein VPN. Man kann es verwenden, um die IP-Adresse des Benutzers zu verbergen und geografische Beschränkungen zu umgehen. Allerdings verfügen die meisten Proxy-Server nicht über die starken Verschlüsselungsmechanismen, die VPNs verwenden, um die Daten des Benutzers zu schützen. Daher sind sie anfälliger für Abfangen und Überwachung.

Außerdem können Proxy-Server die Internetgeschwindigkeit oft stärker verlangsamen als VPNs und sie sind in der Regel nicht in der Lage, alle Internetverbindungen auf einem Gerät zu routen, sondern funktionieren nur auf Anwendungsebene.

Daher, während Proxy-Server in bestimmten Situationen nützlich sein können, insbesondere wenn es nur darum geht, geografische Beschränkungen zu umgehen, bieten sie im Allgemeinen nicht das gleiche Niveau an Sicherheit, Datenschutz und Gesamtverbindungsschutz, das VPNs bieten.

Einen spezifischen Beitrag zu einem Proxy Server habe ich hier (Proxy – Sicher, schnell und zuverlässig) geschrieben.

Das Tor-Netzwerk

Tor, das für „The Onion Router“ steht, ist ein Netzwerk, das Internetverbindungen über mehrere verschachtelte Server (die sogenannten Tor-Knoten) leitet, um Anonymität zu gewährleisten. Während Tor eine starke Anonymität bietet, kann es die Internetgeschwindigkeit erheblich verlangsamen und einige Websites blockieren Tor-Verbindungen.

Smart DNS

Ein Smart DNS (Domain Name System) ist ein Dienst, der den DNS-Server, den ein Gerät verwendet, ändert, um geografische Beschränkungen zu umgehen. Es bietet jedoch keine zusätzliche Sicherheit oder Verschlüsselung.

https

https (Hypertext Transfer Protocol Secure) ist eine sichere Version des https-Protokolls, das Websites verwenden. Es verschlüsselt die Verbindung zwischen einem Benutzer und einer Website, um den Datenverkehr zu schützen. Es schützt jedoch nur den Datenverkehr zwischen dem Benutzer und der Website und bietet keinen Schutz für andere Internetverbindungen oder Aktivitäten.

Einen spezifischen Beitrag zu https und https habe ich hier (https und https – Eine Reise zur Web-Sicherheit) geschrieben.

Ende-zu-Ende-Verschlüsselung

Bei der Ende-zu-Ende-Verschlüsselung kann man Daten so verschlüsseln, dass nur die kommunizierenden Benutzer sie entschlüsseln. Es wird oft in Messaging-Apps und anderen Kommunikationstools verwendet. Hierzu kann man sich auch die Beiträge über Signal und Delta Chat anschauen. Es schützt jedoch nur die Daten innerhalb der verschlüsselten Kommunikation und nicht andere Internetverbindungen oder Aktivitäiten.

Fazit

VPNs spielen eine immer wichtigere Rolle in der digitalen Welt, da sie Datenschutz, Sicherheit und Freiheit im Internet bieten. Bei der Auswahl eines VPN-Anbieters sollten Benutzer jedoch vorsichtig sein und Anbieter auf der Grundlage ihrer Sicherheitsmerkmale, Datenschutzrichtlinien und Leistungsfähigkeit bewerten. Trotz ihrer Grenzen und potenziellen Risiken stellen VPNs ein unverzichtbares Werkzeug für eine sichere und private Internetnutzung dar. Empfehlungen werde ich keine Aussprechen, da mir dieses Thema etwas zu heikel ist. Dennoch gibt es in der nahen Zukunft bestimmt noch die Vorstellung der ein oder anderen VPN Lösung.

Der Beitrag VPN (Virtual Private Networks) – Datenschutz im Internet erschien zuerst auf CEOsBay.

Kurze Zeitreise

Die Geschichte von HTTP beginnt 1989 mit Tim Berners-Lee, einem Physiker am CERN. Er entwickelte das HTTP-Protokoll, um die Übertragung von HTML-Dokumenten, den sogenannten Hypertexten, über das Internet zu ermöglichen. Dies war ein Schlüsselbestandteil seiner Vision vom World Wide Web, einem Informationsmanagement-System, dass es Benutzern ermöglicht, Informationen über das Internet zu teilen und zu verlinken.

Die Veröffentlichung der ersten dokumentierten Version von HTTP, HTTP/0.9, erfolgte 1991. Es war ein sehr einfaches Protokoll, die lediglich die GET-Methode unterstützte. Dies erlaubte einem Webbrowser, eine Anfrage an einen Webserver zu senden und ein HTML-Dokument zurückzuerhalten.

Die Veröffentlichung von HTTP/1.0 erfolgte 1996 als IETF RFC 1945. Es fügte weitere Methoden wie POST und HEAD hinzu und unterstützte auch HTTP-Header, was zusätzliche Metainformationen über die Anfrage und die Antwort ermöglichte.

HTTP/1.1, das heute weit verbreitet ist, kam 1997 zum Einsatz und man hat es später in RFC 2616 festgelegt. Es fügte wichtige Verbesserungen wie Persistente Verbindungen, Chunked-Übertragungen und zusätzliche Cache-Steuerung hinzu.

HTTP/2, im Jahr 2015, mit dem Ziel, die Leistung zu verbessern und die Latenz zu reduzieren. Es unterstützt Multiplexing, Priorisierung und Kompression von HTTP-Headern.

HTTPS – Hypertext Transfer Protocol Secure

Eingeführt, um die Übertragung sensibler Daten über das Internet sicherer zu machen. Es verwendet eine Verschlüsselung, um die Daten vor der Abhörung und Manipulation zu schützen.

Die Geschichte von HTTPS beginnt 1994 mit Netscape Communications, dem Unternehmen hinter dem damals populären Netscape Navigator Webbrowser. Sie führten HTTPS ein, zusammen mit dem SSL (Secure Sockets Layer) Protokoll, um sichere Transaktionen über das Web zu ermöglichen.

Das SSL-Protokoll entwickelte sich über die Jahre weiter und es fand schließlich eine Ersetzung durch das TLS (Transport Layer Security) Protokoll statt, dass man heute für HTTPS verwendet. Die aktuelle Version (Stand Juli 2023) ist TLS 1.3, dessen Veröffentlichung im Jahr 2018 stattfand.

Heute wird HTTPS von fast allen Websites verwendet, die sensible Daten übertragen, wie Online-Banking, E-Commerce und E-Mail-Dienste. Mit der Einführung von Let’s Encrypt, einer kostenlosen, automatisierten und offenen Zertifizierungsstelle, ist HTTPS auch zunehmend auf anderen Websites verbreitet, was zu einem sichereren Web für alle beiträgt. Auch Google achtet auf das Protokoll, wenn man beabsichtigt, das Ranking der Website auf Dauer zu verbessern.

Auch wenn es über die Geschichte ersichtlich ist, wofür unsere beiden Kandidaten gut sind, gehe ich nachfolgend nochmals etwas spezifischer auf die Definitionen, sowie auf die Vor- und Nachteile ein.

HTTP: Was ist das?

HTTP steht für Hypertext Transfer Protocol. Es ist ein Protokoll, das für die Übertragung von Informationen im World Wide Web verwendet wird. HTTP ist zustandslos, das bedeutet, dass jede Anfrage, die über HTTP gesendet wird, unabhängig von den vorherigen Anfragen ist.

HTTPS: Was ist das?

HTTPS steht für Hypertext Transfer Protocol Secure. Wie der Name schon sagt, ist es eine sichere Version von HTTP. Es verwendet SSL (Secure Sockets Layer) oder TLS (Transport Layer Security) Protokolle, um eine verschlüsselte Verbindung zwischen dem Client (zum Beispiel einem Webbrowser) und dem Server herzustellen. Dies bedeutet, dass alle Daten, die zwischen Client und Server übertragen werden, verschlüsselt und daher sicher sind.

Unterschiede zwischen den beiden Protokollen

Der Hauptunterschied zwischen HTTP und HTTPS ist die Sicherheit. HTTP überträgt Daten in Klartext. Das bedeutet, wenn jemand die Daten während der Übertragung abfangen kann, kann er sie leicht lesen und verstehen. HTTPS dagegen verschlüsselt die Daten, die übertragen werden. Das bedeutet, selbst wenn jemand die Daten abfängt, kann er sie nicht lesen, ohne den richtigen Schlüssel zu haben, um die Verschlüsselung zu entschlüsseln.

Ein weiterer Unterschied ist die Port-Nummer, die von den beiden Protokollen verwendet wird. HTTP verwendet Port 80, während HTTPS Port 443 verwendet.

Vorteile von HTTP

Einfachheit: HTTP ist einfacher zu implementieren, da es keine Zertifikate oder Schlüssel benötigt.

Geschwindigkeit: Da es keine Verschlüsselung gibt, ist HTTP in der Regel schneller als HTTPS.

Nachteile von HTTP

Sicherheit: HTTP ist unsicher. Jede übertragene Information, einschließlich sensibler Daten wie Kreditkartennummern und Passwörtern, kann abgefangen und gelesen werden.

Vorteile von HTTPS

Sicherheit: HTTPS ist sicher. Es schützt die übertragenen Daten vor Abhören und Manipulation.

Vertrauen: Websites, die es verwenden, sind in der Regel von Benutzern und Suchmaschinen als vertrauenswürdiger eingestuft.

SEO: Suchmaschinen wie Google bevorzugen HTTPS-Websites und ordnen sie in den Suchergebnissen höher ein.

Nachteile von HTTPS

Komplexität: Die Einrichtung von HTTPS erfordert den Kauf und die Installation eines SSL-Zertifikats. Dies kann für einige Benutzer kompliziert sein.

Leistung: Aufgrund der Verschlüsselung kann es etwas langsamer sein als HTTP.

Fazit

Die Nutzung der beiden Protokolle hängt stark von den Anforderungen und dem Schutzbedarf von Nutzerdaten ab. HTTP, obwohl weniger komplex und in manchen Fällen schneller, bietet keine Sicherheit für übertragene Daten. Jede Information, die über HTTP gesendet wird, ist anfällig für das Abfangen und den Missbrauch.

HTTPS hingegen stellt sicher, dass alle übertragenen Daten verschlüsselt und somit sicher sind. Es bietet ein höheres Maß an Vertrauen für Benutzer und kann sogar die SEO-Positionierung verbessern. Obwohl die Einrichtung der sichereren Variante eine gewisse Komplexität mit sich bringt und die Performance potenziell etwas beeinträchtigt werden kann, sind die Sicherheits- und Vertrauensvorteile in der heutigen digitalen Landschaft unverzichtbar. Aus diesem Grund fällt einem auch immer wieder das Schlosssymbol in der URL Leiste auf, die auf eine ungeschützte oder eben geschützte Website hinweist.

Insgesamt ist es klar, dass der Wechsel zu HTTPS nicht nur für Websites, die sensible Informationen verarbeiten, sondern für alle Websites von Vorteil ist. Dieser Trend zur Universalverschlüsselung ist ein positiver Schritt in Richtung eines sichereren und vertrauenswürdigeren Internets für alle Benutzer und ist in Bezug auf das Kosten-Nutzen-Verhältnis innerhalb eines vertretbaren Rahmens.

Der Beitrag http und https – Eine Reise zur Web-Sicherheit erschien zuerst auf CEOsBay.

Grundlagen

Warum OAuth?

• Benutzerkontrolle: OAuth ermöglicht es Benutzern, Anwendungen und Diensten den Zugriff auf ihre Konten bei verschiedenen Anbietern zu gewähren, ohne dabei ihre Benutzername/Passwort-Kombinationen preiszugeben.

• Sicherheit: Da die Anmeldeinformationen nicht direkt geteilt werden, reduziert OAuth das Risiko von Datendiebstahl und Missbrauch von Anmeldeinformationen.

• Granulare Berechtigungen: OAuth erlaubt es Benutzern, den Umfang und die Dauer der Zugriffsberechtigungen, die an eine Anwendung vergeben werden, präzise zu steuern.

Hauptkomponenten von OAuth

• Ressourcenbesitzer (Resource Owner)
  Der Ressourcenbesitzer ist normalerweise der Endbenutzer, der den Zugriff auf seine Daten und Ressourcen bei einem Ressourcenserver gewährt.

• Ressourcenserver (Resource Server)
  Der Ressourcenserver hostet die geschützten Daten und Ressourcen des Ressourcenbesitzers. Er ist dafür verantwortlich, die Autorisierung und Authentifizierung von Anfragen mithilfe von OAuth-Tokens zu überprüfen. (Kleiner Tipp am Rande. Bei den Tokens handelt es sich nicht um die Tokens, die man aus den Kryptowährungen kennt 😉 )

• Client
  Die Client-Anwendung ist der Konsument der geschützten Ressourcen. Sie stellt Anfragen an den Ressourcenserver, um im Namen des Ressourcenbesitzers auf die Daten zuzugreifen.

• Autorisierungsserver (Authorization Server)
  Der Autorisierungsserver ist für die Ausgabe, Überprüfung und den Widerruf von OAuth-Zugriffstokens zuständig. Er agiert als Vermittler zwischen dem Ressourcenbesitzer, dem Client und dem Ressourcenserver.

OAuth-Fluss

Man kann den OAuth-Fluss in vier grundlegende Schritte unterteilen:

• Anfordern der Autorisierung: Der Client fordert die Autorisierung des Ressourcenbesitzers an, um auf dessen Ressourcen zuzugreifen.

• Autorisierungsantwort: Der Ressourcenbesitzer gewährt die Autorisierung und leitet den Client an den Autorisierungsserver weiter. Der Client erhält einen Autorisierungscode.

• Anfordern eines Zugriffstokens: Der Client sendet den Autorisierungscode an den Autorisierungsserver und fordert ein Zugriffstoken an.

• Token-Ausgabe: Der Autorisierungsserver überprüft den Autorisierungscode, stellt ein Zugriffstoken aus und sendet es an den Client.

Nachdem der Client das Zugriffstoken erhalten hat, kann er es verwenden, um auf die geschützten Ressourcen des Ressourcenbesitzers zuzugreifen, indem er Anfragen an den Ressourcenserver stellt. Der Ressourcenserver überprüft das Token und gewährt den Zugriff entsprechend der Berechtigungen, die vom Ressourcenbesitzer festgelegt wurden.

Versionen und Unterschiede von OAuth

Es gibt zwei Hauptversionen. OAuth 1.0 und OAuth 2.0. Die Veröffentlichung von OAuth 1.0 fand im Jahr 2010 statt und verwendet einen komplexeren kryptografischen Ansatz für die Sicherheit. Im Jahr 2012 folgte OAuth 2.0 und ist eine überarbeitete Version, die eine einfachere und flexiblere Architektur bietet. Zweiteres basiert auf Bearer-Tokens. Bei beiden handelt es sich nach wie vor um offene Standardprotokolle zur sicheren Delegierung von Zugriffsberechtigungen. Obwohl sie gemeinsame Ziele verfolgen, unterscheiden sie sich in ihrer Architektur, ihren Sicherheitsmechanismen und besonders in der Benutzerfreundlichkeit. Durch die unterschiedliche Architektur ist keine Abwärtskompatibilität gegeben.

Sicherheitsmechanismen:

1.0: Verwendet einen kryptografischen Ansatz, bei dem man Anfragen mithilfe von kryptografischen Signaturen und einem gemeinsamen Geheimnis (Shared Secret) zwischen dem Client und dem Autorisierungsserver signiert. Diese Methode erfordert einen erhöhten Aufwand bei der Implementierung und Konfiguration.

2.0: Verwendet Bearer-Token, bei denen der Besitzer des Tokens (Client) Zugriff auf die geschützten Ressourcen erhält. Die Sicherheit basiert hauptsächlich auf der sicheren Übertragung und Aufbewahrung von Tokens (z. B. über https). Diese Methode ist einfacher zu implementieren und erfordert weniger kryptografische Kenntnisse.

Flexibilität:

1.0: Bietet einen starren Ablauf zur Anforderung und Nutzung von Zugriffstokens, der weniger Anpassungsmöglichkeiten für verschiedene Anwendungsszenarien bietet.

2.0: Ermöglicht eine größere Flexibilität und Anpassungsfähigkeit, indem man verschiedene „Grant Types“ (Genehmigungsarten) zur Verfügung stellt, um unterschiedlichen Anwendungsszenarien und Plattformen Genüge zu tun.

Einfachheit:

1.0: Die Implementierung und das Debugging von OAuth 1.0 können komplex sein, da Entwickler den kryptografischen Prozess und das Signieren von Anfragen verstehen müssen.

2.0: Die Implementierung von OAuth 2.0 ist einfacher und erfordert weniger kryptografische Kenntnisse. Dies führt zu einer schnelleren und einfacheren Integration in Anwendungen und Dienste.

Mobile und native Anwendungen:

1.0: Aufgrund seiner komplexeren Natur und der kryptografischen Anforderungen ist OAuth 1.0 weniger geeignet für mobile und native Anwendungen, bei denen Ressourcen und Konnektivität eingeschränkt sein können.

2.0: Durch die einfachere Implementierung und den flexibleren Ablauf eignet sich OAuth 2.0 besser für die Integration in mobile und native Anwendungen.

Vorteile

Sicherheit: Es erhöht die Sicherheit, indem man Anmeldeinformationen nicht direkt teilen muss und Tokens verwendet, um auf Ressourcen zuzugreifen.

Benutzerfreundlichkeit: Es ermöglicht Single Sign-On (SSO) und reduziert die Notwendigkeit, mehrere Benutzernamen und Passwörter zu verwalten.

Flexibilität: Es bietet eine flexible Architektur, die für verschiedene Anwendungsszenarien und Plattformen geeignet ist.

Granularität: Es ermöglicht, den Umfang und die Dauer der gewährten Berechtigungen genau zu steuern.

Nachteile

Komplexität: Die Implementierung von OAuth, insbesondere bei OAuth 1.0, kann komplex sein, da es verschiedene Abläufe und Mechanismen beinhaltet. Dies kann zu einer steileren Lernkurve für Entwickler führen, die sich nicht mit dem Protokoll auskennen.

Sicherheitsrisiken: Trotz der verbesserten Sicherheit, die OAuth bietet, gibt es immer noch Sicherheitsrisiken. Fehlkonfigurationen, unzureichende Validierungen und direkte Angriffe auf den Autorisierungscode oder das Zugriffstoken können die Sicherheit weiter gefährden.

Abhängigkeit von Drittanbietern: Die Verwendung von OAuth kann eine Abhängigkeit von Drittanbieter-Autorisierungsservern schaffen, die möglicherweise Ausfallzeiten, Sicherheitsverletzungen oder andere Probleme aufweisen können.

Datenschutzbedenken: Bei der Verwendung von OAuth besteht das Risiko, dass Benutzer mehr Daten preisgeben als erforderlich, da Anwendungen möglicherweise Zugriff auf mehr Informationen anfordern, als für ihre Funktionen notwendig ist.

Token-Hijacking: Obwohl es die Sicherheit gegenüber der direkten Weitergabe von Anmeldeinformationen verbessert, besteht immer noch die Gefahr, dass Angreifer Zugriffstoken abfangen oder stehlen können. Dies kann zu unbefugtem Zugriff auf Benutzerdaten führen.

Eingeschränkte Implementierung: Die Nutzung von OAuth in bestimmten Anwendungsszenarien, wie beispielsweise bei Geräten mit eingeschränkter Internetkonnektivität oder eingeschränkten Eingabemöglichkeiten, kann sich als schwierig oder teilweise unmöglich gestalten.

Best Practices

• Man sollte immer die neueste Version (aktuell OAuth 2.0) für bessere Sicherheit und Flexibilität verwenden.
• Implementierung von „Proof Key for Code Exchange“ (PKCE) Erweiterung ist zu empfehlen, um Angriffe, die den Autorisierungscode abfangen, verhindern zu können.
• Sichere Speicherung des Zugriffstokens und der Client-Anmeldeinformationen, um den Missbrauch zu verhindern.
• Verwenden von kurzen Gültigkeiten und Lebensdauern für Zugriffstokens und Erneuerungen bei Bedarf mithilfe von Aktualisierungstokens.
• Implementierung von Zustimmungsbildschirmen, um Benutzer über den Umfang und die Dauer der Berechtigungen, die man gewährt, zu informieren.

Fazit:

OAuth ist ein leistungsstarkes Protokoll, das die sichere Delegierung von Zugriffsberechtigungen im Internet ermöglicht. Durch das Verständnis der Grundlagen von OAuth und die Einhaltung der Best Practices können Entwickler Anwendungen erstellen, die eine sichere und benutzerfreundliche Erfahrung bei Login-Verfahren bieten.

Der Beitrag OAuth – Login ohne Preisgabe von Anmeldeinformationen erschien zuerst auf CEOsBay.

• Create: Erstellt einen neuen Datensatz in der Datenbank.
• Read: Liest einen Datensatz aus der Datenbank.
• Update: Ändert einen vorhandenen Datensatz in der Datenbank.
• Delete: Löscht einen Datensatz aus der Datenbank.

CRUD verwendet man häufig in Webanwendungen, um Benutzereingaben zu verarbeiten und Daten in einer Datenbank zu speichern, abzurufen, zu aktualisieren oder zu löschen. Es ist ein grundlegender Bestandteil vieler Anwendungen und ein wichtiger Teil der Softwareentwicklung.

Kurze Zeitreise

Die Idee von CRUD geht zurück auf die Anfänge der Datenbanktechnologie in den 70er Jahren. Zu dieser Zeit gestalteten sich Datenbanksysteme noch sehr rudimentär und man hat sie hauptsächlich für die Verwaltung von Geschäftsdaten verwendet. Die grundlegenden CRUD-Operationen waren bereits zu dieser Zeit vorhanden, wenn auch in einer trivialeren Form.

In den 80er Jahren gewannen relationale Datenbanksysteme immer mehr an Popularität, was die Entwicklung von Standard-Sprachen wie SQL (Structured Query Language) förderte. Diese Sprachen boten eine standardisierte Möglichkeit, Daten in einer Datenbank zu manipulieren, einschließlich der CRUD-Operationen.

Mit dem Aufkommen des World Wide Web und der Entwicklung von Webanwendungen in den 90er Jahren stieg die Bedeutung von CRUD signifikant an. Webanwendungen benötigen eine Möglichkeit, Daten zu speichern und abzurufen, um interaktive Funktionen bereitzustellen. Die Standardisierung von https und die Entwicklung von REST-basierten Architekturen haben CRUD zu einem wichtigen Konzept für die Entwicklung von Webanwendungen gemacht.

Heute ist es ein grundlegendes Konzept in der Softwareentwicklung und kann in einer Vielzahl von Anwendungen und Technologien Verwendung finden. Von relationalen Datenbanksystemen und RESTful-Webservices bis hin zu NoSQL-Datenbanken und Frontend-Frameworks. Man erwartet, dass es auch in Zukunft eine wichtige Rolle spielt, da Datenverarbeitung und -manipulation immer wichtig ist.

CRUD im Kontext von REST

Im Kontext von REST (Representational State Transfer) bezieht es sich auf die grundlegenden https-Methoden, die man für die Interaktionen mit Ressourcen verwendet:

• Create: Die POST-Methode verwendet man um eine neue Ressource zu erstellen.
• Read: Die GET-Methode verwendet man um eine vorhandene Ressource zu lesen.
• Update: Die PUT-Methode verwendet man um eine vorhandene Ressource vollständig zu aktualisieren und die PATCH-Methode um Teile einer Ressource zu aktualisieren.
• Delete: Die DELETE-Methode verwendet man um eine vorhandene Ressource zu löschen.

Diese Methoden entsprechen den CRUD-Operationen und bilden die Grundlage für die Interaktion mit RESTful-Webservices. Wenn man eine RESTful-API erstellt, sollte man die https-Methoden immer so implementieren, dass sie den CRUD-Operationen entsprechen und somit eine standardisierte und intuitive Schnittstelle für die Client-Software bereitstellen.

CRUD außerhalb von Datenbanken und Softwareentwicklung?

CRUD findet auch Anwendung in anderen Bereichen als der Datenbank- und Softwareentwicklung. Vor allem, wenn es generell um die Verwaltung von Informationen oder Objekten geht.

Hier noch einige Beispiele für die Anwendungsgebiete von CRUD

• Content Management Systeme (CMS): CMS-Plattformen wie WordPress oder Drupal verwenden CRUD, um Inhalte wie Artikel, Seiten oder Medien zu verwalten und zu bearbeiten.
• E-Commerce-Plattformen: E-Commerce-Websites verwenden CRUD, um Produkte zu erstellen, zu lesen, zu aktualisieren und zu löschen.
• Projektmanagement-Tools: Man nutzt es, um Projekte, Aufgaben und Aufgabenlisten in Projektmanagement-Tools wie Trello oder Asana zu verwalten.
• IoT (Internet der Dinge): Geräte im Internet der Dinge erzeugen häufig große Datenmengen, die man speichern und abrufen muss. Man verwendet es daher, um diese Daten in einer Datenbank zu speichern und zu manipulieren.
• Medizinische Datensätze: In der Gesundheitsbranche verwendet man CRUD-Operationen, um medizinische Datensätze zu erstellen, zu aktualisieren und zu löschen, z.B. Patientenakten, Diagnosen und medizinische Tests.

Fazit

Zusammenfassend lässt sich sagen, dass CRUD ein grundlegendes Konzept in der Datenbank- und Softwareentwicklung ist. Es eignet sich hervorragend für die Verwaltung von Daten in einer Datenbank. Auch für die Interaktion mit einer Ressource über eine RESTful-API Schnittstelle. Die vier CRUD-Operationen (Create, Read, Update und Delete) sind die grundlegenden Funktionen. Die benötigt eine Anwendung immer. Sowohl um Daten zu verwalten als auch zu manipulieren.

CRUD hat in den letzten Jahrzehnten eine wichtige Rolle in der Entwicklung von Webanwendungen, CMS, E-Commerce-Plattformen, Projektmanagement-Tools, IoT und der Gesundheitsbranche gespielt. Dies ändert sich voraussichtlich auch voraussichtlich nicht. Lediglich die Geschwindigkeit als auch die Effizient werden sich der Technologie voraussichtlich anpassen. Es ist ein wichtiger Bestandteil der meisten Anwendungen und ein grundlegendes Konzept, welches jeder Entwickler verstehen sollte.

Der Beitrag CRUD – Kernprinzipien für effiziente Datenmanipulation und solide Anwendungsarchitektur erschien zuerst auf CEOsBay.

Es beschreibt unter anderem eines der wichtigsten REST-Eigenschaften. Da der Architekturstil eine universelle Schnittstelle bieten soll, fordert HATEOAS, dass der REST-Client sich ausschließlich durch das Folgen von URIs (Uniform Resource Identifier) im Hypermedia-Format durch die Webanwendung bewegen kann. Wird dieses Prinzip umgesetzt, benötigt der Client abgesehen von einem grundsätzlichen Verständnis von Hypermedia. Keinerlei weitere Informationen, um mit der Anwendung bzw. dem Server zu kommunizieren.

Die Bereitstellung der einzelnen URIs erfolgt dabei beispielsweise in Form von href- und src-Attributen. Vorausgesetzt es handelt sich um HTML-Dokumente oder -Snippets. Auch durch JSON– bzw. XML-Attribute/-Elemente, die der jeweilige Client automatisch erkennt.

Durch die Umsetzung des HATEOAS-Prinzips lässt sich die Schnittstelle eines REST-Services jederzeit anpassen. Dies kann ein wichtiger Vorteil dieser Architektur gegenüber anderen Applikationsstrukturen sein. Vor allem im direkten Vergleich mit Anwendungen, die man auf Grundlage von SOAP (Simple Object Access Protocol) ausführt.

Das HATEOAS-Konzept ist wichtig, weil es die Flexibilität und Skalierbarkeit von RESTful APIs verbessert. Ohne HATEOAS müsste ein Client spezifische URLs und Endpunkte kennen, um eine Anwendung effektiv zu nutzen. Dies kann jedoch kritisch sein, da URLs sich in der Regel ändern können. Diese Tatsache kann jedoch eben auch zu Fehlern und fehlerhaften Anfragen führen.

Durch die Verwendung von Hypertext-Links wird ein Client in die Lage versetzt, den aktuellen Zustand der Anwendung zu verstehen und dynamisch zu navigieren. Wenn beispielsweise ein Client eine Anfrage an den Server sendet, um eine Liste von Benutzern abzurufen, könnte der Server eine Antwort zurückgeben, die Links zu den einzelnen Benutzerdetails enthält. Der Client kann dann den Link zu einem bestimmten Benutzer folgen, um weitere Informationen abzurufen.

Ein Beispiel ist eine Bestellungsverwaltung in einem Online-Shop. Wenn ein Kunde eine Bestellung aufgeben möchte, kann der Server eine Antwort zurückgeben. Die enthalten wiederum Links zu den verschiedenen Schritten des Bestellvorgangs. Um beispielsweise den Warenkorb anzuzeigen, die Versandadresse anzugeben, Zahlungsinformationen anzugeben, etc. Der Client kann dann den Link zum nächsten Schritt folgen, ohne spezifische URLs oder Endpunkte zu kennen.

HATEOAS ist jedoch nicht nur für die Navigation innerhalb einer Anwendung wichtig. Es ermöglicht auch eine einfache Integration mit anderen Anwendungen und Diensten. Wenn eine API beispielsweise HATEOAS-konform ist, kann man sie von anderen Anwendungen oder Diensten aus leichter nutzen, da sie den Zustand der Anwendung und die verfügbaren Aktionen verstehen können.

Fazit

Insgesamt verbessert das HATEOAS-Konzept die Flexibilität und Skalierbarkeit von RESTful APIs, indem es Clients in die Lage versetzt, dynamisch zu navigieren und den aktuellen Zustand der Anwendung zu verstehen. Durch die Verwendung von Hypertext-Links werden Anwendungen leichter integrierbar und besser wartbar. Wenn man also eine RESTful API entwirft, sollte man in Betracht ziehen, HATEOAS zu verwenden, um die Nutzbarkeit und die Flexibilität der Anwendung zu optimieren.

Der Beitrag HATEOAS – Evolution von REST für selbsterklärende APIs und zukunftssichere Web-Anwendungen erschien zuerst auf CEOsBay.

Kurze Zeitreise

Eclipse ist im Grunde genommen der Nachfolger von IBM Visual Age for Java 4.0. Der Quellcode dafür wurde im Jahr 2001 von IBM freigegeben. Im Jahr 2004 beschloss das von IBM geführte Eclipse-Konsortium die Ausgründung der rechtlich eigenständigen Eclipse Foundation, die seitdem für die Entwicklung von Eclipse verantwortlich ist. Es unterstützt die Java-Version 5 ab Version 3.1 und Java 6 ab Version 3.2. Ab dem Jahr 2006 wurden die Veröffentlichungstermine neuer Versionen der wichtigsten Eclipse-Komponenten harmonisiert, um Versionskonflikte zu vermeiden und Eclipse-Anwendern die Nutzung zu erleichtern. Man hat den Veröffentlichungszyklus ab der Version 2018-09 auf Quartalsaktualisierungen verkürzt, da ab Java 9 nicht mehr alle 3 Jahre, sondern alle 6 Monate eine neue Java Version erscheint. Es folgt nun einem Rolling Release Modell.

Rolling Release

(„rollen“ und „veröffentlichen“. Sinngemäß handelt es sich dabei um die kontinuierliche Aktualisierung der Software und ist ein Begriff aus der Softwareentwicklung. Bei einem Betriebssystem, dass das Rolling-Release-Prinzip anwendet, gibt es keine Betriebssystem-Versionen, bei denen bei einem Versions-Upgrade eine große Menge an Software auf einmal aktualisiert wird. Die einzelnen Software-Pakete werden vielmehr immerfort aktualisiert. Dies schließt sogenannte Releases, also Veröffentlichungen des Betriebssystems, aber nicht aus. Im Gegensatz zu einem Betriebssystem ohne Rolling Releases sind die Veröffentlichungen jedoch keine Versionen, sondern sogenannte Snapshots. Dies bedeutet, eine Kopie aller im Moment im Repository liegenden Software-Versionen. Diese Snapshots dienen meistens auch als Installations-Medien.

Die Projektnamen waren bisher nach den Jupitermonden (Callisto, Europa und Ganymede), den Raumsonden Galileo und Helios, die Version 3.7 nach der für Eclipse typischen Farbe Indigo benannt. Die Anfangsbuchstaben der Projektnamen werden ab Version 3.5 in alphabetischer Reihenfolge vergeben. Die Version 3.8 erschien gleichzeitig mit der Version 4.2. Um mit dem schnelleren Release-Zyklus von Java mitzuhalten, hat man 2018 von einem jährlichen Release auf vier Releases pro Jahr umgestellt. Damit hat man auch das Namensschema der Release-Versionen auf „{Jahreszahl}-{Monat}“ vereinfacht, also beispielsweise „2018-09“. Die einzelnen Versionen werden jeweils als Grundversion oder als Zusammenstellung aus verschiedenen Programmpaketen veröffentlicht. Einzelne Programmpakete kann man jedoch auch später noch nachinstallieren. Die Benutzeroberfläche von Eclipse ist standardmäßig englischsprachig. Es gibt jedoch zu jeder Version Babel-Language-Packs, die man sich in den entsprechenden Sprachen als Plugin installieren kann.

Darauf gehe ich so explizit ein, da ich mich in den letzten Tagen mit Kollegen über Eclipse ausgetauscht und in einem Quellcode verweise auf „Jupiter“ entdeckt habe. In der jüngsten Vergangenheit habe ich mich mit Jupyter beschäftigt. Daher auch hier ein Verweis auf den Beitrag damit es zu keiner Verwechslung der Themen kommt. Beides von Grund auf verschiedene Themen bzw. Dinge 😉

Architektur

Bis einschließlich zur Version 2.1 ist Eclipse als erweiterbare IDE konzipiert gewesen. Ab Version 3.0 ist es selbst nur der Kern, der die einzelnen Plug-ins lädt, die dann die eigentliche Funktionalität zur Verfügung stellt. Diese Funktionalität basiert, wie bereits erwähnt, auf Equinox. Sowohl Eclipse als auch die Plugins sind vollständig in Java implementiert. Zur Erstellung der GUI (grafischen Benutzeroberfläche) wurde SWT verwendet. Zur Darstellung der GUI-Komponenten basiert SWT ähnlich wie AWT auf den nativen GUI-Komponenten des jeweiligen Betriebssystems. Eclipse steht für 14 verschiedene Systeme und Architekturen zur Verfügung und gilt somit als plattformunabhängig. Die Plugins lassen sich direkt von einem Update-Server, über den „Market Place“, oder durch Entpacken einer Installationsdatei installieren.

Das frei verfügbare Eclipse SDK umfasst die Eclipse-Plattform, Werkzeuge zur Java-Entwicklung (Java Development Tools, JDT) und die Umgebung zur Entwicklung von Eclipse-Plugins (Plugin Development Environment, PDE).

Rich Client Platform

Eclipse bietet eine Rich Client Platform, welche es Anwendungsentwicklern ermöglicht, basierend auf dem Eclipse-Framework, von der Eclipse-IDE unabhängige Anwendungen zu schreiben. Die folgenden Komponenten (Plugins) werden typischerweise mindestens für eine Eclipse-Rich-Client-Platform-Anwendung verwendet:

• Eclipse Core Platform – steuert den Lebenszyklus einer Eclipse-Anwendung
• Eclipse Platform UI – stellt die Workbench mit den Konzepten Sichten, Editoren, Perspektiven, Menüs und Toolbars zur Verfügung
• Standard Widget Toolkit (SWT)
• JFace

Weitere Eclipse-Komponenten, wie das Hilfesystem oder das automatische Aktualisierungssystem, kann man ebenfalls einsetzen. In der Regel nutzt man das Eclipse-OSGi-Framework Equinox zum Kombinieren (bundling) der Komponenten.

Das UI (User Interface)

Eclipse ist in Komponenten (parts) gegliedert, die in Sichten (views) und Editoren (editors) gegliedert sind. Wobei die Unterscheidung in view und editor sich an der Nutzung orientiert und nicht technischer Natur ist. Diese Fenster kann man durch Drag and Drop beliebig anordnen oder minimieren.

Sichten

Mit Hilfe der views kann man Daten direkt bearbeitet und darunterliegende Datenstrukturen verändern.

Beispiele für views sind die auch aus den meisten anderen Editoren bekannte Navigator-View, die im Projektverzeichnis enthaltene Dokumente anzeigt, der Klassenexplorer, der baumartig strukturiert Symbole für die Klassen, Funktionen, Variablen und Importe eines geöffneten Quelltextes anzeigt oder das Suchfenster, dass die Ergebnisse einer Suche auflisten kann.

Editoren

Editoren sind Komponenten, die nur das jeweils geöffnete Datenelement bearbeiten und in denen der Nutzer explizit speichern muss, um Daten zu verändern. Beispiele sind Fenster, die meist den Quelltext mit Syntaxhervorhebung anzeigen, wobei es für viele Programmiersprachen einen eigenen Editor gibt. Beispielsweise für Java, C, PHP, Python, HTML, aber auch einen einfachen Texteditor. Genauso gibt es auch visuelle Editoren (beispielsweise UML-Editoren, GUI-Builder) oder solche, die Baumstrukturen anzeigen (etwa der XML-Editor). Editoren nehmen normalerweise den meisten Raum des Programmfensters in Anspruch. Mehrere geöffnete Quelltexte kann man als Reiter öffnen, die man dann über Tabs am oberen Rand in den Vordergrund bringen kann. Außerdem kann man Tabs fixieren, damit man beispielsweise den zugehörigen Quelltext nicht versehentlich schließt. Auch kann man die Editoren weitestgehend frei per Drag and Drop anordnen. Davon abgesehen ist es möglich, eine Datei in mehreren Editoren gleichzeitig zu öffnen.

Perspektiven

Perspektiven sind vollständige Anordnungen von parts. Ein editor bleibt beim Perspektivwechsel erhalten. Perspektiven sind weitestgehend frei konfigurierbar und man kann benutzerdefinierte Konstellationen speichern sowie laden. Meistens stellen Plugins, die man nachinstalliert, vorkonfigurierte Perspektiven zur Verfügung, diese passt man dann meisten den eigenen Wünschen und Vorlieben an.

Plugins und Erweiterungen

Es gibt zahlreiche Erweiterungen für Eclipse. Teils proprietär, teils frei verwendbar bzw. Open Source. Primär verwendet man es als Java IDE. Dabei kommen vor allem die in den Java Development Tools zusammengefassten Plugins zum Einsatz. Es existieren aber etliche Plugins für andere Sprachen, die ich bereits unter Editoren erwähnt habe. Hinzu kommt noch die Entwicklung von OSGi-Bundles. Dazu zählt vor allem das CDT-Projekt, welches C und C++ unterstützt und unter Anderem die GNU Compiler Collection sowie die LLVM (-Clang und -GCC) abdeckt. Darüber hinaus gibt es auch Plugins für Perl, PHP, ColdFusion, Ruby, Python, C#, Fortran, Ada2005, Scala usw. Diese kann man über ein Menü in Eclipse einbinden. Neben Plugins für konkrete Programmiersprachen gibt es auch solche, die allgemeine Entwicklungsprozesse unterstützen, wie beispielsweise Mylyn für „aufgabenorientierte Entwicklung“ oder Saros für Verteilte Paarprogrammierung auch Distributed Pair Programming, DPP oder Pair Programming, PP genannt. Oft sind diese Ergänzungen – anders als das Kernprogramm – ausschließlich in der englischen Sprache erhältlich.

Neben den Java Development Tools gibt es viele weitere Projekte, die man ebenfalls auf der Eclipse-Website koordiniert. Ein solches Projekt ist das Eclipse Tools Project, dass verschiedene Hilfsmittel entwickelt, die Entwickler erweitern können. Weitere Projekte sind das Eclipse Modeling Framework (EMF), das Graphical Editing Framework (GEF) und die eingestellte Eclipse Riena Platform (Riena). Mit EMF lässt sich ein Datenmodell erstellen, das zum Beispiel auf UML basieren kann. GEF ist ein Projekt, dass es Entwicklern erlaubt, mit Hilfe eines existierenden Datenmodells schnell einen grafischen Editor zu erstellen. Riena unterstützt Entwickler bei der Ausstattung einer Anwendung mit einem benutzerfreundlichen Interaktionskonzept und ansprechenden Oberflächenelementen.

Basierend auf diesen Erweiterungen und dem modularen Aufbau von Eclipse selbst, lassen sich für Projekte spezifische Eclipse-Bundles erstellen. Diese enthalten alle für ein bestimmtes Projekt notwendigen Teile und Erweiterungen von Eclipse, ohne mit unnötigen Teilen Hauptspeicher und Rechenleistung zu verbrauchen.

Inzwischen gibt es auch Open Source-Erweiterungen, die eine automatisierte Bereitstellung und Konfiguration erheblich erleichtern. Dazu zählen oasp4j-ide, Oomph und Yatta Profiles, von denen ich einige in zukünftigen Beiträgen thematisiere.

Fazit

Durch den quelloffenen Ansatz und der kostenfreien Nutzungsmöglichkeit ist Eclipse neben IntelliJ eines der beliebteren IDEs. Man kann durch Plugins und Erweiterungen viele Programmiersprachen bedienen. Der Programmkern von Eclipse stellt in dem Zusammenhang die einzige versionsübergreifende Konstante dar. Jede Aktualisierung führt Neuerungen in den Kern ein und die integrierten Plugins bzw. Erweiterungen erfordern dadurch meist eine Anpassung an die neue Version.

Die grafische Oberfläche von Eclipse ist auf eine effiziente Arbeitsweise ausgerichtet. Der konzeptionelle Aufbau durch Views, Editoren und Perspektiven sorgt für eine anpassbare Optik und eine bequeme Arbeitsweise mit und in der IDE. Man kann sowohl die Funktionalitäten als auch die GUI von Eclipse durch die manuelle oder automatische Installation von Plugins bzw. Erweiterungen anpassen. Entsprechende Möglichkeiten finden sich in dem standardmäßig integrierten Market Place von Eclipse.

Der Beitrag Eclipse – Die flexible Entwicklungsumgebung erschien zuerst auf CEOsBay.

Grundprinzipien von PHP

Es ist eine serverseitige Sprache, was bedeutet, dass man PHP-Skripte ausschließlich auf einem Server ausführt, bevor es das Ergebnis an den Webbrowser des Clients sendet. Dies hat den Vorteil, dass man sensible Daten wie Passwörter oder Datenbankverbindungen nicht direkt im Quellcode des Clients preisgeben muss.

Einige der grundlegenden Prinzipien:

• Einfache Syntax: Es ist bekannt für seine einfache und leicht verständliche Syntax, die es sowohl Anfängern als auch erfahrenen Programmierern ermöglicht, relativ schnell produktiv zu sein.

• Dynamisches Typisierungssystem: Im Gegensatz zu streng typisierten Sprachen erlaubt es Variablen, verschiedene Datentypen (z.B. Strings, Zahlen, Arrays und Objekte) während der Laufzeit zu speichern. Dies ermöglicht eine höhere Flexibilität und verkürzt die Entwicklungszeit.

• Integration mit HTML: Man kann PHP-Skripte direkt in HTML-Dateien einbetten, wodurch es einfach ist, dynamische Inhalte innerhalb einer statischen HTML-Seite zu erstellen.

• Umfangreiche Standardbibliothek: Es bietet eine umfangreiche Sammlung von Funktionen und Klassen, die die Arbeit mit Dateien, Datenbanken, Sitzungen, Cookies, Netzwerkprotokollen und vielem mehr erleichtern.

Vorteile von PHP

• Plattformübergreifend: Es ist kompatibel mit verschiedenen Betriebssystemen wie Windows, Linux und MacOS. Dies macht es zu einer idealen Wahl für Webentwickler, die plattformunabhängige Anwendungen erstellen möchten. Bis vor einigen Iterationen von MacOS konnte man einen Server nativ über das Terminal starten. Dies hat man aber scheinbar aufgrund von Sicherheitsrisiken unterbunden. Möglich ist dies nun via Homebrew. Hierzu verweise ich gerne auf den folgenden Artikel.

• Leistungsfähigkeit: Man kann komplexe und umfangreiche Webanwendungen verarbeiten und ist in der Lage, auch bei hoher Last stabile Leistung zu liefern.

• Kostenfrei und Open Source: Es ist eine Open-Source-Software, was bedeutet, dass man sie kostenlos herunterladen, verwenden und modifizieren darf. Dies hat zu einer großen und engagierten Entwicklergemeinschaft geführt, die nach wie vor zur ständigen Verbesserung und Erweiterung der Sprache beiträgt.

• Breite Unterstützung: Viele Webhosting-Unternehmen unterstützen PHP von Haus aus und man kann es leicht auf einem Webserver installieren.

Anwendungsgebiete von PHP

Wie bereits erwähnt ist es ist eine vielseitige Programmiersprache. Man kann sie aus diesem Grund in einer Vielzahl von Anwendungsfällen einsetzen. Einige der wichtigsten Anwendungsgebiete von PHP sind:

• Content-Management-Systeme (CMS): PHP ist die treibende Kraft hinter einigen der beliebtesten CMS wie WordPress, Joomla und Drupal. Diese Systeme erleichtern die Erstellung und Verwaltung von Websites ohne tiefgreifende Programmierkenntnisse.

• E-Commerce-Plattformen: Man verwendet es häufig zur Entwicklung von Online-Shops und E-Commerce-Plattformen. Beispiele hierfür sind WooCommerce, Magento oder PrestaShop. Die Skalierbarkeit und Flexibilität von PHP ermöglichen es Entwicklern, umfangreiche und leistungsfähige E-Commerce-Websites zu erstellen, die auf die individuellen Bedürfnisse der Kunden zugeschnitten sind.

• Webanwendungen: PHP eignet sich hervorragend für die Entwicklung von benutzerdefinierten Webanwendungen und hat eine Vielzahl von Frameworks wie Laravel, Symfony oder CodeIgniter, die den Entwicklungsprozess vereinfachen und beschleunigen.

• APIs und Web-Services: Aufgrund seiner Fähigkeit, einfach und schnell mit verschiedenen Datenquellen und -formaten zu arbeiten, eignet sich PHP hervorragend zur Entwicklung von APIs und Web-Services, die als Brücke zwischen unterschiedlichen Anwendungen und Plattformen fungieren.

• Social-Media-Plattformen: PHP ist die Grundlage einiger bekannter Social-Media-Plattformen wie Facebook, dass man ursprünglich in PHP entwickelt hat. PHP kann man aber auch bei der Entwicklung eigener Social-Media-Plattformen oder bei der Integration von Social-Media-Funktionalitäten in bestehende Anwendungen einsetzen.

Fazit

PHP hat sich als eine robuste, vielseitige und weit verbreitete serverseitige Skriptsprache etabliert, die man in einer Vielzahl von Anwendungsbereichen einsetzt. Mit seiner einfachen Syntax, den leistungsfähigen Funktionen und breiten Unterstützung durch Webhosting-Unternehmen, ist PHP eine ausgezeichnete Wahl für Webentwickler, die dynamische, interaktive und benutzerfreundliche Websites und Webanwendungen erstellen möchten. Die engagierte und wachsende Entwicklergemeinschaft garantiert die fortlaufende Verbesserung und Erweiterung der Sprache, was PHP zu einer attraktiven Option für Webentwickler auf der ganzen Welt macht.

Der Beitrag PHP – Die Sprache für dynamische und interaktive Webanwendungen erschien zuerst auf CEOsBay.

Der Zweck von REST liegt schwerpunktmäßig auf der Maschine-zu-Maschine-Kommunikation. REST stellt eine einfache Alternative zu ähnlichen Verfahren wie SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) und dem verwandten Verfahren RPC (Remote Procedure Call) dar. Anders als bei vielen verwandten Architekturen kodiert REST keine Methodeninformation in den URI (Uniform Resource Identifier), da der URI Ort und Namen der Ressource angibt, nicht aber die Funktionalität, die der Web-Dienst zu der Ressource anbietet. Der Vorteil von REST liegt darin, dass im WWW bereits ein Großteil der für REST nötigen Infrastruktur (z. B. Web- und Application-Server, https-fähige Clients, HTML- und XML-Parser, Sicherheitsmechanismen) vorhanden ist und viele Web-Dienste per se REST-konform sind. Eine Ressource kann dabei über verschiedene Medientypen dargestellt werden, auch Repräsentation der Ressource genannt.

So ist ein Online-Dienst, der lediglich unveränderte Seiteninhalte nach dem Internetstandard https anbietet, bereits REST-konform. Dynamisch erzeugte Seiten folgen diesem Paradigma jedoch meistens nicht. So bieten beispielsweise Nachrichtenseiten sich ständig ändernde Informationen mit sowohl unterschiedlichem Format als auch Inhalt an, die nur schwer automatisch verarbeitet werden können. Bliebe das Format unverändert, so wäre eine essenzielle REST-Eigenschaft erfüllt. So ist eine Webseite, auf der ständig die aktuelle Uhrzeit in immer demselben Format abrufbar ist, REST-konform.

Die Bezeichnung „Representational State Transfer“ soll den Übergang vom aktuellen Zustand zum nächsten Zustand (State) einer Applikation verbildlichen. Dieser Zustandsübergang erfolgt durch den Transfer der Daten, die den nächsten Zustand repräsentieren.

Kurze Zeitreise

Das REST-Paradigma entwickelte sich aus dem 1994 von Roy Fielding entworfenen https Object Model. Fielding entwickelte seine Idee von einem einheitlichen Konzept über die Jahre weiter, bis er 2000 den REST-Architekturstil im Rahmen seiner Dissertation (Hier der Link zu der Arbeit) veröffentlichte. Das Programmierparadigma der „RESTful Application“ wurde allerdings häufig falsch umgesetzt und findet erst seit 2014 Anklang in der Welt des WWW. In seiner Arbeit geht Fielding dabei auf die verschiedenen Anforderungen ein, die für die Webarchitektur wichtig sind.

Wie funktioniert REST?

Der Architektur-Stil verweist auf sechs Eigenschaften, die ein Dienst haben muss. Dabei ist nicht festgelegt, wie man diese Prinzipien implementieren muss. Fielding beschreibt für jedes Architekturprinzip dessen Vor- und Nachteile. Dabei handelt es sich um Client-Server, Zustandslosigkeit, Caching, Einheitliche Schnittstellen, Mehrschichtige Systeme und optional Code on Demand, auf die ich nachfolgend eingehen werde.

• Client-Server (Es gilt generell die Anforderung, dass alle Eigenschaften der Client-Server-Architektur gelten. Der Server stellt dabei einen Dienst bereit, der bei Bedarf vom Client abgefragt wird. Der Hauptvorteil dieser Anforderung ist die einfache Skalierbarkeit der Server, da diese unabhängig vom Client agieren. Dies ermöglicht des Weiteren eine unterschiedlich schnelle Entwicklung der beiden Komponenten.)
  
• Zustandslosigkeit (Jede REST-Nachricht enthält alle Informationen, die für den Server bzw. für den Client notwendig sind, um die Nachricht zu interpretieren. Weder der Server noch die Anwendung soll Zustandsinformationen zwischen zwei Nachrichten speichern. Man spricht daher von einem zustandslosen (englisch: stateless) Protokoll. Jede Anfrage eines Clients an den Server ist insofern in sich geschlossen, als dass sie sämtliche Informationen über den Anwendungszustand beinhaltet, die vom Server für die Verarbeitung der Anfrage benötigt. Zustandslosigkeit in der hier beschriebenen Form begünstigt die Skalierbarkeit eines Webservices. Beispielsweise können eingehende Anfragen im Zuge der Lastverteilung unkompliziert auf beliebige Maschinen verteilt werden, da jede Anfrage in sich geschlossen ist und Anwendungsinformationen somit ausschließlich auf der Seite des Clients vorgehalten werden. Aus diesem Grund ist auf der Seite des Servers keine Sitzungsverwaltung erforderlich. In der Praxis nutzen deswegen viele https-basierte Anwendungen Cookies und andere Techniken, um Zustandsinformationen auf der Client-Seite zu behalten. Weiterhin begünstigt wird die Ausfallsicherheit, weil die Zustandslosigkeit fordert, dass transaktionale Datenübertragung in einem einzigen Seitenaufruf erfolgt. Die Zustandslosigkeit bringt dabei aber den Nachteil mit, dass sich die Netzwerkperformance verschlechtert. Da bei jeder Abfrage alle Informationen zum Interpretieren mitgeschickt werden müssen, sind aufwendigere Abfragen nötig, als wenn sich der Server die Interaktionen merken würde.)
  
• Caching (https-Caching soll genutzt werden, wobei aber gilt: Eine Anfrage, die nicht gestellt werden muss, ist die schnellste Anfrage. Fielding führt dabei den Nachteil auf, dass der Client auf veraltete Cache-Daten zurückgreifen könnte, statt die neue Ressource abzufragen. Wir kennen dies beispielsweise, wenn wir an einer Website unsere Änderungen vorgenommen haben aber die aktualisierten Informationen nach der Synchronisierung mit dem Server nicht richtig angezeigt werden bzw. lediglich die alten Informationen)
  
• Einheitliche Schnittstelle (Dies ist das Hauptunterscheidungsmerkmal aller weiteren Architekturstile. Dabei besteht diese aus vier weiteren Eigenschaften.)

1. Die Adressierbarkeit von Ressourcen, bei der jede Information, die über einen URI kenntlich gemacht wird, als Ressource gekennzeichnet wird. Jeder REST-konforme Dienst eine eindeutige Adresse hat und dem Uniform Resource Locator (URL). Diese „Straße und Hausnummer im Netz“ standardisiert den Zugriffsweg zum Angebot eines Webservices für eine Vielzahl von Anwendungen (Clients). Eine konsistente Adressierbarkeit erleichtert es außerdem, einen Webservice als Teil eines Mashups weiterzuverwenden.
   
2. Repräsentationen zur Veränderung von Ressourcen, wodurch die unter einer Adresse zugänglichen Dienste unterschiedliche Darstellungsformen (Repräsentationen) haben können. Ein REST-konformer Server kann je nachdem, was die Anwendung anfordert, verschiedene Repräsentationen einer Ressource ausliefern, z. B. in verschiedenen Sprachen oder Formaten (HTML, JSON oder XML) oder auch die Beschreibung oder Dokumentation des Dienstes. Die Veränderung einer Ressource (also deren aktuellen Status) soll nur über eine Repräsentation erfolgen.
   
3. Selbstbeschreibende Nachrichten, REST-Nachrichten sollen selbstbeschreibend sein. Dazu zählt u. a. die Verwendung von Standardmethoden. Über diese Standardmethoden lassen sich Ressourcen manipulieren.
   
4. „Hypermedia as the Engine of Application State“ (HATEOAS) laut Fielding die wichtigste Eigenschaft

Ziel ist die Einheitlichkeit der Schnittstelle und somit ihre einfache Nutzung. 

• Mehrschichtige Systeme, bei dem die Systeme mehrschichtig aufgebaut sein sollen. Dadurch reicht es, dem Anwender lediglich eine Schnittstelle anzubieten. Dahinterliegende Ebenen können verborgen bleiben und somit die Architektur insgesamt vereinfachen. Vorteile dabei sind die bessere Skalierbarkeit der Server, sowie eine mögliche Abkapselung durch Firewalls. Durch Cache-Speicher an den Grenzen (z.B. vom Server zum Web) steigert man die Effizienz der Anfragen (Siehe Caching).
  
• Code on Demand, wobei diese Forderung von Fielding optional ist. Unter Code on Demand versteht man die Übertragung an den Client Code erst im Bedarfsfall. Folglich zur lokalen Ausführung. Ein Beispiel hierfür wäre die Übertragung von JavaScript-Code bei einer HTML-Repräsentation.

Folglich kommt für die Umsetzung des REST-Paradigmas ein zustandsloses Client-Server-Protokoll zum Einsatz. Als Anwendungsschicht-Protokolle werden hauptsächlich https und https eingesetzt. Dies liegt unter anderem daran, dass sich diese im WWW etabliert haben, über einen vergleichsweisen einfachen Aufbau verfügen und mit so gut wie jeder Firewall kompatibel sind. REST vereinheitlicht die Schnittstelle zwischen Systemen auf eine überschaubare und bezüglich des zu erwartenden Verhaltens standardisierte Menge von Aktionen. Welche Aktionen dies sind, ist in REST nicht festgelegt aber alle Aktionen sind allgemein definiert. In der Regel durch die verwendeten Protokolle der Anwendungsschicht.

Während REST als Abstraktion des WWW keine spezielle Implementierung und kein spezielles Protokoll fordert, ist doch zu beobachten, dass fast ausschließlich https zum Einsatz kommt. Dadurch werden auch die Menge der Aktionen festgelegt.

Wird über https zugegriffen, so gibt die verwendete https-Methode, darunter GET, POST, PUT und DELETE, an, welche Operation des Dienstes gewünscht ist. https schreibt vor, dass GET „safe“ (sicher) sein muss, was bedeutet, dass diese Methode nur Informationen beschafft und keine sonstigen Effekte verursacht. Die Methoden GET, HEAD, PUT und DELETE müssen laut https-Spezifikation idempotent (dasselbe) sein, was in diesem Zusammenhang bedeutet, dass das mehrfache Absenden der gleichen Anforderung sich nicht anders auswirkt als ein einzelner Aufruf. Abhängig von der Implementierung können noch weitere https-Befehle unterstützt werden. Dazu gehören COPY, MOVE, MKCOL, LOCK und UNLOCK des WebDAV-Protokolls, sowie LINK und UNLINK aus RFC 2068. Bei der Kommunikation über UDP kann zudem das CoAP aus RFC 7252 statt https eingesetzt werden, welches leicht abweichende Bedeutungen für GET, POST, PUT und DELETE besitzt.

Fazit

Die meisten Unternehmen verwenden den REST-Architekturstil für die Entwicklung / Implementierung von Webdiensten, da es sich um eine einfache und benutzerfreundliche Oberfläche handelt, die weniger Schulung für die vorhandenen / neuen Mitglieder des Projekts erfordert. Unternehmen erwägen REST zusammen mit ihren vorhandenen Webdiensten.

Der Beitrag REST – Schönheit der einfachen Architektur erschien zuerst auf CEOsBay.

Es verfolgt einen dezentralisierten Ansatz, basiert auf den IMAP bzw. SMTP Protokollen und ist, meiner Erfahrung nach, eines der „sichereren“ Messenger Apps, die man heutzutage nutzen kann.

Was ist IMAP?

Das Internet Message Access Protocol (IMAP), ursprünglich Interactive Mail Access Protocol, ist ein Netzwerkprotokoll, dass ein Netzwerkdateisystem für E-Mails bereitstellt.

Was ist SMTP?

Das Simple Mail Transfer Protocol (Einfaches E-Mail-Transportprotokoll), gehört zu der Internetprotokollfamilie, dass zum Austausch von E-Mails in Computernetzen dient)

Durch den Einsatz der E-Mail-Protokolle IMAP und SMTP ist Delta Chat mit jedem herkömmlichen E-Mail-Client kompatibel. Seit Veröffentlichung im Februar 2019 verzeichnet die App im Google Play Store über 100.000+ Downloads. Auch ist die App im Apple App Store verfügbar aber auf die Zahlen haben wir leider keinen Zugriff. Nachdem ein Freund mich darum gebeten hat, heute ein bisschen was über Delta Chat 😉

Wie funktioniert Delta Chat?

Wie anfangs angesprochen, werden die IMAP- und SMTP-Protokolle benutzt. Daher kommt das System ohne Registrierung bzw. Erstellung eines Kontos innerhalb des Messengers selbst und ohne eigene Server aus. Auch wird keine Telefonnummer oder der Zugriff auf das Adressbuch benötigt. Man ist bei der Verwendung nicht auf Nutzer beschränkt, die denselben Dienst verwenden. Folglich kann man damit Nutzer erreichen, die andere Chat-Clients verwenden, da das zugrundeliegende Messaging-Protokoll der offene E-Mail-Standard ist. Alles in allem sehr viel versprechend. Doch zu Beginn habe ich „sichereren“ in Anführungszeichen geschrieben. Bewusst 😉

Dies liegt aber weniger an Messenger selbst, sondern an der E-Mail-Infrastruktur bzw. den zugrundeliegenden Protokollen IMAP und SMTP. Darüber aber nachfolgend mehr.

Verschlüsselung

Bei Nachrichteninhalten wird auf Ende-zu-Ende-Verschlüsselung (E2EE) zur „sichereren“ Kommunikation gesetzt. Unter „E2EE“, versteht man die Verschlüsselung übertragener Daten, über alle Übertragungsstationen hinweg. Nur die Kommunikationspartner (Die jeweiligen Endpunkte der Kommunikation) können die Nachrichten entschlüsseln. Dazu nutzt der Messenger OpenPGP (Ein standardisiertes Datenformat für verschlüsselte und digital signierte Daten). Zertifikate definieren das Format, die als „Schlüssel“ bezeichnet werden. Autocrypt stellt eine weitere Schutzebene dar. Diese Verschlüsselung baut auf dem OpenPGP-Standard auf und ist damit kompatibel. Autocrypt ist ebenfalls eine standardisierte Richtlinie, die eine nutzerfreundliche Verschlüsselung von E-Mails und automatisierten, aber ungesicherten Austausch kryptografischer Schlüssel ermöglicht.

Bei der Verknüpfung eines E-Mail-Kontos generiert Delta Chat bei der Ersteinrichtung automatisch ein Schlüsselpaar. Auch der Import von bereits bestehenden Schlüsseln ist möglich. Mittels Autocrypt werden die öffentlichen Schlüssel anschließend zwischen den Teilnehmern ausgetauscht und ermöglichen damit eine E2EE-Kommunikation. Bei Autocrypt kann theoretisch ein nichtwohlgesonnener E-Mail-Provider diese Verschlüsselung kompromittieren, da Autocrypt grundsätzlich jeden Schlüssel akzeptiert. Dies erfolgt über „Opportunistic Security (RFC 7435)“. Dies werde ich zu einem späteren Zeitpunkt thematisieren, da es den Rahmen sprengen würde. Es ist 06:10 Uhr, Sonntag morgen 😀 – Wen es aber interessiert, kann dennoch auf den Link klicken 😉

MiTM

Auf jeden Fall können wir festhalten, dass das Potential erfolgreicher Man-in-the-Middle-Attacken minimiert wird. Bei einem Man-in-the-Middle-Angriff platziert sich der Angreifer logisch oder physisch zwischen dem Opfer und den verwendeten Ressourcen. Der Angreifer ist dadurch in der Lage, die Kommunikation abzufangen, mitzulesen oder zu manipulieren. Delta Chat erweitert den Autocrypt-Standard daher um countermitm – dadurch wird die Wahrscheinlichkeit einer erfolgreichen Man-in-the-Middle-Attacke auf verifizierte Schlüssel bzw. Kontakte minimiert.

Neben dieser „Schwäche“ kommt hinzu, dass OpenPGP keine Perfect Forward Secrecy beherrscht. (PFS – Perfect Forward Secrecy ist eine Methode für den Schlüsselaustausch kryptografischer Verfahren. Es bewerkstelligt, dass eine nachträgliche Entschlüsselung durch Bekanntwerden des Hauptschlüssels erschwert bzw. ausgeschlossen wird. Die Sitzungsschlüssel werden nicht ausgetauscht und sind nicht mehr rekonstruierbar). Die Schutzziele der „glaubhaften“ Abstreitbarkeit und Folgenlosigkeit sind daher nicht umsetzbar. Um sicher zu stellen, dass man mit seinem wahren Gegenüber kommuniziert, stellt Delta Chat eine Authentifizierung via QR-Code zur Verfügung. Dadurch wird gewährleistet, dass sich kein Dritter zwischenschaltet. Nach der Durchführung des gegenseitigen Scans des QR-Codes, werden die Nutzer als „Verifiziert“ markiert.

Wenn die Empfänger einer Nachricht auch Delta Chat nutzen, werden die Nachrichten automatisch Ende-zu-Ende-verschlüsselt und als Chatnachricht dargestellt. Allerdings erlaubt Delta Chat das Versenden von Nachrichten auch an E-Mail-Postfächer bzw. Kontakte, die kein Delta Chat verwenden. Wenn der Empfänger einen E-Mail-Client verwendet, der nicht Autocrypt-kompatibel ist, werden Nachrichten unverschlüsselt bzw. nur transportverschlüsselt gesendet bzw. empfangen. Das hat den Nachteil, dass ein E-Mail-Provider die so empfangenen / versendeten Nachrichten unter Umständen einsehen kann. Diesen Umstand sollte man unbedingt berücksichtigen bzw. bei der Nutzung von Delta Chat im Hinterkopf behalten. Welche Transportverschlüsselung zum Einsatz kommt, kann in der App eingesehen werden bzw. wird dies im Nachrichtenverlauf mit einem Schloss symbolisiert.

Dezentralisierung

Wie bereits angesprochen, verfolgt Delta Chat den Ansatz der dezentralisierten Kommunikation, da der Nachrichtenaustausch nicht über zentrale Server läuft. Delta Chat setzt auf die bestehende E-Mail-Infrastruktur auf und kann dadurch auf eigene Server verzichten. Die Nutzung von Delta Chat setzt demnach lediglich ein bestehendes E-Mail-Postfach voraus, das mit Delta Chat verknüpft werden muss. Der Nutzer ist also vollkommen frei in seiner Entscheidung, bei welchem E-Mail-Anbieter er ein Konto eröffnet. Die einzige Voraussetzung ist das IMAP-Protokoll.

Fazit

Ist man im Besitz einer E-Mail-Adresse, kann man Delta Chat ohne eine Registrierung und vor allem Serverunabhängig nutzen. Wird Delta Chat von der Gegenseite nicht genutzt, werden Nachrichten an die konventionelle E-Mail-Adresse des Empfängers gesendet. Wenn der Empfänger auch Delta Chat nutzt, bekommt man die Nachricht innerhalb der App angezeigt. Durch diesen Ansatz ist es nicht notwendig, denselben Messenger zu nutzen. Man kann Delta Chat daher auch als interoperablen Messenger nutzen.

Im Grunde genommen eignet sich Delta Chat für Personen, die ihre Telefonnummer nicht teilen wollen. Gleichzeitig kann man sich die Möglichkeit offen halten, über einen Messenger erreichbar zu sein.

Leider ist nicht sichergestellt, dass Nachrichten E2EE verschlüsselt zugestellt werden und damit für einen Angreifer einsehbar sind. Über die Metadaten können die An- und CC-Felder des E-Mail-Headers eingesehen werden. So lässt es sich relativ einfach herausfinden, wer mit wem, zu welchem Zeitpunkt kommuniziert hat. Die Interoperabilität hat durchaus seine Vorteile. Ob die Vorteile dabei die Nachteile überwiegen, darf jeder für sich selbst entscheiden. Alles in allem stellt Delta Chat eine gute Alternative als Instant Messenger dar. Selbst für meinen Geschmack, wird eine gute Portion an Mehrwert für den Dezentralisierungsgedanken leistet.

Der Beitrag Delta Chat – E-Mail neu erfunden erschien zuerst auf CEOsBay.

Was ist Mastodon?

Mastodon, 2016 von dem deutschen Softwareentwickler, Eugen Rochko, aus Berlin, gegründet. Im Gegensatz zu den beliebten kommerziellen Social-Media-Plattformen, ist Mastodon Open Source. Folglich dient die Anwendung im Idealfall dem Ziel, der Öffentlichkeit einen Mehrwert zu schaffen und nicht primär irgendwelchen Aktionären.

Den Begriff Open Source habe ich bereits mehrfach in meinen Beiträgen erwähnt und werde es in einem der nachfolgenden Beiträge genauer erklären. Laut seiner Aussagen in seinem Blog arbeitete Eugen Rochko 5 Jahre lang als Einzelunternehmer an dem Projekt, mit dem er unter anderem auch seinen Lebensunterhalt bestritt, bevor er sich als Angestellter des gegründeten Unternehmens ein Gehalt ausgezahlt hat. 8 Jahre sollen die juristischen Angelegenheiten für die ordnungsgemäße Gründung gefressen haben.

(Hatte ich schon erwähnt, wie toll Deutschland als Gründungsland und Tech-Standort funktioniert? 😉)

Laut seiner Aussagen, konnten mehr Ressourcen für Dinge wie die Einstellung zusätzlicher Entwickler, UX-Designer, die Entwicklung offizieller Apps usw. aufgebracht werden. Im Juni 2021 konnte dann die Mastodon gGmbH (gemeinnützige Gesellschaft mit beschränkter Haftung) offiziell eingetragen werden. Eine kurze Erklärung, was eine gGmbH ist, erfolgt gleich im Anschluss.

Was ist eine gGmbH?

Eine gemeinnützige Gesellschaft mit beschränkter Haftung ist im Grunde genommen ähnlich strukturiert wie eine gewinnorientierte Gesellschaft mit beschränkter Haftung.

Mit ein paar wichtigen Unterschieden:

• Die Gründungsurkunde der Gesellschaft ist so verfasst, dass die Tätigkeit der Gesellschaft auf Ziele ausgerichtet ist, die der Allgemeinheit zugute kommen
• Die Gesellschafter dürfen keine Einkünfte aus der Tätigkeit der Gesellschaft erhalten und können höchstens die Gelder abheben, die sie ursprünglich eingezahlt haben
• Die Mitarbeiter dürfen keine außerordentlich hohen Löhne erhalten und die Gesellschaft kann Spenden erhalten, die dann steuerfrei sind, obwohl alle anderen Einkünfte, die nicht der Definition einer Spende entsprechen, weiterhin mit verschiedenen Steuern belegt werden
• Um eine solche juristische Person zu gründen, muss die Gründungsurkunde einer Prüfung durch das Finanzamt standhalten und die Gründer müssen ein Startkapital von 25.000 EUR einzahlen, wie es bei einer GmbH üblich ist.

Weiter mit „Was Mastodon eigentlich ist…“

Mastodon mag auf den ersten Blick wie ein Twitter-Klon aussehen aber das System hinter der Microblogging-Plattform ist etwas komplexer. Der Dienst ist dezentralisiert. Nicht im Sinne einer Blockchain. Die werde ich auch noch genauer unter die Lupe nehmen und in einem Beitrag thematisieren. Sie beschreibt sich selbst als „Federation“. Mit Föderation, in diesem Kontext, ist eine Form der Dezentralisierung gemeint, die anstelle eines zentralisierten Dienstes, den alle Menschen nutzen, mehrere Dienste, die von einer beliebigen Anzahl von Menschen zur Verfügung gestellt und genutzt werden kann.

Eine Mastodon-Webseite kann selbstständig funktionieren. Genau wie bei einer herkömmlichen Webseite, melden sich die Benutzer*Innen an, posten Nachrichten, laden Bilder hoch und sprechen miteinander. Im Gegensatz zu einer herkömmlichen Webseite können jedoch Mastodon-Webseiten mit den Nutzern interagieren und auch ihre Nutzer können untereinander kommunizieren. So als ob man eine E-Mail von einem Gmail-Konto an jemanden schickt, der bei beispielsweise bei Fastmail, ProtonMail oder einem anderen E-Mail-Anbieter registriert ist. Solange man die Adresse des Empfängers kennt, kann man jeden auf einer beliebigen Seite mit seiner Adresse erwähnen oder benachrichtigen.

Wie läuft die Sache mit der Registrierung/Anmeldung?

Wenn man ein Konto zum ersten Mal erstellt, wählt man einen Server aus (Ähnlich wie bei der Eröffnung eines E-Mail-Kontos bei einem Provider), der die Adresse des Profils generiert. Wenn man sich zum Beispiel über den „ioc.exchange“ bei Mastodon anmeldet, lautet die Adresse @[Benutzername]@ioc.exchange. Unabhängig davon, bei welchem Server man sich anmeldet, kann man mit Benutzern von anderen Servern kommunizieren, so wie Gmail-Nutzer beispielsweise Protonmail-Nutzer anschreiben und umgekehrt. Allerdings kann es sein, dass einige Server andere Server blockieren, da sie nicht so ganz miteinander klarkommen (Gründe hierfür sind beispielsweise Interessenkonflikte). Folglich kann mit niemandem eines blockierten Servers kommunizieren werden.

Das Mastodon Jargon bzw. die Fachsprache

Mastodon-Benutzer bezeichnen die einzelnen Gemeinschaften im Allgemeinen als „Instanzen“ oder Server. Diese Mastodon-Server können von Einzelpersonen, Gruppen oder Organisationen erstellt und betrieben werden, die jeweils ihre eigenen Regeln für die Anmeldung von Benutzern sowie ihre eigenen Moderationsrichtlinien haben. Bei einigen Servern kann jeder mitmachen, während andere nur auf Einladung oder mit Genehmigung eines Administrators betrieben werden. Ein Server für professionelle Wissenschaftler verlangt beispielsweise, dass die Bewerber einen Link zu ihrer Forschung angeben, um zu zeigen, dass sie tatsächlich in einem professionellen akademischen Kontext bzw. Umfeld arbeiten.

Die Wahl des Servers, auf dem man das eigene Konto registrieren möchte, mag aufwändig erscheinen – Aber es ist möglich, das Konto später wieder zu verschieben. Aus diesem Grund ist die Auswahl des Servers nicht fundamental bzw. unumkehrbar. Außerdem kann man nach wie vor anderen Personen folgen, unabhängig davon, auf welchem Server man sich befindet.

Mastodon verwendet ein standardisiertes, offenes Protokoll zur Umsetzung des Verbunds. Es wird als ActivityPub bezeichnet. Jede Software, die von und durch die Federation über ActivityPub implementiert wird, kann nahtlos mit Mastodon kommunizieren, genau wie Mastodon-Webseiten miteinander kommunizieren.

Das Fediverse („federated universe“) ist die Bezeichnung für alle Webseiten, die über ActivityPub und das www (World Wide Web) miteinander kommunizieren können. Dazu gehören alle Mastodon-Server und auch andere Implementierungen wie:

• Pleroma – Ein modulares Microblogging-System
• Pixelfed – Eine föderierte Plattform für die gemeinsame Nutzung von Bildern, mit der man Medienbeiträge teilen und konsumieren kann
• Misskey – Das neben Microblogging auch ein anpassbares Dashboard enthält
• PeerTube – Mit dem man Videos in Kanäle hochladen kann
• Plume – Mit dem man längere Artikel veröffentlichen kann
• Und viele mehr, da es sich um individuelle und persönliche Webseiten handelt

Mastodons Äquivalent von Tweets werden als „Toots“ bezeichnet. Doch dieser Begriff scheint nicht mehr so beliebt zu sein und wird von den Nutzern eher als „Posts“ bezeichnet. Dennoch wird der Begriff „Toot“ immer noch auf älteren Clients von Drittanbietern verwendet.

Es unterstützt eine Reihe von Twitter-Konventionen wie Antworten, Retweets, Favoriten, Lesezeichen und Hashtags. Aber Retweets werden als „Boosts“ bezeichnet und es unterstützt nicht das Konzept der Zitat-Tweets. Dies war eine bewusste Entscheidung des Gründers. Seiner Meinung nach ermutigt es das Individuum mit der Audienz zu interagieren, statt mit einer spezifischen Person.

Auch die Mastodon-Listen scheinen etwas anders zu funktionieren als bei Twitter, da man nur Personen zu einer Liste hinzufügen kann, denen man bereits folgt. Und Direktnachrichten auf Mastodon sind nur Beiträge mit dem @Benutzernamen, keine privaten Nachrichten, die in einem DM-Posteingang landen.

Was klassifiziert Mastodon als Open Source?

Jeder kann Mastodon herunterladen, verändern und auf seinem eigenen Server installieren – Das Urheberrecht liegt nicht bei den Entwicklern der Plattform.

Dies bedeutet jedoch nicht, dass man den Code von Mastodon ohne Quellenangabe einfach so übernehmen kann, wie die Social-Media-Plattform des ehemaligen Präsidenten Donald Trump, „Truth“ im Jahr 2021, die Runde machte. Freie Software steht in der Regel unter der Lizenz AGPL. Diese erlaubt es, den Code zu benutzen und zu verändern, wenn man sich dabei an die Lizenzvereinbarungen hält. Die AGPL-Lizenz schreibt vor, dass die Software auch nach ihrer Veränderung öffentlich zugänglich bleibt. Das soll verhindern, dass kommerzielle Anbieter*Innen sich den Code aneignen, ohne der Allgemeinheit etwas zurückzugeben.

Gibt es im Vergleich zu Twitter irgendwelche Nachteile?

Soweit ich es beurteilen kann, ist die Nutzerbasis von Mastodon im Vergleich zu Twitter immer noch sehr klein. Es ist vergleichsweise auch weitaus weniger intuitiv zu bedienen, da es nicht für ein großes globales Publikum wie Twitter ausgelegt ist. Dies kann sich aber mit der Zeit ändern. Vor allem dann, wenn sich dem Projekt mehr Entwickler anschließen.

Und da die Ausstattung, damit sind die Hardware-Ressourcen gemeint, von Mastodon noch nicht so gut ist wie die von Twitter, funktioniert es scheinbar hin und wieder nicht so gut. In den letzten Tagen war der Dienst zeitweise träge, wenn nicht sogar völlig zum Stillstand gekommen, da sich die Server an den massiven Zustrom neuer Nutzer erst anpassen mussten. Dies kann sich auch auf andere Bereiche der Nutzung auswirken. Vor allem wenn man versucht, auf die Schnelle eine Reihe von Freunden auf dem Dienst zu folgen, und feststellt, dass man zwischendurch warten muss, weil Restriktionen auftreten.

Was sind die Vorteile von Mastodon im Vergleich zu Twitter?

Allem voran, es ist Open Source und vor allem dezentral. Ob es dem Twitter-Hype gleichkommt, kann ich mir persönlich nicht vorstellen. Einige Nutzer können Mastodon jedoch Twitter vorziehen, da es von Natur aus individueller anpassbar ist. Im Gegensatz zu Twitter haben die einzelnen Communities unterschiedliche Inhaltsrichtlinien, die eine Vielzahl von unterschiedlichen Nutzererfahrungen ermöglichen, die man so bei Twitter nicht hat. Und obwohl die Nutzerbasis auf Mastodon kleiner ist, kann dies manchmal zu persönlicheren und direkteren Gesprächen führen, als wenn man sozusagen ins Leere tweetet.

Wie steht es mit der Sicherheit?

Mastodon ist das, was man daraus macht. Aufgrund des dezentralen Charakters von Mastodon, kann man den eigenen Wünschen entsprechend, ein kontrolliertes Online-Erlebnis, mit strengeren Schutzmaßnahmen gegen Belästigungen erschaffen, wenn man einen Server erstellt. Einige Mastodon Funktionen existieren explizit für die Eindämmung von Belästigungen. Man kann zum Beispiel nur nach Hashtags suchen. Nicht aber nach Wörtern, die in einem Beitrag vorkommen. Wenn man also möchte, dass ein Beitrag auffindbar ist, kann man es taggen. Wenn das Publikum eingeschränkt werden soll, kann niemand den Tweet über beispielsweise „Teureres Parfüm“ finden, indem nach „Teureres Parfüm“ gesucht wird, wenn es nicht getagged wurde.

Eine textbasierte Suche kann jedoch Beiträge anzeigen, die man selbst geschrieben, favorisiert oder geboosted hat. Auch sind die Beiträge auffindbar, in denen jemand die eigene Person erwähnt oder getagged hat..

Der Dienst verfügt über eine weitere praktische Funktion, die es Nutzern ermöglicht, direkt im Erstellungsfeld eine Inhaltswarnung zu einem Beitrag hinzuzufügen. Einige Mastodon-Nutzer haben sich in letzter Zeit einen Spaß daraus gemacht und andere gewarnt, dass ihr Beitrag ein Twitter-Drama zum Inhalt hat.

Können Bilder/Medien gepostet werden?

Wie bereits erwähnt, unterstützt Mastodon viele Twitter-Konventionen. Die Unterstützung für Medien ist jedoch relativ begrenzt. Twitter untertützt eine Vielzahl von Medien und anderen Daten, die man an Tweets angehängten kann. Einschließlich der eignen sozialen „Spaces“, die Audio, Fotos, Videos, GIFs, Umfragen, genaue Ortsangaben und experimentelle „Status“-Tags enthalten. Mastodon unterstützt lediglich Bilder, Videos, Audio und Umfragen.

Man kann einem Beitrag bis zu vier Bilder mit einer Größe von bis maximal 8 Megabyte hinzufügen. Videos und Audiodateien können beliebig lang sein, die Dateigröße ist jedoch auf 40 Megabyte begrenzt.

Kann man privat Freunden schreiben/posten?

Ähnlich wie bei Twitter soll es den Nutzern möglich sein, die Sichtbarkeit der Tweets durch die „Circle-Funktion“ einzuschränken. So bietet Mastodon die Möglichkeit, die Privatsphäre eines Beitrags zum Zeitpunkt der Erstellung festzulegen. Beiträge können so eingestellt werden, dass sie für alle sichtbar sind. Auch so, dass sie nicht gelistet werden. Man kann sie von den „discovery features“ ausschließen. Nur für die eignen Follower sichtbar machen oder nur für die ausschließlich erwähnten Nutzer sichtbar machen.

Kann man wie bei „Twitter-Blue“ verifiziert werden?

Es gibt kein universelles Verifizierungssystem wie bei Twitter. Einige Server überprüfen die Benutzeranmeldungen und man kann sich in gewisser Weise selbst verifizieren. Dies macht man, indem man Links zu dem eigenen Mastodon-Profil hinzufügt. Diese müssen ein bestimmtes Attribut (rel=“me“) haben, um zu beweisen, dass man die Person ist, die man vorgibt zu sein.

Einige Server machen sich zurzeit mit der Verifizierung auf eine weniger offizielle Art und Weise einen Spaß. Auf dem Server mstdn.social kann man beispielsweise dem Anzeigenamen blau-weiße Häkchen und andere Emoji hinzufügen, die einen verifiziert aussehen lassen, obwohl diese Emojis keinerlei Bedeutung haben – So ähnlich wie das neue Verifizierungssystem von Twitter, nur kostenlos! 😉

Ist Mastodon hier, um zu bleiben?

Mastodon erfährt einen massiven Zustrom neuer Nutzer von Twitter. So viel ist jedenfalls klar. Ob sich dieses Wachstum fortsetzen kann, wird sich zeigen. Mit nur 1,8 Millionen Nutzern am Tag ist Mastodon weitaus kleiner als Twitter, welches Stand heute über 206 Millionen täglich aktive Nutzer zählt, die darüber hinaus auch noch monetisiert werden können. Dennoch sind nicht alle sozialen Netzwerke gleich und vielleicht zieht man es auch vor, auf einem eigenen Server über Spiele zu plaudern, anstatt in ein Reich des Wahnsinns zu twittern. Oder aber man ist fasziniert von dezentralisierten Systemen und macht allein schon aus diesem Grund mit.

Kann man von Twitter zu Mastodon cross-posten?

Ja, dies scheint mithilfe von Tools von Drittanbietern möglich zu sein. So kann man mit den gängigen Autorisierungen, Twitter-Posts direkt zu Mastodon weiterleiten. Hierzu gibt es bereits einige Repositories auf GitHub, die man dafür nutzen kann. Auf GitHub und Repositories gehe ich in einem späteren Beitrag ein.

Fazit

Alles in allem finde ich Open Source Anwendungen grundsätzlich gut. Ob sich Mastodon durchsetzen wird, lässt sich in diesem Augenblick wohl eher schlecht als recht sagen. Auch sollte man nicht vergessen, dass sich im Jahr 2019 das rechtsradikale Netzwerk „Gab“ mit ungefähr einer Millionen Nutzer*Innen auf Mastodon niederließ und damit eines der größten Knotenpunkte darstellte. Aus diversen Foren habe ich erfahren, dass Administratoren vieler Instanzen Gab blockiert haben (Hierfür ist ein einfacher Eintrag in den Einstellungen der jeweiligen Instanz nötig).

Folglich wurden Nachrichten „Toots“ von Gab nicht mehr weitergeleitet, man konnte die Nachrichten auch nicht mehr in der öffentlichen Timeline sehen und man konnte Gab Nutzer nicht suchen bzw. finden. Die Entwickler*Innen von Mastodon selbst distanzierten sich umgehend von Gab. Ich bin jetzt auf jeden Fall mal dabei und werde mich die Tage, falls ich etwas Zeit finde, mehr damit beschäftigen. So gesehen, war ich bereits ende 2018 mal online, doch irgendwie wurde der Server scheinbar gelöscht. Heute findet man mich auf Mastodon über @coezbay@ioc.exchange – Erst einmal nicht so aktiv und eher aus Forschungszwecken dabei 😉

Der Beitrag Mastodon – Open Source Twitter Alternative erschien zuerst auf CEOsBay.