change list for WebCore/JavaScriptCore version 60

[Trey Matteson]

--Apple-Mail-2-386636659
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed


On Friday, Feb 14, 2003, at 14:59 US/Pacific, Dirk Mueller wrote:

>> - added ways to detect pages that have password fields or are secure
>> forms so we know not to save the values in them
>
> interesting, we have that password-not-caching in HEAD, but we got a 
> lot of
> complains about this.
>
> what is the idea behind skipping the session-state saving of secure 
> forms?
> this means that upon "back" when you mistyped something in your home 
> banking
> you can start from scratch.
>
> the history is transient, when you close the window its gone.
>

Wells Fargo chose to block access via Safari when they discovered that 
the password and account name could be available via back/forward.  
Everyone here agreed we should never save/restore a password field.  In 
addition we decided to be additionally conservative as to not 
save/restore any forms that are submitted via https that contain a 
password field.  This matches WinIE (but not MacIE).

The case this protects against is someone leaving their computer 
momentarily, or leaving a session open at a public terminal, and having 
someone go back to view the account.  Accounts are sometimes social 
security numbers, which some people are sensitive about.

You can certainly make arguments for and against the value of this 
choice.  Since the size of these forms is typically only two fields, we 
decided to accept the inconvenience of retyping a field when going back 
in return for a slight reduction of security risk, and a greater level 
of acceptance by sites who are paranoid.  We are watching for strong 
user feedback that this choice is incorrect, and could possibly revisit 
it.

trey

--Apple-Mail-2-386636659
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII



On Friday, Feb 14, 2003, at 14:59 US/Pacific, Dirk Mueller wrote:


<excerpt><excerpt><fixed>- added ways to detect pages that have
password fields or are secure 

forms so we know not to save the values in them

</fixed></excerpt><fixed>

interesting, we have that password-not-caching in HEAD, but we got a
lot of 

complains about this. 


what is the idea behind skipping the session-state saving of secure
forms?

this means that upon "back" when you mistyped something in your home
banking 

you can start from scratch. 


the history is transient, when you close the window its gone. 


</fixed></excerpt>

Wells Fargo chose to block access via Safari when they discovered that
the password and account name could be available via back/forward. 
Everyone here agreed we should never save/restore a password field. 
In addition we decided to be additionally conservative as to not
save/restore any forms that are submitted via https that contain a
password field.  This matches WinIE (but not MacIE).


The case this protects against is someone leaving their computer
momentarily, or leaving a session open at a public terminal, and
having someone go back to view the account.  Accounts are sometimes
social security numbers, which some people are sensitive about.


You can certainly make arguments for and against the value of this
choice.  Since the size of these forms is typically only two fields,
we decided to accept the inconvenience of retyping a field when going
back in return for a slight reduction of security risk, and a greater
level of acceptance by sites who are paranoid.  We are watching for
strong user feedback that this choice is incorrect, and could possibly
revisit it.


trey


--Apple-Mail-2-386636659--