Help me develop TinyWall's Privacy Statement

Discussion in 'other firewalls' started by ultim, Mar 10, 2016.

  1. ultim

    ultim Registered Member

    Joined:
    Oct 12, 2011
    Posts:
    307
    TinyWall has always followed a very stringent privacy policy. It does not, in past or present versions, send any kind of information to me or to third parties. Not even non-personal information. Even when it checks for an update every few days, no records are collected or kept at all, not about IP address, not about the current version on your machine, not anything. Literally nothing. This is what I would like to see from other software too, and especially with TinyWall, whose main purpose is to protect both your security and privacy, it is all the more important to keep following similar guidelines.

    Unfortunately, these wishes as a user are somewhat in contrast with my wishes as a developer. I cannot possibly keep in touch with everybody who experience problems – this is an issue of both time, user knowledge, and trust. Ultimately, I need some telemetry from live installations, for increasing system compatibility, tracking down bugs, determining relevant configurations, and laying out new features.

    For this, I'm leaning towards implementing some automatic feedback in TinyWall. I want to do this as transparently as possible though, and as much as possible with your consensus. To ensure my intentions and methods are clear and transparent to all, I have put together a preliminary privacy statement that describes what data future versions of TinyWall would like to analyze.

    This is where you come in: I ask You for your feedback and input.

    Below is a first draft of the privacy policy that I'd like to implement. It should specify what TinyWall's guidelines are regarding privacy, what, if any, data is collected, and for what purpose. Please note, that as I said above, nothing is collected in present versions, and anything that is described here is only for the future. But that is the whole point: before any such telemetry is implemented, I'm asking for your input. I would like to know if this is acceptable for you, for what percentage of you this is acceptable, and in case you have objections, what improvements you suggest to make this acceptable.

    Of course I will continue to keep your privacy in high regards, and TinyWall will only implement the kind of telemetry that gets documented here. When it is final, this document will be added to TinyWall's current EULA. And until that happens, in this thread you have a chance to influence it. Also, until then, TinyWall will retain its current “zero collection” policy.

    See the draft of TinyWall's Privacy Policy in the next post. I guess it turned out more formal than I would like, but probably only because I wanted to be very specific, to leave as little to imagination as possible. The short version is that what I want is NOT spying on you, but collecting telemetry about TinyWall and ONLY about TinyWall, so that I can improve it in various ways.
     
  2. ultim

    ultim Registered Member

    Joined:
    Oct 12, 2011
    Posts:
    307
    TinyWall Privacy Policy / Privacy Statement
    DRAFT


    1. Scope and goal of this document

    TinyWall is a software to enhance and protect its users' security and privacy. To facilitate this goal, it is essential that the software itself handles user data with respect and sensitively. The author of TinyWall is proud to have always respected his users' privacy to the maximum, and is committed to continue doing so, and to follow the guidelines and points laid out in this document in connection with TinyWall.

    This document describes how the software TinyWall, related services, its installer, or any installed component, third-party or not (collectively called forth on “TinyWall” or the “Software”, used interchangeably), will treat information stored on, generated on, or input to a user's computer. For all versions of the Software released while this document is in effect, the Software will adhere to the points described herein.

    2. Data that is NOT collected
    TinyWall and its author is committed to not only preserve, but to improve and protect the user's privacy and security. To this end, TinyWall does not collect and transmit, or otherwise store, locally or remotely, any of the following kind of information:
    1. Information that could be potentially used to identify a user or their device. Such data includes, but is non-exclusively, information about the user's identity, real name, machine account name, personally identifiable information (such as post- or IP-address), or unique hardware identifiers.
    2. Information generated or stored by software other than TinyWall.
    3. Information about a user's behavior or usage pattern of software other than TinyWall.
    4. Information about the local network, visited networks and remote endpoints, or otherwise information about connections initiated or received on the user's machine.
    3. Data that is collected
    For the sake of improving TinyWall, it may collect some anonymous information about the usage and execution of the Software, as long as not in contradiction with the points in Section 2. of this document.

    These data can fall into the following categories:
    1. Data to improve the general stability and quality of the Software
      Information about the version of the execution environment and operating system, as well as recorded software crashes and error conditions in TinyWall.
    2. Data used to improve the user experience of the Software
      Information about execution times of parts of the Software and performance metrics, as well as usage frequency of some features, and information about firewall exceptions.
    3. Data to better determine relevancy for target audience
      Information about maintenance operations, such as installing or uninstalling TinyWall.
    4. How the collected data isused

    The data listed in Section 3. are transmitted in encrypted form either on periodic intervals, or at certain events like recognized error conditions in the Software.

    The data are collected for the sole purpose of improving the Software's stability, user experience, and features. They will not be shared with anybody not involved in the development of TinyWall. The data will not be traded or sold to third-parties.
     
    Last edited: Mar 11, 2016
  3. Jarmo P

    Jarmo P Registered Member

    Joined:
    Aug 27, 2005
    Posts:
    1,183
    I have to say that I don't like it. The one best thing about TinyWall as it is today is the privacy.

    You might have your reasons that I am not really asking why you would need to change TW privacy policy so much. I know you are making some bigger update, possibly quite different from existing one in behind the scene. But do you really need user information (any) be gathered? I know most others won't like that too.

    You know that firewall's never make any money? Not worth for the development costs/effort I mean. So if this is some ambitious move for that direction, I'd say forget it.

    Could what you are wanting be just an option to help you if willing to share that data you want if it is needed for testing the new release? I know I have never helped say Mozilla Firefox developers though when it has crashed to send the information. It is a different thing to help you, but still.
     
  4. TheWindBringeth

    TheWindBringeth Registered Member

    Joined:
    Feb 29, 2012
    Posts:
    2,084
    Asking for general feedback is a good thing. Will you also be asking each user for permission before you collect telemetry from their device?

    May need refinement given that you will, presumably, be causing the user's IP Address to be transmitted to the telemetry server. Which is owned by who, btw? Might want to mention unique software identifiers too, or do you intend to send one?

    Rules would reveal information about a user's usage of other software. Will you be collecting any information about those?

    Telling people what you intend to exclude will help them, but telling them what you intend to include may help them even more.
     
  5. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    8,010
    Location:
    The Netherlands
    I'm not going to lie, I'm against all forms of telemetry, I hate this stuff. My advice is to give an option to disable it.
     
  6. amarildojr

    amarildojr Registered Member

    Joined:
    Aug 8, 2013
    Posts:
    1,963
    Location:
    Brasil
    Oh look, another developer who is gathering tons of data...... :thumbd:
     
  7. ultim

    ultim Registered Member

    Joined:
    Oct 12, 2011
    Posts:
    307
    Thanks for your inputs. I'll try to answer each concern/question, then I'll wait for new feedback.

    @Jarmo:
    -----------------------------
    I won't deny that I wouldn't mind if TinyWall provided some return on my “investment”, and that in the future I might try to explore various ways to make something out of this program. I was also contacted by some interested third-parties (plural). Nevertheless, I assure you none of these options I'm thinking about involve trading with your data, or giving them away in any way. None.

    I could make it an option, like you, TheWindBringeth and Rasheed suggested. I'm only afraid in this case that almost nobody would turn this on.

    @TheWindBringeth
    -----------------------------
    Providing an option to enable/disable telemetry could work, technically. The problem here is that I'm not sure it is much better if it is turned on by default, that is also something that nobody wants. And if TW starts with telemetry off by default, nobody will turn it on.

    About the IP address being transmitted:
    For any server on the internet, the client IP is always visible. It is transmitted with *every *single *ip *connection. This is how the internet works and I can do nothing about it. I cannot “turn it off”, nobody can. I can promise however, that 1) I won't extra transmit it to overcome hidden addresses due to proxies or routers, 2) that I won't store it on the server, and that 3) I won't correlate it with other information from you. I don't think there is anything else that technically possible to do about this, but if this is enough, I'll be glad to clarify that in the doc above.

    Who owns the server?
    TinyWall is currently hosted at a german hosting provider, Hosteurope Gmbh. Their servers used to be also in Germany, but recently they moved most of their small clients to a farm in France. That is where TinyWall has its own virtual private server now. The hardware is not mine technically since I am only renting it, but otherwise (at least theoretically) I am the only one with full access to the data on this server.

    Unique software identifiers?
    Of course I TinyWall will never read out unique identifiers of other software on your computer. It would be very practical though if TW could has its own. Why, I'm going to talk about that a few lines down below. Here, I'll just describe it technically: it would be fully random, e.g. not generated from your data, and therefore not possible to backtrack it to a specific person. Since I'm not looking at your other information like connections you made or websites you visited, I also cannot use it track you like web-cookies do. So it is pretty private.

    Collecting info about rules?
    This is where I also talk about why a unique random id for TinyWall would be needed. And also why I'd need information about your rules. Both are necessary to implement a feature that many users have been asking about for a long time: a much larger and more often updated rule database. Obviously I cannot keep installing hundreds of software all the time manually, checking for changes, updating rules, issuing updates and so on. This database would need to be generated automatically. But to implement such a cloud database, the system needs the rules that are created aorund the world. Your rules. I couldn't care less about the applications you use. This information would be collected not for my personal leasure, but to churn it through an algorithm that processes the rules from different users, and spits out a database with a list of trusted rules based on an implicit voting system. And that is why I need unique TinyWall IDs too. Because to implement this automatic “voting” and make it somewhat secure, I need to make sure that the same application from the same users does not end up multiple times in the database.


    I can refrain from using tinywall IDs if you want, and also refrain from collecting information about your rules. But then I am sure I'll never be able to build up this database in the scale most of you would like to.

    I hope I could answer your questions up to this point. Please keep the suggestions coming, or simply just let me know if based on the current information available you are okay with these plans. I'll scratch the whole idea if everybody is so bothered by it, but to be honest I'd prefer if I could implement at least part of it, like the automatic submission of software errors reports.
     
  8. zapjb

    zapjb Registered Member

    Joined:
    Nov 15, 2005
    Posts:
    3,513
    Location:
    USA - Back in a real State in time for a real Pres
    Just a spaghetti on the wall idea. But what if you charge a $1 (all, part or none can be directed to one of several charities - user's choice) to turn off telemetry. Or not again user's choice.
     
  9. boredog

    boredog Registered Member

    Joined:
    Feb 1, 2015
    Posts:
    1,164
    ScreenHunter_02 Mar. 11 16.13.jpg Windows 10 Home. 64 bit.
     
  10. boredog

    boredog Registered Member

    Joined:
    Feb 1, 2015
    Posts:
    1,164
    Got it installed but in Normal default mode lost internet connection till went to learning mode.
     
  11. Tarantula

    Tarantula Registered Member

    Joined:
    Jul 23, 2010
    Posts:
    357
    What about old school people like me? I only use cash to pay for what I need. I am not using any electronic payment methods. I don't have bank accounts.
     
  12. zapjb

    zapjb Registered Member

    Joined:
    Nov 15, 2005
    Posts:
    3,513
    Location:
    USA - Back in a real State in time for a real Pres
    Prepaid cc?
     
  13. TheWindBringeth

    TheWindBringeth Registered Member

    Joined:
    Feb 29, 2012
    Posts:
    2,084
    @ultim: Thank you for the substantial reply.

    Based on what you've said thus far, I think some users would voluntarily choose to participate. There actually are people who want to "contribute", "provide feedback", etc and go into it eyes wide open.

    On the other hand, I'm sure there are some users that would not want their firewall (be it TinyWall or something else) to phone home a unique identifier, information about rules they are using, and/or error reports. Some of them would want their firewall to never phone home.

    My question at this point would be: Have you considered ASKING the user? By that I mean a one time prompt displayed during a new install or during the install of an update that brings about the change. Briefly describe it, include a link to open the privacy statement where more information could be found, set it up such that the user must effectively say YES or NO in order to proceed, persist and apply their preference. You could even include a "if you change your mind later..." instruction that tells them how to change it later.

    This would assure that the user is aware of the feature's existence, and assure that they know whether it will be enabled or disabled. No surprises.
     
  14. Nebulus

    Nebulus Registered Member

    Joined:
    Jan 20, 2007
    Posts:
    1,582
    Location:
    European Union
    I know that this is only a personal preference and has no statistical relevance, but here it is: IMO the only software that must never phone home is a firewall/packet filter. What is the point of having a software whose purpose is to stop applications to connect to internet to do this kind of thing itself? I know that there are other firewall software that do call home; for instance Comodo Firewall, but it allows the user to block that communication using a custom made rule.

    The second problem I have with your approach is this: maybe you are honest about what are you going to do with the data you collect (I have no reason to doubt you), however once the data is stored it can easily change owners, either by a security breach/hacking or if a company decides to buy the software you make. In both cases you will have no say in what happens to the data.
     
  15. TheWindBringeth

    TheWindBringeth Registered Member

    Joined:
    Feb 29, 2012
    Posts:
    2,084
    Even before storage on the server would become a possibility, the data would have to get to the server. In a secure manner, obviously. Which means you have to worry about protocol vulnerabilities, advances in brute forcing, figure out how to protect private encryption keys on a server which is running on someone else's platform, etc.

    This is no ordinary data we're talking about, either. It is information about security rules/state.
     
  16. Peter2150

    Peter2150 Global Moderator

    Joined:
    Sep 20, 2003
    Posts:
    17,039
    Hi Ultim

    I've been following this thread with interest. I've played with Tiny on and off, but I have to say honestly, that even that fact you are thinking this way, makes me add Tiny to software that will never again touch my system. I apply this to paid software as well as free. Call home to check a license, thats okay. Send info on my system, absolutely no way. The problem here isn't a privacy statement, but the fact you want to do something that requires it.

    Pete
     
  17. ultim

    ultim Registered Member

    Joined:
    Oct 12, 2011
    Posts:
    307
    1) Of course I see the privacy implications of the matter. Transmitting information about your rules and such *is* sensitive information. Some of this, unfortunately, is required to implement the very popular feature request that I've described above. Exactly because I recognize the privacy implications, I needed to find out if people are willing for this trade-off for the feature.

    2) The other stuff are less sensitive. For example, transmitting error reports with your OS version without any way to associate it with your computer or person, is something that shouldn't have any security or privacy implications, assuming it is correctly implemented. Still, I wanted to ask you about this lesser stuff as well, because it shouldn't be me who decides what counts as private for you, but you should decide.
     
  18. ultim

    ultim Registered Member

    Joined:
    Oct 12, 2011
    Posts:
    307
    Asking the user during installation just like you described sounds like the best alternative to me. Even then though, based on the current feedback I got, collecting information about rules seems like a definitive no-go at the moment. Which tbh is fine by be, I'm not personally interested in that, it only means one less complicated feature to think about.

    @To all others: Keep your voices coming.
     
  19. ultim

    ultim Registered Member

    Joined:
    Oct 12, 2011
    Posts:
    307
    Wouldn't this basically mean you'd have to pay for your privacy? I don't like this idea, sry, but thanks for letting me know about whatever comes to your mind. Don't let this discourage you.
     
  20. TheWindBringeth

    TheWindBringeth Registered Member

    Joined:
    Feb 29, 2012
    Posts:
    2,084
    Care to elaborate on "the other stuff" and error reports?

    Turning off all forms of automated error reporting has been a best security practice for ages, because such reports nearly always contain some detailed information about the environment. Such as some hardware info, installed/enabled software components and their version numbers, etc. Which can reveal what types of security features are in use, what type of encryption system is being used, whether a protection component is down, what exploits might work given that or software versions, be useful for fingerprinting, sometimes capture unique identifiers, and sometimes include memory contents. Edit: It is unclear if your "assuming it is correctly implemented" eliminates all the concerns.

    Obviously, you can generate textual reports. Which are good because then the user can fully review what they contain, redact if/where necessary, and then a) copy and paste somewhere, and/or b) submit to the developer via secure channel. This would be a manual submission process, and one that is optional. Earlier, you said "automatic submission of software errors reports". Which sounds different.

    Edit: You seem to have abandoned the idea of rules collection, but it is unclear whether the collection of "lesser stuff" is still under consideration, would involve asking the user, etc. Thus this attempt to shed more light on it.
     
    Last edited: Mar 13, 2016
  21. ultim

    ultim Registered Member

    Joined:
    Oct 12, 2011
    Posts:
    307
    You are right in general, but in TinyWall's case the situation is much better. TinyWall does not use memory dumps like other applications, eliminating one of the primary risks of transporting sensitive information by accident. The information that'd be sent on software errors are a stack trace, the error message and type, TinyWall's version, .Net's version, and Windows' version. While the latter two could in theory reveal patch levels about your system that a malicious attacker can use, given that the information is not only sent encrypted but is not associated with your IP or any other device ID, there is practically no way to use that information against you, because the attacker would not know which machine on the internet the information pertains to. This is why I deemed this information less critical.

    Not to mention, all this assumes that the attacker can compromise an https-connection or break into TinyWall's server – which I'm not saying is impossible, but is probably not worth it just to find out your OS version. Should the latter ever happen, it is much more likely they'd go with replacing TinyWall's download with an infected one instead of looking at the OS version of a computer they cannot even associate with any machine on the internet.

    The only “other stuff” left are technical measurements of certain TinyWall features. “Did a user ever use a certain feature at all?” or “How many milliseconds does it take for TinyWall to initialize the firewall rules?” would be some practical examples.

    And yes, I would like error report submissions to be automatic, assuming the user enabled it. In either case, the user would get asked during installation if he wants to enable it. It should also be separately controllable from update checks, so that your TinyWall installation would still privately check for updates without transmitting this information if the user chooses so.
     
  22. TheWindBringeth

    TheWindBringeth Registered Member

    Joined:
    Feb 29, 2012
    Posts:
    2,084
    Well, the information TinyWall phones home will be transported by IP and therefore associated with the user's IP Address when it is sent over the Internet and when it is received by your VPS. How you process what you receive is up to you. I think your comment speaks to the latter and what conditions will be afterward.
    The data sent to your server might not be worth the trouble, but if it were thought to be then an attacker may attempt to gain access to it. If someone did gain control of your server and they were motivated, they would try to capture information as it is received along with the IP Address that sent it. Without disrupting your normal processing and alerting you. There would be no way for telemetry participants (potential targets) to detect and respond to it (unless and until you did). Which makes the approach useful for reconnaissance purposes. I'm not saying that is going to happen; just mentioning it.
    I don't know if it will in your case, but I would point out that telemetry on the use of certain features can, in some scenarios, reveal security posture. Hopefully, you'll assure that this too is somehow behind the asking you intend to use.
     
    Last edited: Mar 17, 2016
Loading...