Topic: Why is Armory sending our *USERNAMES* to bitcoinarmory.com ‼️ (Read 9248 times)

P.P.S. - We found a subtanstial improvement for OSX performance that was a small change so we decided that should go into 0.92.2.  Also should have minimal impact (simply disabling AppNap, I think).  

That's awesome, great work!

I believe on Ubuntu running it through terminal you can see the fetches/etc and all that comes along with it. If anyone would compile it and run it that way it should be easy to spot if it's still repeating previous behavior.

Sadly myself I'm not familiar enough with code to review it.

Thanks again and awesome work!

def getDecoratedURL(self, url, verbose=False):
blahblahblah
print url + '?' + urllib.urlencode(argsMap)
return url + '?' + urllib.urlencode(argsMap)

To 1a5f9842524:  I believe you said you ran some network tools to find the original issue.  Can you do this again to make sure I didn't miss something? 

Okay, so here's my plan.

I'd like to have a new version out by next week (0.92.2).  Given that the change is small and doesn't go by any critical code paths, the release testing process can be relaxed slightly.   We'll try to have it out by Monday.

Second, the way I'd like to do it is to put a 4-byte random identifier in the settings file, and use that to for duplicate detection.  That identifier will be overwritten/changed every month, so that any thing that would care about trying to match IDs to systems will expire after a month.  This allows us to aggregate up to monthly statistics.  Anything longer than that we can do without.  

Third, we will decouple the announcement stuff entirely from OS/version reporting.  We will add an option in File->Settings to completely disable this.  Then announcement fetching will send a bare string with no extra metadata.   And as suggested, no extra data needs to be sent on subsequent announcement fetches.

Fourth, we will add a command-line option called "--tor" (with an equivalent option in the settings).  Then we will adapt the code to use that flag  to implement all the standard Tor-based settings:  most likely "--skip-announce-check --skip-online-check --satoshi-port=X".  You guys will be able to examine what code paths are affected by this setting and make recommendations for us to improve it.   (note there is also a "--skip-version-check" flag, but that is no longer used, since we updated the announcement system in 0.91).

I want to reiterate that we do care about privacy -- I've personally been a proponent of security and privacy on these forums for years.  And it would be tough to see why we would really care to match up IDs with announcement fetch pings.  We're not in the data collection business, no advertising, nothing.  We wouldn't know what what to do with it even if we saved it.   We (I) simply made a judgment error when implementing this (compounded by the fact that it was developed as part of a feature we wanted to aggressively promote -- security announcements).  Armory is a massive program, and it is respected for being thorough and careful, but we can't get 100% right.  One of the nice things about open-source is that people can find issues, call them out, and get it fixed.  And that's exactly what happened here.  Thanks for your guys' patience and we'll get this fix out there.

Okay, so here's my plan.

I'd like to have a new version out by next week (0.92.2).  Given that the change is small and doesn't go by any critical code paths, the release testing process can be relaxed slightly.   We'll try to have it out by Monday.

Second, the way I'd like to do it is to put a 4-byte random identifier in the settings file, and use that to for duplicate detection.  That identifier will be overwritten/changed every month, so that any thing that would care about trying to match IDs to systems will expire after a month.  This allows us to aggregate up to monthly statistics.  Anything longer than that we can do without.  

Third, we will decouple the announcement stuff entirely from OS/version reporting.  We will add an option in File->Settings to completely disable this.  Then announcement fetching will send a bare string with no extra metadata.   And as suggested, no extra data needs to be sent on subsequent announcement fetches.

Fourth, we will add a command-line option called "--tor" (with an equivalent option in the settings).  Then we will adapt the code to use that flag  to implement all the standard Tor-based settings:  most likely "--skip-announce-check --skip-online-check --satoshi-port=X".  You guys will be able to examine what code paths are affected by this setting and make recommendations for us to improve it.   (note there is also a "--skip-version-check" flag, but that is no longer used, since we updated the announcement system in 0.91).

I want to reiterate that we do care about privacy -- I've personally been a proponent of security and privacy on these forums for years.  And it would be tough to see why we would really care to match up IDs with announcement fetch pings.  We're not in the data collection business, no advertising, nothing.  We wouldn't know what what to do with it even if we saved it.   We (I) simply made a judgment error when implementing this.  Armory is a massive program, and it is respected for being thorough and careful, but we can't get 100% right.  One of the nice things about open-source is that people can find issues, call them out, and get it fixed.  And that's exactly what happened here.  Thanks for your guys' patience and we'll get this fix out there.

Okay, so here's my plan.

I'd like to have a new version out by next week (0.92.2).  Given that the change is small and doesn't go by any critical code paths, the release testing process can be relaxed slightly.   We'll try to have it out by Monday.

Second, the way I'd like to do it is to put a 4-byte random identifier in the settings file, and use that to for duplicate detection.  That identifier will be overwritten/changed every month, so that any thing that would care about trying to match IDs to systems will expire after a month.  This allows us to aggregate up to monthly statistics.  Anything longer than that we can do without. 

Third, we will decouple the announcement stuff entirely from OS/version reporting.  We will add an option in File->Settings to completely disable this.  Then announcement fetching will send a bare string with no extra metadata.   And as suggested, no extra data needs to be sent on subsequent announcement fetches.

Fourth, we will add a command-line option called "--tor" (with an equivalent option in the settings).  Then we will adapt the code to use that flag  to implement all the standard Tor-based settings:  most likely "--skip-announce-check --skip-online-check --satoshi-port=X".  You guys will be able to examine what code paths are affected by this setting and make recommendations for us to improve it.   (note there is also a "--skip-version-check" flag, but that is no longer used, since we updated the announcement system in 0.91).

I want to reiterate that we do care about privacy -- I've personally been a proponent of security and privacy on these forums for years.  And it would be tough to see why we would really care to match up IDs with announcement fetch pings.  We're not in the data collection business, no advertising, nothing.  We wouldn't know what what to do with it even if we wanted to.   We (I) simply made a judgment error when implementing this.  Armory is a massive program, and it is respected for being thorough and careful, but we can't get 100% right.  One of the nice things about open-source is that people can find issues, call them out, and get it fixed.  And that's exactly what happened here.  Thanks for your guys' patience and we'll get this fix out there.

Simple don't use armory, if you don't like it. This is absolutely unacceptable. This should be fixed right away.

Well on the bright side Armory is open source so I forked it on GitHub to remove this behavior.  It looks to be done entirely in a single Python file so you don't even need to rebuild anything to make the change.  Just merge these changes into your announcefetch.py and you should be good to go.

https://github.com/weirddan455/BitcoinArmory/commit/09207dc089facfcea279e485077ed0848491995b

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.