staging.inyokaproject.org

Linux und Open Source ist für seine transparente Entwicklung bekannt. Blogbeiträge, Ankündigungen und Updates ergießen sich einem steten Strom gleich über den interessierten Anwender. Die wirklich interessanten Projekte haben es da schwer hervorzutreten, deshalb möchte ich hier eine kleine Vorschau auf einige Projekte geben, die eine nähere Betrachtung verdienen.

Spracherkennung / Assistenten

Dieser Bereich ist momentan omnipräsent und leider dominiert durch Alexa, Siri & Co. Allesamt cloud-gebunden, proprietär und daher eigentlich nur als Wanzen getarnte Lifestyle-Produkte (siehe auch: Wanzen für das Wohnzimmer mit Firmen-Branding). Zwei Projekte haben zumindest eine minimale Chance dem etwas entgegen zu setzen. Das erste ist Mozillas Common Voice, eine freie Datenbank zur Spracherkennung. Hoffentlich gehört das nicht zu den Projekten die Mozilla schnell wieder beerdigt. Ebenfalls Potenzial hat Mycroft, die im ersten Quartal 2019 den Mycroft Mark II veröffentlichen wollen. Das Projekt ist seinen Kinderschuhen definitiv noch nicht entwachsen, aber momentan die alltagstauglichste Open Source Software in diesem Bereich. Die Software ist allerdings nicht auf den Assistenten beschränkt, sondern lässt sich theoretisch auch auf einem normalen Betriebssystem installiert. Die Entwickler von KDE haben dafür zwischenzeitlich auch ein Plasmoid für die Desktopintegration veröffentlicht.

Purism Librem 5

Der Smartphone-Markt ist hinsichtlich Datenschutz und Open Source in einem wirklich schlimmen Zustand. Hoffnungsvoll gestartete Projekte wie SailfishOS, Ubuntu Phone, Plasma Mobile etc. pp. siechen vor sich hin oder wurden offiziell beerdigt (siehe auch: Freie Mobilbetriebssysteme - Ein Trauerspiel). Den Markt teilen sich Apples iOS und Googles Android nahezu vollständig auf. Selbst die proprietären Konkurrenten BlackBerry und Microsoft haben zwischenzeitlich aufgegeben. Das Apple-Betriebssystem iOS ist zwar sicher, aber hochgradig geschlossen und Googles Android ist hinsichtlich Datenschutz und Sicherheit eine Katastrophe.

Purism möchte dem sein Librem 5 entgegen setzen. Ein Smartphone mit offener Hardware und einem gänzlich neuen Betriebssystem auf Linux-Basis. Die ersten fertigen Modelle sind für 2019 angekündigt. Dann lässt sich sicherlich auch mehr zur Alltagstauglichkeit sagen. Manche Ankündigungen, wie die Entscheidung für GNOME (das zu dem Zeitpunkt überhaupt nicht mobil-tauglich war) und jetzt Flatpak-Apps stimmen da leider skeptisch.

Linux

Die Linux-Entwicklung auf dem Desktop ist ziemlich erlahmt - das betrifft alle Distributionen und Desktopumgebungen. Für Anwender muss das nichts schlechtes bedeuten, immerhin werden Fehler behoben und kleinere Funktionsupdates vorgenommen. Ein großer Wurf steht 2019 aber nicht in Aussicht, ggf. wird Wayland ein bisschen alltagstauglicher.

Zwei Projekte bekommen jedoch zu wenig Aufmerksamkeit. Erstens ist dies elementary OS (siehe auch: elementaryOS - Wenigstens eine Vision für den Desktop). Die dortigen Entwickler haben eine Vision für ihren Desktop (die sich optisch zugegebenermaßen stark an macOS orientiert) und setzen diese um. Es gibt eine konsistente Bedienoberfläche, einen funktionsfähigen App Store und interessante neue Apps. Das ganze umgesetzt von einem kleinen Team, was zeigt wie ineffektiv, ideenlos und uninspiriert die restliche Desktopentwicklung im Linux-Bereich abläuft. Es lohnt sich die Entwicklung im Auge zu behalten.

Das zweite Projekt ist der Budgie Desktop von Solus, der inzwischen auch für andere Distributionen zur Verfügung steht. Gegenwärtig ist das quasi eine alternative GNOME Shell, da man fast alle Programme von dort entlehnt. Die Desktopumgebung macht bisher einen guten Eindruck und für 2019 hat man die Entwicklung der Version 11 ins Auge gefasst.

Sonstiges

Neuigkeiten von Fairphone bezüglich eines Modell 3 wären interessant und eine Präzisierung der Pläne inwieweit die Distributionen eine Integration der neuen Paketformate Flatpak und Snap anstreben (siehe auch: Neue Paketformate - Der Weg ist noch weit). UBports schraubt momentan fleißig an der übernommen Ubuntu Phone-Basis. Mal schauen, ob sie die Schlagzahl halten und das Projekt auf ein zeitgemäßes Niveau bringen können.

Bilder:
Einleitungs- und Beitragsbild von A_Different_Perspective via pixabay

Der Enterprise Policy Generator richtet sich an Administratoren von Unternehmen und Organisationen, welche Firefox konfigurieren wollen. Damit löst die Erweiterung den bekannten CCK2 Wizard in der Ära Firefox Quantum ab. Die neue Version 4.3 macht den Enterprise Policy Generator fit für die aktuellen Firefox-Releases.

Download Enterprise Policy Generator für Firefox

Mit Firefox 60 und Firefox ESR 60 hat Mozilla die sogenannte Enterprise Policy Engine eingeführt. Die Enterprise Policy Engine erlaubt es Administratoren, Firefox über eine Konfigurationsdatei zu konfigurieren. Der Vorteil dieser Konfigurationsdatei gegenüber Group Policy Objects (GPO) ist, dass diese Methode nicht nur auf Windows, sondern plattformübergreifend auf Windows, Apple macOS sowie Linux funktioniert.

Zwar steht diese Erweiterung in keiner direkten Verbindung zum bekannten CCK2 Wizard, teilt aber die grundlegende Idee vom CCK2 Wizard, welcher in Firefox Quantum nicht mehr funktioniert. Der Enterprise Policy Generator wurde als Nachfolger vom CCK2 Wizard konzipiert – nur eben für Firefox Quantum und Enterprise Policies. Die Firefox-Erweiterung hilft bei der Zusammenstellung der sogenannten Enterprise Policies, so dass kein tiefergehendes Studium der Dokumentation und aller möglichen Optionen notwendig ist und sich Administratoren die gewünschten Enterprise Policies einfach zusammenklicken können. Mehr Informationen gibt es auf der Info-Seite zum Enterprise Policy Generator.

Neuerungen Enterprise Policy Generator 4.3.0

Wie immer gemeinsam mit neuen Firefox-Versionen – morgen werden Firefox 65 und Firefox ESR 60.5 veröffentlicht – steht auch eine neue Version des Enterprise Policy Generators zur Verfügung.

Der Großteil der Änderungen fand dieses Mal unter der Haube statt, um die Voraussetzungen für die neu unterstützten Policies zu schaffen.

Die neuen Firefox-Versionen beinhalten dieses Mal keine neuen Enterprise Policies, dafür unterstützt der Enterprise Policy Generator 4.3 nun die SecurityDevices-Policy zum Hinzufügen von PKCS #11 Sicherheits-Modulen, von Firefox seit Firefox 64 beziehungsweise Firefox ESR 60.4 unterstützt.

Außerdem werden mit dem Update die beiden neuen Policies SSLVersionMin sowie SSLVersionMax zum Festlegen der mindestens erforderlichen respektive maximal unterstützten TLS-Version unterstützt. Diese beiden Policies funktionieren ab Firefox 66.

Roadmap

Wer sich für die Pläne der kommenden Versionen interessiert, findet hier die aktuelle Roadmap. Auch können an dieser Stelle Vorschläge für Verbesserungen gemacht werden.

Entwicklung unterstützen

Wer die Entwicklung des Add-ons unterstützen möchte, kann dies tun, indem er der Welt vom Enterprise Policy Generator erzählt und die Erweiterung auf addons.mozilla.org bewertet. Auch würde ich mich sehr über eine kleine Spende freuen, welche es mir ermöglicht, weitere Zeit in die Entwicklung des Add-on zu investieren, um zusätzliche Features zu implementieren.

Der Beitrag Firefox: Enterprise Policy Generator 4.3 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

Unter Linux sowie anderen unixoden Betriebssystemen greift man für Kopiervorgänge in der Regel auf cp zurück. Ein Kommando zum Kopieren von Dateien entspricht dann unter z.B. Debian nachfolgendem Schema:

cp -rv source dest

Nachteil dieser Variante: man sieht zwar, welche Dateien bereits kopiert wurden, es fehlt allerdings eine Fortschrittsanzeige, die insbesondere bei größeren Kopiervorgängen hilfreich wäre.

Abhilfe schafft hierfür rsync. Die genauere Bedienung wird im ubuntuusers.de-Wiki erläutert, im Kern geht es aber um die Option --info=progress2, welche eine Fortschrittsanzeige aufruft.

rsync -a --info=progress2 source dest

Das Flag -a steht sinngemäß für archive und ist ein Alias für einige weitere Optionen, darunter rekursives kopieren sowie preserve, also der Erhalt der Metadaten wie Modification Time, Owner, etc. (soweit es das Dateisystem erlaubt)

Update [28.01. 19:00 Uhr]: die Optionen -r und -v gibt es unter einigen unixoden Systemen nicht, deswegen habe ich das Codebeispiel auf Debian als Beispiel eingeschränkt. (Vielen Dank tux.!)

