Beiträge von MuLu

Stelle deine Frage öffentlich an die Threema-Forum-Community - über 4.800 Mitglieder helfen dir weiter. > Frage stellen <


    Ersteres ist mir unbekannt. Letzteres war meiner Meinung nach der richtige Schritt zu browserunabhängigen WebExtensions. Ob die Probleme mit e10s vorgeschoben waren oder nicht, sei mal dahingestellt.


    https://stadt-bremerhaven.de/mozilla-firefo…-daten-sammelt/
    https://www.golem.de/news/firefox-m…712-131727.html

    Notwendig war die Integration von WebExtensions auf jeden Fall. Die Abschottung der alten APIs aber nicht. Die werden ja teilweise immer noch von Mozilla-eigenen Addons genutzt. Man hat schlicht und einfach andere Entwickler ausgeschlossen.



    Installierte PWAs sind die Zukunft. Winzige Apps in riesige Browser-Engines zu packen und davon dann etliche gleichzeitig laufen zu lassen war schon immer ein Workaround.


    Für einige Apps funktioniert das ja bereits jetzt ganz gut. Für einen Messenger z.B. aber aktuell komplett undenkbar. Alleine den Speicherplatz den eine PWA aktuell belegen kann ist dazu nicht geeignet. Kann man natürlich recht einfach beheben, müssten die Entwickler nur endlich mal tun.
    Oder grade Discord als Beispiel: Da fehlt z.B. einfach eine API für globale Hotkeys oder auch Overlays.



    Ähm, nein…
    Nochmal: Das sind zwei verschiedene Unternehmen. Die werden sich ganz sicher nicht Programmierer "ausliehen" – wozu auch? Hat ja jeder seine eigenen.
    Ich meine das sind beides Open-Source-Projekte, vlt. könnten manche da (privat) beitragen, aber eine "Ausleihe" ist das nicht. Allein schon arbeitsrechtlich stelle ich mir das schwierig vor.


    Es kommt durchaus vor dass größere Firmen einzelne Programmierer in Vollzeit an Open-Source-Projekte (nicht Unternehmen) ausleihen.
    Wozu? Im einfachsten Falle weil man die Software selbst nutzt und so Features schneller und einfacher in die offiziellen Quellen bekommt. Kostet schlussendlich weniger Resourcen als bei jedem Release Hand anzulegen oder gar einen eigenen Fork zu pflegen.
    Arbeitsrechtlich habe ich von den USA jetzt nicht so viel Ahnung.



    BTW mit WebKit gibt es epiphany für Linux/GNOME


    Ist mir als Debian-User durchaus bekannt. Aber eben NUR für Linux. Aber wie schaut es z.B. mit Windows oder Android (Jaja, ich weiß. Eigentlich auch Linux-Kernel) aus?
    Deswegen schrieb ich ja auch dass mir nicht für für jedes OS was einfällt.

    Zitat


    Aber genau deswegen, sollte man ja versuchen, die Chromium-Engine zu meiden. Oder zumindest die Diversität zu waren.


    Wie gesagt: Man kann die aktuellen Versionen der Gecko-Engine nur mit Firefox nutzen weil Mozilla alle Möglichkeiten zur embedded-Nutzung gestrichen hat. Sonst hätte evtl. ja auch Opera auf Gecko statt Blink umgestellt.
    Für Browserhersteller (die nicht die Kapazitäten für eine eigene Engine haben) ist eben Blink/Chromium das bessere Produkt.

    Warum ich den Fuchs nicht mehr nutzen will habe ich bereits geschrieben. Alternativ nutzt man halt Forks. Dazu aber nochmal den Artikel.

    Ich fürchte (aktuell) ist der Kampf schon entschieden. Sowohl Firefox als auch der "alte" Edge interpretieren ja mittlerweile auch CSS mit dem WebKit-Prefix.

    Vorweg: Ich bin niemand der Google oder Mozilla verteufelt. Ich finde aber der User sollte schon wissen, dass er Daten an Google schickt. Auch wenn Google nicht drauf steht.



    Google hat mit der Gecko Engine garantiert nichts am Hut. Wozu denn auch - sie haben ja ihre eigene. Wenn du mir nicht glaubst, schau ins Repository.


    Ja, gut möglich dass sie sich nicht einmischen. Ausschließen würde ich da aber nix.
    Mir fallen auch ein paar Fälle ein bei denen ein Teil des Sponsorings so aussah, dass man den Projekten Programmierer "auslieh".
    Ernst gemeinte Frage: Wie schaut das denn da bei Mozilla und Google aus?
    Gerade wenn es Konkurrenz ist sollte man kritisch bleiben ob die Programmierer für das Projekt arbeiten oder durch nur für den AG.
    Die Einflussnahme kann ja ganz subtil ablaufen.



    Bei den von dir gelisteten Services des Browsers (nicht der Engine)


    Ich sprach ja auch explizit von "Firefox selbst" und nicht der "Gecko Engine". ;)
    Wobei die Nutzung der (aktuellen) Gecko-Engine ja auch zwingend die Nutzung von Firefox (oder nem Fork) bedeutet. Näheres dazu dann unten.
    Edit: Zumindest auf dem Desktop.


    aber beispielsweise hat Mozilla einen eigenen Geolocation-Service.


    Der aber bei Firefox (zumindest bei neuen Profilen) nicht genutzt wird. Sondern "https://www.googleapis.com/geolocation/v1/geolocate?key=%GOOGLE_LOCATION_SERVICE_API_KEY%". Leicht nachzuprüfen über einen Blick in about:config.


    Aber nochmal zum Engine-Problem:
    IMHO ist Mozilla auch zum Teil selbst Schuld dass deren Browser immer weniger genutzt und auf die Engine weniger Rücksicht genommen wird.
    Mal von der ungefragten Installation von Addons und der Abschaltung der XUL-Plugins abgesehen.
    Mozilla hatte Prism. Das wurde zugunsten Chromeless eingestellt. Welches dann auch eingestellt wurde.
    Dann kam Electron und hat genau diese Lücke gefüllt. Das hat natürlich auch dazu geführt, dass von Entwicklern auf Blink optimiert wurde und bei Problemen darauf verwiesen wurde Chrome zu nutzen. Aus Entwicklersicht ist das natürlich praktisch nur eine Codebase zu haben.
    Und bums hat man wieder mehr Nutzer bei der Konkurrenz.
    Als weiteren Versuch von Mozilla gab es zwischendurch auch Positron. Auch das wurde mittlerweile wieder eingestellt. Ebenso wie die Möglichkeit Gecko in eigene Software zu implementieren.
    Das ist zwar nicht schön, aber wer die Entwickler verscheucht, der verscheucht auf mittelfristige Sicht eben auch die Nutzer.


    Im Endeffekt gibt es zum (eigentlichen) Thema wenige Punkte (evtl. kann ein Mod ja das Engine-Thema in einen neuen Thread splitten):
    An Engines bleibt also dann eigentlich nur:
    - Trident (MS, kann man eh knüllen wenn man auf was anderem als Windows unterwegs ist)
    - Gecko (Zwingt einen zu Firefox oder nem Fork)
    - WebKit (Spontan fallen mir da aber auch nicht für alle Betriebssysteme Browser ein)

    Auf die Servo-Engine bin ich mal gespannt. Die kommt aus einer Kooperation von Samsung und Mozilla und soll sowohl standalone als auch embedded tun.


    Naja ich sehe bisher nicht den Vorteil (vor allem in der usability) in dezentralen webs.
    Preferiere wenig schnitstelken und alles dich beieinander.


    Der generelle Vorteil: Die Daten bleiben beim Betreiber (im Idealfall also bei dir) und bei den betreiber der anderen Instanzen.
    Die Usability hängt jetzt aber weniger von zentral oder dezentral ab sondern eher welche Software du für welchen Zweck nutzt. Ein Facebook-Nutzer wird kaum mit Mastodon zurecht kommen. Ein Twitter-Nutzer dagegen eher, weil es eben genau dafür als Ersatz gedacht ist.
    Statt "@example" spreche ich halt nun einen User mit "@user@example.com" an. Grade bei ActivityPub kannst du entsprechend einfach zwischen z.B. einer Nextcloud-Installation mit einer Mastodon-Installation kommunizieren.

    Zitat

    Das war Mut ein Grund, warum ich nie mit diaspora etc warm wurde.
    Auch das viele dieser Produkte einen installierten client benötigen.


    Ja, Diaspora ist (je nachdem wie eingerichtet) ziemlicher Overkill.
    Zumindest für die dezentralen Social-Networks brauchst du eigentlich neben einem Browser keine extra Software auf Nutzerseite.

    Mist, ich habe da die Antwort von Aries tatsächlich nicht mehr mitbekommen. Nu gut, nu halt mit etwas Verzögerung.

    Was die Engine angeht, da habt ihr natürlich recht. Generell ist das allerdings mittlerweile ein schwieriges Thema weil Google irgendwo immer seine Finger drin hat oder zumindest hatte. Ich würde tatsächlich eher WebKit anstatt Gecko ins Rennen werfen. Da hängt zumindest Google (nicht mehr) direkt dran.

    Da Google auch der Hauptgeldgeber von Mozilla ist zweifle ich schon fast dran, dass es da bei Firefox-Kooperation geblieben ist. Eher fummelt Google auch direkt in der Engine mit.
    Bei Firefox selbst ist es ja auch nicht nur mit Integration der Suchmaschine getan. Safe-Browsing-API, Recaptcha-Whitelisting, WiFi-Geolocation, First-Party-Tracking-Cookie ...

    Falkon/QupZilla ist übrigens auch so ein Kandidat. Der nutzt (in aktuellen Versionen) als Engine QtWebEngine. Die basiert wiederum auf Chromium.
    Auf iOS bleibt uns ja eh keine Wahl außer WebKit zu nutzen.

    Aber nochmal zurück zum Thema Browser selbst. Ich war früher selbst begeisterter Firefox-Nutzer.
    Leider hat sich Mozilla dann durch die ungefragte Installation von Addons und dem Abschalten der alten Plugin-API (die Möglichkeiten und Masse der Plugins waren für mich das Alleinstellungsmerkmal) einiges an Reiz verloren.


    Ja, WhatsApp speichert die Telefonnummern von Kontakten nur wenn ein mit dieser Telefonnummer verknüpfter WhatsAppaccount existiert. Ansonsten wird die Telefonnummer wie bei Threema nur hochgeladen um zu prüfen ob ein Account mit dieser Nummer existiert.

    Afaik wird bei Threema nur ein Hash der Telefonnummer übermittelt. Bei WhatsApp wird die Telefonnummer im Klartext an Facebook übertragen.


    UWP ist proprietär und daher nicht optimal. Das Einzig richtige wäre auf PWA zu setzen, somit wäre man Plattformunabhängig.


    Selbiges ist bei den Android- und iOS-APIs der Fall. PWA macht bei einem Messenger allerdings weniger Sinn da der Speicherplatz teils _sehr_ limitiert ist. Bei Safari unter iOS sind das afair 50 MB, Edge hat Geräten mit < 32 GB Speicher n Limit von 500. Da hat man bei Videos und Bildern schnell ein Problem.

    Nextcloud ist wohl eher für größere Firmen gedacht. Basis Preis ab 50 Usern für 1900€/Jahr.
    [...] Einen eigenen Server habe ich nicht.

    Das, was du da raus gesucht hast ist die Variante, die vom Hersteller betrieben und gewartet wird.

    Natürlich kannst du Nextcloud auch einfach selbst betreiben. Einen eigenen Server brauchst du da nicht unbedingt. Da reicht fast jedes Shared-Hosting-Paket welches PHP und MySQL bietet. Kleine Pakete kriegst du schon um die 2 €/Monat.


    Selbst da dauert es immer zu lange bis alle Upates ausgerollt werden. Zudem ist dann fraglich wer WhatsApp kostenlos Serverkapazität zur Verfügung stellen würde.


    Für die Freischaltung von Servern müssen keine Updates ausgerollt werden. Das wird einfach serverseitig freigeschalten. Das ist einfaches S2S wie im Protokoll eben vorgesehen.
    Und wie meinst du das mit "kostenlos Serverkapazität zur Verfügung stellen"? Oo


    Ein Webbrowser mit Chromium-Engine fällt bei mir durchs Google-Raster.

    Dir steht es frei den Sourcecode durchzuschauen. Der ist bei Chromium (nicht Chrome) nämlich frei verfügbar.

    Welchen Browser verwendest du denn? Firefox kann ja dann auch nicht deines sein weil Mozilla ja auch ordentlich von Google finanziert wird. ;)

    Jawoll, die starren Klassen werden zwar noch gelehrt, aber ebenso steht das Sub- und Supernetting auf dem Lehrplan.

    Wenn du wirklich so darauf bedacht bist das Backup im Netzwerk zu halten fallen mir 2 Möglichkeiten ein. Beide setzen vorraus, dass du deinen WebDAV-Server frei konfigurieren kannst.
    1) DynDNS-Adresse, per Upnp alle 2,5 Monate ein Portforwarding auf machen und sich via ACME-Client ein Zertifikat holen. Das kannst du auch über wenige Zeilen als Cronjob einrichten.
    2) Du baust dir eine eigene CA auf (für jedes OS gibt es da eigentlich brauchbare, einfache Software), bringst deinem Android bei der CA zu vertrauen und stellst für den Server halt dann ein Zertifikat aus, welches x Jahre hält.

    Das ganze jetzt aber aufweichen indem man auch HTTP zulässt finde ich allerdings auch bedenklich.


    Erstens hab ich keine Kreditkarte. Zweitens bin ich aktuell nicht auf ein Betriebssystem festgelegt.


    Das Thema Kreditkarte/Familienbibliothek war an Helmut gerichtet.

    Zitat


    Ist iOS sicherer als Android? Werden da die Apps vorher geprüft? So hab ich das verstanden. Andererseits greifen sowohl Apple als auch Google die Daten ab und keiner weiß, wozu und was damit weiter passiert. Pest oder Cholera?


    Kommt drauf an, wie du sicherer definierst. Sowohl im Apple Store, als auch im Play Store werden die Inhalte vorher geprüft.

    Zitat


    Was Du mit den Gmailadressen meinst weiß ich nicht. Wenn ich eine löschen will, weil ich zu viel Spam dorthin bekomme, dann lasse ich die sperren. Google löscht ja nicht wirklich sondern sperrt nur den Login. Apps wären dann weg.


    Du mischt hier Gmail und Google Konto. Du kannst problemlos Gmail aus deinem Google-Konto entfernen. Dann musst du halt eine alternative Mailadresse angeben mit der du dich bei deinem Google Konto anmeldest.
    Klar, wenn du deinen kompletten Google Account löschen lässt, dann ist der weg. Deswegen löscht man sinnigerweise auch nur den GMail-Account.
    Warum sollte man überhaupt einen Account löschen, wenn er Spam-Probleme hat? Einfach via Filter alle löschen lassen und erwünschte Absender auf die Whitelist.

    Zitat


    Am liebsten wäre es mir, wenn die Apps, die ich gerne nutzen möchte, auch als Download auf der Herstellerseite zur Verfügung stehen würden. Dann würde ich auch mehr Apps kaufen. Warum dies nicht der Fall ist weiß ich nicht. Klar, man könnte auch Apps die infiziert sind herunterladen, aber das kann im PlayStore ja auch hin und wieder vorkommen.


    Weil sich z.B. InApp-Einkäufe, Usertracking, Werbung, etc. halt recht easy über die Google/Apple-Dienste realisieren lassen.
    Den Versuch die apk via apkmirror z.B. runterzuladen und zu nutzen kannst du natürlich mal probieren.
    Oder dir mal Recoon oder YalpStore anschauen.


    So, Alternativen sind natürlich Browser MIT der von Mozilla aufgegeben XUL-Schnittstelle (zum weiteren Gleichschalten mit Google-Chrome oder was für politischen Gründen auch immer).


    WebExtensions allgemein implementieren ist super. Das macht es für Entwickler sehr viel einfacher Extensions für mehrere Browser zu entwickeln.
    Die alten Addons aber abzuschalten fand ich auch sehr schwach. Grade deswegen war ja FF auch so beliebt: Er hat sich dank der Schnittstellen sehr individuell anpassen lassen. Ich erinnere mich gerne an DTA oder opendownload² zurück.
    Der Witz ist ja: Die XUL-Schnittstellen gibt es weiterhin. Nur Addons sind dafür nicht mehr zugelassen.

    Etwas OT: Twitter macht das ja ähnlich. Groß wurde Twitter nur wegen der offenen API. Jetzt stellt man sie stückweise ein. :/

    Zitat

    Von gestern zu heute habe ich mir deshalb noch den (einer Fremd-Quelle zufolge) offiziell von Mozilla empfohlenen Alternativ-Browser "Waterfox" angeschaut. Dieser scheint weiterhin alle Schnittstellen zu unterstützen, lädt erfolgreich mein Profil inklusive aller Add-ons, lädt auch die aktuelle Threema-Web-Version - wird aber leider nicht offiziell unterstützt, weshalb der Versand von Nachrichten nicht erlaubt(?) wird.


    Hast du mal probiert den User-Agent auf einen aktuellen Firefox zu ändern?

    Du kannst bei einem Google-Account mehrere Mailadressen hinterlegen und die verknüpften auch für Docs, Drive, etc. nutzen. Wenn dir eine "zu doof" geworden ist, dann hinterlegst du eben eine andere.
    Der Google-Account bleibt trotzdem der selbe.

    Wenn du dir eine GMail-Adresse angelegt hast: Korrekt, die lässt sich nicht ändern. Aber du kannst natürlich bei jedem anderen Anbieter eine neue Mailadresse registrieren und auch die im Account hinterlegen.
    Oder du erstellst einen neuen und lässt den alten Account bei Android hinterlegt. Dann kannst du auch die alten, gekauften Apps nutzen.
    Von "Apps gehen verloren" kann man da nicht reden.


    Auch wenn das vermutlich nicht mehr aktuell ist:
    Du könntest dir auch mal die Google Familienmediathek anschauen. Da hinterlegst du nur bei einem Eltern-Account eine Kreditkarte. Dazu schaltest du einfach Kaufbestätigungen ein. Heißt: Will ein Kind was über die KK kaufen musst du es bestätigen. Zahlungen über andere Methoden (Guthabenkarte z.B.) gehen trotzdem.
    Vorteil: Du könntest die App einfach über die Familienmediathek frei geben und zahlst somit nicht extra für die Lizenzen.

    Was das Update von Apps außerhalb des Play-Stores angeht: Komplett automatisieren kannst du das als Entwickler regulär nicht. Du kannst zwar die APK runterladen und die Installation anstoßen, aber auf den "Installieren"-Button muss der Nutzer selbst noch drücken.
    Dazu musst du noch einmalig die Installation über externe Quellen aktivieren. Je nach Android-Version generell oder pro App.