#cloud
4 reasons your cloud provider should be using end-to-end encryption
We’re all pretty dependent on cloud services nowadays, with everything from our email inboxes to game streaming services storing our data somewhere other than on our physical computers. But with that ever-increasing dependency comes inherent risk. Your cloud provider could be using unsafe practices, like not encrypting data, or they could be a smaller provider that might disappear one day. Or it could be both of those and a whole host of other issues you might not think of. To keep your cloud storage private and secure, you need to choose a provider that uses end-to-end encryption (E2EE) in their design, and preferably one that also uses a zero-knowledge model so that your data is encrypted everywhere it goes unless it’s on your personal devices where the decryption keys are stored.
Clouds are attractive targets for hacking as there is just so much data stored there from private individuals, to corporate entities, to governments etc. Once you’ve got the keys to the kingdom, and there is no E2EE, you can browse through what you want. However, where there is E2EE then you have to crack each one individually, or you have to hack the user’s end device to get to their cloud data.
I remember at one time, Microsoft was offering E2EE for government, where government would choose their own encryption key to use. But for example with Google all that data needs to be exposed to them for searching and adverts.
Others like Proton Drive you provide your own encryption password, and if you want to search for example your email, it first does a download dump of your data to do the search locally.
The common theme here is, the more secure and E2EE there is, the less convenience, fewer cloud features, no option of recovery there is for a lost encryption key. If there is an easy way to do a password reset, AI features that work across your cloud data, or data sharing with a simple link, the chances may be that your cloud data is visible to the provider.
The best case scenario is that that data is being used just to empower features for you (or serve relevant adverts) but the worst case is it is hacked by a 3rd party, it is exposed to a foreign government, or is it being sold off to data brokers or other upstream suppliers (looking at Facebook and WhatsApp here).
Even a person’s data in Apple’s Cloud was visible to Apple, which is why Apple could be compelled to hand over this data to any law enforcement agency, and why some celebrities had their nude photos stolen.
If you don’t hold the keys yourself, then you don’t have an E2EE cloud data service. If your cloud data is being stored by a foreign owned company, or outside of your country, you may want to worry even more about it. That said, based on being in a country that has a PATRIOT Act or a CLOUD Act, storing your data elsewhere may actually be a big plus for you.
See xda-developers.com/4-reasons-y…
#Blog, #cloud, #privacy, #security, #technology
GAFAM : l'intelligence artificielle polluerait huit fois plus que prévu ⬅️ URL principale utilisée pour la prévisualisation Diaspora* et avec plus de garantie de disponibilité.
Archivez vous même la page s'il n'existe pas encore d'archive et évitez ainsi les pisteurs, puis ulilisez µBlockOrigin pour supprimer d'éventuelles bannières qui subsisteraient sur la page sauvegardée.
💾 archive.org
#environnement #pollution #gafam #cloud #centrededonnées #intelligenceartificielle
#Microsoft tells #customers it lost log data for key #security products
Between September 2 and September 19, "a bug in one of Microsoft's internal monitoring agents resulted in a malfunction in some of the agents when uploading log data to our internal logging platform," Microsoft wrote in the #customer notification.
There's no evidence of cyberattacks stemming from this incident.
#cloud #fail #cybersecurity #news #service #problem #wndows #software #economy
A gallery of the amazing #clouds while out #sailing yesterday as we had a cold front approaching.
#cloud #meteorology #sailboat #boat #boating #cumulus #altocumulus
in die cloud oder selber machen?
#computer #internet #cloud #fefe
[l] Ich habe heute einen Vortrag zur Frage gehalten, ob man in die Cloud ziehen soll oder nicht. Das war eigentlich eine interne Schulungsveranstaltung, aber sie hatten auch ein paar externe Sprecher, unter anderen mich. Ich pack die Folien online, wenn ich Zeit habe.
Jedenfalls gehe ich bei solchen Vorträgen immer ähnlich vor: Ich schreibe mir meine Punkte auf, auf die ich selber komme, und dann spreche ich meine Kumpels an und frage die nach ihrer Meinung. In diesem Fall habe ich u.a. meinen Kumpel Kris gefragt, und der hat nicht nur ein Essay geantwortet sondern seine Ausführungen zu meiner Kernfrage auch direkt nochmal in sein Blog gepackt. Absolut faszinierende Einsichten, auch wenn ich an einigen Stellen zu anderen Ergebnissen komme, bzw. Schritte, die Kris logisch zwingend fand, weniger kritisch sehe.
<
p>Er argumentiert, dass Prozessoren nicht mehr schneller (im Sinne der Taktrate) werden sondern nur noch dicker (d.h. mehr Caches und vor allem mehr Cores). Das beschleunigt hie und da auch noch mal ein bisschen was, aber im Wesentlichen müsste man alle Cores ausnutzen, um so ein Monstrum zu nutzen.
<
p>Das ist auch mein Stand.
<
p>Dann findet er, man müsse als Firma das zweitteuerste Modell kaufen, weil das der Sweet Spot im Preis ist, und erzählt von einer Firma, die 50.000 Blade-Server im Einsatz hatte. Und wenn du das zweitgrößte Modell kaufst, hast du halt direkt 128 Cores oder so in der Hand. Wenn eine Anwendung nur so auf 8 Cores skaliert (mal angenommen jetzt), dann müsstest du auf dem Teil 16 VMs laufen lassen mit je einer Anwendung drin. Wenn also die Kiste umkippt, dann sind 16 Anwendungen mit gestorben, und deine ganze Firma ist vermutlich platt.
Diese Schlussfolgerungskette finde ich nicht so stringent wie er. Die Hardwarekosten sind gegenüber den Personal- und Aufräumkosten in Krisen geradezu vernachlässigbar. Ich überspitze jetzt ein bisschen, aber das ist im Wesentlichen auch eine These von Kris. Wenn das so ist, dann kauf halt dickere Hardware und nutze die nur zu 1/4 oder was auch immer. Dann hast du auch die "Skalierung", die die Cloud verspricht, direkt in house mit eingekauft, wenn ein Lastpeak reinkommt.
Kris meint, die optimale Lösung wäre dann die Cloud, denn die kann deine VMs jeweils auf anderen Rechnern mit den VMs anderer Leute unterbringen, und so die Leistung der Hardware nutzen, ohne dass bei dem Ausfall einer Kiste gleich mehr als eine VM pro Kunde kaputt ist.
Das stimmt alles, aber aus meiner Sicht muss deine Infrastruktur auch mit dem Ausfall von zwei oder 16 VMs umgehen können, insbesondere wenn du 50.000 Rechner da stehen hast. Bei kleineren Infrastukturen finde ich die Argumentation nachvollziehbarer, aber da kaufst du dann halt dickere Hardware als du brauchst. Machen wir alle ständig. Zählt mal die Cores auf euren Smartphones und erzählt mir, dass ihr die wirklich braucht.
Abgesehen davon sind das aber faszinierende Einblicke für Leute, die ein paar Verständnis-Voraussetzungen mitbringen. Viel Spaß bei der Lektüre, und nochmal vielen Dank an Kris, dass er so ausführlich geantwortet hat.
Update: Eine Bemerkung noch. Wenn du einen Rechner mit einer CPU mit 64 Cores hast, und du benutzt nur 8 davon, dann können die höher takten als wenn du alle 64 benutzt. Und wenn die rumidlen, geht auch der Stromverbrauch drastisch zurück. Es ist also nicht so, als ob man hier die ganze Zeit laufende Kosten für nicht abgerufene Leistung hat.
Usbek & Rica - Technoféodalisme : Avons-nous vraiment régressé vers le Moyen-Âge numérique ? ⬅️ URL principale utilisée pour la prévisualisation Diaspora* et avec plus de garantie de disponibilité.
Archivez vous même la page s'il n'existe pas encore d'archive et évitez ainsi les pisteurs, puis ulilisez µBlockOrigin pour supprimer d'éventuelles bannières qui subsisteraient sur la page sauvegardée.
💾 archive.org
#numérique #néoféodalisme #économie #capitalisme #féodalisme #gafam #cloud #cloudcapital #monopole #nouvelâgedesmonopoles #propriétéintellectuelle #surveillancedemasse #capitalismedesurveillance #technoféodalisme
