So, until that, we now here Neil, we still talk online safety laws and the learnings from
a lot of pro bono work.
So, Neil, the process here.
Can you hear me at the back? It's my friend working.
It is working, but you can't hear me at the back.
Okay, thank you, thumb up.
Put it back on.
Right.
Hello, I'm Neil.
Some of you, I know.
Some of you, I don't know.
I'm a lawyer on the freight.
Look, nobody's perfect.
I would normally say, I'm not your lawyer, but looking around, I actually am your lawyer for
some of you here.
So, for those of you where I'm not your lawyer, if those of you who I am your lawyer, I am still your lawyer,
at the end of this as well.
Okay.
So, I run a small law firm and I run it almost entirely on free software.
And I spent a huge amount of time over the last 12, 18 months looking at online safety laws and
free software communities.
So, that's looking both at people who run free software in a way that
brings it within scope of online safety laws.
But also people who develop free software, which when people run it, brings them in scope of online
safety laws.
So, I'm talking today, predominantly, from the point of view of people running these services,
but it also has an impact on people developing these services, developing the software that
powers these services.
What can be built into things to help with some of this?
So, I'm talking about online safety laws and I'm in English lawyer, I can only advise on English
law, but other places are thinking about online safety laws as well.
So, although my focus is on the UK's online safety act, there are online safety laws in Australia,
there are online safety laws in some states in the USA, and there's an awful lot of
conversation about other online safety laws in other countries as well.
And they're not all the same.
They're not all the same, so if you're running a project that's available globally,
how do you think about compliance?
What I'm going to do, I'm going to paint a background picture first, not quite how we got to here,
but this is where we are.
And then talk through some of the considerations, some of the mitigations,
some that I've spoken with with others here over the last year or so, what can you do about some of these things?
But your starting question is, okay, all these countries have got or are developing online safety laws.
That's nice, so what?
Unfortunately, much as it would be great to be able to care only about the laws that apply in your country.
Lots of these laws purport to have extraterritorial effect.
In other words, they claim to apply to people outside their country,
not to people outside their country, where the servers are outside the country as well.
Now, I say purport, because what the law says, and what can be enforced,
aren't necessarily the same thing.
So I take an example from the UK.
The UK Telecom's regulator has just imposed a £1 million fine for breach of the online safety laws.
They've imposed this fine against a provider in embellis,
who has never engaged with any of the regulators' correspondence.
Hands up if you think that's fine is going to be paid.
And I don't know whether you're an optimist or a pessimist, but yes, either way.
There may be a purpose to bring that to imposing that fine to simply say, look, we can.
But to me, the chances of actually being able to get that fine paid to them has got to be really rather limited.
But these laws are claiming to have extraterritorial effect.
We'll talk a bit later, perhaps, about assessing the risk as to whether you really need to be worried about the extraterritorial effect of somebody else's laws.
So you've got a starting point, the laws aren't always the same in all the countries.
You've got the second point that sometimes these laws say they apply to people outside the country,
they may apply to you, even though there are laws of a completely different country.
And they vary in terms of this scope, okay, who he uses next cloud.
Gitsy, mastered on who follows me or mastered on.
I'm so sorry for that.
Loads and loads of everyday services brought within scope, okay, different countries take different approaches.
So I say brings them to the scope, I'm thinking from a UK point of view.
The online safety act encompasses services which lots of foster projects use.
Australian approach is to name specific services and to apply the rules to those.
That's a fundamentally different approach.
So you've got different countries adopting it in completely different ways.
You may recognize some of these services.
And while you're reading that, I'm going to try and re-attach this.
Can you hear me at the back still?
Sort of yes, but I'm judging by the fact you did anything at all means you can sort of hear me.
Okay, so a whole load of things brought within scope.
And much of the work I've done over the last year has been about these kind of things.
A free software project that wants to have a forum for its users.
The wants to have an online tool for collaborative generation of translations.
This is not the kind of thing that you hear about in Parliament.
This is not the kind of thing that comes up in online safety discourse and says,
someone who's been reading archwiky.
And nevertheless, wikies could be in scope, a service that allows users to see what other users have written in bash.
All sorts of things.
So we've got a plethora of different laws in different countries.
We've got countries that say that their laws apply to you even if they're not in those countries.
And we've got different scopes of those laws, some of which cover services that most of you will use multiple times a day.
So what? Okay.
We've talked about how we got to hear.
This is some of my thinking on perhaps what can we do about this.
Now, inevitably, what you do will depend on your own situation,
which is another way of the lawyers standard of it depends.
Okay? These are things that I've drawn on in the last year or so.
And the first one, can I just ignore it?
Can I let it all go away?
The answer is potentially yes, but it will be sensible to approach it in a pragmatic way.
And what is the genuine risk of enforcement activity?
Are you doing the kind of things?
Is it regulated going to be interested in you?
Because it's one thing for the law to say it does apply to you.
And it's quite another thing to find yourself a regulatory target.
Now, that's something that's much easier to access as a law is being on the statute books for a while with experience.
You can see some regulators publish regulatory priority lists.
You can get a sense from public discourse of the kind of services that people care about.
And you can make an assessment that, you know, maybe the forum for discussing predominantly among contributors of a particular software project
probably isn't as high up the list as some very large popular online platform.
There's still an element of risk in that, but you could make an assessment that that risk is relatively low.
You can make an assessment that the risk at that point in time is relatively low and keep watching and see how things develop.
But you may very well come to the conclusion that yes, there are online safety laws in various countries.
There are various laws that require different things in different countries.
And your plan is to do absolutely nothing at least for now.
That's a consideration in K.
So that's thinking about things from what risk does the regulation present to you?
What's the realistic risk of enforcement?
You could also look at this from a perspective of your own services,
or if you're developing software, the risks that someone running your software would face.
What actual risks does your software or does your service pose?
Can you try and mitigate that?
There are different ways of doing that.
I think a risk assessment makes sense.
There are lots of different ways of doing risk assessments and different laws may require you to consider different things,
or to do your risk assessments slightly differently.
From my point of view, having some form of risk assessment, I know some of you in this room have done online safety-related risk assessments,
because I've read some of your online safety-related risk assessments.
I know how to party, and they are not all the same.
But what they have each done is shown that someone has engaged with a subject matter that they've tried to think through the risks that apply to their service.
So, while some regulators may say you should do it this way, in some laws say no you should do it this way,
if you see it simply as a tool to think through risks in a structured way, great.
And okay, different laws, different regulators may require different things.
But, if you are working on a free software project, in a lot of cases this will be volunteer labor.
This will be volunteer time, and this will be volunteer skills.
Maybe you don't have the resources to cover every single different risk assessment to do it in every single different way.
Maybe in an ideal world you could, but if a regulator does come knocking and you've done something, hey, you've done something.
You've got something to show here that you didn't completely brush it to one side.
You weren't saying I've done nothing at all.
You're saying I've tried to engage with this in a way that's appropriate to our scope, our scale, and our services.
Will that sort of look, we've got something, will that always fly?
No, nothing will always fly, but it seems like a sensible way to try and approach it.
And there are some things that are going to come up almost irrespective of the country.
If you run a service that particularly aims at having child users, you are likely to be a high risk service.
And there'll be many people who run services that don't aim to have child services, but nor do they completely discourage them.
If you run a wiki for a niche Linux or BSD project, you probably do have child users, but you're probably not encouraging child users.
Having is what you're doing massively attractive to children, you know you're going to get loads of them, you know you've got loads of them, or is it the kind of thing where you may, but probably not particularly attractive.
And services which involve pornography, so alongside the work I do with free software, the other part of my pro bow and a work is predominantly for sex workers.
pornography comes up quite a lot in that context. In the free software world, I'm going to park that for now, but if you find that you have a four or more community where people are regularly posting pornographic images, that or or other pornographic content, that will be something to consider as part of the risk assessment from under almost any online safety law.
But sexual abuse material, so whether that's a potential for grooming, or a potential for image distribution or video distribution, again high priority, as is the terrorist bucket.
Unfortunately, terrorism means different things to different people trying to determine what is terrorist content may vary by country, but if you were to think through those four things for most services, you are covering things that most countries are likely to have at the top of their priority list.
Others will have other things too, that's not exhaustive, those are the things that I've seen come up time and time again in different countries.
So that's if you want to take an approach of what do we need to do to at least try and be compliant?
What if you wanted to slightly more than that? What if you actually wanted to do some good with this process?
Could you move beyond compliance, move from a mindset of what do we need to do to keep the regulator off our backs to actually, how could we use this to keep our users our community safer?
And can you create a better, safer experience for all users, but especially your more vulnerable users?
And when you start thinking through the online safety laws from that perspective, how can you do better, how can you build a better, richer, stronger, more inclusive community?
You start seeing things slightly differently, and it moves away from being a regulatory tick box exercise into a, oh just a minute.
Yeah, that could be used in a harmful way, but it's still a useful feature, what could we do about it?
And how can you lessen the risk of either the abusive use or the misuse of the services that you're operating for your community or the software that you're developing?
Okay, so we now have we got to hear kind of considerations what tangibly could be done?
I'm going to split this into three, but fundamentally the mitigations that you deploy will depend on the risk that you've identified.
It's very hard to try and mitigate something where you haven't already considered it to be a risk.
So I come back to that idea of a risk assessment, and if you are going to mitigate those risks, write them down as well.
Because then you can show if somebody comes, look, not only have we thought about it, we thought about what's an appropriate proportionate solution that's available within our budget time resources and whatever.
We can show we're thinking about these things in a way that a regulator's likely to see a mature organisation, a mature community.
So, your mitigations based on your risk is that you've thought about them, you've started to document them.
The first thing I talk about is something that Karen talked about as she opened the room today, setting standards and upholding them.
Clear, enforced rules or codes of conduct.
Accessible to everyone in plain language, there's no secret code of conduct.
There's no convoluted legalese.
It simply sets out these are the standards of behaviour that are expected, and that they apply to everyone.
Now, this is an area where I've seen numerous contexts and also free software projects.
That the rules may not apply to everyone equally.
Very difficult to enforce a framework where some people get special treatment and others don't.
But I'd start clear behaviours, this is what we expect, this is what happens if you don't.
The second bucket is reactive, dealing with harm that's already happened.
Now, I'd hope my risk assessment, you've already identified that these are relatively low risk harms,
because if you've got high risk harms, you don't want to be dealing with these after these happened,
because it means that someone must have suffered through them by that point.
So, when you look at features in a social media application, for example, to block somebody or to meet someone,
yes, you can use them, proactively.
But chances are most people do it after they've already suffered the conduct in question.
They're typically reactive features.
Obviously, things that come up.
Who does a user go and talk to if they have a problem with something?
Not all services have an easy, obvious report button.
If they do, great, as long as it's backed up by action.
But if that isn't there, and if you can't introduce it, because the service doesn't have their feature,
is it clear and prominent who they should go and talk to?
Who do they need to report something to?
Does the person whom they report stuff know what they need to do?
Who handles the reports? How do they handle it?
Are the sanctions the consequences documented somewhere, so that someone who's acting as that moderator,
someone who's acting in that role of investigating whatever, they know what they need to do,
and they can apply those standards consistently repeatedly and easily.
That's the one I see most organisations slip up on, is they've kind of thought about it.
They've got a code of conduct, but a report comes in, and then there's a panic.
And there's a panic, because they're not sure who's dealing with it, who's already dealt with it,
who's commented on the forum thread about it, that it doesn't need to be massively difficult.
You're not trying to write your own procedural rules akin to a court, just something less you,
just something clear and simple that you can apply equally.
But this is where something bad already happened, someone is reporting it,
you're going in to stop, to put out the fire that's already started.
What could you do to stop that in the first place?
Where you're really looking at these high risk cards, it's what can you do proactively,
trying to prevent the harm from happening?
So, again, it will depend on the service in question.
An awful lot of harm sometimes someone sees, comes from services where anyone can use them,
just simply sign up, off you go, you can start posting.
There are good reasons for making things easier to use, for reducing barriers to entry.
I'm not saying never do it, but when you've assessed the risk of context of your service,
maybe having some form of manual approval step before people can start using them,
could reduce the risk, but still make your service useful.
Could users have different functionality?
Does every user need the ability to send an encrypted direct message to every other user,
the moment that they sign up?
Do they need to be able to send an encrypted direct message containing an image to everyone?
Who's just when they just signed up?
The vector for abuse is very obvious.
There could be good reasons, but there are also very obvious abuse factors.
So, can you differentiate based on user time, duration of use of the service,
all number of different facets?
The third one, I've written it, I feel it's a little pointed,
but kind of with reason, I love GITC, I use GITC.
I do look at GITC instances.
GITC for those who don't know is a fast fantastic free software video conferencing service.
It runs in your browser, you don't need a client for it.
You join using a meeting name, somebody else joins using a meeting name,
you have a video chat.
A fantastic tool for all sorts of things, including CSUN content.
A fantastic tool for having a meeting to which someone else joins
and starts broadcasting pornography or CSUN content.
So, if you run a GITC or other video conference,
one of my first thoughts from a risk assessment point of view
is, do you really need anyone to be able to start that conference?
Could you look at looking it down a bit?
The last thing I'd touch on is community knowledge sharing.
Not everything I've done with the online safety act,
but an awful lot of it.
I've put online, online safety act.co.uk, risk assessments,
sample terms and additions, all sorts of things,
because these frameworks are onerous.
They are challenging, particularly if you're not used to dealing with them.
The more we can pull knowledge about how other services have done it,
the more we can build up that baseline and get to a good place.
Now, they may also be scope for knowledge sharing about bad servers, bad actors,
problems and things.
When you start sharing information about individuals,
you might also want to think from a data protection point of view.
But thank goodness, I'm not doing a data protection talk this afternoon.
Just a flag, there may be value in doing that.
It may be perfectly legitimate to do that.
You may find a perfectly good legal way of doing it.
There will be data protection considerations when you start sharing information about individuals.
Now, the other thing that I pondered talking about,
but decided in 30 minutes not going to age verification.
It's the topic that's coming up in all sorts of different countries.
Again, not all asking for the same thing.
Should it be device-based?
Should it be browser-based?
I think the one that worries me the most is the idea that before one visits a pornography site,
you should turn on your camera and prove that you are an adult.
This doesn't seem particularly well thought through,
but that's the level of the dialogue in some places at the moment.
So, I won't talk through that.
I think it's an issue that will come up and we will need to deal with them in the free software community.
But with three or four minutes remaining, what questions do you have?
Thank you.
So, since you've stepped upon this already,
so say one instead of launching a GTS instance,
so say one to launch on more than one single user server,
or a matrix server, or anything else that's a bookroom server, anything.
What would you recommend to do?
So, the question related to Fediverse server,
was it a single user server, did you say?
So, I have a single user mastered on service.
Some people will say that's still one user too many.
I come on with a risk.
I may have done a risk assessment or not.
I don't think many online safety rules are designed to deal with someone's own speech
in the same way of what they write on their own blog.
The way some Fediverse server's work means other users may be able to,
you'll post, maybe effectively relay through your server,
you may be able to search someone else's posts.
I've locked all that functionality down on my server.
People can only see what it is that I post for better or worse.
And at that point, I think I'm quite comfortable with the risk.
If I were to run, say, a matrix server or an XMP server,
in our family, as I do, I haven't bothered about risk assessment for that.
If I were to allow other people to sign up for it,
I would be thinking, far more carefully about it.
Okay.
Hi.
I know you're British, but sorry.
Do you happen to be able to shed any light on the upcoming,
any upcoming European laws?
I'm a complete lay, I have no idea,
which kinds of laws are coming up.
And the names of these laws were to find more information about them
in this notoriously opaque process.
I'm not, so are there any other European laws coming up to deal with this?
I don't know if there are specific legislative proposals.
Others might.
What I'm seeing is a general direction of travel along this kind of lines.
I don't have a specific citation for you, I'm afraid.
Okay.
Talk tomorrow about it at 12.
Okay.
Sorry, I wasn't saying you should talk tomorrow about it at 12,
but there is a talk tomorrow about it at 12.
Matthias.
Hi.
I'm setting up a hack space.
And instead of having it be that members can visit websites
over the internet, I was thinking about using tall hidden services.
And having DNS point to these six addresses and on unaddresses.
And this way, no one on the internet can visit my websites.
Unless they have, well, yeah, if I put in DNS, they would know.
But the idea is I would share the hints of service with people.
Physically, maybe on a piece of paper.
And now they can visit the website or the internet.
Do you think that that is a valid solution to some of these problems?
So, is running something as a tall hidden service,
a way of avoiding regulatory risk?
I run tall hidden services.
All of my websites and stuff behind tall hidden services.
No, not fundamentally.
If you've got users, you've got users.
You might be able to find basic regulatory investigations.
But there are a lot of people also using tall hidden services for user to use
stuff that regulators and law enforcement agencies know perfectly well about.
So, do it for, because it's good for privacy.
Do it because it's good for security.
Probably not a great regulatory risk mechanism.
Please all chime in with a big round of applause for Neil.