social.stefan-muenz.de

Search

Items tagged with: luca

Distanz Tracker für Innenräume. Jetzt echt @lehr_thorsten@twitter.com ? Nichts gelernt aus dem #Luca Debakel?
Öffnungen innovativ absichern – Distanztracker soll Hygienekonzepte verbessern und Nachverfolgung erleichtern
https://www.stuttgart.de/pressemitteilungen/2021/juni/corona-oeffnungen-innovativ-absichern-distanztracker-soll-hygienekonzepte-bei-verbessern-und-nachverfolgung-erleichtern.php
#Luca
 
Die #CoronaWarnApp wird für mich immer nutzloser. Obwohl schon lange angekündigt ist immer noch kein CheckIn mit #Luca QR-Code möglich. Heute in #MeckPom war also nirgends CheckIn möglich weil kein Schwein ein #cwa qr-code zur Verfügung stellt. Wann soll diese Funktion eigentlich nun wirklich kommen, in der achten Welle der #Corona #Pandemie?

(Nein ich werde das Vorort nicht mit den Angestellten diskutieren!)
 

#Luca QR-Code generieren


https://f-droid.org/packages/digital.selfdefense.lucia

#Lucia lässt einen Check-In Codes erzeugen, die angeblich valide sind. Falls jemand kein Bedürfnis verspürt, seine personenbezogenen #Daten einer shady Werbeklitsche mit kreativem Verhältnis zur Wahrheit und überraschendem Verständnis von #IT-Security zu senden …
 
#luca Verträge rück-abwickeln. Jetzt.
#luca
 
Du benutzt die #LucaApp, dein Name ist Frommer und wohnst in Fromhausen? Du wirst jetzt im CSV-Export fürs Gesundheitsamt "mer" heissen und in "hausen" wohnen. Und Name in nicht-Latin script geht gar nicht.
https://gitlab.com/lucaapp/web/-/blob/d671d978/services/health-department/src/utils/sanitizer.js

#bad #code #luca
 
Code injection - man sollte nicht glauben, dass das heute noch möglich ist.

#luca
#luca
 
@vilbi @sven @kuketzblog @digitalcourage
Der #Datenschutz hindert niemanden daran, Flottenverbräuche etc. zu erfassen. Es ist das Konzept, das immer die Gier nach persönlichen Daten beinhaltet, welches nicht passt.
Bestes Beispiel:
#Luca vs. Covid Warnapp
=
Desaster vs. smarte Intelligenz
 
Letztes Jahr hieß es noch, ein Zwang zur Benutzung der Corona Warn App ginge gar nicht. Nun regt es niemanden auf, dass Ladenketten Eintritt nur mit der Luca-App gewähren und Bundesländer die Benutzung dieser App per Verordnung zur Pflicht machen.

Unstete Zeiten, das …

#CWA #Luca
#CWA #Luca
 
#Luca #app #Datenschutz #Nordfriesland #Restaurant

Ja SCHEISSE! Jetzt hat man die Möglichkeit in Nordfriesland Essen oder Trinken zu gehen - aber NUR mit der verfickten Luca-App.
Daß die CoronaApp das auch kann ist irrelevant. Und Zettel und Stift machen die auch nicht. Tolle Wurst.
 
#Luca #app #Datenschutz #Nordfriesland #Restaurant

Ja SCHEISSE! Jetzt hat man die Möglichkeit in Nordfriesland Essen oder Trinken zu gehen - aber NUR mit der verfickten Luca-App.
Daß die CoronaApp das auch kann ist irrelevant. Und Zettel und Stift machen die auch nicht. Tolle Wurst.
 
Merkwürdig. Ich kenne Golem eigentlich als kritisch berichtend, aber hier wird beachtlich viel offensichtliche PR wiedergegeben. "Keine Sicherheitslücke gefunden". Well.

RT @golem@twitter.com

Digitale Gästelisten: Woher kommt der Hass auf die Luca-App? #Luca-App https://glm.io/156425?s

🐦🔗: https://twitter.com/golem/status/1392376109170372612
 
@sl007 funktioniert das bei jemandem? In meinem fiktiven #Luca Location-Account werden keine Check-ins angezeigt. #Luci zeigt den Namen der Location aber korrekt an. #LucaApp
 
