AIエージェント時代の不正対策：Fingerprintのデバイス識別とボット判別

A major challenge for almost every online service is reliably identifying users and knowing whether a given user or agent can be trusted. Historically, web services leaned on cookies stored in the browser to remember a visitor and recognize them when they return. The problem is that cookies live in the user's own browser and are easy to remove, block, or avoid entirely, so a bad actor can simply clear them to escape recognition. IP blocking and capture puzzles are firmer approaches, but they can frustrate legitimate users while doing little to stop a determined attacker. That leaves developers stuck between being too lax in losing control or too strict in driving real users away. Fingerprint.js was started in 2012 as an open source project. In 2019, Fingerprint was launched as a separate, full commercial platform built on the original Fingerprint.js GitHub library to recognize devices and browsers without relying on cookies.

It handles identification by reading over 100 signals, from fonts and screen resolution to how a device renders audio and graphics. Keisha Rose works in developer relations at Fingerprint. In this episode, she joins Gregor Vand to talk about fingerprinting, how fingerprint combines multiple signals to identify fraudulent actors, how to distinguish legitimate AI agent use from anonymous or malicious bots, and how fingerprint's research team uncovered and disclosed a privacy vulnerability in Firefox and Tor that could have been used to track people across the web. Gregor Vand is a security-focused technologist, having previously been a CTO across cybersecurity, cyber insurance, and general software engineering companies. He is based in Singapore and can be found via his profile at van.hk or on LinkedIn. Hello and welcome to Software Engineering Daily.

My guest today is Keisha Rose from Fingerprint. Welcome, Keisha. Hey, thanks for having me. Yeah, very excited to have you on today. We're going to be hearing about a product and a technology, I guess, that runs on a lot of people's browsers and they're kind of using it without them even realizing in a positive way. But we're going to get into all that in just a second. I'd love to just hear what was your road into technology in general and then what was your path to fingerprint? Yeah, so I actually started out as an analyst in behavioral health in a nonprofit and I ended up making my way into tech because I fell in love with one of the companies I ended up working for, which is Tableau Software. Shout out to Tableau. But that's what kind of got me into it. I started there as a sales engineer. I then moved over to the product side as the PM. I was doing a little bit of DevRel at the same time, and I left Tableau to go to Algolia as a PM. And I was like, you know, I kind of miss that DevRel side. So in my next role, I was like, let me look for something a little bit more in the developer evangelism, developer relations space.

And that's how I ended up at Fingerprint. Nice. And actually, just like I think where I work, people ask our team, what is DevRel? Like, how would you describe DevRel? Yeah, I think it encompasses a bunch of things. I think it's getting involved in the community, but also being able to enable people to use whatever product it is you're evangelizing or trying to promote. It's like, can you actually help people use your product? At least that's how I approach it. So I'm creating content. I'm going to events. I'm giving webinars, sample code, applications, those types of things, tutorials, whatever it is I can make that can help people say, oh, that's how that works. okay, now I understand how I'm supposed to integrate this product or use this tool or whatever it is. Yeah, it's kind of like this, I think, for the deep in the weeds engineers, it's kind of a magical role to have on their team because they often don't want to have to, they build this thing and they're like, well, I don't have to explain how to use it, which is not really how products get to market. So yeah, it's amazing when you have someone who understands the technicals and is good clearly at explaining the hows and the whys and all that stuff.

Exactly. There's a lot of content that our engineers will say, oh, we want to share this thing, and I'll work with them to polish it, or they'll just set the base code. So I'm like, okay, I got it from here. I'll take it to market from here. So we definitely collaborate a lot. Amazing. So, yeah, let's talk about Fingerprint. So I think first up, Fingerprint is both an open source repository of technology and a company, I believe, just by the same name. Could you maybe just speak a little bit about what is the technology at a very high level, And then what is the rough split then between how the open source works? And then what does the company and the product within that company then give on top? Yeah, for sure. So Fingerprint started out as Fingerprint.js way back in 2012 when our CTO and co-founder Valentin created the open source project Fingerprint.js. And he worked on that a while. And then I think it was like 2019 or maybe 2020, he actually made it into a product and like a full-on SaaS company.

