- From: Anne van Kesteren <annevk@opera.com>
- Date: Tue, 19 Feb 2008 10:10:52 +0100
- To: "Collin Jackson" <collinj@cs.stanford.edu>, public-webapi@w3.org
- Cc: "Adam Barth" <abarth@cs.stanford.edu>
On Tue, 19 Feb 2008 02:21:31 +0100, Collin Jackson <collinj@cs.stanford.edu> wrote: > Approach 1: Create a prefix denoting headers that are determined by > the user agent and cannot be overwritten by unprivileged JavaScript. > For example, "UA-" or "Sec-". This is the approach we prefer. Given that older clients and malicious clients will be vulnarable why is that not a problem going forward? I'm fine with doing this though. > [...] but under the current > specification we'd have to chose a header name that starts with > "Proxy-". There have been many other proposals for new > security-related HTTP headers (e.g. content restrictions) so it would > be nice to solve this issue in general. Comments like this do encourage me to introduce "Sec-" so we don't get a whole bunch of fake "Proxy-" headers. (Note that not all clients blaclist everything "Proxy-" yet.) > Another related issue that would be good to standardize is the > handling of the Cookie header. Internet Explorer 6 and 7 doesn't > appear to allow Cookies to be set using XMLHttpRequest at all. Firefox > 2 allows pages to use XMLHttpRequest to set a Cookie header, but > merges the user-set header with the user agent header: > > Cookie: [actual cookies values]; [user-set Cookie header value] > > I've heard some arguments for removing Cookies from cross-site > XMLHttpRequests, which indicates to me that the Cookie header might be > a good candidate for adding to the security-sensitive list. What are those arguments? -- Anne van Kesteren <http://annevankesteren.nl/> <http://www.opera.com/>
Received on Tuesday, 19 February 2008 09:06:39 UTC