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