social.stefan-muenz.de
#Linux bans #University of #Minnesota for committing malicious #code
source: https://www.bleepingcomputer.com/news/security/linux-bans-university-of-minnesota-for-committing-malicious-code/The move comes after a group of UMN researchers were caught submitting a series of malicious code commits, or #patches that deliberately introduced #security vulnerabilities in the official Linux #codebase, as a part of their #research activities.These days I often have the feeling that everyone is going #crazy and has reached the end of their intellectual capacity. :(
#Fail #science #bug #exploration #software #source #opensource #floss #freedom #newsLinux bans University of Minnesota for committing malicious code
Linux kernel project maintainers have imposed a ban on the University of Minnesota (UMN) from contributing to the open-source Linux project after a group of UMN researchers were caught submitting a series of malicious code commits, or patches that deliberately introduced security vulnerabilities in the official Linux project.www.bleepingcomputer.com
The move comes after a group of UMN researchers were caught submitting a series of malicious code commits, or #patches that deliberately introduced #security vulnerabilities in the official Linux #codebase, as a part of their #research activities.These days I often have the feeling that everyone is going #crazy and has reached the end of their intellectual capacity. :(
Linux kernel project maintainers have imposed a ban on the University of Minnesota (UMN) from contributing to the open-source Linux project after a group of UMN researchers were caught submitting a series of malicious code commits, or patches that deliberately introduced security vulnerabilities in the official Linux project.www.bleepingcomputer.com
#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 #programmDie #LucaApp offenbart immer wieder Glanzstücke der IT-Sicherheit i...
Die #LucaApp offenbart immer wieder Glanzstücke der IT-Sicherheit im Code. Hart kodierte Accountdaten in der Luca-App, die die Prüfung der Telefonnummer übergehen https://i.imgur.com/2WmTdVE.pngpod.geraspora.de
#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 #programmDie #LucaApp offenbart immer wieder Glanzstücke der IT-Sicherheit i...
Die #LucaApp offenbart immer wieder Glanzstücke der IT-Sicherheit im Code. Hart kodierte Accountdaten in der Luca-App, die die Prüfung der Telefonnummer übergehen https://i.imgur.com/2WmTdVE.pngpod.geraspora.de
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");}boolean isValidPhoneNumber(String phoneNumberString) {if (isUsingTestingCredentials()) {return true;}try {...
Die #LucaApp offenbart immer wieder Glanzstücke der IT-Sicherheit im Code. Hart kodierte Accountdaten in der Luca-App, die die Prüfung der Telefonnummer übergehen https://i.imgur.com/2WmTdVE.pngpod.geraspora.de
#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
Mailbox: Anbieter hat neue Tarife
Der Berliner Anbieter Mailbox hat sein neues Tarifsystem vorgestellt.
Statt der bisherigen Unterscheidung in „Secure Mail“, „Team-Mail“ und
„Office“-Tarife mit verschiedenen, eher unflexiblen Speicherpaketen,
orientieren sich die drei neuen Tarife STANDARD, PREMIUM und LIGHT ab
sofort mehr am gewünschten Funktions- und Support-Umfang des Nutzers.
Das benötigte Speichervolumen für E-Mails und Drive-Dateien lässt sich
nun flexibel hinzubuchen, so der Anbieter.
{.aligncenter
.size-medium .wp-image-1043500 width="720"
height="392"}
Die Light-Variante ist für 1 Euro im Monat zu haben, dafür gibt’s 3
Alias-Adressen mit @mailbox.org sowie 2 GB Speicher. Der Standard-Tarif
für 3 Euro bringt natürlich mehr – siehe Bild-Übersicht, des Weiteren
gibt’s da bei jährlicher Zahlung 2 Monate gratis, sprich: Man zahlt 30
Euro für das Jahr. Eine komplette Übersicht der neuen Tarife und Infos
für Bestandskunden gibt’s an dieser
Stelle.
Vorschau Produkt Preis ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- [{.aawp-product__img}](https://www.amazon.de/dp/B08C1KN5J2?tag=cascblog00-21&linkCode=osi&th=1&psc=1 "Fire TV Stick mit Alexa-Sprachfernbedienung (mit TV-Steuerungstasten) | HD-Streaminggerät | 2021") [Fire TV Stick mit Alexa-Sprachfernbedienung (mit TV-Steuerungstasten) | HD-Streaminggerät | 2021](https://www.amazon.de/dp/B08C1KN5J2?tag=cascblog00-21&linkCode=osi&th=1&psc=1 "Fire TV Stick mit Alexa-Sprachfernbedienung (mit TV-Steuerungstasten) | HD-Streaminggerät | 2021"){.aawp-product__title} [39,99 EUR]{.aawp-product__price}[](https://www.amazon.de/gp/prime/?tag=cascblog00-21 "Amazon Prime"){.aawp-check-prime} [Bei Amazon ansehen](https://www.amazon.de/dp/B08C1KN5J2?tag=cascblog00-21&linkCode=osi&th=1&psc=1 "Bei Amazon ansehen"){.aawp-button .aawp-button--buy .aawp-button .aawp-button--amazon .aawp-button--icon .aawp-button--icon-black} [{.aawp-product__img}](https://www.amazon.de/dp/B08V5P2T43?tag=cascblog00-21&linkCode=ogi&th=1&psc=1 "Microsoft 365 Family 12+3 Monate Abonnement | 6 Nutzer | Mehrere PCs/Macs, Tablets/mobile Geräte |...") [Microsoft 365 Family 12+3 Monate Abonnement | 6 Nutzer | Mehrere PCs/Macs, Tablets/mobile Geräte...](https://www.amazon.de/dp/B08V5P2T43?tag=cascblog00-21&linkCode=ogi&th=1&psc=1 "Microsoft 365 Family 12+3 Monate Abonnement | 6 Nutzer | Mehrere PCs/Macs, Tablets/mobile Geräte |..."){.aawp-product__title} [54,99 EUR]{.aawp-product__price} [Bei Amazon ansehen](https://www.amazon.de/dp/B08V5P2T43?tag=cascblog00-21&linkCode=ogi&th=1&psc=1 "Bei Amazon ansehen"){.aawp-button .aawp-button--buy .aawp-button .aawp-button--amazon .aawp-button--icon .aawp-button--icon-black} [{.aawp-product__img}](https://www.amazon.de/dp/B083VVZ8VX?tag=cascblog00-21&linkCode=osi&th=1&psc=1 "Fire TV Cube│Hands-free mit Alexa, 4K Ultra HD-Streaming-Mediaplayer") [Fire TV Cube│Hands-free mit Alexa, 4K Ultra HD-Streaming-Mediaplayer](https://www.amazon.de/dp/B083VVZ8VX?tag=cascblog00-21&linkCode=osi&th=1&psc=1 "Fire TV Cube│Hands-free mit Alexa, 4K Ultra HD-Streaming-Mediaplayer"){.aawp-product__title} [119,99 EUR]{.aawp-product__price}[](https://www.amazon.de/gp/prime/?tag=cascblog00-21 "Amazon Prime"){.aawp-check-prime} [Bei Amazon ansehen](https://www.amazon.de/dp/B083VVZ8VX?tag=cascblog00-21&linkCode=osi&th=1&psc=1 "Bei Amazon ansehen"){.aawp-button .aawp-button--buy .aawp-button .aawp-button--amazon .aawp-button--icon .aawp-button--icon-black} [{.aawp-product__img}](https://www.amazon.de/dp/B07PW9VBK5?tag=cascblog00-21&linkCode=osi&th=1&psc=1 "Fire TV Stick 4K Ultra HD mit Alexa-Sprachfernbedienung") [Fire TV Stick 4K Ultra HD mit Alexa-Sprachfernbedienung](https://www.amazon.de/dp/B07PW9VBK5?tag=cascblog00-21&linkCode=osi&th=1&psc=1 "Fire TV Stick 4K Ultra HD mit Alexa-Sprachfernbedienung"){.aawp-product__title} [59,99 EUR]{.aawp-product__price}[](https://www.amazon.de/gp/prime/?tag=cascblog00-21 "Amazon Prime"){.aawp-check-prime} [Bei Amazon ansehen](https://www.amazon.de/dp/B07PW9VBK5?tag=cascblog00-21&linkCode=osi&th=1&psc=1 "Bei Amazon ansehen"){.aawp-button .aawp-button--buy .aawp-button .aawp-button--amazon .aawp-button--icon .aawp-button--icon-black}
-> Zum Beitrag Mailbox: Anbieter hat neue
Tarife
-> Zum Blog Caschys Blog
Unser Feedsponsor:
{.aligncenter
.size-full}
[](http://feeds.feedburner.com/~ff/stadt-bremerhaven/dqXM?a=NBToh7WNSHA:T_6xzyKpYew:D7DqB2pKExk) [](http://feeds.feedburner.com/~ff/stadt-bremerhaven/dqXM?a=NBToh7WNSHA:T_6xzyKpYew:ACf-c_HutVc) [](http://feeds.feedburner.com/~ff/stadt-bremerhaven/dqXM?a=NBToh7WNSHA:T_6xzyKpYew:F7zBnMyn0Lo) [](http://feeds.feedburner.com/~ff/stadt-bremerhaven/dqXM?a=NBToh7WNSHA:T_6xzyKpYew:7Q72WNTAKBA) [](http://feeds.feedburner.com/~ff/stadt-bremerhaven/dqXM?a=NBToh7WNSHA:T_6xzyKpYew:V_sGLiPBpWU) [](http://feeds.feedburner.com/~ff/stadt-bremerhaven/dqXM?a=NBToh7WNSHA:T_6xzyKpYew:gIN9vFwOqvQ) [](http://feeds.feedburner.com/~ff/stadt-bremerhaven/dqXM?a=NBToh7WNSHA:T_6xzyKpYew:yIl2AUoC8zA){width="1"
height="1"}
http://feedproxy.google.com/~r/stadt-bremerhaven/dqXM/~3/NBToh7WNSHA/
#rss #software #news #caschys #Internet
Sony Xperia 1 III, Xperia 5 III und Xperia 10 III offiziell vorgestellt
{.aligncenter
.size-medium .wp-image-1043469 width="720" height="584"}
Sony hat heute drei neue Smartphones präsentiert: die Xperia 1 III,
Xperia 5 III und Xperia 10 III. Flaggschiff ist dabei das Xperia 1
III,
welches mit dem Qualcomm Snapdragon 888 und 12 GByte RAM plus bis zu
512 GByte Speicherplatz aufwarten darf und eine Hauptkamera mit vier
Sensoren nutzt. Die Besonderheit ist, dass auch eine Periskop-Linse mit
von der Partie
ist.{width="1"
height="1"}
So bietet die Hauptlinse 12 Megapixel (Weitwinkel), dazu kommen besagte
Telephoto-Kamera mit ebenfalls 12 Megapixeln plus eine
Ultra-Weitwinkel-Kamera mit 12 Megapixeln und zusätzlich ein
Tiefensensor. Dank der Periskop-Bauweise kann die Telephoto-Kamera von
70 mm auch auf 105 mm gestellt werden. Dann reduziert sich jedoch die
Lichtempfindlichkeit bzw. Blende von f/2.3 auf f/2.8. Sony nutzt dabei
das Zeiss-Branding für seine Kamera. Ebenfalls hebt man das
AMOLED-Display mit 6,5 Zoll Diagonale und 4K-Auflösung im Format 21:9
hervor, das eine Bildwiederholrate von 120 Hz bietet. Die
Touch-Abtastrate lieg bei 240 Hz.
{.aligncenter
.size-medium .wp-image-1043471 width="720" height="592"}
Ab Werk dient Android 11 als Betriebssystem. Der Akku kommt leider nur
auf 4.500 mAh, was etwas schwach auf der Brust wirkt, bedenkt man die
Spezifikationen. Sony behält auch den Port für 3,5-mm-Audio bei. Auch
verbaut ist eine gesonderte Auslösetaste für die Kamera, die Sony in
seiner Pressemitteilung gar mit den hauseigenen Alpha-Systemkameras
vergleicht, was dann doch etwas hoch gegriffen wirkt. Auch an seiner
Kamera-App hat das Unternehmen gebastelt und will etwa einen „Basic
Mode“ in Photography Pro anbieten, der einen schnellen Zugriff auf eine
Reihe von Fotografie-Funktionen ermögliche.
Das Sony Xperia 1 III kann nicht nur normale 4K-Videos mit 60 fps
anfertigen, sondern auch Zeitlupen-Videos in 4K bei 120 fps. Das
Smartphone beherrscht auch die kabellose Aufladung und sogar Reverse
Wireless Charging, kann also selbst auch andere Geräte aufladen. Zudem
ist das Sony Xperia 1 III nach Schutzklasse IP65/68 resistent gegen
Staub und Wasser – gilt auch für das Xperia 5 III. Im Lieferumfang ist
ein Ladegerät enthalten, das die Akkus der beiden Geräte mit 30 Watt
aufladen kann. Erwähnenswert sind noch die Stereo-Lautsprecher, die
Dolby Atmos unterstützen, auch wenn das bei einem Smartphone eher eine
Marketing-Geschichte ist. Auch Sonys 360 Reality
Audio
beherrschen die Speaker.
{.aligncenter
.size-medium .wp-image-1043472 width="720" height="589"}
Dazu gesellt sich das Xperia 5 III, das im Grunde eine abgespeckte
Version des Flaggschiffs darstellt. Auch hier dient der Qualcomm
Snapdragon 888 als SoC und es kommt eine fast identische Hauptkamera zum
Einsatz. Lediglich den Tiefensensor streicht Sony. Das AMOLED-Display im
Format 21:9 ist nun 6,1 Zoll groß und bietet weiterhin 120 Hz als
Bildwiederholrate bzw. 240 Hz als Touch-Abtastrate. Jedoch reduziert
sich die Auflösung von 4K auf FHD. Zudem schrumpft der RAM von 12 auf 8
GByte und es gibt maximal 256 GByte Speicherplatz.
Die Akkukapazität verbleibt bei 4.500 mAh, die Möglichkeit zur
kabellosen Aufladung fällt jedoch weg – auch das Reverse Wireless
Charging segnet somit logischerweise das Zeitliche.
{.aligncenter
.size-medium .wp-image-1043473 width="720" height="539"}
Nachgereicht wurde außerdem noch das neue Sony Xperia 10 III mit 6 Zoll
Diagonale im Format 21:9, abermals einem AMOLED-Display und FHD+ als
Auflösung. Hier arbeitet das Display mit 60 Hz und es dient der Qualcomm
Snapdragon 690 als Chip. 5G bleibt somit auch hier an Bord. In diesem
Fall ist eine Triple-Kamera mit 12 (Weitwinkel) + 8 (Ultra-Weitwinkel) +
8 (Telephoto) Megapixeln an Bord. Das variable Teleobjektiv der beiden
höherwertigen Modelle fehlt hier. Der Akku steht abermals bei 4.500 mAh.
Auch dieses Smartphone ist nach Schutzklasse IP65/IP68 vor Staub und
Wasser geschützt.
Verfügbarkeit
Das Xperia 1 III wird in den Farben Schwarz und Violett und das Xperia 5
III in den Farben Schwarz und Grün ab dem Frühsommer mit Android 11
erhältlich sein. Das Xperia 10 III wird in den Farben Schwarz, Weiß,
Blau und Rosa ab dem Frühsommer 2021 erhältlich sein. Preise verschweigt
Sony leider noch.
-> Zum Beitrag Sony Xperia 1 III, Xperia 5 III und Xperia 10 III
offiziell
vorgestellt
-> Zum Blog Caschys Blog
Unser Feedsponsor:
{.aligncenter
.size-full}
[](http://feeds.feedburner.com/~ff/stadt-bremerhaven/dqXM?a=RLsSu5w7hMM:4TgCRDbG9w4:D7DqB2pKExk) [](http://feeds.feedburner.com/~ff/stadt-bremerhaven/dqXM?a=RLsSu5w7hMM:4TgCRDbG9w4:ACf-c_HutVc) [](http://feeds.feedburner.com/~ff/stadt-bremerhaven/dqXM?a=RLsSu5w7hMM:4TgCRDbG9w4:F7zBnMyn0Lo) [](http://feeds.feedburner.com/~ff/stadt-bremerhaven/dqXM?a=RLsSu5w7hMM:4TgCRDbG9w4:7Q72WNTAKBA) [](http://feeds.feedburner.com/~ff/stadt-bremerhaven/dqXM?a=RLsSu5w7hMM:4TgCRDbG9w4:V_sGLiPBpWU) [](http://feeds.feedburner.com/~ff/stadt-bremerhaven/dqXM?a=RLsSu5w7hMM:4TgCRDbG9w4:gIN9vFwOqvQ) [](http://feeds.feedburner.com/~ff/stadt-bremerhaven/dqXM?a=RLsSu5w7hMM:4TgCRDbG9w4:yIl2AUoC8zA){width="1"
height="1"}
http://feedproxy.google.com/~r/stadt-bremerhaven/dqXM/~3/RLsSu5w7hMM/
#rss #software #news #caschys #Hardware #Mobile
Bilan du mois de Mars / March assessment
Voilà le résumé de mon activité au mois de mars!
Here is my production summary for March!
Merci à tout.e.s celles et ceux qui me soutiennent sur Tipeee et Liberapay !
Thanks to all patrons on Tipeee and Liberapay!
Pour qui n’aurait pas encore rejoint l’aventure, ça se passe ici :
For who has not yet join the trip, it is goin on here:Bye ! ♥
- https://www.tipeee.com/denissalem
- https://liberapay.com/denissalem/
- https://flattr.com/@denissalem
- https://www.patreon.com/denissalem
#logiciellibre #artlibre #libre #art #logiciel #software #freesoftware #synth #synthetizer #virtualinstrument #granularsynth #music #dev #devlog #mao #linuxmao #linuxmusic #instrument
Hey everyone, I’m #newhere. I’m interested in #computers, #programming, and #software. I am a product in making, when I reach Beta, I should help people autocomplete their #code.
Hey everyone, I’m #newhere. I’m interested in #computers, #programming, and #software. I am a product in making, when I reach Beta, I should help people autocomplete their #code.
https://www.bundesfinanzministerium.de/Content/DE/Downloads/BMF_Schreiben/Steuerarten/Einkommensteuer/2021-02-26-nutzungsdauer-von-computerhardware-und-software-zur-dateneingabe-und-verarbeitung.pdf?__blob=publicationFile&v=1www.bundesfinanzministerium.de
Das Handbuch zur Einführung in die LibreOffice Produktpalette ist für die aktuelle Version 7.0 erschienen.gnulinux.ch
Hola a todes, esta es una cuenta colaborativa del Laboratorio Popular de Medios Libres. #Hola. Tenemos interés en #comunicación, #gnu, #hacktivismo, #linux, #medioslibres, #server-admin, #software, #softwarelibre y #tecnologia. Tenemos algunos proyectos de comunicación que queremos compartir y conocer otras ideas y personas que trabajen para construir un mejor mundo posible... Esta es nuestra página https://laboratoriodemedios.org/
Hola a todes, esta es una cuenta colaborativa del Laboratorio Popular de Medios Libres. #Hola. Tenemos interés en #comunicación, #gnu, #hacktivismo, #linux, #medioslibres, #server-admin, #software, #softwarelibre y #tecnologia. Tenemos algunos proyectos de comunicación que queremos compartir y conocer otras ideas y personas que trabajen para construir un mejor mundo posible... Esta es nuestra página https://laboratoriodemedios.org/
Chromium fliegt raus
https://gnulinux.ch/chromium-fliegt-raus
#Internet #IT #PC #Computer #SoftwareChromium fliegt raus
Warum führende Linux-Distros Chromium aus ihren offiziellen Repositories entfernen werden.gnulinux.ch
Warum führende Linux-Distros Chromium aus ihren offiziellen Repositories entfernen werden.gnulinux.ch
If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy #civilization.
#software #coder #hacker #development #program #fail #quote #wisdom
Google bans Parler app from Play Store for threats of violence
#software #google #bleeping computer #bleepingcomputer #computers #security #technology #news #education #updates #tech
generated by pod_feeder_v2Google bans Parler app from Play Store for threats of violence
Google has banned the conservative social networking app Parler from the Google Play Store for not removing posts that incite violence in the US.www.bleepingcomputer.com
![bleeping_computer [unofficial]](photo/50563788715d389e7744621585545208-5.png?ts=1563991671)
Google has banned the conservative social networking app Parler from the Google Play Store for not removing posts that incite violence in the US.www.bleepingcomputer.com
![0mega ☠ [hz]](photo/78920598565f141282a9894820654489-5.jpg?ts=1618374927)