Diskussionen über das Für- und Wider von Linux und Windows landen mit hoher Wahrscheinlichkeit irgendwann bei Microsoft Office. Linux-Enthusiasten halten dann meist dagegen, dass man mit LibreOffice ein vollwertiges Office-Paket hat und kaum jemand wirklich Microsoft Office benötigt. Eine Erhebung zur Relevanz von Microsoft Office gibt es jedoch nicht.

Eine solche Relevanz zu messen ist auch sehr schwierig und vermutlich unmöglich zu leisten - sie kann deshalb auch hier nicht erfolgen. Trotzdem sollte man das Thema im Blick haben, wenn man die Vor- und Nachteile alternativer Betriebssysteme wie Linux abwägt.

Vor wenigen Tagen stellte Microsoft seine Office Suite im Mac App Store zur Verfügung (was man bei der WWDC 2018 ankündigte). Allerdings mit einigen Beschränkungen: Erstens fehlen natürlich einige Bestandteile wie beispielsweise Access und zweitens gibt es nur die Office 365 genannte Abo-Version (das Abo muss allerdings nicht im Store erworben werden). Trotz dieser Beschränkungen ist Microsoft Office binnen weniger Tage an die Spitze der Charts geschossen. Genaue Zahlen liegen natürlich nicht vor.

Apple-Anwender sind mit Sicherheit nicht so Microsoft-fixiert wie Windows-Nutzer und man kann anhand der Charts getrost davon ausgehen, dass viele mit dem iWork-Paket zufrieden sind. Trotzdem erfreut sich Microsoft Office riesiger Beliebtheit und der Store bildet sicherlich nicht die kompletten Installationszahlen ab, da die normal lizenzierten Versionen weiterhin per Installationsroutine installiert werden müssen. Eine Möglichkeit, die für die Abo-Variante selbstverständlich auch weiterhin besteht.

LibreOffice gibt es übrigens auch im Mac App Store - die Vanilla Variante liegt zur Zeit auf Platz 96 der kostenpflichtigen Apps. Der Vergleich ist leider nicht direkt möglich, da die App lediglich kostenpflichtig im App Store zur Verfügung steht und im Internet kostenlos heruntergeladen werden kann.

Von diesen Beobachtungen ausgehend muss man wohl leider konstatieren, dass Microsoft Office eine große Bedeutung, weit über das Windows-Ökosystem hinaus hat. Es ist und bleibt ein riesiger Nachteil für Linux, dass Microsoft Office nur über den Umweg Wine / Crossover zur Verfügung steht.

Der Verfügbarkeit von Microsoft Office bzw. die perfekte Kompatibilität der erzeugten Dokumente (siehe auch: Limitationen freier Software - OOXML in LibreOffice und Pages) ist leider zu oft der Stolperstein für eine erfolgreiche Migration auf ein anderes System.

Da helfen leider auch die Verweise auf den Funktionsumfang von LibreOffice und der proprietären Alternative Softmaker Office (siehe auch: Softmaker Office 2018 - Proprietäre Officelösung für Linux, macOS und Windows) nicht. Von jenen Experten, die LaTeX für den Nabel der Welt halten mal ganz abgesehen.

Angesichts der Erhebung von Telemetriedaten in Windows 10, sowie seit vergangenem Jahr auch in Office (siehe auch: Kommentar: Auf Windows folgt Office - Telemetriedaten ohne Opt-out), ist das eine sehr bedauerliche Situation.

Bilder:
Einleitungs- und Beitragsbild von andreas160578 via pixabay

Webseiten, welche automatisch Töne von sich geben, gehören ab Firefox 66 standardmäßig der Vergangenheit an – sowohl am Desktop als auch auf Android.

Die automatische Wiedergabe von Ton auf Webseiten zu unterbinden, ist für Firefox-Nutzer kein komplett neues Thema. Bereits in Firefox 41 gab es hinter einem versteckten Schalter eine erste Implementierung eines Autoplay-Blockers.

In der Zwischenzeit hat sich einiges getan. So wurde die Logik, wann die Wiedergabe blockiert wird, optimiert. Firefox folgt dabei einem sogenannten User-Gesten-Aktivierungs-Modell, bei welchem die automatische Wiedergabe von Sound zunächst deaktiviert ist, aber aktiviert wird, wenn der Nutzer mit der Seite interagiert.

Ein Beispiel: Der Nutzer klickt auf einer Webseite den Link zu einem YouTube-Video an. Firefox verhindert die automatische Wiedergabe des Videos. Der Nutzer klickt dann auf YouTube ein anderes Video an. Da angenommen werden kann, dass sich der Nutzer bewusst auf der Webseite bewegt und das Video anklickt hat, um es abzuspielen, wird dieses Video automatisch wiedergegeben und die Wiedergabe nicht blockiert.

Neu ist auch, dass es nun eine sichtbare Option in den Firefox-Einstellungen gibt, um den Autoplay-Blocker aktivieren respektiere zu deaktivieren.

In den Einstellungen gibt es auch eine Ausnahmeliste. Dort können sowohl Webseiten festgelegt werden, welche Medien trotz aktiviertem Autoplay-Blocker automatisch abspielen, als auch Webseiten, deren automatische Wiedergabe trotz deaktiviertem Autoplay-Blocker blockiert wird.

Ein Hinzufügen von Ausnahmen ist nicht nur über die Firefox-Einstellungen möglich, sondern auch direkt auf der entsprechenden Webseite über das Info-Symbol in der Adressleiste von Firefox.

Neben der Aktivierung oder Deaktivierung des Autoplay-Blockers konnte seit Firefox 63 über eine versteckte Einstellung noch eine dritte Option getestet werden: Damit hatte Firefox auf jeder Webseite, welche eine automatische Wiedergabe starten wollte, den Nutzer gefragt, ob er dies möchte. Diese Option hat Mozilla in Firefox 66 wieder entfernt, nachdem diese Möglichkeit im Nutzer-Feedback durchgefallen war.

Der Autoplay-Blocker wird ab Firefox 66 standardmäßig aktiviert sein, zunächst allerdings nur für 25 Prozent der Nutzer. Eine Erhöhung auf 50 Prozent soll am Ende der ersten Woche erfolgen, ehe das Feature dann am Ende der zweiten Woche für alle Nutzer aktiviert werden soll – immer vorausgesetzt, es werden keine größeren Probleme festgestellt.

Auch in Firefox 66 für Android wird der Autoplay-Blocker standardmäßig aktiviert werden. Hier steht die Ausrollungsweise noch nicht final fest, aber vermutlich wird hier das Feature vom ersten Tag an für alle Nutzer aktiviert werden. Firefox 66 erscheint nach aktueller Planung am 19. März 2019.

Der Beitrag Firefox 66 blockiert automatische Sound-Wiedergabe auf Webseiten erschien zuerst auf soeren-hentzschel.at.

Es gibt zwei Möglichkeiten, sich bei MediaWiki einzuloggen,

• per api.php
• als „normaler“ User (über die index.php)

api.php

Diese Variante setzt voraus, dass du Special:BotPasswords für deinen Account vergeben hast. Mit der API-Methode ist wirklich nur die api.php erreichbar. Versucht man mit der Session die index.php zu erreichen, erhält man die Meldung „Du musst angemeldet sein!“

Zunächst die Anmeldung, weche wir in einer request.session speichern:

#!/usr/bin/env python3
import requests
username 		= 'produnis'					# Username to login with
botpwd 			= 'myapibot@foobarfoobarfoobars52o8mk8apimpsb8'	# Password of Special:BotPasswords in the style BOTNAME@password

api_url   = "https://my.wiki.ltd/api.php"
session = requests.Session()
r1 = session.get(api_url, params={
    'format': 'json',
    'action': 'query',
    'meta': 'tokens',
    'type': 'login',
})

r2 = session.post(api_url, data={
    'format': 'json',
    'action': 'login',
    'lgname': username,
    'lgpassword': botpwd,
    'lgtoken': r1.json()['query']['tokens']['logintoken'],
})
if r2.json()['login']['result'] != 'Success':
    raise RuntimeError(r2.json())

Nun kann die API wie folgt aufgerufen und ausgelesen werden:

MyParams = {
	"action": "query",
	"format": "json",
	"prop": "pageprops",
	"titles": "Kategorie:Hauptkategorie"
}
mycontent = session.get(api_url, params=MyParams)
mydata=mycontent.json
print("i got: ", mydata()['query']['pages'])

index.php

Wenn wir die index.php nutzen wollen, zB um die Mpdf-Extension aufzurufen, müssen wir uns anders einloggen:

#!/usr/bin/env python3
import requests
from bs4 import BeautifulSoup as bs

username 		= 'produnis'					# Username to login with
userpwd			= 'SuperSecreet'				# Userpassword
botpwd 			= 'myapibot@foobarfoobarfoobars52o8mk8apimpsb8'	# Password of Special:BotPasswords in the style BOTNAME@password

api_url   = "https://my.wiki.ltd/api.php"
index_url = "https://my.wiki.ltd/index.php"

payload = {
	'wpName': username,
	'wpPassword': userpwd,
	'wploginattempt': 'Log in',
	'wpEditToken': "+\\",
	'title': "Special:UserLogin",
	'authAction': "login",
	'force': "",
	'wpForceHttps': "1",
	'wpFromhttp': "1",
    #'wpLoginToken': '',
	}

def get_login_token(raw_resp):
	soup = bs(raw_resp.text, 'lxml')
	token = [n.get('value', '') for n in soup.find_all('input')
		if n.get('name', '') == 'wpLoginToken']
	return token[0]

with requests.session() as s:
	resp = s.get(index_url + '?title=Spezial:UserLogin')
	payload['wpLoginToken'] = get_login_token(resp)
	response_post = s.post(index_url + '?title=Spezial:UserLogin&action=submitlogin&type=login', data=payload)

