* Anne van Kesteren wrote: > http://www.w3.org/TR/from-origin/
The proposed `From-Origin` header conveys a subset of the information that is already available through the Referer header. As it is, it is very rare for the Referer header, or coressponding interfaces that are available to scripts, to be absent and the draft does not even attempt to argue how the reasons for the Referer header's abscence don't apply to `From-Origin`. It also lacks a description of the problem domain. As an example, it is unclear that there are important use cases that require telling a.example.com apart from b.example.com (assuming that example.com is a "public suffix" while the subdomains are not). That's important if one were to design the mechanism where it's easy for a site to verify if the "from-origin" is acceptable, but hard to learn the actual "from-origin" when it is not. (Consider as a trivial example you send the MD5 of the "from-origin" instead of the actual value: verification would be easy, but learning the actual value would require to go through a possibly long list of possible origins; of course, brute force against MD5 is trivial, and if you use the "whole origin" you couldn't check for "*.example.com", without trying all possibilities for the wildcard, but cryptography offers other options, and knowing constraints is important to find and evaluate them.) Similarily, it is unclear whether there is actually an important need to know more than "same 'public suffix'" if "Referer" is there anyway most of the time (you can obviously make up examples to illustrate a difference, but there are usually design alternatives that render such examples unimportant). Clearly "Referer" information would be available more often if there had always been a policy to only strip path and query information in- stead of stripping it entirely, and the only difference between such a policy and the proposed header -- assuming the idea is that it'd be available 'always' -- that there wasn't such a policy. But that is about all there is to this proposal at the moment, and I don't find that very convincing. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
