Gli ultimi otto messaggi ricevuti dalla Federazione
-
@redhotcyber oibò, non mi sorprende per nulla, visto che l'azienda proviene dal #RegnoDiMezzo dove danno un diverso valore alla riservatezza delle persone.
Ottimo motivo per #Evitare #TikTok
-
TikTok rifiuta la crittografia end-to-end per i messaggi privati
đź“Ś Link all'articolo : https://www.redhotcyber.com/post/tiktok-rifiuta-la-crittografia-end-to-end-per-i-messaggi-privati/
#redhotcyber #news #sicurezzainformatica #crittografia #tiktok #messaggiprivati #moderazione #forzedellordine
-
Chiedi a ChatGPT e ti rispondi un hacker. 900.000 persone non lo sanno e sono a rischio
đź“Ś Link all'articolo : https://www.redhotcyber.com/post/chiedi-a-chatgpt-e-ti-rispondi-un-hacker-900-000-persone-non-lo-sanno-e-sono-a-rischio/
#redhotcyber #news #cybersecurity #hacking #malware #browser #chromium #intelligenzaartificiale
-
"Which US & Israeli military companies are profiting from the Iran war?"
"Defence stocks reach all-time highs, driven by need to produce billions of dollars of weapons systems."
"The biggest defence companies in the US have agreed to “quadruple production” in a meeting attended by "RTX (fmr Raytheon), Lockheed Martin, Boeing, Northrop Grumman, BAE Systems, L3Harris Missile Solutions & Honeywell Aerospace."
-
So, listen, Bibi, stop bombing Iran's oil...
"When this regime goes down... we are going to make a tonne of money."
~Sen. Lindsey Graham
On his trips to Israel, Graham coached Netanyahu "on how to lobby President Trump for action".
"Venezuela and Iran have 31 percent of the world’s oil reserves. We’re going to have a partnership with 31 percent of the known reserves", said Graham.Â
-
@jonny@neuromatch.social honestly good for you for investing the time to critique this knowing it's AI (adjacent or wholesale) involvement.
-
@julian @PortaFed
giving a further read: I can't really imagine a case where someone would a) regularly be creating signed backups and also b) know in advance where you wanted to migrate to to set the destination_did. Like if this is for the case where the instance has shut down, you might have some signed backup, but you probably haven't planned in advance where you would want to migrate, and if the instance is down you wouldn't be able to create the migration object after the fact.the validation strategy for the export is sort of mystifying to me. if the whole object is signed, then why would you need a merkle tree for objects and also an object count? if the contents of the object have changed post signing, then the signature validation will just fail and those are irrelevant.
true to form for LLM generated documents, several critical things are left undefined, like what last_accepted_sequence is or how that works.
probably the most important problem is that it's not really clear how all other instances are supposed to handle this, which is the entire hard part of a migration spec. Like, if the purpose here is to preserve identity, then you would need to have all the other instances come to see the new identity as being equivalent to the old identity, and there's no discussion of how that process works for third-party instances at all. like e.g. in FEP-1580 i had to spend a long time gaming out scenarios for how third party instances would handle a move event.
so without that it's not really an account portabiltiy spec, it's an account export/import spec, which is fine, just not really needed since signing objects and collections (which this spec should use anyway) is already described by other specs.
-
@silverpillThank you , these are important corrections and I appreciate you taking the time.
You're right on both points. I'll update the spec to reflect that FEP-ef61 authority is not actor-rooted in the way I described, and that migration is possible via outbox export-import. I was overstating the gap.
The distinction I was trying to draw is narrower:
