Re: Automatic Entry and Forms

   From: Adam Jack <ajack@corp.micrognosis.com>
|   I believe that unless we have a user authorize each item of data on
|   a per URL basis, if only once per data item, then we will be opening
|   a large privacy leak -- however unitentionally.
---

I guess I'd like to see the browser associate a privilege level with
each datum it caches.  Authorization would not be required for data the
user indicated to require no privilege.  For my own use, this would
include everything I have ever filled in in a form (I haven't used a
credit card number with a form, yet).  I guess I would then add an ACL
mechanism to grant specific privilages to specific domains.

Sending privileged data to an unprivileged site would require a specific
prompt and verification.

---
|   > 
|   > Ack! Good heavens, no! Phil's idea to use URIs to name templates
|   > disintermediates so nicely. No need for a central registry.
|   >
|   I think the Ack is a little strong -- and, myself not having a soln
|   other than I have expressed before w/ the learning browser, I am
|   beginning to see this as close to optimal. 
---

The template mechanism appears to allow you to have a distributed,
self-managing registry of names.  It looks pretty sensible to me.  You
could handle the core standard names by using the defining IETF document
as the template.

---
|...
|   I am no expert on naming schemes however I wonder whether a group (URI) 
|   plus tag (field name) mechanism is as good as the more typical 
|   XXXX.YYYY.ZZZZ hierarchy. Surely, as was suggested in an earlier 
|   thread, the style sheet value mechanism might present a more functional 
|   model. (E.g. we could then consider functionality like allowing
|   information XXXX.YYYY.* to site AAAAA but not site BBBBB. We could
|   also consider user group (organisation) defaults not just user
|   defaults.)
---

I suggested an access control mechanism above.  At any rate, the access
control mechanism has to be in the browser and the field value cache,
not in the naming mechanism.  The user's level of concern about each
value has to be controlled on the user's side, not implied by the name
of the field or its defining agency.

---
|
|   As well as privacy issues we have to remember the practical issues.
|   The form author needs to track down the correct field name to use
|   when they create the form.  If the "template" mechanism were in place, 
|   with no registry, this task might be prohibitive. The theoretical benefits 
|   of flexibility could easily be outweighed.
---

Again, I think the "core" names would migrate up to one, or a few,
defining standard templates, and most other names would be on a single
form or single site basis, so I don't think naming would really be that
ugly.

|   I do not believe that any mechanism will solve all requirements in this
|   area. Given that -- I would prefer to see a situation were a few hundred
|   fields were centrally maintained, and universally recognized, than have
|   a fragmented system like that of the "templates". 
---

I concur with the wish to see that core set of standardized names, but I
think the "template" mechanism is a very attractive way of managing the
standard set.

scott

--
scott preece
motorola/mcg urbana design center	1101 e. university, urbana, il   61801
phone:	217-384-8589			  fax:	217-384-8550
internet mail:	preece@urbana.mcd.mot.com

Received on Monday, 26 February 1996 10:21:32 UTC