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.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
