You're listening to a stage talk titled Building Tools for Research. This week, we were joined by my colleague, Galen Riesch. Galen is behind many of the Bellingcat built open source tools available today and came in to share his advice on how to get started in tool development, whether you're a coder or someone passionate about accessibility. You can find links to all of the resources mentioned
in the talk in the podcast description. This talk was hosted by me, Charlotte Mar, on Thursday the 28th of August 2025 in the Bell and Cat Discord server. So welcome back to our Stage Talk series. This week I'm joined by my brilliant colleague Galen Riesch. Galen's name pops up in many conversations here in the server and within Bellingcat. I was actually surprised to hear that this is his first
stage talk. Here's our tech community lead and one of the many amazing people we have behind the scenes creating useful tools and visualizations for our investigations. Here's the mind behind tools that you might be using today, including tools that help you find things like the Shadow Finder tool, a tool that assists with locating a place based on a shadow. and collaboration tools that make working together easier like the search grid generator and the color highlighter.
You also may have seen his face in our YouTube tech series, walking you through how to use the command line, or have come across his guidance in our tech community spaces within this very server. Regardless of where you might have encountered Galen, today he is here to discuss the basics of his role, highlighting why you might want to get involved in tool building and what goes
into a useful tool for research. We'll explore some of Bellingcat's tools and highlight others, explain what ethical and security considerations you need to make when building a resource, and give you direction on where and how you can get involved. As we talk, please make sure to add your questions in the chat box via the message bubble icon in the top right corner of your screen, and please note within your question if you do not want me to read your username out. Again,
this is being audio recorded. So it's really important that you do that if you're not comfortable with me reading your Discord username. All right, Galen, go ahead. Tell us a little bit about tool building. Yeah, thank you so much, Charlie. It's a very generous introduction for the stage talk on building tools for research. I'm going to take a moment just to introduce myself a little bit more and to give you a bit of a sense of
my background and where I'm coming. where I'm coming at all of this tool development from. I'm an investigative technologist at Bellingcat. I spent a lot of time working with you wonderful folks in the community. My background is in engineering and research. Before my time at Bellingcat, I was at the BBC where I worked in their research
and development department. And before that, I was at the University of Birmingham where I was completing a PhD in radar, so in electrical engineering, which is a far cry from most of the work that I do now. So I'm definitely not a developer by training, although I do now develop a lot of tools and work with folks to develop
new investigative approaches. But really, I think For me, the common thread is development of ideas and finding the ideas from the kind of rich pool of thoughts and things that people tell you that could bubble up into a really valuable tool. So that's a little bit about me. What I want to talk about today then is like, why build a research tool? What makes a tool accessible?
And finally, what makes a tool usable? We'll talk a little bit about the difference in how I'm using the words accessible and usable there a little bit later on. But yeah, why build a tool? What makes it accessible and what makes it usable? The absolutely most important thing that I cannot overstate, tools must be free in
the open source research space. We did some research at Bellingcat a few years ago, some of my colleagues did, and one of the huge takeaways was that any tool that requires some sort of paid access is just like a no -go. Don't even think about it because many people don't have the resources to be able to spend on getting access to a tool on the off chance that it solves their problem.
So tools must be free. And I think that this is kind of a philosophy that fits really nicely in with the open source research philosophy in that with a Bellingcat article, our researchers will try and take you through the investigation and show you how the investigation has been done so that you too can replicate it if you want. And that's a little bit more difficult if they've used the super expensive tool. It doesn't mean that we don't use paid tools from time to time.
But when thinking about developing a new tool, we have to think that they've got to be free. Now, I have these three key strands that I find useful when thinking about a tool. That's the concept, the utility, and the execution. Is there a good concept? Can it meaningfully advance an investigation? Because if it can't, then the concept isn't very good. If I came up with a tool that increases all the text in a PDF by 5 % and turns every copy of the word into Comic
Sans, that would be a terrible tool. The concept is just bad. It doesn't matter how well the zero utility, and it doesn't matter how well I execute that tool, the concept just isn't there. Moving on to utility, does the tool have utility for people who might actually use it? Will they actually try to use the tool? Does it seem appealing? Does it seem to solve a need? And then execution,
is the tool developed well? When people try to use it, like of those people who think it has the utility for them, will they actually be able to use it and actually get the results they need? So these are the three strands that I think I'll unpack those in a bit more detail. So firstly, like, the concept, why build a research tool? So in my experience, there's a couple of strands of like places that tool ideas originate. One
is investigative needs. So this is where somebody who is working on an investigation says, hey, there's a problem here. And I think there's a opportunity for solving it through code development or through some other source of tool. Generally speaking, not always, but generally, these are professionally motivated. It's professionals working in investigative environments where they're encountering similar problems day in, day out.
And an example of this is with a recent article that went out, not that recent now, but on the One X Bet betting website. Please take a look at that article. I think it's a fantastic investigation. But as part of that, we needed to build a web scraper to go in and pull out a load of videos that were being streamed on this website. And so there, there's a technical need, and we needed to build some sort of research tool that would
fill that, that would address that need. And so I went away, worked with a colleague, and we built a scraping pipeline that could run away and grab all of the videos this site streamed over the course of the day. So that's motivated by investigative need and those videos were then, you know, used in the article and used in the subsequent investigation. The other angle is interesting ideas. This is a much more accessible route into building a research tool because it's
like conceptually intriguing. I'm sure many, many folks listening will have ideas or will have encountered things and thought, huh, that's curious. I wonder if I could do something with that. The downside is like, will anyone care? An example of this that is very close to my heart is the shadow finder tool that Charlie mentioned
in the introduction. So this is a tool that lets you take a photograph of a scene and by measuring the height of an object in the scene and the length of its shadow, if you know things like the time of day and the date, it's able to give you a restricted set of locations where that photo could have been taken. And if you have multiple photos from the same location, you're able to really narrow down the location quite precisely of where that photo could have been
taken. And this was a tool that came out of the Discord community. And when I built it, I thought, this is a really cool idea. unites a bunch of really cool things that matter to me, like the kind of physics of the sun and all of the kind of geometry that I spent some time doing in my kind of educational training. It really appealed to me as an idea, but I definitely had that concern, like, will anyone care? And crucially, like, will that tool ever be useful for anything? It
turns out it was. After a couple of months after putting it together and making it available to folks came the one expect story. And we actually used it to geolocate a really difficult, difficult one of these live streams, we were able to narrow it down to a city so that folks in the discord could have a look and more have a much more focused search on that area. So these are really the two driving factors. And oftentimes, people will
approach with interesting ideas. I think you really have to develop an understanding over time about which ideas will actually be useful in some future investigation. So you've got to have a good concept if you're planning on building a research tool. Right, utility or what makes a tool accessible. So when I use accessibility here, I'm not referring to accessibility in the sense of a website being colorblind friendly
or available for use with a screen reader. But rather, I mean the how much prerequisite rather how much prerequisite knowledge is required to access the tool. So I think of this as a ladder of development. So at the bottom of this ladder, you have the kind of messy scripts that you might write as part of an investigation or to test an idea out. This is where tools really start life typically, and they are the least accessible
and the lowest effort end of the ladder. So to use a tool at this stage of development, a user has to have Python installed on their machine. If it's a Python script, which for me it often is, they have to have some technical expertise and the confidence to edit the code that you've written for your own specific example. It's a great way to prototype a tool, but it will only ever find a narrow technical audience if you
try and publish that as a tool. The next step up, so adding a little bit more effort and making the tool a little bit more accessible, is what's called a library API. This is where you take that script and you give it a small like incremental improvement. So it's still only going to really be useful for people who are technically adept and familiar with the language we tend to write in Python. So I'll refer to tool being written
in Python primarily. It will still only be useful for folks who are technically proficient and confident. However, what the library API kind of lets you do is hide away all of the logic of your messy script so that if someone wants to tweak what you've written to suit their investigative need, you've already done the hard work for them. They don't need to edit your code. They can just use your code. So this is a really nice kind of step up. The next step on the ladder is a
command line interface. So it's a significant step up in terms of accessibility, but Research from the study that my colleagues conducted a few years ago shows that over 50 % of journalists and open source researchers are not comfortable with the command line. So even building a tool out to a level where it's usable on the command line, and for a bit of context, the command line is the part of the computer that you might see in movies where you see a hacker pulling up a
terminal and typing in code. That's the command line. It looks really scary. In reality, it's just a text -based interface to the computer. So a command line interface gives your tool the ability to be used by anyone who has a little bit of confidence on the command line. They don't have to go through the rigmarole of figuring out your API, figuring out your code. They can just use the tool that you've provided. But like I say, many folks are still not comfortable with
that. Coming towards the top of the ladder now, we have these kind of couple of user interfaces. So the first that we like to use are Jupyter Notebooks and Colab Notebooks. This is a really nice way to wrap up Python code in a user interface that is maybe slightly more accessible for folks
with no programming experience. It still takes a little bit of understanding, but in my experience working with people, if you send them a link to a notebook or either a Jupyter notebook or a Colab notebook, after a little bit of explanation, they're very comfortable using that tool there
on out. And there's a bunch of techniques for simplifying the interfaces on a Colab notebook that I recommend kind of investigating if you're interested in developing tools, because for me, This is really the level at which a tool becomes practically useful for people outside of a kind of technical bubble. So I really highly rate Jupyter Notebooks and I really highly rate Google
CoLab Notebooks as well. And finally, the kind of the last rung on the ladder, but in reality, it's quite a significant step up in terms of effort. is a full user interface, a full graphical user interface. This is one of the best ways to make a tool accessible to a large number of people, but it can really be a lot of extra development work. And if you're thinking about building a tool with a full interface, ask yourself, is it worth the effort? Is the target audience for
my tool? going to need the added convenience of a user interface, or would they be happy with a notebook? If you answer that they would be happy with a notebook, that's what you should do. Don't go the extra mile. Just deliver that tool that meets the needs of your users. And this is something that we try to think about. So, Bellingcat, we publish several command line interface tools. We also... publish a bunch of
research notebooks. So we have a repository on our GitHub which contains a bunch of research notebooks that let you perform a variety of tasks that we don't think merit full development of standalone tools, standalone user interfaces. So that's the ladder from a messy editable script at the bottom through a library API through a command line interface, through Jupyter or Colab Notebooks, and finally, a full user interface.
The further you go up, the more effort it is, but the far more accessible for the end user. At Bellingcat, we don't particularly advocate a front -end framework if you're thinking about building a user interface. We think that Streamlip seems like a pretty good option. And personally, I have done quite a lot of development in Vue, which is a JavaScript -based front -end framework that can be really good for building user interfaces.
Another important thing to consider when you're producing an interface is how are you going to make it secure and how are you going to host it, the whole tool? Because... If you've produced a tool, and I've told you earlier on it's important for it to be free, are you going to have to spend a load of money to host that tool so that other people can use it for free? And the answer really should be no. Building a user interface and hosting a user interface can be expensive, but it doesn't
have to be. Streamlit gives you access to a certain amount of compute per month, which means your users don't have to pay to use your tool. It's really powerful. Same with Google Colab notebooks. They don't have any cost to hosting. And if you build a website, I would encourage you to investigate what it means to build a website that is static. So it's one where you just put the files on the internet and all of the complicated stuff happens
in the user's browser. It's a really powerful technique for letting users do really complicated things. And it builds security into the process because you're not asking people to upload sensitive files to your server. You just ask people to load it into their own browser. And that's where all of the magic happens. So it's far more secure.
And ultimately, it's generally free to host the open source projects using tools like GitHub, which if you're developing open source research tools, and you're not familiar with already, I suggest you investigate GitHub and get more familiar with it. So the final section is execution.
So this doesn't refer to how accessible a tool is going to be and how attractive a tool is going to be to a potential user, but rather this is once somebody's opened your tool up, once they want to they've been convinced that this tool could be useful for them, what makes it actually usable? And really, with the exception of it being free, and by free I really do mean free, I can't hammer this home. Freemium isn't sufficient, not a free trial, it really has to be free to
get people's buy -in. But the three core principles are it should be simple, so the tool should do one thing really well. Of course, there are many amazing tools out in the world that are very complicated and do lots of complicated things. But my experience in the open source research space is that if you're developing a tool, make it simple. Do that one thing really, really well. Users really relate to tools that meet their need. And you're not trying to sell anything
to people. You're not trying to get an annual subscription. You don't have to promise the world. You can say, if you want a tool that puts a grid on a map, I've got a tool for you. If you want a tool that lets you search local council meetings, I've got a tool for you. If that's not what you need, these aren't the tools for you. And a shout out, I think, is appropriate at this point for the Bellingcat Toolkit. a fantastic resource for finding new tools that might meet your investigative
needs. So simple, does one thing well. The interface should be clear. You've got to put the user at the heart of the interface. And imagine that when you open up the tool, you have no idea what it's meant to do. And all of the information should be contained within the user interface and within the design of the tool. Coming from an engineering background, This isn't the most natural space for me. But I know that I previously had lots of fantastic colleagues at the BBC who
worked on user experience and design. And I feel I learned a lot from them and now I'm a strong advocate for really considering the user's experience and designing accordingly. And finally, if possible, the tool should be quick. This might mean you have to spend a little bit more time optimizing your code or designing your processing pipeline differently. But ideally, a user should be able to press the button and get results nearly instantly.
Because otherwise, if you press a button and see a loading bar or a spinning wheel of doom, it really erodes trust. folks will start to think, oh, have I done this right? Have I made a mistake? And in the world of these open source research tools, if a user makes a mistake that causes your tool to fail, you don't want that pathway to be very similar to using your tool normally.
You want them to get a really clear error message and a nice instruction to please contact you as the developer and let you know what they were trying to do when it went wrong. really inviting feedback and inviting development is such an important part of making an open source research tool usable. So yeah, to recap, I think you need that great concept. You need the idea to be a
really solid one. Put yourself in the shoes of an investigator if you don't work in that space and think, is what I'm offering valuable to them? Does it solve a problem that they either have or could conceivably have in the course of an investigation? Then think of how much effort is reasonable to put in to make this tool have utility because you don't want to be spending months and months and months developing a tool that nobody uses. Build something, put it into
the world and see what people think. And finally, when you're building it, when you're executing that tool, that tool development, make sure that you put the user at the heart and really design the experience so that the entire tool comes together for your user. And with all of those things, you'll build a fantastic research tool and people will love using it. Charlie, I think that leaves me to hand back to you. Yes, thank you so much, Galen, for that really clear and
knowledgeable. presentation. It's really amazing to see how you break down the parts of tool development. It's been really helpful actually for a number of people in the chat. There are some common themes emerging in the chat though, so I wanted to ask you first about those. Do you have to have coding know -how to get involved with tool building? And if so, in terms of maybe leading
tool development? What other ways can you get involved with tool development that might not be so focused on the coding section of development? Absolutely. So the short answer is no, you definitely don't have to be a coder to get involved. I think it definitely helps to have the more familiarity with coding you have. after the easier time you'll have when you're exposed to these quite technical spaces, but it's definitely not a barrier. There are a huge number of ways that folk can get involved.
One thing that we always find helpful is when folk who don't have a technical background or technical experience try to use our tools. If you're wanting to get involved with tool development, the easiest way, I would say, is to try out a bunch of tools and see if they work. And if you encounter a problem, reach out to the developer. So we have spaces in Discord here where if you encounter a problem, you can shout about it.
And really, like... feel free to test the tools to like their breaking point, because as a developer that works on some of these tools and supports other developers in building these tools, you know, you do your best to think about what people are going to do with the tool. But ultimately, it's not about us developing it. It's about you using it. So you don't have to have any coding knowledge to use many of the tools we produce.
But if you try and use it and we failed in the execution step, then we failed and we need to know about that. So a lot of the, for me, the joy, so we just published a tool today, more or less, and I've had some feedback from folks on Blue Sky about tweaks that could make the tool more usable. And what I've done is I've taken those and I've noted those down in the
tools repository on GitHub. So if you're comfortable enough to create an account on GitHub, there are ways to get involved with the conversation around tools, even without having to be a developer. And if you head to Bellingcat's GitHub, which is github .com forward slash Bellingcat, there's a big section on the landing page there that explains how you can get involved with Bellingcat's tools specifically. So I hope that answers the question. Within the chat, we've got people saying,
for example, Sarah, our moderator. She says, you can be a technical writer as a contributor. People love us. And that is really true. That is being able to really describe how to use a tool is, is part of the reason why our Bellingcat toolkit exists. Because not enough people do this when they build tools is make, you know, really good documentation. So people understand how to one use it and. the benefits and the disadvantages of each tool as well. So that's in the chat as
well that I linked the toolkit. I've also just put in the chat some links to spaces within the server. Gelin mentioned the GitHub, but we also have within the server tech contributors, which is a place to find ongoing tool ideas and to pitch those tool ideas and to find people who want to build together. And tools and sites is a place where people share often useful tools
that they've come across. And tool support is that place within the server where you can ask for help with a particular tool or flag something that's not quite working, particularly with a Bellingcat one if you're not comfortable or aren't familiar with GitHub and the way that that works. Just building on this slightly. Somebody said that they'd be comfortable picking up an idea from a list of ideas people had, but didn't try. Is there anywhere like that? So we've just mentioned
the tech contributors within the server. Is there anywhere online where people do say, oh, we have this idea for a tool, but don't necessarily have the resources to build it? Is there somewhere like that where you can get involved in those kinds of communities? You mentioned already the tech contributors space. There's a channel in there for working on working on new ideas. I think it's called welcome and info, which is perhaps not the best name, but it can be used
for developing ideas. And within tech contributors, it's a forum channel. So there are a bunch of different ideas that are in there. Oh, no, there is a I misspeak there is a a section of tech contributors called tool idea workshop. So that's where people might be discussing new ideas. I'll be honest, it's a little bit of a stagnant channel
right now. So if you're if you're interested, if you're excited by this, please go dive into tool ideas, workshop, share your ideas and really like use that as a space to collaborate with others. We do have a We do have a space with some long -standing challenges on the Bellingcat GitHub. That too is a little bit stale now. I mean, it's something that I've been working on
a little bit in the background. And I hope that at some point soon, I'll be able to release a kind of list of like a shopping list of ideas that we at Bellingcat think are really valuable and would be really cool enhancements to the open source research world, but they just don't exist yet. That's something that I'm working on in the background and hopefully I'll have something to share publicly on that in the not too distant future, but we'll have to wait and
see. Yeah, I just also want to thank John in the chat, who's been also putting in a bunch of useful links, which I'll put in the description of the podcast as well for those who do want to learn the command line and coding as well. So thank you so much for sharing those. And it's really valuable, as Galen said, to know coding for these kinds of tasks, but it's not exclusive.
Joanna in the chat, a good colleague and the person, the brain behind the toolkit has asked Galen, what has been your favorite tool building experience so far? Why was it so fun? So it's a great question, Hannah. I think there are, I've enjoyed building lots of different tools. Um, for different reasons, I think, um, and I need to not let recency have an impact. I recently launched the council search tool, which is a UK and Ireland focus tool for finding verbatim,
um, verbatim quotes from council meetings. Um, I'm very proud of that and it's very, um, it's very recent, but I think my, my favorite tool development experience has been the shadow finder tool. Because it came out of an idea in the community that I hadn't thought of before, I was aware of some of the methods that you can use for geolocation and chronolocation with the sun. And I was aware of websites like Suncalc. But the idea of running Suncalc backwards hadn't ever occurred to me.
And so when Gabor Friesen came into the Discord and shared the idea, I thought, oh, that's really smart. That's really smart. It's probably not going to be useful all the time for every project, but maybe one in a thousand projects is going to hit against a brick wall where the geolocation is just super difficult. But you have this other kind of information. And I think that was the most rewarding for me, both because it kind of
scratched that kind of intellectual itch. but also because it seemed to be a really valuable idea that came out of the community. So Gabor and I collaborated on building the tool, me doing the coding primarily, but then we would kind of iterate. I would share a version with him and we'd talk about what works and what didn't work. So I think having a partner in development really made that experience stand out for me. I'm just going to take the opportunity as well
to shout out about the grid search tool. This is at grid .bellingcat .com. It's such a simple tool. It also came out of conversations with the community, but there was less iteration because it was such a simple need. Plainly, the idea is if you're doing a geolocation with five people trying to work systematically in an area, how are you going to coordinate the workload? What the grid tool lets you do is it lets you download a grid that goes over a map in Google Earth.
And so you can say, right, I'm taking this section of grid cells. I'm taking this section of grid cells. And you can divide work and mean that people aren't double checking the same area. And yeah, it can help you keep track of areas you've already checked. So it is useful in like a few fronts. But it's such a simple tool. It just creates a KML file that you can download and open in Google Earth. It's really like the tech equivalent of getting a pencil and a ruler
and drawing a grid on your map. Well, we're shouting out tools. You mentioned earlier that a new tool came out today. Do you want to share a little bit about what that tool is before we delve into other audience questions? Yeah, absolutely. You must cut me off if I rabbit on about it. Yeah, this is a tool that I've been working on lately and it's just reached the state where it's ready.
It's a council search tool. This was born out of conversations with local journalists in the UK who one of the kind of classic local journalism tasks is attending council meetings or watching in the modern day, watching live streams of council meetings to see if anything scandalous happens or if there are any discussions about new developments or interesting things for a local journalist to cover. And one local journalist I was talking to said, yeah, I spent I spent every evening
of my life doing this. And one day I got a real big scoop because they forgot to turn the recording off at the end. And I thought, oh, that's really interesting. And that's great if you've got the resources to do that. But I know that in the UK, at least, local journalism is one of those areas that's been consistently underfunded and undersupported over recent years. So anything for local journalists and local democracy researchers. to help them cover local council meetings seemed
like a valuable addition. And what this tool does is it goes away and in the background, it grabs the transcripts associated with those live streams that councils put out there into the world, and it makes those transcripts searchable. So if you go to the search tool now, you would see a big search bar and you can type in things like off the record or That's outrageous. Or you could type in specific company names that
you're interested in. And you can then start to see all of the meetings in which those terms have been mentioned. And the search tool gives you a little preview of the section of text. And crucially, there's a button that takes you to the source video. And if you click that button, it's going to take you not just to the page where the video is, but it's going to take you to exactly correct timestamp for the part that you searched.
I'm really hopeful that this will become a powerful tool for local democracy researchers and local
journalists. It's all open source and at the moment I just have written code to support one council multimedia provider and I have an aspiration that other folks who are interested and want to get involved will go out there and look at their local council or if you're not in the UK or Ireland, you'll look at a council that you've come across as part of an investigation or just the first one that came up on your Google search and you'll see what format they've used for their
meeting streams and you'll see if you can reverse engineer that in a way that can add support for that council and to other councils that use the same provider into this tool. A current outstanding task is to support YouTube, which many councils use. I've not done that yet. And I think it would be really exciting to be able to support those many, many councils that use YouTube to archive their council meetings. One of the audience members has just put, reminds me of Filmot, a transcript
search for YouTube. So maybe that's something to check out. Sarah says, that's sick. What a time saver. As someone who used to sit in council meetings as part of her job, I 100 % agree. They were hell. John asks, is this on GitHub as well? Because I know that most councils in the Netherlands publish this as well. Yes, it is on GitHub. So it's open sourced. So it, we have a hosted backend service for it. So we host the database for this tool. And that does all of the kind of scraping
on the backend. But the front end is open source. The backend is open source. And if you, did you say it was the Netherlands? In the Netherlands, many councils publish. Yeah. I think adding different country support would be something that I would be excited to do. It's just not been something that's been in the initial scope of the project, but there's absolutely no reason from a technical perspective why that wouldn't work. Or indeed, if you wanted to host your own country -specific
version of this, that would be amazing too. Please have a little play with that. Let us know if you come across any issues. You know the spaces in GitHub and the spaces are then here to flag that now. It's really, really important. And yeah, we wanted to really announce that today just so that you had a little tool, a new tool to play with after this talk. I'm just taking it back to building your own tools though, away
from the current available tools. We had a question earlier about how EU nations are currently moving to free open source software away from Microsoft Office, for example. And they asked about what it meant for cyber security. But I had a wider question on that in terms of actually building open source tools. Are there any security issues that you need to consider when building and opening
up your code to the world. This is one of the reasons why I'm quite a strong advocate for using those kind of Colab notebooks or producing a website that is static and runs entirely in a user's browser. Because in doing that, you kind of circumvent many of the security challenges of deploying a service like we've done with the council search tool. because then you have to make sure it's secured and you have to have some understanding of how to do that effectively.
So yeah, there are definitely security concerns in publishing a tool, but if you make it so that it only runs on a used device and you're not loading malicious code onto people's computers, that's a really good thing. As long as you're not the security problem is I think what I'm saying. Following those tips circumvent a huge number of those issues. And then on the idea of open source tools were generally so there's
a subtle distinction. that we encounter really frequently in the Bellingcat tool space is the difference between open source research and open source technology, open source code. So they're very similar, but slightly different. So with open source research, that means we're using open sources of information to conduct our investigations. And there an open source could require payment. So in Bellingcat investigations, we will sometimes use imagery from the satellite company Planet
as part of our investigation. Now, that's open source in the sense that anyone could pay Planet for that imagery. And we also then publish the imagery server, kind of check our work. But it's not open source in the free and open source software sense, where all of the code is public and available for people to iterate on and improve. Now, incidentally, I think both sets of ideas are really compatible.
It's why we publish so many of our tools in an open way, because it just fits the, it's a really good intersection between technical folks and research folks that I think can lead to really kind of fruitful relationships. And I think more and more as institutions move towards kind of open source tools, I think or I hope that the community around open source continues to grow and it helps just everyone build better tools
in the long run. This is a question that comes up quite a lot when we're talking about tool building. Obviously people tend to think a lot at the minute about AI, one of the most common AI tools. that are kind of emerging at the minute is kind of these verification checkers. I had a conversation with someone very recently who is keen to build a similar one, and they're asking us about the types of disinformation and misinformation that we encounter, because that's something they're
looking into. But Aries in the chat has asked an interesting question about how tools specifically are preparing, particularly when it comes to detection or counter misinformation tools, how they're preparing to cope with new AI misinformation and disinformation. What kind of architectural feature level innovations are on your mind to help investigators detect and counter misinformation while still leveraging AI effectively is the
question. But I don't know if you've ever come across a tool that is 100 % reliable when it comes to identifying AI, I haven't. I know we've recommended some in the past with additional verification techniques, of course. But yeah, I don't know. Do you want to speak a little bit to that space that currently there's a lot of tool builders, developers kind of looking at and what that particular space looks like? Definitely. And I think there's a few strands to it as well.
So I'll try and... speak to each of them as I see them, and hopefully that's useful. So I think, firstly, there's the whole space about like AI detection tool. AI detection tools are going, it's going to be a constant battle between AI detection tools and nefarious AI trainers. Of course, there may be cooperative solutions between like larger platform, but AI detection is like an adversarial exercise, will always be a kind
of shifting ground. And I don't think, I don't think there will ever be a tool that delivers good results always and is consistent, like is ahead of the curve for a long period of time. It might be that a tool that is very effective one month. is going to be obsoleted with the next model release and its developers will have to go back to the drawing board to improve their
detection model. But I think sometimes I think we risk focusing on detection tools when actually the kind of ecosystem of misinformation is perhaps a much more fruitful place to investigate. So I think to stay ahead of synthetic media and those advanced obfuscation approaches is almost
to forget about the technical element. If you see an image online that is surprising or shocking, follow your nose and follow your investigative instincts and see, well, if there is a huge fire in this location, Why are all of the images this exact one angle? Can I find multiple images on social media posted by different sources, like beginning to build up a picture of the misinformation landscape around a particular event, I think is perhaps a more useful approach than putting
an image into an AI image detector. Of course, there's a place for those detectors, but I think as the technology moves on and as things become more and more convincing and it becomes increasingly difficult to separate reality from a generation, I think it will become those contextual clues that provide the really kind of richest information. So I apologize, it's kind of a non -technical answer to the question and it's not a space that
I'm a particular expert in. I know my colleague Kalina would probably have a much more intelligent answer to how to spot misinformation, particularly AI -generated misinformation. But I think it's an honest one. I don't think all problems have a tech solution. And that's probably quite an important lesson for those of you thinking of going into kind of or being involved with like tech development in this space is sometimes there are very human solutions to these problems as
opposed to technical ones. Yeah, I can count. I can't even count on my hand the amount of times I've been asked by a journalist when I've been doing talks on disinformation. Is there like a tool that fixes this? It's like the answer is no. That's not the answer. The tool isn't the answer, as far as I'm aware. So I agree with you there. I wanted to ask though, in terms of when we're talking about updating tools and making sure that they're advancing enough with the tech.
We've had some tools in the past, spelling out tools break when social platform policies have changed, right? How do you keep on top of that, particularly when you're building search tools, search across specific platforms? a tremendous amount of effort, frankly. I think there's not
really a good way around it. If a tool that you're building relies on somebody else's service, then that is, as part of developing that tool, you have to understand that if you want to keep that tool working in the long run, you have to... you have to accept the possibility that that person could change how they're operating. This is particularly true in the world of scraping.
So if anyone has tried to do any social media scraping in the last five years, frankly, you'll have found a plethora of tools, some of which are very good one week and terrible the next. some of which are kind of mediocre all the time, and some of which are just kind of terrible. But as far as I'm aware, there's no like consistently fantastic social media scrapers, because those social media platforms are constantly shifting. And so the amount of work required to keep up
with them is significant. It doesn't mean it's not worth doing, but it's definitely a consideration when building a tool is thinking like, how, how do I keep this supported in the long run? It's why with a tool like the grid search tool, I'm super happy because that will, I hope, fingers crossed, require zero maintenance along because it does what it says. It does that one thing really well. And it lets you download a file format that's barely industry standard, which
is a KML file format. So there's no shifting ground there. When it comes to tools that rely on third party services. That's a feature of the landscape. And I think you either accept that your tool is going to take a lot more of your time or you accept that at some point it's going to break. And that's just how it is. Yeah. And as you said at the beginning, I think simplicity is often key when you're thinking about applications, particularly. Do you often, within tool documentation,
do you often have to assess? What devices can use your tools and in what regions tools are applicable as well? Is that something that's really useful to add into documentation, for example? If you have any, the general rule with tool documentation is if you have some insight that you think is useful to someone else, put it in the documentation. On a personal level, I don't think I have a tremendous amount of insight into what is... what are useful to folks in different
regions. It's something that I have in mind and would like to better my understanding of so that we can build better tools that are more portable and more useful to a larger number of researchers. In terms of devices, it's a really good question because I think more and more journalists are doing things on their phone. more and more researchers will be doing things on the go. You might be on the train doing a little bit of research.
So finding ways to make your tool suitable for mobile is like a really essential thing in modern landscape. And that is a downside of the Colab Notebooks, Jupyter Notebooks that I talked about earlier is that they are not very accessible for mobile device. You immediately cut out a significant fraction of your users or at least your users a significant fraction of the time
when they're on the go. It's one of the things that I really like about using Vue, that's V -U -E, the JavaScript framework for front -end development, is kind of implicit in the design is a mobile -first approach, which means that your site will be good on mobile. So the council search tool should work on mobile. And you should have a perfectly good experience there. So thinking of that and testing for if your tool works on mobile is a really good thing to do. And I know
it's something that we do. This is maybe a slight aside from tools, but it's something that we do when thinking about article content for Bellingcat stories is does the article look good on a tiny mobile phone? I'm just going to pull up my responsive design mode in my browser to give you a sense. So the size of phone screen that we test for if we're doing some interesting kind of novel experience in an article is 320 by 547 pixels. That's the screen size or the functional screen
size of an iPhone 5. which is tiny. I can't overstate how small that is. So when you're building a tool, think about what's it going to look like on a tiny, tiny screen? What's it going to look like if that person on a tiny, tiny screen turns their phone into landscape mode? How is this tool going to look? Is it even going to be usable? Do we just have to tell them to turn their phone around? But if you can do that, that's such a
valuable addition to a tool. If you can add those graceful degradations as people's screen sizes get smaller, as it becomes more and more difficult for them to access the functionality of the tool, let it lose its functionality in a graceful way. Tell the user that it would be better if they found a larger screen or turn their phone around. And make sure you do that. early on in the tool
interface planning process. Because there's nothing more frustrating than if you've built this beautiful tool interface and then you test it on mobile last minute and it doesn't fit. That is gutting. So that would be my advice is to test it early. I'll let you know what I've cracked that one. Yeah, as you can with the council search tool, please do test that out for Galen on mobile as well. We are coming up to the end of the hour,
so I wanted to ask you one last question. You mentioned at the beginning that most of the open source tools are free. If somebody does want to make a business out of this, make money, is that even possible within the open source formats or is that something that is just so anti the ethos that you don't recommend it? I don't recommend it, not because it's anti -the -ethos. So for instance, the Mozilla Foundation, they release the Firefox browser, which is an open source
web browser. But they are also a commercial entity. And as I understand, part of their business model is providing support to organizations that want to use the open source tool at scale. And that's quite a common model. see in the open source software space is an organization publishing something for free and then selling services to help businesses use it at scale. So that kind of infrastructure support for larger, more complicated tools is an avenue where you can make a business
out of it. I'm the wrong person to ask about developing proprietary tools because it's a different trust architecture to the one that we like using at Bellingcat, which is one where the method is very clear, the tools are very clear, and open source tools make their method implicitly transparent. If somebody wants to sell a tool that does a thing and you're not going to tell me how I do it, it makes it much harder for me to justify using it in an investigation. It's
not impossible. Sometimes tools will unlock a level of analysis that is tremendously helpful and unsticks an investigation, but it then becomes a conversation about whether that tool should be used or not. And so I'm the wrong person to advocate for a paid tool ecosystem. Keep it open, keep it free is the message there. Thank you so much, Galen, for your time today. And thank you to everybody who's joined the audience. Please do check out the tech contributor space within
the Discord. I'll pop it again in the chat now. It is a space for you to chat with Galen and others from our team and each other about possible tools. And you can see some of the ones in there that Galen is already talking to people about. And do check out our Bellingcat GitHub as well that has tons and tons and tons of useful tools on day. Experiment with them. And if you find an issue, please flag it to us so we can fix
it quickly. Thank you again, Galen. This recording will hopefully be up on podcast platforms, which will be posted in here by this weekend. And we'll be back in two weeks time with another stage talk. But for now, thank you and goodbye. Thank you, Charlie, so much for hosting and moderating and keeping track of all questions. As always, you do a fantastic job. Oh, the flattery. The conversation's blowing. Thank you very much.
Thank you for listening to the Stage Talk. If you'd like to catch a Stage Talk live where you can ask the guest questions, join the Bellingcat Discord server by visiting www .discord .gg The music you've heard is titled Dawn by Newer Self and is courtesy of Artlist.