Request for Project Removal Due to Security and GDPR Compliance Concerns

[frankgrowatt]

Dear Johan Meijer,

I hope this message finds you well. My name is Frank, and I am an Aftersales Engineer at Growatt. I am writing to address concerns regarding your project on GitHub, which is designed to intercept and forward data streams intended for Growatt’s monitoring servers.

We appreciate your interest and the innovative effort demonstrated in your project. However, it poses significant security and privacy risks by potentially exposing sensitive information and compromising the integrity of our monitoring systems. Moreover, this practice appears to be in conflict with the General Data Protection Regulation (GDPR) enforced in the European Union, which mandates strict guidelines on the processing and transfer of personal data.

Given these concerns, we kindly request the removal of your project from GitHub to maintain the security and reliability of our services and to ensure compliance with GDPR. This action is crucial to prevent any potential legal issues and to preserve the trust of our customers.

We are open to discussing this matter further and exploring potential collaborations that comply with GDPR requirements. Please feel free to contact me directly by sending an email to [email protected] and mentioning my name, Frank, or by calling us on +31(0)85 040 9967 and requesting to speak with Frank. You can also find our contact details at https://nl.growatt.com/support/contact if you need more information or want to discuss potential next steps.

Thank you for your understanding and cooperation.

Best regards,

Frank
Aftersales Engineer
Growatt New Energy B.V.

P: +31(0) 85 040 9967
E: [email protected]
W: www.ginverter.com

[rany2]

However, it poses significant security and privacy risks by potentially exposing sensitive information and compromising the integrity of our monitoring systems.

Wouldn't removing all modes that rely on the main Growatt server be enough? There is a mode that is fully standalone and therefore would not impact your monitoring systems. Further, Grott doesn't send any data to third parties unless specifically configured to do so.

[tabascoz]

You see things really being upside-down. I knew of Grott project before purchasing Growatt. Grott was key factor for me to opt for Growatt hardware as it would allow me to leverage automation.

I knew their security wasn't great and having a server running and ensuring our data is not flying around gave me an extra layer of confidence. now they want to shut down the project... funny world...

[patcher-ms]

@frankgrowatt

Also, if the data collected is changed and then sent to our server, we won't be able to identify the changes. We have clients who expect very accurate data readings, and differences as small as 5% compared to their energy bills can cause dissatisfaction.

I have very bad news for you. Regardless of what Grott does your server isn’t authenticating the clients. This means that a malicious user can just connect to your server and push arbitrary data to it. As long as they get the format of the messages right and they can write any inverter id and datalogger id they like in the messages.

Now that I think about it, I am seriously concerned a sufficiently motivated attacker could get information like WiFi network name and password from your servers with a malicious client. If that can actually happen it would be super bad.

[tabascoz]

@patcher-ms thanks for letting us know. @frankgrowatt let us know your comments about this "potential" Critical vulnerability in Growatt end, how you're protecting my data.

[JaykeMeijer]

Therefore, we ask that if you wish to change the service IP, please get in touch with us first to discuss the risks. It's important that you inform us and agree to take responsibility for any data leaks that may occur from your inverter.

What if users use a private DNS to change the DNS resolution of server.growatt.com to their Grott installation? Then they are not changing the service IP.

By using Grott, the user is consciously deciding to extract the data from your ecosystem. That means they are inherently accepting the responsibility for security of that data. No authority is going to prosecute you because a user leaked their own data by extracting it from your system (unless perhaps, it is deemed that you did not implement the proper security controls to prevent data extraction in the first place, such as sufficient encryption *cough*). What if the user downloads the data from your interface, and then it gets leaked. That also would not be on you. This is the same situation.

You could ask that Grott states explicitly in their README that by using it, you take responsibility for the security of that data, that might be fair.

You're never going to get control over what users do with your system by saying "you can't do that". If you're worried about the impact that has on data, ensure that you protect that data with proper security controls. Trying to force end-users to behave in a way you want because you failed to secure it, is a statement of lack of control from your side. If one of our developers came to me during a security review stating "we didn't secure it properly, but we'll tell the users not to misuse it", I would whip their asses back to the drawing board faster than you can say "approval denied".

[rany2]