#AnkeDomscheit-Berg sammelt seit Anfang April die Fails der #Luca App. Lesenwerter Thread.
https://nitter.eu/anked/status/1379665492739231744
 
Du wolltest schon immer alle Ministerpräsidenten auf einmal in Deinem bevorzugten Scherzartikel-Laden einchecken?

https://luci-app.de

#luca #luci #lucaApp
 
Die QR-Codes der #CoronaWarnApp und der #luca-App sind nun doch nicht kompatibel. Bedeutet nochmal 2 - 3 Wochen Wartezeit auf das entsprechende Update - und neue QR-Codes für 114.000 teilnehmende Geschäfte. 🙊https://www.golem.de/news/kontaktnachverfolgung-corona-warn-app-laesst-sich-leichter-trollen-als-die-luca-app-2105-156186.html
 
Ich freue mich sehr in einer #Modellregion zu leben! 🤦‍♂️

#luca #coesfeld #corona
Bild/Foto
 
#luca #lucaApp
Gemeinsame Stellungnahme zur digitalen Kontaktnachverfolgung

https://digikoletter.github.io
 
Weiß wer, ob es laufende Prozesse zur #Luca App gibt? Also Personen oder Vereine, die gegen den Einsatz klagen?
#Luca
 
Viele Menschen sorgen sich um ihre Daten – erstaunlicherweise mehr bei der Corona-Warn-App als bei der umstrittenen #Luca-App https://www.zeit.de/digital/datenschutz/2021-04/corona-warn-app-luca-app-datenschutz-sicherheit-smartphone/komplettansicht
 
RT @derfreitag
#Luca: Die Länder geben 20 Millionen Euro für eine überflüssige App aus https://www.freitag.de/autoren/der-freitag/luca-kam-sah-und-spionierte

Von Anne Roth @annalist
#Luca
 
#Luca-App:

Warum im Voraus bezahlte Lizenzen eine schlechte Idee sind.

Die meisten Bundesländer haben bereits Verträge mit Luca unterschrieben. Der IT-Unternehmer Ralf Rottmann fragt sich, warum sie für eine Jahreslizenz der App bereits vorab und pauschal Millionen von Euro an das junge Unternehmen zahlen – statt auf nutzungsabhängige Preismodelle zu bestehen, wie sie in der Branche üblich sind. ...

https://netzpolitik.org/2021/luca-app-warum-im-voraus-bezahlte-lizenzen-eine-schlechte-idee-sind/
 
Was ich noch zu sagen hatte..
#LucaApp

RT @derfreitag@twitter.com

#Luca: Die Länder geben 20 Millionen Euro für eine überflüssige App aus https://www.freitag.de/autoren/der-freitag/luca-kam-sah-und-spionierte

Von Anne Roth @annalist@twitter.com

🐦🔗: https://twitter.com/derfreitag/status/1385560346136616962
 
Heute habe ich #Datenschutzbeschwerde bei den Landesdatenschutzbeauftragten von Berlin und Baden-Württemberg gegen culture4life GmbH, den Machern der #Luca-App eingereicht.
https://www.fam-heidrich.net/datenschutzbeschwerde/
 
Habe ich damit zu #BoykottLuca aufgerufen?

#luca
 

#Sicherheit in der Luca-App und von #OpenSource allgemein


Durch einen Post von @Michael Vogel wurde ich auf ein Problem im Quellcode der Luca-App aufmerksam: https://pod.geraspora.de/posts/13446160

Die zwei kritischen Code-Stücke sind für das Testen zuständig und man findet sie hier: https://gitlab.com/lucaapp/android/-/blob/master/Luca/app/src/main/java/de/culture4life/luca/ui/registration/RegistrationViewModel.java

Teil 1:
public boolean isUsingTestingCredentials() {
return Objects.equals(firstName.getValue(), "John")
&& Objects.equals(lastName.getValue(), "Doe")
&& Objects.equals(phoneNumber.getValue(), "+4900000000000")
&& Objects.equals(email.getValue(), "john.doe@gmail.com");
}

