zwavejs2mqtt was pulled from hass repo because of privacy violation.
https://github.com/hassio-addons/repository/pull/280
They claim this is the problem:
https://github.com/zwave-js/zwavejs2mqtt/pull/989/files
Can we reverse the telemetry commit or make it opt in only, please?
As someone about to run zwave-js, I'm surprised by this. I think this really needs to be default off; "notification" is totally inadequate for any kind of data transmission. This is particularly true for zwave where people might have locks.
I'm working on it. BTW I suggest you both to read what kind of data we are sending: https://zwave-js.github.io/node-zwave-js/#/getting-started/telemetry?id=usage-statistics
Thanks @robertsLando and thanks for the link. Seems like it would be helpful data. I'll opt-in, even though I generally do not. Thanks for all you do!!
As @robertsLando said, there wasn't a privacy violation. There was disagreement about opt-in vs opt-out and whether users were notified in advance (it was in the release notes, change log, and documentation), but there was some confusion at the project level about what users would be shown from those when upgrading with the addon, which none of us run. It's since been worked out and we've changed how it works. It's now purely opt-in with a pop-up and isn't enabled until you first return to the UI to elect yes or no. Certainly no one had any wrongful intent on our part and in fact the node-zwave-js documentation always required developers to disclose this before enabling the collection. This was never intended to be done in secret.
To be clear, nothing attributable to any actual person is collected or maintained. Records are not tied to an IP address and the IP isn't stored. Node-zwave-js has been modified today to use a salted hash of the home ID, even though the home ID isn't particularly sensitive. There seems to be some confusion around this...you'd need the user's home address to make use of the home ID and if you knew where they lived you could just park outside and intercept it with any hubzb1 running the zniffer software. It is of trivial importance and we just needed some unique identifier that was anonymous. Nevertheless, if it turns people off we'll use something different.
Nothing is collected regarding actual usage of devices such as if you're home. Just literally a list of devices connected to zwavejs and their info so we can better understand the ecosystem and prioritize features. As well as being able to use the aggregate number of devices from a manufacturer to garner collaboration from the manufacturer.
@gdt No information useful to breaching locks is in any way collected, not to mention those are included securely anyway. At most we'd know what model you use, which we could walk up to your front door and find out (if we knew where you lived).
While I understand your motivation and intention, I do not share the reasoning in your counterargument and do not believe this matter is at all open to interpretation. It is clearly a privacy issue, if any of the user's data is shared with third-parties without said user's consent. While not exclusively so, one of the key drivers for migration of users to HA is the notion that they are in control of their data. Many HA users strive to eliminate ANY "phone home" functionality in the components of their home automation systems. Incidents like this, erode public trust in the product, with respect to security and privacy, regardless of whether or not the add-on is directly produced by the HA development team. As one does not have to agree to any terms, licenses or policies, when installing the add-on, simply having the pertinent information in documentation, which the end user might or might not see, does not constitute consent. I would be surprised if an overwhelming majority reads dozens of pages AND understands the legal language in end user license agreements and terms of service documents before simply clicking the "Accept" buttons. Only later does it come out that Google, Facebook and Amazon know the exact route of your neighbor's dog walk last night :-)
Once again, I honestly believe that the intentions motivation here are pure, but please understand us as the end users.
As @robertsLando said, there wasn't a privacy violation. There was disagreement about opt-in vs opt-out and whether users were notified in advance (it was in the release notes, change log, and documentation), but there was some confusion at the project level about what users would be shown from those when upgrading with the addon, which none of us run. We'd talked to the HA devs about this last week but not the addon's maintainer. It's since been worked out and was just a misunderstanding. It's now purely opt-in with a pop-up and isn't enabled until you first return to the UI to elect yes or no. Certainly no one had any wrongful intent.
To be clear, nothing attributable to any actual person is collected or maintained. Records are not tied to an IP address and the IP isn't stored. Node-zwave-js has been modified today to use a salted hash of the home ID, even though the home ID isn't particularly sensitive. There seems to be some confusion around this...you'd need the user's home address to make use of the home ID and if you knew where they lived you could just park outside and intercept it with any hubzb1 running the zniffer software. It is of trivial importance and we just needed some unique identifier that was anonymous. Nevertheless, if it turns people off we'll use something different.
Nothing is collected regarding actual usage of devices such as if you're home. Just literally a list of devices connected to zwavejs and their info so we can better understand the ecosystem and prioritize features. As well as being able to use the aggregate number of devices from a manufacturer to garner collaboration from the manufacturer.
@gdt No information useful to breaching locks is in any way collected, not to mention those are included securely anyway. At most we'd know what model you use, which we could walk up to your front door and find out (if we knew where you lived).
I completely understand the concern, that's why we changed how it worked when it was raised. It was always meant to be disclosed and the node-zwave-js documentation requires developers to disclose to users before enabling. The misunderstanding on our end was about what users saw when upgrading in the addon, which none of us use. In any event it has been fixed.
Let's also focus on what would theoretically be shared. We'd go to manufacturer X and say, you should help us better support your devices because 10,000 of our users use at least one of your devices. That's the level of sharing we're talking about. Not the raw data and not any individualized information.
It is clearly a privacy issue, if any of the user's data is shared with third-parties without said user's consent.
We should clearly define what user's data means. If you look at what kind of data we collect you cannot say it's anything personal that goes against any privacy law. BTW the probelem has been fixed now and we are sorry if someone has feel 'cheated' by us

