Pages:
Author

Topic: Why is Armory sending our *USERNAMES* to bitcoinarmory.com ‼️ - page 3. (Read 9273 times)

newbie
Activity: 15
Merit: 0

You know that the user won't be making transactions when the application is closed, so you can start to eliminate transactions on the chain which couldn't possibly have been theirs.

Not really. One can broadcast the raw tx let's say on blockchain.info when the client is closed. I did it a few times myself.
newbie
Activity: 8
Merit: 0
It's not hard to imagine how this would be connected with the transactions a person makes just due to the timings of the requests.

Running armory doesn't necessarily mean that you are performing transactions, so i don't think any connections can be made by that.

Sure they can.

You know that the user won't be making transactions when the application is closed, so you can start to eliminate transactions on the chain which couldn't possibly have been theirs. Armory doesn't use compressed point pubkeys, and does not reuse addresses which you can use to further filter the transactions you see. With the last two features alone you can eliminate a large portion of all transactions in each block as being not possibly being made by Armory.

Having 32 bits of the home folder hash is actually pretty devastating to your privacy as well. Within that space you could search bitcointalk user names for example with only a 1 in 4 billion chance of a false positive per attempt. I'd bet on a lot of people having user names that very much match with their bitcointalk ones.
sr. member
Activity: 476
Merit: 250
It's not hard to imagine how this would be connected with the transactions a person makes just due to the timings of the requests.

Running armory doesn't necessarily mean that you are performing transactions, so i don't think any connections can be made by that.

In any case it's nice that you have noticed that and i think a permanent opt-out option should be available.
Then again stats might be one of the few ways for creators to monetize their wallet-software.
newbie
Activity: 8
Merit: 0
We added the unique ID so that we have a way to count unique users without logging IP addresses.

