Trusting Zenarmor (fka Sensei) / Sunny Valley Networks

[jf2001j]

Concerning the data flow for

"Send Heartbeat: Every Zenarmor installation sends heartbeat information 3-8 times a day.

Heartbeat is a required functionality for the correct operation of the software and cannot be disabled.

The information shared in a heartbeat message is unique node identifier, IP address, Zenarmor software versions, platform version info, important Zenarmor configuration parameters, and Subscription related information like active subscription plan and number of devices in use."

and the error message

"Heartbeat is a required functionality for the correct operation of the software and cannot be disabled."

In my opinion, Sunnyvalley should check the position of the data protection supervisory authorities https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-22019-processing-personal-data-under-article-61b_en, in particular page 14 (section 3.1).

[mb]

Thanks @jf2001j, looking into that.

[almodovaris]

The only problem is if you tie such data to a person. If it is anonymised, it is not a privacy matter.

[GeoffW]

The only problem is if you tie such data to a person. If it is anonymised, it is not a privacy matter.

But it is.  The effectiveness of security measures changes over time and attacks only ever get better.  What was thought to be effective anonymisation today may turn out to be not-so-effective tomorrow, perhaps because someone has been very clever in their analysis of the metadata, or because an attack was made on the data in transit to anonymisation, or because mission-creep has introduced additional metadata that allows more dots to be joined.  Security and privacy are an ongoing concern.

[almodovaris]

Suppose you have a schools community with 10 schools at different locations, with more than 1000 persons. It is not prohibited to tie the data to a location, it is prohibited to tie the data to individual persons.

[GeoffW]

Suppose you have a schools community with 10 schools at different locations, with more than 1000 persons. It is not prohibited to tie the data to a location, it is prohibited to tie the data to individual persons.

Which highlights the sort of assumption that gets people into trouble.  If data collection assumes that linking data to a location is safe then it may tie data to individuals in homes, small business, or people working late or on weekends.

More obscure issues arise when product X identifies data by location and so does product Y, and if an attacker has access to supposedly anonymised data from both it can link the locations and draw conclusions not available otherwise.  If you follow the various security blogs you can read about researchers identifying individuals by linking several supposedly anonymous data sources.

Of course services may need to collect some data, but the security and privacy issues are not simple, and they are ongoing.

[jf2001j]

The only problem is if you tie such data to a person. If it is anonymised, it is not a privacy matter.

I think that is not correct. The procedure is basically subject to the GDPR regardless of any subsequent "processing" on the server. Already the "collection" from the firewall (always with IP address, but according to text at Heartbeat also with "unique node identifier").

In addition, one must also see the legal regime separate from the GDPR, Article 5 Section 3 EU Directive 2002/58 (as amended in 2009), which regarding the "storage" and "readout" of information (regardless of the personal reference!) sees strict interpretations regarding "absolute necessity" and "expressly desired by the user".

Back to the personal reference of the GDPR:

There have been several ECJ rulings on personal reference (e.g. via IP address; like C-582/14), i.e. when there is basically the possibility of identification.
Arguments:

• Here one must see the IP address of the firewall.
• Also, a static/long-lived identifier (as in Heartbeat: "unique node identifier") is explicitly listed in Art. 4 paragraph as "identification number".
• In addition, a fingerprint could already be created via the interaction of the information transmitted during the "Heartbeat" event, which would make recognition possible.

In my view, there is no legal basis for "Heartbeat".

• There is no "necessity" for a contractual basis (6.1.b GDPR) (the Zenarmor firewall functions also work without notification that an instance is online; of course, cloud management does not work, but that is already optional). The supervisory authorities have a strict understanding of the "core" of the contract.
• Likewise, consent (6.1.a GDPR) lacks "voluntariness" (7.4 GDPR).
• "Legitimate interest" would be conceivable (6.1.f GDPR), but then it is irritating why a non-selectable checkbox (sounds like "opt-out") is offered. Also, I wonder what the "usual expectations" of the user are.
  
  For legitimate interests - cf. https://www.sunnyvalley.io/docs/opnsense/configuring/configuring-zenarmor-privacy-settings-on-opnsense-firewall#heartbeat-and-license-check :
  
  • There is reference to "license verification". But with the free license, this is not necessary.
  • Regarding "checks the state of packet processing worker" this is possibly a legitimate interest (low hurdles here), but in a weighing with the interests of the user I consider it very low and against it the interests of the user predominant.
    (Example: what does it help the user if the manufacturer finds out that his installation with free firewall license does not work anymore? There is no automatic help from the manufacturer).
  
  It might be the case - this is pure speculation - that the manufacturer wants to know about the number of running installations, but this potential "legitimate interests" of him is not listed (to my understanding) in the description of "Heartbeat". It would be preferable for the user if the manufacturer would allow a non-compulsory opt-out for the user (beside Art. 21 GDPR "on grounds relating to his or her particular situation"). Also I think the interests of the user are also predominant here.
  
  

