Shamar @Shamar@qoto.org

@roboneko

Uhm... no.

Constants are _defined_.

Just as an example, (since @p2hang mentioned this book), attached you can read an extract from page 36 of #PrincipiaMathematica¹ where the number one is _defined_.

Mathematicians define mathematical constants all the time as they need them in their theorems.

It has nothing to do with their "size" (what is a "huge number" btw? huge compared to what?) and all to do with notational convenience.

As notations they are communication tools (just like the rest of Mathematics, to be fair²) and their usefulness depends on their arbitrary meaning, the information they convey.

So if you want to distribute a software you do not have the right to distribute, all you have to do is to express it as a (somewhat interesting) number and you are fine.

Here a constructive proof of this (quite obvious fact): http://fatphil.org/maths/illegal.html

Then sure, some constants can be expressed in several ways and you need to prove that each of them are equivalent.
That's the case of Pi's decimal expression, for example.

But confusing the process of defining constants and the process of expressing their value in a particular form shows that you do NOT understands mathematics at all.
___

1) https://en.m.wikipedia.org/wiki/Principia_Mathematica

2) http://www.tesio.it/2018/10/11/math-science-and-technology.html

@p2hang

😘

Dude, you are confusing the definition of a constant with its numerical expression (likely in base 10).

I argued, since the beginning, that any software can be encoded as a mathematical constant.

That is: for any software, you can define a mathematical constant whose binary representation correspond to its executable (or its UTF-8 source code, or...).

Just like you can define 1 to be... 1¹.

As for spelling, well... thanks God I'm not a native English speaker!

English is just one of the languages I can speak and likely not my favourite one!

Sure, I'm sorry for your pain, but trust me: USA caused (and cause) much MUCH more pain around the world!
___
¹ yet, to be honest, I would be eager to learn about the proof that help uncover "the value of one"!

@p2hang

Tell me you pretend to know something while you do not understand it at all¹.

Unfortunately you got an education.
And it didn't worked at all.

Maybe... get a culture²? 😉

____

1) Mathematical constants are nothing more than useful cultural conventions, see for example https://tauday.com/tau-manifesto

2) http://fatphil.org/maths/illegal.html

@agntsmith

Any software (or content) can be encoded as a mathematical constant.

@fsf

@ekaitz_zarraga

Very nice article Ekaitz!

I wish you wrote it years ago when I had to understand these stuff for Jehanne!

Some time ago I was wondering about a malloc-less OS and the only real use case you cannot turn into static allocation of BSS or into messages over (bidirectional and random-access pipes) are the ones related to graphics.

The ultimate reason is that screen size might vary.

So I was wondering: what if ELF executable would have provided several BSS sizes and the loader was able to pick the right one?

ELF is pretty modular and flexible: how would you do that?

The best I was able to conceive is an additional LOAD segment with an additional entry point to run whose return value would compute the BSS space required.

So that it could check the execution environment and decide how much memory it would need.

The cons was that you couldn't fork or exec while running this function.

Can you see a better approach?

@loweel

🤣

Sai, a tuo modo sei divertente.

Mi accusi di fare una supercazzola e farcisci i tuoi post di acronimi tecnici.

Mi accusi di eccessiva astrazione ma per provare a confutare il mio approccio tiri in ballo insiemi ordinati e persino Peano.

Opponi alla analisi dei rischi il threat modeling nonostante dal mio primo post io abbia chiarito che l'analisi e la minimizzazione dei rischi include ANCHE la modellazione delle minacce.

Scrivi threat model per vendere ai tuoi clienti ciò che sai fare, pur sapendo che non è sufficiente.

Insomma, non stai facendo una gran figura.

Chi ci legge potrà valutare da sé chi di noi due sa di cosa parla e chi ripete l'unica lezione che ha imparato.

Se avessi più tempo (e tu ti fossi mostrato in buona fede) potremmo tornare al contesto iniziale e confrontare i diversi sistemi di messaggistica per un uso personale con i due metodi confrontando i risultati.

