Hello, On Sun, Jan 31, 2010 at 09:56:41PM +0000, Dee Earley wrote: Right. Okay. It depends what you want to see. Let's go through the ways in which BitFolk staff need to use your data first.. - Your outgoing traffic is automatically sniffed for SSH SYN packets in order to automatically detect SSH scanning activity. Time, source IP, source port, destination IP is stored. It isn't reviewed by a human unless an alert fires, and it's considered the customer's personal information. - If there is any sort of abuse report or indication of possible abusive activity, or a problem with the customer's service or any other sort of operational need, we sometimes need to be able to sniff the customer's traffic in order to work out what is going on. We don't want to have to ask for permission before doing that. Any data stored is deleted once the problem is worked out, and it's again considered personal information. - If your VPS is not responding or is using an abnormal amount of disk IO then we need to be able to look at the customer's console output to see if it's properly locked up, if it's in an OOM death spiral, etc. Again we don't want to have to ask permission. Now, as regards the actual data on the customer's VPS, we don't consider it personal data in the same sense as the Data Protection Act defines personal data. The customer's filesystem data isn't data that BitFolk has collected about the customer, and we don't store and process this data for our own purposes. It's whatever the customer happened to put on a service provided to them. - Customer data may be automatically accessed for backup purposes, and moved between hosts as required. If the customer makes use of the backup service then it will be duplicated one or more times for that. When the customer's contract ends (or is broken by the customer) we may decide to keep the data for up to 3 months before deleting it. If requested it will be deleted as soon as the contract ends. Backups will be deleted immediately. - If the customer's service has been or is likely to have been compromised and abusive behaviour has been detected, the first step is to prevent the abuse from leaving the virtual machine. This is usually accomplished by turning off its network or applying firewalling. Next we expect the customer to work out what has gone wrong. If the customer is unable/unwilling to work out what's gone wrong then we have to make a call between looking ourselves or saying goodbye to the customer, because it's pointless setting up a new VPS if we don't know how it got compromised. If we decided to investigate this for the customer then we would ask for permission to look through their OS and possibly data. - We can't explicitly list every possible operational situation that would require us to access your data, so it is always possible that something new will happen. In general except where detailed above we will try to ask permission first. In terms of what it is POSSIBLE to access, the customer should consider that all of their data is accessible to anyone with root on the hardware they are hosted on. The block devices can be directly read, even encrypted block devices can have their keys read out of guest memory. If you're making use of the backup service then you have most likely given root access by SSH key. You can narrow that down to specific hosts, and http://troy.jdmz.net/rsync/ contains a script you can use to allow access through an SSH key that can only call rsync. If this is what you were looking for I can tidy it up a bit and add it to the dpa page. Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting "The electric guitar - like making love - is much improved by a little feedback, completely ruined by too much." -- The League Against Tedium