On Wednesday 31 December 2008 23:19, Colin Davis wrote: > Forgive my being naive, but couldn't you remove that vulnerability by > adding a nonce to the URL string? > > As I understand to exploit the history trick, you need to be able to show > the page and check the css-color against a visited link.. If the fproxy > request went to http://127.0.0.1:8888/randomstring/ssk, where randomstring > was generated by fproxy and appended before each link, the history trick > would fail. > > Freesites could still link to one another by way of having the filter > rewrite the 127.0.0.1/randomstring before sending the link to the browser.
Or even better: 127.0.0.1/SSK at ...?security=<long string> > > -Colin > > > 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 > > _______________________________________________ > > Devl mailing list > > Devl at freenetproject.org > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > -------------- 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/5c87d5b7/attachment.pgp>