I hope the manufacturer will check the current implementation.

[TheForumTroll]

Any update on this? Seems the last comment could use a reply, especially since there were good replies to the rest (which is very commendable btw.)

[mb]

Hi @jf2001j, @TheForumTroll,

Thank you for sharing your feedback related to the Heartbeat.

We appreciate your feedback. As shared previously, we believe we are lucky to be serving a technically sophisticated and privacy-conscious user community.

Indeed, this is helping us very much in our quest to provide a great security product without sacrificing the privacy of our users. Compliance with applicable regulations, including CCPA and the General Data Protection Regulation (GDPR), is of utmost importance to us.

@jf2001j, as you correctly pointed out, there are several other technical points where heartbeat messages are helping us to improve the quality of the software:

The information about the number of unique installations provide us insights on several key performance metrics:

• Pro-active detection of software problems: After every release, an unexpected drop  in the number of deployments generally signals us that there might be a software problem affecting some of our users, which allows us to act proactively and start a remediation process without any delay which might impact an even greater number of users.
• Ability to understand how new capabilities shipped with a new release is perceived by our users: We are able to assess this from an increase in the rate of new deployments after a software release.
• Understanding how the software is performing on a newly introduced vs existing platforms: The platform information in the heartbeat provides us this information.
• Understanding which releases are being used and on which platforms & versions: so that we can decide safe EOL dates for supporting individual platforms and releases
• Understanding which platforms Zenarmor is being deployed on, helps us focus our porting and integration efforts.

Also, the number of unique installations information allows us to provide this KPI to our investors so that they have an understanding of how the software is perceived in the field. This is one of the reasons with which we can justify a free tier in the eyes of our investors.

We take it as homework to add this information to the help section of the Heartbeat selection.

Regarding whether IP addresses and similar information which do not directly identify the user:

While we were working on the latest version of the PP and ToS, although there are several interpretations whether it's personal information or not, we decided that it would be safer if we handled them as sensitive information.

To that end, we've placed the necessary security mechanisms in place. The relevant sections in the Privacy Policy ensures that this information is legally safeguarded.

We respect an individual's right to have a differing opinion with our view of this data as information  necessary to maintain our quality of service to our installed user base. We take very seriously our responsibility to protect all data from any purpose other than what’s been stated. We appreciate that individuals or organizations may not wish to share any data when using our service. In this case we understand their decision to uninstall and discontinue the use of our software.

Your feedback is well noted and appreciated. We’ll continue to carefully consider your input in our decision making processes as we continue providing the best possible service to our customers. Thank you.

[firewall]

@mb has there been reconsideration of allowing users to disable communication with sunnyvalley servers? you seem to have focused on the riders in this thread vs. the arguably more significant group. on one hand you have existing forum users whose ignorance of privacy maintenance rush to defend something they've already installed. on the other, several users created a forum account to add their concern after searching the web for similar answers.

how did your opportunity cost analysis manage to suggest that you forego an unknown number of free users in favor of data collection?  how many of those same users could have been upsold & transitioned to your saas offering over the last 3 years? i imagine those KPI might also be valuable for to the investors you reference, yet you're operating blindly.

i've spent quite a bit of time with tools such as suricata, wazuh, maltrail, security onion / zeek / elk stack, zabbix / nagios in the interim, and i've found some combination thereof to meet (if not best) my understanding of zenarmor features & functionality. though i'd enjoy familiarizing myself with zenarmor i'm patient enough to wait for our ability to operate it in the absence of data collection. after all, you don't need it.