On 6/30/12 10:01 AM, secguard...@yandex.com wrote:
>> To clear things up completely: this is an addition to the existing
>> SafeBrowsing feature in Firefox.  This feature augments what the current
>> one can detect, but will involve sending out URLs in pings.
>>
>> Based on Moheeb's reply (in this thread), I think we should move ahead
>> with implementing this for our windows users.  It seems to me, and
>> please chime in if I'm out of line here, that we should:
>>
>> 1.  Stand up a proxy that handles both pings and list updates.
> 
> Perhaps I didn't get it right. Is there a difference (e.g. updated more
> frequently or region specific) between this whitelist and the
> safebrowsing list? If there is only one current whitelist at time
> delivered to all clients, mozilla can host this list instead of being a
> proxy. Wouldn't that be more efficient?

This is a separate list from the current safebrowsing list.  The current
SafeBrowsing list is huge, and we do chunked updates.  The proposed
feature has a small whitelist of domains and hashes that are "known good".

And you're right: we would not simply proxy requests for the whitelist
updates, we would actually cache and re-host it.

>> ** This proxy would strip the last octet out of IP addresses for pings
> 
> I'm not an expert here, but would that be sufficient for IPv6?
> 
> What about the "browsers fingerprint" (user agent etc.)? Will this kind
> of informations be stored by mozilla and/or be transmitted to google?

No.  We would just send the regular information in the ping (URL,
filesize, hash) along with the IP/24.  If there are cases where the
client is not waiting on a reply from the ping, we could even batch
submit them, but as far as I know the client waits on a ping result.

> Personally, I still prefer opt-in.

The privacy purist in me says the same, but we want to weigh the number
of pings (potential privacy invasion) with the chance that bad binaries
are detected.  For people who download very common things (Adobe Reader
updates, etc), pings will not be frequent.  For those who download
uncommon things, my hunch (yeah, not science) is that they are more
likely to download malware and will benefit more from this feature.  So
it follows that the people with a higher risk profile will benefit most
from the feature and those with a lower risk profile won't generate pings.

>> ** Firefox then pings us (the proxy) instead of Google directly
>> 2.  Explore tying in other reputation systems via the proxy
>> 3.  Document the endpoints in detail so users/enterprises can select to
>> use Google directly (probably via about:config prefs) or choose an
>> alternate reputation service provider.
> 
> +1
> 
> But in order to disable the application reputation system (ARS) there
> will be an additional checkbox in preferences => security ?

Probably.  Something like "[x] Check downloads for malware"?  I'm not
sure the exact wording, but it would be right under the phishing/malware
checkboxes.

> Can a user decide, by enabling checkboxes, to only use the whitelist
> part of the system ans disable the "sending URL" part?

Probably not.  Moheeb can probably talk more on this point, but I
believe to maintain the reputation system, Google wants all participants
who use the list to ping them for things not on the list.

> Something like this:
> 
> (x) Safebrowsing
> (x) Application Reputation System  (daily updated local whitelist only)
>      ( )Allow additional queries
>               ( ) to <provider> via mozilla  (proxy)
>               ( ) directly to <provider>
> 
> If there are different ARS providers, <provider> could be a dropdown-menu?

Maybe in the future.  For now, we should implement it like safebrowsing
(you can change about:config prefs to set the endpoints, or use an
add-on).  We can explore implementing something similar to the search
plugin system with a drop-down in the Security preferences dialog, but
so we can get our users some benefit more quickly I don't think we
should scope it for v1.

> I think the user should be informed, if and what steps are taken, e. g.
> with a text in the download history for each file.

This is a good idea.  I will add it to the feature page.

> examples:
> 
> a. ARS not applicable    (no executable file)
> a. ARS disabled          (binary not checked)
> b. binary whitelisted from <provider> on <date of last whitelist update>
> c. binary checked on <date> after ping to <provider> (via mozilla)
> 
> 
> 
> Quoting part of my own mail from June, the 13th:
> 
> "Google or anybody who gets exclusively informations about the "download
> behavior" of millions of users can at least use this advantage to
> redirect its resources in software development or marketing money to
> hold down emerging competitors. Is mozilla willing to assist?"

I am not an attorney and can't comment on anything regarding antitrust
or law in general.  But from a privacy perspective I see your concern
here and think it is crucial that any agreement we have with Google for
the use of this service limits use of the data they collect from Firefox
users; specifically, I think we should deploy this in Firefox if they
only use information they collect to improve the ARS and not their other
products.

-Sid

> This issue has not been considered yet. Aren't there implications
> regarding to competition/antitrust law? Only changing IP adresses
> doesn't help here.
> A question to the professionals: How likely are other competitive ARS
> service providers besides google in the future?
> 
>> Sound good?
>>
>> -Sid
>>
> 
> All the best.
> 
> user s.
> 
> [snip]

_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security

Reply via email to