Revision [2660]

Last edited on 2008-03-28 14:11:37 by MatthewToseland [javascript]
Additions:
- Browser problems. 0.7.0 will ship a Firefox profile, which will be configured for maximum security and performance for Freenet. Unfortunately, there is [[https://bugzilla.mozilla.org/show_bug.cgi?id=425065 a bug]] in Firefox which causes some problems with this. However, other solutions may be interesting too. Basically, the problems we want to solve are: 1) We need either a lot of parallel connections to fproxy, or ideally we would like to have not only web pages but also inline images show up as a loading graphic (perhaps even a progress bar) until they are loaded, which is then replaced when the data is found. 2) It must not be possible for a regular web page to access our browser history (via e.g. the CSS hide-link-if-visited property). Suggestions have included a plugin, an extension, or bundling a browser (this last is IMHO problematic in that we'd have to keep it up to date, and it would increase the download size significantly). It might even be possible to allow limited javascript via a plugin??
Deletions:
- Browser problems. 0.7.0 will ship a Firefox profile, which will be configured for maximum security and performance for Freenet. Unfortunately, there is [[https://bugzilla.mozilla.org/show_bug.cgi?id=425065 a bug]] in Firefox which causes some problems with this. However, other solutions may be interesting too. Basically, the problems we want to solve are: 1) We need either a lot of parallel connections to fproxy, or ideally we would like to have not only web pages but also inline images show up as a loading graphic (perhaps even a progress bar) until they are loaded, which is then replaced when the data is found. 2) It must not be possible for a regular web page to access our browser history (via e.g. the CSS hide-link-if-visited property). Suggestions have included a plugin, an extension, or bundling a browser (this last is IMHO problematic in that we'd have to keep it up to date, and it would increase the download size significantly).


Revision [2659]

Edited on 2008-03-28 14:01:16 by MatthewToseland [add browser problems]
Additions:
- Browser problems. 0.7.0 will ship a Firefox profile, which will be configured for maximum security and performance for Freenet. Unfortunately, there is [[https://bugzilla.mozilla.org/show_bug.cgi?id=425065 a bug]] in Firefox which causes some problems with this. However, other solutions may be interesting too. Basically, the problems we want to solve are: 1) We need either a lot of parallel connections to fproxy, or ideally we would like to have not only web pages but also inline images show up as a loading graphic (perhaps even a progress bar) until they are loaded, which is then replaced when the data is found. 2) It must not be possible for a regular web page to access our browser history (via e.g. the CSS hide-link-if-visited property). Suggestions have included a plugin, an extension, or bundling a browser (this last is IMHO problematic in that we'd have to keep it up to date, and it would increase the download size significantly).


Revision [2658]

Edited on 2008-03-27 18:46:34 by MatthewToseland [add anonymous development item]
Additions:
- More work on anonymous development. Finish pyFreenetHg (some major features are missing), identify any core changes that are needed to better support it (and ideally implement them), set up scripts to gateway the mailing lists to and from FMS or whatever forum system becomes dominant, access to the bug tracker over freemail, debugging on freemail, and build a system to publish a continually updated pyFreenetHg (or other freenet-hosted distributed VCS) tree mirroring the main SVN repository (with easy migration if we choose to switch the main repository to Mercurial). Demonstrate the full range of DVCS functionality on a mercurial (or other) tree hosted on Freenet (merges of bundles etc). Possibly implement some form of Freenet-friendly bug tracker system (maybe with a plugin).


Revision [2657]

Edited on 2008-03-27 16:56:11 by MichaelRogers [2006/7 were mislabelled as 2005/6]
Additions:
Summer of Code 2006 was very successful: Jerome Flesch built Thaw, a well-maintained and widely used filesharing app we have bundled with Freenet for some time. Florent Daigniere did a lot of good work on the installer and other boring stuff, and continues to be a core dev; Dave Baker did some good work on Freemail, although this is not very widely used as yet and is still somewhat buggy; and Michael Rogers' simulation work was of less value than we had hoped, but still useful. See NewTransportLayer for some related work. All of these were people we knew already to a greater or lesser degree.
Summer of Code 2007 was expanded and somewhat less successful: Notable successes include unit tests, searching, and more simulations (that helped to deal with a major attack vector amongst other things). Other projects included a C''''+''''+ library (which wasn't finished or documented, and hasn't been widely used afaik), a blogging plugin (which works, but isn't currently bundled and may have been overambitious technically), and a new link layer encryption scheme (which was reworked by a core dev). However we did pass all of our students. Some of them still contribute.
Deletions:
Summer of Code 2005 was very successful: Jerome Flesch built Thaw, a well-maintained and widely used filesharing app we have bundled with Freenet for some time. Florent Daigniere did a lot of good work on the installer and other boring stuff, and continues to be a core dev; Dave Baker did some good work on Freemail, although this is not very widely used as yet and is still somewhat buggy; and Michael Rogers' simulation work was of less value than we had hoped, but still useful. See NewTransportLayer for some related work. All of these were people we knew already to a greater or lesser degree.
Summer of Code 2006 was expanded and somewhat less successful: Notable successes include unit tests, searching, and more simulations (that helped to deal with a major attack vector amongst other things). Other projects included a C''''+''''+ library (which wasn't finished or documented, and hasn't been widely used afaik), a blogging plugin (which works, but isn't currently bundled and may have been overambitious technically), and a new link layer encryption scheme (which was reworked by a core dev). However we did pass all of our students. Some of them still contribute.


Revision [2656]

Edited on 2008-03-26 05:08:27 by NextGens [huh?]
Deletions:
====Sugestions====
- Library in C or C++
- Wrapper transport to tor, mute or gnunet
- Recompile java source code in gcc-java or bytecode similar Parrot


Revision [2655]

Edited on 2008-03-25 13:51:42 by MatthewToseland [link to google]
Additions:
We have been accepted as of the 17th of March. Google's guide to applying as a student: [[http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants here]].
Deletions:
We have been accepted as of the 17th of March. Students can apply from the 24th.


Revision [2653]

Edited on 2008-03-20 17:45:12 by MatthewToseland [elaborate on packaging, and explain that it's not high priority]
Additions:
- Packages for all the major Linux varieties, and better support for Linux (e.g. at the moment the installer doesn't even add an init.d script). Likewise on OS/X. Specifically, linux doesn't install a startup script, there are no linux packages except for one unofficial ebuild, the OS/X startup script doesn't work, and we should have the bunny systray icon back (there was some progress on this but nextgens ran into some problems). Note this is a low priority and relatively easy project, apply for something else as well. We would expect maintainable scripts and templates so we can do daily builds of packages etc. Rewriting the installer is not a priority at the moment, although if you think you can make it much better then contact us.
Deletions:
- Packages for all the major Linux varieties, and better support for Linux (e.g. at the moment the installer doesn't even add an init.d script). Likewise on OS/X.


Revision [2650]

Edited on 2008-03-18 23:14:26 by MatthewToseland [email]
Additions:
If you want to send us a proposal prior to actually applying, email us at devl at freenetproject.org.


Revision [2649]

Edited on 2008-03-18 22:17:03 by TimesE [Sugestions]
Additions:
====Sugestions====
- Library in C or C++
- Wrapper transport to tor, mute or gnunet
- Recompile java source code in gcc-java or bytecode similar Parrot


Revision [2648]

Edited on 2008-03-18 15:41:53 by ArneBab [Link to mercurial over freenet and ikiwiki added]
Additions:
- A working wiki system for Freenet. There has been some work on this but afaik it wasn't finished / didn't have write support? Maybe [[http://ikiwiki.info/ ikiwiki]] with [[http://127.0.0.1:8888/USK@BkZ2XwR55CSn90f~QnvIz5WfOtOBtHvW5zekL4t1Tms,Ea7ieYqQK5-YrlnVeJIQNp6L90MyrjVjP3A9QN1xgCA,AQACAAE/pyFreenetHg/10/ mercurial over freenet]] might be a good starting point.
Deletions:
- A working wiki system for Freenet. There has been some work on this but afaik it wasn't finished / didn't have write support? Maybe ikiwiki with mercurial over freenet might be a good starting point.


Revision [2647]

Edited on 2008-03-18 15:35:26 by ArneBab [note ikiwiki with the existing mercurial freenet backend to the wiki proposal.]
Additions:
- A working wiki system for Freenet. There has been some work on this but afaik it wasn't finished / didn't have write support? Maybe ikiwiki with mercurial over freenet might be a good starting point.
Deletions:
- A working wiki system for Freenet. There has been some work on this but afaik it wasn't finished / didn't have write support?


Revision [2646]

Edited on 2008-03-17 23:57:03 by MatthewToseland [we've been accepted]
Additions:
We have been accepted as of the 17th of March. Students can apply from the 24th.
Deletions:
(We haven't yet been accepted, since orgs cannot apply until Monday. We will update this page when and if we are accepted, however it is likely on our past record).


Revision [2629]

Edited on 2008-03-05 15:22:24 by MatthewToseland [progress-in-database]
Additions:
- Client layer: keep progress of requests and inserts in a database (probably not BDBJE, it has corruption problems), rather than in RAM. Store to a separate file only enough to restart from scratch if the database is corrupted. Would greatly reduce RAM usage on most nodes and decouple it from the size of your queue. There are some complications e.g. we should probably keep fproxy requests in RAM, we need to find a few keys-to-fetch in advance to avoid stalling on the database when we should be sending a request, etc.


Revision [2628]

Edited on 2008-03-05 15:03:45 by DaveBaker [add freemail webmail]
Additions:
- Webmail interface for Freemail, plus potentially an interface for seeing delivery statuses of messages and so forth.


Revision [2627]

Edited on 2008-03-05 14:56:13 by MatthewToseland [mention RSS]
Additions:
- Content filters for all the popular MIME types. At the moment we sanitise HTML reasonably effectively (but we don't support a lot of recent stuff; we do strip scripting and changing that is outside the So''''C's scope), we let through text (after checking it for RSS), and we do basic sanitising of JPEGs, PNGs and GIFs. Everything else results in a warning to the user. We should have better support for HTML5/XHTML2, possibly with embedded SVG etc, and filters for RSS, MP3, Ogg everything, PDF (big job!), etc. Also, we should implement optional (but by default) filtering on insert to strip out potentially compromising metadata, using the same filters with different settings.
Deletions:
- Content filters for all the popular MIME types. At the moment we sanitise HTML reasonably effectively (but we don't support a lot of recent stuff; we do strip scripting and changing that is outside the So''''C's scope), we let through text (after checking it for RSS), and we do basic sanitising of JPEGs, PNGs and GIFs. Everything else results in a warning to the user. We should have better support for HTML5/XHTML2, possibly with embedded SVG etc, and filters for MP3, Ogg everything, PDF (big job!), etc. Also, we should implement optional (but by default) filtering on insert to strip out potentially compromising metadata, using the same filters with different settings.


Revision [2626]

Edited on 2008-03-05 14:55:19 by MatthewToseland [formatting]
Additions:
- Content filters for all the popular MIME types. At the moment we sanitise HTML reasonably effectively (but we don't support a lot of recent stuff; we do strip scripting and changing that is outside the So''''C's scope), we let through text (after checking it for RSS), and we do basic sanitising of JPEGs, PNGs and GIFs. Everything else results in a warning to the user. We should have better support for HTML5/XHTML2, possibly with embedded SVG etc, and filters for MP3, Ogg everything, PDF (big job!), etc. Also, we should implement optional (but by default) filtering on insert to strip out potentially compromising metadata, using the same filters with different settings.
Deletions:
- Content filters for all the popular MIME types. At the moment we sanitise HTML reasonably effectively (but we don't support a lot of recent stuff; we do strip scripting and changing that is outside the SoC's scope), we let through text (after checking it for RSS), and we do basic sanitising of JPEGs, PNGs and GIFs. Everything else results in a warning to the user. We should have better support for HTML5/XHTML2, possibly with embedded SVG etc, and filters for MP3, Ogg everything, PDF (big job!), etc. Also, we should implement optional (but by default) filtering on insert to strip out potentially compromising metadata, using the same filters with different settings.


Revision [2625]

Edited on 2008-03-05 14:54:56 by MatthewToseland [mention scripting stripping]
Additions:
- Content filters for all the popular MIME types. At the moment we sanitise HTML reasonably effectively (but we don't support a lot of recent stuff; we do strip scripting and changing that is outside the SoC's scope), we let through text (after checking it for RSS), and we do basic sanitising of JPEGs, PNGs and GIFs. Everything else results in a warning to the user. We should have better support for HTML5/XHTML2, possibly with embedded SVG etc, and filters for MP3, Ogg everything, PDF (big job!), etc. Also, we should implement optional (but by default) filtering on insert to strip out potentially compromising metadata, using the same filters with different settings.
Deletions:
- Content filters for all the popular MIME types. At the moment we sanitise HTML reasonably effectively (but we don't support a lot of recent stuff, as well as of course stripping out scripting), we let through text (after checking it for RSS), and we do basic sanitising of JPEGs, PNGs and GIFs. Everything else results in a warning to the user. We should have better support for HTML5/XHTML2, possibly with embedded SVG etc, and filters for MP3, Ogg everything, PDF (big job!), etc. Also, we should implement optional (but by default) filtering on insert to strip out potentially compromising metadata, using the same filters with different settings.


Revision [2624]

Edited on 2008-03-05 14:53:25 by MatthewToseland [delete javascript filtering]
Deletions:
- [[http://wiki.freenetproject.org/JavascriptFilter Javascript filtering]]. It should be possible to implement a javascript filter: A lot of javascript is inherently safe, it's a question of defining those parts that are safe, failing on access to the rest, and creating libraries of sanitized functions that can be swapped in by the filter (possibly at a performance cost). Some of the security issues will be quite convoluted e.g. how do you prevent a message board app from doing timing-based profiling on your datastore? Upload rights should be restricted, and a possible solution would be per-client caches.


Revision [2623]

Edited on 2008-03-05 14:53:00 by MatthewToseland [link]
Additions:
- [[http://wiki.freenetproject.org/JavascriptFilter Javascript filtering]]. It should be possible to implement a javascript filter: A lot of javascript is inherently safe, it's a question of defining those parts that are safe, failing on access to the rest, and creating libraries of sanitized functions that can be swapped in by the filter (possibly at a performance cost). Some of the security issues will be quite convoluted e.g. how do you prevent a message board app from doing timing-based profiling on your datastore? Upload rights should be restricted, and a possible solution would be per-client caches.
Deletions:
- Javascript filtering. It should be possible to implement a javascript filter: A lot of javascript is inherently safe, it's a question of defining those parts that are safe, failing on access to the rest, and creating libraries of sanitized functions that can be swapped in by the filter (possibly at a performance cost). Some of the security issues will be quite convoluted e.g. how do you prevent a message board app from doing timing-based profiling on your datastore? Upload rights should be restricted, and a possible solution would be per-client caches.


Revision [2614]

The oldest known version of this page was created on 2008-03-04 15:16:58 by MatthewToseland [first version]
Valid XHTML 1.0 Transitional :: Valid CSS :: Powered by WikkaWiki