Re: Empfehlung für NAS mit Kalenderserver?

[Chris]

Hallo,

> On 01/20/2018 09:02 PM, willi uebelherr wrote:
>> Die frage von Stefan war auf, zumindest weitgehendst, freie software
>> gerichtet. Da kommt nun Thomas mit dem angebot fuer 2 zu bezahlende
>> loesungen an. Was soll denn das? Arbeitet Thomas fuer einen verein zum
>> verkauf von Software?

Frei bedeutet nicht kostenlos. Kommerzielle Software ist auch nicht das
Gegenteil von Freier Software. Wohingegen Freie Software die nicht
kommerziell sein darf, unfrei ist.

Wieso sollte man nicht kommerzielle Software vorschlagen? Die
Anforderung besagte ja nicht: Muss Freie Software und gratis sein.

LG,
Chris
___
FSFE-de mailing list
FSFE-de@lists.fsfe.org
https://lists.fsfe.org/mailman/listinfo/fsfe-de

Re: Das beA muss Freie Software werden

[Werner Koch]

On Fri, 26 Jan 2018 16:08, max.m...@fsfe.org said:

> - Kein Perfect Forward Secrecy

Geht bei Email sowieso nicht.  Durch 9Unter-)Schlüsselrotation kann man
bei OpenPGP aber leicht Forward Secrecy erreichen.  Ob das überhaupt
notwendig ist, hangt aber vom Bedrohungszenario ab.  Da Anwaltspost
sowies immer viele Leser der Dokumente hat, ist das m.E. völlig
irrelevant.

> - Kein AEAD [^2]

OpenPGP benutzt AE(AD) seit 2000, also bevor es diesen Begriff überhaupt
gab.  Es nennt sich hier MDC und leistet genau das was AE auch leistet.
Cryptographen mögen solche ad-hoc Verfahren allerdings nicht so gerne.
Im übrigen kommt AEAD bald bei OpenPGP auch zu Einsatz - im aktuellen
Master von GnuPG ist der aktuelle Proposal seit ein paar Tagen
implementiert.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpWp2swDUEMY.pgp
Description: PGP signature
___
FSFE-de mailing list
FSFE-de@lists.fsfe.org
https://lists.fsfe.org/mailman/listinfo/fsfe-de

Re: XMPP Probleme (Re: Freie Alternative zu einer Whatsapp/Threema-Gruppe)

[Roland Hummel]

Hi,

On 01/26/2018 04:27 PM, Benedikt Geißler wrote:
> Wie ich in der Mail um 14:44 Uhr schrieb, ist das bei Conversations
> (eigentlich bei jedem XMPP-Client, da das Protokoll ein Push- und kein
Pull-
> Modell vorsieht) nicht so. Es wird nichts aktiv gepullt, nur eine TCP-
> Verbindung offengehalten. Da das Offenhalten einer Verbindung quasi
keinen
> Strom braucht (zumindest i. d. R. bei WLAN, in Mobilfunknetzen ist das
> möglicherweise anders), spielt es keine Rolle, ob die Signalisierung
nun per
> Google-Cloud-Messaging oder direkt geschieht. Google-Cloud-Messaging
müsste ja
> auch über eine solche „Standleitung“ realisiert sein.

okay, vielen Dank für die technische Richtigstellung. Dennoch wurde sich
seitens meiner Tester*innen hier und da massiv über den hohen
Akkuverbrauch durch Conversations beschwert, den ich dann (wie sich nun
herausstellt leider falsch) mit dem Pull-Verfahren erklärt hatte.
Anyway: auch mit falscher Erklärung gehörte ein hoher Energie-Verbrauch
ausdrücklich nicht zu den Argumenten, die ich in solchen Fällen gegen
XMPP angeführt hätte. Wenn ich zivilgesellschaftlich kontrollierbare
IT-Strukturen mit erhöhtem Energieverbrauch bezahlen muss, dann zahle
ich diesen Preis gerne (Stallmans "zero practical sacrifice"-Argument:
wenn Freiheit nichts kostet, ist Freiheit auch nichts wert - mit diesem
Argument habe ich die meisten "meiner" User auch überzeugt, XMPP doch
bitte weiter eine Chance zu geben). Soll heißen: Das mit dem
Akkuverbrauch ist für mich nicht auf der Argumentationsliste, weder bei
Matrix noch bei XMPP. Wahrscheinlich hab ich mich deswegen auch weniger
mit den technischen Details auseinandergesetzt.

