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. -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
