help me, please, to implement project of storing datas on cellular phones

_______________________________________________
Tech mailing list
Tech@...
http://freenetproject.org/cgi-bin/mailman/listinfo/tech

imap and talktalk.net

_______________________________________________
Tech mailing list
Tech@...
http://freenetproject.org/cgi-bin/mailman/listinfo/tech

Freenet on a mesh network

_______________________________________________
Tech mailing list
Tech@...
http://freenetproject.org/cgi-bin/mailman/listinfo/tech

Freenet on a Delay-tolerant network

How would Freenet work on a delay-tolerant network like Probabilistic Routing Protocol using History of
Encounters and Transitivity (PRoPHET) [1] ?

 [1] http://tools.ietf.org/html/draft-irtf-dtnrg-prophet

--
tom_a_sparks "It's a nerdy thing I like to do"
Please use ISO approved file formats excluding Office Open XML - http://www.gnu.org/philosophy/no-word-attachments.html
3 x (x)Ubuntu 10.04, Amiga A1200 WB 3.1, UAE AF 2006 WB 3.X, Sam440 AOS 4.1

Solution to churn problem and possibly to the Pitch Black attack

I read the Pitch Black paper and I think I've figured out a solution. Instead 
of trying to fit a circular keyspace in a graph that's spread over the 
surface of the earth with some long-distance links, I think it would be 
better to make the keyspace have more dimensions. Here's my proposal:

Break a key or location into four equal parts. These are coordinates of the 
point on a four-dimensional torus. Distance is measured in 8-space by 
embedding each torus dimension as a circle.

Every 1024 times a node adds something to its store, it performs this 
calculation: First it adds all the keys in its store as vectors in 8-space, 
then reduces that to a 4-dimensional point on the torus. Then it adds all its 
neighbors' locations and again reduces it to a point on the torus. The result 
is its new location. The location will be close to its neighbors; if the 
surface containing locations is curved, more of the store will be on the 
outside of the curve. Young nodes with few keys stored will be pulled rapidly 
toward their neighbors; old nodes will remain stably located near their data. 
Unlike the current method, where the product of distances rewards nodes for 
having locations next to each other, in this system nodes next to each other 
will be pulled apart, spreading more evenly over the keyspace.

The number of dimensions could be any divisor of 32 (the number of bytes in a 
hash). More than that and the notion of averaging in a dimension becomes 
problematic. I have a hunch that the optimal number of dimensions is 4, where 
two represent the surface of the earth and the other two different social 
classes in a region. Could someone who has a Freenet simulator run some tests 
and see how well this method performs for various numbers of dimensions?

Pierre
--

-- 
I believe in Yellow when I'm in Sweden and in Black when I'm in Wales.

nodes caching frequently requested files

Hi,

I'm completely new to freenet, actually I had this idea and someone told
me that this already exists. Awesome! So I'm not sure if this is done
already, I couldn't find anything on this. My idea is that if there are
seedboxes (sry I'm from the bt world, dunno how you call them), and, say,
50GB of free disk space, and there is this new episode of, say, Pioneer
One, and every 30 minutes he has to route the very same file. Couldn't we
implement the option to cache that file so other nodes are less seizured
and the file gets more seeders. The same technique could be used to keep
files with few seeders alive, of cause. Is this already implemented? If
not, what do you think of the idea?

-jan

Freenet doesn't start

I receive following error messages upon starting Freenet

"The Freenet wrapper terminated unexpectedly."

"The Freenet launcher was unable to connect to the Freenet node at port  
(8888)"   <- or any other port I tested

WebM filter

I see on the roadmap that a Theora filter is planned for the 0.8 release
and WebM is pushed back until 0.9. I think a WebM filter should be
supported in 0.8 if possible. It obviously provides much better video
quality than Theora. It also seems to have more momentum at the moment
with Firefox, Chrome, and Opera supporting it by about the time 0.8 is
released.
  Danny
  maminow@...

--

-- 
http://www.fastmail.fm - Same, same, but different...

Another approach to public gateways?

There has been some discussion of public gateways on IRC recently, particularly by nextgens, and by an
enthusiastic person joining the channel concerned with wikileaks.

The problem with public gateways has always been that the owners of these nodes are liable to get into
trouble for allowing access to Bad Stuff.

I wonder if we could:
1) Have a selective gateway mode, where you only allow external access to your personal favourite sites (a
checkbox when you bookmark, perhaps), AND
2) Co-ordinate between the gateways via a Web of Trust app, so that you can click on a link and have it find a
gateway that has that site? AND
3) When you reach a site that isn't mirrored by anyone, try a universal gateway AND
4) If there aren't any universal gateways, or every time you see a download page, send some advertising to
get the user to install Freenet, possibly with a locally served installer package (requires our packages
are signed).