Unterm Strich zählte für mich: bei Matrix kamen ausnahmslos immer alle
Nachrichten auf allen Geräten plattformübergreifend an, inklusive
vollständiger History auf allen Geräten (egal wie lange einige davon
abgeschaltet waren) und ohne überall nochmal MUCs hinzuzufügen und
Einstellungen vornehmen zu müssen und zuguterletzt: ohne irgendwelche
Compliance-Tests durchführen zu müssen oder nächtelanges "welche
XEP-Erweiterung sollte ich wohl noch installieren, damit ich endlich
zuverlässige Nachrichtenübermittlung bekomme"-Getüftel und
Hilfe-Bettelei in Dev-Chats.

Das Problem ist nämlich: ist der mühsam von XMPP überzeugten
Freund*innen-Kreis auch nur einmal von der Problematik betroffen, dass
irgendwas nicht ankam (was btw in Diskussionen im Schlimmsten Fall zu
immensen Missverständnissen führen kann), ist das Vertrauen in das
System dahin, was sich darin zeigt, dass mir Leute, die mir über XMPP
schreiben könnten, dann im Notfall doch eine SMS schicken, weil sie
nicht mehr auf XMPP vertrauen.

In einem MUC, den ich seit Deaktivierung meines eigenen Prosody-Servers
über einen riseup-Account nutze, hat sich das Problem bestätigt: dort
sind dismail.de-User, jabber.at-User und riseup.net-User anwesend und
auch hier kommen immer wieder Zwischenfragen, dass der Chatverlauf für
User X irgendwie keinen Sinn macht mit der Bitte, doch mal einen
Screenshot aus der Sicht von User Y zu schicken um zu sehen, was da
schon wieder nicht durchkam.

Ich sage das nicht, weil ich frustriert auf einem alt-ehrwürdigen
Standard wie XMPP rumbashen will, sondern weil ich es wirklich schade
finde, dass XMPP trotz seiner über Jahre vorhandenen Führungs-Position
im Bereich dezentraler Messenger-Systeme es nicht geschafft hat, ein
System wie Matrix bereitzustellen, mit dem auch Leute mit begrenzten
zeitlichen Möglichkeiten und begrenztem IT-Wissen das ja ursprünglich
wohl angestrebte Ziel eines breiten föderalen Netzwerkes herstellen
können, das dann auch wirklich zuverlässig funktioniert. XMPP bedient in
der aktuellen Form für mich das Vorurteil, dass "dieser dezentrale open
source Kram" nur etwas für eine bestimmte Elite ist, womit das (für
mich) eigentliche Ziel verfehlt wird, eine digital mündige
Zivilgesellschaft realistisch zu ermöglichen.

Aber wie gesagt: ist ja dank Bridging durch Matrix kein Problem. Je mehr
dezentrale Systeme es gibt, desto besser. Ich bin aber froh, dass mit
Matrix die große Lücke gefüllt wird, auch technisch interessierten Laien
wie mir selbstverwaltete digitale Infrastrukturen zu ermöglichen.

On 01/26/2018 02:30 PM, Alexander Dahl wrote:
> Unterstützt Dein XMPP-Server XEP-0280 Message Carbons? Wenn nicht, ist
> das vielleicht der Grund dafür.

War zumindest bei mir (Prosody) aktiviert, die beschriebenen Probleme
gab es trotzdem.

On 01/26/2018 03:02 PM, JokerGermany wrote:
> Nutze natürlich Omemo.
> Allen meinen Geräten habe ich nur nicht in gajim getraut, alle anderen
> haben sich gegenseitig getraut.
> Habe mal angehängt 3 Bilder eines Chatverlaufs
> Das Firephone und das VFD1400 waren die ganze Zeit angeschaltet, über
> das Firephone wurde geschrieben.
> Das Firephone2 wurde kurz vor 12 Uhr angeschaltet.
>
> Das Gajim auf meinem Rechner, dass nicht an war, findet selbst im
> Verlauf keine Nachrichten von heute...

