Re: [Tech] Opera JPEG vulnerability

Top Page
Author: Matthew Toseland
Date:  
To: tech
Subject: Re: [Tech] Opera JPEG vulnerability
Delete this message
Reply to this message
gpg: Signature made Sat Mar 1 12:42:12 2008 UTC using DSA key ID E43DA450
gpg: Good signature from "Matthew John Toseland <toad@amphibian.dyndns.org>"
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.