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

このメッセージを削除

このメッセージに返信
著者: brno
日付:  
To: hackmeeting
題目: Re: [Hackmeeting] javascript e facilit? = felicit?
On 27/07/2014 11:50, ɣęƈƞą wrote:
> 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!)
>


non scherziamo, dai.. :P
forse un passo avanti si potrebbe fare:
http://www.soeren-hentzschel.at/mozilla/firefox/2014/07/12/was-machen-eigentlich-electrolysis-e10s-und-shumway/


>
>
>> * 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.


"i browser stanno diventando sistemi operativi", dai vecna, non sono
frasi che uno si aspetta da te :) dov'e' finito il vecna di s0ftpj?
ridatecelo!


>
> 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.
>


io non ho capito una cosa, ma vogliamo fare utenti o vogliamo garantire
qualcosa alle persone con le persone?
no perche' se vogliamo fare utenti, basta scrivere una MERDA di
programma come whatsapp e fai gli stracazzo di utenti. se vuoi invece
garantire un livello accettabile di privacy, consapevolezza e sicurezza,
allora ci spostiamo in un campo diverso e che, onestamente, preferiamo.

>
>
>> 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.
>


non l'ha neutralizzato, l'ha *semplicemente* ignorato.

mi spieghi in termini pratici la differenza tra enigmail e minilock?
(intendo proprio in numero di click!)[i colori? il drang and drop? gli
occhiali di nadim?], ignorando la parte di key management, che con
enigmail PUOI fare, con minilock non sai manco che cos'e'! per non
parlare dei bug che con minilock hai e con enigmail/gpg no.


> 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.
>


cosa insegni scusa? a fare copy&paste? "tieni popolo, con questo sei
sicuro, devi solo fare copy&paste, non te ne deve fregare di quel che in
realta' stai eseguendo" -- questo e' il futuro? il modello da seguire?

state bene allora!


>
> (nota a margine: keybase.io )
>


ma quel keybase che da la possibilita' di uploadare le private keys?
"si, ma te la critta!!111!" AHAHAHHAHAHAHAHAHAHHAHA... *CONSAPEVOLEZZA*
si dai, diamo strumenti PERICOLOSI agli utenti e poi quando ci avranno
bucati, diremo: "beh, e' colpa dell'utente che ha messo la propria key
privata sui nostri serve, mica noi che glielo permettevamo?"


ciaone!

ps: come mai nessuno ha ancora nominato end-to-end l'extension di google
su chrome? lolololol.