Re: Rec Proposal: Separate in-browser editor for entry of Personally Identifiable Information (PII)

Hi Shawn,

> I don't want to get too mired in the technical description but...  I can
> see how this might foil a phishing "site", per se, but would it also be
> able to foil instances where a phishing form is injected via XSS into a
> trusted site?  This could happen by either injected the form code in the
> URL itself or by sourcing an external page.  For example, if a trusted
> login form is susceptible to XSS attacks, then an attacker could insert
> his own login form that would, according to the browser address bar, be
> sourced from the trusted site while posting the data elsewhere.  I
> haven't seen this too much "in the wild" so I'm really not sure if
> current anti-phishing countermeasures can address it either.

I'd like to understand a bit better what sort of thing in our scope would 
foil this.

The security context information the user would need would be either 1) 
some comparison of the "main" site and the "login form" site, or 2) some 
clear indication of the trustworthiness of the "login form" site and 
whether or not its already trusted with the PII the user is putting in. 

Sounds like the latter may in fact be covered by the PII editor Tyler 
proposes. 
        Mez