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

On Sat, Jul 26, 2014 at 05:28:51PM +0200, ɣęƈƞą wrote:
>boyska:
>> minilock è solo per chrome, e probabilmente lo sarà sempre. google
>> chrome ha dei seri problemi di sicurezza a priori: il suo webstore è
>> fortemente legato all'account google, soggetto che di fatto controlla le
>> estensioni installate sul browser. Questa cosa non crea dei problemi?
>
>
>hai detto tre cose, ne contesto solo una.
>
>"minilock è solo per chrome": si, minilock di nadim, in questa fase, è solo
>per chrome.
>
>"probabilmente lo sarà sempre": ma chi lo sa ? e chi se ne frega di

mi riferivo al fatto che fare estensioni di sicurezza per firefox è
ancora più ridicolo che farle per chrome. Firefox non ha nessun
meccanismo di isolamento tra estensioni.

Renderebbe ancora più goffo questo processo che ha già dell'esilarante:
* il browser è, attualmente, la parte più debole del nostro sistema
operativo. Intendo dire, a meno che non usiate windows; in quel caso è
inutile usare la crittografia
* buon senso vorrebbe incoraggiare una limitazione dell'utilizzo, una
riduzione del danno, qualcosa del genere. Lo stesso spirito con cui
anche i più favorevoli ai social network tra di noi dicono "va bene
stare su facebook, ma fallo con intelligenza e attenzione"
* qualcuno decide di mettere _tutto dentro_ al browser. What could go
wrong?

>minilock rilasciato da nadim ? è un repository su github, è una tecnologia
>aperta, il codice è JS, fare un porting per renderlo per firefox significa
>mantenere dal 5% al 10% di codice differente, fare un porting per renderlo

ok va bene un sacco di roba è open, ma che vuol dire? :) Messa così, si
potrebbe dire che c'è lo standard posix, un compilatore libero, evvai
possiamo fare tutto!

>un pacchetto node.js (e farselo girare headless in un container docker
>superlimitato, così che anche il problema del non poter fare audit
>dell'interprete JS, usi un profilo minimale che ti fa solo inviare/ricevere

ma scusa, il container docker in una tecnologia ultra userfriendly e
crossplatform?
(a parte il fatto che lxc non è una misura di sicurezza)

>disco). Quello che conta è che è una tecnologia aperta = non crea una rete
>chiusa, non creerà lo stesso problema che c'è con whatsapp/fb/skype. E ha
>le potenzialità per diventare uno standard de facto, perché una massa
>critica la si può raggiungere grazie alla semplicità d'uso.

quindi dici tipo jabber eh? :P Credo che dovremmo ragionare meglio su
cosa vuol dire "tecnologia aperta", e su come si esce dal meccanismo
delle reti chiuse. Intendo dire che non basta un protocollo pubblicato,
una rete federata o cose del genere per rendere tutto sicuro e in nostro
controllo.

>"google e chrome sono un problema": è vero, rianalizzando il threat model,
>e facendo un'associazione forse un pò più pessimistica della realtà, cioè
>che google sia in mano al DoD, allora questo strumento non va considerato
>affidabile per chi non combatte un nemico comune con gli stati uniti, che
>considerando la quantità di nemici che hanno, rimane comunque una buona
>soluzione per una buona fetta di utenti nelle development countries. fino a
>che qualcuno non ci fa l'app per firefoxOS (5%-10% di differenza di codice)

firefoxOS, così come (a quel che so) ogni sistema operativo per
smartphone attualmente esistente, fa ampio uso di blob proprietari,
usa chipset gsm di dubbissima fama, vedi ad esempio la backdoor gsm dei
samsung.
Pensare agli smartphone come piattaforma in cui valga la pena usare
crittografia forte non credo sia utile; certo si può fare riduzione del
danno, ovvero cercare di alzare il costo di attacco pur senza avere
una certezza vera. Ma per quello, sugli smartphone, c'è già textsecure:
basterebbe farlo funzionare :)

--
boyska