Hallo,
ich bin die Tage auf einem Podcast[1] der GLS Bank über Online-Banking aufmerksam gemacht geworden. Interessant, ab ca 24:40 diskutieren sie die Möglichkeit eine Banking App als Freie Software über F-Droid anzubieten. Mein Eindruck ist, dass man zwar nicht ganz abgeneigt ist, aber doch noch viele Bedenken hat:
- Sie wüssten keinen Ansprechpartner der für den Support (und vermutlich auch für die Entwicklung) einer solchen App in Frage kommen würde.
- Haftungsfragen wenn beliebig modifizierte Banking-Apps zum Einsatz kommen können, wenn aus der Community bugs eingeschleust werden,...
usw.
Auf jeden Fall interessant sich mal die Gedanken und Bedenken dazu aus dem Bankenbereich anzuhören. Was denkt ihr, sind das reelle Bedenken?
Könnten wir als FSFE dazu beitragen hier Ängste und Unsicherheit abzubauen, da wo sie unbegründet ist?
[1] https://blog.gls.de/podcast/onlinebanking-gls-podcast-9/
Viele Grüße, Björn
Hey Björn,
On 20/02/2019 17.49, Bjoern Schiessle wrote:
ich bin die Tage auf einem Podcast[1] der GLS Bank über Online-Banking aufmerksam gemacht geworden. Interessant, ab ca 24:40 diskutieren sie die Möglichkeit eine Banking App als Freie Software über F-Droid anzubieten.
ich kenne den Podcast und habe bei der Stelle auch genau hingehört. Man muss dem Mitarbeiter anrechnen, dass er sich vorsichtig ausgedrückt hat und (mein Eindruck) versucht hat, die Vorurteile über FOSS zu vermeiden.
Als weitere Info:
Die mobile App der GLS-Bank [1] wird meiner Meinung nach sehr "stiefmütterlich" behandelt. Was aber auch daran liegt, dass IIRC die App zusammen für alle VR-Banken/genossenschaftlichen Banken entwickelt wird und dann nur umgebrandet wird. Wer darüber mehr weiß, soll mich bitte korrigieren.
Daher sollte man dort dann auch ansetzen, also bei diesen Leuten hier:
https://de.wikipedia.org/wiki/Bundesverband_der_Deutschen_Volksbanken_und_Ra...
Viele Grüße,
Jonke
[1] http://web.archive.org/web/20190220170652/https://play.google.com/store/apps...
Moin!
Am Mittwoch, 20. Februar 2019, 18:08:55 CET schrieb Jonke Suhr:
Als weitere Info:
Die mobile App der GLS-Bank [1] wird meiner Meinung nach sehr "stiefmütterlich" behandelt. Was aber auch daran liegt, dass IIRC die App zusammen für alle VR-Banken/genossenschaftlichen Banken entwickelt wird und dann nur umgebrandet wird. Wer darüber mehr weiß, soll mich bitte korrigieren.
Das ist richtig. Technisch gesehen ist die GLS-Bank eine VR-Bank und nutzt die IT-Infrastruktur dahinter. Das verbindet sie z.B. auch mit der Reisebank, die eine Tochter der DZ-Bank ist, aber das ist ein anderes Thema. :-)
Die Entwicklung für die VR-Banken macht i.d.R., aber m.W. nicht ausschließlich, die Fiducia GAD [1]. Ob die sich auch für die App verantwortlich zeichnen, weiss ich nicht.
Die App enthält neben der Oberfläche einen FinTS-Client, d.h. die Kommunikation erfolgt auf dem selben Weg wie das heimische Online-Banking und man kann es theoretisch mit jeder FinTS/HBCI 3.0 Implementierung anbinden. Wenn diese Hürde genommen wäre, dann wäre es "nur" noch eine UI, die entwickelt werden müsste.
Wenn man dann aber soweit wäre, wäre die Beschränkung der App auf die GLS-Bank ein Anti-Feature, weil der FinTS/HBCI-Kern mehr oder weniger direkt mit allen anderen unterstützenden Banken zugreifen könnte. Wenn die GLS-App aber (eingeschränktes) Multibanking bieten würde, dann wäre das möglicherweise eine Win-Win-Situation.
Viele Grüße Christian
[1] https://www.fiduciagad.de/startseite.html
On 21/02/2019 21.35, Christian Kalkhoff wrote:
Wenn man dann aber soweit wäre, wäre die Beschränkung der App auf die GLS-Bank ein Anti-Feature, weil der FinTS/HBCI-Kern mehr oder weniger direkt mit allen anderen unterstützenden Banken zugreifen könnte. Wenn die GLS-App aber (eingeschränktes) Multibanking bieten würde, dann wäre das möglicherweise eine Win-Win-Situation.
Ich fürchte soweit wird es nicht kommen, aber wir werden sehen. Für die GLS-Bank ist so ein Bankkonto mit FinTS-Zugang eben auch ein "Produkt" was vermarktet wird, und nicht nur reine Infrastruktur.
Allein schon aus dem Grund, dass unbedarfte Benutzer*innen einfach im Play Store nach "GLS Bank" suchen werden, um die App zu finden, wird es wohl bei einer gebrandeten Version bleiben.
Aber, Zukunftsmusik: Vielleicht wird die UI bzw. das Front-end ja in einem Repo veröffentlicht und jede (Genossenschafs-)bank hat ihren eigenen Fork.
Hallo Björn,
das ist in der Tat sehr interessant!
Bjoern Schiessle schiessle@fsfe.org writes:
- Sie wüssten keinen Ansprechpartner der für den Support (und
vermutlich auch für die Entwicklung) einer solchen App in Frage kommen würde.
Dazu haben ja ein paar Leute schon was gesagt und dem stimme ich soweit zu. Allerdings haben wir hier noch ein weiteres gutes Argument, wie man Freie Software in solche Bereiche bringen kann, selbst wenn die Bank selbst sowas nicht bereitstellt: Frei dokumentierte und implementierbare Schnittstellen. Es gibt solche im Bankingbereich bereits und wenn die Bank diese einfach anbietet und die Informationen dazu bereitstellt, sollte eigentlich jede beliebige Software mit der Bank kommunizieren können. In vielen Fällen geht das ja bereits mit aqbanking, das dann seinerseits mit z.B. Gnucash kommuniziert. Ehrlich gesagt wüsste ich auch keinen sinnvollen Grund, warum man für zwei verschiedene Banken zwei verschiedene Apps brauchen sollte.
- Haftungsfragen wenn beliebig modifizierte Banking-Apps zum Einsatz
kommen können, wenn aus der Community bugs eingeschleust werden,...
Hier könnte man mit Lizenzargumenten gut weiterkommen, weswegen ich auch die Lizenzarbeit für sehr wichtig ist (oft wird die als zu trocken angesehen). Viele gängige Lizenzen, sowohl wenn es um starkes Copyleft (z.B. AGPL) als auch im Bereich der Laissez-Faire-Lizenzen (z.B. Apache 2.0). Das wäre schon mal eine Absicherung und auch sonst spricht nichts dagegen, dass die Bank gewisse Releases signiert und vielleicht mehr Haftung übernimmt. Aber wenn die Schnittstellen auf Seiten der Bank sauber implementiert sind, sehe ich sowieso kein Problem, denn eine manipulierte App ist auch nicht viel anders als eine Original-App + Trojaner.
Auf jeden Fall interessant sich mal die Gedanken und Bedenken dazu aus dem Bankenbereich anzuhören. Was denkt ihr, sind das reelle Bedenken?
Ich denke man muss das ernst nehmen und die Leute dort abholen, wo sie gerade sind. Banken sind da sicher etwas konservativer, aber gerade bei den Genossenschaftsbanken sollte sich doch die Idee von Gemeinschaft und Teilen gut kommunizieren lassen, oder?
Happy hacking! Florian
Hallo, Liste,
Am 22.02.19 um 15:43 schrieb Florian Snow:
Frei dokumentierte und implementierbare Schnittstellen. Es gibt solche im Bankingbereich bereits und wenn die Bank diese einfach anbietet und die Informationen dazu bereitstellt, sollte eigentlich jede beliebige Software mit der Bank kommunizieren können. In vielen Fällen geht das ja bereits mit aqbanking,
ich rufe aktuell 1x pro Woche mit aqbanking die Kontoauszüge des Bankkontos ab, das die FSFE bei der GLS-Bank hat. Daraus generiere ich dann automatisiert z.B. die Aufzeichnungen für unsere Spendenverwaltung und die E-Mails an die Spender.
Viele Grüße,
Hallo Liste,
deutsche Banking Apps (soweit ich weiß auch die der VRs) verwenden den "Shield" des norwegischen Unternehmens Promon zur Isolierung im Endgerät. Der ist zwar geknackt, aber sowas hat ja noch nie jemanden interessiert. Promon ist ein Freund der "security through obscurity" wie zuletzt das Verfahren vor dem Landgericht Nürnberg-Fürth gegen Sicherheitsforscher gezeigt hat (https://www.heise.de/newsticker/meldung/Offenlegung-von-Softwareluecken-Rech...).
Code-Offenlegung wird es mit Promon nicht geben und die VR werden auf Promon nicht verzichten. Es geht dabei meiner Einschätzung nach vor allem um Haftungs-/Versicherungsfragen. Dagegen ist jede Argumentation zwecklos.
Wenn überhaupt wäre ein Alleingang der GLS denkbar, da die einen gewissen Gemeinnützigkeitsanspruch haben. Das wäre ein unglaublicher Erfolg. Halte ich aber für ausgeschlossen, da eine freie App nicht versicherbar ist.
Viele Grüße Ilu
Am 22.02.2019 um 15:57 schrieb Reinhard Müller:
Hallo, Liste,
Am 22.02.19 um 15:43 schrieb Florian Snow:
Frei dokumentierte und implementierbare Schnittstellen. Es gibt solche im Bankingbereich bereits und wenn die Bank diese einfach anbietet und die Informationen dazu bereitstellt, sollte eigentlich jede beliebige Software mit der Bank kommunizieren können. In vielen Fällen geht das ja bereits mit aqbanking,
ich rufe aktuell 1x pro Woche mit aqbanking die Kontoauszüge des Bankkontos ab, das die FSFE bei der GLS-Bank hat. Daraus generiere ich dann automatisiert z.B. die Aufzeichnungen für unsere Spendenverwaltung und die E-Mails an die Spender.
Viele Grüße,
FSFE-de mailing list FSFE-de@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/fsfe-de
Diese Mailingliste wird durch den Verhaltenskodex der FSFE abgedeckt. Alle Teilnehmer werden gebeten, sich gegenseitig vorbildlich zu behandeln: https://fsfe.org/about/codeofconduct
Hallo alle;
kurze Zwischenfrage hierzu:
Am 23.02.19 um 11:19 schrieb Ilu:
Code-Offenlegung wird es mit Promon nicht geben und die VR werden auf Promon nicht verzichten. Es geht dabei meiner Einschätzung nach vor allem um Haftungs-/Versicherungsfragen. Dagegen ist jede Argumentation zwecklos.
Die Anforderung, Haftungs- und Versicherungsfragen notfalls auch vertraglich geregelt zu bekommen, verstehe ich durchaus und kann insofern auch ein Stück weit verstehen, daß ein technisch "wackeliger" Partner wie Promon (der genau diese Anforderung erfüllen kann) im Zweifelsfall immer noch in solchen Umgebungen akzeptiert und gefragt ist.
=> Beschäftigt sich jemand mit der Frage, wie man dieser Anforderung mit SoftwareLibre begegnen kann? Gibt es dazu Ideen oder Ansätze?
Viele Grüße, Kristian
Hallo Kristian,
für die rechtliche Seite bräuchte man Insider-Informationen, an die man nur schwer rankommt, weil alle Beteiligten ein Interesse an der Geheimhaltung haben. Ich glaube nicht, daß jemand von uns da Informationen hat. Wenn man mit der GLS darüber ins Gespräch kommen kann, wäre das super. Nur eine Bank kann die nötigen Infos beschaffen.
Wenn es um technische Hintergründe geht, sollten die in dem Heise-Artikel angesprochenen verklagten Sicherheitsforscher sich bestens auskennen. Mit denen kann man mit Sicherheit ein Hintergrundgespräch führern. Schau Dir mal das Video von deren Vortrag auf dem 35c3 an.
Mir fällt grad ein, daß ich das Thema schonmal mit einem EDV-Verantwortlichen aus den VR besprochen hatte. Der war jung und aufgeschlossen, sagte aber, daß die Strukturen der VR alt und verkrustet seien und sich bei den Verantwortlichen der VR nichts bewegen läßt. Vorherrschende Unternehmensphilosophie: Das war schon immer so.
Die Anforderung, Haftungs- und Versicherungsfragen notfalls auch vertraglich geregelt zu bekommen, verstehe ich durchaus und kann
Nee, die kannst Du eben nicht vertraglich regeln. Die Bank müßte das angeblich zusätzliche Risiko tragen und das wird sie nicht tun. Auf den Kunden abwälzen darf sie es auch nicht. Die Versicherung wird sich stur stellen. Und Firmen wie Promon versprechen das Blaue vom Himmel und kommen damit durch. Das ist ein strukturelles Problem.
Es wäre ja schon viel gewonnen, wenn eine Bank ihre App außerhalb des Shops als apk zum Download anbieten würde. Oder auf nem Stick abgeben. Mit Promon und allem. Aber nichtmal das wirst Du erreichen.
Viele Grüße Ilu
Am 23.02.2019 um 12:41 schrieb Kristian Rink:
Hallo alle;
kurze Zwischenfrage hierzu:
Am 23.02.19 um 11:19 schrieb Ilu:
Code-Offenlegung wird es mit Promon nicht geben und die VR werden auf Promon nicht verzichten. Es geht dabei meiner Einschätzung nach vor allem um Haftungs-/Versicherungsfragen. Dagegen ist jede Argumentation zwecklos.
Die Anforderung, Haftungs- und Versicherungsfragen notfalls auch vertraglich geregelt zu bekommen, verstehe ich durchaus und kann insofern auch ein Stück weit verstehen, daß ein technisch "wackeliger" Partner wie Promon (der genau diese Anforderung erfüllen kann) im Zweifelsfall immer noch in solchen Umgebungen akzeptiert und gefragt ist.
=> Beschäftigt sich jemand mit der Frage, wie man dieser Anforderung mit SoftwareLibre begegnen kann? Gibt es dazu Ideen oder Ansätze?
Viele Grüße, Kristian
Hallo Kristian,
für die rechtliche Seite bräuchte man Insider-Informationen, an die man nur schwer rankommt, weil alle Beteiligten ein Interesse an der Geheimhaltung haben. Ich glaube nicht, daß jemand von uns da Informationen hat. Wenn man mit der GLS darüber ins Gespräch kommen kann, wäre das super. Nur eine Bank kann die nötigen Infos beschaffen.
Wenn es um technische Hintergründe geht, sollten die in dem Heise-Artikel angesprochenen verklagten Sicherheitsforscher sich bestens auskennen. Mit denen kann man mit Sicherheit ein Hintergrundgespräch führern. Schau Dir mal das Video von deren Vortrag auf dem 35c3 an.
Mir fällt grad ein, daß ich das Thema schonmal mit einem EDV-Verantwortlichen aus den VR besprochen hatte. Der war jung und aufgeschlossen, sagte aber, daß die Strukturen der VR alt und verkrustet seien und sich bei den Verantwortlichen der VR nichts bewegen läßt. Vorherrschende Unternehmensphilosophie: Das war schon immer so.
Die Anforderung, Haftungs- und Versicherungsfragen notfalls auch vertraglich geregelt zu bekommen, verstehe ich durchaus und kann
Nee, die kannst Du eben nicht vertraglich regeln. Die Bank müßte das angeblich zusätzliche Risiko tragen und das wird sie nicht tun. Auf den Kunden abwälzen darf sie es auch nicht. Die Versicherung wird sich stur stellen. Und Firmen wie Promon versprechen das Blaue vom Himmel und kommen damit durch. Das ist ein strukturelles Problem.
Es wäre ja schon viel gewonnen, wenn eine Bank ihre App außerhalb des Shops als apk zum Download anbieten würde. Oder auf nem Stick abgeben. Mit Promon und allem. Aber nichtmal das wirst Du erreichen.
Viele Grüße Ilu
Am 23.02.2019 um 12:41 schrieb Kristian Rink:
Hallo alle;
kurze Zwischenfrage hierzu:
Am 23.02.19 um 11:19 schrieb Ilu:
Code-Offenlegung wird es mit Promon nicht geben und die VR werden auf Promon nicht verzichten. Es geht dabei meiner Einschätzung nach vor allem um Haftungs-/Versicherungsfragen. Dagegen ist jede Argumentation zwecklos.
Die Anforderung, Haftungs- und Versicherungsfragen notfalls auch vertraglich geregelt zu bekommen, verstehe ich durchaus und kann insofern auch ein Stück weit verstehen, daß ein technisch "wackeliger" Partner wie Promon (der genau diese Anforderung erfüllen kann) im Zweifelsfall immer noch in solchen Umgebungen akzeptiert und gefragt ist.
=> Beschäftigt sich jemand mit der Frage, wie man dieser Anforderung mit SoftwareLibre begegnen kann? Gibt es dazu Ideen oder Ansätze?
Viele Grüße, Kristian
Hier mal noch ein Nachtrag (weiß nicht wie mir das entgangen ist):
https://subsembly.com/oem.html
Die GLS-Bank nutzt das "Whitelabel-Angebot" der Firma Subsembly. Zu den bereits genannten Gründen käme also auch noch ein nicht unerheblicher Pfadabhängigkeitseffekt hinzu (komplett neue Codebasis wäre erforderlich).
Pressemitteilung der GLS-Bank:
https://www.gls.de/privatkunden/gls-bank/aktuelles/presse/app-gls-mbank-gls-...
On 23/02/2019 11.19, Ilu wrote:
Hallo Liste,
deutsche Banking Apps (soweit ich weiß auch die der VRs) verwenden den "Shield" des norwegischen Unternehmens Promon zur Isolierung im Endgerät. Der ist zwar geknackt, aber sowas hat ja noch nie jemanden interessiert. Promon ist ein Freund der "security through obscurity" wie zuletzt das Verfahren vor dem Landgericht Nürnberg-Fürth gegen Sicherheitsforscher gezeigt hat (https://www.heise.de/newsticker/meldung/Offenlegung-von-Softwareluecken-Rech...).
Code-Offenlegung wird es mit Promon nicht geben und die VR werden auf Promon nicht verzichten. Es geht dabei meiner Einschätzung nach vor allem um Haftungs-/Versicherungsfragen. Dagegen ist jede Argumentation zwecklos.
Wenn überhaupt wäre ein Alleingang der GLS denkbar, da die einen gewissen Gemeinnützigkeitsanspruch haben. Das wäre ein unglaublicher Erfolg. Halte ich aber für ausgeschlossen, da eine freie App nicht versicherbar ist.
Viele Grüße Ilu
Am 22.02.2019 um 15:57 schrieb Reinhard Müller:
Hallo, Liste,
Am 22.02.19 um 15:43 schrieb Florian Snow:
Frei dokumentierte und implementierbare Schnittstellen. Es gibt solche im Bankingbereich bereits und wenn die Bank diese einfach anbietet und die Informationen dazu bereitstellt, sollte eigentlich jede beliebige Software mit der Bank kommunizieren können. In vielen Fällen geht das ja bereits mit aqbanking,
ich rufe aktuell 1x pro Woche mit aqbanking die Kontoauszüge des Bankkontos ab, das die FSFE bei der GLS-Bank hat. Daraus generiere ich dann automatisiert z.B. die Aufzeichnungen für unsere Spendenverwaltung und die E-Mails an die Spender.
Viele Grüße,
FSFE-de mailing list FSFE-de@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/fsfe-de
Diese Mailingliste wird durch den Verhaltenskodex der FSFE abgedeckt. Alle Teilnehmer werden gebeten, sich gegenseitig vorbildlich zu behandeln: https://fsfe.org/about/codeofconduct
FSFE-de mailing list FSFE-de@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/fsfe-de
Diese Mailingliste wird durch den Verhaltenskodex der FSFE abgedeckt. Alle Teilnehmer werden gebeten, sich gegenseitig vorbildlich zu behandeln: https://fsfe.org/about/codeofconduct
Am 22.02.2019 um 15:43 schrieb Florian Snow:
- Haftungsfragen wenn beliebig modifizierte Banking-Apps zum Einsatz
kommen können, wenn aus der Community bugs eingeschleust werden,...
Hier könnte man mit Lizenzargumenten gut weiterkommen, weswegen ich auch die Lizenzarbeit für sehr wichtig ist (oft wird die als zu trocken angesehen). Viele gängige Lizenzen, sowohl wenn es um starkes Copyleft (z.B. AGPL) als auch im Bereich der Laissez-Faire-Lizenzen (z.B. Apache 2.0). Das wäre schon mal eine Absicherung und auch sonst spricht nichts dagegen, dass die Bank gewisse Releases signiert und vielleicht mehr Haftung übernimmt. Aber wenn die Schnittstellen auf Seiten der Bank sauber implementiert sind, sehe ich sowieso kein Problem, denn eine manipulierte App ist auch nicht viel anders als eine Original-App + Trojaner.
Ich denke nicht, dass man unter Verweis auf die entsprechenden Ausschlussklauseln in den Lizenzen Haftungsfragen endgültig erledigen kann. Insoweit gibt es noch keine einschlägige, vor allem keine höchstrichterliche Rechtsprechung.
Allerdings können offener Quellcode, einschließlich der Buildskripts, nachvollziehbare Builds mit bitgleichem Ergebnis, Hashes und Signaturen einen hohen Sicherheitsstandard generieren, welcher sich wohl auch PR-mäßig verwerten lässt. Erfordert aber ein aufgeklärtes Publikum und damit etwas Aufklärungsarbeit.
Gruß Michael
Hallo Michael,
"Dr. Michael Stehmann" anwalt@rechtsanwalt-stehmann.de writes:
Ich denke nicht, dass man unter Verweis auf die entsprechenden Ausschlussklauseln in den Lizenzen Haftungsfragen endgültig erledigen kann. Insoweit gibt es noch keine einschlägige, vor allem keine höchstrichterliche Rechtsprechung.
Das ist natürlich richtig. Ich denke nur die Ausschlussklauseln können als Argumentationshilfe dienen.
Happy hacking! Florian