Yes, but as someone said "Stop letting the perfect be the enemy of the useful."
I think it needs to be measured what is the usefulness of this feature. How many attacks would we protect against? (not just possible vulnerabilities) There is a certain loss in implementing this feature because of the creep factor. You would essentially make it easier to malware to exfiltrate sensitive data: instead of writing the code to detect when user is typing sensitive data, the malware could just look at the db you use. =dev On 22 March 2012 14:05, Adam Barth <abarth-mozi...@adambarth.com> wrote: > The attacker will just watch for keydown events and exfiltrate the > data as the user types. Once you can detect a problem, the harm is > already done. > > Adam > > > On Thu, Mar 22, 2012 at 1:51 PM, Yvan Boily <ybo...@mozilla.com> wrote: >> I think I didn't explain it clearly. >> >> We would use the field names in our analysis to nominate a set of fields >> that are considered to contain sensitive data. The browser would acquire a >> list of these fields through an update process, or ship with it. Through >> normal usage the form history list will get filled out. When a form history >> field is added that matches the list, the value of that field is added to >> the filter to flag the data as sensitive. When a user enters data on a >> site that matches the "sensitive" filter the user would be notified that >> there is an untrustworthy site asking for potentially sensitive data. >> >> Make more sense? >> >> >> On 12-03-22 1:46 PM, Adam Barth wrote: >> >> 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 _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
