It seems like this wouldn't help in the case when your connection has actually been compromised by an attacker because the attacker would just avoid these sensitive names.
Adam On Mar 22, 2012 1:27 PM, "Yvan Boily" <ybo...@mozilla.com> wrote: > Done. > > I agree that the "sensitive" field list could be challenging to > produce. As for the "popular" site database, I would defer to other > existing lists of top sites (Alexa top site list comes to mind). > > As for building the survey list we could probably use an add-on to > collect sanitized & anonymized data. Grabbing a list of the field names > that have matching values, and tracking a hit count for them would allow > us to see which fields are likely to be related; if we can gather just > the variable names and match count for a large set of users we should be > able to build a reasonable profile of what might constitute a > "sensitive" field. > > > On 12-03-22 1:14 PM, Sid Stamm wrote: > > Hey Yvan, > > > > Can I suggest bringing this up in dev.security? I think you'll get more > > feedback there... > > > > My take is that we could leverage this kind of info, but the set of > > "sensitive" fields will change over time and I'm not too fond of > > maintaining a database of (1) popular sites and (2) parameters that are > > "sensitive" fields on those sites. > > > > -Sid > > > > On 03/22/2012 01:12 PM, Yvan Boily wrote: > >> Shane and I were having a quick chat about privacy and security UX and > >> we ended up chatting about an interesting concept to improve the user > >> experience when a 'bad' certificate is in use (expired, self-issued, > etc) > >> > >> Firefox already maintains a database of auto-complete fields, and over > >> time a user will have a set of data that could potentially be used to > >> warn the user when they are sending 'sensitive' fields over insecure > >> channels. > >> > >> By performing a survey of large usage payment sites we could identify > >> common parameter names that are saved on major sites, then flag fields > >> such as name, address, credit card number,etc, related fields as being > >> "personal" data. > >> > >> If we did this, would it be feasible to analyze user input into DOM > >> elements and raise warnings if personal data is entered into documents > >> loaded from "bad" sites? > >> > >> I haven't spent too much time thinking about it, but fields identified > >> as personal data from the survey could be fed into a bloom filter, and > >> then user input on "bad" sites could be checked against this filter to > >> determine if there is sensitive data in it. This could help users to > >> better understand the context of our somewhat unfriendly bad certificate > >> error messages. > >> > >> Thoughts? > >> > _______________________________________________ > dev-security mailing list > dev-security@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security > _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
