Beiträge von Sören Hentzschel

    Compositing: WebRender


    Und da steht auch nichts davon, dass die Kriterien nicht erfüllt wären:


    Entscheidungsprotokoll

    WEBRENDER:

    opt-in by default: WebRender is an opt-in feature

    available by user: Qualified enabled by pref


    Auf macOS steht hier beispielsweise derzeit:


    blacklisted by env: No qualified hardware

    miinimouse, eine about:support-Info bringt so nichts, weil du demnach WebRender aktiviert hast. So lässt sich dort natürlich kein Grund für eine Deaktivierung ablesen. Vielleicht magst du eine entsprechende Info ohne erzwungenes WebRender liefern.


    Zu den Kriterien für die Aktivierung von WebRender in Firefox 68: Windows 10 und Grafikchip von Nvidia oder AMD ist richtig. Weiter kommt es aber auch auf das genaue Modell und Treiber an. Und der Computer darf sich nicht im Akku-Betrieb befinden. Aber selbst wenn alle Kriterien erfüllt sind, wird WebRender nicht für jeden Nutzer aktiviert, weil es eine kleine Kontrollgruppe ohne WebRender gibt, damit Mozilla Metriken wie Stabilität und Performance zwischen WebRender und Nicht-WebRender via Telemetrie vergleichen kann.


    Ob WebRender durch Erfüllung der Kriterien aktiviert wird oder nicht, hängt jedenfalls nicht von gfx.webrender.all ab, sondern von gfx.webrender.all.qualified, was aber standardmäßig nicht über about:config sichtbar ist. Weder der eine noch der andere Schalter reflektiert, ob WebRender tatsächlich aktiviert ist oder nicht, sondern nur, ob WebRender aktiviert werden soll, wenn die Kriterien erfüllt werden. Mit gfx.webrender.all kann man die Aktivierung unabhängig von Kriterien erzwingen.

    An sich ist das nichts Neues. Vor Jahren gab es schon Artikel, welche Ähnliches beschrieben haben, beispielsweise: https://www.makeuseof.com/tag/…ing-youd-surprised-sends/.


    Das war 2014. Dort wurde geschrieben, dass die Lösungen von AhnLab, Avast, AVG, AVIRA, Bitdefender, BullGuard, Emsisoft, ESET, F-Secure, G DATA, Kaspersky Lab, McAfee, Microsoft, Panda, Sophos, Symantec, Trend Micro, Vipre und Webroot alle eine eindeutige Tracking-ID setzen und diese an den Hersteller übermitteln, teilweise sogar alle besuchten URLs. Ja, Microsoft wird hier auch genannt. Ob das Tracking nun auch für Dritte ermöglicht wird, wie in diesem Fall, oder "nur" für den AV-Hersteller, das macht für mich persönlich keinen so großen Unterschied mehr, denn wenn ich mir ein Programm installiere, welches meine Sicherheit verbessern und Privatsphäre schützen soll, dann will ich ganz sicher nicht einmal, dass mich der Hersteller dieser Software trackt. Das ist ein ziemlicher Verstoß gegen das Vertrauens-Prinzip, auf welchem die ganze Branche basiert. Manche dieser Programme, darunter Avast und Kaspersky, sendeten dem Artikel zufolge sogar ganze Dokumente vom System des Benutzers an den Hersteller, wenn das Programm einen Verdacht hatte. Ein Verdachtsfall kann aber praktisch immer vorliegen, solche Heuristiken und Definitionen arbeiten ja nicht fehlerfrei.


    Lange Rede, kurzer Sinn: Das war vor fünf Jahren. Es hat sich offensichtlich nicht viel geändert. Ein damals schon auffälliger Hersteller fällt fünf Jahre später immer noch durch Tracking-Mechanismen auf. Riesen-Überraschung. Nicht.


    Dennoch ist der Artikel gut als Erinnerung für alle Nutzer, die immer noch solcher Software vertrauen.

    Die Einstellung hat nichts mit einer ungefragten Installation von Add-ons zu tun. Da geht es nur darum, ob eine zusätzliche Warnung bei Installation durch den Nutzer aus anderer Quelle als AMO erscheint. Websites können so oder so nicht ungefragt Add-ons installieren. Wenn Mozilla Hotfix-Erweiterungen oder Studien verteilen möchte, läuft das nicht über eine Website und sowieso ohne Bestätigung und schon gar nicht mit einer Warnung. ;)

    der Firefox 70 mit ausgeblendeten https Zertifikat ist


    Ich verstehe nicht, was dieser Satz bedeuten soll. Aber so, wie sich das liest, bin ich mir fast sicher, dass du irgendetwas falsch verstanden hast. Ich empfehle dir den Artikel auf unserer Website:


    Firefox 70: Änderung der Darstellung von HTTP und HTTPS in Adressleiste

    Dadurch mache mir gerade etwas Sorgen um die Sicherheit in der Zukunft


    Es gibt überhaupt keinen Grund, sich um die Sicherheit Sorgen zu machen, ganz im Gegenteil. Vier von fünf Anfragen in Firefox sind bereits HTTPS und nicht mehr HTTP:


    https://letsencrypt.org/stats/#percent-pageloads


    Es ergibt also nicht mehr viel Sinn, HTTPS hervorzuheben, weil das ganz einfach die Norm ist. Dafür wird in Zukunft hervorgehoben, wenn die Norm nicht eingehalten wird, sprich die Übertragung unverschlüsselt ist. Wenn das überhaupt einen Einfluss auf die Sicherheit hat (wohlgemerkt wenn), dann verbessert es die Sicherheit, weil dein Bewusstsein dafür geschärft wird, wenn Seiten noch eine unverschlüsselte Übertragung nutzen. Denn das gefährdet deine Sicherheit. Schließlich geht es nicht darum, dass du siehst, dass eine Seite das macht, was du im Jahr 2019 schlicht erwarten darfst. Wenn es dir um Sicherheit geht, solltest du vor allem davor gewarnt sein, wenn eine Seite dir diese grundlegende Sicherheit nicht bietet. Und genau das macht Firefox ab Firefox 70: Es stellt Websites, welche kein HTTPS nutzen, ausdrücklich als unsicher dar. Das war bislang nicht der Fall. Wenn 80 Prozent aller Seiten hervorgehoben werden (und die Zahl ist immer weiter steigend; irgendwann sind es 85 Prozent, dann 90 Prozent, …), dann hat das keinen Nutzen. Dann wird man höchstens blind für das, was wirklich relevant ist.


    In dem von mir verlinkten Artikel steht übrigens auch, wie du den Hinweis darauf, dass kein HTTPS verwendet wird, noch deutlicher gestalten kannst, indem Firefox dann neben dem durchgestrichenen Schloss-Symbol, welches Standard ab Firefox 70 ist, zusätzlich noch den Text "Nicht sicher" anzeigt. Das macht es dann noch einfacher für dich.


    Allerdings:


    ich wurde bei Paypal auf eine Phishing Seite geleitet ohne das ich etwas gemerkt hatt


    HTTPS schützt nicht vor Phishing! Da sitzt du einem großen Irrtum auf. Selbst Phishing-Seiten nutzen HTTPS. HTTPS kostet nicht einen Cent und kann wirklich jeder haben. Nicht einmal ein EV-Zertifikat schützt dich vor Phishing:


    https://www.typewritten.net/writer/ev-phishing/


    Wie man in dem Artikel lesen kann, ist es sogar recht einfach für eine Phishing-Seite, ein EV-Zertifikat zu erhalten. Es ist ein großer Fehler, das überzubewerten. Darum macht es auch nichts, dass Firefox das ab Version 70 auch nicht mehr in der Adressleiste besonders hervorhebt, denn der Nutzen davon ist seit Jahren schon höchst umstritten. Nutzer verbinden das gerne mit einer zusätzlichen Sicherheit, die das aber überhaupt nicht bedeutet. Es kann Phishing sogar erleichtern!


    Ein weiterer lesenswerter Artikel über die Probleme von EV-Zertifikaten:

    https://stripe.ian.sh/


    EV-Zertifikate sind ein schönes Geschäft, denn die kosten gutes Geld, während normale Zertifikate mittlerweile häufig kostenlos sind. Aber sonst haben diese wenig bis gar keinen realen Nutzen*, wie die beiden Artikel eindrucksvoll belegen.


    *) Gut, für große Unternehmen wie Banken ist es natürlich ein sehr realer Nutzen, dass sie dadurch Vertrauen schaffen. Aber eben auch nur auf der Grundlage, dass Nutzer im Allgemeinen damit überhaupt nichts anfangen können und glauben, ein ein EV-Zertifikat macht den Unterschied zwischen vertrauenswürdig und nicht vertrauenswürdig. In gewissen Positionen muss man das natürlich bedienen.

    Hallo,


    die Domain firefox.com gehört Mozilla, also ja, private-network.firefox.com ist eine Domain von Mozilla. Das ist die Domain von Mozillas kommendem Proxy-Dienst. Aber wieso solltest du das löschen wollen? Das tut doch nicht weh. Man muss schon gezielt nach dieser Einstellung suchen, um diesen Eintrag zu sehen, ansonsten kommt man damit überhaupt nicht in Berührung. Als es noch Test Pilot gab, stand an dieser Stelle beispielsweise auch testpilot.firefox.com. Bis Firefox 66 stand sogar addons.mozilla.org an dieser Stelle, was dann entfernt wurde, weil AMO mittlerweile eine andere Schnittstelle nutzt und diese Berechtigung nicht mehr benötigt.

    Ich weiß nicht, wie korrekt das bereits funktioniert, jedenfalls sind noch ein paar Tickets offen, deswegen würde ich es noch als unfertig betrachten.


    Neues zur Adressleiste:


    Die Darstellung der Suchmaschinen wurde geändert:



    Der Schalter browser.urlbar.quantumbar existiert nicht länger, die alte Implementierung der Adressleiste kann daher nicht mehr aktiviert werden. Dafür gibt es mit browser.urlbar.megabar einen neuen Schalter (tut derzeit noch nichts), hinter welchem die größere Neugestaltung der Adressleiste entwickelt wird.

    Gibt es Nachteile wenn ich es nicht herausziehe aus dem Konstrukt? Für mich ist es als Laien übersichtlicher wenn es so wie ich oben postete 2x drin ist. Aber wenns falsch ist, und/oder irgendwelche Nachteile bringt dann mache ich es natürlich so wie du sagst.


    Vom Code her macht es keinen Unterschied, nur von der Code-Qualität: Wir sprechen jetzt von einer einzelnen Zeile. Aber lass deinen Code wachsen und du hast plötzlich 15 Zeilen an dieser Stelle, die in beiden Fällen absolut identisch sind. Je mehr Code man dupliziert, desto unübersichtlicher und schwieriger zu warten wird es für dich.


    Wäre das dann so?


    Korrekt.

    Weil wenn ich es eine Klammer vorher einfüge, lädt es nur nach else


    Wäre es eine Klammer vorher, dann wäre es ja auch innerhalb des else-Blockes, deswegen würde es nur in dem Fall ausgeführt werden. Deswegen ist Code-Einrückung wichtig. Wenn sich öffnende und dazu passende schließende Klammer immer auf der gleichen Achse befinden, sieht man, was wozu gehört. ;)

    Ich denke nicht, dass bypassCache notwendig ist.


    Wenn du browser.tabs.reload(); sowohl im if als auch im else verwendest, also tatsächlich immer, dann kannst du das aus diesem Konstrukt ganz herausziehen.


    Sprich statt:


    JavaScript
    1. if (condition) {
    2.     // other code…
    3. browser.tabs.reload();
    4. }
    5. else {
    6.     // other code…
    7. browser.tabs.reload();
    8. }


    so:


    JavaScript
    1. if (condition) {
    2. // other code…
    3. }
    4. else {
    5. // other code…
    6. }
    7. browser.tabs.reload();

    Ist es sinnvoll auf Github dazu ein Projekt (oder wie man das nennt) zu starten um die ganze Code Klauerei zu dokumentieren? Dann könnte ich, wenn die Erweiterung irgendwann mal auf AMO ist auch auf die Github Seite verweisen für den Quelltext. Wobei wenn es wirklich zu Problemen kommt habe ich doch keine Ahnung wie man Fehler ausbügelt.

    Letztlich musst du wissen, wie du deine Sachen organisierst. Für mich persönlich ist Git unverzichtbar, wenn es um Programmier-Arbeiten geht. Aber das erfordert halt auch wieder ein paar Kenntnisse darüber, wie man das verwendet. Das hängt also in erster Linie davon ab, ob du die Bereitschaft hast, dich damit auch noch zu befassen.

    Schön, dass das funktioniert. :)

    Was mich wundert, ich habe mir bestimmt über 50 Erweiterungen angesehen und nichts vergleichbares gefunden. Meist bestanden sie (zumindest die kleineren) nur aus einer background.js Datei, in der dann alles drin stand.


    Ich habe keine Ahnung, was es so an Erweiterungen gibt, weil ich eigentlich nie nach Erweiterungen suche. Vielleicht ist das kein so häufiger Anwendungsfall, Content-Scripts per Schaltfläche an- und abschaltbar zu machen. Die Erweiterung, welche du als Basis genommen hattest, war ja auch insofern anders, als dass diese kein Content-Script benötigte, sondern eine Firefox-Einstellung geändert hat.

    Keine einzige hatte was von let registered = null; drin stehen, auch nicht die Beispieldateien, die es dort im Paket gibt.


    Im Endeffekt habe ich das angewendet, was hier in Prosa steht:

    https://developer.mozilla.org/…nsions/API/contentScripts


    Man muss das Resultat von browser.contentScripts.register einer Variablen zuordnen, wenn man auf eben jenes Objekt später die unregister()-Methode anwenden will. Und die Variable hab ich ganz oben im Script deklariert, damit sie global verfügbar ist. Es soll ja bei jedem Klick auf die Schaltfläche das gleiche Objekt benutzt werden.


    In Verbindung mit async function ToolbarButtonClicked spuckt nicht mal Google was brauchbares dazu aus.


    Das ist nicht verwunderlich. Dieses ToolbarButtonClicked() ist ja eine Funktion der Erweiterung, die hat er der Entwickler der Erweiterung so genannt und könnte auch HansPeter() heißen. Dazu wird man nicht viel finden. Und das async muss vor jedem function stehen, wenn await verwendet wird. Das wiederum ist also sehr allgemein.

    Das bedeutet also auch, dass man ähnliche Scripte in die content_script.js rein machen könnte wie das Originale und es würde wohl funktionieren? 8|


    Ja, nach dem Prinzip kannst du theoretisch jedes Script, welches auf Websites wirken soll, per Button ein- und ausschaltbar machen.