Teil 2:
boolean isValidPhoneNumber(String phoneNumberString) {
if (isUsingTestingCredentials()) {
return true;
}
try {...

Als Hackerin mit Codex will ich mich darüber nicht nur lustig machen sondern erklären worin das Problem liegt und wie man es beheben kann.

Sicherheitsverständnis bei Open-Source

Ein weit verbreitete Fehleinschätzung ist, dass Open-Source sicherer ist als geheimer proprietärer Quellcode. Niemand außer dem Besitzer kann geheimen Quellcode prüfen und deswegen können Fehler jahrelang unbemerkt bleiben und nur von Eingeweihten ausgenutzt werden. So kann man im geheimen Quellcode problemlos Hintertüren und andere Schweinereien verstecken.

Open-Source oder freier Quellcode kann von jedem eingesehen werden und so ist es schwieriger dort Hintertüren zu verstecken. Diese Schwierigkeit macht den offenen Quellecode schon mal ein bisschen sicherer. Dann muss dieser Quellcode aber immer noch getestet, überprüft und kontrolliert werden. Geschieht dies nicht und alle vertrauen nur blind auf die Sicherheit dann ist das sehr fahrlässig. Es gibt leider Beispiele wo offensichtliche Fehler im frei zugänglichen Quellcode jahrelang übersehen wurden - siehe: Heartbleed - https://de.wikipedia.org/wiki/Heartbleed

Jetzt muss man aber auch die Philosophie von freier Software verstehen und die wird nirgendwo an der Universität gelehrt. Die muss man sich per Selbststudium im Internet beibringen. Wenn jeder in den Quellcode schauen kann und er danach immer noch sicher ist, dann habe ich echte Sicherheit (immer vorausgesetzt, dass Experten auch drauf geschaut haben). Das heißt natürlich, dass ich nichts in den Quellcode schreiben darf was man später ausnutzen kann (weil dies würde die Sicherheit schwächen).

Leider lernt man an der Universität oder Ausbildung sogut wie nichts über Sicherheit, die schon beim Design der Software ansetzt. Dies sind relativ neue Forschungen und die Ausbildungskräfte bilden sich nicht gut genug fort als das sie darüber Kenntnisse hätten. Für Wirtschaftsinformatiker scheint es wichtiger zu sein, dass sie profitabel sind und nicht sicheren Quellcode schreiben (blöder Kapitalismus).

Was ist hier das Problem?

Am oben gezeigten Quellcode sieht man, dass getestet wird. So was nennt man Test-Driven-Development und das ist zunächst etwas Gutes. Der Quellcode wird vor dem "Build" also dem zusammenbauen als fertige App zunächst automatisiert getestet und wenn ein Test fehlschlägt wird der "Build" abgebrochen, sodass der Fehler korrigiert werden muss. Der Fehler kann wenn er durch den Test erkannt wird also nicht beim Endbenutzer auftauchen.

Wie man aber in Teil 2 oben sieht kann man mit den Testdaten Prüfungen in der App umgehen und dadurch mehr Rechte erhalten. Noch viel schlimmer ist, dass wir in Teil 2 sehen, das der "try"-Teil erst nach der Prüfung auf Testdaten startet. "Try" ist für die Fehlerbehandlung zuständig und das bedeutet ich kann mit Testdaten die App in einen undefinierten Zustand bringen, weil es keine Fehlerbehandlung gibt. Diese undefinierten Zustände können Hacker häufig für Exploits ausnutzen.

Insgesamt also alles sehr schlecht!

Wie kann ich das besser machen?

1) Compilerflags - Mit Compilerflags kann ich verhindern, das bestimmte Programmteile in der produktiven App landen. Vereinfacht gesagt ich baue mir eine Testversion und wenn die funktioniert dann baue ich mir eine Produktivversion wo die Testfunktionen nicht enthalten sind. Großer Nachteil dieser Methode ist, das Programmierer gelegentlich vergessen, die Testfunktionen richtig rauszulöschen mit den Flags weil sie zu sehr unter Druck stehen und dann Fehler machen. So ist es häufiger schon passiert, dass unbeabsichtigt Testfunktionen doch im Produktivsystem gelandet sind. Ein weiteres Problem ist wenn Fehler nicht in der Testversion auftreten aber im Produktivsystem weil es anders gebaut wurde. Dann sind wahrscheinlich irgendwo die Compilerflags falsch gesetzt worden. Ein Fehler den man dann niemals machen darf, der aber schon passiert ist, ist, dass dann einfach die Testversion ausgeliefert wird in der Hoffnung, dass das niemand merkt.

2) Testflags verwenden - In der Testumgebung wird über die Konfiguration ein bestimmtes Flag gesetzt, sodass die Software weiß, dass sie im Testmodus ist. Nachteil ist, dass bösartige Hacker diese Flag auch in der Produktivumgebung setzen könnten.