Perfekt beschrieben, genau diese Art von Problemen kann ich 

Re: XMPP Probleme (Re: Freie Alternative zu einer Whatsapp/Threema-Gruppe)

[Benedikt Geißler]

Am Freitag, 26. Januar 2018, 14:05:51 CET schrieb Roland Hummel:
> Ist bei der F-Droid-Version definitiv so, da die App ja nicht von Push
> profitieren (und deswegen "schlafen" kann), sondern aktiv pullen muss.

Wie ich in der Mail um 14:44 Uhr schrieb, ist das bei Conversations 
(eigentlich bei jedem XMPP-Client, da das Protokoll ein Push- und kein Pull-
Modell vorsieht) nicht so. Es wird nichts aktiv gepullt, nur eine TCP-
Verbindung offengehalten. Da das Offenhalten einer Verbindung quasi keinen 
Strom braucht (zumindest i. d. R. bei WLAN, in Mobilfunknetzen ist das 
möglicherweise anders), spielt es keine Rolle, ob die Signalisierung nun per 
Google-Cloud-Messaging oder direkt geschieht. Google-Cloud-Messaging müsste ja 
auch über eine solche „Standleitung“ realisiert sein.

Freundliche Grüße,
Benedikt


___
FSFE-de mailing list
FSFE-de@lists.fsfe.org
https://lists.fsfe.org/mailman/listinfo/fsfe-de

Re: Das beA muss Freie Software werden

[Max Mehl]

# Bernhard E. Reiter [2018-01-26 15:37 +0100]:

Am Mittwoch 24 Januar 2018 09:41:30 schrieb Dr. Michael Stehmann:

Am 24.01.2018 um 08:27 schrieb Bernhard Reiter:



Das ist der erste grundlegende Fehler, denn es wurde
"Ende-zu-Ende-Verschlüsselung" versprochen.


Ja, das halte ich in der Tat für ein Design-Problem, das nicht so leicht zu 
beheben ist und vermeidbar gewesen wäre.


Heute gab es dazu einen Artikel von Hanno Böck auf golem.de [^1], in dem
er eine mögliche Lösung skizziert, die auf GPG und einem zentralen
Schlüsselservice basiert.

Einzige technische Probleme, die ich daran sehe:
- Kein Perfect Forward Secrecy
- Kein AEAD [^2]
- Kein einfacher Zugang zu definierbaren Nachrichten vor dem
 eingestellten Vertretungszeitraum (aber ist das so wichtig?)

Dazu gibt es tatsächlich meines Wissens nach noch keine
Freie-Software-Lösungen (zumindest nicht so erprobt wie GPG). Man hätte
die 38 Millionen Euro ja dafür verwenden können, aber naja...

An dieser Stelle noch der Hinweis, dass gestern auch DAVIT, die
Arbeitsgemeinschaft IT des Deutschen Anwaltvereins, den Offenen Brief
der FSFE [^3] unterzeichnet hat. Damit wird deutlich, dass die
Forderung, das beA jetzt und für alle zukünftigen Entwicklungen als
Freie Software zu veröffentlichen, langsam auch in "konservativere"
Zirkel vordringt.

Viele Grüße
Max

[^1]:
https://www.golem.de/news/anwaltspostfach-die-unnoetige-ende-zu-mitte-verschluesselung-von-bea-1801-132394.html
[^2]: https://en.wikipedia.org/wiki/Authenticated_encryption
[^3]: https://fsfe.org/campaigns/publiccode/bea

--
Max Mehl - Program Manager - Free Software Foundation Europe
Contact and further information: https://fsfe.org/about/mehl
Support advocacy for Free Software:  https://fsfe.org/donate


pgpTQdt6OzEAF.pgp
Description: PGP signature
___
FSFE-de mailing list
FSFE-de@lists.fsfe.org
https://lists.fsfe.org/mailman/listinfo/fsfe-de

Ende-zu-Ende Verschlüsslung Email (war: Freie Alternative zu einer Whatsapp/Threema-Gruppe)

