- From: Shel Kaphan <sjk@amazon.com>
- Date: Tue, 13 Aug 1996 18:58:55 -0700 (PDT)
- To: Jeffrey Mogul <mogul@pa.dec.com>
- Cc: Shel Kaphan <sjk@amazon.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Jeffrey Mogul writes: > 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. > ... > 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 > > Your connectivity points are well taken. At this point the combination that sounds best to me is, as you suggest, a way to get the server to return something to the browser that says, in effect, "once more, with your profile". Then we'd need a DNS extension to identify a set of servers on which browser profiles are kept, so that browsers could find a copy of their profile from some server that caches profiles. These servers might just as well be http servers. Is this just too much infrastructure for this to ever really work? How else could the browser stay appraised of up-to-date versions of its own profile? I think much of the point of the exercise would be lost if the browser just spits back a canned profile that was built in when the browser was released. If things were set up in this manner, it would be possible for a fully connected http server to query the profile server itself and not do the redirection, if it was so configured, or to use the redirect method if it weren't. It would be possible (and so, probably inevitable) for browsers to cheat and just send a canned profile if they got such a redirection response. Also, the bit about the signing of the profiles might need a little thought, because it isn't necessarily the vendor that you want to have being responsible for the profile. Vendors might be less likely to note bugs or count them as worth including. --Shel
Received on Tuesday, 13 August 1996 19:00:23 UTC