Intuitivamente scommetterei che ne emergerebbe una sostanziale equivalenza con il tuo metodo (mera analisi delle minacce) ed un discreto vantaggio dei sistemi federati con il mio metodo (per le ragioni già descritte nel resto del thread e per altre).

In altri termini, il tuo metodo, da solo, è inutile.

Se l'avevi introdotto in questo thread per sembrare un esperto in materia, ti è andata malissimo.

Peccato però.
Sembrava poter diventare una chiacchierata interessante.

@fatualux @miriamgreco@mastodon.uno

@loweel

Io non ho descritto alcuna ricetta magica. Ho descritto gli strumenti di analisi che, SE adottati sistematicamente, permettono di minimizzare i rischi cibernetici per individui e organizzazioni.

Non ho mai parlato di "sistemi sicuri" in astratto o in assoluto, ma di come un sistema possa diventare concretamente PIÙ sicuro, iterativamente, nel tempo.

E non ho mai detto che sia sempre un processo economico.
Il sistema progettato male richiederà costi economici enormi.
Questi costi vanno però confrontati con i danni cibernetici che causerà non affrontarli.

Dunque sì, hai ragione, ci vorranno decenni a raggiungere un livello decente di sicurezza cibernetica nel nostro Paese.

Ma questa è una ottima ragione per cui cominciare il prima possibile ANZITUTTO dall'educazione e dall'informazione dei nostri concittadini.

Suggerire che NON POSSONO farci niente, quando in realtà possono fare molto ed in modo molto semplice ed economico, significa peggiorare la situazione.

Per questo, anche se posso comprendere la tua frustrazione (che per inciso, è anche la mia) non posso condividere il tuo fatalismo.

C'e molto da fare.
Ma SI PUÒ fare.

@fatualux @miriamgreco@mastodon.uno

@loweel

Esatto.

Confermi, come dicevo, che il threat modelling NON serve a rendere sicuro il sistema cibernetico.

Tu lo usi per minimizzare il rischio ed il costo delle contestazioni del tuo operato in caso di incidenti, sapendo che tali incidenti prima o poi avverranno.

E non sei solo!
E se rileggi ciò che ho scritto noterai che ho menzionato questa funzione del threat modelling sin dal principio del nostro scambio: "attenzione che la modellazione delle minacce fornisce uno specchietto sintetico utile e comprensibile ai decisori in modo che finanzino gli investimenti necessari"

La tua analisi rende il sistema più sicuro?

A leggere ciò che hai scritto, si direbbe di no: fotografi lo status quo e basta.

Cosa che, per carità, è utilissima, ma solo come punto di partenza.

Tu invece ti fermi lì.
Per questo tendi a ridurre la questione a "tanto è tutto insicuro".

Io non posso permettermi il lusso di questa riduzione e devo valutare i rischi ed ideare modi di minimizzarli.

Per questo ciò che a te sembra solo un impalcatura teorica, è parte del mio lavoro.

PS: non capisco l'acredine dei tuoi toni, non sono un tuo cliente e non ti ho insultato.
Sono felice di avere una conversazione civile nel merito, se ti interessa.
Se non ti interessa... amen.
Ma la vita è troppo breve per lasciarla consumare all'ira.

@fatualux @miriamgreco@mastodon.uno

@loweel

ROTFL! :-D

La mia non voleva essere una "lezioncina": hai introdotto un concetto di cyber security in risposta a @miriamgreco@mastodon.uno e ho voluto estenderne il contesto perché limitarsi a dire che tutto tanto rimane insicuro è il primo passo per smettere di investire in sicurezza.

Di nuovo, quello che dici è vero¹, ma è molto parziale.

Non puoi ridurre la sicurezza informatica ad un valore scalare che si colloca fra insicuro (0) e sicuro (1).

Dipende da cosa vuoi proteggere (gli asset), dai perché (gli impatti che vuoi limitare), dalle minacce che ti circondano e dalle vulnerabilità cui sei sottoposto.

Vero, #Meltdown e #Spectre non sono mitigabili. Ma puoi controllare chi accede alla macchina.

