This all seems out of scope for the work WebAppSec is chartered for. Henry, can you please raise this in another venue.
-Ekr [As WG Chair] On Tue, Jul 17, 2012 at 1:15 PM, Henry Story <[email protected]> wrote: > > On 17 Jul 2012, at 21:32, Dirk Pranke wrote: > >> On Mon, Jul 16, 2012 at 11:22 PM, Henry Story <[email protected]> >> wrote: >>> Ok, I don't really have a browser to hack on. On the other hand a few of us >>> are working on building a CORS >>> proxy at the read-write-web community group to enable javascript linked data >>> agents to build up in the browser views of data distributed on the web. >>> There may be some interesting results this brings up that we can discuss at >>> TPAC in Lyon... :-) >> >> Building a CORS proxy for any reason other than to prototype something >> sounds (at first blush) like a bad idea; as Adam says, you're >> basically changing the security policies the web is supposed to be >> using. It seems like if you're having to do this you're solving the >> wrong problem, and maybe there's something else that should be >> changed? > > Well I have proposed to the Linked Data Profile WG today that it may be > useful for them add a use case that would take WebApps into account so as to > look at some of the issues that are brought up in this space when WebApps > interact with LinkedData. See the mail here: > > http://lists.w3.org/Archives/Public/public-ldp-wg/2012Jul/0041.html > > A lot of Linked Data providers do not support CORS (it's too new for them to > have noticed, and too far from their use cases) yet we would like to build > apps that use that data. As a result one cannot have a javascript application > as described in that e-mail do a GET on such resources using CORS alone. One > needs a proxy to get such resources. > > What I am not so clear about is whether there is any need for CORS to put > any restrictions at all on resources that are fetched with GET - since GET is > indempotent - especially when the GET request is done without any access > control at all. That would at least make a lot of public linked data > browseable without the need for a proxy using javascript. Furthermore a proxy > is so easy to build, any such public data can be found anyway, so the CORS > restriction on GET have no real effect, other than getting people to write > CORS proxies.... > > Next since I mentioned this in the e-mail to the LDP WG, let me mention this > here. I have an interesting suggestion for you on how to make it easier to > work out when one could trust a JS Origin. So what is the issue? Currently > there is a bit of a problem with the Origin header because the site receiving > a request with an Origin header may not know anything about that Origin site > at all. Currently that means it has to close the connection. But what if I > the user who logged in really trust the origin site JS? (say because it is > hosted on my FreedomBox). So lets say I have some JS on my FBox and that JS > goes to the site of a friend of mine. How can that Friend know that I trust > the JS coming from my FBox, and not trust say the JS from some other random > site? Well if I log in with WebID and the WebID Profile is hosted on my FBox, > then that seems like a good indicator that my friend should trust requests > that come from JS that has the Origin of my FBox. One could even make this > explicit with a relation in my profile such as > > > :me trustsOrigin <http://bblfish.net/> . > > > Then my friends server could have confirmation from my profile that the > origin is trustworthy. > > Of course if the JS, was signed then things could be even more easy, because > that would allow me to place signed JS on my site that I trust and we would > not have the trouble of someone maliciously uploading JS in a blog post of > mine also getting rights at the same time. That is why I thought JS signing > would be a pretty useful feature to have. > > Henry > >> >> -- Dirk > > Social Web Architect > http://bblfish.net/ > >
