- From: Sigbjørn Vik <sigbjorn@opera.com>
- Date: Tue, 20 May 2014 14:55:24 +0200
- To: Mike West <mkwst@google.com>, Joel Weinberger <jww@chromium.org>
- CC: "Oda, Terri" <terri.oda@intel.com>, Michal Zalewski <lcamtuf@coredump.cx>, Dan Veditz <dveditz@mozilla.com>, Egor Homakov <homakov@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Eduardo' Vela <evn@google.com>
On 16-May-14 09:19, Mike West wrote: > I've (finally) put up a proposal based on this > discussion: https://github.com/w3c/webappsec/pull/18 Great to see that we are still moving forward on this, this proposal certainly is better than what we have today. :) For the sake of playing the devil's advocate, why limit ourselves to HTTP redirects? Certainly meta http-equiv redirects should be treated the same way. What about various JS redirects? Both the algorithm and the discussion should probably use the same language, to make it explicitly clear what is being considered. (Currently algorithm says "HTTP redirect" and discussion says "redirect".) For the record, I am still opposed to this solution. I'll quickly recap my objections against it: * It doesn't resolve redirection login detection, which may add a new security hole to previously secure sites, one against which sites cannot protect themselves. * It thus adds an unfixable security issue for the foreseeable future for all web sites. This might theoretically hinder the web moving forwards in the future. * It doesn't fully support the path construct (doesn't work after redirects). * It is confusing and complex for webmasters (and as they vastly outnumber browser developers, it is the most confusing and complex solution overall). * It provides a false sense of security to webmasters. A webmaster might accidentally open a hole when trying to tighten security, or an unrelated change elsewhere (e.g. changes to use a redirect) might render a site insecure. -- Sigbjørn Vik Opera Software
Received on Tuesday, 20 May 2014 12:55:54 UTC