EPISODE 1979

[INTRODUCTION]

[0:00:00] ANNOUNCER: 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 and losing control, or too strict and driving real users away.

FingerprintJS was started in 2012 as an open-source project. In 2019, Fingerprint was launched as a separate, full commercial platform, built on the original FingerprintJS 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. Keshia 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 vand.hk, or on LinkedIn.

[INTERVIEW]

[0:02:10] GV: Hello, and welcome to Software Engineering Daily. My guest today is Keshia Rose from Fingerprint. Welcome, Keshia.

[0:02:16] KR: Hey, thanks for having me.

[0:02:18] GV: 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 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?

[0:02:40] KR: Yeah. 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 got me into it. I started there as a sales engineer. I then moved over to the product side as a PM. I was doing a little bit of DevRel at the same time. And I left Tableau to go to Algolia as a PM. I was like, "I missed that DevRel side." In my next role, I was like, "Let me look for something a little bit more in the developer evangelism, developer relations space." That's how I ended up at Fingerprint.

[0:03:18] GV: Nice. Actually, just like, I think where I work, people ask our team, what is DevRel? How would you describe DevRel?

[0:03:25] KR: 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. 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."

[0:03:56] GV: Yeah. It's like this, I think, for the deep in the weeds engineers, it's 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. 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.

[0:04:19] KR: 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 do it the base code stuff like, "Okay, I got it from here. I'll take it to market from here." So, we definitely collaborate a lot.

[0:04:32] GV: Amazing. Yeah, let's talk about Fingerprint. 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?

[0:04:59] KR: Yeah, for sure. Fingerprint started out as FingerprintJS way back in 2012, when our CTO and Co-Founder Valentin created the open-source project, FingerprintJS. He worked on that a while. Then I think it was 2019, or maybe 2020, he actually made it into a product and a full-on SaaS company. That became Fingerprint without the JS. I think we dropped that a couple of 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 expands on it. What exactly does this library do? It basically looks at the different characteristics of your browser. It can say, "Okay, based on the way you draw certain images, the types of fonts, or plug-ins 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.

You can say, "Oh, okay. This person logged in right to your bank," for example. I don't have to keep putting my password in every single time I log in. "Oh, great. Remember my device? Cool." Next time I 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 a stolen credit card, or they did some kind of abuse. Well, we don't want to allow that to come back again, so now you can do that recognition again.

The open-source version is all client side. Of course, the commercial version is a bit more robust, obviously, paying for it. Some more additional features on top of it. It also includes a server-side component and a whole bunch of smart signals, which we can get into later. That's the main difference between the open-source library and the company itself.

[0:06:49] GV: Yeah. Nice. You 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?" How do you delineate between a fingerprint and a cookie?

[0:07:05] KR: Great question. Fingerprinting, when it's done right, at least, doesn't require a cookie. The thing about fingerprinting versus a cookie is the cookie can get lost at any time, right? The cookie can get cleared, it can get deleted, or it can be blocked from being set to begin with. 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, it's like, oh, just delete this. Now you completely lost track of this person. You've got nothing else that you can use to even get any signal about what they might be doing, or if they're suspicious. Fingerprinting in general, not just our product, but in general, doesn't require or rely on storing data that anyone could just manipulate, or change any time.

[0:07:52] GV: Yeah. 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. As we'll hear, I think throughout this episode, there are so many reasons that actually by having, let's just keep calling 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 when to serve a real person versus not a real person, or a real agent, and we'll get on to that, because that's an interesting topic as well.

Yeah, I think that's just something to call out right at the beginning, where people again, maybe listening, and there was even something on Hacker News, maybe a couple of weeks ago, where someone had a slightly negative take on just the idea of fingerprinting. Not the company itself, but fingerprinting in general. 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. I'd love to hear, if I'm a developer, how am I actually going to implement this? We're going to hear from the developer side and then maybe hear a bit more from the user side. If I'm a developer, how am I implementing fingerprint effectively?

[0:09:07] KR: Yeah. So, we work with both websites and mobile applications. The visitor, we call our visitor ideas, 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. 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, cool, fingerprint 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're to send it to your backend, so you can actually make sure you're getting trusted data. Then on the backend, we've got a ton of different SDKs for all kinds of frameworks and languages. 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 signal, 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 in a bunch of different bullions 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.