[Bernhard Reiter]

Am Donnerstag 25 Januar 2018 22:24:39 schrieb Thorsten Behrens:
> > Irgendwie habe ich das Gefühl, das man sich einen Bärendienst
> > erweist wenn man E-Mail als alternative zu WhatsApp & Co empfiehlt.
>
> Yeps, das ist so. Allerdings ist da grade viel in Bewegung gekommen,
> mit dem autocrypt-Standard.

Aus meiner Sicht ist https://wiki.gnupg.org/WKD der bessere Ansatz.
(Das liegt wohl auch daran, dass ich ihn mit entwickelt habe. :) Was ich 
schade finde, ist dass die autocrypt Leute unseren früher veröffentlichen 
Ansatz kannten und sich nicht die Mühe gemacht haben uns Rückmeldung dazu zu 
geben, wo sie unsere Argumentation nicht teilen.)

Es liegt jetzt daran, wieviele Email-Provider und Email-Klienten die 
weitergehenden Möglichkeiten implementieren. Posteo ist schon recht weit. 
Mailbox.org bietet die Abfrage ab Q2 2018 an. 

Die aktuelle GnuPG-Version 2.2 kann die Abfrage bereits (*), Email-Klienten 
können zu meiner Email-Addresse bernh...@intevation.de direkt einen 
öffentlichen Schlüssel mit Basisvertrauen bekommen und dann automatisch 
verschlüsseln.

Die Verteilung der öffentlichen Schlüssel rein per Email hat den Nachteil, 
dass Basisvertrauen nur durch zeitliche verlaufende Infos entstehen kann und 
die Regel dafür sind für Nutzer deutlich komplizierter zu verstehen. (Und 
mehr Platz verbraucht es auch und ich meine dabei sogar Probleme mit den 
MIME-Standards gesehen zu haben.)

Gruß,
Bernhard
(*) GnuPG 2.0 ist EOF seit Dezember.

-- 
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


signature.asc
Description: This is a digitally signed message part.
___
FSFE-de mailing list
FSFE-de@lists.fsfe.org
https://lists.fsfe.org/mailman/listinfo/fsfe-de

Re: Das beA muss Freie Software werden

[Bernhard E. Reiter]

Am Mittwoch 24 Januar 2018 09:41:30 schrieb Dr. Michael Stehmann:
> Am 24.01.2018 um 08:27 schrieb Bernhard Reiter:

> Das ist der erste grundlegende Fehler, denn es wurde
> "Ende-zu-Ende-Verschlüsselung" versprochen.

Ja, das halte ich in der Tat für ein Design-Problem, das nicht so leicht zu 
beheben ist und vermeidbar gewesen wäre.

[Zert Problem]
> > Das ließe sich technisch durchaus mit überschaubaren Aufwand tun:
> > Der "Client" könnte ein geheimes Zertifikate selbst pro Anwender erzeugen
> > und dann in den Browser importieren. Oder gleich einen Browser selbst
> > mitbringen.

In der Tat scheinen die das nun so zu machen:
  https://heise.de/-3951936

Allerdings gehen sie nicht auf die anderen Probleme ein (z.B. veraltete 
Bibliotheken).

Gruß,
Bernhard


signature.asc
Description: This is a digitally signed message part.
___
FSFE-de mailing list
FSFE-de@lists.fsfe.org
https://lists.fsfe.org/mailman/listinfo/fsfe-de

Re: XMPP Probleme (Re: Freie Alternative zu einer Whatsapp/Threema-Gruppe)

[JokerGermany]

Ups vergessen,
Als Server wird trashserver.net wird sowohl vom Sender, als auch vom
Empfänger verwendet.
Den habe ich mir extra danach ausgesucht, ob er "alle" Addons unterstützt


