On Tue, 16 Apr 2024 at 01:22, Polarian &lt;polarian(a)polarian.dev&gt; wrote: 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. 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). 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. 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. Some further info here: How to satisfy GDPR's consent requirement for IP logging? - Law Stack Exchange <https://law.stackexchange.com/questions/28603/how-to-satisfy-gdprs-consent-requirement-for-ip-logging> 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 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. 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. 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.

s/SCO/ICO/ I am exhausted, apologises for mistake :) Take care, -- Polarian GPG signature: 0770E5312238C760 Jabber/XMPP: polarian(a)icebound.dev

On Tue, 16 Apr 2024 at 12:58, Polarian &lt;polarian(a)polarian.dev&gt; wrote: When the courts decide... Sorry, that's an unhelpful answer, but it is accurate. 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. Mmmm... I think that's a grey area. Individuals running services certainly are covered by the GDPR. 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. 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). 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 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). The EU Stupid Cookie Law has been copied to UK law, and isn't part of the GDPR. Sucky law. Yes, but it's not the client's responsibility since they are neither the controller nor processor at this point. Dave.

I'm going to put to general issues with the GDPR here, and refer back to them: Firstly, there's a distinction to be made between "exempt" and "out of scope". You ideally want to be out of scope. If you're in scope but exempt, then you're still subject to the GDPR in every respect, just formally exempt. So, for example, law enforcement is exempt - but they still need to be subject to the GDPR and register etc. Nothing we do is likely do be exempt. But, if you or I say "exempt" we should assume we really mean "out of scope". Secondly, the GDPR doesn't (as is popularly understood) require consent for all data; it requires a "legal basis" for all data processing, and one of those legal bases can be "legitimate interest", which in turn covers things like "I need this to provide the service", or "I need this to have decent security", or "I just kind of wanted to do this and I have more lawyers than you do". It's only things that are truly optional that you need consent for. On Wed, 17 Apr 2024 at 00:31, Polarian &lt;polarian(a)polarian.dev&gt; wrote: So, as per above, open source is likely not considered "purely professional", so if you provide a service based around open source, it may become subject to the GDPR. You are, however, unlikely to need explicit consent for any of it. I think even quite detailed data collection would be covered by "legitimate interest" as being required to ensure security, and if anyone argues wave xz in front of them. Yeah, except imagine bugs in contracts. ... while they're friends, at least. If you're ever in court over this, I'll testify as an expert witness on why some form of backlog is important. Right, so, I asked an actual DPO about this. (Being explicit, I'll attribute *every* statement the DPO made to the DPO, so you know what's the professional advice, but of course this is not taking all your circumstances into account and therefore don't legally rely on this) You don't need an actual DPO, by the way. But if the channel is for an open source project, then DPO says a basic privacy policy (somewhere) and an ICO registration would be probably needed. But unless you're doing extended analytics, then DPO says you don't need to worry over consent. If you don't have their account information to some degree, you cannot send them the chatroom's messages; this feels very legitimate interest to me. Yes, but also to the extent where the service is secure, etc, so slightly beyond what you're saying here. Not really - it's more around the intent than technical detail. Not quite - DPO says that the easiest thing to do is call the UK ICO helpdesk. They'll actually walk you through it all. That's not the definition, though, the phrasing used is "purely personal". I didn't ask the DPO about this case, but yes, I think as long as you can reasonably claim it to be "purely personal", then you're out of scope. You don't need to explicitly agree to a privacy policy; one just needs to be available, and you can assume that continued use of the service means the privacy policy is acceptable. You probably do need to tell people it's changed when it does. The only time you'd need to involve technical measures here is if you had consent requirements for optional features. Dave.