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>

Reply via email to