On Saturday 01 March 2008 00:24, juergen urner wrote: > Marco A. Calamari schrieb: > > On Wed, 2008-02-27 at 18:51 +0000, Matthew Toseland wrote: > > > >> This is interesting because it came at the end of a thread on Frost where the > >> OP was arguing that Freenet shouldn't filter JPEGs. (Freenet strips out EXIF > >> data and other unknown chunks from JPEGs on download to maximize security; in > >> the future we will do something similar on inserts). > > > > IMHO changing in any way information inserted in Freenet *must* > > be documented, evident in user interface, up by default > > but easily user selectable. > > Is it really up to Freenet fixing issues in software people may use > along with it? Sounds like opening a can of worms with scarce > devel time at hand. If it is a problem related to fproxy, let fproxy > deal with it. Or tell users not to use Opera. > > As I see it, Freenet has a tendency of mixing node and client > stuff a bit too much.
We have to implement filtering because our threat model is completely different to that of the typical web browser. This explains why we implement filtering of HTML, and it explains why we warn the user on any type we can't filter - for example, mp3s can contain id3 tags, which might be interpreted by some players so you can click on the url to go to the song's author's homepage - or even as HTML. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20080301/475f3ac5/attachment.pgp>