On Wednesday 31 December 2008 18:14, Colin Davis wrote: > I really think option 2 is the by FAR the most user friendly, for quite > a few reasons- > > 1) Software shouldn't be ill-behaved. I'm a large advocate of and for > Freenet, and even I get quite annoyed when freenet alters Firefox by > creating a new profile. I understand the rationale, but one software > package shouldn't modify the others on your machine. This is in part a > trust issue- Imagine the arguments on Slashdot if the newest iTunes > update added a Firefox profile for browsing Apple specific sites.. One > software package shouldn't be modifying others. > > 2) Creating a firefox profile doesn't work if Freenet isn't installed > locally. Freenet runs as a daemon, which is very convenient to connect > to remotely.. Since freenet requires a permanent connection to be > helpful, I prefer to run it on an old server in the closet, or hosted at > a Datacenter; Both of these optiosns work fine with Option 2, but with > option 1, I get the old-style, degraded experience. > > 3) Not everyone uses Firefox. I know, they should. IE has bugs, etc, > etc. But Opera still has quite a few users, Safari is the default on the > Mac, and Chrome is a growing alternative on Windows. It shouldn't be a > requirement that users use a specific browser to access Freenet > > Your point about Browser History can be addressed by Noting that users > may want to use the "Privacy Mode" feature of their browser, if it > exists. Safari and Chrome have this feature, and Firefox is adding it in > the next revision. While the Privacy mode is active, no history is > saved, and the cache is wiped.
That is hardly a reliable and universal out of the box solution! > > The connection limit is going up across the board. > https://bugzilla.mozilla.org/show_bug.cgi?id=423377#c4 > > Firefox 2: 2 > Firefox 3: 6 > Opera 9.26: 4 > Opera 9.5 beta: 4 > Safari 3.0.4 Mac/Windows: 4 > IE 7: 2 > IE 8: 6 Not relevant, the numbers here are not comparable to what we would need, but if we have a good implementation of the progress screen we won't need anywhere near as many as we do now. > > It's important to note, however, that the delay is not caused in going from fproxy to the browser. > The delay caused because Freenet takes a long time to request from the network. > A "Loading" page is necessary here regardless. > > Further, since, IIRC, freesites are submitted as compressed entire sites, requesting index.html will also pull in the images, etc. > This means that by the time any of the site loads, fproxy should already have the rest of the site in cache, so the browser limit isn't the issue. Unless it has inline images which are big enough to not fit in the container, or the site is split into multiple containers, or it has overflowed, or it inlines images from other sites ... > > I think the current situation is probably good enough, if the loading screen were in place. The browser-in-a-browser is the best option of the three, but still seems overkill. It's not overkill, it's a critical security bug. It MUST be solved, or it becomes the weakest point of the whole system. In fact arguably it's the weak point in the whole proxy/http/url's idea: if freenet has URLs, external websites will be able to probe browser history's for them, therefore we should not have a simple proxy at all, at least not without warning the user and asking for an explicit override. > -CPD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20081231/227dccf8/attachment.pgp>