Vero, i #WebBrowser sono estremamente ostili agli utenti, eseguono automaticamente codice personalizzato sotto il controllo di terze parti, ma puoi educare gli utenti a minimizzare i rischi in vari modi (plug-in, VPN, Tor etc...) o fornire loro macchine dedicate alla navigazione in rete etc...

Non è vero che non puoi far nulla.

E non è vero che ti basta una analisi delle minacce per decidere cosa fare.

E non è vero che ti basta una analisi delle vulnerabilità.

È vero che rimane sempre un rischio residuo. È vero che nessun sistema è sicuro contro qualsiasi avversario. ²

Tuttavia si può minimizzare (NON azzerare) tutta una serie di rischi.

E per farlo bisogna sapere che è effettivamente possibile e come.

Ed un modo per ridurre tutta una serie di vulnerabilità è evitare i sistemi centralizzati e quelli non ispezionabili (ovvero proprietari).

Questo non rimuove tutti i rischi, ma ne riduce moltissimi. E costa relativamente poco.

Ad esempio, #Matrix (sebbene ancora imperfetto) è molto migliore di #Signal, #Telegram e #WhatsApp perché open source, decentralizzato ed end-to-end encrypted by default (per quanto riguarda i dati.. i metadati sono un'altra storia).

Dire "eh ma tanto ti devi fidare dell'amministratore" significa fare una affermazione corretta ma tanto parziale da risultare irrilevante: è vero, ma la federazione ti permette di avere più account, ti permette di scegliere di chi fidarti e di rimuovere tale fiducia rapidamente (per non parlare del fatto che l'amministratore non può comunque conoscere il contenuto dei tuoi messaggi).

Insomma, essere fatalisti è irrazionale.
E non aiuta a migliorare le cose.

Perché se ci troviamo nel mondo cibernetico attuale è proprio a causa della profonda ignoranza delle persone su questi temi che, in quanto ignoranti, non possono esercitare una scelta consapevole come consumatori, acquirenti e utenti.

¹ per intenderci, sono talmente d'accordo da averne scritto profusamente in passato, attirandomi ban da diverse comunità amministrate da dipendenti di Google, vedi ad esempio http://www.tesio.it/2018/07/31/the-web-is-still-a-darpa-weapon.html http://www.tesio.it/2018/07/31/the-web-is-still-a-darpa-weapon.html https://dev.to/shamar/i-have-been-banned-from-lobsters-ask-me-anything-5041 etc...

² neanche un computer spento e disconnesso è sicuro contro chi vi ha accesso fisico

@fatualux

@loweel

Tutto giusto ma attenzione che la modellazione delle minacce fornisce uno specchietto sintetico utile e comprensibile ai decisori in modo che finanzino gli investimenti necessari, ma non esaurisce assolutamente l'analisi dei rischi cibernetici.

Anche perché le minacce sono fuori del tuo controllo e molto spesso anche della tua consapevolezza.
Quindi limitarsi al threat modeling significa assumere una prospettiva fatalista: in sostanza c'è poco da fare.

E non è affatto così, anche se il tuo avversario dovesse essere la CIA.

Il rischio di un sistema cibernetico è determinato da tre fattori che possono essere analizzati indipendentemente ed in maniera integrata nonché monitorati nel tempo per minimizzare tale rischio cibernetico:
1) vulnerabilità presenti
2) minacce
3) impatti

Sulle minacce si può fare poco più che elencarle, valutarne la probabilità e prepararsi ad identificarle il prima possibile quando si presentano.
È quello che fai con un sistema d'allarme perimetrale in casa, ad esempio: funziona bene se sei circondato da amici e parenti e contro il ladro che cerca di forzare la porta di notte. Ma non funziona contro il finto esattore delle tasse, o il finto collega del marito che si presenta a casa con una scusa.

Analogamente se sai di essere un bersaglio di interesse della CIA puoi prepararti ad identificare i loro accessi, a disseminare i tuoi storage di informazioni false ed honeypot etc...
In questo modo riduci o elimini certi tipi di impatto in caso di attacco portato a termine con successo, ma non elimini la minaccia.

La minaccia però per essere attuata deve SEMPRE sfruttare delle vulnerabilità.
Minimizzare le vulnerabilità di un sistema cibernetico è sempre possibile anche se azzerarle può essere impossibile.