Am 26.01.2018 um 14:59 schrieb JokerGermany:
>
> Am 26.01.2018 um 14:12 schrieb Benedikt Geißler:
>> Am Freitag, 26. Januar 2018, 11:25:44 CET schrieb JokerGermany:
>>> Mein Kollege spricht von hohen Akkuverbrauch von Conversations, was ich aber
>>> nicht bestätigen kann.
>> Ist er in vielen Gruppenchats beteiligt (also welchen mit höherem 
>> Nachrichtenaufkommen)? Und hat der Server Stream Management und Client State 
>> Indication aktiviert? Wenn ersteres und/oder nicht zweites der Fall ist, 
>> dann 
>> könnte das der Grund sein. ;)
> Das mit dem Gruppenchats bezweifle ich, da ich überhaupt der schuldige
> bin, dass er XMPP nutzt ;)
>
>
>>> Ich Empfang auf allen Geräten, und ich glaube sogar nur wenn sie Online
>>> sind, was mein Gesprächspartner geschrieben hat, aber nicht was ich
>>> geschrieben habe.
>> Hat der Server Message Carboning aktiviert? Wenn nein, dann empfängt immer 
>> nur 
>> das Gerät, welches online ist und höchste Prorität eingestellt hat, die 
>> Nachricht.
>>
>> Benutzt du OMEMO oder OTR?
>>
>> Bei OMEMO: stelle sicher, dass du auch allen deinen eigenen Schlüsseln 
>> vertraust, dann müsstest du auch alle Nachrichten bekommen. Evtl. hilfreich 
>> ist auch „Blind Trust Before Verification“ bei Conversations:
>> https://gultsch.de/trust.html
>>
>>
> Nutze natürlich Omemo.
> Allen meinen Geräten habe ich nur nicht in gajim getraut, alle anderen
> haben sich gegenseitig getraut.
> Habe mal angehängt 3 Bilder eines Chatverlaufs
> Das Firephone und das VFD1400 waren die ganze Zeit angeschaltet, über
> das Firephone wurde geschrieben.
> Das Firephone2 wurde kurz vor 12 Uhr angeschaltet.
>
> Das Gajim auf meinem Rechner, dass nicht an war, findet selbst im
> Verlauf keine Nachrichten von heute...

___
FSFE-de mailing list
FSFE-de@lists.fsfe.org
https://lists.fsfe.org/mailman/listinfo/fsfe-de

Re: XMPP Probleme (Re: Freie Alternative zu einer Whatsapp/Threema-Gruppe)

[Benedikt Geißler]

Am Freitag, 26. Januar 2018, 14:10:54 CET schrieb David Rabel:
> Bin mir ziemlich sicher, dass der Akkuverbrauch von Conversations auch
> ohne Google Play Services kaum ins Gewicht fällt.

Dem ist definitiv so. Conversations baut eine TCP-Verbindung auf und sofern 
das jeweilige Android-Betriebssystem es zulässt, bleibt diese Verbindung 
bestehen. Strombedarf fällt dann nur an, wenn auch wirklich Nachrichten 
verschickt werden und mittels Client State Indication können „unwichtige“ 
Nachrichten serverseitig herausgefiltert werden, wie etwa: der Client befindet 
sich im Standby und daher werden keine Nachrichten wie „Nutzer xy schreibt 
gerade…“ und „Nutzer xy ist jetzt online“ gar nicht erst zugestellt.

Im Gegensatz dazu bietet Matrix nicht diese Möglichkeit, eine persistente TCP-
Verbindung zum Server offen zu lassen, so dass natürlich ohne Google-Cloud-
Messaging nur noch das aktive Polling bleibt…


Freundliche Grüße,
Benedikt Geißler


___
FSFE-de mailing list
FSFE-de@lists.fsfe.org
https://lists.fsfe.org/mailman/listinfo/fsfe-de

Re: Give it away! - 27.01.2018 18:00 Uhr

[Paul Hänsch]

On Wed, Jan 10, 2018 at 06:37:23PM +0100, Dr. Michael Stehmann wrote:
> Ich würde mich freuen, wenn Ihr mich auf dem Weg "heraus aus unserer
> Filterblase" begleiten würdet.

Ich bin dabei. Bis morgen.

-- 
Paul Hänsch █▉Webmaster, System-Hacker
  █▉█▉█▉  
Jabber: p...@jabber.fsfe.org▉▉ Free Software Foundation Europe


signature.asc
Description: PGP signature
___
FSFE-de mailing list
FSFE-de@lists.fsfe.org
https://lists.fsfe.org/mailman/listinfo/fsfe-de