Nun können Seiten ausgerufen werden per:

	response = s.get(index_url + '?title=Special:Watchlist')

Weblinks

• https://stackoverflow.com/a/38378803/1493264 how to login to Mediawiki with Python
• https://www.mediawiki.org/wiki/User:Produnis/Login_to_MediaWiki_using_Python
• https://github.com/produnis/myscripts/blob/master/python/mwc2pdf.py

share this

Es gibt zwei Möglichkeiten, sich bei MediaWiki einzuloggen,

• per api.php
• als “normaler” User (über die index.php)

    #!/usr/bin/env python3
    import requests
    username        = 'produnis'                    # Username to login with
    botpwd          = 'myapibot@foobarfoobarfoobars52o8mk8apimpsb8' # Password of Special:BotPasswords in the style BOTNAME@password
    
    api_url   = "https://my.wiki.ltd/api.php"
    session = requests.Session()
    r1 = session.get(api_url, params={
        'format': 'json',
        'action': 'query',
        'meta': 'tokens',
        'type': 'login',
    })
    
    r2 = session.post(api_url, data={
        'format': 'json',
        'action': 'login',
        'lgname': username,
        'lgpassword': botpwd,
        'lgtoken': r1.json()['query']['tokens']['logintoken'],
    })
    if r2.json()['login']['result'] != 'Success':
        raise RuntimeError(r2.json())
    

    MyParams = {
        "action": "query",
        "format": "json",
        "prop": "pageprops",
        "titles": "Kategorie:Hauptkategorie"
    }
    mycontent = session.get(api_url, params=MyParams)
    mydata=mycontent.json
    print("i got: ", mydata()['query']['pages'])

    #!/usr/bin/env python3
    import requests
    from bs4 import BeautifulSoup as bs
    
    username        = 'produnis'                    # Username to login with
    userpwd         = 'SuperSecreet'                # Userpassword
    botpwd          = 'myapibot@foobarfoobarfoobars52o8mk8apimpsb8' # Password of Special:BotPasswords in the style BOTNAME@password
    
    api_url   = "https://my.wiki.ltd/api.php"
    index_url = "https://my.wiki.ltd/index.php"
    
    payload = {
        'wpName': username,
        'wpPassword': userpwd,
        'wploginattempt': 'Log in',
        'wpEditToken': "+\\",
        'title': "Special:UserLogin",
        'authAction': "login",
        'force': "",
        'wpForceHttps': "1",
        'wpFromhttp': "1",
        #'wpLoginToken': '',
        }
    
    def get_login_token(raw_resp):
        soup = bs(raw_resp.text, 'lxml')
        token = [n.get('value', '') for n in soup.find_all('input')
            if n.get('name', '') == 'wpLoginToken']
        return token[0]
    
    with requests.session() as s:
        resp = s.get(index_url + '?title=Spezial:UserLogin')
        payload['wpLoginToken'] = get_login_token(resp)
        response_post = s.post(index_url + '?title=Spezial:UserLogin&action=submitlogin&type=login', data=payload)

        response = s.get(index_url + '?title=Special:Watchlist')

Mit dem Bookmarks Organizer 3.1 steht ein Update für die Firefox-Erweiterung bereit, welches Verbesserungen der Bestätigungs-Dialoge sowie eine Fehlerbehebung und aktualisierte Übersetzungen bringt.

Download Bookmarks Organizer 3.1 für Mozilla Firefox

Der Bookmarks Organizer soll dabei helfen, wieder Ordnung in die Lesezeichen zu bringen, indem nicht mehr funktionierende sowie doppelte Lesezeichen gefunden und Weiterleitungen korrigiert werden. Ein ausführlicher Überblick über alle Funktionen kann hier gefunden werden. Bookmarks Organizer 3.1 erfordert mindestens Firefox 60 und ist damit auch mit Firefox ESR 60 kompatibel.

Verbesserte Bestätigungs-Dialoge

Der Bookmarks Organizer zeigt vor dem Korrigieren einer Weiterleitung oder dem Löschen eines Lesezeichens eine Bestätigungs-Meldung an.

In Bookmarks Organizer 3.1 wurde der native Bestätigungs-Dialog, welcher vom Browser kommt, durch eine eigene Implementierung ersetzt. Dieser sieht zum einen wesentlich besser aus, hat vor allem aber nicht die Checkbox zum Unterdrücken weiterer Dialoge. Diese Checkbox hatte nämlich für Probleme gesorgt, da diese nicht synchron mit dem internen Status des Bookmarks Organizers war. Außerdem erlaubt die neue Implementierung weitere Verbesserungen des Dialog-Verhaltens in der Zukunft.

Wer nach defekten Lesezeichen sucht und nach der Überprüfung die Bestätigungs-Dialoge deaktivieren möchte, muss nicht länger eine erneute Überprüfung aller Lesezeichen durchführen, da sich die entsprechende Einstellung ab sofort umgehend auswirkt und nun jederzeit ein- und wieder ausgeschaltet werden kann.

Sonstige Verbesserungen

War die Oberfläche des Bookmarks Organizers bereits geöffnet und dann wurde ein neues Lesezeichen hinzugefügt, welches defekt ist, wurde dieses zwar korrekt mitgezählt, aber nicht in der Ergebnisliste angezeigt, wenn nach defekten Lesezeichen gesucht worden ist, ohne die Oberfläche des Bookmarks Organizers noch einmal neu zu laden. Dieses Problem wurde im Bookmarks Organizers 3.1 behoben.

Außerdem wurden diverse Übersetzungen aktualisiert.

Gefällt? Unterstützung gerne gesehen!

Wer die Entwicklung des Add-ons unterstützen möchte, kann dies tun, indem er der Welt von Bookmarks Organizer erzählt und die Erweiterung auf addons.mozilla.org bewertet. Auch würde ich mich sehr über eine kleine Spende freuen, welche es mir ermöglicht, weitere Zeit in die Entwicklung des Add-on zu investieren, um zusätzliche Features zu implementieren.

Der Beitrag Firefox WebExtension Bookmarks Organizer 3.1 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

Pylint ist ein Werkzeug zur statischen Codeanalyse. Da die Option für anschauliche HTML-Reports seit Version 1.7 entfallen ist, muss nun ein kleiner Umweg eingelegt werden, der in diesem Artikel erläutert wird.

Mit der dynamischen Typisierung verfügt Python über eine Eigenschaft, durch die sich einige Bugs erst zur Laufzeit „entfalten“ und im worst-case zum Crash der Anwendung führen. Um dieses Risiko zu minimieren steht die statische Codeanalyse („linting“) zur Verfügung, um den Code auf häufige Muster von Schwachstellen zu untersuchen und einen einheitlichen Codingstyle (in Python die bekannt PEP 8) zu forcieren.

Unter Python ist Pylint durchaus bekannt und übernimmt zuverlässig diese Aufgaben. Oft besteht der Wunsch, die Ergebnisse der Analyse außerhalb des stdout-Outputs in HTML angezeigt zu bekommen. Leider wurde Pylint in Version 1.7 um die Option beraubt.

Um in der aktuellen Version 2.3.0 dennoch HTML-Reports zu erhalten, wird ein kleiner Umweg benötigt: hier muss der Report als JSON ausgegeben und dann in HTML umgewandelt werden. Benötigt werden die Pakete pylint und pylint-json2html.

pip install pytlint pylint-json2html

In Punkto Konfiguration muss im project root die pylintrc mit folgendem Inhalt erstellt werden.

[MASTER]
load-plugins=pylint_json2html

[REPORTS]
output-format=jsonextended

Diese Konfiguration passt das Verhalten von pylint an. Der Aufruf

pylint moduledir/ > lint.json

(wobei moduledir natürlich der Name des Projekts ist) leitet nun die Ausgabe im JSON-Format in die Datei lint.json.

pylint-json2html -f jsonextended -o pylint.html < lint.json

generiert im letzten Schritt aus der über den per stdin eingeleiteten JSON-Datei eine HTML-Datei, deren Name mit der -o-Option spezifiziert wird. Die HTML-Reports sehen zwar schlicht aus, bieten aber sehr sinnvolle Information, die zur Erhöhung der Codequalität beitragen.

Google Chrome ist der Browser mit den größten Marktanteilen weltweit. Seit der initialen Veröffentlichung im Herbst 2008 hat der Browser einen rasanten Aufstieg vollzogen und die proprietäre und quelloffenen Konkurrenz gleichermaßen auf die Ränge verwiesen. Der Browser kostet seine Anwender nichts und steht auf allen Betriebssystemen zur Verfügung. Dieser Tage offenbart sich warum das Investment dennoch sinnvoll für Google war.

Chrome ist eine gewaltige Erfolgsgeschichte für Google. Seit der Veröffentlichung hat der Browser den Markt komplett umgekrempelt. Opera, Internet Explorer, Microsoft Edge - alle sind sie gestorben oder als Abklatsch auf Chrome-Basis wiedergekehrt. Geschickt hat man zudem die Open Source Community um den Finger gewickelt und sich in den unter Linux wichtigen Toolkits GTK und Qt festgesetzt, die ebenfalls Bibliotheken für WebKit/Chromium bereitstellen. Aktuell widerstehen nur zwei Alternativen: Firefox von Mozilla und Safari von Apple. Firefox kämpft dabei mit stetig sinkenden Marktanteilen, während Apple durch das eigene Ökosystem zumindest im Nischenbereich relevant bleiben wird.

Chrome kostet seine Anwender nichts und bringt Google auch direkt keinerlei Einnahmen. Während Firefox durch die Mozilla Foundation finanziert wird und Apple durch Hardwareverkäufe die Softwarentwicklung finanziert ist Chrome für Google kein Geschäft - zumindest auf den ersten Blick.

Eines darf man niemals vergessen. Im Grunde genommen ist Google ausgehend von seiner Einnahmenstruktur kein IT-Konzern, sondern eine Werbefirma. Die Google-Mutter Alphabet verdient ihr Geld hauptsächlich mit Werbung. Der Anteil liegt seit längerem konstant bei über 80%. Man möchte zwar die Einnahmenstruktur zukünftig diversifizieren aber momentan ist Google ziemlich abhängig von Werbeeinnahmen.

Werbung im Internet ist ein dategetriebenes Geschäft. Je mehr man über die Kunden weiß, desto zielgerichteter kann man ihn mit Werbung versorgen. Viele der Datenschutz-Skandale in den letzten Jahren wie das ausufernde Tracking im Internet, Standorterhebung über Bluetooth (siehe: Android - Keine sichere Alternative Teil II - Standortdaten über Bluetooth) etc. pp. haben ihren Ursprung im Gedanken Werbeeinahmen zu steigern. Schon alleine aus diesem Grund ist es attraktiv die Software zu kontrollieren, über die Milliarden Nutzer das Netz aufrufen, immerhin überträgt Chrome zahlreiche Daten an Google.

Ein weiteres Ärgernis für die Werbeindustrie sind die immer effektiveren Werbeblocker, die optional für alle Browser zur Verfügung stehen. Seit Jahren verklagen Verleger und Medienunternehmen daher die Entwickler solcher Blocker. Zumindest für Deutschland urteilte der Bundesgerichtshof 2018 letztinstanzlich, dass diese technischen Hilfsmittel legal sind.

Jüngst wurden nun Überlegungen bei Google bekannt, wie man die eigene Dominanz auf dem Browsermarkt nutzen kann um sich dieser lästigen Umsatzhemmnisse zu entledigen. Man kappt einfach die benötigten APIs und lässt damit faktisch nur noch die inneffektive interne Lösung zu.

Das kommt weder überraschend, noch ist es verwerflich. Google hat viel Geld in einen Browser investiert, stellt diesen kostenlos zur Verfügung und hat damit große Marktanteile erreicht. Ob möglicherweise die Verbreitung durch unlautere Methoden zustande kam, müssen Wettbewerbsbehörden überprüfen, die zahlreichen Auseinandersetzungen zwischen der EU und Google sind schließlich noch nicht abgeschlossen.

Es wäre aber wünschenswert wenn die zahlreichen mehr oder minder unabhängigen Blogger nicht permanent dem Stockholm-Syndrom erliegen und die IT-Konzerne über den grünen Klee loben würden (siehe auch: Kommentar: Stockholm Syndrom unter Bloggern). Ebenso werden die engen Verbindungen zwischen der vorgeblich so unabhängigen Open Source Szene und Google viel zu wenig thematisiert.

Google/Alphabet sind weder gut noch schlecht, es ist ein börsennotiertes Unternehmen und möchte seine Einnahmen steigern. Es liegt an den Anwendern auf die verbliebenen Alternativen auszuweichen und diese dadurch zu stärken.

Bilder:
Einleitungs- und Beitragsbild von 200degrees via pixabay

Die klassische Paketverwaltung von Linux stößt schnell an ihre Grenzen wenn man gezielt neuere Programmversionen einsetzen möchte, als die Distribution mitliefert oder Softwareanbieter ihre Produkte für eine Vielzahl von Distributionen gleichzeitig zur Verfügung stellen möchte. Dafür haben sich in den letzten Jahren neue Paketformate wie beispielsweise Flatpak oder Snap etabliert. Ausgereift sind beide noch lange nicht!

Die Limitationen der klassischen Paketverwaltung sind bekannt und werden außer von eingefleischten Fans auch nicht geleugnet. Selektive Aktualisierungen von einzelnen Programmen sind ebenso schwierig, wie die Installation von Programmen, die auf veralteten Bibliotheken basieren. Zudem hat Linux bei der Rechteverwaltung von Programmen durchaus Nachholbedarf (siehe auch: Kommentar: Flatpaks und Snaps - Ein Schritt in die richtige Richtung und Rechteverwaltung auch für den Desktop - Apple macht es vor).

Wie so oft im Linux-Universum konnte man sich natürlich nicht einigen, weshalb zwei unterschiedliche Projekte das gleiche Ziel verfolgen. Im Jahr 2014 kündigte Canonical daher so genannte Snaps an. 2015 folgte die Ankündigung so genannter XDG-Apps, heute umfirmiert zu Flatpak. Diese neuen Paketformate sollen auf allen Distributionen lauffähig sein und es Entwicklern ermöglichen ihre Software nur ein einziges mal paketieren zu müssen. Im Idealfall enthält das Paket alle notwendigen Abhängigkeiten, die auf einer Basislaufzeitumgebung aufsetzt.

Im Jahr 2019 muss man leider konstatieren, dass beide Projekte bestenfalls eine Technologievorschau sind und es unklar ist, welches oder ob sich überhaupt eines von beiden durchsetzen kann.

Canonical ist in üblicher Manier vorgeprescht und hat Snap mit der letzten LTS-Version seiner Ubuntu Distribution ausgeliefert. Die Priorisierung von Snap-Paketen in der grafischen Softwareverwaltung lässt in schöner Regelmäßigkeit verzweifelte Nutzer in den Supportforen auflaufen. Schlicht weil die Snap-Programme in vielen Anwendungsfällen nicht wie erwartet oder gar nicht funktionieren. Der Ruf solcher Snap-Pakete hat daher in den vergangenen Monaten gelitten und könnte das Projekt insgesamt scheitern lassen.

Flatpak geht hier dezenter vor. Das Format steht zwar inzwischen bei vielen Distributionen zur Verfügung, zahlreiche Softwareanbieter unterstützen es und die beiden grafischen Softwareverwaltungen GNOME Software und KDE Discover bieten eine optionale Integration von Flatpaks. Standardmäßig setzt aber kaum eine Distribution darauf. Aus guten Gründen, kämpft das Format doch mit zahlreichen Problemen. Das kann man beobachten wenn man z. B. Spotify als Flatpak installieren möchte. Im Betrieb nutzt das Programm, sowie die Laufzeitumgebung ca. 1,5 GB Arbeitsspeicher. Angesichts der Ausstattung von Linux-Rechnern ein absurd hoher Ressourcenverbrauch.

So notwendig eine Überwindung der klassischen Paketverwaltungen in einigen Bereichen auch ist, ob Flatpak und/oder Snaps der richtige Weg sind oder ob beide an der Aufgabe scheitern steht noch nicht fest.

Bilder:
Einleitungs- und Beitragsbild von harshahars via pixabay / Lizenz: Pixabay Lizenz

Ein Phänomen, welches sicher viele Nutzer kennen, ist das Springen des Inhalts, wenn man scrollt, während die Seite noch nicht fertig geladen ist. Dieses Verhalten gehört ab Firefox 66 der Vergangenheit an.