[0:10:26] GV: Yeah. I'd love to hear about the smart signals. I believe there's a lot of them, so maybe you can walk us through the different types that we have.

[0:10:33] KR: Absolutely. In that JSON response that we give you, and actually, if you take a look at our website, we've got a demo. You can see the whole thing for your own browser. In there, there's over a hundred different data points. 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, like give us more data, as much data as possible. They'll just dump everything in there. Some folks will look at what we call our smart signals. Those are more of like a derived signal.

For example, one of the raw attributes might be your browser, your browser type, for example. The smart signal would be more like, "Oh, are they using a VPN?" We'll break it down by why we think they're using a VPN. Is there a time zone mismatch? Is it a certain exit node, for example? The smart signals do a bit more on the back end to give you some of those higher details to make decisions on.

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." For that, we have our suspect score that bungles all of them up together into just one number. The higher the number, the more signals that you've triggered and the more suspicious that you are. It depends on how you want to go about it. I always call Fingerprint a data company kind of. We've got more things in 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. Then you've got the full flexibility to do with that as you please.

[0:12:05] GV: Nice. In the "past," 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 in incognito mode, which both very valid things to do, basically, it became a point in time where you just almost got automatically blocked from things. Yeah, how does Fingerprint look at that? 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?

[0:12:38] KR: Exactly. 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 certain types of content and you have to be certain specific areas. Maybe you rely on IP, or some kind of location, and having a VPN might be 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. We're going to just give you that information. 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. I think we saw VPN raised to 17%. I think that's the number. Don't quote me. It was like one in five almost. VPN on its own is probably not really going to tell you much. There are plenty of people who use VPN. There are plenty of people who use 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're going to figure that out. 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 up and help you."

[0:14:13] GV: Yeah. I mean, because I live in Singapore, but I like to access sites for things in the UK, and even say a government site, where I want to deal with something official, because I'm still a UK citizen. There have been times where just because I'm on VPN, because I'm literally in a public place, I'm using Mullvad. It's still a Singapore server, for example, but I'm being blocked from doing things. Not only that, I also noticed that I get blocked even off VPN. Like, "Oh, you're in Singapore. You're not in the UK. We're just going to block you." Which is quite frustrating. That's why I think this technology is great if it can be implemented properly and effectively.

[0:14:52] KR: 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 got to do something to take care of, maybe some government business, you shouldn't be blocked just because you're on vacation, or you're moving around in 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 like, what are the other signals that are going on? Were they also tampering with their browser? Okay, ow it's a little more suspicious. Versus was VPN the only thing? Probably, it's fine. Maybe you want to ask an extra verification step, make sure it's actually you.

[0:15:27] GV: Yeah. 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 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 their and/or customer cases that are interesting you'd think for our audience?

[0:15:53] KR: Yeah. Yeah. Our main use cases usually float around things around 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, charge back, dispute, that type of thing. Then there are also a couple personalization use cases, but fraud and abuse tend to be the main pieces. 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 want to talk, surprisingly surprising to me, I've learned a lot being at this company. I've been at Fingerprint for about three years now and I've learned - every week, I learn 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?

[0:16:51] GV: Kind of, but I think you should definitely explain what is it.

[0:16:54] KR: I'll explain. 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, that can cost money, especially if you're sending it to a phone that's on a carrier that has paid text messages. You end up paying for that text message to be sent. What people can do is actually, maybe more shadier carriers, or fraudulent carriers, they have this scheme basically, where you're being paid for these text messages. Maybe the carrier is getting a cut depending on it. Maybe you're just doing your own thing. 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. People will end up spamming these one-time passcodes over and over and over again.

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 bot detection, we want to see, can we track - is this device, is there a certain amount of different devices? Have you select devices that are doing this? What's going on? How do you protect this page besides just an IP rate limit? That was the new one that I was like, "That's a thing? I didn't even think of that."

[0:18:11] GV: AI token fraud is also, I mean, that's a big one as well, right?

[0:18:14] KR: Yeah. 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? 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 abuse. If you are using stolen credit cards to buy certain quote or limit instruction 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 translated to a new technology and a new very hot topic, very valuable use tokens.

[0:18:59] GV: Yeah, super interesting. Yeah, it was just so many, as you say, new ways of committing fraud effectively against platforms that turn up week on week. The whole running theme here is if you can actually identify a real person, a real agent, as we'll get onto from a duplicate, if you like, then this is super, super, super helpful.