Re: XMPP Probleme (Re: Freie Alternative zu einer Whatsapp/Threema-Gruppe)

[Alexander Dahl]

Moin,

On Fri, Jan 26, 2018 at 11:25:44AM +0100, JokerGermany wrote:
> Was mich stört ist das Verhalten bei mehreren Geräten.
> Ich Empfang auf allen Geräten, und ich glaube sogar nur wenn sie Online sind, 
> was mein Gesprächspartner geschrieben hat, aber nicht was ich geschrieben 
> habe.

Unterstützt Dein XMPP-Server XEP-0280 Message Carbons? Wenn nicht, ist
das vielleicht der Grund dafür.

Schau mal in Conversations unter "Konten verwalten" auf Dein Konto und
hake dann in den Optionen "Server-Info" an. Es werden dann eine
Auswahl von XEPs angezeigt, die für mobile Nutzung sinnvoll sind, und
ob der von Dir genutzte Server die unterstützt.

Ganz interessant zu dem Thema ist auch:

https://conversations.im/compliance/

Inklusive sehr weit untem verlinkten Tool, das die Daten generiert
hat, kann man auch ohne in der Liste aufzutauchen mal gegen seinen
XMPP-Server fahren. ;-)

Grüße
Alex

-- 
»With the first link, the chain is forged. The first speech censured, 
the first thought forbidden, the first freedom denied, chains us all 
irrevocably.« (Jean-Luc Picard, quoting Judge Aaron Satie)
*** GnuPG-FP: C28E E6B9 0263 95CF 8FAF  08FA 34AD CD00 7221 5CC6 ***


signature.asc
Description: PGP signature
___
FSFE-de mailing list
FSFE-de@lists.fsfe.org
https://lists.fsfe.org/mailman/listinfo/fsfe-de

Re: XMPP Probleme (Re: Freie Alternative zu einer Whatsapp/Threema-Gruppe)

[Benedikt Geißler]

Am Freitag, 26. Januar 2018, 11:25:44 CET schrieb JokerGermany:
> Mein Kollege spricht von hohen Akkuverbrauch von Conversations, was ich aber
> nicht bestätigen kann.

Ist er in vielen Gruppenchats beteiligt (also welchen mit höherem 
Nachrichtenaufkommen)? Und hat der Server Stream Management und Client State 
Indication aktiviert? Wenn ersteres und/oder nicht zweites der Fall ist, dann 
könnte das der Grund sein. ;)

Weitere Details gibt es auch in diesem Beitrag:
https://gultsch.de/xmpp_2016.html

> Ich Empfang auf allen Geräten, und ich glaube sogar nur wenn sie Online
> sind, was mein Gesprächspartner geschrieben hat, aber nicht was ich
> geschrieben habe.

Hat der Server Message Carboning aktiviert? Wenn nein, dann empfängt immer nur 
das Gerät, welches online ist und höchste Prorität eingestellt hat, die 
Nachricht.

Benutzt du OMEMO oder OTR?

Bei OMEMO: stelle sicher, dass du auch allen deinen eigenen Schlüsseln 
vertraust, dann müsstest du auch alle Nachrichten bekommen. Evtl. hilfreich 
ist auch „Blind Trust Before Verification“ bei Conversations:
https://gultsch.de/trust.html

Bei OTR: Da kann ich ohnehin nur von abraten, da es nicht mit Message 
Carboning und Message Archive Management zusammenarbeitet. Bei Conversations 
wird es perspektivisch bald auch Gott sei Dank nicht mehr angeboten.


Freundliche Grüße,
Benedikt Geißler


___
FSFE-de mailing list
FSFE-de@lists.fsfe.org
https://lists.fsfe.org/mailman/listinfo/fsfe-de

Re: XMPP Probleme (Re: Freie Alternative zu einer Whatsapp/Threema-Gruppe)

[David Rabel]

On 26.01.2018 14:05, Roland Hummel wrote:
> On 01/26/2018 11:25 AM, JokerGermany wrote:
>> Mein Kollege spricht von hohen Akkuverbrauch von Conversations, was ich
>> aber nicht bestätigen kann.
> 
> Ist bei der F-Droid-Version definitiv so, da die App ja nicht von Push
> profitieren (und deswegen "schlafen" kann), sondern aktiv pullen muss.
> 

