- From: David W. Morris <dwm@shell.portal.com>
- Date: Wed, 14 Aug 1996 17:38:56 -0700 (PDT)
- To: http working group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
On Wed, 14 Aug 1996, Jeffrey Mogul wrote: > 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. > > The vendor is an obvious choice, both because the browser vendor > has an obvious incentive to keep the user relatively happy (at I'll say it again... vendors have already demonstrated they don't rate the trust to be designed in as the sole source of the profile information. One well known vendor was statistically sampling bug reports 1-1/2 years ago. What they are doing now, I haven't heard but as an ISV I can't tolerate a solution which leaves my customers wondering if the profile will be maintained. > least, until the browser market is back to being dominated by > a single vendor!) and because if you don't trust the vendor > who gave you the browser binary in the first place, you can't > really trust anything done with a browser profile. There is trust where intent is involved and there is trust where the issue of things falling thru the cracks is involved. I am not suggesting evil intent ... a bug is a bug. Furthermore, the original suggestion did not involved the browser at all and a solution only need depend on the browser correctly and uniquely identifying its identity. Some other collaborative repository owned by the content suppliers can provide the actual data base ... or the effective profile can be a compendium of multiple sources. If we work on this issue, it needs to address coding and precedence for merging first. Storage and exchange is a secondary issue. Dave Morris
Received on Wednesday, 14 August 1996 17:44:31 UTC