Re: Darknet vs opennet wording? was Re: Addressing the "Barlow" attack against opennet

On Thursday 23 December 2010 19:32:31 Matthew Toseland wrote:
> On Tuesday 21 December 2010 00:42:53 Matthew Toseland wrote:
> > On Friday 17 December 2010 15:50:11 Matthew Toseland wrote:
> > > On Tuesday 07 December 2010 17:21:07 Matthew Toseland wrote:
> > > > On Friday 03 December 2010 19:15:22 Klaus Koch wrote:
> > > > > > > It is a hard problem. But our traditional approach hasn't been terribly
> > > > > > > honest IMHO.
> > > > > 
> > > > > We were talking on #freenet on how to explain new users in a few words 
> > > > > (installer?) what freenet's security is all about and how to "warn" them of 
> > > > > the shortcomings of opennet. I came up with the following text:
> > > > > 
> > > > > "Freenet's security and anonymity is based on the idea that users connect to
> > > > > people they trust. Opennet mode (=LOW security level) is a convenience feature
> > > > > for new users who don't have trusted peers yet and it's security is not as 
> > > > > strong as darknet (= MEDIUM/HIGH security level). Use this mode to befriend 
> > > > > people you think you can trust. Get the highest security out of freenet by 
> > > > > connection to your reallife friends!"
> > > > > 
> > > > > somehow there's still missing that even connecting to a coworker is better 
> > > > > than a random stranger, but I still struggle to put it into one of the 
> > > > > sentences...
> > > > 
> > > > IMHO that is precisely what people misunderstand most frequently. How about:
> > > > 
> > > > Generally on Freenet you are only vulnerable to the users your node is connected to. 
> > > > Do you want Freenet to connect only to your friends? 
> > > > 
> > > > YES (DARKNET MODE):
> > > > If you have 5 or more friends who run Freenet, you should enable darknet mode, and add them on the Friends

Your friends can see what you are doing was Re: Darknet vs opennet wording? was Re: Addressing the "Barlow" attack against opennet

On Saturday 01 January 2011 13:32:41 Matthew Toseland wrote:
> On Thursday 23 December 2010 19:32:31 Matthew Toseland wrote:
> > On Tuesday 21 December 2010 00:42:53 Matthew Toseland wrote:
> > > On Friday 17 December 2010 15:50:11 Matthew Toseland wrote:
> > > > On Tuesday 07 December 2010 17:21:07 Matthew Toseland wrote:
> > > > > On Friday 03 December 2010 19:15:22 Klaus Koch wrote:
> > > > > > > > It is a hard problem. But our traditional approach hasn't been terribly
> > > > > > > > honest IMHO.
> > > > > > 
> > > > > > We were talking on #freenet on how to explain new users in a few words 
> > > > > > (installer?) what freenet's security is all about and how to "warn" them of 
> > > > > > the shortcomings of opennet. I came up with the following text:
> > > > > > 
> > > > > > "Freenet's security and anonymity is based on the idea that users connect to
> > > > > > people they trust. Opennet mode (=LOW security level) is a convenience feature
> > > > > > for new users who don't have trusted peers yet and it's security is not as 
> > > > > > strong as darknet (= MEDIUM/HIGH security level). Use this mode to befriend 
> > > > > > people you think you can trust. Get the highest security out of freenet by 
> > > > > > connection to your reallife friends!"
> > > > > > 
> > > > > > somehow there's still missing that even connecting to a coworker is better 
> > > > > > than a random stranger, but I still struggle to put it into one of the 
> > > > > > sentences...
> > > > > 
> > > > > IMHO that is precisely what people misunderstand most frequently. How about:
> > > > > 
> > > > > Generally on Freenet you are only vulnerable to the users your node is connected to. 
> > > > > Do you want Freenet to connect only to your friends? 
> > > > > 
> > > > > YES (DARKNET MODE):

Friends can see what you are doing: How to deal with this?

Right now the situation on Freenet is that:
- Your peers can see what you are doing. On either opennet or darknet!
- On opennet, anonymous identities can be traced by e.g. connecting to every node.
- On darknet, tracing anonymous identities is very hard.
- It is possible to write a plugin to identify a large proportion of what your friends are doing, and would not
be all that difficult; the database of keys would be the most resource-intensive part.
- Per-friend trust levels control how much data is shared with a friend node but even low friend trust does
not solve the basic problem of requests being visible.