Before we get onto the agent stuff, which I'm very personally interested in, I believe Fingerprint helped identify actually - 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. Yeah, could you maybe just speak a bit more to what happened there and how does Fingerprint actually help out on that?

[0:19:52] KR: Yeah, for sure. 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. We have a fabulous research team. They are constantly looking into new changes. They're constantly looking at different ways to find different signals. As part of our research team, this was a finding that they had found. I remember correctly, it was specifically within the Firefox private browsing, which also applied to Tor browser as well. The idea here was around the index DB. 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.

Basically, the idea is websites can store data in your browser, whether it be cookies, like I talked about earlier, session storage, local storage, etc. Index DB is another way to store data. It's a structured data format. Websites can add one to many databases that they want to store data. Usually, it's for things like maintaining state, or maybe if you have 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. Let's say, for example, I create 15 different databases, label them A through, I think it's 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. so instead of just returning to me, ABCD, etc., it can return back GDH, whatever combination of letters, or whatever you've used in the database. That uniqueness is what you could use to actually identify those browsers. Now, the problem is that, this is what also surprised me and I was like, "What?" I mean, because that by itself is okay, who cares? You get returned the databases. It's a different order, but whatever. But actually, that ordering of the databases can be accessed by other sites.

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. 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 codes 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. 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. 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. This particular thing, you could use it across any website you wanted to, any site. Even if you close the tabs, I think it's only if you fully close, like fully quit the process, not just closing tabs, but fully end the process, only then was it going to give you a new ordering. That was the high level. Hopefully, I did the researchers proud on giving the overview.

[0:23:10] GV: I feel I really understand it. 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, like one that I read about that can be possible and you can let me know if it's part of Fingerprint is some kind of sound profile, where you can technically play a silent sound through the sound card and then get back some kind of signal from that. I guess, part one of the question is, what are the signals that are used? 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 a good thing to track, and what is a not good thing to track?

[0:23:55] KR: Yeah, yeah. 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 and do 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 a noise playing. I think, was it Alibaba, or AliExpress types like that using -

[0:24:14] GV: I feel like dogs can hear it and humans can't.

[0:24:16] KR: 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 the visual canvas at Fingerprint. 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. These are all different ways that we can get some additional entropy on different devices, or browsers. But we have over a 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. It's that combination.

We try and do it in a way that if you change one thing, if you upgrade your browser, that shouldn't cause the whole Fingerprint to disintegrate. You need to be able to have something a bit more stable than that. So, we bring those things together. Then your second question, would you ask your second piece?

[0:25:09] GV: Yeah. The second bit was, if you look at the Firefox Tor piece, which was, yeah, where 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 Fingerprint determine what's, I don't know how you could call it fair game, or what is the thing that says, this is actually a good thing to track, and then this, in the Tor example it's like, this is not a good thing to track and we want to flag this to Firefox?

[0:25:36] KR: Exactly. A lot of different things go into it. I think for that one, and again, I'm not the one that necessarily made a 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. 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 may be trying to do certainly be 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 build profiles on people, or track them across the entire Internet. 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. If it's like, maybe it changes too often, or if it's not stable enough, if it's not reliable enough, then won't maybe we'll share it, or disclose it. 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. Always like, "What else do we have?" Researchers are always thinking of like, "What else have we found?" We have to actually find these things. It does take time. But we usually look at, okay, is it, do we believe in the privacy aspect? Is it actually a really good signal? And go from there.

[0:27:02] GV: Yeah. I love that when DevRel and researcher are like, "I want you to find more," so I've got more to talk about.

[0:27:08] KR: Exactly.

[0:27:09] GV: Yeah. 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 is Fingerprint obviously had to adapt to handle this new way of doing things and also, especially looking at when browsers can fit into two buckets. One is browser automation-based agent. That was, I think 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 just - they make direct HTTP calls, which would look a bit more like a human, I think. More like an application rather. 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 it that?

