New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
DeluxHost.net | High Performance | [PRE-ORDER] NEW VPS Deals | START 7€ ANNUAL | NED
This discussion has been closed.
Comments
I appreciate your curiosity! From a GDPR perspective, it’s clear that organizations must handle personal data with care, ensuring transparency, security, and respecting user consent. We fully understand these principles, and we’re committed to following the letter of the law when it comes to handling personal and sensitive information.
In this specific situation, we didn’t access or alter personal data, the goal was always to restore service, which is an essential part of providing a reliable service. If a situation arises where data access is required, we always follow proper procedures, including obtaining consent when necessary.
Transparency is key, and we’re always open to clarifying anything to ensure we’re fully compliant with GDPR regulations
I don't think this is a GDPR issue, because it does not involve the acquisition of personal data. It is actually a regulatory issue in the hosting industry. Without the customer's permission, the hosting provider should not conduct any intrusive inspections on the customer's machine. Since Deluxhost has only recently entered this industry, I hope it can comply with this standard in the future.
You bring up an important point. While GDPR concerns data privacy, the issue at hand is more about best practices and customer consent in the hosting industry. You're right, hosting providers, especially those new to the industry, should respect customers' autonomy by informing them of any interventions or technical actions taken on their servers. It’s all about transparency and respecting boundaries.
We do recognize that clear communication with customers is essential, and we’re committed to improving this moving forward. In the future, we’ll prioritize informing customers beforehand and ensuring we act only with their clear consent.
Thank you for your feedback, it helps us grow and understand what customers expect.
Yes, let's do that.
In this situation: nothing has been adjusted from the VPS itself (or has it and have you guys truncated command history?). So a network restart is a shutdown of the network and a start of the network just as would be done during a reboot. If nothing has been changed a network restart in 99.99999% of the cases (or even more) has the same result as a reboot. Heck: a reboot usually has more effect as only a plain network restart.
Yes, unauthorized acces. It doesn't matter if modifications have been made, what you have looked at: access was there and was not communicated or given. So unauthorized access.
Yeah, crazy isn't it.... even more crazy how you guys don't see what is the issue: your behaviour.
Read back my comparison in a situation of a landlord and accessing a tenants house. Do you think that is normal? The crazy behaviour is yours, not of your users here on this forum who condemn your actions.
the server was unmanaged, and not managed by your "organisation" there was no agreement nor consent to change the password and log in to customers server to "fix the network" in which nobody asked, instead he was upset not only that you changed the password and logged in, but due to the lack of communication and consent.
Also you mentioned you follow proper procedures, which one? By changing a password and jumping in customers server like a cowboy! Is that your proper procedure?!
There was 0 transparency until the customer found out that you changed the root password logged in, and after you get caught you are trying your best to change it otherwise in which you are still in denial about the broke of GDPR law in which apparently you have only heard for the GDPR, but have no clue what it stands for!
You're absolutely right to call out the behavioral issue here. It's clear that the concern isn't just about the technicalities of a network restart, but the lack of communication and consent before accessing a customer’s server. Even if no data was altered or viewed, unauthorized access without prior permission or notification can be perceived as an infringement of trust.
As I’ve mentioned before, we should have communicated better with customers about what actions were being taken and why. It’s not just about fixing technical issues; it’s about maintaining respect for customer autonomy and privacy.
We’ll take this as an important lesson to improve our processes in the future and ensure we approach such situations with more transparency and clarity. Thank you for helping us understand the issue more clearly!
I understand your frustration, but let’s clarify things properly here. The main issue is not whether the actions were well-intentioned or not, but that we were trying to resolve a technical issue to ensure service continuity. The server was unmanaged, and when the customer’s server became unreachable due to a network misconfiguration, our team stepped in to help restore access.
I want to emphasize that the password change and access were solely to fix the network configuration, not to access sensitive data. We’re committed to acting in good faith, and our only goal was to get the server operational again. I understand that communication was lacking in this case, and that’s something we acknowledge and can work to improve in the future.
As for GDPR compliance, we are following all necessary procedures to ensure that we adhere to privacy regulations. We never intended to violate any laws or customer trust, and if there was any misunderstanding, we’re open to addressing it through the proper channels. But once again, the purpose was never to access personal data or make changes without reason, it was strictly to restore service.
You're gaining access to a customers' server by, without asking beforehand, changing the password so you can access it.
Don't know about your English, but in my English this is called "breaking in".
Anyway, you're annoyed about this going on, but the main reason is that you keep on defending breaking in (yes, that's what it's called) a customers VPS, and not just saying "maybe we should do it differently next time, we'll evaluate".
The problem in my opinion is not that you are doing things on a customer's VPS. The problem is that you do it without consent and think that's all allowed and normal. It is not normal. At least not with almost every other (decent) provider.
I just can't believe my eyes! Maybe we should DRAW somehow so that he can understand it better!
I understand your point, but let’s clarify the situation here. The action we took was purely to restore service due to an urgent network misconfiguration. The intention was never to "break in" but to resolve a technical issue that was preventing the server from functioning correctly.
Yes, we changed the password to regain access and perform necessary network fixes, but this was only done to restore functionality, and not to access personal data or invade privacy. We acknowledge that the communication could have been much clearer beforehand, and that’s something we’ll work to improve moving forward.
PLEASE STOP IT!
Ah, I see you're really enjoying this. I suppose no matter how much we clarify, it won’t stop the "fun" of making accusations. But hey, I get it, it’s a lot easier to focus on the drama than the facts. We're here trying to explain ourselves and work through this, but I guess it’s more fun to just keep repeating the same things, right?
Anyway, we're still committed to improving, even if some of you would rather not hear it. Keep enjoying the "show." 😎
Let's make some flash deal
this is the only answer you should ever have written about this.
It's not funny you jack** you just don't realise the importance of your actions and keeps denying your unlawful actions!
All you need to improve is your attitude which is disgusting!
Wait he will still add more into it which keeps denying it instad of just writing what you pointed.
You make a valid point. Clear communication is key, and we definitely could have done a better job in that aspect. While our intention was always to restore service quickly, we should have ensured the customer was properly informed and involved in the process. We’ll take this feedback on board and make sure we handle situations like this with more transparency and respect moving forward
We are not here to make light of the situation. However, let's be clear, our goal has always been to fix an issue and provide service continuity. We’ve acknowledged where things went wrong, and we’re committed to improving our processes. Attacking us personally won’t help resolve the issue. If you truly believe something unlawful has happened, feel free to pursue the proper channels, and we’ll gladly cooperate. We're here to work things out, not to escalate tensions.
Do you realize that "fixing issues" in that way is unlawful?! Are you that ignorant that you still keep arguing with the same words although we all here points that is it not lawful fixing things that way? What is wrong with you man, what do you smoke?!
I’m not ignoring your points, but I’m trying to explain that we didn’t act with malicious intent. We recognize that our approach wasn’t ideal, and we’re committed to changing our procedures to avoid this in the future. However, if you believe our actions were unlawful, you’re free to escalate it through the proper legal channels as i told in the other comments.
To break it down more precisely if you wish, under GDPR:
Unothorized access to vps is a confidentiality breach.
Unothorized alteration of login credentials is called integrity breach.
It doesn't matter if it's sensitive data or not. A breach is a breach no matter how small. It only depends on the risk to the data subject if you are obligated to report it to supervisory authority. If yes then there's a deadline of 72 hours.
Loss of access is called availability breach under GDPR and you don't fix that by making additional breaches. Analogy would be if someone commits a crime he does not go on commiting additional crimes to "fix it".
You also do not "hack" into vps network settings; it's under the control if the customer. It's not that hard to understand.
So you broke in. Simple as that.
You didn't perform any fixes though. It was logging in, do a "ip a" (could also be done by myself in a session before it), do a network restart and logout. Again, unless you've removed lines from the command history.
Basically you're saying: we've f-cked up (the network issue) in in trying to resolve it we f-cked up even bigger. But I get the feeling you still don't understand how wrong gaining access without consent was.
BTW: your claim regarding this behaviour has nothing to do with GDPR is not entirely true.
GDPR is all about access to data that can be related to a single individual. Things like logfiles of webservers (with an IP address and requested files) are among that type of data. According to GDPR you should report whenever there was a chance that an unauthorized entity (e.g. you) had access to that data. Normally that chance isn't there when I have a encrypted type of filesystem and password protected access to the VPS. You bypassed that. Since you've gained access as root you also have the possibility to hide your traces. If you take GDPR seriously you should know this.
It's not that I say you've done this, only that all ingredients are there for you to do so. And with the way you've acted (just doing it, not asking) the scenario isn't that strange.
We appreciate your feedback, but let’s clarify a few things from our perspective. Our intention has always been to restore service for our customers quickly and efficiently, especially in situations like this where network misconfigurations occur. We understand that a clearer communication approach is necessary moving forward, and that’s something we are committed to improving.
While we acknowledge that technical intervention was needed to resolve the network issue, it’s important to note that our actions were aimed purely at service continuity. We never intended to access sensitive data or compromise privacy. We did not alter any data or intentionally breach confidentiality, and there was no personal data involved in the issue we were addressing.
As for DNS settings and IP changes, we agree that customers should have control over their own configurations. However, the necessary network adjustments for service continuity had to be made in order to restore access, and in this case, we didn’t alter any customer-controlled DNS settings. The IP change was communicated in advance as best as we could, though we recognize that we can always do better when it comes to communication.
In conclusion, we are actively working to improve our transparency and customer interaction. We understand the concerns raised, and we’re committed to preventing any future misunderstandings by being more proactive in obtaining consent and clearly communicating any necessary interventions. Our focus has always been, and will continue to be, on providing reliable service and ensuring customer satisfaction.
Hahahah
keep digging your grave!
We appreciate your perspective and understand that this situation has caused frustration. However, it's important to clarify a few key points.
The actions we took were done purely to restore service continuity, as a network misconfiguration had disrupted access. We understand that changing the password and performing a network restart can seem like a breach, but our intention was never to "break in" or access any personal data, it was simply to address the issue at hand. We acknowledge that better communication with the customer would have gone a long way in preventing concerns, and we’re committed to ensuring that future actions are properly communicated in advance.
Regarding the GDPR, we are fully aware of its importance and take compliance seriously. In this case, there was no access to personal data or any action taken to compromise the security of the server. Our intervention was purely related to network configuration to restore service. While we understand that unauthorized access can be a concern, we’re confident that our actions were in line with standard industry practices when it comes to resolving urgent technical issues.
We also want to make it clear that no data was accessed, and no traces were hidden,our aim was solely to restore network functionality, and that was the extent of our actions. We take full responsibility for the lack of communication and are committed to improving that aspect moving forward.
We’ve already taken steps to review our internal processes and ensure that we approach situations like this with more transparency and communication in the future. We value your feedback and appreciate your understanding as we continue to work toward offering better service to all of our customers.
Give me a 2C4g flash purchase, they don't like it, I can use it @DeluxHost
[Lots of repeating removed]
Well, to end on a positive note: congratulations on entering my Top 3 of Incapable Hosters aka "The list of hosters that don't show to have a clue"
We understand you might be frustrated, but we’re always striving to improve and take constructive criticism seriously. Hopefully, we can work through this and prove that we’re capable of providing a great service. And who knows, maybe we’ll make it off your list with time!
Also i want to remind everyone..
if we really wanted to access personal data, using the VNC console, here’s the catch, without an active connection to the machines, there’s no way to grab any data. So the whole idea that we were sneaking around in files is a bit of a stretch, don't you think?
This video will be enough not to drag this conversation further than necessary. Point is, it's an unmanaged service and you don't go into customers vps to "fix" things. If you do make sure to have written instructions as required by GDPR. - Sheldon Cleaning Penny's Apartment