Jason S wrote:
> On Oct 30, 6:14 pm, Jonas Sicking <jo...
>> Anything else would be a security bug.
>> The reason is that website A might be behind a corporate firewall. And
>> so if website B could read this data, corporate firewalls would not work
>> if a user inside the firewall browsed sites outside the firewall.
> gack, that makes sense. (unfortunately.) So this is a firewall in the
> broadest sense? e.g. firewall F exists around computers within the
> domains paranoid-company.com and other-paranoid-company.com? Otherwise
> it seems like if websites A and B are not within the local domain
> (e.g. both outside the firewall) then there's not a security risk.
If both servers exist within the same firewall, or both outside all
firewalls, then there is no security risk no.
> Technically I don't need website B to read the data, I just want the
> client-side script for the end-user to read that data... although I
> suppose if you allow website B to be arbitrary (e.g. "evil") then I
> suppose the script could send data to website B.
Yes, once a webpage has information there are tons of ways it can
communicate that back to its home server, there is no way to prevent
that other than pulling the network plug.
> The other option you haven't mentioned, which I can do, is to have
> website B's server contact website A to issue a proxy.
> I can do that,
> the only reasons I haven't are because then my server has to carry the
> bandwidth & it adds latency; i'd prefer it if the client computer
> could get the data directly.
Yup. This is why we've added technologies such as cross-site
XMLHttpRequest and postMessage. It only works if both sites cooperate