- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 09 Jun 2010 14:34:10 +0200
- To: Anne van Kesteren <annevk@opera.com>
- CC: HTTP Working Group <ietf-http-wg@w3.org>, Bil Corry <bil@corry.biz>, "Yngve N. Pettersen (Developer Opera Software ASA)" <yngve@opera.com>, Michal Zalewski <lcamtuf@google.com>, Jeff Hodges <Jeff.Hodges@kingsmountain.com>, Adam Barth <ietf@adambarth.com>
On 09.06.2010 08:31, Anne van Kesteren wrote: > On Wed, 09 Jun 2010 02:48:20 +0200, Yngve N. Pettersen (Developer Opera > Software ASA) <yngve@opera.com> wrote: >> Well, there is actually a fourth choice: Ask the user (Yes, I know, >> the user will most likely know just as little as the client about what >> those header were intended to mean, and the opportunities for social >> engineering attacks will be legion). > > There's also a fifth. Based on implementation experience we can probably > figure out what the scenario for headers should be. You might end up > with special cases, but at least you know it can be implemented and you > can give advice for future clients so they will no longer have to > reverse engineer the market leader. As far as I can tell from the data Bill provided, there is no general agreement on how this needs to be done. That being said; a document explaining that widely-used UAs do, and also pointing out potential security problems would be a good thing to have. I just do not see why this would need to be part of the protocol definition. Best regards, Julian
Received on Wednesday, 9 June 2010 12:34:48 UTC