No authority is going to prosecute you because a user leaked their own data by extracting it from your system (unless perhaps, it is deemed that you did not implement the proper security controls to prevent data extraction in the first place, such as sufficient encryption cough).

Well, grott isn't even extracting it from Growatt's systems. It is just being analyzed while en-route to Growatt. There is an "encryption" scheme but I think it's just a simple XOR cipher if I'm not mistaken, so it was easily defeated.

Edit: I guess it doesn't help that the key was just "Growatt" but I am doubtful that the intention was to make it difficult.

[patcher-ms]

@frankgrowatt what exactly are the "significant security and privacy risks by potentially exposing sensitive information and compromising the integrity of our monitoring systems" you are concerned about?

Your product page claims data is encrypted, which should be enough to give you all the guarantees you need, if it were implemented properly. Well, proper encryption would make implementing software like Grott impossible so you might have some work to do.
Even with the current "encryption" scheme, you could always sign your messages and that would guarantee that the data has not been tampered with.

Talking about potential GDPR violations, why is my ShineWifi sending back to Growatt servers the name and password of my own WiFi network? That doesn't sounds great.

Said that, let's move to some constructive feedback.
There are broadly three categories of users:

• people who are happy with what your server provide and don't need anything more than it;
• people who are happy with ShineServer but also want to build some sort of automation. For them rich API access would be useful. I myself asked for API access before looking into Grott and sadly never got a reply to my message. For this category Grott is a really good way to get what we want done;
• people who want to manage thing on their own using alternative tools like Solar Assistant that get data directly from the inverter and completely sidestep your server side.

If Grott were to go away my guess is that unless you provide way richer API many people would abandon ShineSever entirely and move to Solar Assistant or other comparable products instead.

As a user my wish list would be:

• API access, which would allow some people to entirely get away without needing Grott or similar software;
• a better documentation of the protocol used between ShineWifi and ShineServer for people who need/want to still use software like Grott. There is a lot of guesswork involved at the moment, which frankly is quite risky when it comes to messages that can are sent to the inverter;
• actual encryption between the ShineWifi and ShineServer, which would get you close to your security goals regardless of an user is using Grott or not;
• an official supported way to use software like Grott. It doesn't even need to be a proxy between ShineWifi and ShineServer. ShineWifi could be configured to push data to ShineServer (with proper encryption and authentication) and optionally to another server (again, with proper encryption and authentication).