3) So Testen, dass es keinen Unterschied macht (beste Lösung). Warum im Testsystem nicht mit anonymisierten oder pseudonymisierten Daten so testen wie unter echten Bedingungen? Meistens macht das etwas mehr Aufwand aber dafür hat man die Tests unter Echtbedingungen gemacht was den höchsten Wert hat. Keine Flags oder Funktionen im Quellcode die ausgenutzt werden könnten.
#luca #software #testen #test #sicherheit #problem #bildung #entwicklung #verstädnis #lernen #hack #hacking #app #smartphone #gesundheit #corona #programm
 

#Sicherheit in der Luca-App und von #OpenSource allgemein


Durch einen Post von @Michael Vogel wurde ich auf ein Problem im Quellcode der Luca-App aufmerksam: https://pod.geraspora.de/posts/13446160

Die zwei kritischen Code-Stücke sind für das Testen zuständig und man findet sie hier: https://gitlab.com/lucaapp/android/-/blob/master/Luca/app/src/main/java/de/culture4life/luca/ui/registration/RegistrationViewModel.java

Teil 1:
public boolean isUsingTestingCredentials() {
return Objects.equals(firstName.getValue(), "John")
&& Objects.equals(lastName.getValue(), "Doe")
&& Objects.equals(phoneNumber.getValue(), "+4900000000000")
&& Objects.equals(email.getValue(), "john.doe@gmail.com");
}

Teil 2:
boolean isValidPhoneNumber(String phoneNumberString) {
if (isUsingTestingCredentials()) {
return true;
}
try {...

Als Hackerin mit Codex will ich mich darüber nicht nur lustig machen sondern erklären worin das Problem liegt und wie man es beheben kann.

Sicherheitsverständnis bei Open-Source

Ein weit verbreitete Fehleinschätzung ist, dass Open-Source sicherer ist als geheimer proprietärer Quellcode. Niemand außer dem Besitzer kann geheimen Quellcode prüfen und deswegen können Fehler jahrelang unbemerkt bleiben und nur von Eingeweihten ausgenutzt werden. So kann man im geheimen Quellcode problemlos Hintertüren und andere Schweinereien verstecken.

Open-Source oder freier Quellcode kann von jedem eingesehen werden und so ist es schwieriger dort Hintertüren zu verstecken. Diese Schwierigkeit macht den offenen Quellecode schon mal ein bisschen sicherer. Dann muss dieser Quellcode aber immer noch getestet, überprüft und kontrolliert werden. Geschieht dies nicht und alle vertrauen nur blind auf die Sicherheit dann ist das sehr fahrlässig. Es gibt leider Beispiele wo offensichtliche Fehler im frei zugänglichen Quellcode jahrelang übersehen wurden - siehe: Heartbleed - https://de.wikipedia.org/wiki/Heartbleed

Jetzt muss man aber auch die Philosophie von freier Software verstehen und die wird nirgendwo an der Universität gelehrt. Die muss man sich per Selbststudium im Internet beibringen. Wenn jeder in den Quellcode schauen kann und er danach immer noch sicher ist, dann habe ich echte Sicherheit (immer vorausgesetzt, dass Experten auch drauf geschaut haben). Das heißt natürlich, dass ich nichts in den Quellcode schreiben darf was man später ausnutzen kann (weil dies würde die Sicherheit schwächen).

Leider lernt man an der Universität oder Ausbildung sogut wie nichts über Sicherheit, die schon beim Design der Software ansetzt. Dies sind relativ neue Forschungen und die Ausbildungskräfte bilden sich nicht gut genug fort als das sie darüber Kenntnisse hätten. Für Wirtschaftsinformatiker scheint es wichtiger zu sein, dass sie profitabel sind und nicht sicheren Quellcode schreiben (blöder Kapitalismus).

Was ist hier das Problem?

Am oben gezeigten Quellcode sieht man, dass getestet wird. So was nennt man Test-Driven-Development und das ist zunächst etwas Gutes. Der Quellcode wird vor dem "Build" also dem zusammenbauen als fertige App zunächst automatisiert getestet und wenn ein Test fehlschlägt wird der "Build" abgebrochen, sodass der Fehler korrigiert werden muss. Der Fehler kann wenn er durch den Test erkannt wird also nicht beim Endbenutzer auftauchen.

Wie man aber in Teil 2 oben sieht kann man mit den Testdaten Prüfungen in der App umgehen und dadurch mehr Rechte erhalten. Noch viel schlimmer ist, dass wir in Teil 2 sehen, das der "try"-Teil erst nach der Prüfung auf Testdaten startet. "Try" ist für die Fehlerbehandlung zuständig und das bedeutet ich kann mit Testdaten die App in einen undefinierten Zustand bringen, weil es keine Fehlerbehandlung gibt. Diese undefinierten Zustände können Hacker häufig für Exploits ausnutzen.

Insgesamt also alles sehr schlecht!

Wie kann ich das besser machen?

1) Compilerflags - Mit Compilerflags kann ich verhindern, das bestimmte Programmteile in der produktiven App landen. Vereinfacht gesagt ich baue mir eine Testversion und wenn die funktioniert dann baue ich mir eine Produktivversion wo die Testfunktionen nicht enthalten sind. Großer Nachteil dieser Methode ist, das Programmierer gelegentlich vergessen, die Testfunktionen richtig rauszulöschen mit den Flags weil sie zu sehr unter Druck stehen und dann Fehler machen. So ist es häufiger schon passiert, dass unbeabsichtigt Testfunktionen doch im Produktivsystem gelandet sind. Ein weiteres Problem ist wenn Fehler nicht in der Testversion auftreten aber im Produktivsystem weil es anders gebaut wurde. Dann sind wahrscheinlich irgendwo die Compilerflags falsch gesetzt worden. Ein Fehler den man dann niemals machen darf, der aber schon passiert ist, ist, dass dann einfach die Testversion ausgeliefert wird in der Hoffnung, dass das niemand merkt.

2) Testflags verwenden - In der Testumgebung wird über die Konfiguration ein bestimmtes Flag gesetzt, sodass die Software weiß, dass sie im Testmodus ist. Nachteil ist, dass bösartige Hacker diese Flag auch in der Produktivumgebung setzen könnten.

