Hi!
The problem with dumping all data destined to a specific peer is that
you don't know which data (a) belongs together (ECRS) and (b) goes to
the same target, because of receiver-anonymity. Also, just tracking
queries that came from a peer in the past and then answering via mail is
likely not useful --- the peer likely doesn't care anymore (as he was
just forwarding for someone else and has since then forgotten about the
state).
Another key point is that getting information in a timely manner is
likely also crucial --- we don't need censorship-resistant anonymous
networks to distribute information to prosecute WW II criminals. On the
other hand, preventing collateral murder that still happens today
requires more timely information flow and protection for those leaking
information.
Now, in terms of countries going off-line, the current technical
solution we have in GNUnet is content migration and selective
replication. So if the country is off-line, peers of people who are
likely to travel (i.e. journalists and others with a ticket to get out)
can be configured to soak up data from other peers (migration) and users
that have particularly interesting information can tell their peers to
'push' that information more strongly into the network (by picking a
higher replication level).
The result is similar to your proposal in that the peers that receive
data essentially build up a dump (database) and then that dump can be
moved. Now, there is no 'intended target' for the dump, other than "the
outside world". But once that peer connects at the outside, the
information would leak. And, what might be an additional benefit, the
user who moved the data might never know what data he gathered and he
might himself not be able to decrypt it.
So for censorship-resistant file-sharing, I think we already have a
decent solution in place. I'm still interested in the area of
ultra-high latency communication, but more for applications like e-mail
where the target system might be offline, not so much for file-sharing.
Now, maybe you were thinking about more messaging-like applications in
your proposal; that's certainly something I'd like to eventually see;
however, that's still rather a long way away and I'm not sure that this
would be something to implement at the level of the transport API. This
would probably be easier to do closer to the appplication level,
especially as not all applications will be able to work with large delays.
Happy hacking!
Christian
On 03/08/2012 12:29 AM, [email protected] wrote:
Hello list,
hopefully my thoughts will not be considered too heretical. ;-) Honestly,
please don't hesitate to tell me if this is the wrong project to ask for
implementing this proposal. I know it is major feature request and this project
at the moment aims at sharing data over active connections and in
semi-real-time.
Taking "The message from Tahrir Square" into account it shows that the wired
means of communication are shut down and the wireless wide-area alternatieves are either
centralised and/or localiseable by technical measures. To adress this issue a trade of
the luxury of real-time for a diversity of transport-channels should be possible.
Now my thought, rather a question, is:
Why not, as an alternative meta-method of transport, make a "dump" of all data
destined to be sent to a specific peer and transport it otherwise as a file ?
These ways could be:
Sneakernet
USB dead drops
Bluetooth
(re)writeable CD/DVDs
diverse steganographic hacks
you name it...
Now I know, this is an asynchronous method of communication and would not be usable for
VPN and TOR-like applications, but it would combine advantages of the afforementioned
ways (no data retention, no means of time-correlation analysis and personal control over
the data if you meet the respective person) with the "core values" of gnunet
(end-to-end encyption, anonymous file sharing, mutual authentification and most important
of all plausible deniability).
So why not implementing an API for these asynchronous transport channels ?
From my understanding the current transport-API assumes the channels to be synchronous and in
semi-real-time, since you can open a channel and have a session to close. An asynchronous
transport-API would of course require some changes of the gnunet framework. Gnunet should keep an
account of "ongoing" communications to other peer (what has been requested / sent via an
"offline packet") and keep this information over a reboot.
The API would need a queue function to collect everything that needs to be sent
until it can be.
Transport modules would center around the event of a suitable device being
connected, upon connection files/data are read, answers and reactions get
computed and written to the medium.
In this context a timeout would of course not exist.
As for me, I have some experience at coding but "just implementing it and sending
you the patch" is definitely above my level, also for it means a major change to the
core framework.
If my thoughts are not completely lunatic, please let me know and I will post a
more detailled feature request in Mantis.
Sincerely,
a.jhonson
_______________________________________________
GNUnet-developers mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gnunet-developers
_______________________________________________
GNUnet-developers mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gnunet-developers
