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 [email protected] https://lists.mozilla.org/listinfo/dev-security