Bin mir ziemlich sicher, dass der Akkuverbrauch von Conversations auch
ohne Google Play Services kaum ins Gewicht fällt. Mein Handy ist leider
grade am Ladegerät und voll geladen und ich sehe deshalb den
Akkuverbrauch pro App nicht. Meine aber mich zu erinnern, dass
Conversations hinter Screen, OS, WLAN und noch anderem Kram kam.

Grüße
  David



signature.asc
Description: OpenPGP digital signature
___
FSFE-de mailing list
FSFE-de@lists.fsfe.org
https://lists.fsfe.org/mailman/listinfo/fsfe-de

Re: XMPP Probleme (Re: Freie Alternative zu einer Whatsapp/Threema-Gruppe)

[Roland Hummel]

On 01/26/2018 11:25 AM, JokerGermany wrote:
> Mein Kollege spricht von hohen Akkuverbrauch von Conversations, was ich
> aber nicht bestätigen kann.

Ist bei der F-Droid-Version definitiv so, da die App ja nicht von Push
profitieren (und deswegen "schlafen" kann), sondern aktiv pullen muss.

> Was mich stört ist das Verhalten bei mehreren Geräten.
> Ich Empfang auf allen Geräten, und ich glaube sogar nur wenn sie Online
> sind, was mein Gesprächspartner geschrieben hat, aber nicht was ich
> geschrieben habe.

Deckt sich mit meiner Erfahrungen. Genau solche Punkte wurden mir
irgendwann, bei aller Liebe für "Kommandozeilenausflüge", zu "frickelig".

Gruß
Roland




signature.asc
Description: OpenPGP digital signature
___
FSFE-de mailing list
FSFE-de@lists.fsfe.org
https://lists.fsfe.org/mailman/listinfo/fsfe-de

Re: Empfehlung für NAS mit Kalenderserver?

[Peter Hormanns]

Hallo Thomas,

Am 25.01.2018 um 23:55 schrieb Thomas Doczkal:
> On 01/20/2018 09:02 PM, willi uebelherr wrote:
>>
>> Die frage von Stefan war auf, zumindest weitgehendst, freie software
>> gerichtet. Da kommt nun Thomas mit dem angebot fuer 2 zu bezahlende
>> loesungen an. Was soll denn das? Arbeitet Thomas fuer einen verein zum
>> verkauf von Software?
> 
> Ich möchte betonen, dass ich von beiden Firmen in keiner weise Geld
> erhalte dafür das ich diese Namen genannt habe.
> 
> In Zukunft werde ich meine Antworten nicht mehr auf die Liste schreiben
> sondern diese Informationen wahrscheinlich besser direkt adressieren.
> 
> Es tut mir aufrichtig leid, das ich etwas geschrieben habe, dass nicht
> das Idealbild von 100% freier Software entsprochen hat. Ich gebe mir
> mühe, dass dies nicht mehr vorkommt.
> 

Ich weiß nicht, wie groß der Anteil an freier Software auf diesen
Geräten ist. Aber ich vermute, dass der Anteil nicht weit von 100%
entfernt ist. Die NAS-Geräte sind eine Möglichkeit auf relativ einfachem
Weg einen Linux-Server zu Hause zu haben. Das gehört meiner Meinung nach
sehr wohl hier hin.

@willi: Frei bedeutet nicht kostenlos. In diesem Fall kauft man
Hardware. Die mitgelieferte Software lässt sich bei vielen Geräten gegen
freie Distributionen austauschen.

Viele Grüße,
Peter

-- 
Peter Hormanns - Informatikbüro Hormanns & Wenz
http://www.hormanns-wenz.de - Tel 02151 3274911
Peter Hormanns - Hafenstraße 17 - 47809 Krefeld
___
FSFE-de mailing list
FSFE-de@lists.fsfe.org
https://lists.fsfe.org/mailman/listinfo/fsfe-de

Re: XMPP Probleme (Re: Freie Alternative zu einer Whatsapp/Threema-Gruppe)