IMHO at a minimum we need to:
- Tell the user in the first-time wizard. We are pretty close to this now, it probably makes sense to
elaborate very slightly, see the other thread.
- Make darknet a lot easier to use with invites, FOAF connections etc.
- Be careful what claims we make in public or on the website.
- Consider a change of terminology to emphasise darknet - "social darknet" ? The point is your friends are a)
your gateway to the network and b) assumed to be non-hostile, and the attacker is assumed not to be one of
your friends but a distant entity such as a corporate or (not too annoyed / well funded!) government agency.

Ideally we would provide an option which would provide adequate protection against a single malicious
friend, albeit at a significant performance cost. IMHO most users won't need this, at least most of the
time, because e.g. filesharers tend to connect to filesharers.

_______________________________________________
Devl mailing list
Devl@...
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

Local tunnels was Re: Friends can see what you are doing: How to deal with this?

On Saturday 01 January 2011 16:50:11 Matthew Toseland wrote:
> Right now the situation on Freenet is that:
> - Your peers can see what you are doing. On either opennet or darknet!
> - On opennet, anonymous identities can be traced by e.g. connecting to every node.
> - On darknet, tracing anonymous identities is very hard.
> - It is possible to write a plugin to identify a large proportion of what your friends are doing, and would
not be all that difficult; the database of keys would be the most resource-intensive part.
> - Per-friend trust levels control how much data is shared with a friend node but even low friend trust does
not solve the basic problem of requests being visible.
> 
> IMHO at a minimum we need to:
> - Tell the user in the first-time wizard. We are pretty close to this now, it probably makes sense to
elaborate very slightly, see the other thread.
> - Make darknet a lot easier to use with invites, FOAF connections etc.
> - Be careful what claims we make in public or on the website.
> - Consider a change of terminology to emphasise darknet - "social darknet" ? The point is your friends are
a) your gateway to the network and b) assumed to be non-hostile, and the attacker is assumed not to be one of
your friends but a distant entity such as a corporate or (not too annoyed / well funded!) government agency.
> 
> Ideally we would provide an option which would provide adequate protection against a single malicious
friend, albeit at a significant performance cost. IMHO most users won't need this, at least most of the
time, because e.g. filesharers tend to connect to filesharers.
> 
Tunnels may be possible: Because, on darknet, mobile attacker source tracing is hideously expensive,
(and connecting to everyone is virtually impossible, we do not have to worry about distant attackers
(except perhaps for the predictable-in-advance top SSK and chat posts). So we only have to worry about our
direct peers. Plus, we have both direct friend-to-friend connections and FOAF connections to route
down, which should make life easier. The simplest, rather limited options:

Me -> A's friend -> A

Re: [freenet-support] Freenet 0.7.5 build 1314 (and 1313)

On Friday 31 December 2010 02:41:32 Juiceman wrote:
> On Thu, Dec 30, 2010 at 7:48 PM, Matthew Toseland <toad@...org
> > wrote:
> 
> > Freenet 0.7.5 build 1314 is now available, please upgrade! It will be
> > mandatory on Tuesday.
> >
> > This build's main new feature is a new packet format. This should give
> > significant improvements in several areas:
> > - Fewer small packets.
> > - Much more efficient. Expect improved payload percentages, and failing SSK
> > requests in particular (which are very important for chat etc) should use
> > significantly fewer bytes.
> > - Better (faster) retransmission on lossy links.
> > - Able to adapt to any reasonable MTU.
> > - Lays the foundations for transport plugins (although not with really tiny
> > packets).
> > - Also necessary for the next stage of new load management, which should go
> > in next week if all goes well.
> >
> > This was zidel's Summer of Code project, although I've done some last
> > minute improvements.
> >
> > There are also some minor changes to filename sanitising on unix OS's and
> > some language infrastructure needed by Freetalk.
> >
> > Please upgrade! And please let me know if you have any problems.
> >
> > (1313 was never released due to finding some serious bugs at the last
> > minute)

Release plan, release schedule and tentative feature freeze

I would just like to point out that I am not planning to meet the deadline of 31 January. The reasons for this are:
1. The critical features for the release - particularly new load management (which has recently
incorporated new packet format) and darknet enhancements - really do matter.
2. In particular, I refuse to release without the darknet enhancements. Insubordination has its place,
when you're right! And in this case I'm right. :) Having said that, the absolute minimum of darknet
enhancements should be relatively small.
3. Equally, new load management matters. Right now the state of the network - even *before* the new packet
format changes - is pretty poor. And IMHO new load management is long overdue - and most of it, believe it or
not, is done already. However, several of the major components (notably new packet format and the timeout
related changes scheduled next) will require significant debugging, and after the fact stabilisation.
4. The darknet enhancements were not envisaged when I agreed to the deadline originally. (My recollection
is there was never a clear consensus for any particular date at a meeting, it was essentially an agreement
between me and ian.)
5. Meeting the deadline will require avoiding debugging important bugs which affect users and prevent
network growth.
6. Meeting the deadline will require not working effectively with volunteers whose interests are not
directly aligned with the deadline: Postponing or more likely completely ignoring their work.
7. Making Freetalk work well will require significant work on debugging and improving USK subscriptions.
It has recently become clear that this is developing into a serious crisis.
8. A public release the day after new load management is finished would be suicidal. Major changes at the
network level result in the network performing badly for a while and need major debugging.

