On Wednesday 31 December 2008 23:37, Matthew Toseland wrote: > 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>
Okay, so we can solve both of the basic problems in-browser and without excessive use of javascript: 1. The history problem: Just add ?security=<long string> to freenet URIs. Rewrite them in fproxy when parsing freesites. The secret string should be derived from the uri and therefore useless externally if a user accidentally copies it. If the user enters a uri in the fproxy fetch-a-key box, fproxy can rewrite it. If the user tries to do http://127.0.0.1:8888/<key>, fproxy can tell them that this is a bad idea and they should wipe their browser history, and then give them a fixed link. This is slightly ugly but not hideously so (session cookies are pretty universal), and will work in any browser including with javascript disabled. There are two solutions to eliminate the ugliness: a) With a custom profile, with internet access turned off, possibly using fproxy as an actual proxy, and some way to identify itself to fproxy, we don't need to send the ?security= strings. b) With javascript, delete the location bar and provide some UI elements including a location bar that just includes the Freenet key (in freenet: format maybe), not the localhost URI. IMHO this is possible with javascript and frames. 2. The connections problem: For regular page fetches (full browser window occupied), we solve this with the progress screen. This can be updated every 5 seconds if we have no javascript, and more frequently (1 second?) if we do, since we can do XmlHttpRequest's, and since there is less relayout happening. Obviously in both cases we need to make allowances for overloaded fproxy e.g. on public nodes. For pages with inline images which are not in the cache, there is not much we can do without javascript: multipart/replace doesn't work for inline images, nor do Location: refresh's. But with javascript, we can poll regularly for the whole page, and update the loading graphic for each image as it progresses. > > > > -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/20090101/da81d28d/attachment.pgp>
