Replies: 2 comments 1 reply
-
|
Hi @damanic, Thanks for the follow-up. I understand your concerns about the remote code loading, and I appreciate you wanting to upgrade while maintaining your security standards. I would like to emphasize that our claims about not collecting user data can be easily verified by anyone. You can run Rotki in a completely sandboxed environment and monitor all network activity to see exactly what data is being transmitted. Furthermore you can open the developer tools within Rotki itself or use your browser's network tab to inspect every request and response. This provides concrete evidence of what's actually happening rather than relying on trust alone. Regarding the theoretical scenario you've outlined about data collection and user association, I understand the concern, but it's based on an incorrect assumption about how the system works. Regardless, I recognize that from a security perspective, you'd want to verify this independently rather than take my word for it, which is exactly why the verification methods above are so valuable. Unfortunately, since we are a small team, at the moment we don't have the development capacity to redesign how the premium feature distribution mechanism works. Restructuring this system would require significant engineering resources that we need to allocate to feature development and maintenance. This means the current architecture is what we can offer for now, and it's ultimately up to you as the user to decide whether you're comfortable proceeding with the premium features given these constraints. I completely understand if the current setup doesn't meet your security requirements. You can still test and verify the behavior using the methods I mentioned. If after your own testing you're still not comfortable with the architecture, then waiting for a potential future change in how we distribute premium features might be the right choice for you. I appreciate your interest in supporting the project through a premium subscription, and I hope the verification options I've outlined help you make an informed decision that aligns with your security standards. Best Regards, |
Beta Was this translation helpful? Give feedback.
-
The fetched code can change at any moment, there is no barrier to pushing through changes. So even if I have checked the code on my hosted instance and inspected network communication to be satisfied with the data currently being communicated to rotki.com, it can change at any moment without requiring my permission to update. There can be no concrete evidence because the code is not concrete. The only guarantee is to block premium code from being loaded.
There is no way to verify independently - you have to trust that there will not be a silent update that gathers data. If I set up monitoring and one day spot a malicious communication, it is too late. The only way to verify independently is for all code to be opensource and hosted locally with user permission required before any code change/update. Proposal for improved transparencyThere is good intention and messaging for this app in terms of privacy and security, for instance I get this warning:
I haven’t used the premium version yet, but I hope that on first login, users are shown a clear confirmation dialog. This dialog should explain that some premium features are not open source and are delivered via code imported from rotki.com’s servers. While Rotki states that no private data is transmitted to their servers, users should be made aware that the imported code for premium features — such as graphs or reports — has the technical ability to read and communicate the data displayed in in those reports. Users should be required to acknowledge and accept this before continuing. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @damanic, Thank you for the follow-up. I appreciate the thoughtful feedback, and we will take your suggestions into consideration. I understand your concern about a potential future compromise of the remotely loaded code. However, this architecture has been in place since the beginning of our premium features, and we maintain very tight access controls on both the source code and deployment infrastructure. Also, I want to clarify one important technical point: the imported code currently doesn't have the technical ability to communicate the data as you've described. What you're concerned about is the possibility that a future update might introduce such capability, which is indeed a valid worry, but it's important not to misrepresent the current technical reality. The architecture as it stands today doesn't provide these capabilities to the premium components. Look, I completely understand if this approach doesn't align with your security requirements. At the end of the day, it's your choice whether to use the product based on your comfort level with the current architecture. We respect that different users have different security standards and threat models, and what works for some may not work for others. We'll consider your feedback. Thank you again for taking the time to engage. Best regards |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi, @kelsos thanks for your thorough response on this discussion. It’s a bit unfortunate that the thread was locked, as I now need to open a new one just to follow up.
My main concern around security and privacy relates to the fact that closed-source code is being imported from a remote server, which has the potential to read data from the DOM and transmit it. Given that premium features revolve around reports and graphs, what prevents this code from accessing and collecting information about a user's holdings shown on their report views?
Since premium users authenticate their self-hosted instance with rotki.com and have paid for access, it's also theoretically possible to associate collected data with their IP address or perhaps even billing location.
I want to upgrade to Premium, as I cannot tolerate only being able to view 100 transactions, but I can't see how I can do that and still consider the application self hosted and secure.
Is there any chance you might review the way premium features are distributed so that they can be paid for, downloaded and installed by the user instead of injected from a remote source. I don't mind the application performing integrity checks over API, but all code needs to be self hosted and only updated by an approved update.
Beta Was this translation helpful? Give feedback.
All reactions