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?
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.
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.
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.
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.
The centre server hosting the MUC would ultimately be the one
responsible for the data, seen as its the one who would (possibly) have
logging and storing messages in MAM, furthermore its the one which is
making the connection to all the other servers users are from, and thus
it is the one which can see where all the messages are going.
I can see a very strong argument against hosting your own MUC and
against the use of http upload when joining federated channels, I think
there is a good chance this would remove the exemption and make you
liable for GDPR.
Again, not looking for definite legal advice, just wanting to see what
others think on the situation.
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.
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.
Take care,
--
Polarian
GPG signature: 0770E5312238C760
Jabber/XMPP: polarian(a)icebound.dev