Talvolta però si tratta di applicare semplice buon senso, come evitare di mettere tutte le uova in un paniere: non riutilizzare le password o evitare servizi centralizzati (come #Telegram, #Signal o #WhatsApp) o personal assistants (come #Alexa, #GoogleAssistant o #Cortana) etc... sono tutte ovvie applicazioni di questo principio generale.

Poi si può minimizzare l'impatto di un attacco: ad esempio non mischiando le attività (o i contatti) personali e quelle professionali sullo stesso dispositivo si sottrae ciascun gruppo in caso di compromissione dell'altro. Cifrando il disco di un PC, lasciandolo spento quando non in uso e memorizzando una password sicura, si riduce l'impatto di un furto del PC stesso e così via.

La minimizzazione del rischio cibernetico non lo azzera, ma lo può ridurre enormemente, aumentando notevolmente il costo e la complessità di un attacco.

E molte delle pratiche da mettere in atto proteggono tanto dalla CIA quanto dal marito geloso.

@fatualux @miriamgreco@mastodon.uno

@miriamgreco@mastodon.uno

Sì, ma c'è un enorme differenza fra doverti fidare di qualcuno che non conosci, per cui sei un numero e che non deve risponderti di niente perché tanto non hai alternative, e fidarti di qualcuno che conosci e che comunque puoi cambiare in pochi minuti.

Inoltre molti server significa meno dati in ogni server nonché la possibilità tecnica e legale di avere più account.
Tutto ciò riduce l'impatto di un qualsiasi problema per te e rende impossibile una profilazione di massa riducendo il rischio collettivo quanto quello individuale.

@miriamgreco@mastodon.uno

La centralizzazione poi è un problema rilevante sia in termini di sicurezza che di privacy in quanti determina un single point of failure sia tecnico che amministrativo.

Possono essere censurati a livello statale, possono raccogliere metadati delle comunicazioni fra TUTTI gli utenti (anche quando è abilitata la cifratura end-to-end) etc.

Per non parlare del lock-in: se il tuo amministratore #Matrix perde la tua fiducia, puoi cambiare facilmente server.
Con un qualsiasi sistema centralizzato non puoi.

Consigliare sistemi di messaggistica centralizzata nel 2022, con una guerra in corso, è ridicolo.

Oggi lo fanno gli stessi che anni fa suggerivano #Telegram: nella migliore delle ipotesi, non sanno di cosa parlano.

@miriamgreco@mastodon.uno

No: il Fediverse è un sistema decentralizzato (federato) e ti permette messaggi asincroni.

Analogamente #Element (che usa il protocollo #Matrix) usa un sistema di server federati che, esattamente come il fediverse, ti permette di comunicare in modo asincrono SENZA centralizzazione.

Dunque la centralizzazione NON è necessaria per la messaggistica asincrona e chi ti ha detto il contrario, nella migliore delle ipotesi, non sapeva di cosa parlava.

Discorso diverso vale per i protocolli peer-to-peer (come quelli usato da #Jami e #Briar) che richiedono che sia mittente che destinatario siano online per distribuire un messaggio.
In questi protocolli la comunicazione può essere asincrona ma il messaggio rimane sul dispositivo del mittente fintanto che il destinatario non diventa raggiungibile. Il che può essere effettivamente noioso per app mobili.

Tuttavia non tutti i sistemi decentralizzati sono anche peer-to-peer.

@fatualux

Io uso #Element, basato su protocollo #Matrix.

È federato, open-source ed il contenuto dei messaggi è cifrato end-to-end by default. Solo alcuni metadati in chiaro rimangono visibili agli amministratori delle istanze.
Oltre a Element esistono altri client che trovi anche su F-Droid. E conosco diverse persone che gestiscono i propri sever (sempre open-source).

È meglio di Telegram, Signal e WhatsApp, ma non è di livello militare.

Se ti serve qualcosa di livello militare, FORSE puoi provare #Briar.
Ne ho letto bene... ma non l'ho ancora provato e non ne ho studiato il sorgente.

@miriamgreco@mastodon.uno