On Sat, Jul 05, 2003 at 08:04:30AM -0400, [EMAIL PROTECTED] wrote:
> Ok, I'm going to keep reiterating the concerns of myself, jrand0m, and many 
> others until something is done about them. (Some of these might just be mine, 
> however. I speak for myself right now.)
> 
> Freenet will not work in a hostile environment currently, because it's busy 
> being prettified for our comfy homes with fast computers and cable modems. This 
> is bad. I'd like to see you hike over to Tunisia or something, hook it up to 
> a computer and modem there, and make Freenet work. Doesn't work? Didn't think 
> so. (Ok, so Tunisia's a bit too developed, but try rural parts of Cuba, etc.)

Bullshit. Freenet will not work in hostile environments because a truly
hostile regime would ban it and set up a node harvester. Secondly,
Freenet's system requirements are quite considerable, and most really
hostile regimes currently are in the third world. The former issue may
eventually be addressed by the combination of NGrouting, trusted links
only routing, and steganography. But this will have to wait for after
1.0, it is HARD, and we need a working network first.
> 
> User modes == more options == more likely to break != KISS
> 
> Don't place all these images in the default builds for the error pages. It 
> shouldn't be up to a browser to cache them. Certainly, someone should not have 
> to risk their ass trying to get a more minimal page if they are in a hostile 
> environment.

It will run perfectly well with no browser cache. Anyone who will get
into serious trouble for running freenet will have read the README. If
they are an idiot, they will be busted. Idiocy conquers all. If they are
not an idiot, hopefully they will realize that turning off the browser
cache would be a good idea. In any case, there is an option
mainport.params.servlet.1.params.noCache=true

Which is off by default, and which I implemented but apparently did not
document in Node.java, sorry. This will tell the browser not to cache
Freenet content. A note on this will be added to the README.

With regards to the various decorative images, well, firstly, you can
disable images in your browser; this should also reduce the risk of web 
bugs (note added to README). Secondly, you should be running your own
node, or you have no plausible deniability. The only case in which the
images would be dangerous is if freenet itself is illegal and you are 
tunneling to somebody else's node. In such a dire situation, you are
probably f*cked anyway, because as explained above, Freenet is
detectable. I don't believe that adding a no-cache option for
_everything_ sent from Fred to the browser is particularly urgent or
useful, for the above reasons, however, if somebody wants to implement
it, we will accept a patch.
> 
> Don't log stuff like keys. Even if the person didn't request it, you 
> shouldn't be logging the names of keys.

Why would you have ANY logs if you are so paranoid? The purpose of logs
is to help to debug the node. Logs detail all sorts of things such as
the keys you accessed, (sometimes in human readable form), the nodes you
talked to, and more. If your computer itself is likely to be taken away,
and Freenet itself is not illegal, firstly, they will have your
datastore, and despite pcaching they may be able to identify your
frequently accessed content, (and there is nothing we can safely do
about this either, because if we added an option to not cache content
requested locally at all, a node that got a request could probe your
node for the content and thus identify it as a locally generated
request), and secondly, you have bigger concerns - browser cache, 
swapfile, anywhere you have actually downloaded the forbidden content
and so on. We COULD provide log anonymization, possibly with a number of
different levels, however it would be considerable work, and the truly
paranoid would probably run without logs, and it would be difficult to
prove that there is NO dangerous logging code.
> 
> Adopt the same deprecation method as Python. One build, the feature is 
> normal, the next is might be deprecated, and in the next build, it's gone. Don't 
> keep deprecated features forever, like it seems you do.

For example?

I know there are some issues with the config file, but anything else?
> 
> Make sure you try as hard as you can to break Freenet. Don't simply use it 
> normally. For instance, I do my browsing and publishing, but I'm also working on 
> what I believe to be a possible remote exploit or varying seriousness in 
> Fred.

We welcome exploit attempts. We always have done.
> 
> I'm not saying toad isn't working hard, but I think his effort is rather 
> misguided at times. He has done a lot, I admit that, but now we need to focus on 
> making it work where it would do the most good.

No, we need to get a large enough network that the first world countries
won't simply ban it outright, and fast enough that we will have plenty
of legitimate cover traffic, since for the foreseeable future it will
not be possible to run freenet in truly hostile, well resourced regimes.

And yes, there are a number of security features not yet implemented,
but planned for 1.0. Freenet will never be perfect. However a network
that is completely broken is completely useless even if it is perfectly
secure - and we will implement, for example, premix routing, before 1.0.

-- 
Matthew J Toseland - [EMAIL PROTECTED]
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.

Attachment: pgp00000.pgp
Description: PGP signature

Reply via email to