[JokerGermany]

Mein Kollege spricht von hohen Akkuverbrauch von Conversations, was ich aber 
nicht bestätigen kann.

Was mich stört ist das Verhalten bei mehreren Geräten.
Ich Empfang auf allen Geräten, und ich glaube sogar nur wenn sie Online sind, 
was mein Gesprächspartner geschrieben hat, aber nicht was ich geschrieben habe.

Naja, nach der Empfehlung hier werde ich wohl mal riot.im testen

Am 24. Januar 2018 08:48:50 MEZ schrieb Bernhard Reiter 
:
>Hallo Roland,
>
>vielen Dank fürs Aufschreiben Deiner Erfahrungen, das bringt uns alle
>weiter.
>
>Die XMPP Probleme interessieren mich, Du beschreibst aus meiner Sicht
>zwei 
>verschiedene Probleme
>
>Am Sonntag 21 Januar 2018 11:15:37 schrieb Roland Hummel:
>> Vorher hatten wir XMPP (Prosody) lange im Test, die Client-Lage unter
>> iOS war aber mehr als dürfitg (nicht in Bezug darauf, dass es für iOS
>> keine XMPP-Clients gibt, sondern, 
>
>a) Kannst Du das näher erklären? Es scheint ja welche zu geben, die in
>Deinem 
>Test durchgefallen sind.
>
>https://xmpp.org/software/clients.html listet vier iOS Klienten, davon
>erscheinen mindestens die folgenden eine Erstprüfung auf Freie Software
>zu 
>bestehen:
>
>https://github.com/ChatSecure/ChatSecure-iOS
>  oder eine Variante https://github.com/zom/Zom-iOS
>https://tigase.tech/projects/tigase-ios-messenger/repository
>
>> dass diese spätestens in MUCs große 
>> Probleme gemacht haben, entweder weil der OMEMO-Schlüsselaustausch
>nicht
>> funktionierte oder weil Nachrichten nicht durchkamen).
>
>Das scheinen dann Implementierungsprobleme der XMPP Klienten auf iOS zu
>sein,
>richtig? Da XMPP sonst interessant erscheint (weil standardisierte 
>Protokollvarianten), würden sich vielleicht Problemberichte lohnen.
>
>> Auch unabhängig von der iOS-Problematik kamen bei XMPP immer mal
>wieder
>> nicht reproduzierbar Nachrichten nicht an und die Fehlermeldungen
>waren
>> nicht eindeutig (also: Fehlermeldung, dass eine Nachricht nicht
>> übermittelt wurde, sie kam aber an - keine Fehlermeldung, wenn eine
>> Nachricht angeblich übermittelt wurde, die aber nie ankam).
>
>Das wäre dann allgemeine XMPP Probleme mit den Protokollvarianten oder
>denkst 
>Du das es dabei auch um die Server-Implementation geht?
>
>Gruß,
>Bernhard
>
>-- 
>www.intevation.de/~bernhard   +49 541 33 508 3-3
>Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
>Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.___
FSFE-de mailing list
FSFE-de@lists.fsfe.org
https://lists.fsfe.org/mailman/listinfo/fsfe-de

Re: Freie Alternative zu einer Whatsapp/Threema-Gruppe

[Werner Koch]

On Thu, 25 Jan 2018 22:24, t...@documentfoundation.org said:

> mit dem autocrypt-Standard. K-9 und Enigmail sollten das IIRC in der

Das Schöne an Standards ist es, daß es so viele davon gibt.

Wenn ein Programmierer zu faul ist, einen MIME Parser zu benutzen, dann
werden Daten einfach in den RFC-822 Header geworfen und das als Standard
bezeichnet.  Der Standard um OpenPGP Keys zu versenden ist allerdings
seit 22 Jahren RFC-3156 (vormals RFC-2015).  Wer darüberhinaus weitere
Metadaten transportieren will, kann dies immer noch in MIME Headern des
application/pgp-keys Parts machen.


SCNR,

 Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpF3YypJP83N.pgp
Description: PGP signature
___
FSFE-de mailing list
FSFE-de@lists.fsfe.org
https://lists.fsfe.org/mailman/listinfo/fsfe-de