On Mon, Jan 01, 2001 at 10:21:00PM -0500, [EMAIL PROTECTED] wrote:
> On Sun, Dec 31, 2000 at 01:10:25PM -0800, Dale Babiy wrote:
> > On Sat, Dec 30, 2000 at 08:53:25PM -0500, news wrote:
> > > And of course browsers *could* implement this functionality themselves.
> >
> > It seems risky to make the assumption that all browser code should be
> > trusted esp. given that we have no ability to audit the code. A piece of
> > firewalling code would seem more appropiate under the circumstances,
> > unfortunatly it would be highly platform dependant. I think delegating
> > the responsibility for this to Fproxy makes the most sense in the long
> > run.
>
> I agree in the short run, but in the long run, I think browsers should
> evolve to support freenet: the same way they have evolved to support
> things like HTTP, FTP, proxies, gopher, wais, HTML, etc.
*grins* well here I run into a design philosophy problem. I generally buy
the unix, 'do one thing and do it well' ethos. For example, I use my
browser for http. I have another application to do my FTP activities,
etc.
The problem is that existing web browsers are _not_ designed to meet
Freenet's base design goal, to provide a secure anonymous mechanism for
transfering data.
Web browsers have tools like cookies, redirects, etc, which are designed
to provide, in many cases the exact oppisite. Instead of our goal, which
is in essance to give control over the process to the consumer/publisher,
web browsers attempt to give control to the server, sending info about
platform, cookies, poping up new windows to different sites all without
the users permission. It would require a major deep design change to make
any of the mainstream browsers into a device that I would be happy
acting as an unmediated user agent for my browsing of the Freenet.
> In the short term, perhaps a useful tool would be to have a proxy
> running on localhost that was switchable by the user (think system
> tray icon for winbloze) into freenet or non-freenet mode. In freenet
> mode it blocks all non-freenet protocols, and otherwise it passes
> through directly to the 'net or the user's normal web proxy.
Yep, and this is the direction I would like to see Fred/Fproxy head in.
Don't get me wrong. I'd love for Mozilla to parse Freenet:// natively,
but I'd hate to see the option to use an Fproxy mediator to be
lost. Security <=> Convience is as always a continium and I think the
user should be given a choice of where to place themselves on that
continium. For 99% of the public, ya punching a freenet:// address into
IE10.9e would probably be suffient for their needs. For those running the
Martian underground smuggling out opressed human slaves, something closer
to the secure end of the scale might be more desirable.
Would you trust your life to the fact that your web browser doesn't leak
any info when you type freenet:KSK@resistance/mars/contacts.html in the
address bar?
--
Dale Babiy
"If the internet routes around failure why does www.microsoft.com resolve?"
_______________________________________________
Freenet-dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
