On Saturday 31 August 2002 14:41, Matthew wrote:

> > On Sat, Aug 31, 2002 at 02:47:45PM -0400, Gianni Johansson wrote:
> > On Saturday 31 August 2002 12:46,  Matthew wrote:
> > > > On Sat, Aug 31, 2002 at 12:33:58AM -0400, Gianni Johansson wrote:
> > > >
> > > > On Friday 30 August 2002 08:57, Matthew wrote:
> > > > > > On Thu, Aug 29, 2002 at 01:57:03PM +0100, Matthew Toseland wrote:
> > > > > > Hi. Newly implemented fproxy functionality allows you to fetch an
> > > > > > old edition of a DBR site, like this:
> > > > > > http://127.0.0.1:8888/SSK at rBjVda8pC-Kq04jUurIAb8IzAGcPAgM/TFE//?d
> > > > > >ate= 2002 0817
> > > >
> > > > You don't need to change the anonymity filter.  Just add support for
> > > > a date specifier in fproxy that doesn't use any illegal characters,
> > > > similar to to the external checked jump stuff.
> > > >
> > > > e.g.
> > > > http://127.0.0.1:8888/__USE_DATE_20020817__SSK at rBjVda8pC-Kq04jUurIAb8
> > > >IzAG cPAgM/TFE//
> > >
> > > Ugh. The anonymity filter blocks all links, both outlinks and links
> > > within freenet, which have ? in them...
> > >
> > > this is a problem for several sites
> >
> > Why? Are there cases besides the one I outlined below?  If we allowed
> > escaped ?, : and & in checked jumps would that make content authors happy
> > or are there other issues?
>
> Yes,
???

If we implement the following escapes:
__USE_DATE_xxxx__ -- dates
__COLON__  - ":"
__QMARK__  - "?"
__AMP__       - "&"

I think you can express any of the external jump URLs that people are 
complaining about.

Please give counter examples if you can think of one.

I would not change the anonymity filter at all unless you can state a 
compelling reason for doing so.  As I mentioned before, the debate and 
tweaking went on for *months*.  I do not at all consider myself an expert in 
this area but a lot of people spent a long time getting it right.

> > As far as internal content goes, I don't think that allowing content
> > authors to pass arbitrary arguments to fproxy is a good idea, at least
> > not without warning first.
>
> Hmmm. Perhaps. We have
> ?htl (hmmm)
> ?force (useless, as mallory doesn't know the random number)
> ?date (useless to mallory)
> ?mime (useless, as fproxy will reconfirm or filter if the mime type is
> risky) ?key (useless to mallory)

The worry is not so much what is there now, it is that as people continue to 
maintain fproxy and error in handling any new argument becomes a potential 
anonyimity risk if arbitrary arguments are allowed.

If "?" remains blocked the risk goes away.

> > Another issue would be preventing the case of a freesite making a link
> > that causes local files to be inserted into freenet without warning
> > you...
>
> This can happen through a get request? Really? How?
Maybe you are right. I haven't thought it through.

>
> > > Can it indicate javascript, or is this just to stop links within
> > > freenet from messing with the fproxy parameters? Can we safely allow
> > > ?'s in external links then?
> >
> > I think there was some issue with escape sequences that would allow you
> > to generate dangerous html but I can't remember.  The debate on the
> > filter went on for months and months.  I would be really careful about
> > changing it unless you are sure you know what you are doing.
> >
> > [
> > Aside: Could someone (Ian? agl?)  get the old mailing list archives back
> > on line so newer developpers have access to ancient freenet dev
> > chronicles. ]
> >
> > The only place I have seen ? (and also ":" ) cause problems is in legal
> > checked jumps.
> >
> > e.g. /__CHECKED_HTTP__hawk.freenetproject.org:8890/
> >
> > Trips the anonyimity filter even though it's safe.
>
> Yes, and similar problems with ?'s. javascript: can cause evil code...
> but probably not when prefaced with http://...
>
> > The easy conservative thing to do is to create legal escapes.
> >
> > So the above example would become:
> >
> > /__CHECKED_HTTP__hawk.freenetproject.org__COLON__8890/
> >
> > the filter wouldn't trip when the page was loaded.
> >
> > When the user clicks on the link, they would get the usual warning
> > message, with the escapes still in the url (that way fproxy is *never*
> > rendering html that might have dangerous characters).
> >
> > If they clicked through then fproxy would generate a redirect to the
> > external page with the escapes unescaped.
>
> So an extra level of indirection? Hmmm.
I haven't worked on that code in a long time.  There might already be a 
redirect there.  Even if  it requires an extra redirect I'm not worried about 
it at all.

-- gj

_______________________________________________
devl mailing list
devl at freenetproject.org
http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to