On Wednesday 05 Dec 2012 06:55:13 Robert Hailey wrote: > > On 2012/12/04 (Dec), at 8:10 PM, Arne Babenhauserheide wrote: > > > Am Donnerstag, 1. November 2012, 21:30:35 schrieb Matthew Toseland: > >> - More work on making darknet easy. > > > > Yes, please! > > > > How about automatic insert of my noderef as CHK, so I can just hand a > > friend > > an in-freenet-link to connect? > > So you want a sort of... "open invitation"? Whoever finds the chk can become > a darknet peer... unless the operator has put a count-limitation on it, or > since disabled it manually (via an open invitations list?). > > An interesting idea, and not a bad one either, as it would be a necessary > first step for the welcome-package idea anyway as the "one_time_token.txt" is > effectively a limit-1 open-invitation.
Invites should be one-time yes. > > It seems like it would remove 50% of the handshake process for those who find > it "secure enough" for their purposes, but I think Matthew said something > about it not gelling well with darknet-only nodes being "undetectable" (that > they would have to respond to an unverified request or something). That's why invites should be one-time. Making them both one-time and very short might be problematic, but is impractical anyway in a lot of cases. Maybe an easily scanned visual representation? What were those 2d barcode like things called? They have very few bits but we could improve on that with e.g. using primary colors... > > Relatedly, it seems to me that the most likely onboarding use-case is simply > two persons that want to have a secure conversation between themselves (maybe > not even as a darknet peer, as it would cause a direct IP link between them). > Therefore, I would see the common use-case being the easy fabrication of an > (incredibly specialized) linux boot-usb-stick, that is used when needed to > send/receive queued messages. > > I'm not sure if it would be easier or harder than a zip-invite, as you'd only > have to maintain one OS 'installer' to maintain, but it'd be more > all-inclusive and prone to feature-creep (like encrypting the entire usb > stick). Then again, if the image was pre-built (e.g. by authoritative freenet > servers, or anonymous freeneteers with a special interest in such), then all > the client app would have to do is inject the invitation (by offset or > overwriting magic content), and probably recompute a CRC (or is that only for > cd/dvd images...). > > Either way, the open-invitations you mentioned would be needed first. Implementation: Darknet peer flagged as LISTEN ONLY, where the noderef deliberately does not include any means to contact it. The receiver should ideally not record the IP address it last connected from either. Receiver must be port forwarded. IMHO anything where one side absolutely must be port forwarded is impractical, a lot of people aren't, granted a lot of the time not being port forwarded means Freenet doesn't work at all but it's not true *all* the time... A related use case, "upload on the run" works even on opennet provided you are expendable, or expect to be elsewhere very soon afterwards, and can 1) bootstrap fast enough, 2) upload fast enough, 3) announce your uploaded content fast enough and 4) confirm that it's announced fast enough. #3 and #4 are problematic at the moment, but I have solutions for them. Obviously if the bad guys control the seednodes - or all the seednodes you can connect to - then you lose.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
