Sorry guys, I've been out all day, but I've been thinking about this. You all are absolutely right. We made two mistakes:
(1) We assumed that because we choose not to store/process the IP data, that users would believe us that we don't
(2) We incorrectly assumed the that space of user home paths on your desktop was big enough that the 4 byte identifier would not have adverse privacy implications. I did not consider that people's home usernames might be, say, their username on bitcointalk.org
It's quite clear that those two pieces of data do have pretty serious privacy implications. I want to fix this ASAP.
To be clear, the reason we made the unique identifiers is
because we don't want to store any IP data for the reasons described: if there was a subpoena of some sort, we'd prefer to not have anything to reveal. And we don't store it. But, we incorrectly assumed that the unique identifiers would be sufficiently non-privacy-leaking while still allowing us to remove duplicates (in response to justus: we want an identifier that will be persistent between loads so that users that start the program over and over are not counted for each start--as we all know, a lot of users have difficulty with Armory and will start it 300 times to try to get it to work). It is clear these were bad assumptions since we technically
could be storing both which
would be quite bad.
I hope we've generated enough good faith with the community that we get a little slack that this was not our intention. I take the blame for not realizing that, and I want to make sure that it is fixed. ASAP. I will happily take feedback on how this should be adjusted so that we can meet our goals without compromising the privacy of the users.
I agree we should decouple the option from the announcement fetching. We consider announcements to be extremely important, and why we made that difficult to disable: if there's a critical security (or privacy!) vulnerability in Armory, there is a very short window where someone might try to exploit it to steal peoples' coins, and there's no better way to help users than to make sure a big scary warning pops up the next time they start Armory. The fact that we coupled the OS/version reporting with meant that it was as hard to disable that as it is the announcement fetching. We can easily separate them and will happily make it easy to disable the OS/version reporting.
Re privacy policy: On the advice of our lawyer, we included the "may collect IP addresses" because we have no way to prove that we don't. And since our website uses google-analytics, we don't have control over what google does with the access patterns of users to our website. It was a bit of CYA that companies have to abide by, especially in the US. Note we describe at the bottom of that page
we describe how to disable it with a link to our troubleshooting page.
On the upside: another positive example of the power of open-source software. We have casually encouraged users to go through the code base, and we even contacted the Open Crypto Audit Project to try to get a code review (and never heard back from them). We are obviously believers in open-source, and here's the first solid example of Armory getting better because of it. We will get this fixed.
