social.stefan-muenz.de

Search

Items tagged with: Programm

Hier noch einmal eine Erinnerung an das EuropaCamp 2021: Es beginn heute um 14:15 Uhr. Heute im Mittelpunkt: der Arabische Frühling. Zum Livestream geht's hier: https://europacamp.zeit-stiftung.de/#Programm #EuropaCamp #MyEurope Advertorial
Startseite

EuropaCamp: EuropaCamp – Act together! (FinnPriebe)

 

#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
 

Merkel hat Wort gehalten und ihren Plan DDR 2.0 damit erfüllt wenn wir dies #Diktatur #Programm nicht stoppen !

 
Wer weiß denn sowas? 👾

Frage zum Thema "Körper"

#tv #quiz #programm #fernsehen #show
Bild/Foto
 
Bild/Foto
Bild/Foto

Bild/Foto

#dwr #foto #fotografieren #mywork #goodmorning #fbg #fbd #jamendo #CC

Guten Morgen #Welt!

Wo die #Eichel ist, da ist auch #Scrat nicht weit!


Nun, wenn die Eichel auftaucht wird es meist spannend, lustig, es gibt coole #Sprüche, man kämpft um #Leben und #Tod und es wird kurzweilig.

Scrat, wird wahrscheinlich nicht auftauchen, aber eine #Klassenfahrt verspricht für alle Beteiligte ein ähnliches #Programm.

Also Leuts, es gibt heute noch einmal #Kaffee, aber den Rest der #Woche, macht ihr bitte einen auf #Selbstversorger.

Wir lesen uns in einer Woche!

hoffentlich

morituri te salutant

https://www.jamendo.com/track/237418/rock-in-peace-keep-on-rockin

#Frühstück #Kaffee #Kakao #Welt #Tee
 
Bild/Foto
Bild/Foto

Bild/Foto

#dwr #foto #fotografieren #mywork #goodmorning #fbg #fbd #jamendo #CC

Guten Morgen #Welt!

Wo die #Eichel ist, da ist auch #Scrat nicht weit!


Nun, wenn die Eichel auftaucht wird es meist spannend, lustig, es gibt coole #Sprüche, man kämpft um #Leben und #Tod und es wird kurzweilig.

Scrat, wird wahrscheinlich nicht auftauchen, aber eine #Klassenfahrt verspricht für alle Beteiligte ein ähnliches #Programm.

Also Leuts, es gibt heute noch einmal #Kaffee, aber den Rest der #Woche, macht ihr bitte einen auf #Selbstversorger.

Wir lesen uns in einer Woche!

hoffentlich

morituri te salutant

https://www.jamendo.com/track/237418/rock-in-peace-keep-on-rockin

#Frühstück #Kaffee #Kakao #Welt #Tee
 

Programm der Kieler Open Source und Linux Tage veröffentlicht


Bild/Foto

📌 Das Programm der 17. Kieler Open Source und Linux Tage, die am 20. und 21. September stattfinden, steht nun fest. Wie immer bietet die Veranstaltung bei freiem Eintritt Workshops, Vorträge und zahlreiche andere Aktivitäten. Zuvor gibt es die »Digitalen Woche Kiel«

#Programm #KielerOpenSource #OpenSource #Linux #LinuxTage #Kiel #Veranstaltung #Workshops #Vorträge #DigitaleWocheKiel #Workshop
 

Programm der Kieler Open Source und Linux Tage veröffentlicht


Bild/Foto

📌 Das Programm der 17. Kieler Open Source und Linux Tage, die am 20. und 21. September stattfinden, steht nun fest. Wie immer bietet die Veranstaltung bei freiem Eintritt Workshops, Vorträge und zahlreiche andere Aktivitäten. Zuvor gibt es die »Digitalen Woche Kiel«

#Programm #KielerOpenSource #OpenSource #Linux #LinuxTage #Kiel #Veranstaltung #Workshops #Vorträge #DigitaleWocheKiel #Workshop
 
Bild/Foto

The Telegraph: Why you should think twice before using viral AI photo editor FaceApp


Natasha Bernal 17 July 2019

Have you ever wondered what you will look like in 40 years' time? Thanks to an incredibly popular Russian artificial intelligence app, you can now share your a photo of your face to find out.