[0:28:03] KR: 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, have those browsers and that type of thing. We've continued to build on top of that for AI agents and AI assistants. There's also additional technologies, things like web bot auth, which allow these agents to cryptographically sign their signatures, their headers, so you can say, "Oh, yeah. This is actually ChatGPT, or Claude, etc. You can actually try and verify it that way.

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? 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? We layer a bunch of different things together. It's the heuristics about the actual characteristics of the thing, how often, how fast is it working? We'll use web bot auth. And all these things come back to you. Again, that really simple JSON.

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. For bad bots, we mostly mean it didn't announce itself. Doesn't this have to be a bad bot necessarily, but it's not announcing who it is. Or is it possibly a human? Great. Then from there, we'll tell you information, "Oh, yeah. This is Claude, or it's a Perplexity browser," or whatever it is. It's muse. Cool. Here's some more information, some details about it and then you can go from there.

This is definitely a new frontier, I think, for anyone that has websites, or applications, because it used to be like, well, is it a bot or is it not a bot? 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 go through and say, okay, are you able to see these bots? Can you even tell that they're 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? 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 goes through all these different things.

Back in the day, it was like, well, bot, most likely it's probably bad. Almost maybe a Google search, or 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. I think people are scrambling to try and figure out, 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?

[0:30:46] GV: Yeah, this case of bot purchasing something. Unfortunately, a lot of businesses would benefit from that in the long term. Yeah, I work for a company where we're being approached by the frontier labs, etc., saying, "Hey we want to be able to probably purchase stuff on your platform." We're going, "Okay. But how do we know it's you?"

[0:31:05] KR: Yeah. Yeah.

[0:31:06] GV: That's really interesting. You did mention this. It's a draft on IETF, but web bot auth. What is that? I mean, I see there's actually a cool testing page on Fingerprint, where you can have your bot, your agent, sorry, send a request and see how it gets returned. How hopefully will this help in the future? Do you think it will help, I guess, in the future?

[0:31:29] KR: 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's doing some stuff. I do think web bot auth is a pretty solid start. The idea at high level is that you would cryptographically sign your headers that your bot is sending. Then there's a registry that we can compare to to say, "Okay, yup. We know that this is the bot that says it is." On top of that, we have verified that that is owned by the company that they say that they are owned by.

There's two pieces. There's one that says, "Yup, I am so and so. I've signed myself. I'm good to go." Yet, the same point, you still can say you're anybody. We do a second layer on top of that saying, yes, we've actually checked. We verify that these specific ones are ChatGPT, Claude, etc. Then the web bot auth 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 web bot auth tool is really great. It's a free tool anyone can use. You can send your bot to it. You can open a web page in your browser too, but you're not going to get anything. It's meant for bots specifically. At least, it will tell you if you've configured your cryptographic signatures appropriately. If you're missing headers, that kind of thing. It says, "Yup, 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 go forth and do the right thing.

Web bot auth is just one of the many tools we use. We also have a new feature that's currently in preview, I think. Most of our technology right now is like, you add this to your mobile SDK. It's an SDK you add to your mobile page, or your jobs add to your web page. Many of these bots are not using browsers to fetch information, for example. They're like you said, they're using HTTP requests, direct requests, maybe they're not even loading JavaScript, for example. 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 necessarily just loading pages. Now you've got that on the edge. You can add it to your middleware. It's really, really fast. Again, all this comes down to, we'll give you the information, and then you can go from there and do what you need to do with it.

[0:33:43] GV: Amazing. I guess, coming back to 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 click, literally press a button to say that I am human. I just think there's a really, really not great way to do it. I assume Fingerprint, there is no, as a human, I don't know this is happening right. That's the whole nice part of this, right?

[0:34:12] KR: Yes, yes. Exactly. All of this is happening in the background. The end users have - they don't see anything. They're not challenged. There's no drag the puzzle piece, or click on the fire hydrants. There's none of that. They don't even need to do anything to be cleared as not a bot. When I'm talking about the fraud side and the user experience side, they go hand in hand. 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. You get both sides of it as well.

[0:34:45] GV: I have faith in technology. I cannot wait for the day when I never have to do one of these puzzles ever again.

[0:34:50] KR: Yes.

[0:34:51] GV: There was a particularly bad point in time when a certain VPN provider, I wouldn't name which one, they clearly had a problem with being identified by actually, Google. Anytime I went to Google, it would ask me about five. It would just keep repeating through puzzles just to make one search on Google. I was like, okay, this is -

[0:35:11] KR: That's too much.

[0:35:12] GV: Yeah. Yeah. This was, I guess, pre - I think it was pre-AI. 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 of the history, I think.

[0:35:26] KR: Honestly, nowadays bots can solve many of these captchas anyways. Who are we really stopping with these?