So that became fingerprint without the JS. I think we got that a couple years ago because we do more than just websites and browsers. But the open source version basically gives you the main core pieces of what we do in the main commercial product as well. It really started from the open source version. The commercial product just kind of expands on it. So what exactly does this library do? It basically looks at the different characteristics of your browser, and it can say, okay, based on the way you draw certain images, the types of fonts or plugins you've got installed, what's your screen resolution? What kind of operating system do you have? It looks at all these different characteristics and is able to put them together into a hash that can then be used to identify you later on. So you can say, oh, okay, this person logged in to your bank, for example, and I don't have to keep putting my password in every single time I log in. Oh, great. Remember my device? Cool. Next time they come back, it's like, oh, yeah, there it is. We recognize you. But it also can work to prevent fraud as well. The opposite, right? Last time this device was used or this browser was used,

they used the stolen credit card or they did some kind of abuse. Well, we didn't want to allow that to come back again, so now you can do that recognition again. So the open source version is all client-side. And, of course, the commercial version is a bit more robust, obviously, paying for it. So let's put some more additional features on top of it. It also includes a server-side component and a whole bunch of smart signals that we can get into later. But that's the main difference between the open source library and the company itself. Yeah, nice. And you kind of touched on it there, but I think it's helpful to set the scene, which some people might have heard all that and then thought, well, isn't that what's called a cookie? And how would you sort of delineate between a fingerprint and a cookie? Great question. So fingerprinting, when it's done right at least, doesn't require a cookie. and the thing about fingerprinting versus the cookie is the cookie can get lost at any time, right? The cookie can get cleared, it can get deleted or can be blocked from being set to begin with. And so for use cases where you're thinking about maybe personalization, that kind of thing, it's not necessarily as big of a deal depending on how you're using it, obviously. But for things

like fraud prevention or abuse prevention, where someone is probably going to purposely get rid of that cookie, they see the cookie and say, oh, just delete this. Now you've completely lost track of this person. You've got nothing else that you can use to even get any kind of signal about what they might be doing or if they're suspicious. So fingerprinting in general, not just our product, but in general doesn't require or rely on like storing data that anyone can just manipulate or change anytime. Yeah. And I think another thing that we'll go through a couple of examples later on, but very clear to make that this is a very useful technology because again, I think people can hear cookie and they can hear tracking of some description and see it as an only negative thing. And as we'll hear, I think throughout this episode, there are so many reasons that actually by having, let's just keep calling it a fingerprint because that's what it is. Having a fingerprint can be extremely useful for not only you as a user, keeping you safe, useful for companies in a positive way, knowing like when to serve a real person versus not a real person or a real agent.

And we'll get onto that because that's kind of an interesting topic as well. But yeah, I think that's just something to call out right at the beginning where people again may be listening and there was even something on hacker news maybe a couple weeks ago where someone had a slightly negative take on just the idea of fingerprinting not the company itself but fingerprinting in general so i think it's good to call out there are many many positive use cases for this which is what we're going to talk about today so i'd love to hear if i'm a developer like how am i actually going to implement this and so we're going to hear from the developer side and then maybe hear a bit more from the user side. So if I'm a developer, how am I implementing fingerprint effectively? Yeah. So we work with both websites and mobile applications. So the visitor, what we call our visitor ID is the term we use for our fingerprint, can either represent a browser like on your computer or your phone, or it can represent an actual mobile device. So if you're working with a website, all you really would need to do is add our JavaScript client agent, just a few lines of code and say, whenever you want us to

Identify your visitor, like, cool, fingerprint, like, let me know, what's this device, what's going on with it? You call a simple get function, and we return back to you an event ID. We also give you the visitor ID, but best practice is you just send it to your back end, so you can actually make sure you're getting trusted data. And then on the back end, we've got a ton of different SDKs for all kinds of frameworks and languages. But really, at the end of the day, it's just a JSON API. You can just fetch our server API. We send you back a ton of different properties. and we'll get into the smart signals, but things like, is this person tampering with their browser? Are they using a proxy? Have we seen them on a block list somewhere before? Are they cloning your app? Are they trying to pretend to be multiple people? All this just comes back to you with a bunch of different Booleans and objects, really simple, straightforward data. So you can really integrate it into anything you want. There's no proprietary tooling you have to finagle with. It's just, can you call it API? Cool, you can put us there. So yeah I love to hear about the smart signals I believe there a lot of them so maybe you can walk us through the different types that we have Absolutely So in that JSON response that we give you and actually if you take a look at our website we got a demo You can see the whole thing for your own browser

