On Monday 27 July 2009 14:18:21 Matthew Toseland wrote:
> On Monday 27 July 2009 13:48:03 Matthew Toseland wrote:
> > http://emsenn.com/wp-content/uploads/2009/07/SoIC-1.21.pdf
> >
> > SPECIAL USAGE
> > There are some tools that may be developed which are not intended
> > to allow access to the entire Internet, but still allow people to
> > communicate.
> > PEER-TO-PEER
> > Peer-to-peer connections are a type of connection in which two
> > users communicate without the need of a centralized server. Almost
> > everything on the Internet relies on client-server connections, though
> > peer-to-peer is increasingly being used. It is a viable way for
> > communication because it is incredibly hard to completely block and does
> > not require a single server to stay in service for the duration of the
> > conflict. Unfortunately, almost all peer-to-peer solutions require a
> > network that is separate from the general Internet, meaning that they would
> > not allow dissidents to access their favorite websites.
> > FREENET
> > FreeNet allows the users to view (either in open or darknet
> > methods) a completely peer-to-peer web. It has the benefit of being able to
> > be a darknet, meaning no one who isn?t trusted to get on is even able to
> > connect. However, this also greatly limits the content available on the
> > darknet. Furthermore, adding content is a fairly complicated process.
> > While FreeNet is a great system and currently in very active
> > development, it is not quite ready for use in a situation like Iran.
> >
> > [ snip gnunet ]
> >
> > SUMMARY
> > In handling the Iranian firewall?s current measures and expansion,
> > there are a wide variety of options. However, at this time, none are ideal
> > and all are able to be theoretically filtered without cutting all Internet.
> > We do have several ways to keep the Iranian people communicating with the
> > world and each other and are developing new and expanded communication
> > methods.
> >
> IMHO it is useful to consider priorities in the light of using Freenet in its
> intended context, as opposed to in terms of getting more users in order to
> continue programming Freenet. However, there is a great deal of overlap
> between the two. Plus, we may be able to get funding for specific tasks
> designed to improve Freenet's utility in Iran, China, etc. Suggested priority
> areas:
> - Physical security. Specifically, the current stable build caches everything
> that passes through the node, including stuff requested and inserted locally.
> This will be largely resolved in the next stable build, with configurable
> physical security levels, optional encrypted client cache (and downloads
> database), a panic button that actually works, etc. There is work to do on
> encrypting the database for the chat system, searching etc.
> - Easy insert of freesites. We need a good freesite insertion wizard, a
> plugin as part of the base install. Maybe another attempt at an easy blogging
> wizard too.
> - Better performance on very slow connections, or where some connections may
> be very slow. In Iran, throttling the international gateway has been a
> deliberate tactic (!). There are some specific things (e.g. making the ping
> thresholds configurable, this is done in git), but this also overlaps with
> more general performance work: bloom filter sharing, better load management
> etc.
> - Small darknets may have some performance issues.
> - Better, integrated, attack resistant, easy to use, fast, chat. Negative
> trust issues may or may not be important, depending on the deployment, likely
> not a problem in the short term anyway. Embedded chat forums would probably
> work well...
> - Microblogging.
> - Ability to download an up-to-date Freenet installer from Freenet. IMHO this
> is easy and important, although specific deployments by groups such as
> NedaNet may use their own customised installers.
> - Reconfiguring the installer for new bookmarks and so on. IMHO this is easy,
> can be addressed on a case by case basis by individual organisations.
> However, language-specific freesite lists would be interesting for general
> use...
> - RSKs: Important sites, particularly those distributing executables, need a
> revocation mechanism. This can be emulated with HTML UI elements, but is
> clumsy and problematic due to the various different error messages.
> - Anything that makes it easier to connect to Friends.
> - [ long term ] Transport plugins and stego.
> - [ long term ] People have asked many times about making a true proxy system
> for Freenet. Generally it has been seen as out of scope, although there are
> various options technically. As long as Tor works, there is little reason for
> this - but we might be able to get funding, and IMHO Freenet/darknet may work
> in environments where Tor cannot. Maybe we should reconsider it?
> - [ long term ] 24x7 requirement, especially for darknet - this is not
> realistic in the west and may be even less so in other places.
>
Filtering audio/video files is also important for some places. Hopefully kurmi
will be able to deal with this. Filtering PDFs is important for other places
but is a lot more work.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20090727/43b6ebf0/attachment.pgp>