Closed Bug 190700 Opened 22 years ago Closed 21 years ago

Form autocomplete should be disabled for https (ssl, secure) pages

Categories

(Toolkit :: Form Manager, enhancement)

Product:
Toolkit
Component:
Form Manager
Platform:
x86
All
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: marksmithurbana, Assigned: hewitt)

References

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5

This is a serious security hole for phoenix running on a multi-user machine. 
Imagine for example, you submit your credit card information to a site.  In
other browsers (at least mozilla & IE), the auto complete values for these
fields are not stored - in phoenix, they are.

Reproducible: Always

Steps to Reproduce:
1.Read details
2.
3.
Actual Results:  
Read details

Expected Results:  
Read details

Read details
Phoenix 20030207/Linux tries to complete https URLs and stores them in the
history. But I noticed that Opera6 does as well... I'm not a security expert,
but I don't see the harm in storing https URLs, you still, hopefully, have to
login to sites like Amazon that accept your credit card info. Just because the
URL is remembered doesn't mean you can get anything else from the browser about
the transaction. I'm leaving as unconfirmed at the moment...
No, it's not autocomplete of URLs that is the issue.  It's autocomplete of form
fill-in values from HTTPs pages that is the security issue.  Sorry for the lack
of clarity in my initial posting ;)
does the autocomplete stuff work if another OS user is using Phoenix? I don't
think so because the autocomplete information should be stored in user's profile
which can't be accessed by another OS user (by default)..
While it may be true that the data is stored in the user's profile, any
administrator with the slightest knowledge would easily be able to access the
autocomplete data.  In my opinion, it would just be much more secure to disable
Satchel on https pages.  Coupled with the fact that there is still no way to
delete a single entry in Satchel, this can be an issue when entering credit card
numbers, social security numbers, etc.

This should not be marked as UNCONFIRMED, but instead as an RFE.
OS -> All
-> Enhancement

Confirming for developer review.
Severity: major → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
This is a bit heavy handed. I'm going to mark this as "WONTFIX" and refer you to
bug 201850 (Autocomplete Fun) where there exists a patch to make autocomplete
not operate on fields where the site author specifies autocomplete="true" (the
de facto standard autocomplete blocking attribute) which commerce sites tend to
use for sensitive fields such as CC.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WONTFIX
Taking QA and mass verification of dupe, invalid and wontfix autocomplete bugs.
Sorry for the bugspam.
Status: RESOLVED → VERIFIED
QA Contact: asa → davidpjames
*** Bug 237021 has been marked as a duplicate of this bug. ***
*** Bug 271176 has been marked as a duplicate of this bug. ***
*** Bug 257455 has been marked as a duplicate of this bug. ***
*** Bug 274988 has been marked as a duplicate of this bug. ***
*** Bug 302871 has been marked as a duplicate of this bug. ***
See also bug 252486, for making this a pref.
*** Bug 223214 has been marked as a duplicate of this bug. ***
*** Bug 356145 has been marked as a duplicate of this bug. ***
See also bug 188285, which asks for heuristics to keep Firefox from storing credit card numbers.
Component: Location Bar and Autocomplete → Form Manager
Summary: Auto complete should be disabled for https (ssl) secure pages → Form autocomplete should be disabled for https (ssl, secure) pages
In reply to bug 188285 comment 47:

> You don't need to trust sites to turn off autocompletion. We already have a
> condition which alerts us to the presence of sensitive data - SSL.

SSL indicates authentication and encryption, not the presence of sensitive data.  While sensitive data is usually entered into pages that use SSL, many sites use SSL for less sensitive data.  We should not discourage those sites from using SSL.

bugzilla.mozilla.org is an example.  It uses SSL for everything, since it contains some of the most sensitive data on the Web, but it also contains a large amount of non-sensitive data.  Without autocomplete for things like bug numbers and attachment MIME types, Bugzilla would be a lot more frustrating to use.
You're right. I wouldn't want anyone to have to type in a bug number by hand when that would cause Firefox not to store credit card numbers, PIN numbers, banking information, or anything like that.
I agree with Jesse, it's not usefull to be restricted with all the SSL sites. With the form attribute autocomplete="off" you can disable the autocomplition. It's like the same as you say to every webdesigner they have to make there website accessibly for everyone. It's the responsibility of every webdesinger if he add this attribute where you fill in some sensitive datas.
In reply to comment 19:
>With the form attribute autocomplete="off" you can disable the autocomplition.

In reply to comment 6:
>...there exists a patch to make autocomplete not operate on fields where the
>site author specifies autocomplete="true"....

The problem is that many sites don't do this, and the user is not only unprotected but usually clueless.


In reply to bug 188235 comment 47:
> You don't need to trust sites to turn off autocompletion. We already have a
> condition which alerts us to the presence of sensitive data - SSL.

I just checked with Bugzilla, and autocompletion works fine with SSL.
Is this "autocomplete" attribute part of an (X)HTML specification? I don't believe that it is. Offloading user security from a single potential failure point (Mozilla) to millions (each individual Web site) is irresponsible. Not only that, but implementing a feature with potential security risks and then telling Web developers that it's their responsibility to work around Mozilla's disregard for the security of users' data (with non-standard HTML at that) is just wrong. I have no delusions that Mozilla is going to do the right thing, I'm just pointing out that it isn't right and why.

VanillaMozilla: Of course it works with SSL ... that's the problem.
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.