[0:35:32] GV: Yeah, that's a great point as well. Looking at where Fingerprint is also going from a product perspective, I believe Fingerprint launched an MCP implementation back in March. I think it's in GA now. What does that enable by having MCP as part of Fingerprint?

[0:35:49] KR: Yeah. We've been launching a bunch of things to help folks integrate Fingerprint into AI tools, whether it's analyzing the data, or actually implementing and adding Fingerprint to your code base. A couple of things. The MCP server, that was the first piece we did. It does include an onboarding skill to get you started. 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? Where is that coming from? Or, is there any clusters of devices that are maybe doing more fraud than others? It helps you dig into that with natural language, without having to pull up a SQL and try and do your own analysis. We're going to continue to expand on that even more, which I'm really excited about. That's the main thing for the MCP server, I would say, is helping you figure out what's going on.

Then just recently, we've launched our CLI. 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. You can 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 the use case skills as well, so make it even more specific to what we think is best practices for different use cases.

All of this is in one package. We actually just this week launched a new page for AI installation. The idea is like, we know folks are using AI tools, right? It does not know if you're a vibe coder, or if you're a senior engineer, people are using AI tools. Why not make it as easy as possible to 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. It's gotten a lot of great adoption already. It's like, okay, we definitely need to support the folks that are using this AI tools.

[0:37:38] GV: Yeah, I was going to ask about that just in terms of, now so many people are doing almost all development. I feel like CLI tooling and browser use is changing in a sense. Fingerprint, either today or in the future, we'll be able to see when an agent is still understanding good agent from a bad one through CLI doing things. That's a very general description, but yeah. That seems quite an important use case for the future.

[0:38:07] KR: Yeah, the CLI you plug it in, you're like, okay, let's get my API keys from the dashboard. It's set for you, get 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 get up and running.

[0:38:27] GV: Amazing. Yeah, I think just to recap on the up and running, where does someone go? And what are the easy first steps to just seeing that Fingerprint is working and doing things for a developer?

[0:38:40] KR: 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. 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 get an idea of how we work and you can dig through it. Then there's also a bunch of use case demos. You can say, "Oh, I'm really interested in preventing [inaudible 0:39:12], or account takeover, or chargebacks, or whatever the different use cases are. Paywall. I forget the exact ones that we have on there. But you can go through and you can actually try them out, click them, go through.

For example, the account takeover one, maybe you trying to hack into someone's account, you can go through and try it yourself interactively. Those are where I'd say to start with taking a look at the demo. Actually, let me look at the page right now. Yes. Okay, we've got a great one for account sharing as well. You can take a look at it, open the page, create a fake account on the page, open the page in incognito, or something else and say, "Oh, hold on a second. We recognize you. You are open in a different browser," and say, "Oh, hold on a second. What's going on here?" You can just try it out for yourself. You can reset the demos as well as you go along to test it and play with it.

[0:39:59] GV: Yeah, very cool. Yeah, just looking through all of these. Also, just on a personal note, recommend the web bot off trial page. It has a very nice interface, a very fun interface that someone clearly put a lot of effort into. I'll describe it as cyberpunk CLI. That's what it feels. Yeah, definitely check that out, even if it's, I say, "just for the for the UI is very fun."

[0:40:20] KR: I will share it with our designers. They're very proud of it.

[0:40:23] GV: Oh, good, good. Nice. Before we wrap up, where also Fingerprint produces some pretty interesting reports that I think for anyone that's maybe, we do have non-technical listeners as well that might be interesting. We have, I believe there's a device intelligence report and there's also a financial services AI traffic survey. Could you maybe just speak to both of those? How does that help a company, especially maybe, yes, just side barring to potentially a non-technical user. How does this help them understand the lay of the land, perhaps?

[0:40:55] KR: Yeah, absolutely. We do a ton of different reports and surveys throughout the year. I would say, look through and see if you can find one that pertains to your industry. We've done financial services. We've done travel and hospitality as well, AI in general. 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." I'm very proud of this one.

If you really are interested in what these signals are, what do they mean? What are they detecting? It breaks it down piece by piece and also gives you an idea of how frequent these things show up. The VPN, we saw it's 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 is going wrong. 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 industry specific. So, keep an eye out to see what we've got going on.

[0:41:51] GV: Amazing. Keshia, 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.

[0:42:07] KR: Thanks so much for having me.

[END]