Hello,
> 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.
Ah... well I am not well versed in law, thanks for the clarification.
> 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).
I see the point, but where is the line drawn? When is it considered
professional/commercial?
When the courts decide... Sorry, that's an unhelpful answer, but it is accurate.
> 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.
This is a difficult one, just sharing internet with your family or
friends then makes you GDPR liable without this exemption. For example
I run OpenBSD on the router, my logs could contain personal
information, however am I going to get sued by family/friends for it?
Or will they simply say "hey could you delete my stuff" "yeah sure no
problem".
(I guess it depends on whether your family are mean enough to
go to the SCO to report you as well... most wouldn't)
GDPR wasn't designed to handle domestic use, storing family pictures
could then make you liable to GDPR, which would be a major headache for
every single person.
It seems unlikely to be a problem in practice, but yes, I think if you had an XMPP server that you offered accounts on to friends, you'd be very much skirting the GDPR.
On the other hand, if you just operate the router for your own home, then even if others are also using it I can't see that being a problem.
Remember, the law is intended to be "reasonable"; lawyers have often warned me over the years that technical folk tend to fall into the trap of seeing the law as some kind of computer program, but it's more like the specification for one, and there's therefore much "intent" to be assumed.
> If "friends" were a concrete exemption - it's not - then an
> organisation could declare all its users to be friends.
Organisations fall under professional/commercial use to its void
anyways.
An individual running a small chat server with his friends, shouldn't
break GDPR.
Mmmm... I think that's a grey area. Individuals running services certainly are covered by the GDPR.
I don't know how the EU enforces GDPR, but the introduction of the SCO
has added tons of overhead and a big headache to knowing when to pay
the fee, and when not to. Failure to pay the fee you will be fined.
Stupid system.
As far as the UK ICO is concerned, they're useless, so I wouldn't worry - I can't imagine they're organised enough to fine anyone.
For example, I am pretty much GDPR compliant anyways, my friends know
what I store, they agreed to it, and I will purge their data the moment
they want me to. The issue isn't complying with GDPR, but you only pay
the fee if you are not exempt, you shouldn't pay it if you are exempt.
So you must know where the line is drawn. (also becoming SCO registered
then gives you full liability)
> 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.
You must ask for consent for non-critical data storage, you only store
the bare minimum for whatever you are providing to work.
Again, it depends where the line is drawn here.
GDPR also takes protecting data seriously, so if you store extra data
for the sake of security, then you are still complying.
Yes indeed. Well. Sort of.
You have to ask for consent for anything that you don't have any other legitimate reason. "legitimate interest", however, covers a lot. (And, probably, a lot more than it should).
> 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).
I would argue it would still need consent.
XEP are extensions to the base protocol, the base still works without
MUCs, as MUC is an additional feature, surely permission should be
asked? Some clients don't even inform you if the server is logging or
if the logs are publicly available. These are NOT required for the
operations of a MUC. You could also argue that MAM isn't required and
you should ask permission to store peoples messages, OMEMO encrypted or
not.
Wait, no. So if someone joins a chatroom, then for that chatroom to work XEP-0045 needs to be supported, and in order to support a reasonable service you do indeed need to store at least some messages for at least some time.
This all might well need a privacy policy published, and might need an ICO registration if it's not for purely personal reasons.
So if you're running a chatroom for you and your friends/family to chat, in the same way that you have a family groupchat on WhatsApp, then I see no reason to need to register.
Similarly, HTTP is an extension to the base spec of IP, but if you use a website you don't have to consent to processing of your IP address, or indeed formally consent to having your HTTP requests processed.
The example the SCO gives for this (paraphrased :P):
A builder needs an address and a name to complete the work on a house,
they do not need to ask for consent to store this data as it is
required for them to provide their service, however the builder wants
to email the invoice to the client, they must request permission to
store the email address, as the invoicing is not required to provide
their service.
Only the bare minimum should be consent-less.
The invoicing is required, but what is not required is to send the invoice by email.
Similarly, nothing required to provide a chatroom service needs consent, but if you wanted to get more data that'd have to be optional and would need consent. Also, if you took the data and processed it more than was needed - for example, if you produced a top ten of people messaging, or ran analytics to determine whose messages were read first - then you'd need to ask consent for that processing.
Unless I am taking the examples too extreme :P
Yes and no.
The builder doesn't need to ask for consent for names and addresses, but the building work itself is still optional. A chatrooom is indeed an optional thing to have on a server - but if it's there, there are some fundamental requirements in order to provide that service.
> 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.
The thing is, there is two sides to http upload.
The uploader, which would definitely be a service, you are letting them
upload whatever file to share with someone else, and you are storing it
for them.
Yes, totally agreed there.
However you are then delivering this image to many different users,
this can also be considered a service, your server is serving a
download, its no different than a netflix stream (in fact you could
upload a film with http upload and then share it with all your
friends!).
Ah... If you were using it in that way, then maybe it would be a service. But if it's simply ancillary to sending cat GIFs, then not so much.
> 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.
SCO only mentions 3 exemptions.
The ICO mentions loads, actually, but personal use isn't one of them - that's simply out of scope entirely for the GDPR.
I only need to cross the exemption line once, even if its minor, to be
accountable for GDPR, or at the very least, the SCO registration fee.
I can't find anything on WAN accessible home services and GDPR/SCO
compliance, I looked around, doesn't seem people talk about it.
Is it just assumed SCO doesn't give a damn about some small server?
Most home services are things like a personal blog, and there's been lots written about those. An XMPP server is something different, but unless you're offering that as a service, I'm unconvinced it falls into scope. (And if you are, I'm pretty sure it does).
> 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.
Depends on whether this law copied over to the UK, and also depends on
the type of cookie. There is a cookie guide the size of the GPDR
describing the different types of cookies and when they are/are not
required to follow GDPR.
The EU Stupid Cookie Law has been copied to UK law, and isn't part of the GDPR.
Sucky law.
> 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).
In the privacy policy of your server you sign up with, which you
agree to, sure.
But in a MUC with http uploads from OTHER servers, you haven't agree to
their privacy policy and thus you are automatically downloading from a
server you haven't consented to, and haven't seen their privacy policy
(not like people read them anyways).
Yes, but it's not the client's responsibility since they are neither the controller nor processor at this point.
Dave.