- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Tue, 13 Aug 96 10:24:46 MDT
- To: Shel Kaphan <sjk@amazon.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Shel writes:
The problem with [Simon's] approach is that oddities of particular
browsers may not exist in a hard coded database built into the
browser itself at the time it is released, but may only be
recognized by third parties, after the fact. The
UA-characteristics database should be independent of the UA
itself. I'm assuming here that this database may contain fine
detail about UA behavior that may even include bugs noticed long
after the release.
I know Shel has had to fight the real-world battle against the attack
of the evil browsers, but I'm not sure I would be quite as gloomy
about a UA-provided UA-profile.
Even if the UA vendor manages to botch the UA-profile setting when
the browser is released, it should not take a great deal of imagination
to design in a mechanism for updating the UA's idea of its profile
to reflect reality. Simple applications of public-key signatures
should prevent any nasty security implications. For example, whenever
your server believes that the UA-profile is wrong, it sends a Redirect
to a URL that causes the browser to download and update its stored
UA-profile, but only if the public-key signature is correct and only
if the included timestamp is newer than the stored one.
This is just an off-the-cuff idea, but it seems to avoid the requirement
for complete connectivity (because the server could obtain a signed
UA-profile from the UA vendor and mirror it locally).
-Jeff
Received on Tuesday, 13 August 1996 10:33:59 UTC