But in there, there's over 100 different data points. And now our customers tend to have a few different ways that they use the data. Some customers will just dump everything into their own machine learning models. Whatever they've got for their fraud, give us more data, as much data as possible. So they'll just dump everything in there. some folks will look at what we call our smart signals. There's more of like a derived signal. So, for example, one of the raw attributes might be like your browser, your browser type, for example. The smart signal would be more like, oh, are they using a VPN? And we'll break it down by why we think they're using a VPN. Is it like a time zone mismatch? Is it a certain exit node, for example? But the smart signals do a bit more on the back end to give you some of those higher details to make decisions on. And then we have some folks who are like, you know what? I don't really want to look into the smart signals. I don't have time to try and figure out which ones to care about. And so for that, we have our suspect score that kind of like bundles all of them up together into just one number. And the higher the number, the more signals that you've triggered and the more suspicious that you are.

So it kind of depends on how you want to go about it. I always call fingerprint like a data company kind of. We've got more things than just data, obviously. But I feel like our core is like, here's all this data that can help you make decisions to prevent fraud and prevent abuse. and make better overall experiences. And then you've got the full flexibility to do with that as you please. Nice. And in the quote past, like if someone was just accessing a site from a VPN, it still happens today, but they're clearly not using fingerprint. If you access a site with a VPN or an incognito mode, which both very valid things to do, basically they kind of became a point in time where you just almost got automatically blocked from things. So, yeah, like how does fingerprint look at that? And then how does it help mean that someone actually can continue to use a VPN legitimately, but still not be blocked from things that they'd like to do? Exactly. So we, out of the box, don't automatically block or allow anything. We do have a rules engine that you can use to build your own custom rules.

You could say, oh, if someone is using a VPN, maybe you work in an industry where regional rules are really important. Maybe it's like certain types of content and you have to be certain specific areas. And maybe you rely on like IP or some kind of geolocation and having a VPN against your rules or regulation. In that case, maybe you do want to block it. But if you're just a regular site, you don't have those kinds of regulations. You probably don't. Most people use VPNs. It's become a very normal thing to use. And so we're going to just give you that information. And then based on your business, based on your use case, you can choose what to do with it. We did a report earlier this year just looking at how many times some of these signals got flagged for all of our identifications. We did over 23 billion identifications last year and continue to grow. And I think we saw VPN raised to 17%. I think that's the number. Don't quote me. But it was like, yeah, like one in five almost. And so VPN on its own is probably not really going to tell you much. Like there are plenty of people who use VPN. There are plenty of people who use like incognito mode.

It's more about what actually makes sense for your use case and your business. Is VPN actually a fraud signal for you? Maybe it is. Maybe it's not. But you've got to figure that out. And we also have tools to help you figure that out as well. You can give us your fraud flagged data, and then we'll compare it to what the signals were and say, Hey, actually, most of the time for your type of fraud, it was these signals that mostly came out and kind of help you. Yeah, because I live in Singapore, but I like to access sites for things in the UK. like even say a government site where I want to deal with something official because I'm still a UK citizen and there have been times where just because I'm on VPN because I'm literally in a public place I'm using Mulvad and it's still a Singapore server for example but I'm being blocked from doing things and not only that like I also noticed I get blocked even off VPN like oh you're in Singapore you're not in the UK so we're just going to block you which is quite frustrating so that's why I think this kind of technology is great if it can be implemented properly effectively

exactly that really is the key it's like okay VPN is only one signal let's say if you're a citizen of country A and you're on vacation in country B and you gotta do something to take care of maybe some government business you shouldn't be blocked just because you're on vacation or you're maybe you're moving around the different world locations yeah what we always try and tell people is like it's not just a signal to use by itself to block somebody it's kind of like what are the other signals that are going on. Were they also tampering with their browser? Okay, now it's a little more suspicious. Versus, was VPN the only thing? Probably it's fine. Maybe you want to ask an extra verification to make sure it's actually you. Yeah. What other, I guess, I'd love to just hear about both use cases as well as I know you've got a pretty illustrious list of companies and customers that actually use this. Have you got any kind of standouts of use cases that are interesting of fraud use cases that people maybe wouldn't think are a thing, but actually fingerprint can help there and or like customer cases that are interesting, you think, for our audience? Yeah, yeah. So our main use cases

usually float around things around like account security. So account takeover, free trial abuse, new account fraud, account sharing, that kind of thing. We also tend to find things around payment fraud as well, chargeback disputes, that type of thing. And then there are also a couple like personalization use cases, but fraud and abuse tend to be the main pieces. And we can help from things like ban evasion to paywall enforcement to everything in between. Basically, anytime you want to figure out like what has this device done before and are there any risky signals around this device. We've got a ton of different case studies, but one that if you talk about like surprisingly surprising to me, I've learned a lot being at this company. I've been at this company for about three years now and I've learned every week I'm learning something new. I'm like, this is a fraud thing people do? I would not have known this if I didn't work at this company. We have a case study where somebody was solving the problem of SMS pumping. Have you ever heard of this? Kind of, but I think you should definitely explain what it is. I'll explain to you guys. I'll do my best to explain. I'm not an expert on this. But the idea

is you think about every time you log into a website and they send you one of those one-time passcodes to your phone, right? Like that can cost money, especially if you're sending it to a phone that's on a carrier that has paid tax messages and you end up paying for that tax message to be sent. And so what people can do is actually maybe more shadier carriers or fraudulent carriers. They have this theme basically where you're being paid for these text messages and maybe the carrier is getting a cut depending on it. Maybe you're just doing your own thing. But at the end of the day, the company who's just trying to help you log in is now being charged all these fees just to send you that one-time passcode. And so people will end up like spamming these one-time passcodes over and over and over again. And you're like, you don't want to not send the one-time passcode for the people who are actually trying to log in. But if someone's trying to abuse your login page to rake in some money, now you're like, okay, not only do you need to detect bot detection, we want to see, can we track, is this device, is there a certain amount of different devices, like a few

select devices that are doing this? Like what's going on? How do we protect this page besides just like an IP rate limit. So that was a new one that I was like, that's a thing? I didn't even think of that. And AI token fraud is also, I mean, that's like a big one as well, right? Yeah. And you know, the thing is really at the end of the day, AI token fraud is really just the same types of abuse with a new label on it, right? So if you think about AI token fraud, that can be anything from, let's say, free trial abuse. If you've got a company that lets you get some free tokens or free credits and you're racking up a bunch of fake accounts to try and use it all up, that's AI token fraud. views. If you are using stolen credit cards to buy certain quota limits or such for tokens, same thing. If you're using account takeover tactics to hack into somebody else's account to use their quota or to use their tokens, right? All these things are really the same types of use cases, but they're just kind of like translated to a new technology and a new, very hot topic, right? Very valuable use tokens. Yeah, super interesting. Yeah, there's just so

many as you say like new ways of committing fraud effectively against platforms that sort of turn up week on week so the whole running theme here is if you can actually identify a real person a real agent as we'll get on to from a duplicate if you like then this is like super super super helpful before we get on to the agent stuff which i'm very personally interested in i believe fingerprint helped identify actually so this is where it's interesting the whole privacy piece that some people might say, well, I don't want to be tracked and so on. Well, fingerprint actually helped, I believe, helped identify a bug in Firefox that was actually, I believe, causing people from, if you were the same person in multiple Tor sessions, you were actually being identified. And so, yeah, could you maybe just speak a bit more to like what happened there and how does fingerprint actually help out on that? Yeah, for sure. So our main product is all about recognizing devices, browsers, but also recognizing the changes in these browsers. These browsers and

devices change all the time. So we have a fabulous research team. They are constantly looking into new changes. They're constantly looking at different ways to find different signals. And so as part of our research team, this was a finding that they had found. So if I remember correctly, it was specifically within like the Firefox private browsing, which also applied to Tor browser as well. And the idea here was around the IndexedDB. So let me try and explain it as best as I possibly can. Remember that I'm not the researcher, so I'll do my best. But basically the idea is websites can store data in your browser, whether it be cookies, like we talked about earlier, session storage, local storage, etc. IndexedDB is another way to store data, to structure data format. And websites can add one to many databases that they want to store data. Usually it's for things like maintaining state or maybe you have like an offline application, those kinds of things. They want to store data in your browser. Cool. Great. The problem was the way that you could retrieve that list of databases from the browser So let say for example I create 15 different databases label them A through I think it P whatever the letter is right A bunch of different databases I create them and even if I order them or create

them in order, the actual order that they get returned back to me is not the same order. That order has a bit more randomness to it. I think it's based on the UUIDs and the way that the hashing worked, but there's a randomness to that order. And so instead of just returning to me A, B, C, D, et cetera, it can return back like G, D, H, whatever kind of combination of letters or whatever you've used in the database. And that uniqueness is what you can use to actually identify those browsers. Now, the problem is that this is what also surprised me when I was like, what? I mean, because that by itself is like, okay, who cares? You get returned the databases. It's a different order, but like whatever. But actually that ordering of the databases can be accessed by other sites. So let's say a different site also makes that same list of A through P databases, for example. The UUID that gets stored in your browser is actually the same. So when the first time it happens, they get the UUID address, cool. The second time it happens, if it's the same name, it gets that same ID. And so if everybody's in cahoots and they're saying, oh, yeah, we all made A through P databases,

then we have that exact same randomized order to track you from site to site. So that was the issue. At Fingerprint, we do not like being tracked. We don't like being tracked, like profiles of data being built on us. We specifically built the product so that you wouldn't be used tracking people from site to site, right? If customer A identifies my phone, for example, they're going to get one visitor ID. Customer B is getting a completely different visitor ID. But this particular thing, you could use it across any website you wanted to, any site. And even if you close the tabs, I think it's only if you fully close, like fully quit the process. not just closing tasks, but fully end the process, only then was it going to give you a new ordering. So that was at a high level. Hopefully I did the researchers proud. I'm giving the overview. I feel I really understand it. So this maybe leads me back to a couple of pieces. One is I'd love to hear more about what are the other determinants that are used to fingerprint, for example.

I'm aware one that I read about can be possible and you can let me know if it's part of fingerprint is like some kind of like sound profile where you can technically play a sort of like silent sound through the sound card and then get back some kind of signal from that. So I guess part one of the question is what are the signals that are used? And then I think the second part of the question is in the example you've just given with the Tor, how does fingerprint determine what it does see as like a good thing to track and what is like a not good thing to track. Yeah, yeah. So I think you're talking about audio canvassing or audio fingerprinting, excuse me. That is absolutely a thing. We've got a great blog post on that as well for folks who are interested to look into it more. But you basically got it. Yeah, we play a noise. You don't hear the noise. It also doesn't show up in your browser as like a noise playing. I think, was it Alibaba or Aliexpress? It's not like dogs can hear it and humans can't. Yeah, no, nothing like that. Exactly. No, no. The customer, the end user would not notice it. But yes, the way that your specific hardware plays certain sound, same thing with like the visual canvas when you're bringing the way your computer draws a certain shape or renders a certain piece of text is very unique based on your operating system, your hardware, your graphics card, that kind of thing.

So these are all different ways that we can get some additional entropy on different devices or browsers. But we have like over 100 different things that we look at. Some of them are more useful than others. Right. Some of them are stronger. Some of them are more popular or obvious. And so it's kind of that combination. And we try and do it in a way that, like, if you change one thing, like if you upgrade your browser, that shouldn't cause the whole fingerprint to, like, you know, disintegrate. Like, you need to be able to have something a bit more stable than that. So we kind of bring those things together. And then your second question, which you asked, your second piece. Yeah, so the second bit was, look at, like, the Firefox Tor piece, which was, yeah, where, like, you know, something that can be used to identify you across, say, tabs or something. That was actually seen as a negative in that case. How does fingerprints determine, like, what's, I don't know, how you call it fair game, or, like, what is the thing that says, like, this is actually a good thing to track, and then this, in the guitar example, is, like, this is not a good thing to track, and we want to flag this to Firefox?

Exactly. A lot of different things go into it. I think for that one, and again, I'm not the one that necessarily made that decision, but I would say definitely for things that are going to be tracking people across the Internet, we really don't want to support that in any way. So we're always looking for new ways to identify browsers and different devices. But something like this that could very easily be used to track people across the internet, especially in something like Tor Browser or Firefox private mode, you've got folks that are maybe trying to do certain government work or dissenting, that kind of thing. There's a certain level of you don't want these things to be easily accessible across multiple different sites. If you want to talk about how this person has access to your site and what they're doing in your business, that's cool. Great. Love that. but let's not try and, you know, build profiles on people or track them across the entire Internet. So I do think that's part of what goes into it as well. I think also the strength of the signal goes into it as well. You know, if it's like maybe it changes too often or if it's not stable enough, if it's not reliable enough, then maybe we'll share it or disclose it.

But whenever we feel like it's actually a security issue, like the Firefox one, the Tor one, we're definitely going to disclose that. They don't come up too often. We've done it a couple of times. I'm always like, what else do we have, researchers? I'm always thinking, I'm like, what else do we have? Like, we have to actually find these things. It does take time. But we usually look at, like, okay, do we believe in the privacy aspect? Is it actually a really good signal? And kind of go from there. Yeah, I love that when DevRel and researchers are like, I want you to find more. I've got more to talk about. So, AI agents, I mean, I think, obviously, a lot of our listener base will be deploying them, using them at this point in time. I'd love to hear about how has fingerprint obviously had to adapt to handle this new way of doing things. And also especially looking at when browsers can kind of fit into two buckets. One is browser automation based agent. And that was, I think, sort of agent V1. Although I'm aware there are, the frontier labs are actually deploying

this type of agent across a bunch of things, just from what I'm aware of, as well as agents that do You just make direct HTTP calls, which would look a bit more like a human, I think, more like an application rather. So yeah, could you maybe just talk through how does fingerprint deal with these cases? How does it start to know what is a legitimate bot versus a bad bot, I guess, if you want to call that? Yeah, yeah, for sure. We layer a bunch of different techniques together. We've always had bot detection based on certain heuristics, based on certain characteristics of the bot, their activity, certain things that we know about, headless browsers, and that type of thing. So we've continued to build on top of that for AI agents and AI assistants. There's also additional technologies, things like WebBotOff, which allow these agents to cryptographically sign their signatures, their headers, so you can say, oh, yeah, this is actually Chats, CPT, your cloud, et cetera, because you try and verify it that way. But obviously, not all AI agents and all AI assistants are going to announce themselves.

For example, at least as of today, as far as I know, Meta's Muse does not necessarily announce itself, right? And people are like, well, how do we detect this thing? We don't want to block it because it's probably somebody who's trying to actually use your website legitimately. But how do we work with this? And so we kind of layer a bunch of different things together. So it's the heuristics about the actual characteristics of the thing, how often, how fast is it working? We'll use what about off. And all these things kind of come back to you. And, again, that really simple JSON. Like we're doing all the hard work in the background. Our researchers are always looking for new techniques and things to do. All you have to worry about is here's the end result. It was a good bot or it was a bad bot. And for bad bots, we mostly mean like it didn't announce itself. It doesn't have to be like a bad bot necessarily, but it's like announcing who it is. Or is it possibly a human? Great. And then from there, we'll tell you information. Oh, yeah, this is Claude or it's, you know, perplexity browser or whatever it is. It's news. Cool. Here's some more information, some details about it, and then you can go from there. but this is definitely a new frontier I think for anyone that has like websites or applications

because it used to be like well is it a bot or is it not a bot and now it's like well hold on we want the bots we want some of them we do want some of these bots these AI agents these AI assistants to be able to interact we're also going to be coming out in the next month actually a assessment where you can kind of go through and say okay are you able to see these bots can you even tell that there on your website? Can you tell what kinds of agents are there? What are they doing? Are you able to actually give them a great path to do what they want to do? Can they make a purchase? Can they make a booking? You know, whatever it is that your site does. Are you making it easy for legitimate agents to do that while still preventing fraud? Are you able to check authorization, right? It kind of goes through all these different things. Because now, back in the day, it was like, well, but most likely it's like, it's probably that. Like, unless like maybe like a Google search or like a search crawler maybe then maybe you want to index your page maybe but those are pretty well known now it is like the wild wild west and i think people are kind of scrambling to try and figure out like how do i still block fraud and abuse while letting in folks who just want to use

an agent to access their site or the application yeah this case of like you know bought purchasing something unfortunately a lot of businesses would benefit from that in the long term yeah i work for company where we're being approached by the Frontier Labs, et cetera, saying, hey, we want to be able to probably purchase stuff on your platform. And we're going, okay, but how do we know it's you? So that's really interesting. You did mention this. It's a draft on IETF, but WebBotAuth, what is that? And I mean, I see there's actually kind of like a cool testing page on fingerprint where you can have your bot, your agent, sorry, send a request and see how it gets returned and how hopefully will this help in the future and do you think it will help, I guess, in the future? I do, I do. I mean, it's still an emerging standard, right? There's so many of these standards I feel like that are coming out right now. I feel like everybody's got their own way to try and handle, especially the e-commerce stuff. I think Google's doing some stuff, Visa doing some stuff but I do think WebBotOff is a pretty solid start The idea at high level is that you would cryptographically sign your headers that your bot is sending and then there a registry that we can compare to to say okay yep we know that this is the bot that says it is and on top

of that, we have verified that that is owned by the company that they say that they are owned by, right? So there's like two pieces. There's one that says like, yep, I am so-and-so, and here's, I signed myself, I'm good to go, but at the same point, you still can kind of say you're anybody. We do a second layer on top of that saying, yes, we've actually checked, we've verified that these specific ones are ChatGPT, Cloud, et cetera. And then the WebBotAuth test page, if you have your own agent that you want to use, you want to make sure that it's being received well by all these sites that are trying to allow AI agents to do legitimate business on their website, the WebBotAuth tool is really great. It's a free tool anyone can use. You can send your bot to it. You can open the webpage in your browser, too, but you're not going to get anything. is meant for bots specifically. But it basically will tell you, you know, if you've configured your cryptographic signatures appropriately. If you're missing headers, that kind of thing, it says, yep, we recognize you, or nope, you need to fix this. So folks can get their agents and bots ready for these types of standards so that if they're legitimate, they're able to actually, you know, go forth and do the right thing.

And, you know, WebBotAuth is just one of the many tools we use. We also have a new feature that's currently in preview, I think. but most of our technology right now is kind of like you add this to your mobile SDK like an SDK you add to your mobile page or your JavaScript you add to your web page but like many of these bots are not using browsers to fetch information for example right they're like you said they're using HTTP requests, direct requests maybe they're not even loading JavaScript for example and so we also have a automation intelligence API coming out as well so that can help as an additional layer to help you find the folks that are not just people you're just loading pages right so now you've got that on the edge You can add it to your malware. It's really, really fast. But again, all of this comes down to we give you the information, and then you can kind of go from there and do what you need to do with it. Amazing. I guess coming back to sort of maybe this still hits the agentic use case, but definitely hits the human use case, is if I can think of many cases, I'll just call them out Cloudflare, where I hit a site and I'm told, can I literally press a button to say that I am human?

And I just think there's like a really, really not great way to do it. I assume like fingerprint, there is no, as a human, I don't know this is happening, right? That's kind of the whole nice part of this, right? Yes, yes, exactly. All of this is happening in the background. The end users have, you know, they don't see anything. They're not challenged. There's no like drop the puzzle piece or click on the fire agents. There's none of that. They don't even need to do anything to be, you know, cleared as not a bot. So that's kind of how I, when I'm talking about the fraud side and the user experience side, they kind of go hand in hand, right? Like the bot stuff helps you protect your pages, your logins, your forms. But if I'm able to easily assess if you're not a bot, great. I'm not going to ask you to do some puzzle to get into the website, right? So you kind of get both sides of it as well. I have faith in technology. I can't wait for the day when I never have to do one of these puzzles ever again. Yes. There was a particularly bad point in time when a certain VPN provider, I wouldn't name which one, And they clearly had a problem with being identified by actually Google. And any time I went to Google, it would ask me about five.

It would just keep repeating through puzzles just to make one search on Google. And I was like, okay, this is too much. Yeah, yeah. This was like, I guess, I think it was pre-AI. So as soon as ChatGPT came along, that was when I was like, okay, well, I'm being half blocked from Google through VPN. So I might as well just go and start my searches in ChatGPT. And the rest is history, I think. but honestly nowadays bots can solve many of these cappers anyways like you know who are we really stopping with these yeah that's a that's a great point as well looking at like where fingerprint is also going from a product perspective i believe fingerprint launched an mcp implementation like back in march and it's i think it's in ga now like what does that sort of enable by having mcp as part of fingerprint yeah we've been launching a bunch of things to help folks integrate fingerprint into the AI tools, whether it's analyzing the data or actually implementing and adding fingerprint to your code base. So a couple of things, the MCP server, that was the first piece we did. It does include like an onboarding skill to kind of get you started.

But for me, I think the main use for the MCP server is really analyzing your data. It can help you figure out, okay, what happened with that bot attack? Like, where is that coming from? Or is there any clusters of devices that are maybe doing more fraud than others? And it kind of helps you dig into that with like natural language without having to pull up a sequel and try and do your own analysis and so we're going to continue to expand that even more i'm really excited about but that's like the main thing for the mcp surf i would say is helping you kind of figure out what's going on and then just recently we've launched our cli so you can now use a new fingerprint cli it tells you like what use case are you trying to solve for it helps you set up your fingerprint account from scratch and you can kind of get off and running in a few minutes and have it fully implemented into your project. We also have a bunch of skills coming out as well. We've got them for different quick starts in a month or so, maybe next quarter. We're going to be doing use case skills as well to make it even more specific to what we think is best practices for different use cases. But all of this is kind of in one package. We actually just this week

launched a new page for AI installation. And so the idea is we know folks are using AI tools. It doesn't matter if you're a vibe coder or if you're a senior engineer, people are using AI tools. So why not make it as easy as possible to like hook fingerprint into those tools, whether it's helping you to build fingerprint into your application, whether it's helping you to analyze, whatever it is, we want to meet you where you are. And it's gotten a lot of great adoption already. It's like, okay, we definitely need to support the folks that are using these AI tools. Yeah, I was going to ask about that. Yeah, just in terms of now, like so many people are doing almost all development through CLI tooling and browser use is changing in that sort of sense. So like fingerprint either today or in the future will be able to sort of see when an agent is still understanding a good agent from a bad one through CLI doing things. Like that's a very general description. Yeah, so that seems like quite an important use case for the future. Yeah, the CLI, you plug it in, you're like, okay, let's get my API keys

from the dashboard. It gets up for you, gets you set up, and then it will implement fingerprint directly into your web page. You're like, oh, I need to protect my login page. Cool. It'll set it up there for you. It's got AI hooked into it. And so it makes it as easy as possible for you to kind of get up and running. Amazing. So, yeah, I think just this recap on the up and running, like where does someone go? And what are kind of like the easy first steps to just seeing that like fingerprint is kind of working and doing things for a developer? Yeah, we've got a demo that you can check out. It's at demo.fingerprint.com. Let me make sure I'm saying that right. Yes, demo.fingerprint.com. If you go there, you'll find a bunch of things. One is the playground. And this is where you can see all those different smart signals I told you about, the raw JSON output that we would give you. All of that's there. It's actually live from your browser. So you can kind of get an idea of how we work, and you can kind of dig through it. And then there's also a bunch of use case demos. So you can say, oh, you know, I'm really interested in preventing financial slubbing or account takeover or, you know, chargebacks or whatever the different use cases are.

I forget the exact ones that we have on there. But you can go through and actually try them out, click them, go through. So, for example, you know, the account takeover one, maybe you trying to hack into someone's account, you can kind of go through and try it yourself interactively. And so those are where I would say to start with taking a look at the demo. And so, actually, let me look at the page right now. Yes, okay, we've got a great one for, like, account sharing as well. You can kind of take a look at it, open the page, create a fake account on the page, open the page, like, in Camino or something else, and say, oh, hold on a second, you recognize you, or open it in a different browser and say, oh, hold on a second, what's going on here? So we can kind of try it out for yourself. You can reset the demos as well as you go along to kind of test it and play with it. Yeah, very cool. Yeah, just looking through all of these. and I'd also just on a personal note recommend the WebBot off trial page. It has a very nice interface, like very fun interface that someone clearly put a lot of effort into. I'll describe it as like cyberpunk CLI is kind of what it feels. So yeah, definitely check that out even if it's a quote just for the UI. It's very fun. I will share it with our designers.

They're very proud of it. Oh good, good, nice. Before we kind of wrap up, Maware also Fingerprint produces like some pretty interesting reports that I think, like, for anyone that's maybe, we do have non-technical listeners as well, that might be kind of interesting. We have, I believe, there's a device intelligence report and there's also, like, a financial services AI traffic survey. Like, could you maybe just speak to both of those? Like, how does that kind of help a company, especially maybe, yeah, sort of just sidebarring to potentially a non-technical user? How does this help them understand sort of the lay of the land, perhaps? Yeah, absolutely. We do a ton of different reports and surveys throughout the year. and so I would say you know look through and see if you can find one that pertains to your industry we've done like financial services we've done like travel hospitality as well AI in general but the device intelligence report I think is a really good one to start with I'm proud of it because I was the one that was like this is a great idea we should do this so I'm very proud of this one but if you really are interested in like what these signals are what do they mean like what are they

detecting it kind of breaks it down piece by piece and also gives you an idea of how frequent these things show up. So like the VPN we saw is like one in five. Okay, not that big of a deal. Versus things like app cloning on a mobile device. Much smaller take, that's probably a much stronger signal for you that something's going wrong. So we do a ton of different reports. We also do a bunch of webinars as well. Some of them are device intelligence specific. Some of them are more like industry specific. So, you know, keep an eye out to see what we've got going on. Amazing. Keisha, thank you so much for coming on. I've definitely learned a bunch today. I'm going to be taking some of this stuff back to our, we have a ton of great developers. I'm very curious how much of this they do and don't know about as well. So we take it to them and yeah, we'll be following along. Thanks so much for coming on. Thanks so much for having me.