Hello,
> I would strongly argue that you joining a chatroom does not mean you
> fall under the ICO's remit, even if you store a copy of messages from
> others you see, and even if you paid for the purpose.
>
> Here's another example: If you buy a magazine related to your
> profession (say, a computer programming journal), then they may
> publish a letters page. This is surely an equivalent situation.
>
> Similarly, you don't have to inform the ICO that you occasionally get
> phone calls or receive a text message on your mobile - even if you
> *shock* store the phone numbers you received them from on your phone.
> Forever. The same reasoning has to apply for 1:1 messages you receive.
However I am not only the client here, I am both the client and the
server.
In your interpretation you are seeing only the client, and not the
server in the mix, the client server is what connects to the remote
server, therefore storing and processing data which is for a client.
This could surely alter the interpretation no?
No, the question isn't "client" versus "server", those are low-level technical distinctions. Do not, ever, try to apply a technical meaning to a legal document, there's a lot of impedance mismatch you'll find yourself tripping over.
The GDPR does talk of "offering a service", but that is a business meaning of service, rather than a technical one.
My server could be peering with a "corporate" or "professional"
servers, I guess its important to read the entire GDPR and not just
rely on the ICO regurgitation of the legislation.
Your stuff (client, server, etc) is accessing a service offered by those other servers. This is no different to you accessing, I dunno, a discord server over a web browser. The GDPR affects the service provider (or more accurately, the controller and processors).
> Now, if you offer others the ability to join your server, you're
> clearly offering a service and that puts you firmly into the GDPR,
> whether it's family or not.
Not exactly, quoting ICO from the previous email:
"This means that if you only use personal data for such things as
writing to friends and family or taking pictures for your own
enjoyment, you are not subject to the UK GDPR."
They literally state messaging friends or family does not fall under UK
GDPR, this is the purpose of my XMPP server, therefore I do not believe
this would be an issue.
Ooooh... Nice try. So if you have a falling out with your cousin and they demand you delete their account and associated data, you think that the GDPR won't apply? Good luck with that.
If "friends" were a concrete exemption - it's not - then an organisation could declare all its users to be friends.
> Similarly, hosting a chatroom may also put you under the GDPR. You
> may need a privacy policy, and may need to obtain consent. However, I
> think this one is something of a grey area, and you might find there
> are legal arguments for an exemption there.
I doubt you can exempt this.
At it is, MUCs are a little bit of a difficulty... images are from each
individual MUC the user is from, this therefore means clients which
auto-download are feeding data to other MUCs without consent, if this
MUC isn't registered, then there are issues.
Well, to be clear, I think the structure of XEP-0045 would make an argument for exemption pretty interesting, but it's also a useful defence by dint of being a published interoperable standard. You'll note that, for example, you don't need to explicitly offer consent to use a DNS server, despite the fact they may not only log your IP address (gasp!) but also process your IP address data (shock!) to detect security issues. So I think it may be possible to exempt a self-hosted MUC from GDPR consent requirements. Whether that means it's exempt from registration I don't know.
I suspect that the finding would be that a MUC hosted for reasons other than being purely personal would need registration (ie, the £45 a year), but not consent, at least for a standard MUC service (including MAM and the other expected features of a typical chatroom service).
You could also use the same argument against http upload as a whole, a
foreign user is requesting data from your server, you are providing a
service to them to share a image.
Yes, HTTP upload is a privacy nightmare. It's also a general problem for federated services where the clients lack full connectivity; like they're behind an enterprise firewall. Or over a low-bandwidth radio link. But I think that from a GDPR point of view, it'd only become an issue if you were deliberately abusing the privacy issues to tie a user's identity to the IP address for further processing.
Again, "service" here is not the same as the technical meaning. Your own HTTP upload service isn't a thing you offer to everyone, it's a thing you have to run to send people pictures of cats.
It does seem after further look into GDPR, one downside is that it
appears to be a kick in the balls to start ups which need to go through
the legal headache (and also small fee from SCO), and then for
individuals wanting to self host, the more I delve into it, the more it
seems that it effectively kills any self hosting which is
WAN-accessible.
That last is certainly not true. There are a swathe of exemptions from consent and other GDPR related issues which mean that unless you're doing something pretty odd for a self-hosted site, you're good.
However!
If you do cookies on your purely personal website, you still need to ask for consent because of the EU Stupid Cookie Thing of 2002.
Also there might even be a case against clients which default to
downloading images automatically. As a user you have consented to your
provider storing information on you, but in a MUC a client which
automatically downloads images is, without consent, connecting to
foreign servers which could log IP addresses (which are considered
identifiable information). Surely there should be a pop up warning you
"Hey auto downloading of http uploads is enabled, this will share your
IP with federated servers", you then consent to this and all is good.
Or thats my understanding at least, I am sure there is some way this is
fine.
I don't think you need to ask for consent here. It might need to be noted in a privacy policy (probably not) and it would certainly be a good idea for a client to note this at some point in their privacy guide (ie, not a legal requirement just a nice thing to do).
Dave.