Mozilla hat in Firefox 66 sogenanntes Scroll Anchoring implementiert. Das Problem, welches Mozilla damit behebt, ist besonders von bildlastigen Webseiten bekannt: Man lädt eine Webseite und scrollt zu einer bestimmten Stelle, bevor Firefox die Möglichkeit hatte, die Webseite komplett zu laden. Plötzlich tritt an diese Stelle ein anderer Inhalt, weil Firefox weitere Bilder geladen hat, was die Position des gesamten Inhaltes verschiebt. Die Folge: Der Nutzer muss erneut scrollen, um wieder an die gewünschte Stelle zu kommen. Ähnliches gilt für das Öffnen eines Links mit Anker (#), während Firefox noch damit beschäftigt ist, die Inhalte zu laden.

Mit dem in Firefox 66 implementierten Scroll Anchoring ist dies anders. Firefox lädt wie bisher auch alle Ressourcen wie Bilder, verändert dabei aber nicht mehr die Position. Für den Nutzer entsteht nicht länger ein Sprung des Inhalts.

Der Beitrag Firefox 66 bekommt Scrolling ohne Sprünge während Ladevorgang erschien zuerst auf soeren-hentzschel.at.

In privaten Fenstern merkt sich Firefox keine Surf-Spuren wie Chronik oder Cookies. Die Startseite privater Fenster beinhaltet bislang lediglich Informationen über diesen Modus. In Zukunft steht hier wie in regulären Fenstern ein Suchfeld zur Verfügung.

Private Fenster in Firefox schützen die Privatsphäre der Nutzer, da Firefox in diesem Modus keine Chronik, Suchanfragen, Cookies sowie temporäre Dateien speichert. Außerdem ist in diesem Modus der Tracking-Schutz standardmäßig aktiviert, der Referrer wird standardmäßig gekürzt und Webseiten, welche nicht über HTTPS aufgerufen werden, werden als unsicher markiert.

Die Startseite privater Fenster erhält bislang lediglich Informationen darüber, was sich Firefox in diesem Modus merkt und was nicht. Mozilla hat die Seite nun überarbeitet und dabei die Informationen nicht nur kompakter dargestellt, auch gibt es hier nun ein Suchfeld, über welches die vom Benutzer eingestellte Standard-Suchmaschine genutzt werden kann, um im Web nach Informationen zu suchen.

Der Informations-Block enthält außerdem einen Link zu einem neuen Hilfe-Artikel, welcher mit diversen Mythen über private Fenster aufräumt und deutlich macht, was private Fenster nicht leisten.

Die Neuerung steht ab sofort in der Nightly-Version von Firefox 66 zur Verfügung und wird auch in Firefox Beta 66 verfügbar sein. In der finalen Version von Firefox 66 wird diese Neuerung standardmäßig zunächst deaktiviert sein, um diese im Rahmen einer Studie mit einem Teil der Nutzer zu testen, bevor die Neuerung flächendeckend ausgerollt wird. Die finale Version von Firefox 66 erscheint nach aktueller Planung am 19. März 2019.

Der Beitrag Firefox 66: Startseite privater Fenster erhält Suchfunktion erschien zuerst auf soeren-hentzschel.at.

Nextcloud ist eine vielfältige Lösung und bietet eine gute Basis um möglichst viele Informationen zwischen Endgeräten synchron zu halten. Es gibt zahllose Möglichkeiten eine eigene Nextcloud zu betreiben. Drei Varianten werden hier knapp vorgestellt.

Linux bietet in einer vernetzten Welt keinen Komfort - wohl aber verschiedene Werkzeuge um einen hohen Grad an Vernetzung zu erreichen. In der Serie "Cloud unter Kontrolle" wird genau diese Vernetzung Thema sein. Das Ziel ist eine Lösung, die in etwa dem umfassenden Angebot entspricht, wie es Apple mit den iCloud-Diensten oder Google mit seinen Lösungen bietet. Allerdings unter Kontrolle des Nutzers.

Serie:

1. Cloud in Eigenregie I: Vorbemerkungen
2. Cloud in Eigenregie II: Basis für Nextcloud wählen
3. Cloud in Eigenregie III: Nextcloud einrichten
4. Cloud in Eigenregie IV: Dateien über die Cloud verwalten
5. Cloud in Eigenregie V: Integration in GNOME
6. Cloud in Eigenregie VI: Kontakte synchronisieren
7. Cloud in Eigenregie VII: Kalender und Aufgaben verwalten
8. Cloud in Eigenregie VIII: RSS Feeds lesen und synchronisieren
9. Cloud in Eigenregie IX: Baustelle Podcasts
10. Cloud in Eigenregie X: Notizen

Im Grunde genommen benötigt Nextcloud lediglich einen Serverumgebung und eine Datenbank. Gerne abgekürzt als LAMP (Linux, Apache, MySQL, PHP). Das macht Nextcloud quasi universell einsetzbar, vom raspberry pi bis zum Webspace. Nextcloud lässt sich zudem auch auf vielen NAS-Lösungen als Paket nachinstallieren.

Die Serie widmet sich der Cloud in Eigenregie mit dem Ziel möglichst große Kontrolle über die eigenen Daten zu erhalten. Die Nextcloud-Instanz sollte daher nach Möglichkeit in den eignen vier Wänden laufen.

Linux Server

Der Betrieb auf einem eigenen Home Server ist die klassische Lösung. Nextcloud läuft auf allen Distributionen und harmonisiert mit vielen unterschiedlichen Lösungen wie Apache, NGINX, MySQL, MariaDB, PostgreSQL etc. pp.

Die Installation auf Basis eines openSUSE Leap Servers ist auf [Mer]Curius bereits beschrieben: Nextcloud auf openSUSE Leap Server installieren

Natürlich läuft Nextcloud auch auf allen anderen Linux-Distributionen. Besonders pflegeleicht ist eine Installation via Snap-Paket, die hier sehr ausführlich beschrieben ist. Aufgrund der Vielfalt der Möglichkeiten muss hier darauf verzichtet werden jede Variante darzustellen.

NAS

Ein NAS (Network Attached Storage) ist inzwischen meist mehr als nur eine Netzwerkfestplatte. Alle ernstzunehmenden NAS-Betriebssysteme bieten die Möglichkeit andere Dienste wie z. B. die Nextcloud nachzuinstallieren. Die populärste freie Lösung, FreeNAS, bietet Nextcloud als Plugin (mehr zu FreeNAS: Ausflug in die BSD-Welt: FreeNAS).

Die Installation erfolgt einfach über die Plugins-Sektion der Verwaltungsoberfläche. Nextcloud läuft dann in einem eigenen Jail - der Containerlösung von FreeBSD - auf einem LAMP-Stack ausschließlich für FreeNAS.

Eine Installation ist aber auch für openmediavault (Anleitung hier) möglich, genau wie unter den proprietären Lösungen Synology (Anleitung hier) oder QNAP (Anleitung hier).

Webspace

Sofern man keinen Home Server oder NAS betreibt und auch kein raspberry pi einrichten möchte, kann man eine Nextcloud natürlich auch auf jedem Webspace einrichten. Möglich machen es dir geringen Anforderungen der Nextcloud an die Umgebung. Während andere Lösungen wie z. B. Seafile Python voraussetzen nutzt Nextcloud nur, was jeder Webspace sowieso bietet.

Die Einrichtung auf einem Webspace ermöglicht also einen niedrigschwelligen Einstieg und eignet sich um die Möglichkeiten zu testen. Sie löst aber nicht das Grundproblem der Datenkontrolle. Der Webspace liegt außerhalb unseres eigenen Zugriffs und lediglich bestenfalls in Deutschland. Der Zugriff erfolgt nur über einen Dienstleister mit dem man in einer Vertragsbeziehung verbunden ist. Hinsichtlich des Datenschutzes unterscheidet sich also eine selbst betrieben Nextcloud auf einem Webspace nicht von einem kommerziellen Cloud-Anbieter.

Bilder:
Einleitungs- und Beitragsbild von IO-Images via pixabay / Lizenz: CC0 Creative Commons

Als Nutzer vom GitLab Runner i.V.m. Docker stand heute ein wenig cleanup an, nachdem der Speicher auf dem System vollgelaufen war. Dies geht relativ fix: für einen generellen Cleanup sorgt dieses kleine Script. Das schafft erst einmal ein wenig Platz, sodass wieder normal auf dem System gearbeitet werden kann. Wer das überquillenden Verzeichnis /var/lib/docker/overlay2 auch gerne bereinigt sehen will, kann

sudo docker system prune -a -f

ausführen. Ich rate von einem primitiven rm * in dem Ordner ab, da es mglw. zu Störungen führen kann. Mit system prune konnte ich immer 80 % des Gesamtspeichers auf dem System wieder freigeben.

Linux bietet in einer vernetzten Welt keinen Komfort - wohl aber verschiedene Werkzeuge um einen hohen Grad an Vernetzung zu erreichen. In der Serie "Cloud unter Kontrolle" wird genau diese Vernetzung Thema sein. Das Ziel ist eine Lösung, die in etwa dem umfassenden Angebot entspricht, wie es Apple mit den iCloud-Diensten oder Google mit seinen Lösungen bietet. Allerdings unter Kontrolle des Nutzers.

Serie:

1. Cloud in Eigenregie I: Vorbemerkungen
2. Cloud in Eigenregie II: Basis für Nextcloud wählen
3. Cloud in Eigenregie III: Nextcloud einrichten
4. Cloud in Eigenregie IV: Dateien über die Cloud verwalten
5. Cloud in Eigenregie V: Integration in GNOME
6. Cloud in Eigenregie VI: Kontakte synchronisieren
7. Cloud in Eigenregie VII: Kalender und Aufgaben verwalten
8. Cloud in Eigenregie VIII: RSS Feeds lesen und synchronisieren
9. Cloud in Eigenregie IX: Baustelle Podcasts
10. Cloud in Eigenregie X: Notizen

Der mangelnde Komfort wurde hier im Blog bereits diskutiert (siehe: Warum Linux in einer vernetzten Welt einfach keinen Komfort bietet!). Die Diskussion beinhaltete aber eine ansehnliche Liste an Werkzeugen um eine perfekte Integration mehrere Systeme im Arbeitsprozess zu erreichen. Als Vorbild bietet sich Apples iCloud Dienste an, da bei keiner anderen Kombination von Diensten und Betriebssystem eine Integration verschiedener Endgeräte so einfach ist.

Anforderungen

Das Ziel der Serie ist eine ähnliche Integration für ein Linux/Open Source Ökosystem zu erreichen. Dies beinhaltet als Zielsetzung eine Synchronisation folgender Dienste:

• Dateien (in ausgewählten Ordnern)
• E-Mails
• Kalender und Aufgaben
• Kontakte
• Messenger (Kommunikationsinhalte)
• Notizen & Wissensmangement
• RSS-Feeds
• Podcasts
• Browserverlauf
• Passwörter

Lösungsmöglichkeiten

Diese Liste lässt sich nicht mit einer Kombinationslösung erledigen. In dem oben bereits genannten Artikel, sowie der anschließenden Diskussion wurden zahlreiche Dienste genannt.

• Nextcloud / ownCloud
• Syncthing
• Seafile
• Mailcow
• Joplin
• Tiny Tiny RSS
• Bitwarden

Viele der genannten Dienste erledigen nur eine einzige Aufgabe (und diese dafür ggf. sehr gut), der Einsatz einer Vielzahl an Lösungen erhöht aber den Pflegeaufwand immens und ist daher für den Einstieg nicht sinnvoll. Ich habe daher beschlossen mit einer Lösung zu beginnen, die bereits mehrere Anforderungen gleichzeitig erfüllen kann. Aus der vorliegenden Liste ist das lediglich Nextcloud / ownCloud.

Nextcloud oder ownCloud

Im Jahr 2016 hatte sich Nextloud von ownCloud abgespalten. Viele Kommentatoren hatten damals der ursprünglichen Software ownCloud einen mehr oder minder schnellen Tod vorausgesagt. Dieser ist bis heute nicht eingetreten und die Frage, wo eigentlich die Basisarbeit verrichtet wird gleicht einem Glaubenskrieg.

Persönlich konnte ich der Entwicklung von ownCloud auch nach 2016 viel abgewinnen (siehe auch: Kommentar: Warum ownCloud statt Nextcloud?). Das hat sich nicht grundlegend geändert. Die Linux Community hat sich jedoch ganz überwiegend Nextcloud zugewandt. Dies äußert sich z. B. in der Verfügbarkeit von Paketen für die Serveranwendung und die Clientprogramme in den Paketquellen etc.

Um die Einstiegshürden möglichst niedrig halten basiert diese Serie daher auf Nextcloud. Persönlich möchte ich aber gerne dazu ermutigen ownCloud eine Chance zu geben.

Linux Distribution

Während mit Nextcloud die primäre Lösung bereits festgelegt wurde, habe ich mich noch nicht für eine Distribution / Desktopumgebung für das Desktopbetriebssystem entschieden. In der Diskussion hat sich gezeigt, dass GNOME augenscheinlich in einigen Bereichen viel weiter als KDE ist, weshalb die eigentlich präferierte Lösung openSUSE & KDE Plasma zur Zeit zur Disposition steht. Schließlich soll diese Serie zeigen, was möglich ist und dies möglichst einfach.

Einschränkungen

Diese Artikelserie ist "Work in progress". Die obige Liste spiegelt die Zielsetzung wider um auch transparent zu zeigen, was möglich ist und was eher nicht. Ich hoffe möglichst die komplette Liste umsetzen zu können, kann dies aber momentan noch nicht sicher versprechen, weil sie nicht komplett durch recherchiert ist.

Bilder:
Einleitungs- und Beitragsbild von IO-Images via pixabay / Lizenz: CC0 Creative Commons

Fedora folgt openSUSE und Ubuntu und möchte demnächst über die Paketverwaltung einige Informationen über die Anwender erheben. In den einschlägigen Kommentarspalten überschlägt sich die gleichermaßen achtsame, wie leicht erregbare und vollkommen irrational argumentierende Community. Doch wenn man gut umgesetzte Datenerhebung nicht unterstützt, stellt man sich komplett ins Abseits.

Telemetriedaten und Betriebssysteme sind spätesten seit der Veröffentlichung von Windows 10 ein wichtiges Thema. Zuletzt fokussierte sich die Debatte auf Ubuntu und jüngst kam openSUSE hinzu (siehe auch: Kommentar: Datenerhebung durch Linux-Distributionen). Ubuntu hat einige der gesammelten Daten jüngst in Berichten zusammen gefasst und veröffentlicht. Dabei kamen manche interessante Fakten über Linux/Ubuntu-Nutzer zum Vorschein (siehe auch: Warum Telemetrie-Daten notwendig sind)

Die Erhebung und Auswertung von Telemetrie-Daten ist einfach unerlässlich um zielgerichtet Entscheidungen treffen zu können. Es fällt vielen Datenschutz-Aktivisten immer noch schwer diesen Umstand zu akzeptieren, aber das führt in die Sackgasse.

Die reine Datenerhebung ist nämlich noch gar nicht das Problem. Es gibt kein Problem, wenn die Daten dezentral erhoben und gespeichert werden, ein durchdachtes Anonymisierungskonzept vorliegt und umgesetzt wird, sowie für den Anwender eine Möglichkeit besteht, der Datensammlung zu widersprechen. Nach aktuellem Kenntnisstand hat keine Distribution bei der Datenerhebung diesen Grundsätzen widersprochen.

Natürlich wäre ein Opt-in Verfahren schön, aber man muss hier auch die Praktikabilität im Blick behalten. Debian verfolgt bei Popcon seit Jahren einen Opt-In Ansatz und die man kann anhand eines Basis-Pakets wie z. B. Bash gut sehen, dass das keine ausreichenden Daten liefert. Wenn Debian wirklich nur 200.000 Installationen hätte, wäre das wirklich überraschend.

Datenerhebungen sind problematisch wenn damit Datensätze aus vielen unterschiedlichen Quellen zur Profilbildung herangezogen werden bzw. zur Erhebung und Auswertung auf zentralisierte Dienste wie beispielsweise Google Analytics zurückgegriffen wird. Hier trägt die Datenerhebung der einzelnen Projekte nämlich mittelbar zur Vergrößerung der Datenhalde von Google bei.

Ein bisschen mehr Augenmaß bei der Kritik ist daher wünschenswert. Wenn man das Bedürfnis nach einer Datengrundlage für Entscheidungen ignoriert, schürt man nur nihilistische Einstellungen, frei nach dem Motto "Ist doch eh schon egal, nehmen wir Google Analytics, die Datenschützer motzen eh." Das wäre wirklich fatal. Gut umgesetzte Datenerhebung mit Sinn für Datenschutz und Anwenderinteressen sollte man daher belohnen, indem man sie einfach nicht skandalisiert.

Bilder:
Einleitungs- und Beitragsbild von kreatikar via pixabay / Lizenz: CC0 Creative Commons

In diesem Artikel stelle ich mein neustes Projekt, das VGKB, ein Wiki für mathematisch-technische Themenbereiche, vor. Es wird viele Blogartikel systematisieren und neue Kategorien erschließen, die bisher nicht ihren Weg in den Blog finden konnten.

Als sicherlich letzter nutze ich mit diesem Blogpost die Möglichkeit, euch ein frohes neues Jahr und hierfür alles Gute zu wünschen. Durch meine Prüfungen und Projektarbeiten konnten in letzter Zeit wenig Beiträge für den Blog geschrieben werden. Aber die Aktivität wird in den Wochen sicherlich wieder zunehmen.

Wie immer nutze ich den Jahresanfang, um neue Projekt auszuprobieren. So war es letztes Jahr der Wochenrückblick, der als Pilot für eine breitere thematische Ausrichtung diente. Die im letzten Jahr wieder auferwachte Diskussion über ein Leistungsschutzrecht, jetzt auf EU-Ebene, als auch der nicht unerhebliche Zeitaufwand haben dazu geführt, den Wochenrückblick vorerst zu pausieren. Die thematische Erweiterung sowie der Blogrelaunch haben jedoch für frischen Wind gesorgt, was sich auch in den Zugriffszahlen widerspiegelt.

Am wohl wichtigsten war jedoch die Beobachtung, dass ein Großteil meiner Leser den Blog informativ einsetzt – sprich: als beliebteste Posts haben sich der Übersichtsartikel für ISO-Image-Tools und die Let's Encrypt-Artikel (sowohl in Deutsch als auch auf Englisch) herausgestellt. Beide Artikel sind gleichermaßen How To-Anleitung wie auch Leitfaden.

Bei meinem Blog habe ich mich anfangs für einen chronologischen Aufbau entschieden. In der URL wird ein Artikel über das Veröffentlichungsjahr und den -monat eingeordnet. Artikel lassen sich zwar taggen und kategorisieren, diese Elemente ermöglichen allerdings nur Artikellisten. Für den Aspekt eines digitalen Tagebuchs, auf dem in unregelmäßigen Abständen kleinere Abhandlungen über ausgewählte Themen erscheinen, ist dies völlig ausreichend. Zusätzlich möchte ich allerdings auch den Artikeln Raum widmen, die wie ein Nachschlagewerk bestimmte Themen genau behandeln und erläutern. Hier spielt in der Regel Taxonomie eine entscheidende Rolle. In der Umsetzung waren lange Zeit Übersichtsartikel im Blog angedacht, die Einführungstexte und Querverweise zu entsprechenden Artikeln bereitstellen sollten. Die Vermischung von Blogartikeln und Übersichtsseiten birgt aber auch die Gefahr vom kompletten Gegenteil - der Unübersichtlichkeit.

Das VGKB

Aus diesem Grund habe ich das letzte halbe Jahr Vorbereitungen für eine komplett eigene, neue Plattform getroffen. Im

vgar Knowledge Base (VGKB) (https://kb.v-gar.de/)

entsteht deshalb zukünftig eine Wissensdatenbank, welche die verschiedenen Artikel aus dem Blog systematisch bündelt und um weitere Artikel aus mathematisch-technischen Bereichen ergänzt werden soll.

Knowledgebaseartikel werden mehr on point sein, da die Einleitung kürzer gehalten werden kann und sich die jeweiligen Artikel um den Kern - den Inhalt - drehen. Themen können auf mehrere Artikel aufgeteilt werden und Querverweise minimieren Redundanz von Informationen. Auch lassen sich Anleitungen und Beschreibungen besser integrieren und fluten nicht die RSS-Reader meiner Leser.

Für die Realisierung setze ich auf ein Wiki-System, konkret implementiert durch das bekannte MediaWiki, das für diesen Einsatz durch die leistungsfähige Templating-Engine („Wiki-Syntax“) besonders gut geeignet ist. Auch wenn Wiki indirekt Wikipedia impliziert, ist die Ausrichtunng durchaus unterschiedlich, da Wikipedia enzyklopädisch und universal aufgestellt ist, während sich mein Wiki auf spezielle Themengebiete beschränkt und bedarfsgerecht verschiedene Textgattungen (Wissensartikel, Anleitungen, ...) kombiniert.

Es soll allerdings auch ein Einstiegspunkt in der Recherchearbeit sein und auf weitere Quellen verweisen, weswegen Projekte wie das speziell für Ubuntu-Anwender geschriebene ubuntuusers.de-Wiki bei ubuntu- und debianrelevanten Artikeln als gute Quelle für weitereführende Informationen entsprechend oft erwähnt werden wird. Das VGKB setzt sich zum Ziel, eine gute erste Anlaufstelle für eine Reihe von Themenbereichen zu werden.

Ich freue mich wie immer auf euer Feedback (gerne per Kommentar oder Mail) wie auch Vorschläge für Themen, die für das Wiki gewünscht werden. Begonnen wird mit den Themenbereichen Linux, Mathematik, LaTeX und Netzwerke. In den nächsten Tagen und Wochen werden nicht nur bestehende Blogartikel ins Wiki übertragen, sondern auch neue Artikel dort eingestellt. Um Querverweise zwischen beiden Plattformen zu ziehen, habe ich für entsprechende Infoboxen mit Links gesorgt, die ebenfalls sukzessive eingearbeitet werden. Die bisherigen Blogartikel bleiben hier in ihrer Form natürlich weiterhin bestehen. Im Blog wird es auch zukünftig wie gehabt um Technik, Tipps & Tricks sowie Panorama gehen.

Ich wünsche viel Spaß beim Lesen!

Ab Firefox 66 können Tastatur-Kommandos von Firefox-Erweiterungen vom Benutzer geändert werden, unabhängig davon, was der Entwickler der jeweiligen Erweiterung festgelegt hat.

Entwickler von Firefox-Erweiterungen können den Anwender diverse Aktionen auch per Tastatur ausführen lassen. Nicht immer ist die Wahl eines Tastatur-Kommandos für jeden Nutzer optimal. Abhilfe schafft eine neue Funktion von Firefox 66.

Ab Firefox 66 erreichen Nutzer über den Add-on Manager von Firefox eine Oberfläche, über welche sämtliche Tastatur-Kommandos der installierten Erweiterungen angepasst werden können.

Erweiterungen konnten bisher eine eigene Oberfläche implementieren, damit Nutzer die Tastatur-Kommandos ändern können. Davon hatten allerdings die wenigsten Erweiterungen Gebrauch gemacht. Mit Firefox 66 ist dies obsolet und steht automatisch allen Erweiterungen zur Verfügung, welche Tastatur-Kommandos implementiert haben.

Der Beitrag Tastatur-Kommandos von Erweiterungen können ab Firefox 66 geändert werden erschien zuerst auf soeren-hentzschel.at.

Überraschende Nachricht: Mozilla wird Firefox Test Pilot sowie Firefox Screenshots abschalten.

Unter dem Namen Test Pilot betreibt Mozilla eine Möglichkeit für Firefox-Nutzer, potentielle neue Funktionen vorab zu testen. Manche der Experimente haben ihren Weg in Firefox gefunden, andere haben dies nicht. Firefox Screenshots bezeichnet einen Online-Speicher für Screenshots. Beide Dienste sollen abgeschaltet werden.

Test Pilot wird bereits kommende Woche, am 22. Januar 2019 abgeschaltet werden. Bestehende Experimente werden weiterhin funktionieren und über addons.mozilla.org weiterhin zur Verfügung stehen. Die Test Pilot-Erweiterung wird bei Besuch der Webseite deinstalliert werden. Experimente, welche nicht in Form einer Firefox-Erweiterung kommen, wie Firefox Send und Lockbox, werden weiterhin aktiv entwickelt und erwarten signifikante Verbesserungen in der nahen Zukunft.

Die Screenshot-Funktion wird weiterhin Teil von Firefox bleiben, allerdings wird die Möglichkeit entfernt, Bilder online hochzuladen. Anfang der zweiten Jahreshälfte 2019 soll der Screenshot-Server dann komplett abgeschaltet werden.

Update 16.01.2019

Der Grund für die Einstellung von Test Pilot ist nicht etwa mangelnder Erfolg. Ganz im Gegenteil: So sagt Mozilla, dass Test Pilot sogar besser funktioniert hat, als man es sich je vorgestellt hätte. Vor der Gründung von Test Pilot hätte man keine gute Möglichkeit gehabt, schnell Features auf den Markt zu bekommen oder zeitnah Feedback von den Nutzern zu erhalten, um so schließlich Ideen zu evaluieren, bevor viele Ressourcen in etwas investiert werden, was von den Nutzern so überhaupt nicht angenommen wird. Prototyping dieser Art sei damals innerhalb von Mozilla ein fremder Ansatz gewesen. Mozilla als ganze Organisation habe sich aber weiterentwickelt und viel gelernt und so sei man nun nicht mehr auf ein einzelnes Team angewiesen, welches mit neuen Ideen experientiert. Auch 2019 darf man also mit neuen Produkt-Ideen rechnen, die man als Nutzer testen kann. Tatsächlich soll es 2019 sogar noch mehr und nicht weniger Experimente geben. Nur dann eben nicht unter dem Test Pilot-Label.

Erfolg ist letztlich auch der Grund für die Einstellung von Firefox Screenshots als Service. Firefox Screenshots läuft für Mozilla sehr erfolgreich und wird mittlerweile 20 Millionen mal pro Monat genutzt. Und das hat einen Preis: Firefox Screenshots bindet einige Mitarbeiter, welche für den erfolgreichen Wachstum benötigt werden.

Verglichen mit anderen Browserherstellern ist Mozilla sehr klein und hat nun eine begrenzte Anzahl an Ressourcen zur Verfügung. Einfach neue Leute in ein solches Projekt zu werfen, würde vielleicht in einer perfekten Welt funktionieren, und so schreibt Mozilla, dass das Einstellen von geeignetem Personal schwierig sei.

Gleichzeitig bereitet man den Launch einer großen neuen Version von Firefox Send vor – mit Android-App, Firefox Account-Integration und viel größerem Dateigrößen-Limit. Um in dieses Produkt investieren zu können, welches Mozilla wichtig erscheint, mussten Ressourcen abgezogen werden.

Firefox Send ist nämlich unabhängig von Firefox. De facto wird Firefox Send nach Angaben von Mozilla sogar häufiger mit Chrome als mit Firefox genutzt. Das Team, welches sich für Test Pilot verantwortlich zeigte, hat den Fokus nun mehr darauf gelegt, an Diensten zu arbeiten, die über Firefox hinausgehen, um so auch neuen Zielgruppen Mozillas Prinzipien hinsichtlich Datenschutz, Sicherheit und Nutzerkontrolle mitzugeben.

Ähnlich verhält es sich mit Lockbox, was zwar einerseits den Passwort-Manager von Firefox ergänzen soll, andererseits aber auch als Mobile App zur Verfügung steht und wovon nicht nur Firefox-Nutzer profitieren.

Während Test Pilot ursprünglich dazu gedacht war, Firefox-Features zu testen, hätten diese Produkte begonnen, den Horizont von Mozilla zu erweitern. Und so ist dann auch Firefox Monitor als Experiment außerhalb von Test Pilot entstanden, was für Mozilla ein großer Erfolg im Jahr 2018 war. Mozilla sieht mit diesen Produkten eine gute Möglichkeit, als Marke zu wachsen. Eine Plattform zu betreiben, welche sich auf Experimente für den Firefox-Browser beschränkt, sei vom Ressourcen-Bedarf her schwieriger zu rechtfertigen.

Der Beitrag Mozilla schaltet Test Pilot und Firefox Screenshots ab erschien zuerst auf soeren-hentzschel.at.

pfSense ist eine Open Source Firewalllösung, die man gut zu Hause, in der Schule oder in einem Unternehmen einsetzen kann (siehe Installation + Hardwareempfehlungen). In den meisten Fällen möchte man Clients nicht ausschließlich per Netzwerkkabel verbinden, sondern auch kabellos. Am einfachsten geht es, wenn man dazu einen WLAN Access Point an die Firewall mit anschließt, die sich um die kabellosen Geräte kümmert (z.B. Smartphones).

Aufbau des Setups

Ein Bild sagt bekanntlich mehr als 1000 Worte:

Die LAN-Schnittstelle von pfSense verbindet man mit einem Switch, an dem man dann den Access Point und weitere kabelgebundene Clients anschließen kann.

Access Point einrichten

Nachdem der Access Point angeschlossen ist (in unserem Beispiel ein Access Point von tp-link), muss er noch eingerichtet werden. Jeder Access Point bringt meistens auch ein Webinterface mit, über dass man Einstellungen vornehmen kann. Die IP-Adresse des Access Point findet man in pfSense unter Status → DHCP-Leases heraus.

Nun kann man auf das Webinterface des Access Point zugreifen.

Nach dem Login (bei tp-link ist der Standardbenutzername und das Passwort admin) richtet man unter Quick Setup alle wichtigen Einstellungen ein:

• Change the login account → Ja (neuer Benutzername und Passwort festlegen)
• Please select the proper operation mode according to your needs → Access Point
• Access AP Mode Settings
  • Wireless Network Name(SSID) → Name des WLAN-Netzes
  • Channel → Auto
  • Wireless Security Mode → WPA2-PSK
  • Wireless Password → WLAN Passwort
• Type → Static IP
• IP Address → eine IP Adresse aus dem LAN auswählen, z.B. 10.10.10.253
• DHCP Server → Disable (Da pfSense sich um die IP-Adressen kümmert).

Fazit

Es gibt zwar auch Mini-Computer und -router für pfSense, die einen WLAN-Chip mitbringen, doch kann man davon nur sehr wenige im Access Point-Modus betreiben. Meistens unterstützen sie nur den Client-Mode, d.h. man kann sich damit mit einem WLAN-Netz verbinden, aber selbst keines aufspannen. PfSense unterstützt nur wenige Karten im Access Point-Modus. Eine Übersicht findet man hier. Schlussendlich ist es IMHO deutlich einfacher einen Access Point mit pfSense zu verbinden statt den richtigen WLAN Chip zu finden.

Kommentar hinzufügen

Der Beitrag WLAN Access Point mit pfSense verbinden erschien zuerst auf .:zefanjas:..

Wer mehrere Firefox-Installationen auf seinem System nutzt, hat bisher standardmäßig ein gemeinsames Firefox-Profil für alle Installationen verwendet. Dies ändert sich mit Firefox 67.

Lesezeichen, Chronik, Erweiterungen, Passwörter, Einstellungen – diese und noch weitere Dinge werden in einem sogenannten Profil gespeichert. Verschiedene Firefox-Installationen nutzen standardmäßig immer das gleiche Profil. Was im ersten Moment praktisch erscheint, bringt mehrere Probleme mit sich.

Das größte Problem ist die Möglichkeit eines Datenverlustes durch Downgrades. Technisch liegt ein Downgrade nicht nur dann vor, wenn man eine Firefox-Installation durch Neuinstallation einer älteren Version ersetzt. Wer beispielsweise sowohl die aktuelle Release- als auch eine aktuelle Nightly-Version von Firefox installiert hat, führt aus technischer Sicht ebenso ein Downgrade durch, wenn zunächst Firefox Nightly und anschließend die Release-Version von Firefox mit dem gleichen Profil gestartet wird, da auch hier eine ältere Version der neueren Version folgt. Downgrades wurden von Firefox noch nie offiziell unterstützt und Hinweise in den Release Notes, dass ein Downgrade von einer bestimmten Version Probleme verursacht, gab es bereits häufiger.

Ein weiterer Nachteil ist die Tatsache, dass bei Nutzung eines gemeinsamen Profils nicht ohne Weiteres zwei Firefox-Installationen parallel genutzt werden können.

Ab Firefox 67 nutzt der Mozilla-Browser dedizierte Profile pro Installation. Das heißt, dass wenn ein Nutzer mehrere Firefox-Installation hat, jede dieser Installationen ein eigenes Profil verwendet und damit standardmäßig nicht länger in allen Installationen automatisch die gleichen Lesezeichen, die gleiche Chronik etc. zur Verfügung stehen. Wer seine Daten profilübergreifend synchron halten möchte, nutzt dafür idealerweise Firefox Sync, was genau für diesen Zweck ausgelegt ist. Die zuvor genannten Probleme gehören mit dieser Änderung der Vergangenheit an.

Wer bereits unterschiedliche Profile für unterschiedliche Installationen nutzt, was de facto schon vorher empfohlen war, ist von der Änderung nicht betroffen. Wer bisher ein gemeinsames Profil für unterschiedliche Installationen verwendet, ist in der folgenden Weise betroffen: Die Firefox-Installation, welche als erstes gestartet wird, erhält alle bisherigen Daten und Anpassungen. Jede weitere Installation erhält ein ganz frisches Profil. Über den Profilmanager kann die Zuordnung von Firefox-Installationen und -Profilen jederzeit angepasst werden.

Die Änderung wird aller Voraussicht nach am 28. Januar in Firefox Nightly in Kraft treten. Nutzer von Firefox Nightly werden nach dem morgigen Update, am 14. Januar, vorab über die Änderung informiert.

Der Beitrag Firefox 67 bekommt dedizierte Profile pro Installation erschien zuerst auf soeren-hentzschel.at.

VeraCrypt ist der semi-offizielle Nachfolger von TrueCrypt. Alternative Ansätze des Projekt fortzuführen konnten sich nicht durchsetzen. TrueCrypt weiter zu verwenden ist bereits seit längerem nicht mehr empfehlenswert (siehe: TrueCrypt sollte ersetzt werden!). VeraCrypt steht leider bei keiner Distribution in den Paketquellen zur Verfügung und muss manuell installiert werden.

Abgrenzung

VeraCrypt konkurriert auf allen Systemen mit den nativen Verschlüsselungslösungen. Bei Linux mit LUKS (siehe: LUKS - Betriebssystem verschlüsseln / LUKS - Externe Speichermedien verschlüsseln), unter macOS mit File Vault bzw. der nativen Verschlüsselung von APFS (siehe: macOS mit FileVault verschlüsseln / Daten in der Cloud verschlüsseln mit FileVault) und unter Windows mit BitLocker (siehe: Windows 10 mit BitLocker verschlüsseln).

Im Unterschied zu allen genannten Lösungen ist VeraCrypt aber auf allen drei Systemen (und zusätzlich auch noch FreeBSD) verfügbar. Das macht es insbesondere in heterogenen Systemen zur idealen Verschlüsselungslösung. Weiterhin hat es im Gegensatz zu den anderen Lösungen einen offiziellen Audit hinter sich.

Installation und Benutzung

Zwar gibt es teilweise Fremdquellen, aber von deren Einsatz muss bei so sensiblen Bereichen wie einer Verschlüsselungslösung abgeraten werden. Auf der offiziellen Homepage von VeraCrypt kann man Version für Linux herunterladen. Für Legacy-Systeme mit 32bit und ohne SSE2 steht ebenfalls noch eine Variante bereit. Das heruntergeladene Archiv entpackt man mit einem Werkzeug der Wahl.

In dem Archiv befinden sich Installationsroutinen für die Konsole und mit einem grafischen Interface - jeweils für 32bit und 64bit. Die grafische Variante muss auf der Konsole geöffnet werden, da sie Root-Rechte zur Installation benötigt. Pfad und Dateiname sind entsprechend an Version und Architektur anzupassen.

# ./veracrypt-<Version>-setup-gui-<Architektur>

Die Installationsroutine ist sehr minimalistisch gehalten. Zuerst muss man die VeraCrypt Lizenz bestätigen. Nach einem anschließenden Hinweis auf die Routine zur Deinstallation läuft die Installationsroutine durch. Anschließend befindet sich im Menü unter Zubehör o. Ä. ein Link zur VeraCrypt Oberfläche.

Die Oberfläche von VeraCrypt benutzt GTK zur Darstellung und fügt sich dementsprechend sehr gut in entsprechende Desktopumgebungen wie MATE, Xfce oder GNOME ein.

Die Bedienung unterscheidet sich kaum von der Windows-Variante und dem TrueCrypt-Vorgänger.

Über die Schaltfläche Volume erstellen beginnt man die Routine zur Erstellung eines neuen verschlüsselten Containers. Zuerst muss man den gewünschten Verschlüsselungstyp auswählen. Nach der Auswahl des Typs muss noch entschieden werden, ob man im Sinne des Prinzips der "glaubhaften Abstreitbarkeit" einen versteckten Bereich anlegen möchte. Anstelle eines Passwortes kann man auch eine Schlüsseldatei nutzen. Das Dateisystem innerhalb des Containers sollte dem Einsatzzweck angepasst werden. Das bedeutet alle genutzten Betriebssysteme müssen es unterstützen und Limitationen wie die Dateigröße bei FAT ist zu berücksichtigen.

Zusammengefasst

Die Installation und Benutzung ist sehr einfach und vor allem unter Linux dem komplexen Verfahren mit LUKS überlegen (siehe: Verschlüsselten Container mit LUKS anlegen). Der Hauptvorteil von VeraCrypt gegenüber nativen Verschlüsselungsmethoden der jeweiligen Betriebssysteme besteht in seiner systemübergreifenden Verfügbarkeit. Damit ist es insbesondere für den sicheren Dateiaustausch, sowie die Verschlüsselung externer Datenträger geeignet.

Bilder:
Einleitungs- und Beitragsbild von Tumisu via pixabay / Lizenz: CC0 Creative Commons

Mozilla wird noch in diesem Jahr, nämlich mit Firefox 69, die Unterstützung für den Adobe Flash Player standardmäßig deaktivieren.

Der Adobe Flash Player ist das letzte verbliebene NPAPI-Plugin, welches von Firefox noch unterstützt wird, nachdem andere NPAPI-Plugins wie Oracle Java oder Microsoft Silverlight bereits seit Firefox 52 nicht mehr unterstützt werden. NPAPI-Plugins waren für viele Jahre ein wichtiger Teil der Webplattform. In den letzten Jahren hat deren Bedeutung aber immer stärker abgenommen. Praktisch alles, was früher ausschließlich mittels NPAPI-Plugin umsetzbar war, wird heute, dank entsprechender Weiterentwicklung von Webstandards, nativ durch die Browser unterstützt. Heute gelten NPAPI-Plugins vor allem aus einer Sicherheits-Perspektive als problematisch.

Bereits im Juli 2017 hatte Adobe angekündigt, den Adobe Flash Player mit Ende 2020 zu beerdigen. Zeitgleich hatte Mozilla angekündigt, die Unterstützung für den Adobe Flash Player in Firefox Anfang 2020 für Privatanwender sowie Ende 2020 für Enterprise-Nutzer einzustellen. Nun steht ein konkreter Zeitpunkt für den nächsten Schritt fest.

Mozilla plant schon für Firefox 69 die standardmäßige Deaktivierung der Flash-Unterstützung. Firefox 69 wird nach aktueller Planung am 3. September dieses Jahres erscheinen.

Während es zu diesem Zeitpunkt für den Nutzer noch möglich sein wird, die Flash-Unterstützung per Browser-Einstellung zu aktivieren, sollten sich vor allem Webseitenbetreiber darauf einstellen, dass die Nutzer ab diesem Zeitpunkt ohne Änderung seitens Nutzer keine Flash-Inhalte mehr konsumieren können. Nutzer werden auch seitens Firefox nicht dazu aufgefordert werden, den Flash Player zu aktivieren.

Gemäß Roadmap wird die Unterstützung für den Adobe Flash Player dann Anfang 2020 komplett aus Firefox entfernt werden. Da die nächste Enterprise-Version von Firefox auf Firefox 68 basieren wird, sind Nutzer von Firefox ESR von diesem Datum nicht betroffen. Dort wird es erst Ende 2020 soweit sein, vermutlich in Firefox 76, sofern der aktuelle Abstand von acht Major-Releases zwischen ESR-Upgrades eingehalten wird.

Firefox für Android unterstützt bereits seit Oktober 2017 und Firefox 56 keinen Adobe Flash Player mehr.

Der Beitrag Flash-Unterstützung wird in Firefox 69 standardmäßig deaktiviert erschien zuerst auf soeren-hentzschel.at.