Your Privacy Policy (which oddly enough I've never seen before now) says that you only log IP addresses. Which is it? 

https://i.imgur.com/6xPsGpU.jpg

Collecting 32 bits worth of people's usernames is not mentioned in the Privacy Policy at all, ergo you shouldn't be doing it. It also mentions nothing about sending it to Amazon S3, or to Cloudflare which you use to host the ping domains.
full member
Activity: 154
Merit: 100
Utter nonsense.

If you wanted a unique anonymous ID you would have generated a few random bytes and used that. Instead you used a highly identifying, personal piece of information and sent it to your remote server along with the IP address of the user. There's no way you can pretend that was a mistake from somebody who is writing wallet software.

Why don't you do us a favor and delete all the information you've collected without your users consent.

I agree.

On the website, they have a privacy policy that states this:

Quote
ATI may collect your device’s IP address: when you start the software on your device and the software checks for updates and notifications, unless you opt out of this feature.

ATI does not share this information outside of ATI except that ATI may share information with governmental authorities pursuant to a court order or other lawful order.

However I don't recall being forced to agree to this when I ran the software, though from looking at the source it appears to be in the help menu at least.
newbie
Activity: 8
Merit: 0

The 30 minutes isn't to for "collection", it's for announcement checking.  If there's a hard fork and people are potentially going to lose money, we need users to be aware as soon as possible.


Why don't you use the alert system in Bitcoind just like everybody else? It would be instant and more reliable, only you wouldn't be able to collect personal information with that method.



The 30 minutes isn't to for "collection", it's for announcement checking.  If there's a hard fork and people are potentially going to lose money, we need users to be aware as soon as possible.

You don't need to send the installation ID when checking for announcements. Why would you need that?

So that we don't "count" that ping as a unique user.  Our goal is to get a rough gauge of how many people are using Armory, and what the OS & version distribution is.  That's all we use the data for.  If we send a ping without the ID, we don't know if it's a duplicate. 


Utter nonsense.

If you wanted a unique anonymous ID you would have generated a few random bytes and used that. Instead you used a highly identifying, personal piece of information and sent it to your remote server along with the IP address of the user. There's no way you can pretend that was a mistake from somebody who is writing wallet software.

Why don't you do us a favor and delete all the information you've collected without your users consent.
full member
Activity: 154
Merit: 100
So that we don't "count" that ping as a unique user.  Our goal is to get a rough gauge of how many people are using Armory, and what the OS & version distribution is.  That's all we use the data for.  If we send a ping without the ID, we don't know if it's a duplicate.  

Also, I shouldn't have suggested "just" hard-forks... a piece of secure software used by people with massive amounts of money has many different reasons users might need to be notified, including critical security issues with Armory, if they arise.

I still don't know why you need to know their installation ID for each ping. Can you come up with a real-life example of a situation where you'd need to know that information when providing announcements? if there were critical issues in Armory that would affect everyone running that version and not specific installations.

For most users privacy is just as important as security.

Annoucements/statistics should be two completely seperate things. I think statistics should happen on first-run ONLY and it should be very obvious it's happening and easy for the user to opt-out. Checking for annoucements should send the bare amount of information you require, the Armory version and platform.

I was under the impression checks for announcements weren't automatic and it seems others were too. Maybe it should be more obvious that they are automatic and easier to disable them (in the GUI) for people who want to check manually instead.
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
The 30 minutes isn't to for "collection", it's for announcement checking.  If there's a hard fork and people are potentially going to lose money, we need users to be aware as soon as possible.

You don't need to send the installation ID when checking for announcements. Why would you need that?

So that we don't "count" that ping as a unique user.  Our goal is to get a rough gauge of how many people are using Armory, and what the OS & version distribution is.  That's all we use the data for.  If we send a ping without the ID, we don't know if it's a duplicate. 

Also, I shouldn't have suggested "just" hard-forks... a piece of secure software used by people with massive amounts of money has many different reasons users might need to be notified, including critical security issues with Armory, if they arise.
full member
Activity: 154
Merit: 100
The 30 minutes isn't to for "collection", it's for announcement checking.  If there's a hard fork and people are potentially going to lose money, we need users to be aware as soon as possible.

You don't need to send the installation ID when checking for announcements. Why would you need that?
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
As a company, we have to have some way to measure our userbase, and we felt this was the least intrusive way possible.  And you can opt-out.

Why ping every 30 minutes?



The 30 minutes isn't to for "collection", it's for announcement checking.  If there's a hard fork and people are potentially going to lose money, we need users to be aware as soon as possible.
full member
Activity: 154
Merit: 100
Additionally you could still get a list of all usernames on bitcointalk for example and compute the ID hashes by working out what their home directory would be expected to be if they used the same username on bitcointalk and their PC.

You'd be able to check that hash against your "statistics database" and find their installation along with all of the IP's that gave you the statistics.

What you do is arguably worse than simply collecting IP's.

Why don't you just send the OS version etc without the ID on the first time Armory is run? Much better than what you do.
sr. member
Activity: 337
Merit: 250
There should be an option on install to disable this activity of the Armory client.
newbie
Activity: 8
Merit: 0
The code you posted doesn't send your username to bitcoinarmory.com, it sends the truncated hash of your user home directory path.  This does not give us any information about you except that it will be the same when your system makes multiple requests for version/announcement information.   We intentionally chose this instead of tracking by IP because we knew that IP logging was "not cool". 

That's pretty much synonymous, most people will have their user name set to either their common pseudonym or their full name. If you have a batch of people who you think might have sent a transaction, 4 bytes of the hash is more than enough to work out which one.

Sending any personal information at all is "not cool", especially when nobody was told about it in the first place.


As a company, we have to have some way to measure our userbase, and we felt this was the least intrusive way possible.  And you can opt-out.

Why ping every 30 minutes?


We also add the ability for you disable this by running with "--skip-annuonce-check".

You can't expect a user to apply this every single time they load up the client. Not giving the option in the GUI is intentionally obstructive.
full member
Activity: 154
Merit: 100
Guys, calm down.  

The code you posted doesn't send your username to bitcoinarmory.com, it sends the truncated hash of your user home directory path.  This does not give us any information about you except that it will be the same when your system makes multiple requests for version/announcement information.   We intentionally chose this instead of tracking by IP because we knew that IP logging was "not cool".  And in the end, we don't care about your IP, we only use it the ID for collecting statistics about what operatings systems are being use to run Armory and what versions people are using, especially after announcing new versions.  This helps us remove duplicates.

Armory (the company) only tracks unique IDs long enough to collect daily statistics of our user base, like how many people have upgraded.  If a announce-request is made and comes from an ID we have never seen, we add the OS and Armory version to the statistics.  Otherwise we ignore it.   That's it.  We added the unique ID so that we have a way to count unique users without logging IP addresses.    We also add the ability for you disable this by running with "--skip-annuonce-check".  

As a company, we have to have some way to measure our userbase, and we felt this was the least intrusive way possible.  And you can opt-out.



If that is the case, why do you need to collect statistics every 30 minutes? By doing that you also see what times the installation is running which could allow you to match it up against bitcoin transactions made during those times.

And whether you like it or not the IP is transmitted along with the unique installation ID and we can't know whether you are storing the IP's or not. This bypasses any proxy settings set on bitcoind, such as people using Tor.
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
Guys, calm down.  

The code you posted doesn't send your username to bitcoinarmory.com, it sends the truncated hash of your user home directory path.  This does not give us any information about you except that it will be the same when your system makes multiple requests for version/announcement information.   We intentionally chose this instead of tracking by IP because we knew that IP logging was "not cool".  And in the end, we don't care about your IP, we only use it the ID for collecting statistics about what operatings systems are being use to run Armory and what versions people are using, especially after announcing new versions.  This helps us remove duplicates.

Armory (the company) only tracks unique IDs long enough to collect daily statistics of our user base, like how many people have upgraded.  If a announce-request is made and comes from an ID we have never seen, we add the OS and Armory version to the statistics.  Otherwise we ignore it.   That's it.  We added the unique ID so that we have a way to count unique users without logging IP addresses.    We also add the ability for you disable this by running with "--skip-annuonce-check".  

As a company, we have to have some way to measure our userbase, and we felt this was the least intrusive way possible.  And you can opt-out.

sr. member
Activity: 337
Merit: 250
Why is this code in Armory?  What purpose does it serve an end user of Armory?
full member
Activity: 154
Merit: 100
Here is where USER_HOME_DIR is set:
https://github.com/etotheipi/BitcoinArmory/blob/master/armoryengine/ArmoryUtils.py#L265

On my Windows machine it gets set to this: C:\Users\\AppData\Roaming

It seems to send the first 4 characters of the hash, enough information to distinguish between different Armory installations.
legendary
Activity: 1036
Merit: 1000
DARKNETMARKETS.COM
Wow, Armory devs, maybe you can tell us what is going on?
legendary
Activity: 3416
Merit: 1912
The Concierge of Crypto
This is something to consider, but I have not been using Armory because of two reasons:

1. Doesn't work on 32 bit XP.
2. Doesn't work with compressed keys.

I guess you could just block bitcoinarmory.com on your router or firewall.
newbie
Activity: 8
Merit: 0
The GUI gave me the impression that I had to press "Check for updates" before it would "dial home", apparently I was wrong.
I thought that too. All the better to ruin your privacy with I suppose.
Code:
DEFAULT_FETCH_INTERVAL = 30*MINUTE


I didn't see the comment where they admit its logged.
Code:
Use the verbose=True option to add OS, subOS, and a few "random" bytes that help reject duplicate queries.

How would they know if the requests are duplicate if they weren't logging them?

Pages:
Jump to: