Re: [Hackmeeting] javascript e facilità = felicità

このメッセージを削除

このメッセージに返信
著者: ɣęƈƞą
日付:  
To: hackmeeting
新しいトピック: Re: [Hackmeeting] javascript e facilit? = felicit?
題目: Re: [Hackmeeting] javascript e facilità = felicità
qui ci sono risposte per Marco B + boyska + Brno

2014-07-25 15:08 GMT+02:00 Marco Bertorello <marco.bertorello@???>:

>
> Non per aggiungere polemica, ma si.
> Alla fine della fiera, se una cosa è abbastanza semplice da usare,
> viene usata, altrimenti viene abbandonata / snobbata, purtroppo (vedi
> GPG).
>
>

Il fatto è che GPG potrebbe anche non doversi vedere, essere invisibile (il
progetto LEAP mi pare abbia usato quello che chiamano "invisible keys" per
cifrare dati in transito tra client e server, senza che l'utente se ne
accorga) in se, lo uno scazzo è la gestione delle chiavi personali (che è
essenziale perché ci sia una crittografia end to end robusta.)

il paragone che fai è giusto: mi chiedevo in quest'anno, ma cryptokitchen,
un'idea di 10 anni fa e funzionata con una discreta quantità di persone,
quanto potrebbe ancora funzionare ?

poco, i metodi con cui viene usata la tecnologia sono cambiati, Lo scopo:
"cryptography 4 the masses" no. Fatto sta che ora non esiste un meccanismo
pensato per chi si avvicina alla tech in questi anni (e quindi è totalmente
interconnessa al cloud, a bootrasp.js ed ai marketplace) che possa dare lo
stesso livello di sicurezza che 10 anni fa si dava con enigmail.


Boyska:

> vecna, seriamente, sai spiegarmi le vere differenze tra il tuo discorso
> e quello che ho appena scritto?
>


Non so rispondere sulla quantità di differenze, ma Windows XP infatti ha
*vinto* in quegli anni. è stato lo standard, ha dato agli utenti quello che
volevano, e microsoft si è potuta radicare come un attore politico in
diverse parti del mondo grazie a questo. e quando ha avuto bisogno di
infilare delle backdoor nel codice, non ha detto di no (in alcuni casi,
manco erano dell'NSA, erano proprio del suo codice). Però ora stiamo
mescolando l'opportunità, l'usabilità, le scelte che ha fatto M$.

Nadim non è che quando è arrivo a $mila utenti di cryptocat ha detto "ora
lo vendo su iTunes a 0.99", è rimasto così, mentre si migliorava nella
sicurezza e nelle feature.



> fino a che punto può valere questo tradeoff sicurezza/usabilità?



Non vale più nel momento in cui la sicurezza degli utenti passa in secondo
piano. Ma distinguiamo per piacere il momento di lancio da quello di
mantenimento.

Se quel software fosse stato lanciato come "nuovo sistema di condivisione
file -> vai su git -> compila -> copia incolla su IRC -> l'altro scarica ->
verifica l'hash -> hey aspetta non ho la chiave per la verifica, dammi
anche quella. uh, Socialist Millionaire Protocol, dimmi in minuscolo la
città in cui ci siamo visti l'ultima volta... allora siamo nella situazione
2010. software sicuro, utilizzato solo dall'autore e dai suoi amici.

Invece questo si promuove con lo scopo di essere semplice, *e solo la
semplificiazione porta il progresso*. secondo me è un progresso ben più
importante del progresso avuto tra RSA, EC e Curve25519 (che tanto, in
tutti e tre i casi, non saprei di certo trovare debolezze interne, casomai
nel protocollo che le usano).

Poi è naturale che se minilock usa l'idea di "sono sicuro, guardatemi,
usatemi (quel che è successo con haystack)" e poi espone gli utenti, siamo
davanti ad un problema, e naturalmente mi rimangerei ogni genere di
commento. Ma per quel che ho visto personalmente con nadim e cryptocat, si
è preso addosso una valanga di attacchi e quando c'era da migliorarlo lo
migliorava, pensando alla sicurezza degli utenti.

Per anni abbiamo visto sw sicuri rimanere sicuri [*] e poco usabili,
ignorando le necessità degli utenti. E gli utenti comunque sono andati in
pasto a prodotti commerciali senza che ci fosse un'alternativa sicura. ora
se ne stanno creando, mi sembra l'unica cosa importante.

[*] ma ne siamo davvero certi ? una cosa viene auditata se ha un bacino di
utenti. se il rapidshare-anonet-I2P-mixminion rimangono in stato
prototipale, hai voglia a dire "sicuro" perchè l'autore l'ha dichiarato
tale.

Brnocrist:

> bene, allora perche' non spingiamo cose tipo queste:
> https://github.com/cryptosphere/confusion
> che sono usabili e' molto piu' sicure delle cacate tipo cryptocat e
> ancor meno minilock?



Perchè non lo conoscevo, e non l'ho ancora provato. lo guarderò.


>
> ste 'cacate' servono solo a dare l'illusione della sicurezza agli
> utenti. non e' piu' grave che avere un sw difficile da usare?



L'illusione di sicurezza è un problema forte, ma puoi dirmi dove sono
insicure ? perché se mi dici:

vulnerabilità 0 day nel browser o nell'interprete JS, o vulnerabilità nel
browser perché dell'altro codice javascript riesce ad iniettarsi o a
copiare quello che passa, allora il thread va in una direzione. se invece
mi dici qualcos'altro, sono disposto a rianalizzare il threat model minimo
con il quale suggerire queste soluzioni.

ciao,
v