On Thu, Nov 21, 2013 at 2:08 AM, Simon Hirscher <[email protected]>wrote:
> > On Wed, Nov 20, 2013 at 3:21 AM, Melvin Carvalho > <[email protected]> wrote: > > > > On 20 November 2013 03:05, Simon Hirscher <[email protected]> > wrote: > >> > >> On Wed, Nov 20, 2013 at 2:31 AM, Melvin Carvalho > >> <[email protected]> wrote: > >> > > >> > Why do you say no other project is working on this? How can you even > >> > know > >> > every project out there? > >> > >> Melvin, I obviously can't know every project out there. Let's do a > >> search & replace then: > >> >> Because no one *we (or I) know of* is doing this *successfully*. > > > > These are modular components, which elements do you think are not being > done > > successfully? > > I said those 4 problems are not being addressed successfully *at > once*. And that's really the key to understanding why we can't just > solve these issues by mostly building upon existing technologies – > like TLS and web technologies. I don't think anyone is saying that GNUnet is going about it the wrong way. I think it's great that they are addressing things from the ground up. I personally, also think that addressing from the top down provides value to people in more ways than just the immediate technical results. To say that you can't, for instance, provide self-determined data storage because there is a possibility it could be compromised, is like saying you can't run an HTTP server because it could be hacked. There is value in making things better, and giving users more autonomy, and working toward better circumstances. Don't count your GNU/chickens before they hatch ... :) > Because every project [again: I know > of] is just paying attention to one or, at the maximum, two of those > points and on the other hand makes it damn hard or simply impossible > to solve those other two or three issues at the same time. I'm not sure I understand what you mean here. By trying to solve one or two of the 4, it makes solving the other two harder? > > Yes, some > web applications might enable self-determined storage at first glance. > But, meanwhile, by running server-delivered code (which might not even > come from the server you trust – due to compromised TLS certificates) > in your browser you give up on end2end encryption. So, no, it actually > doesn't allow self-determined storage because there might be someone > else listening. > > In fact, we could boil down the four requirements to just one: > Self-determined storage. This already implies end2end encryption, > perfect forward secrecy as well as social graph obfuscation because > *I* determine who gets to see my data and my messages and my buddy > lists. Now and in the future. > > Hence, to wrap it all up and answer your question in the shortest way > possible: So far, there is absolutely no project that managed to > realize genuinely self-determined storage. > There are several projects working toward this goal. remoteStorage.js is one of them, as with the others people have mentioned. I don't think it makes sense, from a social perspective, to say we can't provide real self-determined data storage because TLS has issues. That's mixing two different issues. You *can* provide self determined data storage *and at the same time* you can further illustrate the remaining vulnerabilities. You *can* provide a better method for point-to-point encryption *and at the same time* point out the vulnerabilities in the existing DNS system. Yes, these things wont be perfect. But they *will* be better, and they *will* be progress, and there will be less remaining problems to address, which will be highlighted more so, because solving some problems can improve clarity of remaining problems to a larger audience. "Hey we made this awesome library that will save your user data to your own private storage target, you may need to install this browser plugin, though, to verify that the application you are using hasn't been tampered with, and that you are connecting to the correct server(s)" > > > Why cant this be done in a modular way with different teams working on > > different pieces and then put together. I agree maybe not all pieces are > > perfect, but we cant some of us work on fixing the bugs working together? > > See above. Also, I don't even know where to start when talking about > fixing TLS and doing web apps in a secure way. Then again, that might > be due to the fact that their design is fundamentally broken with > respect to our wishlist. > > Maybe I'm all wrong – in which case I'd ask you to tell me which > building blocks you would use in our quest to fulfill those 4 > requirements. At the same time, I'd ask you to explain to me why do > you think it's even possible to fix all their "bugs" (I prefer the > term "architectural flaws") all at once. In short: Give me a plan I > can believe in. > I think GNUnet is a very good answer to all 4 of those issues, all wrapped up in one project. That's great, I want GNUnet to succeed very much so, but still I don't think we should be exclusionary, or count or GNU/chickens... Is it fair to say that it's possible only parts of the project succeed? Are there any pieces that can be stand-alone without the other components and still provide some level of value? > So far, however, all those solutions you proposed in your previous > email – regarding "E2E + Forward secrecy", "Social Graph Transmission" > and "Self Determined Data Storage" – aren't solutions at all. I think > Carlo really has a point here. > -- > SocialSwarm mailing lists: https://socialswarm.net/en/participate/ > Websites: https://socialswarm.net/ https://wiki.socialswarm.net/ > Liquid Feedback: https://socialswarm.tracciabi.li/ > Digitalcourage, Bielefeld, Germany [email protected] >