Obviously it wouldn't scale indefinitely, and it would be possible to fetch the full mirror list. This is
also possible with e.g. wikileaks' mass mirroring effort though. It might be a worthwhile effort nonetheless?

Just a thought. Maybe somebody would like to write such a plugin.

_______________________________________________
Tech mailing list
Tech@...
http://freenetproject.org/cgi-bin/mailman/listinfo/tech

opennet/darknet

_______________________________________________
Tech mailing list
Tech@...
http://freenetproject.org/cgi-bin/mailman/listinfo/tech

Thoughts on traffic analysis and fast nodes

Problem 1) There are many nodes which have a lot more output bandwidth than Freenet can use.
Problem 2) Requests can in theory be traced across the network by advanced traffic analysis, even on darknet.
(Note that there are rather more powerful attacks that need to be dealt with first, I have discussed these in
other mails)

The best way to improve problem 1 is:
- New load management which takes better account of local circumstances.
- Bulk requests flag, so some requests are flagged as bulk, and will be allowed much longer timeouts and
therefore we allow many more of them at once, and thus are more likely to fill our bandwidth up.

It is interesting to note that right now requests are typically limited by projected worst-case bandwidth
usage (i.e. output bandwidth liability), not by actual output bandwidth usage. Bulk requests should
largely solve this.

However, there is likely to be some remnant even with these measures. And the second problem remains.

On the old email mixnets, they were said to be secure at a given minimum traffic level: An outgoing email
packet could not be matched to an incoming one, because there were several different options to match it
with. With delays this was even more secure.

Theoretically only full Constant Bit Rate links resist powerful traffic analysis. However IMHO we can get
quite close to CBR in practice, without a massive performance cost:

First option: Queue blocks and only send one block when there are a bunch of others to send. The threshold
should be configurable.

Sub-problems:
a) We would have to send entire blocks at once. I.e. we could not forward a block until we had received it in
full. This may however be acceptable for bulk requests. And it is very much compatible with the
trickle-back secure bursting proposals. And on fast nodes it should not normally be a problem anyway, the
special case logic should only trigger occasionally.
b) What if there aren't any others? Solution: Create them from padding or see below.

Obviously this does leak some information, not being full CBR.

Second option: Create useful traffic. Ensure that most peers constantly have data to send, and therefore
data is limited by the capacity of the internet connection to that node. Thus we obscure any data
travelling along that link. The main caveat is if we let message priorities compete between peers, there
will still be information leakage. Right now we don't let message priorities compete between peers, but
if we implement the below we will want to. On nodes with relatively high security settings which have a lot
of output bandwidth, it may be acceptable to turn this off.

Main sources:
a) Bulk requests, see above - the more requests are running at once the greater the chance that a given peer
constantly has data to send.
b) Bloom filter sharing. This requires that the bloom filters or similar structures be divided into chunks
which are independantly useful, but that is fairly essential anyway for reasons of e.g. memory usage.
c) Opportunistic datastore filling.

Obviously the latter two have security impacts themselves, however:
1) Both of these have the potential to significantly shorten average paths and therefore not only improve
performance but security as well, especially against a distant attacker.
2) Our local requests are not cached in our datastore anyway. They could migrate back to it with
opportunistic datastore filling, but no more so than they would migrate to other nodes in the area - if an
attacker can encircle us and find the local data requests stored on a circle of nodes at 2-4 hops out, he can
probably get some idea where we are anyway. The only way to stop that sort of thing is tunnels, or not letting
the attacker get close in the first place. Both are planned, although likely not by default for all parts of
all requests.

Bloom filters can be quite large, but opportunistic datastore filling is likely to be huge, especially if
peers are dynamic i.e. it works slightly better on opennet than on darknet. Bloom filter sharing on the
other hand will probably only work where the overhead is low i.e. where there is spare bandwidth on the side
of the node sending the filters, or where there is a very long-term relationship (e.g. darknet), so the
cost is divided over a long period.

Third option: Full blown enforced CBR. This may be acceptable for some really paranoid darknet users, it's
clearly not something we want by default.

Bursts: The more bursty the network, the more obvious the traffic flows will be in the absence of full CBR. On
the other hand, the shorter they are, both in path length and time, the less likely it is that attackers can
exploit them even if present on a random proportion of nodes (which is very hard on darknet), and the easier
it is to take countermeasures to prevent mobile attacker attacks.

_______________________________________________
Tech mailing list
Tech@...
http://freenetproject.org/cgi-bin/mailman/listinfo/tech