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. Re: Re: KHK Metadata Proposal (Scott G. Miller)
2. RE: negative trust (Henry Hemming)
3. Re: Re: KHK Metadata Proposal (Henry Hemming)
4. Re: Should users have control over their own node's content? (Scott G.
Miller)
5. Re: help please! (Scott G. Miller)
6. Re: Suggestion for ease of use.. (Scott G. Miller)
7. Re: Forwaeding a message from freenet-chat (Scott G. Miller)
8. RE: negative trust (Benjamin Coates)
9. RE: Should users have control over their own node's content? (Benjamin
Coates)
10. Re: Meaningless hits on metadata (Daniel Phillips)
11. RE: negative trust (Greg Titus)
12. Re: Should users have control over their own node's
content? (1723)
13. Re: help please! (Brandon)
14. Re: Forwaeding a message from freenet-chat (Brandon)
--__--__--
Message: 1
Date: Sat, 24 Jun 2000 10:48:59 -0500
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Re: KHK Metadata Proposal
protocol="application/pgp-signature"; boundary="0/kgSOzhNoDC5T3a"
From: "Scott G. Miller" <[email protected]>
Reply-To: freenet-dev at lists.sourceforge.net
--0/kgSOzhNoDC5T3a
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
>=20
> Well, I think there will be atleast some ppl/companies trying to use free=
net=20
> as their private data storage, and the best way to do this is to keep the=
=20
> data alive in freenet by touching it all the time.
Sure, but that would only effect the edge nodes attached to that
company. And if thats the case, why don't they just run their own
permanent data storage system.
--0/kgSOzhNoDC5T3a
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
iD8DBQE5VNhrpXyM95IyRhURArvgAJ97Kh4NqOJK/Z6Og+TWq3fxTkw+SQCfe3K9
uj/zCAc3UE319Eu/0Y21+fg=
=HMOc
-----END PGP SIGNATURE-----
--0/kgSOzhNoDC5T3a--
--__--__--
Message: 2
From: "Henry Hemming" <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: RE: [Freenet-dev] negative trust
Date: Sat, 24 Jun 2000 17:51:39 CEST
Reply-To: freenet-dev at lists.sourceforge.net
Using any kind of a black-list has a huge drawback, however if a popular key
owner (goverment) puts a anti-goverment key in a their black-list a majority
of the ppl will never see anything published with the anti-goverment key. :(
A way around this is to have no black-list and allow clients to _suggest_ to
each other removal of certain keys from their white-list, or to have a
non-permanent white-list, unfortunately, if the white-list is popular it
wont dissapere.
Again a solution might be a timestamp on the white-list, and when old enough
it would be ignored by all clients, this would enforce the update of the
white-list every now and then.
Also to stop a white-list from growing to huge sized maybe it should do
checks on what keys can be found in the white-lists its already leading to
and remove these keys from its own white-list, and thereby reduce the size
of the white-list.
One thing that could be done it to have a separate white-list and
black-list, both available, and the client could chooce whose white-lists
and whose black-lists to use. This would also make some factions very happy,
ie there would appear black-lists containing all known porn site.
--typo
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
--__--__--
Message: 3
From: "Henry Hemming" <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Re: KHK Metadata Proposal
Date: Sat, 24 Jun 2000 18:00:38 CEST
Reply-To: freenet-dev at lists.sourceforge.net
>From: "Scott G. Miller" <scgmille at indiana.edu>
> >
> > Well, I think there will be atleast some ppl/companies trying to use
> > freenet as their private data storage, and the best way to do this
> > is to keep the data alive in freenet by touching it all the time.
>Sure, but that would only effect the edge nodes attached to that
>company. And if thats the case, why don't they just run their own
>permanent data storage system.
Yes, but why not run a client that has 100 connections running all the time,
and while you are it why not just refuse to forward all requests, who knows
anyway?
Concidering you request your own data thru another node, all the nodes along
the path will be affected to some extent. With 100 connections with creates
aprox 10,000 path of variable length, even concidering that some of the
nodes will be the same it does affect freenet on the large.
--typo
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
--__--__--
Message: 4
Date: Sat, 24 Jun 2000 11:03:32 -0500
To: freenet-dev at lists.sourceforge.net
Cc: eford at princeton.edu
Subject: Re: [Freenet-dev] Should users have control over their own node's
content?
eford at princeton.edu
protocol="application/pgp-signature"; boundary="DqhR8hV3EnoxUkKN"
From: "Scott G. Miller" <[email protected]>
Reply-To: freenet-dev at lists.sourceforge.net
--DqhR8hV3EnoxUkKN
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
> 2. Freenet catches on. Many people use it. Many people abuse it.
> Governments don't like it and want to stop what they beleive to be
> abuses. Let's say that you provide no utility to allow node
> owners to easily remove certain content. Government tells node owner
> to stop it. Node owner may shut down his node completely (not good
> for free net), or the node owner may go to some trouble to remove
> the content. But maybe under the current system the node owner
> can say, "I can't help it. Deleteing just that would be too hard
> for me." There's nothing to stop the government from saying, "Actually,=
=20
> we've written this nice little program that will remove the offending=20
> material from your node." Then the node owner loses his previous defense
> and must either use the government's program (scary), figure out how to
> delete it himself (work), shut down the node entirely (bad), or face=20
> the consequences (rare, possiblely unfortunate). If freenet really=20
> catches on, then this is almost inevitable. =20
>=20
> Given those choices, I would prefer that there be a program that you
> guys write and distribute the source code to. Once someone else
> writes a closed source version, you guys will implement this feature.
> And given you're going to write it, you might as well do it now.
> Besides then you'll get some good PR for allowing node operators to=20
> delete content they don't like.
No. First of all, the node operator can't tell whats on his node without
a list of keys to tell if they are bad. Even if he did, this would be a
waste of his time.
When a government comes in and forces him to delete material, they are
affecting only one node. There will be thousands of nodes, and unless the
government can not only locate them all (difficult), *and* find out
*everywyere* that document exists (practically impossible), their
censorship of that specific node doesn't matter.=20
We just *ARE NOT* going to provide any censorship aiding tools. It goes
against the philosophy. We had this debate a week ago, please read the
archives.
Scott
--DqhR8hV3EnoxUkKN
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
iD8DBQE5VNvUpXyM95IyRhURAtFuAJ4kuKzq+NRJcK5/dYDcHtgaS1DipQCghm++
EUQlhuUgBQF47Avltg37rqs=
=n445
-----END PGP SIGNATURE-----
--DqhR8hV3EnoxUkKN--
--__--__--
Message: 5
Date: Sat, 24 Jun 2000 11:04:11 -0500
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] help please!
protocol="application/pgp-signature"; boundary="ni93GHxFvA+th69W"
From: "Scott G. Miller" <[email protected]>
Reply-To: freenet-dev at lists.sourceforge.net
--ni93GHxFvA+th69W
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Please post to freenet-support
On Sat, Jun 24, 2000 at 09:57:47AM +0000, no name wrote:
> Hi,
> I have just down loaded your program and I cant seem to get it to open. I=
=20
> saved it to desk top and along with the freenet software i also downloade=
d=20
> the java software. I even unzipped both downloads and when i click on any=
of=20
> the folders in them it asks you to choose which program to use to open th=
e=20
> program, and Im not quite sure which to open it in. I tried it in explore=
r=20
> and it doesnt work. Im very anxious to begin using your software, so plea=
se=20
> help me. Thank you.
> sincerely,
> nissa
> ________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
>=20
>=20
> _______________________________________________
> Freenet-dev mailing list
> Freenet-dev at lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/freenet-dev
>=20
--ni93GHxFvA+th69W
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
iD8DBQE5VNv7pXyM95IyRhURAg92AJ9E5H2FQpkng7qI2LqrycnLBn2kWQCgrFgz
dy+gZnhxL2PSu7nn1feWnRA=
=wwo9
-----END PGP SIGNATURE-----
--ni93GHxFvA+th69W--
--__--__--
Message: 6
Date: Sat, 24 Jun 2000 11:05:41 -0500
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Suggestion for ease of use..
protocol="application/pgp-signature"; boundary="HKEL+t8MFpg/ASTE"
From: "Scott G. Miller" <[email protected]>
Reply-To: freenet-dev at lists.sourceforge.net
--HKEL+t8MFpg/ASTE
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
>=20
> Would it the following recommendations be 'a good thing' or not?
>=20
> 1) Encourage people to setup a CNAME or A record called
> freenet.yourdomain.yourtopdomain and run the freenet node
> on the default port. For people who are too lazy to run their
> own node, this could point to someone elses node..
>=20
> 2) Encourage freenet clients use "freenet:19114" as a default
> node if no node is specified and no node answers on
> "localhost:19114".
We'd rather have people just run a local node. This isn't a huge
effort. However, these are good suggestions.
--HKEL+t8MFpg/ASTE
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
iD8DBQE5VNxVpXyM95IyRhURAlhuAJ9bHTJut7sYEFBLvM7i/66cmfEIFwCeIEBo
VBzxwsH2NajG4PgB6XsaDJs=
=fWb6
-----END PGP SIGNATURE-----
--HKEL+t8MFpg/ASTE--
--__--__--
Message: 7
Date: Sat, 24 Jun 2000 11:07:21 -0500
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Forwaeding a message from freenet-chat
protocol="application/pgp-signature"; boundary="poemUeGtc2GQvHuH"
From: "Scott G. Miller" <[email protected]>
Reply-To: freenet-dev at lists.sourceforge.net
--poemUeGtc2GQvHuH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
> What if there could be live java objects on the network, not ones that wo=
uld=20
> be downloaded, but ones that could forexample server as a dynamic web=20
> server. Ofcourse this would create the security problem of someone else=
=20
> having control over ones web-server, but with some nasty crypto should th=
is=20
> be possible to solve?
>=20
> Easiest way I can think this could be solved to some extent is for a clie=
nt=20
> to contact multiple hosts, and have them send a one way hash value on the=
=20
> data they are about to send, and if they dont match then refuse to accept=
=20
> the data. Also game servers could be run over freenet in this fashion.
I don't like the idea of using Freenet as a network with visible services
or servers on it. In all honesty, Freenet is a datastore. Applications
that want to be more complicated should only use freenet as such. There
are a lot of very good client-side applications that could be written
without any server side support, and anything more complicated could be
done out of band. =20
--poemUeGtc2GQvHuH
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
iD8DBQE5VNy5pXyM95IyRhURAv4OAKDFHMzRJdFWApW4UvUUxZYYAKyWkACguC69
M5TkpWV3/kLvlIg4qpY6xbA=
=Mr6S
-----END PGP SIGNATURE-----
--poemUeGtc2GQvHuH--
--__--__--
Message: 8
Date: Sat, 24 Jun 2000 12:49:53 -0400
From: Benjamin Coates <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: RE: [Freenet-dev] negative trust
Reply-To: freenet-dev at lists.sourceforge.net
> From "Henry Hemming" <hemming_henry at hotmail.com>
> Using any kind of a black-list has a huge drawback, however if a popular key
> owner (goverment) puts a anti-goverment key in a their black-list a majority
> of the ppl will never see anything published with the anti-goverment key. :(
Yes.
> A way around this is to have no black-list and allow clients to _suggest_ to
> each other removal of certain keys from their white-list, or to have a
> non-permanent white-list, unfortunately, if the white-list is popular it
> wont dissapere.
Minor terminology nitpick:
"Whitelist" is the private list each client keeps of people to trust. It is
never uploaded to Freenet, and occasionally refreshed.
"Trust-list" and "Meta-trust-list" are lists of people the user personally
vouches for. It is uploaded and used by other clients that meta-trust the
user in question.
I suppose clients could suggest to each other people to remove from their
trust-lists.
> Again a solution might be a timestamp on the white-list, and when old enough
> it would be ignored by all clients, this would enforce the update of the
> white-list every now and then.
Yes, clients could be programmed only download reasonably up-to-date trust
lists.
> Also to stop a white-list from growing to huge sized maybe it should do
> checks on what keys can be found in the white-lists its already leading to
> and remove these keys from its own white-list, and thereby reduce the size
> of the white-list.
I suppose this could be done, although I don't think there will be a list size
problem.
> One thing that could be done it to have a separate white-list and
> black-list, both available, and the client could chooce whose white-lists
> and whose black-lists to use. This would also make some factions very happy,
> ie there would appear black-lists containing all known porn site.
> --typo
I'm concerned about potential censorship implications of blacklists. I'd like
to avoid them entirely unless there is some pressing need for them. Also,
what does a client do when one person blacklists someone, and another person
whitelists them?
Here's an idea:
Let's say you trust someone (C) who trusts what turns out to be a spammer (D).
Your client temporarily stops trusting C, and checks C's trust list every
time you refresh your whitelist to see if D has been removed. If it has, you
begin trusting C again. You or your client could also notify C that this was
happening, and if C cared he could check into it. This stops "sleeper"
spammers without using blacklists--the only people that have to know are you
and C.
--
Benjamin Coates
--__--__--
Message: 9
Date: Sat, 24 Jun 2000 13:04:34 -0400
From: Benjamin Coates <[email protected]>
To: freenet-dev <freenet-dev at lists.sourceforge.net>
Cc: eford <eford at princeton.edu>
Subject: RE: [Freenet-dev] Should users have control over their own node's
content?
Reply-To: freenet-dev at lists.sourceforge.net
> From "Scott G. Miller" <scgmille at indiana.edu>
> No. First of all, the node operator can't tell whats on his node without
> a list of keys to tell if they are bad. Even if he did, this would be a
> waste of his time.
> When a government comes in and forces him to delete material, they are
> affecting only one node. There will be thousands of nodes, and unless the
> government can not only locate them all (difficult), *and* find out
> *everywyere* that document exists (practically impossible), their
> censorship of that specific node doesn't matter.
Which is why it's safe to let people remove keys from their node.
> We just *ARE NOT* going to provide any censorship aiding tools. It goes
> against the philosophy. We had this debate a week ago, please read the
> archives.
> Scott
And I still think that since anyone can write this program, we ought to. A
few reasons:
A) Reputation.
If we say that data can't be removed from Freenet, someone will come up with
this program and make us all look stupid. They will no doubt insist (and the
press will repeat) that they have "hacked" Freenet.
B) Damage Control.
If a government distributes this program and insists that everyone use it, it
could upload other information from the node as well... like the link in the
datastore that is likely to contain another copy of the document under attack.
This isn't going to not happen just because we don't do it.
--
Benjamin Coates
--__--__--
Message: 10
From: Daniel Phillips <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Meaningless hits on metadata
Date: Sat, 24 Jun 2000 19:26:23 +0200
Reply-To: freenet-dev at lists.sourceforge.net
On Fri, 23 Jun 2000, 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.
Some things are just too obvious to see right away. If the user originates the
data request through the same server as the search (the normal case) then that
server can easily associate the metadata with the data, and can "touch" the
metadata at the appropriate time.
To implement this, the originating server could keep the results of recent
searches around. When a data request comes through, the server checks the
recent searches to see if any of the retreived metadata references the same
data, and if so it "touches" the metadata. Optionally the server could also
remember the client that made the search so that it knows the same client is
now requesting the underlying data, though this would probably have little
impact on effectiveness of this strategy.
The cost of this is an extra chain of messages from the originating server
back to the server that supplied the metadata. This chain of messages is only
initiated when data is requested shortly after metadata referencing the same
data is retrieved. No reply is needed. This cost is most likely trivial
compared to the cost of the original search.
--
Daniel
--__--__--
Message: 11
To: freenet-dev at lists.sourceforge.net
Subject: RE: [Freenet-dev] negative trust
Date: Sat, 24 Jun 2000 11:22:17 -0700
From: Greg Titus <[email protected]>
Reply-To: freenet-dev at lists.sourceforge.net
Benjamin Coates wrote:
> That`s a concern, but a local negative-trust list won`t stop it. Here`s an
> example:
>
> B trusts C.
> C trusts D.
> D stops being trustworthy, and starts spamming.
> B puts D on a negative-trust list to stop the spam.
> (time passes)
> A begins trusting B.
> A gets a bunch of D`s spam.
>
> The only solution I can think of is for either C to stop trusting D or B to
> stop trusting C.
>
> Either way, though, it makes spamming much more difficult.
>
I wouldn't call it a negative-trust list, because there is no negative in
your system, but maybe a "do-not-care-after-all list". The difference between
a do-not-care list and a blacklist is, in a blacklist you immediately discard
anything by that key while in a do-not-care list, you only ignore that single
link in the trust chain. If that key is trusted through some other link in
your trust tree, you use those results after all.
In the case quoted above, B puts "C except for D" in his trust list, which
A's client sees when A is generating his whitelist. The reason why, IMHO,
this doesn't have any censorship implications is because B explicitly names D,
giving A the opporunity to decide for himself whether to trust C or D
directly and continue to get results from D.
Since all of the tree of trust following and whitelist generation is
happening on the individual client, there is no way for a popular key owner
(government) to get away with blacklisting an anti-government key without, in
effect, advertising that here is a key the government doesn't like. True,
there may be a lot of people that won't bother to verify that who the
government says is a spammer is really a spammer, but there will always be
someone (many people) who will check. I see this as a very similar situation
to all of the bad press that web-censorship products are getting for blocking
incorrect sites, except that there is no way in Freenet to try to keep your
block list secret.
BTW, as a suggestion: I think it is very likely with a system like this that
"expert trust lists" will arise where key X is widely known as an authority on
mp3's (for example) and there end up being many many users that add X to
their trust list. It may make sense to be able to rate the importance of
trusted keys on your client (or categorize your trusted keys to make X most
important when you are looking for that type of content) and send the N most
trusted keys along with your search query. Then the node where search results
are found can give priority to those results which are signed by the keys you
include. If you want more results than that, it can also continue to pass back
other matches, but only the matches that were explicitly asked for by
signature key would be cached on nodes on the way back to the client.
This would have the advantage of doing more work on the node to reduce
bandwidth heading back to the client, plus it solves the problem where spam
gets replicated over all the nodes - only the metadata signed by keys you
explicitly asked for would get cached closer to you.
On the other hand, it has the disadvantage of doing more work on the node.
You'd probably want to actually do the signature verification on the node to
keep spammers from faking signature's by popular trusted keys (caching those
results all over, and only having it be discovered on each individual client).
Doing the signature verification does, however, have the advantage that you
could immediately discard that signature from the node entirely if it doesn't
verify.
--Greg
--__--__--
Message: 12
Date: Sat, 24 Jun 2000 20:27:01 +0200
From: 1723 <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Should users have control over their own node's
content?
Reply-To: freenet-dev at lists.sourceforge.net
Benjamin Coates schrieb:
> And I still think that since anyone can write this program, we ought to. A
> few reasons:
the problem is, you can't do anything usefuel with such a program.
since you don't know what is stored in your disk, you can only
random-delete
documents.
> --
> Benjamin Coates
>
--
Labor, n:
One of the processes whereby A acquires property for B.
-- Ambrose Bierce
--__--__--
Message: 13
Date: Sat, 24 Jun 2000 13:57:20 -0500 (CDT)
From: Brandon <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] help please!
Reply-To: freenet-dev at lists.sourceforge.net
> Ah, you forgot to hold down ctrl, alt, and delete while you click on
> the Freenet program.
Hey, be nice to the newbies. They know not what they do.
--__--__--
Message: 14
Date: Sat, 24 Jun 2000 14:02:23 -0500 (CDT)
From: Brandon <[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
> This would almost work in today's Freenet if someone wrote the client. You'd
> need updatable keys for it to be very useful, as well as a www browser altered
> to access Freenet, and the browser JRE would need some tweaking as well...
Indeed, you could put applets in Freenet, though this looses some of the
usefulness. It would be more useful if distributed code could run on
nodes. But we're not going to do it. But yeah, applets on Freenet all
night long, right on.
--__--__--
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
End of Freenet-dev Digest
