2014-07-26 17:46 GMT+02:00 boyska <piuttosto@???>:
> 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.
>
https://addons.mozilla.org/en-US/firefox/addon/switchy/ ?
https://addons.mozilla.org/en-US/firefox/addon/priv8/
(entrambe di baku!)
> * qualcuno decide di mettere _tutto dentro_ al browser. What could go
> wrong?
I browser stanno diventando come sistemi operativi, non puoi impedire
questa cosa, anche se sono nati inadeguati per quel ruolo. la crittografia
ci viene infilata dentro, se il design di questi sistemi non è ottimale,
sarà migliorato, ma son processi diversi.
ma poi, io stavo rispondendo al fatto che il problema fosse l'account
google richiesto, e stavo dicendo "non è un problema di design, non è
quindi vincolante"
> ok va bene un sacco di roba è open, ma che vuol dire? :)
che questo ha il potenziale per diventare un riferimento per lo scambio di
file sicuro, e che non avrai problemi ad integrarti con la tua
implementazione (che deve avere solo poche differenze dal branch originale,
rendendolo meno oneroso per i programmatori), e che l'account google
richiesto dalla prima release non può essere il motivo per cui definisci
"cagata" l'intero progetto.
ma scusa, il container docker in una tecnologia ultra userfriendly e
> crossplatform?
> (a parte il fatto che lxc non è una misura di sicurezza)
stavo parlando di possibli altre implementazioni che il protocollo può
avere, per rinforzare l'idea che chrome (il problema che sollevavi) non è
un problema di design.
la tecnologia userfrendly ti porta a fare utenti ed a renderlo (forse) uno
standard de facto comodo e suggeribile a chiunque. se fai parte di quello
0.1% di utenti con terminale, magari avrai anche l'applicazione che ti
consente di gestirlo in modo scripato, in modo più limitato, in ambienti
usa e getta.
> 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.
No, non basta. ma è un requisito necessario, si valuta volta per volta, e
minilock non ha nel design alcunché di vincolante. perché non fa uso ne di
server, ne di reti. è un formato di cifratura, una policy di creazione
chiave robuste e un protocollo a chiave asimmetrica in cui ha cercato di
neutralizzare i problemi del key management.
Può essere facilmente insegnato e installato, è semplicemente un bene che
sia nato, e iniziare a pensare a delle integrazioni può essere utile,
perché consente di unificare sotto un'unica spiegazione il problema dello
scambio file sicuro.
(nota a margine: keybase.io )
--
This account is intended for mailing list only. Personal email via:
vecna at globaleaks dot org