Re: Automatic Entry and Forms

Before I respond to the technical content -- my tuppence on the privacy
digression.  [In retrospect whilst proof reading -- I find my choice
-- "digression" -- interesting. Maintaining privacy is a large part of 
the technical challenge with this task. I shouldn't underestimate
that.]

Privacy : 

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.

Imagine a form that has a large number of trailing <BR>'s before a TEXT
(not HIDDEN) input field. Can a browser guarantee that the user has
scrolled so far down and verified that they wish the data sent? What if
a form has set the color of the text to that of the background? What if
a form has wads of text that disguise a TEXT field as input.....

I see no way to automatically determine if a user wishes their data to
be transferred to a site. Yes - they may be free with their data for 
one site -- and maybe for many -- but maybe not for all.

Even if we make it so that the underlying HTML supports the browser in
the aim of automatically filling fields *once* the user has decided it
is OK -- are we not making it a little too easy? Too easy to overlook
risk and not consider the personal impacts of transfering that data to 
this site. 

I won't dwell further on this -- becuase I know I would use this
capability -- however I respect Robert's concerns.

Technical :

On Fri, 23 Feb 1996, Daniel W. Connolly wrote:

> >
> >I would make a recommendation: make it an registration scheme (possibly
> >through IANA), where a registered field name would be accompanied with a
> >text description. If the form designer agreed that the text description
> >matched the input requirement, they'd use the registered field name.
> 
> 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. 

Further -- I don't see that the template mechanism is significantly
different from that of having unique names. (see below)
 
> 
> Hmmm... now I see why you need more
> than one template=... address. Perhaps individual form input elements,
> as well as the <form> container, need the template= attribute.
> 
Quite. This confirms that the template mechanism is just an extended
form of unqiue data item naming. Each data item needs to be uniquely 
addressible. This is distinguishable from a global naming scheme only
in the anarchy it allows and little more.

Consider IP numbers. Within intercommunicating groups we readily agree
that a central registary is key. Is this not just another example of
where a DNS-like solution is viable? [Note: I do not propose this as
a technical solution -- I am not expert enough and it would probably be
somewhat overkill. I use it as an example of where a central registry
is important.]

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.)

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.

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". 

Adam
--
+1-203-730-5437 | http://www.micrognosis.com/~ajack/index.html

Received on Sunday, 25 February 1996 14:29:10 UTC