unknown
1970-01-01 00:00:00 UTC
When you start saying -- "TLS is out" -- that's great but then you've
excluded billions of users and devices. Also "self determined" storage,
imho, means that *I* get to choose my security preferences.
--001a11c23fbc01632b04eba5aa07
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable <div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 21 November 2013 02:08, Simon Hirscher <span dir="ltr"><<a href="mailto:***@simonhirscher.de" target="_blank">***@simonhirscher.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wed, Nov 20, 2013 at 3:21 AM, Melvin Carvalho<br>
<<a href="mailto:***@gmail.com">***@gmail.com</a>> wrote:<br>
><br>
> TLS *as an example* lets you exchange keys, and encrypt messages. Rolled<br>
> out to billions of users and devices.<br>
<br>
</div>What about MITM attacks? What about the fundamentally broken<br>
certificate architecture? The only way I see that both issues<br>
obviously can be solved is to solve the DNS issue right from the start<br>
and use public keys as fundamental identifiers. Now, we're back to<br>
Zooko's Triangle, an issue that GNS probably solves in the most<br>
elegant way.<br>
<br>
On Wed, Nov 20, 2013 at 3:21 AM, Melvin Carvalho<br> <div class="im"><<a href="mailto:***@gmail.com">***@gmail.com</a>> wrote:<br>
><br>
> On 20 November 2013 03:05, Simon Hirscher <<a href="mailto:***@simonhirscher.de">***@simonhirscher.de</a>> wrote:<br>
>><br>
>> On Wed, Nov 20, 2013 at 2:31 AM, Melvin Carvalho<br>
>> <<a href="mailto:***@gmail.com">***@gmail.com</a>> wrote:<br>
>> ><br> </div><div class="im">>> > Why do you say no other project is working on this? How can you even<br>
>> > know<br>
>> > every project out there?<br>
>><br>
>> Melvin, I obviously can't know every project out there. Let's do a<br>
>> search & replace then:<br>
>> >> Because no one *we (or I) know of* is doing this *successfully*.<br>
><br> </div><div class="im">> These are modular components, which elements do you think are not being done<br>
> successfully?<br>
<br>
</div>I said those 4 problems are not being addressed successfully *at<br>
once*. And that's really the key to understanding why we can't just<br>
solve these issues by mostly building upon existing technologies –<br>
like TLS and web technologies. Because every project [again: I know<br>
of] is just paying attention to one or, at the maximum, two of those<br>
points and on the other hand makes it damn hard or simply impossible<br>
to solve those other two or three issues at the same time. Yes, some<br>
web applications might enable self-determined storage at first glance.<br>
But, meanwhile, by running server-delivered code (which might not even<br>
come from the server you trust – due to compromised TLS certificates)<br>
in your browser you give up on end2end encryption. So, no, it actually<br>
doesn't allow self-determined storage because there might be someone<br>
else listening.<br>
<br>
In fact, we could boil down the four requirements to just one:<br>
Self-determined storage. This already implies end2end encryption,<br>
perfect forward secrecy as well as social graph obfuscation because<br>
*I* determine who gets to see my data and my messages and my buddy<br>
lists. Now and in the future.<br>
<br>
Hence, to wrap it all up and answer your question in the shortest way<br>
possible: So far, there is absolutely no project that managed to<br>
realize genuinely self-determined storage.<br>
<div class="im"><br>
> Why cant this be done in a modular way with different teams working on<br>
> different pieces and then put together. I agree maybe not all pieces are<br>
> perfect, but we cant some of us work on fixing the bugs working together?<br>
<br>
</div>See above. Also, I don't even know where to start when talking about<br>
fixing TLS and doing web apps in a secure way. Then again, that might<br>
be due to the fact that their design is fundamentally broken with<br>
respect to our wishlist.<br>
<br>
Maybe I'm all wrong – in which case I'd ask you to tell me which<br>
building blocks you would use in our quest to fulfill those 4<br>
requirements. At the same time, I'd ask you to explain to me why do<br>
you think it's even possible to fix all their "bugs" (I prefer the<br>
term "architectural flaws") all at once. In short: Give me a plan I<br>
can believe in.<br>
<br>
So far, however, all those solutions you proposed in your previous<br>
email – regarding "E2E + Forward secrecy", "Social Graph Transmission"<br>
and "Self Determined Data Storage" – aren't solutions at all. I think<br>
Carlo really has a point here.<br>
</blockquote></div><br></div><div class="gmail_extra">I agree with most almost everything you say here.<br><br>I could spend time going into much more details of the specifics of each modular component, but I suspect it's not going to be that productive at this point. I think maybe a demo would work better, which is something I can work on. It wont be read for this years conf, but maybe next.<br>
<br></div><div class="gmail_extra">
excluded billions of users and devices. Also "self determined" storage,
imho, means that *I* get to choose my security preferences.
--001a11c23fbc01632b04eba5aa07
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable <div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 21 November 2013 02:08, Simon Hirscher <span dir="ltr"><<a href="mailto:***@simonhirscher.de" target="_blank">***@simonhirscher.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wed, Nov 20, 2013 at 3:21 AM, Melvin Carvalho<br>
<<a href="mailto:***@gmail.com">***@gmail.com</a>> wrote:<br>
><br>
> TLS *as an example* lets you exchange keys, and encrypt messages. Rolled<br>
> out to billions of users and devices.<br>
<br>
</div>What about MITM attacks? What about the fundamentally broken<br>
certificate architecture? The only way I see that both issues<br>
obviously can be solved is to solve the DNS issue right from the start<br>
and use public keys as fundamental identifiers. Now, we're back to<br>
Zooko's Triangle, an issue that GNS probably solves in the most<br>
elegant way.<br>
<br>
On Wed, Nov 20, 2013 at 3:21 AM, Melvin Carvalho<br> <div class="im"><<a href="mailto:***@gmail.com">***@gmail.com</a>> wrote:<br>
><br>
> On 20 November 2013 03:05, Simon Hirscher <<a href="mailto:***@simonhirscher.de">***@simonhirscher.de</a>> wrote:<br>
>><br>
>> On Wed, Nov 20, 2013 at 2:31 AM, Melvin Carvalho<br>
>> <<a href="mailto:***@gmail.com">***@gmail.com</a>> wrote:<br>
>> ><br> </div><div class="im">>> > Why do you say no other project is working on this? How can you even<br>
>> > know<br>
>> > every project out there?<br>
>><br>
>> Melvin, I obviously can't know every project out there. Let's do a<br>
>> search & replace then:<br>
>> >> Because no one *we (or I) know of* is doing this *successfully*.<br>
><br> </div><div class="im">> These are modular components, which elements do you think are not being done<br>
> successfully?<br>
<br>
</div>I said those 4 problems are not being addressed successfully *at<br>
once*. And that's really the key to understanding why we can't just<br>
solve these issues by mostly building upon existing technologies –<br>
like TLS and web technologies. Because every project [again: I know<br>
of] is just paying attention to one or, at the maximum, two of those<br>
points and on the other hand makes it damn hard or simply impossible<br>
to solve those other two or three issues at the same time. Yes, some<br>
web applications might enable self-determined storage at first glance.<br>
But, meanwhile, by running server-delivered code (which might not even<br>
come from the server you trust – due to compromised TLS certificates)<br>
in your browser you give up on end2end encryption. So, no, it actually<br>
doesn't allow self-determined storage because there might be someone<br>
else listening.<br>
<br>
In fact, we could boil down the four requirements to just one:<br>
Self-determined storage. This already implies end2end encryption,<br>
perfect forward secrecy as well as social graph obfuscation because<br>
*I* determine who gets to see my data and my messages and my buddy<br>
lists. Now and in the future.<br>
<br>
Hence, to wrap it all up and answer your question in the shortest way<br>
possible: So far, there is absolutely no project that managed to<br>
realize genuinely self-determined storage.<br>
<div class="im"><br>
> Why cant this be done in a modular way with different teams working on<br>
> different pieces and then put together. I agree maybe not all pieces are<br>
> perfect, but we cant some of us work on fixing the bugs working together?<br>
<br>
</div>See above. Also, I don't even know where to start when talking about<br>
fixing TLS and doing web apps in a secure way. Then again, that might<br>
be due to the fact that their design is fundamentally broken with<br>
respect to our wishlist.<br>
<br>
Maybe I'm all wrong – in which case I'd ask you to tell me which<br>
building blocks you would use in our quest to fulfill those 4<br>
requirements. At the same time, I'd ask you to explain to me why do<br>
you think it's even possible to fix all their "bugs" (I prefer the<br>
term "architectural flaws") all at once. In short: Give me a plan I<br>
can believe in.<br>
<br>
So far, however, all those solutions you proposed in your previous<br>
email – regarding "E2E + Forward secrecy", "Social Graph Transmission"<br>
and "Self Determined Data Storage" – aren't solutions at all. I think<br>
Carlo really has a point here.<br>
</blockquote></div><br></div><div class="gmail_extra">I agree with most almost everything you say here.<br><br>I could spend time going into much more details of the specifics of each modular component, but I suspect it's not going to be that productive at this point. I think maybe a demo would work better, which is something I can work on. It wont be read for this years conf, but maybe next.<br>
<br></div><div class="gmail_extra">