AV-Comparatives - Data transmission in Internet security products

Discussion in 'other anti-virus software' started by Petrovic, Apr 29, 2014.

  1. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    14,881
    Location:
    Slovenia, EU
    @fax For me it's really simple. If they don't need this information to protect my system they shouldn't collect it. It's just as simple as that.
     
  2. oliverjia

    oliverjia Registered Member

    Joined:
    Jul 21, 2005
    Posts:
    1,926
    The loads of porn on your HDD will be stolen by the AV company, lol

     
  3. RejZoR

    RejZoR Lurker

    Joined:
    May 31, 2004
    Posts:
    6,426
    Considering how avast! is receiving updates (pushed updates), i think local IP is also necessary, for situations with multiple avast! installs on the same local network. Otherwise i'm not sure how if it could even work.
     
  4. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    14,881
    Location:
    Slovenia, EU
    That doesn't seem right. How does server push updates to local computer? Do you have to open specific port in router and forward it to local IP to get those updates? Does Avast run as server on local machines? If not, then request for update must come from local AV installation. In that case they don't need to know local IP - router knows where to send those packets. Or am I wrong?
     
  5. fax

    fax Registered Member

    Joined:
    May 30, 2005
    Posts:
    3,899
    Location:
    localhost
    How can you say that they don't need it? Simply something we cannot know unless we have developed the software. For example, knowing which IP is used (internet or router) already give useful information to developers to troubleshoot connection problems.
     
  6. fax

    fax Registered Member

    Joined:
    May 30, 2005
    Posts:
    3,899
    Location:
    localhost
    Yeap, sound correct.
     
  7. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    14,881
    Location:
    Slovenia, EU
    Yes, you're right, I don't know if that data can help them protect my system better or not. And I probably will never know. I just don't like the idea of AV vendor collecting all kind of unneeded data and putting it at risk. Antivirus usually runs with highest privileges and it also monitors more or less every action you make (programs you run, webpages you visit...). IMO all data collected should be sanitized and anonymized as soon as possible.
    To be frank this test is raising more questions than giving the answers.
     
  8. xxJackxx

    xxJackxx Registered Member

    Joined:
    Oct 23, 2008
    Posts:
    8,625
    Location:
    USA
    I don't develop their software but I do develop software. I have also been a network admin for the last 9 years. I guarantee they do not need to collect it.
     
  9. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    Use VirusTotal Uploader and have peace of mind. :D
     
  10. ance

    ance formerly: fmon

    Joined:
    May 5, 2013
    Posts:
    1,360
    I second that! :thumb:
     
  11. MaJaRe

    MaJaRe Registered Member

    Joined:
    May 4, 2014
    Posts:
    5
    Agree on that as well.

    As for what would be sensible to collect and send:
    • For updating:
      • License information
      • Some hashed machine ID for the OS its installed on.
    • For Cloud verification:
      • File extension
      • File size
      • 1 or 2 hashes (with 1 hash there is a very small chance that 2 files can have the same hash, even with same size file)
      • Optional: If file has not been encountered yet and is deemed a risk: upload ONLY after ASKING the user for that particular file.
    • For Web security:
    And maybe some other things, as I'm not fully aware on what/how such information is used.

    I see no reason to collect information about my hardware, operating system, login names, event/errorlogs, installed applications, public and/or private IP's, complete URL's, documents, any other personally identifiable information etc.
    For my personal hardware/software: the local software should be dealing with that. Nobody's business what software I have installed.

    The questionaire did not ask for SPECIFIC information about their users, so there is no valid reason to not answer it. For no privacy of any individual is breached by answering if they collect such data (they didn't have to provide the data itself, only if they where collecting it). However, collecting such data may be against EU laws, and I think that was the crux there.
     
  12. Victek

    Victek Registered Member

    Joined:
    Nov 30, 2007
    Posts:
    6,219
    Location:
    USA
    Agreed that "not having anything to hide so no worries" is ignoring the reality of all the snooping that goes on and the fact that privacy can be violated without justification. I understand that if (as you describe) enough effort is made people can piece together a lot identifying information about personal computer use, but if they are coming after you isn't knowing the public IP which in turn identifies the ISP enough? If the ISP is forced to disclose personal information about customers and monitor their online usage patterns why bother doing the extra work of retrieving the private IP, etc? In any case it seems best to use a VPN to alleviate concerns about privacy since there is potentially more anonymity.
     
  13. MaJaRe

    MaJaRe Registered Member

    Joined:
    May 4, 2014
    Posts:
    5
    I do not consider VPN's a "security" measure. more a detriment of it tbh. A lot of VPN's / proxies are just honeypots. Various have been set up by the wrong parties and can find all kinds of things by just looking into the traffic and its destinations about the users of it. Sure, it will be good for your anonymity vs the site you want to do such with, but its at the cost of less security imo. If I'd want one, I'd probably set a server up myself in a cloud somewhere or rent a server etc, and make my VPN to that for that time I would need it. So far I didn't see the need.
     
  14. xxJackxx

    xxJackxx Registered Member

    Joined:
    Oct 23, 2008
    Posts:
    8,625
    Location:
    USA
    If you have only one device, maybe the public IP is enough. If you have multiple devices with multiple people using them, then it just got a lot harder to tie a particular device to you. When you add the internal IP, you just pinpointed that device. DHCP on the router will not help, as they almost always assign the same IP to the same device each time. It's a matter of them invading my private network and uploading information they have no justification to take. Where does it end? I don't know how much it matters though. They are probably also gathering the Mac ID from your NIC too.
     
  15. MaJaRe

    MaJaRe Registered Member

    Joined:
    May 4, 2014
    Posts:
    5
    None of that sort of information is relevant, so it makes it curious to as why they would record so much data. Also, what in regards to their EULA's... often those are pretty vague on what exact data is been extracted from the user. Its all in "generic" terms of what data is extracted, and most often nothing as to why that specific data was needed also. I do think that that is not of the current age anymore. By being a security minded coorporation it should be their first concern, instead of making off of it.

    I'm pretty glad that AV-C has put this on the agenda. For in the end, if some is achieved with this, it will have effect on other applications too.
     
  16. IBK

    IBK AV Expert

    Joined:
    Dec 22, 2003
    Posts:
    1,886
    Location:
    Innsbruck (Austria)
  17. TheWindBringeth

    TheWindBringeth Registered Member

    Joined:
    Feb 29, 2012
    Posts:
    2,171
    I don't know that it is correct to say that most do it that way, but your point is a very good one. That is one bullet point that really should be broken down. I think there are enough critical-to-privacy/infosec details to warrant a separate table for each vendor, which would allow a bullet like that to be answered with some granularity (full URL, full URL after X sanitation efforts, URL with query params stripped, hostname, hash of X, hash of Y, etc).

    I think some additional granularity might be beneficial on the file side as well. There is a significant difference between a) sending *just* a hash of the file, and b) sending the hash plus "version information" such as vendor name, File version, Product Name, etc. If the AV company "knows" the file, sending just the hash lets them know precisely what you are running and all its details (edit: potential for hash collisions worth noting though, which would relate to what type they are using). However, for example in NDA scenarios where everyone is supposed to keeping things secret including from AV companies, sending version information can reveal more and too much to them. Then there is a big difference between sending filename and sending full pathname, particularly where the full pathname isn't going through some sanitation steps.

    That's a good one to add too. You'd think it wouldn't need to be mentioned because no security company would fall short in this area. Yet, I think there have been cases of that and might even still be cases of that. The strongest encryption in the world won't help protect you from some type of "compromise" on either end of course, be that an agency based "compromise" or some other, but you definitely want the channel strongly protected. From others at least. If client side admins can't inspect the traffic they are prevented from doing their job. Trust is not an IT policy, as someone else put it or similarly so.

    I also think it would be worthwhile to shed some light on whether the phone home features can be disabled, and if so, some idea of how doing so will impact detection capability. There's a big difference between "can't disable, can disable but lose all detection capability in this area, can disable but you lose only the cloud portion and there is a pretty robust offline database to fall back on). Personally, I'd also like to know whether each type of data collection is disclosed in a clear and unavoidable manner, and whether choice is handled in an opt-in, opt-out, or ask fashion.

    I'm really pleased and thankful AVC took a crack at the subject, for it is one of the more important ones in the field of security. I hope they continue to work on it and refine it. I found the "this report was initially requested and commissioned by PCgo and PC Magazin Germany" noteworthy. Pretty sad that magazines had to request and sponsor such important work, but kudos to them for doing so. If sponsors are needed to keep at it, and none are found, perhaps they'd consider crowd funding. Some things are worth doing and contributing to.
     
    Last edited: May 5, 2014
  18. DoctorPC

    DoctorPC Banned

    Joined:
    Jan 9, 2014
    Posts:
    813
    I haven't read through this thread entirely, but this is a brilliant report, and long overdue.

    We can see something I have been worried about, Webroot's 'closeness' with the US Govt., and now the fact they collect 'all' of the information on 'all' of their users, including information that is personally identifiable.. So... Interesting how 'specific users' can get 'specific updates', if a company didn't answer NO to that, then I wouldn't want anything to do with them personally, as there should be absolutely no capability to impact an individual user from remote. Also, any AV that transmits Windows Username would be something I couldn't consider running as well, that's a security/privacy compromise that has no business being transmitted. Shame on you companies.

    Looks like Panda needs a closer look - they are in the top for 'No' checkoffs. While the USA-Based companies are clearly datamining their customers. Which again, I have warned against US-Based products for quite some time now. Only thing missing.. IBK needs to show a 'combined total' with an easy to read summary to finish it off.

    Ahn, Emsisoft, eScan, Panda, Fortinet are the overall winners, with Avira and Bullguard close behind.. Webroot/McAfee/Norton/Trend seem to be the WORST offenders.
     
  19. clocks

    clocks Registered Member

    Joined:
    Aug 25, 2007
    Posts:
    2,787
    Is all the Chinese programs. Baidu, Qihoo, Tencent, etc...
     
  20. IBK

    IBK AV Expert

    Joined:
    Dec 22, 2003
    Posts:
    1,886
    Location:
    Innsbruck (Austria)
    as you can imagine, German magazines may not had much interest in Chinese products...
     
  21. DoctorPC

    DoctorPC Banned

    Joined:
    Jan 9, 2014
    Posts:
    813
    and Chinese products are notorious for being laced with spying tools.. I wouldn't even bother with those.
     
  22. MaJaRe

    MaJaRe Registered Member

    Joined:
    May 4, 2014
    Posts:
    5
    If you had, then you would have been aware that not all "tested" where cooperating with it. As I read the document I could not establish:
    - Who had Fully cooperated
    - Who had partially cooperated (and in what degree)
    - Who had NOT cooperated

    Which was said so by Eset replying earlier here in the thread that they didn not reply at all to the questionaire. I don't remember where I read that Symantec did cooperate (probably this topic, but not going to re-read), and Panda defended it being stats blah on a blog, without going into details of which are more problematic concerns imo.

    We do know that part of the data AV-Comparatives used is their own testing, which involved sniffing network traffic, and they could only say some about it when it was not encrypted...

    So while we have a discussion on a issue, its pretty hard to get things fully established, for this is not fully disclosed by all parties been tested, and some things are assumptions based on data transferred.
     
  23. DoctorPC

    DoctorPC Banned

    Joined:
    Jan 9, 2014
    Posts:
    813
    Seems to me this report is pretty accurate, as they used a 'variety' of methods to establish their findings - which by the way is what we do in engineering.

    1) They solicited information from subject companies in a professional manner.
    2) They examined settings within the programs.
    3) They evaluated the EULA's to gather information.
    4) They sniffed/parsed traffic of subject programs.
    5) They examined logs, and other relevant information to see what data was being gathered.

    Wonder what else they did? This seems adequate. Any 'non-response' should be considered a 'yes' in this case, as companies know better than to ignore these sorts of inquiries by well known firms, don't they? Simply not answering doesn't exonerate one from such a report, and in fact to me - it's a guilty plea.

    For me, I will consider this report when evaluating products to deploy, as it's another piece of the puzzle. I already had strong suspicions about Webroot gathering more information than it needed to establish a security logic, and Webroot STRONGLY denied it, saying they cannot even 'identify' individual systems, or data about those systems - we know that was a lie because of this report, which correlates with the findings of individuals. Any product stealing a Windows Username, and Computer Name causes me to pause. Those are privacy issues, and depending on circumstances, security issues.

    For me, the key things from the report that would cause me alarm;

    1) Computer Name
    2) Windows Username
    3) Non-Executable file submission (IE Documents, Financial papers, etc)
    4) Special Updates to Specific Users
    5) Sample of malware collected data, collected by AV (this is a huge red flag)
    6) Visited URL's submitted (even if not malicious)

    Now if your AV is 'generally' yes to those, I would really be starting to consider your privacy/security. As that data isn't required, whatsoever for good functionality of a security product, but is very valuable if you want to 'snoop'. Or in the case of what we already know - snoop as a proxy of State Sponsorship. To me this automatically disqualifies; Webroot, McAfee, Microsoft, Kaspersky, Eset, Symantec, Sophos, Trend, Bit Defender, Avast, Vipre, GData, AVG as potential products to consider. It would cause me 'some' concern for; Avira, F-Secure, Panda. It automatically moves the following to the top of the consideration heap; Ahnlabs, Fortinet, Bullguard, Emsisoft, and eScan.

    There is a lot to consider when choosing a product, and this seems to be one aspect we should be considering. Just because a company 'swears' to not compromise your loot, doesn't mean someone else won't, someone working there won't, or someone may gain access to it.. That's ignoring the fact that ANY State Sponsored action is usually compartmentalized - and those 'guys' assuring you it's not happening, probably don't actually know if it is or not. Ahnlabs suddenly looks more promising, and it's extremely light, and has a nice firewall. When stacked with Appguard+Mbam, who cares of Ahnlabs is an 89-92% detection product? If they aren't sharing your loot, then it's merely a safe, additional security layer. Maybe the 'also rans' will get some traction from this.
     
  24. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    14,881
    Location:
    Slovenia, EU
    @DoctorPC I don't know how thoroughly they examined their settings. For question "Are non executable files transmitted" there is "not disclosed" result for ESET. If they have checked the settings they would have found out that most personal documents types are filtered by default (doc, xls, pps...). User can also change those settings and add additional file types. IMO "not disclosed" is not best description as user can decide which files are sent for analysis.
     
  25. DoctorPC

    DoctorPC Banned

    Joined:
    Jan 9, 2014
    Posts:
    813

    Then the 'not disclosed' folks need to chime in, and carefully answer each question. Otherwise, we're left with assumptions based on the data available, and that data seems to push us in the direction of AVC's findings.
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.