1. Ok, I may be a little bit slow here. If we restrict xhr, and dynamic frames, that would just slow a trouble maker down, not stop him. The same guy who writes the js writes the html, so he can put in html <iframe src=anything.com></iframe> and then the js can access the html via frames[0].contentDocument.innerHTML A c program can crank out the html dynamically, and make all sorts of frames. If you don't want the user to know you're doing it you can set display=none in css so it's not even visible. That's not as convenient as xhr but it still works. So I don't see the point.
> 0 will not block anything (what we do right now) 2. The same guy that writes the js, and the html, also sends out the http headers, so if he wants xhr to access anything then he just sets that http header to 0 and off he goes. It's like we put a lock on our browser for some kind of security, but they can open it with an http key, and everybody knows it. How does that help? 3. If we implement restrictions, we have to do it all, including the http key that unlocks them, because some website might unlock them and expect xhr to work on some other domain, and when it doesn't, then the website doesn't work. 4. The matching rules may not be as simple as "same host" I'm thinking of cookies here. If you set a cookie on bar.com/a/b, that cookie remains valid for foo.bar.com/a/b, bar.com/a/b/c, and foo.bar.com/a/b/c. I'm not sure the details, Chris wrote it, I'd have to go back and read the code. It seems likely though that xhr restrictions, if they were in force, would be similar. You could go ahead and fetch foo.bar.com if you were currently on bar.com. 5. I'm not trying to be rude or ungrateful here, I just don't want to do something that makes things worse. I appreciate all the research you are doing. As for experimenting with firefox to see what it does, we should do a lot more of that. I mean that should be our baseline any time we're not sure of how something works. I've written a lot of css with various side effects, not entirely sure that I'm doing it write. Karl Dahlke _______________________________________________ Edbrowse-dev mailing list [email protected] http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
