W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

Re: Conventions for Sharing User Agent Profiles

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Tue, 13 Aug 96 10:24:46 MDT
Message-Id: <9608131724.AA05047@acetes.pa.dec.com>
To: Shel Kaphan <sjk@amazon.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1331
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).

Received on Tuesday, 13 August 1996 10:33:59 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:17 UTC