Thanks very much for making this opt-in. That truly resolves the concerns.
As for what data is "personal", I find that data even theoretically not connected to people, can be used to find out more than one might think, and that therefore the only safe policy is to transmit absolutely nothing off machine unless there is an opt-in.
@blhoward2 and @robertsLando , guys as I said above, I understood where you're coming from, I understand your motivations are pure in their nature and nobody here meant to "cheat" anyone. I'm also aware that the fix has been applied, so thank you for the great work! Your effort on the project is really appreciated by many!
I'm not trying to be a troll, pick a fight or get into an argument. I am also very much interested in your success and that of HA in general. The purpose of my comment above was to explain what it might feel like from the standpoint of an end user. Since I spent the last decade playing the role of an interpreter between technical and non-technical personnel, I ended up getting a good feel for what the non-technical crowd's understanding level and reaction to these types of issues typically is. In summary, unfortunately I doubt too many would read these threads at all, and if they did, I double they'll remember try to understand anything beyond the words "Privacy Violation". I know this sounds infuriating and frustrating, but such is life.
In terms of clearly defining what constitutes user's data, let's just say any bits flowing outside of my homework to the great wide web without me knowing about it, is an undesired behavior, to put it mildly. There's a reason I flashed a bunch of gadgets with alternative firmware, so I can get that little "warm and fuzzy" feeling that my house isn't being absorbed into some evil botnet, while I'm soundly asleep. Let's put it this way: even though your code is open source and even though I spent a good portion of my life in software, system and cybersecurity engineering, I really just want to install and trust a piece of code, rather than understand the architecture, review and test the code myself.
Imagine someone not incredibly technically savvy, who saw in a YouTube video that "Home Assistant is very easy to set up and is the way to go if you want to protect your privacy." Now image that person's initial reaction when they see the words "Privacy Violation" in their Twitter feed. That's basically all I'm trying to get across.
Once again, keep up the good work! Nothing but gratitude from me and I'm sure others.
Most helpful comment
As @robertsLando said, there wasn't a privacy violation. There was disagreement about opt-in vs opt-out and whether users were notified in advance (it was in the release notes, change log, and documentation), but there was some confusion at the project level about what users would be shown from those when upgrading with the addon, which none of us run. It's since been worked out and we've changed how it works. It's now purely opt-in with a pop-up and isn't enabled until you first return to the UI to elect yes or no. Certainly no one had any wrongful intent on our part and in fact the node-zwave-js documentation always required developers to disclose this before enabling the collection. This was never intended to be done in secret.
To be clear, nothing attributable to any actual person is collected or maintained. Records are not tied to an IP address and the IP isn't stored. Node-zwave-js has been modified today to use a salted hash of the home ID, even though the home ID isn't particularly sensitive. There seems to be some confusion around this...you'd need the user's home address to make use of the home ID and if you knew where they lived you could just park outside and intercept it with any hubzb1 running the zniffer software. It is of trivial importance and we just needed some unique identifier that was anonymous. Nevertheless, if it turns people off we'll use something different.
Nothing is collected regarding actual usage of devices such as if you're home. Just literally a list of devices connected to zwavejs and their info so we can better understand the ecosystem and prioritize features. As well as being able to use the aggregate number of devices from a manufacturer to garner collaboration from the manufacturer.
@gdt No information useful to breaching locks is in any way collected, not to mention those are included securely anyway. At most we'd know what model you use, which we could walk up to your front door and find out (if we knew where you lived).