3) So Testen, dass es keinen Unterschied macht (beste Lösung). Warum im Testsystem nicht mit anonymisierten oder pseudonymisierten Daten so testen wie unter echten Bedingungen? Meistens macht das etwas mehr Aufwand aber dafür hat man die Tests unter Echtbedingungen gemacht was den höchsten Wert hat. Keine Flags oder Funktionen im Quellcode die ausgenutzt werden könnten.
#luca #software #testen #test #sicherheit #problem #bildung #entwicklung #verstädnis #lernen #hack #hacking #app #smartphone #gesundheit #corona #programm
 

#Sicherheit in der Luca-App und von #OpenSource allgemein


Durch einen Post von @Michael Vogel wurde ich auf ein Problem im Quellcode der Luca-App aufmerksam: https://pod.geraspora.de/posts/13446160

Die zwei kritischen Code-Stücke sind für das Testen zuständig und man findet sie hier: https://gitlab.com/lucaapp/android/-/blob/master/Luca/app/src/main/java/de/culture4life/luca/ui/registration/RegistrationViewModel.java

Teil 1:
public boolean isUsingTestingCredentials() {
return Objects.equals(firstName.getValue(), "John")
&& Objects.equals(lastName.getValue(), "Doe")
&& Objects.equals(phoneNumber.getValue(), "+4900000000000")
&& Objects.equals(email.getValue(), "john.doe@gmail.com");
}

Teil 2:
boolean isValidPhoneNumber(String phoneNumberString) {
if (isUsingTestingCredentials()) {
return true;
}
try {...

Als Hackerin mit Codex will ich mich darüber nicht nur lustig machen sondern erklären worin das Problem liegt und wie man es beheben kann.

Sicherheitsverständnis bei Open-Source

Ein weit verbreitete Fehleinschätzung ist, dass Open-Source sicherer ist als geheimer proprietärer Quellcode. Niemand außer dem Besitzer kann geheimen Quellcode prüfen und deswegen können Fehler jahrelang unbemerkt bleiben und nur von Eingeweihten ausgenutzt werden. So kann man im geheimen Quellcode problemlos Hintertüren und andere Schweinereien verstecken.

Open-Source oder freier Quellcode kann von jedem eingesehen werden und so ist es schwieriger dort Hintertüren zu verstecken. Diese Schwierigkeit macht den offenen Quellecode schon mal ein bisschen sicherer. Dann muss dieser Quellcode aber immer noch getestet, überprüft und kontrolliert werden. Geschieht dies nicht und alle vertrauen nur blind auf die Sicherheit dann ist das sehr fahrlässig. Es gibt leider Beispiele wo offensichtliche Fehler im frei zugänglichen Quellcode jahrelang übersehen wurden - siehe: Heartbleed - https://de.wikipedia.org/wiki/Heartbleed

Jetzt muss man aber auch die Philosophie von freier Software verstehen und die wird nirgendwo an der Universität gelehrt. Die muss man sich per Selbststudium im Internet beibringen. Wenn jeder in den Quellcode schauen kann und er danach immer noch sicher ist, dann habe ich echte Sicherheit (immer vorausgesetzt, dass Experten auch drauf geschaut haben). Das heißt natürlich, dass ich nichts in den Quellcode schreiben darf was man später ausnutzen kann (weil dies würde die Sicherheit schwächen).

Leider lernt man an der Universität oder Ausbildung sogut wie nichts über Sicherheit, die schon beim Design der Software ansetzt. Dies sind relativ neue Forschungen und die Ausbildungskräfte bilden sich nicht gut genug fort als das sie darüber Kenntnisse hätten. Für Wirtschaftsinformatiker scheint es wichtiger zu sein, dass sie profitabel sind und nicht sicheren Quellcode schreiben (blöder Kapitalismus).

Was ist hier das Problem?

Am oben gezeigten Quellcode sieht man, dass getestet wird. So was nennt man Test-Driven-Development und das ist zunächst etwas Gutes. Der Quellcode wird vor dem "Build" also dem zusammenbauen als fertige App zunächst automatisiert getestet und wenn ein Test fehlschlägt wird der "Build" abgebrochen, sodass der Fehler korrigiert werden muss. Der Fehler kann wenn er durch den Test erkannt wird also nicht beim Endbenutzer auftauchen.

Wie man aber in Teil 2 oben sieht kann man mit den Testdaten Prüfungen in der App umgehen und dadurch mehr Rechte erhalten. Noch viel schlimmer ist, dass wir in Teil 2 sehen, das der "try"-Teil erst nach der Prüfung auf Testdaten startet. "Try" ist für die Fehlerbehandlung zuständig und das bedeutet ich kann mit Testdaten die App in einen undefinierten Zustand bringen, weil es keine Fehlerbehandlung gibt. Diese undefinierten Zustände können Hacker häufig für Exploits ausnutzen.

Insgesamt also alles sehr schlecht!

Wie kann ich das besser machen?

1) Compilerflags - Mit Compilerflags kann ich verhindern, das bestimmte Programmteile in der produktiven App landen. Vereinfacht gesagt ich baue mir eine Testversion und wenn die funktioniert dann baue ich mir eine Produktivversion wo die Testfunktionen nicht enthalten sind. Großer Nachteil dieser Methode ist, das Programmierer gelegentlich vergessen, die Testfunktionen richtig rauszulöschen mit den Flags weil sie zu sehr unter Druck stehen und dann Fehler machen. So ist es häufiger schon passiert, dass unbeabsichtigt Testfunktionen doch im Produktivsystem gelandet sind. Ein weiteres Problem ist wenn Fehler nicht in der Testversion auftreten aber im Produktivsystem weil es anders gebaut wurde. Dann sind wahrscheinlich irgendwo die Compilerflags falsch gesetzt worden. Ein Fehler den man dann niemals machen darf, der aber schon passiert ist, ist, dass dann einfach die Testversion ausgeliefert wird in der Hoffnung, dass das niemand merkt.

2) Testflags verwenden - In der Testumgebung wird über die Konfiguration ein bestimmtes Flag gesetzt, sodass die Software weiß, dass sie im Testmodus ist. Nachteil ist, dass bösartige Hacker diese Flag auch in der Produktivumgebung setzen könnten.

3) So Testen, dass es keinen Unterschied macht (beste Lösung). Warum im Testsystem nicht mit anonymisierten oder pseudonymisierten Daten so testen wie unter echten Bedingungen? Meistens macht das etwas mehr Aufwand aber dafür hat man die Tests unter Echtbedingungen gemacht was den höchsten Wert hat. Keine Flags oder Funktionen im Quellcode die ausgenutzt werden könnten.
#luca #software #testen #test #sicherheit #problem #bildung #entwicklung #verstädnis #lernen #hack #hacking #app #smartphone #gesundheit #corona #programm
 

Brahahawaaaaaahhhhhh …!


https://www.reddit.com/r/de/comments/mt73uw/ein_tipp_f%C3%BCr_diejenigen_die_in_der_luca_app_nicht/

Ob diese #Luca App gegen irgendwas nützlich ist, keine Ahnung. Aber ziemlich sicher ist sie gut, um Schreikrämpfe zu produzieren. Was für eine dilettantische Deppensoftware.
#Luca
 
#Luca ist so ein Beispiel von "Wir haben ein Problem, lasst uns ein kompliziertes Tool nehmen um es zu lösen, Stift und Papier ist zu einfach".
#Luca
 
Ich meine, das hätte man sich doch denken können, dass man diese Scheiß Checkins spoofen kann, wenn der QR-Code statisch ist und der Checkin keine Challenge hat. Vielleicht hätten die doch wen fragen sollen wie sowas geht? #Luca #LucaApp
 
Bilanz der Corona-Warn-App #cwa

Klare und sachliche Einschätzungen zu CWA, #Luca und die #Apps in anderen Staaten

„Ich habe die CWA ... immer wieder verteidigt. Und die Kernfunktionalität finde ich auch immer noch gut. Aber dass jetzt eine private Anwendung der Standard für die Cluster-Benachrichtigung wird, liegt daran, dass man es verschlafen hat, die CWA rechtzeitig weiterzuentwickeln.“

https://netzpolitik.org/2021/bilanz-der-corona-warn-app-dann-hat-man-irgendwie-das-interesse-verloren/
 
Und zur Vollständigkeit auch noch mal von mir...

'Die zwielichtige Vergabepraxis zeugt bestenfalls von der Strahlkraft des Rappers Smudo, der bisher nicht als Programmierer oder Datenschützer aufgefallen war: Dem Investor der culture4life GmbH, die die Luca-App in Windeseile aus dem Boden gestampft hat, ist es binnen Monaten gelungen, Millionen für ein unreifes und untaugliches Produkt einzuwerben. Dabei vergisst Investor Smudo gern zu erwähnen, dass er mit über 22% am Unternehmen beteiligt ist, also nicht ohne beträchtlichen Eigennutz für die Luca-App wirbt.'


#Luca #Luca-App #Bürgerrechte #Datenschutz #COVID-Glücksritter #Smudo #NoSmudo #Verschwendung #Steuergeld #CWA #CCC #Corona
Scheiß App! Scheiß App! Scheiß App! Scheiß App! Scheiß App! Scheiß App! Scheiß App! Scheiß App! Scheiß App! Scheiß App! Scheiß App! #Luca! Scheiß App! Scheiß App! Scheiß App! Scheiß App! Scheiß App! Scheiß App! Scheiß App! Scheiß App! Scheiß App! Scheiß App! Scheiß App!
#Luca
 
Boah was war das denn? Kollegin kommt an meinen Arbeitsplatz, fragt mich im meine Meinung zu #luca und CWA. Und wischt dann alle meine angesprochen Aspekte zum Thema alle so vom Tisch weil Datenschutz hätte ja eh keinen Sinn und "die wissen ja eh alles schon von uns" und "die da oben machen ja eh was sie wollen".
Toll dass wir mal wieder drüber gesprochen haben.
Ich bin einfach zu nett. Hätte mich nicht auf das Gespräch einlassen sollen. Verschenkte Zeit und Energie.
#luca
 
Lauteshirn 🏳️‍🌈 - 2021-04-13 21:51:27 GMT
CCC fordert sofortigen Stopp der Luca-App und lückenlose Aufklärung. Ich auch!

#fuckluca #ccc #ichauch #luca #corona #bundesnotbremse

https://www.ccc.de/de/updates/2021/luca-app-ccc-fordert-bundesnotbremse
 
RT @zeitonline_dig@twitter.com

Neue Zweifel an der Sicherheit von #Luca: Durch die Lücke #LucaTrack konnten @bkastl@twitter.com und @rvnstn@twitter.com auf alle Orte zugreifen, an denen Menschen sich mit einem Schlüsselanhänger des Unternehmens eingecheckt hatten. https://www.zeit.de/digital/datenschutz/2021-04/luca-app-luecke-software-datenschutz-corona-kontaktverfolgung?wt_zmc=sm.int.zonaudev.twitter.ref.zeitde.redpost.link.x&utm_medium=sm&utm_source=twitter_zonaudev_int&utm_campaign=ref&utm_content=zeitde_redpost_link_x

🐦🔗: https://twitter.com/zeitonline_dig/status/1382089249231634441
 
"Die Betreiber von #Luca erhalten knapp 20 Millionen Euro von den Bundesländern" - Wo sind jetzt die ganzen Kritiker, die meinten das die #CWA Corona Warn App zu teuer war und "der Markt" das besser regeln würde? Das Luca ja kostenlos wäre? https://netzpolitik.org/2021/digitale-kontaktverfolgung-fast-20-millionen-euro-fuer-luca/
#Luca #CWA
 
Könnte ein Laden den QR–Code eines anderen Ladens aushängen und damit den Anmeldevorgang mittels #Luca–App unbemerkt in die Irre führen? App meldet User dann im falschen Laden an? Die Codes sind ja einfach fotografierbar.
 
[l] Sagt mal, diese Luca-App, … wo bleibt denn da das Bekennerschreiben? Zentrum für politische Schönheit oder so. Peng! Yes Men?

Eine Covid-App von Smudo? Ernsthaft? Die so offensichtlich schlecht ist, dass das vorbeifahrenden Passanten auffällt, die nicht mal wirklich geguckt haben?

Ich dachte mir die ganze Zeit, hey, das ist ein Versuch einer Satire, um zu zeigen, wie dämlich die Politik ist, dass die sich selbst so einen Schmarrn andrehen lässt, wenn sie SCHON EINE FUNKTIONERENDE APP HABEN, bezahlt vom Steuerzahler!

Dann kommt Mecklenburg-Vorpommern und kauft eine Lizenz.

Haha, dachte ich mir, erfolgreich vorgeführt! Jetzt können wir das aufklären!

Dann passiert … nichts. Für ein paar Wochen.

Dann kauft Hessen eine Lizenz.

Äh … Leute? Wo bleibt das Bekennerschreiben?

Dann lachen wir alle einmal herzhaft, wählen die Idioten in Hessen und Meckpomm ab, und es geht zurück zum regulären Elend.

Aber ich kriege langsam den Eindruck, dass das gar keine Satire war. Vielleicht fing es an als Satire? Die Fanta 4 haben sich gesagt: Pass uff, die führen wir jetzt mal so richtig vor. Niemand von uns muss nochmal arbeiten, wir haben nichts zu verlieren. Aber dann sahen sie, dass sie da ernsthaft auch noch Kohle rausziehen können und die Gier übernahm?

Was zur Hölle passiert hier gerade?!

#fefebot

#Luca #Luca-App
Um mitspielen zu können, hätte ich jetzt fast auch die #LucaApp installiert, aber leider gibt's die nur im deutschen App-Store. Alle, die ihren Account in anderen Ländern haben, können leider nicht mitmachen.

(Auch nicht in alle anderen #Luca-Locations. Tja.)

RT @thsStadler@twitter.com

Eure Chance! Schnell einchecken. Sonst verpasst ihr die geheime Party. #zdfmagazin

🐦🔗: https://twitter.com/thsStadler/status/1380629083177037831
Bild/Foto
 
Ein geplanter PR-Coup, bei dem Polit-Trullas, Journaille und Schlager-Trullas mitgemacht haben.

#luca

https://taz.de/Versagen-der-gehypten-Corona-App/!5759224/
#luca
 
Later posts Earlier posts