Thousands of people are flocking to use FaceApp, a smartphone app that can make them look older as part of an "age challenge" on social media, boosting it to the top of the Apple Store this week.

But FaceApp isn't new. The technology, created by Russian company Wireless Lab, first launched in 2017 and sparked outrage for offering people the chance to alter their images and look like they are a different race.

Now it has hit the headlines again because of how realistic the technology has become. It uses neural networks - artificial intelligence modelled after the human brain that can learn from patterns - to map people's faces and generate incredibly realistic images of what they will look like in the distant future.

But just because the app makes people look older, it clearly doesn't make them wiser. The sudden surge of popularity of the app raises concerns about people's privacy - and what this AI could do with an immense archive of people's faces.

One click, and you've handed the app the right to use your face

FaceApp allows you to upload an image of yourself or someone else with the click of a button, and automatically edits it to make a face look much older.

Similar to some of Snapchat's most popular image filters, this app can also alter your pictures to look like you are wearing sunglasses, have different hair colour, or are a different genders.

But when you use the app it is not just mapping your face; it is also sending it to the cloud, where it can be stored for an indefinite period of time.

Unlike other apps, the scanning of your photo does not happen on the smartphone but on the cloud, and the company can save a copy of a photo uploaded through the app even if you delete it from your phone.

In fact, one glance at the terms and conditions of FaceApp shows that you are giving the app a "perpetual, irrevocable, non-exclusive, royalty-free, worldwide, fully-paid, transferable sub-licensable license" to use and reproduce your image in all media formats "without compensation to you".

This means that you've sold your face for free and granted FaceApp access to your photo.

"If someone wants to collect personal information for nefarious purposes, one of the easiest ways to do it is to entice people to input the data for what appears to be some 'fun' purpose," says Alan Woodward, privacy expert at the University of Surrey.

"In this case you have no idea where it is being sent or who has access or what it may be used for, now or in the future.

"If you’re not a paying customer, then you will become the product. There's no such thing as a free lunch."

The app could be in 'serious breach' of data protection rules

Experts have already raised serious concerns over whether this app might be in breach of consumer's privacy.

Jonathan Kewley, partner and co-head of technology at law firm Clifford Chance, says that this app could be in serious breach of the European Union's data protection regulation, the GDPR, because it is not clear about how it is using people's data and how long it plans to keep it.

"It's a service directed to European data subjects. Even though it is marketed by a Russian company, it's clearly within the remit of GDPR. They need to have express consent," he argues.

"People think it's fun. But Cambridge Analytica was displayed as a game, and that didn't turn out to be fun."

What you need to know about the privacy row engulfing Facebook and Cambridge Analytica

Very little is known about Wireless Lab, the company that produced FaceApp, as it does not seem to have its own website or information about financial backers aside from its founder, Yaroslav Goncharov, a former technical lead at Microsoft and head of mobile platform at Russian search engine Yandex.

His app's terms and conditions may be available online on the FaceApp website, but those looking to download it straight from the Apple Store are not prompted to accept its terms and conditions before using it, which means that many people could have not provided informed consent.

The Information Commissioner's Office has not yet said whether it will step in to investigate this app, but stated that companies "must provide individuals with information including: purposes for processing their personal data, retention periods for that personal data, and who it will be shared with".

Your face could be gone forever

"It is not clear how FaceApp stores, uses, or manipulates peoples' data, including the detailed biometric maps of their faces, and this could change over time as profit incentives and technologies change," Jade Chong-Smith, legal officer at Privacy International explains. "Even if you delete FaceApp, there is nothing in the terms that governs what the company will do with all the data they have collected about you.

"While people may think that providing their photos and data is a small price to pay for the entertainment FaceApp offers, the app raises concerns about privacy, manipulation, and data exploitation—although these concerns are not necessarily unique to FaceApp."

Privacy International has warned that mass collection of faces is a "highly-prized commodity" for governments and tech companies, used to train algorithms and for facial recognition-enabled mass surveillance.

FaceApp did not respond to requests to comment.
#FaceApp #security #privacy #WirelessLab #Russia #photo #editor #programm #leak #personal #data #news
 
Later posts Earlier posts