Basically, my point is that aiming for a feature complete but buggy alpha/beta will result in not
addressing critical bugs, and that will make things extremely difficult for users, for unpaid
volunteers, and will result in a very poor release, which will not go down well. And it won't be possible to
meet the 31st jan no matter how much of a stressed out unhelpful anti-user anti-volunteer asshole I am in
trying to meet it.

IMHO what we need is:
- A defined and limited set of features that must work reasonably well.

Freenet 0.7.5 build 1319

Freenet 0.7.5 build 1319 is now available. This includes further critical fixes to the new packet format,
particularly affecting NATed nodes or nodes connecting to them. Please upgrade ASAP! Thanks.

_______________________________________________
Devl mailing list
Devl@...
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

Seednodes: Removing me and need more!

I've been lurking for some time and I'm looking for a good way to contribute.  If running a seed node helps then
I'm all for it

I currently have several machines running freenet of which I would be happy to use as a seednode.  My question
is, what makes a good seednode? 

-----Original Message-----
From: devl-bounces@...
[mailto:devl-bounces@...] On Behalf Of Matthew Toseland
Sent: Saturday, January 01, 2011 1:05 PM
To: devl@...; support@...
Subject: [freenet-dev] Seednodes: Removing me and need more!

I have removed my node from the seednodes list as of the next build because being a seednode makes it very
difficult to debug timeout bugs. However, we only have 8 seednodes at the moment. Please email me your
opennet noderef (from the Strangers page in advanced mode) if you can be a seednode. Thanks!

Re: Seednodes: Removing me and need more!

I second this. I'm more than willing to help out, but could you give us some more information about the
particular demands a seednode has to live up to?

On Jan 3, 2011, at 12:52 PM, Bill Ritchie wrote:

> I've been lurking for some time and I'm looking for a good way to contribute.  If running a seed node helps
then I'm all for it
> 
> I currently have several machines running freenet of which I would be happy to use as a seednode.  My
question is, what makes a good seednode? 
> 
> 
> -----Original Message-----
> From: devl-bounces@...
[mailto:devl-bounces@...] On Behalf Of Matthew Toseland
> Sent: Saturday, January 01, 2011 1:05 PM
> To: devl@...; support@...
> Subject: [freenet-dev] Seednodes: Removing me and need more!
> 
> I have removed my node from the seednodes list as of the next build because being a seednode makes it very
difficult to debug timeout bugs. However, we only have 8 seednodes at the moment. Please email me your
opennet noderef (from the Strangers page in advanced mode) if you can be a seednode. Thanks!
> _______________________________________________
> Devl mailing list
> Devl@...
> http://freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: Seednodes: Removing me and need more!

> I've been lurking for some time and I'm looking for a good way to
> contribute.  If running a seed node helps then I'm all for it
> 
> I currently have several machines running freenet of which I would be happy
> to use as a seednode.  My question is, what makes a good seednode?

Mandatory:
- Having a static IP adress or a dynamic DNS host (which you should tell 
Freenet in the configuration about).
- Opennet port needs to be forwarded / open

Optional:
- It shouldn't be to poor with upstream bandwidth. I'd say 30 KiB/s and 
upwards.
- It might cause quite some CPU usage, you will have to observe whether CPu is 
enough

We could really need seednodes so please consider it :)

_______________________________________________
Devl mailing list
Devl@...
http://freenetproject.org/cgi-bin/mailman/listinfo/devl