gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] Reverse resolution of VPN/GNS


From: Martin Schanzenbach
Subject: Re: [GNUnet-developers] Reverse resolution of VPN/GNS
Date: Fri, 04 Nov 2016 23:20:45 +0100

I see now that the public part does not fit into social/psyc. But I do
not fully agree with your social theory. Even if I did the reverse
resolution of PKEYs is just logical. If I can use GNS to resolve
alice.bob.gnu to X then surely GNS should be able to map X to
alice.bob.gnu. Imagine receiving a message from X.zkey and the
application cannot map this to a previous conversation from alice. 

Regarding the social argument:
I think the common case for services is that I want them to be used by
_anyone_. No exceptions. I know spam is a pain, but unsolicited
messages from a person not (yet) in my social graph are not always
spam. And maybe they do not want to join my social graph at all (how is
a discussion between opposing parties supposed to be initiated? They
need to become acquainted? By that logic you must "friend" anyone
anyway, eventually). I do still want to know _who_ that is, though.
Maybe I have an (indirect) relationship. And for that I need to give
his identity a readable name. To do that I need a reverse resolution of
the identity information (PKEY). I cannot depend on my direct
relationships for that and I do not want to.

Assuming the other option (social only, direct relationships or
nothing) is the default it will inevitably create social bubbles that
are even harder to break out from than it is today (case in point: news
websites people read). 
I have no hard evidence here, but I fear such a system will kill
critical discourse as you just surround yourself with similar thinking
peers, limit access to your services and are locked out from others.
Sounds like a great way to implement digital "safe spaces".

BR
Martin


On Fri, 2016-11-04 at 19:35 +0100, carlo von lynX wrote:
> Hello Martin, long time no see.
> Sorry if this sounded like a rant, I'm just surprised that
> after six years gnunet and secushare still don't know each
> other as well as they should...
> 
> On Fri, Nov 04, 2016 at 06:46:36PM +0100, Martin Schanzenbach wrote:
> > 
> > Yes, this is what reverse resolution is for. The only thing you can
> > know about the "caller" is his peerid/identity, at best. 
> 
> Yes, I've fumbled around with gnunet-cadet and was about to
> implement a solution by working directly with the CADET
> API, but I see huge potential in adapting tons of existing
> software if it just works out via DNS emulation.
> 
> > 
> > Now, the question is how you find a path from _your_ identities to
> > that
> > peer. The other way around not necessarily useful.
> 
> You mean a resolution path. Well, that is the ivory tower
> in the room: we don't *need* to resolve any damn random
> public key. We just need to recognize those we are in a
> social relationship with, so we already have the information
> in our local graph. Strangers remain anonymous until proven
> otherwise (in the case of a person contacting a company
> for example) and if I set up a public FTP daemon for my
> friends it is NOT supposed to work for random strangers.
> 
> If somebody needs to get friends with me, then the content
> of the transmission will have the necessary cryptographic
> auth data - so we first complete the rendez-vous process,
> then that person is given a .gnu and thus VPN starts working.
> Therefore, even for an early prototype, we don't need to
> resolve strangers or 2nd degree friends.
> 
> Later, when the secushare social graph is fully functional,
> we will *know* all the public keys of our 2nd degree (and
> possibly beyond, depending on each person's privacy settings)
> friends so there is no need to look any of them up via GNS.
> 
> > 
> > > 
> > > 1. Such a reverse resolution method *would* be a local operation
> > >    if gnunet-social and gnunet-psycstore were actually functional
> > >    and all the appropriate subscriptions in place.
> > >    In other words: You are re-inventing secushare.
> > > 
> > So you fixed the issue in the bug in theory? Can you elaborate how?
> > I
> > don't understand...
> 
> Are you telling me the local ego has no way to enumerate
> their own GNS zone to find that person's pubkey?
> 
> > 
> > > 
> > > 2. In that blog post you are discussing a "public" social graph
> > >    like PGP's. That is a not exactly futuristic idea and very
> > >    much inferior privacy-wise to the private social graph planned
> > >    by secushare.
> > Well, reverse resolution by design is public. This is particularly
> > useful for trust establishment scenarios. I.e. I have a webservice
> > and
> > identity X just logged-in -> reverse resolution to determine if I
> > have
> > a trust relationship to this person. I don't really care about
> > _his_
> > trust relationship to me here.
> 
> Reverse resolution by design is public, that's why we don't do this.
> If a web service is meant to be anonymous, it stays so. If the person
> is supposed to authenticate, then they can initiate a social contact
> exchange with a proper suitable protocol (we use PSYC for that). To
> prevent DoS, SPAMming, phishing and all that *we don't accept* stuff
> from strangers, then try to find out if they were meant to be
> friends.
> Either we already know, or they do a proper introduction. It's like
> ringing the door bell before coming into my kitchen.
> 
> > 
> > > 
> > > 3. To make GNS work with existing applications I simply asked to
> > >    teach gnunet-exit to return the same names that were used by
> > >    gnunet-vpn to build those tunnels in the first place. The rest
> > >    of the challenge is then dealt by secushare's pubsub
> > > structures.
> > > 
> > This does not make sense or you need to explain it to me better.
> > What
> > use would it be to tell exit how the tunnel was built? Such
> > (trust)paths (btw I do not agree here that the peers along the
> > tunnel
> > are in any way related to a social graph or GNS...) are usually not
> > symmetric or bi-directional. There is no guarantee that this trust
> > path
> > is actually useful to the callee.
> 
> The callee either intentionally offers services to strangers - then
> it
> doesn't need any resolution - or it offers services to those people
> it already knows. Everything else is dealt with a proper rendez.vous 
> procedure. And yes, it has everything to do with social networking,
> because doing antisocial gnunet is pointless. We already have
> blockchain for that.
> 
> > 
> > > 
> > > So all we need to move forward is:
> > > 
> > > 1. The closing of that feature request by implementing just the
> > >    resolution of *known* addresses, in a simple and fast way.
> > Define "known". A direct trust path? This is also included in the
> > proposal btw.
> 
> Yes, just the first degree.
> 
> > 
> > > 
> > > 2. Fixing the bugs in gnunet-social or anything below so that we
> > >    can avoid having to use older software just because it works.
> > > 
> > I have only read the thesis on social to be honest. But by that
> > knowledge it do not see how it can solve the reverse resolution
> > issue.
> 
> In secushare I have pubsubs of all my social contacts. Each pubsub
> has a psycstore database. Depending on how much they like me and
> into which social groups they add me, I receive pubkeys of people
> they are connected to that I should be able to reach out to. See
> last month's secushare video for details on this (in German). So
> I already have my gnunet/secushare social graph in the psycstore
> database and just need to SELECT over it. No need to consult any
> DHT, let alone have it be public.
> 
> More on this in...
>       http://secushare.cheettyiapsyciew.onion/rendezvous
>       http://secushare.cheettyiapsyciew.onion/identity
>       http://secushare.cheettyiapsyciew.onion/security
>       http://about.psyc.eu/social_graph
> 

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]