I believe most of us agree that there are security issues involved in automatically filling in form

I believe most of us agree that there are security issues involved in automatically filling in form fields. I suggest we
concretely identify them so we can decide which can be dealt with and which simply have to be acknowledged as
inevitable.

Overview:
The two semi-formal proposals I'm aware of (from Phill Hallam and from me) and almost all subsequent discussions
concern a standard to enable user agents (browsers) to automatically fill in certain fields on a form. After the
agent displays the form, the user can do one of two things: 1) not submit the form, 2) change or erase filled-in
fields (and fill in any additional fields by hand) before submitting the form. All information is stored on the client side,
no information should be submitted without the user's permission.

Security issues:

1) Privacy of information
(keywords: Napoleon, probe, pernicious, insidious, unscrupulous, laughing-all-the-way-to-the-bank) 
Some people believe private information should not be made available in a standard way because of the potential
for abuse. The seriousness of this concern depends on the mechanism of the standard and the implementations of
the mechanism (one browser might ask permission before storing any information typed into fields and before
submitting a form with fields which it filled in automatically, while another browser might cache and fill in fields
without user intervention or permission).

2) Unscrupulous agents
User agents could be written that would purposely transmit private information without the user's knowledge.

3) Faulty agents
Bugs or incorrect implementations of HTML could compromise information. For example, hidden fields could be filled
in without the user knowing. The standard won't allow this, but we can't guarantee that user agents will correctly
follow the standard. 

4) Unscrupulous HTML
Clever HTML authors could purposely design a page to hide or obscure a field so the user is unaware the field is
there (colored text on a similarly colored background, lots of blank lines, etc.).

5) Unscrupulous applets
Java/JavaScript/VBScript/OCXs/OpenDoc parts/etc. may have methods to submit a form programmatically. This is
technically a security deficiency of these languages or objects, not of HTML, and should be addressed by the
respective developers. (Agents could ameliorate the problem with a dialog verifying submission of forms with
auto-filled fields, but that's far from a complete solution.)

6) Accessibility of stored information
User information will be stored on the client system. It would be possible for some sneaky application to read and
transmit it without the user's knowledge. This is no different than private information already stored by the OS or
other applications, except that the information might be more extensive and would all be centralized in one data
store.

7...) Anything else...?

Other points:
- Any CGI script can get the user's IP address from an HTTP header. Many sites are collecting demographic data
without the user realizing the extent of information collected. User agents could be (and have been) written to
extract and store data entered in a form. The potential for abuse already exists. The proposal for a standardized
field naming scheme doesn't increase the this potential; but it has at least 2 dangers that I can see: 1) it will make
that potential more apparent, and 2) as user agenst begin to support the standard, more HTML authors and
Webmasters will search for ways to pervert it. On the other hand, having a standard (as opposed to browser
developers adding their own non-standard fill-in options -- which would be inevitable otherwise) means that
application of the standard and concomitant violations will be easier to monitor.

-Some information is more sensitive than other information. No one seems too worried about a browser filling in
their name and e-mail, but people have a right to worry about a browser filling in their credit card or other private
information if there is a chance that the information could be released without permission. The standard could
employ a scheme (as suggested by Scott Preece) where part of the hierarchy of field identification indicates the
level of desired security. User agents could have some sort of confirmation dialog or permission preference to
control which groups of fields would be filled in. Again, as with hidden fields, there's no guarantee that agents will
conform.

-HTML is used for intranets as well as the Internet. Privacy issues, as well as the scope and type of information
requested on forms, are different in these environments.

-Even if this idea is merged with those for demographics and authentication, the above issues are still relevant
since the form-filling mechanism would remain. However, dozens of new issues raise their ugly heads (such as
control over information sent via HTTP, more opportunities for user agents to be unsrupulous, SMGL entity
replacement making user information even more available to scripts and applets and also making the information
more hideable, to name just a few).

_____________________________________
Jim Taylor, Director of Information Technology
<mailto:jhtaylor@videodiscovery.com>
Videodiscovery, Inc. - Multimedia Education for Science and Math
Seattle, WA, 206-285-5400 <http://www.videodiscovery.com/vdyweb>

Received on Wednesday, 28 February 1996 22:43:26 UTC