People here just want to be able to get data from their inverter (e.g. to put it in personal dashboards) and to be able to write integrations. I believe everyone is going to be happy if we know that the data can safely reach ShineServer (currently it doesn't!, even without Grott) while we are still able to write our own integrations.

[frankgrowatt]

We have received the concerns and have discussed the issue with the legal department. Before pursuing any legal action, we would like to make contact with the author first.

This is why I stated:

We are open to discussing this matter further and exploring potential collaborations that comply with GDPR requirements.

[tabascoz]

Before pursuing any legal action, we would like to make contact with the author first.

Now it sounds like a real threat. Nice.

Although you didn't answer my question: Are you talking on behalf of ""Growatt New Energy B.V." ? Without this answer, i am not wasting my time anymore with you. I have other things to do.

[frankgrowatt]

Yes, I am talking on behalf of ""Growatt New Energy B.V."

Actually I just help someone saw this thread applied an API token.

[tabascoz]

Great to you growatt. you lost a customer.
have a nice day.

[johanmeijer]

Yes, I am talking on behalf of ""Growatt New Energy B.V."

Actually I just help someone saw this thread applied an API token.

@frankgrowatt please explain.......

[tabascoz]

Frank,

You didn't answer none of my questions. I'll put it again:

• What is the GDPR clause this project is not-compliant? You're mentioning a law, it's best to clarify or it may be misinterpreted.
• What are the Security risks Grott has?

However, Grot is unique in that it has the potential to intercept and forward data streams to unknown third parties.

Yes, it is possible IF a user wants. Not mentioned in the project guidelines. Users are FREE TO DO IT if they want. Don't think anyone consuming Grott needs Growatt babysitting them.

As you mentioned, this is possible if specifically configured to do so. We would be subject to lawful punishment for not managing our users' data properly.

What did i mentioned? Where? you're putting words on my mouth, please do speak for yourself.

The concept of Grott Server is also a brilliant idea, but it could potentially harm the interests of our collaboration partners who have invested heavily in building monitoring software for their clients.

This is all the point. It harms Growatt interests. And you want to prevent it. Good luck then. Good luck with Johan and all other forks. I am EU citizen, you trust me I know my rights. As a customer, i really don't like the tone of this conversation.

No one is obligate to use any piece of software. If one install Grott and by any means it violates or brings any additional risks, you know (perhaps better than me) that Growatt would not be liable for such risk. Like buying a car and customizing engine and then putting the blame on Car's manufacturer if something goes wrong.

With regards to the API Calls, we have been testing this feature for end users since the beginning of August.

Ah, good to know. Where is the communication related to this ever being published? Why not contribute to the security of GROTT and integration with API if you're not "closing doors"? If Growatt makes available a better solution, free, where i have the right to send or not MY DATA to China, I would seriously consider migrating to such solution.

Hello, Tabascoz. Could you please review my response to @rany2 ? We are aware of this project because one of the end users has raised concerns. I want to emphasise once again that we will not close the doors, but we do need to know who is receiving the data.

Great that Rany2 got Growatt's attention. I haven't seen your response. But, as a customer, I never had such luck. I have tried twice to contact GROWATT to get firmware updates for the inverters to fix Inverter issues and NEVER got a quality answer from your company. The only real support i had was from fellow forum and community members. Perhaps Rany2 was luckier than me.

[frankgrowatt]

Frank,

You didn't answer none of my questions. I'll put it again:

• What is the GDPR clause this project is not-compliant? You're mentioning a law, it's best to clarify or it may be misinterpreted.
• What are the Security risks Grott has?

However, Grot is unique in that it has the potential to intercept and forward data streams to unknown third parties.

Yes, it is possible IF a user wants. Not mentioned in the project guidelines. Users are FREE TO DO IT if they want. Don't think anyone consuming Grott needs Growatt babysitting them.

As you mentioned, this is possible if specifically configured to do so. We would be subject to lawful punishment for not managing our users' data properly.

What did i mentioned? Where? you're putting words on my mouth, please do speak for yourself.

The concept of Grott Server is also a brilliant idea, but it could potentially harm the interests of our collaboration partners who have invested heavily in building monitoring software for their clients.

This is all the point. It harms Growatt interests. And you want to prevent it. Good luck then. Good luck with Johan and all other forks. I am EU citizen, you trust me I know my rights. As a customer, i really don't like the tone of this conversation.

No one is obligate to use any piece of software. If one install Grott and by any means it violates or brings any additional risks, you know (perhaps better than me) that Growatt would not be liable for such risk. Like buying a car and customizing engine and then putting the blame on Car's manufacturer if something goes wrong.

With regards to the API Calls, we have been testing this feature for end users since the beginning of August.

Ah, good to know. Where is the communication related to this ever being published? Why not contribute to the security of GROTT and integration with API if you're not "closing doors"? If Growatt makes available a better solution, free, where i have the right to send or not MY DATA to China, I would seriously consider migrating to such solution.

Hello, Tabascoz. Could you please review my response to @rany2 ? We are aware of this project because one of the end users has raised concerns. I want to emphasise once again that we will not close the doors, but we do need to know who is receiving the data.

Great that Rany2 got Growatt's attention. I haven't seen your response. But, as a customer, I never had such luck. I have tried twice to contact GROWATT to get firmware updates for the inverters to fix Inverter issues and NEVER got a quality answer from your company. The only real support i had was from fellow forum and community members. Perhaps Rany2 was luckier than me.

Hello Tabascoz,

I'm sorry to hear about your difficulties with Growatt. I didn't answer your question about the laws because I'm not an expert in that area. I will need to check with a colleague on this.

As an EU citizen, your data is stored on our European servers. We adhere to local laws everywhere, which means we use different domains for monitoring and API, such as:

For China: https://server-cn.growatt.com/ to https://openapi-cn.growatt.com/
For other countries: https://server.growatt.com/ to https://openapi.growatt.com/
For North America: https://server-us.growatt.com/ to https://openapi-us.growatt.com/
For Australia and New Zealand: http://openapi-au.growatt.com/

When it comes to Grott, there is no guarantee that the data is stored in accordance with local laws, which has raised concerns among some users.

You compared it to buying and customising a car and then blaming the manufacturer if there are issues. This is a common scenario for us; users often modify our products with various tools, and when something goes wrong, they blame us for any losses.

You can now request an API token from your installer. We are preparing a guide for our installers on how to do this. Alternatively, you can email me directly at [email protected], and mention my name, Frank. I'll help you get the API token.

You'll receive the token and the necessary documentation via email. I also regularly contribute (private time) to a collection on Postman for our users: growatt-public

[tabascoz]

Frank,

Although I understand is a great idea from Growatt to implement API, to discuss Growatt's API I would suggest you to open a new topic.

You came here talking about GDPR issues and "security concerns" where you didn't mention any concrete fact, other than "people my do stupid things" and we might be responsible for it. Like you said, this is BAU for any manufacturing company (I hope you know about that).

Instead of asking open source projects to shut down, you could work with your legal department to stamp a real disclaimer in Growatt Shine-X advising the users if they choose to run software that is not from Growatt, the company would not be responsible. Simple like that.

This is all i have to say about that. For now - total disappointment as customer.

Buy happy to participate and contribute to API. I have my servers registered and recently contacted Growatt Spain office to ask for latest firmware (where i received an outdated one - waste of time), so you know where to find me in your database.

Regards,

[robupham]

Hello Frank,

As a user of Grott, I wanted to add some input that may be helpful.

To be clear, Grott is installed and run by users themselves - it is not a SaaS service run by others. A Growatt customer must choose to install Grott themselves, then configure their Shine datalogger to forward data to Grott, which then in turn sends it to the Growatt Shine cloud platform.
I don't see any basis for Growatt customers to have concerns about privacy. If they don't wish to use Grott they're free to not use it. If they don't trust what Grott does with their data they can read the code.

Ultimately this is a purely optional piece of software a small minority of Growatt customers choosing to install and run themselves, to receive and manage their own generated data.

I could understand Growatt's concern if this were a service provided by Johann (or others) - but it isn't. Users must make the conscious decision to deploy and manage a Grott instance themselves.

[tabascoz]

Yep To add more:

In my case (perhaps many others) would like to have:

• Totally non-depend of cloud solutions (not for privacy but also for privacy). This is mission-critical operation for me and i cannot rely on internet connection for that.
• Ability to full control the inverter
• Ability to fully get and consume data from inverter
• Ability to fully monitor the inverter.

With that we create many things. If I cannot have it with Growatt hardware, which until now i consider a great cost/benefit solution, I'll find an alternative.

Although users like us might not be % relevant, we surely are a great parcel of opinion formers.

[frankgrowatt]

Yep To add more:

In my case (perhaps many others) would like to have:

• Totally non-depend of cloud solutions (not for privacy but also for privacy). This is mission-critical operation for me and i cannot rely on internet connection for that.
• Ability to full control the inverter
• Ability to fully get and consume data from inverter
• Ability to fully monitor the inverter.

With that we create many things. If I cannot have it with Growatt hardware, which until now i consider a great cost/benefit solution, I'll find an alternative.

Although users like us might not be % relevant, we surely are a great parcel of opinion formers.

We also support "Completely independent of cloud solutions" and the other 3 requirements. However, it will also require permissions, so sending an email to [email protected] is essential (if you are in the Netherlands, Belgium, Denmark, or Finland).

You can find local contacts for other regions on this web page: https://en.growatt.com/support/contact

[tabascoz]

@frankgrowatt many thanks for letting me know that Growatt supports it. But I am very happy with Grott and have no plans of moving away from it.

[frankgrowatt]

Actually, I assist numerous projects similar to Grott in creating new features such as intelligent management of charging and discharging based on the electricity prices. Both commercially and in open source, all are welcome.

[frankgrowatt]

Hello, @tabascoz, I've just asked Growatt Spain to review your cases. I'm hopeful that this time we can rebuild some trust.

[frankgrowatt]

Apply API token for end user via the installer

[JaykeMeijer]

Dear Frank,

Your request raises a lot of questions. I don't think the arguments you make for removal are valid.

Argument 1

it poses significant security and privacy risks by potentially exposing sensitive information and compromising the integrity of our monitoring systems.

First of all, this data can't be considered sensitive information (more on that later). Secondly, the decision to expose this data is not made by Growatt, but by the users who decide to install Grott. Therefore, Growatt has nothing to say about this.

As for compromising the integrity of your monitoring systems: Grott does not compromise the integrity of your systems, since it does not modify the communication between the inverter and your servers. It may impact the availability of these services, but given that you sell your inverters without the connectivity option in the first place, this can not be considered an argument.

Therefore, if there are concerns around the interception of the data, the responsibility falls on Growatt to ensure this data is properly protected. That means the implementation of proper encryption. If you consider the data being sent by your inverters of a sufficiently high risk level, as per regulations you as provider are responsible for implementing sufficient controls. For example, the upcoming NIS2 standard says the following:

entities take appropriate and proportionate technical, operational and organizational measures to manage the risks posed to the security of network and information systems which those entities use for their operations or for the provision of their services, and to prevent or minimize the impact of incidents on recipients of their services and on other services

If you argue that intercepting your data is a privacy or security risk, I'd be happy to file a report with the authorities against Growatt for insufficient protection of data. Your "encryption" scheme will most definitely not be considered sufficient by any standard.

Argument 2

Moreover, this practice appears to be in conflict with the General Data Protection Regulation (GDPR) enforced in the European Union, which mandates strict guidelines on the processing and transfer of personal data.

Can you tell us:

1. Which article(s) of the GDPR this practice appears to be in conflict with
2. What data the Growatt inverters send that can be considered Personally Identifyable Information

There are multiple topics about the subject of privacy of energy consumption and production data online, and all come to the conclusion that the energy data itself does not contain PII, unless it can be linked to a natural person(s). See for example:

Nulla questio for registration data provided by the data subject when entering a contract for the roll-out of a smart meter, i.e. name, address and information on consumer’s billing data and payment methods, which are unquestionably “personal data”. The conclusion is less undisputable when it comes to consumer’s “energy data”, which are identified by the recast Electricity Directive as metering and consumption data, and data required for consumer switching. While these data, at first sight, might be considered as technical data and, as such, deemed to fall outside the scope of the GDPR, they are actually – and inextricably - linked with the natural person who is responsible for the metering account via a unique identifier, such as a meter identification number. These data are therefore to be regarded as personal data because they are associated with an identified or identifiable user and disclose information on his/her energy usage, thereby providing insights on the daily life of the data subject. When the data subject is a “prosumer”, i.e. a small or medium-sized agent which both consumes and produces electricity, the “energy data” refer to the amount of energy and power injected into the grid, which in turn provide information on the amount of available energy resources of the data subject. (http://eulawanalysis.blogspot.com/2018/03/data-protection-and-smart-meters-gdpr.html)

Therefore, while this data should be considered PII for Growatt (since you link it with a natural person through the account creation), it is not PII for Grott since the data is not linked to an account or otherwise documented person. Even more so since Grott is only used to extract the data. How the user subsequently decides to store or otherwise process this data is not the responsibility of Grott.

In conclusion, this is nothing more than Growatt trying to bully a small open source project, because it may harm the economic interests for their own API (or, if you are a cynical person, harm the interests of the CCP in their attempt to gain control over the European energy grid). I, for one, am thousands of times more concerned about the privacy and security of the servers of Growatt than I am of Grott, where I have full visibility in the source code and know exactly what I am running on infrastructure that I am in control of.

[tabascoz]

@JaykeMeijer fully agree with your comments and conclusion. NIST 2.0 is very clear about responsibilities. But probably Frank is not either an expert in Information Security to properly comment.

[johanmeijer]

Dear Frank (@frankgrowatt),

Thank you for opening this discussion. It shows that Growatt is aware of Grott and recognize the added value of this open source project,

Seeing the reactions, a lot of people likes Grott as addon to their Growatt implementation (you should cherish this, it can be a reason people choose for Growatt), you should respect that.

As an IT professional dealing with privacy and security issues daily I do not see where Grott is violating any law or regulation in the data privacy area (Growatt might be, but that is not my responsibility).

Users of Growatt inverters (and Grott) can decide what they want to do with there own data. They can route it via a proxy like Grott, send it to third parties (like pvoutput) or can store it in a database or use mqtt to process it. Growatt has no saying about this . It is the consumers data not Growatt.

I really do not understand what you want to achieve with this discussion and the request for removing Grott from GitHub. It is a set of Python programs that people can use to process their own data within their own environment.

Grott as a proxy is not changing any data that is being sent from the inverter (datalogger) to Growatt (you can read this in the open code) and will not do any harm to the Growatt servers.

Grott might have capabilities (blocking commands, adding Grottserver to prevent sending to Growatt totally) Growatt does not like but this is all for securing the data owners privacy and data (and even helps you with solving the security problems you might have).

For now my decision is to NOT remove Grott. I do no see any compelling reasons why I should do this.

If Growatt wants to help to develop Grott in a way that the functionality will still exist and Growatt can accept it, you are more then welcome.

Please contact me at [email protected] if you want to discuss this further. As the Dutch are saying: I leave the ball with you (the ball is in your court).

[johanmeijer]

I added the following disclaimer:

By using Grott, you accept responsibility for the security of the data you extract. Neither Grott nor Growatt can be held responsible for data breaches stemming from the extraction of data outside of the Growatt ecosystem

(see: https://github.com/johanmeijer/grott/wiki/@disclaimer,-statement-of-use-and-limitations}

[PedroKTFC]

Just to add my 2d worth from the UK! I've bought my system and what I do with it is entirely up to me. I have felt compelled to use Grott AND grottserver because there is no flexible API available from Growatt. The use cases people will have for needing a flexible API are many and unpredictable. My particular one is probably very UK (and within that region) specific. As an Octopus Energy customer, once or twice a week I have 2-3 hours of free (yes, free!) electricity which (to date) can start anywhere from 9am to 4pm. I am informed of the period by email from Octopus Energy the day before.

I have implemented automations that process the email, set up various timed activities which, for my solar system, export as much electricity as possible before the free period leaving my battery almost empty (10%), fully charge the battery during the free period, and then reset all these timings and battery levels ready for the next free period.

The level of changes to my inverter's registers is too great to be performed manually every time (too time consuming and too liable to mistakes). So automation is essential and an API also essential. I couldn't see a way of doing that through Growatt's systems hence my turning to Grott and grottserver. Provide an open API and many users won't need to use Grott etc.

[tabascoz]

Congrats for your automation, Great! i wish i have something similar in Portugal :)

I think I'm better served with Grott and OS community and will not use Growatt API even if that came without the "talk with the installer to request API" bull****.

There are some other proprietary APIs around and i fell, as ITsec professional (and user) that the experience is worse. For ex. Tuya, Samsung, Siemens etc. all integrations where OS community figured out a way to bypass cloud it ended up having better results. My two cents !

[PedroKTFC]

There's a fundamental flaw with talking to the installer, what if they're no longer trading?!

[anoppe]

Apart from that, I just don't understand why companies don't want customers to talk to (technical) support directly for things like this. It's not that they are messing with the electrical installation or something similar which can cause unsafe situations.

Anyway, it seems that Growatt is taking its loss. Let's hope that they don't take measures and that Grott users that don't block their system to the internet won't suffer from it...

[rany2]

There's a fundamental flaw with talking to the installer, what if they're no longer trading?!

In my case, I installed it myself so am I supposed to contact myself? How would that work?!

[rany2]

Anyway, it seems that Growatt is taking its loss. Let's hope that they don't take measures and that Grott users that don't block their system to the internet won't suffer from it...

I ended up creating a quick server for my inverter: https://github.com/rany2/spf5000es-server but you'll need to hook it up to something like a Pi to get that working. Obviously not as elegant as using the dongle it came with but it is what it is. The modbus documentation is easily available online.

[frankgrowatt]

To apply API token for end user:

1. Apply API token for end user via the installer #575
2. If your installer cannot assist you, you can seek local support from Contact.
3. Send an email to [email protected] and specify your country and username, and our colleague at headquarters will also pass on your email to local support.