Send Freenet-dev mailing list submissions to
freenet-dev at lists.sourceforge.net
To subscribe or unsubscribe via the web, visit
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
or, via email, send a message with subject or body 'help' to
freenet-dev-request at lists.sourceforge.net
You can reach the person managing the list at
freenet-dev-admin at lists.sourceforge.net
When replying, please edit your Subject line so it is more specific than
"Re: Contents of Freenet-dev digest..."
Today's Topics:
1. Brotherhoods (Muzzle)
2. Re: KHK Metadata Proposal (Muzzle)
3. Re: Forwaeding a message from freenet-chat (Andrus Adamchik)
4. Sorry and new address. (Benjamin Coates)
5. Re: KHK Metadata Proposal (Jason Marshall)
6. Re: Forwaeding a message from freenet-chat (Oskar Sandberg)
7. Re: Self Censorship (Timm Murray)
8. Re: KHK Metadata Proposal (Benjamin Coates)
9. A Metadata Filtering Proposal (Benjamin Coates)
10. Re: Meaningless hits on metadata (Alex Barnell)
11. Re: Meaningless hits on metadata (Alex Barnell)
12. Re: KHK Metadata Proposal (Scott G. Miller)
13. A couple beginner questions about protocol and assumptions... (Greg Titus)
--__--__--
Message: 1
From: "Muzzle" <[email protected]>
To: "Freenet-dev" <freenet-dev at lists.sourceforge.net>
Date: Fri, 23 Jun 2000 13:17:37 +0200
Reply-To: "Muzzle" <muzzle at freemail.it>
Subject: [Freenet-dev] Brotherhoods
Reply-To: freenet-dev at lists.sourceforge.net
How can we espect an user to collect a lot of good pubkey in order to
do pubkey searching?
I think we could ask people who insert in freenet if they want to join
a consortium, a brotherhood (i like this one better) that users trust
and sign the data they add under a group key that his brotherhood (BH)
will give him. If a BH get informed of one of his members spamming
around it will just revoke the key to this user.
Well it's not the clearest proposal i've ever written but i hope youll
understand it.
I thin it dosnt really involve the freenet protocol the BH feature just
need to be implemented on the client side, that will remember trusted
sig. and look for revoked keys.
Michele
--
Muzzle, Flatline, Zero on IRC; ICQ# 36124438
Key fingerprint: 5881 356B DDA7 115B 6FAF C529 34ED 70A8 7E52 D805
www.internations.net/it/muzzle
"We are, we can, we will"
--__--__--
Message: 2
From: "Muzzle" <[email protected]>
To: "freenet-dev at lists.sourceforge.net" <freenet-dev at
lists.sourceforge.net>
Date: Fri, 23 Jun 2000 15:16:03 +0200
Reply-To: "Muzzle" <muzzle at freemail.it>
Subject: Re: [Freenet-dev] KHK Metadata Proposal
Reply-To: freenet-dev at lists.sourceforge.net
On Fri, 23 Jun 2000 01:49:12 -0500 (CDT), Brandon wrote:
>
>> I'm a big proponent of a web-of-trust backed search system. (Though I
>> hate that name, we've gotta get that "web" out of there)
>
>Yay!
>
Is there anyone avaible to explain me the way it work
>> I don't like unrequests. They seem like trouble waiting to happen.
>
>I don't really like them either, but it's either unrequests or come up
>with an alternative. Even though they seem problematic, they do definitely
>solve the problem. I think that signature filtering doesn't solve the
>problem (you don't always have a signature to filter with) but it makes it
>considerably less bad (spam won't live forever).
>
Why not just make metadata search request weightless in order to decide
whether the data should be deleted?
Let the spam some time to die.
--
Muzzle, Flatline, Zero on IRC; ICQ# 36124438
Key fingerprint: 5881 356B DDA7 115B 6FAF C529 34ED 70A8 7E52 D805
www.internations.net/it/muzzle
"We are, we can, we will"
--__--__--
Message: 3
From: "Andrus Adamchik" <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Forwaeding a message from freenet-chat
Date: Fri, 23 Jun 2000 14:27:37 GMT
Reply-To: freenet-dev at lists.sourceforge.net
> > 2. Dynamic
> >
> > This marks the data as not to be cached. In practise, that means it's
> > put into the stack below the "threshold", as routing data only, once
> > it's ben successfully sent. This is for CGIs and other dynamic content
> > where the sender doesn't mind it being destructible, but would still
> > want it not to be traceable. The "dynamic" marker should be sent with
> > the data all the way to its destination.
>
>How can you generate dynamic content when it is not being sent from
>your own machine? I'm guessing you meant this to go with the first
>thing, which makes it irrellevant. You seem to think that there is a
>way to locate somebodies server on Freenet: there is not, only data
>can be located.
>
>Note also that even were it possible, this would be a huge security
>hole. Anything that sends the routing information and not the data
>allows an attacker to home in and disable nodes where information is
>stored, without in effect spreading it elsewhere.
Pardon my ignorance, I just started looking at the whole idea. But inability
to serve dynamic content or execute some code seems to be rather crippling.
(Did I overlook something? If so, disregard everything below and send me a
link.) Original web was also just a way to share static documents, so now
people have to struggle with limitations of HTTP (like HTTP 1.0 being
stateless) to make it dynamic.
Of course because of the privacy and anonymity idea, those programs can not
reside on a fixed server, but what if the code will fly across the network
in a form of Java objects (something like applets, but not necessarily GUI
objects). Pieces of code may be requested the same way as static documents.
In its turn Java objects will request the data they need for processing the
way a regular client would. Java libraries can be distributed just the same
way as mp3 files.
Just an idea. Is anyone already working on any similar problem or is it
totally out of the picture?
Disclaimer: Yes, I know, this will lead to creation of "freE-commerce",
police bots in the network, etc. But still, there should be a way... an
ability to run a program is also a free speech issue.
Andrus
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
--__--__--
Message: 4
To: freenet-chat at lists.sourceforge.net
Cc: freenet-dev at lists.sourceforge.net
Date: Fri, 23 Jun 2000 07:54:40 -0700
From: Benjamin Coates <[email protected]>
Subject: [Freenet-dev] Sorry and new address.
Reply-To: freenet-dev at lists.sourceforge.net
Ugh. Sorry again for the latest batch of doubled e-mails. I'm changing
clients and services so that it won't happen again (unless I'm cursed)
My new address is Coates at mailandnews.com
--
Benjamin Coates
________________________________________________________________
YOU'RE PAYING TOO MUCH FOR THE INTERNET!
Juno now offers FREE Internet Access!
Try it today - there's no risk! For your FREE software, visit:
http://dl.www.juno.com/get/tagj.
--__--__--
Message: 5
From: Jason Marshall <[email protected]>
Subject: Re: [Freenet-dev] KHK Metadata Proposal
To: freenet-dev at lists.sourceforge.net
Date: Fri, 23 Jun 2000 07:09:56 -0700 (PDT)
Reply-To: jmarsh at serv.net
Reply-To: freenet-dev at lists.sourceforge.net
> > There's no point in having automatic serverside authentication of Metadata,
> > it
> > would harm efficiency.
> It would increase CPU usage and decrease bandwidth. Whether it's worth it
> is based on how the tradeoff is weighted and what's more important.
You could always do auditing.
Verify N % of all files you transfer, and verify any repeat requests after the
Mth transfer. Considering that transfers are ultimately limited by the
kernel networking code and the hardware, you probably only need a linear
reduction in the cost per transaction in order to saturate a box.
-Jason
--__--__--
Message: 6
Date: Fri, 23 Jun 2000 17:48:18 +0200 (MET DST)
From: Oskar Sandberg <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Forwaeding a message from freenet-chat
Reply-To: freenet-dev at lists.sourceforge.net
Yes, it is an interesting idea that I have thought about before, no I
don't think it is something we should be working on before we even
know how well static content works.
Oskar Sandberg
md98-osa at nada.kth.se
On Fri, 23 Jun 2000, Andrus Adamchik wrote:
> > > 2. Dynamic
> > >
> > > This marks the data as not to be cached. In practise, that means it's
> > > put into the stack below the "threshold", as routing data only, once
> > > it's ben successfully sent. This is for CGIs and other dynamic content
> > > where the sender doesn't mind it being destructible, but would still
> > > want it not to be traceable. The "dynamic" marker should be sent with
> > > the data all the way to its destination.
> >
> >How can you generate dynamic content when it is not being sent from
> >your own machine? I'm guessing you meant this to go with the first
> >thing, which makes it irrellevant. You seem to think that there is a
> >way to locate somebodies server on Freenet: there is not, only data
> >can be located.
> >
> >Note also that even were it possible, this would be a huge security
> >hole. Anything that sends the routing information and not the data
> >allows an attacker to home in and disable nodes where information is
> >stored, without in effect spreading it elsewhere.
>
> Pardon my ignorance, I just started looking at the whole idea. But inability
> to serve dynamic content or execute some code seems to be rather crippling.
> (Did I overlook something? If so, disregard everything below and send me a
> link.) Original web was also just a way to share static documents, so now
> people have to struggle with limitations of HTTP (like HTTP 1.0 being
> stateless) to make it dynamic.
>
> Of course because of the privacy and anonymity idea, those programs can not
> reside on a fixed server, but what if the code will fly across the network
> in a form of Java objects (something like applets, but not necessarily GUI
> objects). Pieces of code may be requested the same way as static documents.
> In its turn Java objects will request the data they need for processing the
> way a regular client would. Java libraries can be distributed just the same
> way as mp3 files.
>
> Just an idea. Is anyone already working on any similar problem or is it
> totally out of the picture?
>
> Disclaimer: Yes, I know, this will lead to creation of "freE-commerce",
> police bots in the network, etc. But still, there should be a way... an
> ability to run a program is also a free speech issue.
>
>
> Andrus
>
> ________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
>
>
> _______________________________________________
> Freenet-dev mailing list
> Freenet-dev at lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/freenet-dev
>
--__--__--
Message: 7
From: "Timm Murray" <[email protected]>
To: <freenet-dev at lists.sourceforge.net>
Subject: Re: [Freenet-dev] Self Censorship
Date: Fri, 23 Jun 2000 11:06:04 -0500
charset="iso-8859-1"
Reply-To: freenet-dev at lists.sourceforge.net
<snip>
> -You don't have illegal material, you have just a piece of it (how does
> law deal with it?)
<snip>
Probably by saying its a conspericy. That would be a streach, because the
"co-consperiters" never actual talked to each other, but I don't think its
impossible.
--__--__--
Message: 8
Date: Fri, 23 Jun 2000 12:20:59 -0400
From: Benjamin Coates <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] KHK Metadata Proposal
Reply-To: freenet-dev at lists.sourceforge.net
From: Brandon <[email protected]>
> Unsigned metadata will be exactly as useful as randomly signed metadata.
>> Oh yeah: Generating a one-time key, signing the metadata, and throwing
>> away the key is still better than unsigned metadata, because then other
>> people who happen across your metadata can publicize their trust for it
>> (the one-use key) and it will have a chance to spread through people that
>> trust them. Making this work for unsigned metadata would require a whole
>> new layer of complexity (trusting individual metadata instead of signers)
> But if you only sign a single piece of data when telling people to trust
> this key is exactly equal to telling them to trust the piece of
> metadata. So you might as well just send them the key for the metadata
> instead of the public key of the signer. The only thing you gain from
> signing anything is that it gets grouped together with other things you
> sign. Like a directory.
It would be exactly the same as telling people to trust the metadata, but it
wouldn't require anyone to code a way of trusting metadata in addition to
trusting signatures. It works out to the same thing, so we might as well do
it the easy way.
--
Benjamin Coates
--__--__--
Message: 9
Date: Fri, 23 Jun 2000 12:30:20 -0400
From: Benjamin Coates <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: [Freenet-dev] A Metadata Filtering Proposal
Reply-To: freenet-dev at lists.sourceforge.net
I posted a proposal for filtering metadata here:
http://scf.usc.edu/~coates/freenet/proposal.html
I'm not at all happy with the terminology I use, but I think the idea comes
across alright anyway.
--
Benjamin Coates
--__--__--
Message: 10
Date: Fri, 23 Jun 2000 17:37:11 +0100
From: Alex Barnell <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Meaningless hits on metadata
Reply-To: freenet-dev at lists.sourceforge.net
Brandon wrote:
>
> > Why not ignore all hits directly on metadata and just propagate hits on the
> > underlying data back to the metadata. This be pretty simple and hard to
> > exploit.
>
> But then how do you determine which metadata entries to expire and which
> to keep? You can't keep them all because you'd run out of room.
>
That's up for debate - I mean, say one piece of metadata is 300bytes on average,
and say I devote half a gig to metadata. Thats a helluva lot of metadata
(1,789,570 entries).
--__--__--
Message: 11
Date: Fri, 23 Jun 2000 17:39:49 +0100
From: Alex Barnell <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Meaningless hits on metadata
Reply-To: freenet-dev at lists.sourceforge.net
Brandon wrote:
> Of course the way it's looking now, we're going to be able to actually
> encrypt the metadata, too. Even so, they'll be routed differently so nodes
Er, which type of metadata can we encrypt? I know we can encrypt private
metadata routed attached to the document.
--__--__--
Message: 12
Date: Fri, 23 Jun 2000 11:45:11 -0500
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] KHK Metadata Proposal
protocol="application/pgp-signature"; boundary="0OAP2g/MAC+5xKAE"
From: "Scott G. Miller" <[email protected]>
Reply-To: freenet-dev at lists.sourceforge.net
--0OAP2g/MAC+5xKAE
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
>=20
> It would be exactly the same as telling people to trust the metadata, but=
it=20
> wouldn't require anyone to code a way of trusting metadata in addition to=
=20
> trusting signatures. It works out to the same thing, so we might as well=
do=20
> it the easy way.
By trusting metadata, he means only that you take it at face value. The
easy way isn't mandating that everything be signed. Thats computationally
expensive not just for verifying, but also for key generation if you're
trying to remain anonymous by generating a new key for each document.
--0OAP2g/MAC+5xKAE
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE5U5QXpXyM95IyRhURAnS4AKCtPyo+tpYwDHL2cbC/XzStqfuCIwCgiYPW
5vvtEp0ZVBMWhKn2t+B04yE=
=uolH
-----END PGP SIGNATURE-----
--0OAP2g/MAC+5xKAE--
--__--__--
Message: 13
To: freenet-dev at lists.sourceforge.net
Date: Fri, 23 Jun 2000 11:23:40 -0700
From: Greg Titus <[email protected]>
Subject: [Freenet-dev] A couple beginner questions about protocol and
assumptions...
Reply-To: freenet-dev at lists.sourceforge.net
I'm just coming up to speed on Freenet and have a couple of remedial
questions about the low-level protocol and assumptions. Hopefully someone can
answer these and not disturb the metadata discussion going on, which I don't
understand well enough yet to comment on. :-)
The most basic question that I have is this: do I need to trust the nodes I'm
directly connected to or not? One idea in the original paper is that if I
make a request to a node, that node can't know whether I'm getting the
(embarrassing/illegal) data for myself, or whether I'm automatically
forwarding a request from someone else and have nothing (knowingly) to do with
it. A reply with the data should have similar plausible deniability. (There
are some holes in this by watching the depth or manipulating the TTL, but
that's the idea.)
However, I've seen a couple people on the list saying that you should trust
your "neighbors" or not be connected to them. Obviously if I am asking for
data through an HTTP gateway or something, I'd need to trust the gateway
because it knows I'm asking for myself, but if I run my own node this isn't
true. Or if I get surrounded by hostile nodes then together they can know what
I insert/request. However, I think it would be better to have enough
neighbors so that collusion is unlikely (which depends on my level of
paranoia, of course) rather than having few neighbors that I trust (which
means fewer nodes to suborn in order to spy on me).
Second question, does anyone have any information on the topology of the
current nodes (i.e. average connections per node, average # of hops between
randomly chosen nodes, longest non-cyclic path, that sort of thing)? Has there
been any discussion about what the optimum topology should be (the more
connected, the more efficient requests are, but in the limiting case of
everyone direct connected to everyone else, you lose that plausible
deniability again)? Also, knowing what the network looks like should determine
what values are appropriate for TTL, et cetera.
And finally a comment on the protocol/code: I really dislike the depth
component of messages. Its only purpose (please correct me if I'm
misunderstanding) is to have an appropriate TTL for reply messages like
Send.Data, and it both (a) uses bandwidth and storage to keep track of it on
every intermediate node and (b) immediately reveals which node is the
originator of each message to its neighbor unless you undermine its purpose by
randomizing it.
I found an earlier exchange about this in the list archive where someone
suggested doing away with TTL for replies since each node along the way
already should know the message id and exactly which neighbor to forward it
to, which was my first thought on looking at this as well. The response that
that person got was that reply TTLs are for defensive programming and
mentioned an example where because of another bug a reply got bounced between
two nodes until it eventually expired. It seems to me that this is extra
complexity, more work for the nodes, and a big potential hole in anonymity to
put up with just in order to save misbehaving nodes from themselves. There
should be no worry about getting the same reply twice since a node should
remove the message id from its pending requests list the first time it passes
the reply on. If it ever gets that message id again, it won't be in the
pending requests list and it should just drop it.
Thanks in advance for reducing my ignorance,
--Greg
--__--__--
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
End of Freenet-dev Digest
