Hello and welcome to the fifth in our series of webinars, 51Degrees Live.

Today we're going to be looking at the Go programming language and device detection and IP intelligence.

I'm joined by Eugene Dorfman, who looks after some of the 51Degrees code, and we're going to be doing a deep dive taking through how to use these products in the Go programming language.

So, Eugene, why don't you start with the 51Degrees GitHub page and how to find the examples that we're going to be showing you today?

Right. Thanks for the introduction.

So we are at the 51Degrees GitHub organisation page.

You can see that 51Degrees has lots of iintegrations for the IP intelligence and device detection product.

So today we're going to look at the Go integration specifically.

We are going to look at two repositories that have necessary assets for both the libraries and the examples.

So the repositories are IP Intelligence - Go, and Device Detection - Go.

So these repositories have comprehensive readme files on how to build the libraries, how to integrate them, and also there is a section dedicated to examples.

So examples do have their own readme file that describes the lists all of the examples that we have and also has an instruction on how to run them.

The same should be true for device detection.

It also has the examples directory, and it has the list of examples, and instructions on how to run them.

So we must say that both IP Intelligence - Go, and Device Detection - Go, like all other languages that we provide, they are actually wrapping the native library, that does the actual detection.

So the native library is written in the C language.

And GO has a natural way to compile C code using C Go interface.

This doesn't require you to separately build the library, so you don't have to do any extra steps.

You integrate the IP Intelligence Go, or device detection, go as a normal go package.

So in the examples that we are going to look at, For example, if we start with the IP intelligence go, you're gonna see the go mode file, that features this AP intelligence go.

So you don't need anything extra.

You don't need to compile the C library, because this library is actually compiled for you inside the goal.

So go and see here, actually coming together into the same library.

Right.

There's no separation, it's all the same code.

So that is the power of Go, isn't it?

If you've been watching the full series of webinars, you'd have seen that we have this kind of native, Java, native, C# interface through the engines, we're not going to see that because we're using Cgo, so it compiles into the same executable.

Yes, so, unlike those languages, unlike C, .NET, runtime, where the native library compiles into its own dynamic library.

Here, the native library compiles into the static binary together, so it's statically compiles into the same binary as the main executable code.

So we get, like, a single monolith executable.

Cool.

So that is actually making it a bit more lightweight.

So, yeah, so...

Just make a stop.

So we have a look at it running in on premise for device detection.

And we always start with console examples.

We encourage you to start with console because you get less complexity, you go to getting started, which is what we're going to look at now, and you can see how the different features work.

Right , on the top this is the IP intelligence, so I think we start with IP intelligence.

Yes.

And for Go, we actually have only on-premise examples, we don't have the call service implemented for go integration with the cloud service.

I mean, you can use the API, obviously, but you will have to self-write that.

But we do have the full on premise integration suite for IP intelligence and device detection in the goal language.

Just before you move on, there's a reason we don't have cloud backing for go, is because what we've found is all our customers who are using go, wonton premise, the reason they're using go is for speed and performance, they don't want the call to the cloud service, so we just haven't built that.

If you really, really, really want that, please raise a feature request, and we'll have a discussion with you about it, because we're always customer let.

Right.

So, yeah, so, because examples are actually living in the same repository as IP intelligence go, they are just using the same Go mod file, and they will use the, this package, the IP intelligence go that leaves alongside.

Well, it is the main repository itself.

So, example leaves alongside the package, basically.

So, this example shows you how to construct what we call an IPI on premise engine.

So this, call, IP on-premise, actually creates the engine, and there are various properties, various configuration options, that you provide, to this, to this constructor, and, I apologise if I, my terminology is, is not precise, because I'm not a Go engineer by trade, but I'm trying to get as close as possible to the right terminology.

So, so we construct this engine, object with using, this pattern with options, providing a different, configuration, parameters.

The important one is the best to the data file.

So we actually take the data file from the environment variable.

So when I run this example, we provide the path to the data file as a data file environment variable, and it just provides the relative path to the actual data file.

And then we provide that to the engine to start up.

So if I run this example, what we're gonna see in the output is the...

So the red is not an error. It's just the way we output things in the...

Just to make it clear what's part of the example output.

Yeah, so it would just say, like, this is the IP address that would give you this engine as an input, and this is the result that we get from the engine as output.

So, we have, like, various properties, output for each IP address.

So we actually compared them to the expected results.

So this example works both as an example, as an as a test.

So it compares stuff between actual unexpected.

We also have a web example for Go, so I can switch.

Yeah, let's have a look at that so that we just why Eugene's loading up the web example.

We encourage everyone to start with the getting started console examples because they show what's involved.

You just saw they're the construction of the IPI engine, the various different properties you pass into the new method.

And that gives you the concepts effectively that are needed in order to use this.

So we had an IP address being passed in, and then we had results coming back.

So you get to do and see all of that without the additional complexity of the HTTP server.

Once you've done that, then move on to the web example, where we can show you some far prettier output, which is easier to understand.

Right, but similarly to the console example, we still have to construct the engine pretty much the same way as we constructed it for, like, for a console, like, for web, it's gonna be the same engine, but just integrate it a little bit differently, and supplying, and kind of create, generating the results that we will show on page for you.

So let me run that.

Okay, we're gonna start up a guy web server here.

Yeah, so it's listening on 8080.

And if I navigate to local host 8080 with my current IP address.

It's gonna be...

Is the local host, right?

Yeah, local hosts look back.

So nothing interesting.

I can actually override this, and, you know, just type in any IP address, and we will get results for it.

So, for example, this is a Swedish IP address.

we can also run this behind the reverse proxy and, check.

Yeah, see what the real network connection has to say.

Right, so it's 8080, 8080?

Okay.

And if we navigate to this URL, so this is our current IP address.

Okay, see what we know about that, yeah?

Yeah, so we are in Britain.

Yep.

And, in fact, quite a large part of Britain as well, yeah.

And somewhat in Ireland.

Yeah, yeah, yeah.

But anyway we can also check this from my iPhone.

Yeah, let's have a look at that, yeah.

And then...

So what we'll do now is we'll use a real mobile phone, and I think you've got a VPN on there, so we can see...

Yeah, I can actually.. Pretend to be in America and see what it has to say.

I've been going to America real quick.

So through the power of VPNs, we're going to.

United States.

Right.

So, now, I will do the iPhone mirroring.

Right, and if I open this, um...

Cool.

Yeah, so we are actually within the, um...

So, it might be a cast page, actually, let me actually refresh it.

So it's from a different example.

It was cast from a different example.

So now we are, let me see where we are at, actually, yes, we are in the United States.

Oh, that's good news.

We were expected to be given the VPN.

Yeah, and...

Okay, we may not be in the United States, actually, because it looks like there's, what's that Dominican Republic's part of this VPN.

Yeah, so, well, you can see that this is actually a data centre.

I actually don't have a connection type.

Maybe we should add a connection type.

That's a good idea.

Let's add connection type to this demo while we're here, and then we can explain what those different properties mean.

Right, okay, so...

Let me add one more property here.

So, this is the output of...

Where is properties?

If I around this.

Cool, so it's automatically gonna refresh the UI.

No, not automatically I can do relaunch it, but anyway.

You can see that the connection type for my VPN connection says hosting and anonymous and you would expect hosting to be some like Amazon would be a hosting.

Yeah, I think that's reasonable.

So let's go back to those properties, then, for that IP address.

Yeah, just a second, I just wanted to refresh this one to show that this is actually a broadband connection.

Yeah, in England.

So let's put those two next to each other, and then we can just explain the properties that are being returned there for IP. Intelligence.

Right.

So the first thing you can see is we're not just returning a point, which is the most probable point based on the sample of data we've got from real devices.

We're also looking at what's the likely service area, which is the red that you're seeing there in both the maps.

On the broadband connection, the one for the United Kingdom, we can see that the connection type is broadband.

That's what we'd expect.

There's a broadband connection.

And the location confidence is medium.

Whereas for the VPN, It's actually high.

So this is telling us that we are reasonably confident in the location, but you might not want to make high impact business decisions on medium base location confidence.

We can also see that the human probability is 10, so we think it's very likely this is going to be a human, that's actually providing this information.

If it were one, then it would almost certainly not be human.

On the one on the right hand side, which is the iPhone on the VPN, We can be confident in the location.

So we're confident that it is servicing a very large geographic area, skewed, as you can clearly see, on the map towards the eastern part of the United States, but also services other areas, which is what we would expect for a VPN.

And in this particular case, we're not seeing very many samples from other countries, which is why we're seeing a lot around the US.

You've then got the human probability, so that's slightly lower, which again would make sense given it's a data centre, as you observe there, Eugene.

And then you've got those diversity figures.

So they're really important.

They're not populated for the one in the United Kingdom.

We simply don't see enough data to be able to establish the diversity.

But we'll be looking at is how diverse is the number of the different types of devices that we're seeing there.

So the operating systems, the browsers and versions, and the hardware is the model of device.

So, we can see there for a hosting IP address.

We've got quite a high amount of diversity coming from that, which, again, would be suspicious as far as the VPN's concerned.

So we're not providing you necessarily the information that says this is definitely a VPN or not.

We're not hiding that from you because that's going to depend on your business case.

Sometimes you might not be worried about it.

Sometimes you might be.

We're providing you the geographic area.

So if you do care about, say, content restrictions based on geography, maybe your licensing, and being used in the streaming services, et cetera.

You can actually see the countries that you're going to be potentially servicing through this particular IP address.

So within the limits of what can be done with IP, we're giving you the information that you can use to really take action from this information.

And we're starting to combine the device detection with the IP intelligence here.

We're going to show you more about that in a short while, with those diversity values.

Right.

So this I think covers the examples that we had for IP intelligence alone.

Yep.

So maybe it's a good time to tell about...

Let's move across to device detection.

Let's show our audience how that's working and then we'll look to combine the two.

Right, so for device detection, is a similar engine.

It actually was before IP Intelligence, but it doesn't really matter from the technical standpoint.

So, it's also an on premise, package, which takes the data file path, and I'm providing the data file on the common line.

Well, actually, and providing the data file through the environment variable for this particular example.

So, there is a path to the data file, and, this is a console example that is gonna show you, like, a limited number of properties.

And, like, every engine operates with some input data and some output data.

So these properties are the output data.

I can add more here, and the input data would be, like, the user agent, and the user agent client hint.

We call it evidence.

So we call the input data evidence.

So if I run this console example, I'm gonna get, so for this evidence, for this, Android device, I get this device detection results for this desktop device.

I get these results, and this is, like, another Android media hub device, I guess.

We can actually...

And just find out whether we add device type and maybe price band to the output and show people how to do that.

So it's as easy as adding, two more properties to the output.

You can add however many properties you like.

They're all available online at the property dictionary page.

We'll open that in a minute.

Let's finish this first.

We can show people where that is.

Cool.

Right, so, for the first one, we get a smartphone, as a type, and a price band.

The second, we get a desktop as a type, and a new price band, because these are primary...

We did for enough, yeah.

And, well, the last one is also identified as a smartphone, so maybe I was wrong.

It's not a media hub device.

It's probably an Android, yeah.

It looks like it's an Android phone.

But anyway, yeah, this is how easy it is to add...

And let's show people how that's added into the flow data, sorry, into the engine.

How do we actually cool that here?

Well, the engine actually comes, so, the engine, doesn't consume the list of properties in any way, it just gives you the result object, and then you use the list of properties to retrieve those from the result object.

So when we have constructed the engine here, We...

So we pass that to the run method, yeah.

Yeah, and the actual use of engine happens within the match method.

So the engine is given the evidence.

In the process method, it processes this evidence and returns the results.

And then, well, defer results free means we will free that object once this function is finished.

And this is the list of properties that we want to get from the result.

So the retrieval of those properties happens in this loop, because we loop over the list of properties.

And for each property, we first check whether there is a value or not.

So if there is no value, then we will just continue.

If there is a value, then we try to retrieve the actual value, string, and display it. As a string, an output on the screen.

So, this is as simple as this.

And it's exactly the same for IPI, isn't it?

So we've just got these single engines.

If you saw the previous webinars, we also had a pipeline as well, which wraps the engine.

That's not available currently for go there, simply hasn't been enough customer demand.

But again, if that's something you want to see, then let us know, and we can have a discussion with you about how we can build out those features.

We go.

Right, and I think we wanted to briefly mention the property dictionary.

Yeah.

So this is where you can see all the properties.

Right, so, this is, basically the list of all available properties for either device or IP intelligence, for example, for location, and, like, we spoke about the, um.. For example, uh...

Coordinate accuracy.

Accordance, accuracy.

Yeah, that's got location confidence.

The allocation confidence, for example.

And other purposes are, or human detection.

Well, there is a human probability score, that we can also show how to add, into the subsequent example.

So, any, so, there is over, like, 20, I think, close to 300 properties now available.

Oh, there's over 300, if you consider IPI and device detection.

Okay.

Device detections notching up to 300, although some of them are obsolete.

People don't nearly really care about CIADP anymore.

Which is a sort of pre Android type runtime environment.

Right.

So that was a common line example for device detection, and I think we have a good web example of device detection, but it is actually a combination of both IP intelligence.

Like, we have a web example that combines both IP intelligence.

Well, that would be cool to see, so we can see the two running alongside each other, yeah.

Right, so, let me switch back to the IP intelligence go repastory, and, we have a tab, well, a directory called mixed here, and mixed has actually got getting started, console example, and getting started web, UI example.

So we can actually start with the console example first.

Okay.

Okay, cool. Mixed console, I guess.

Right.

So running that, would actually return you...

So, so, you just hit run now, and then with it, well under a 2nd, you got all the results back.

Yes, because this is because we are using a low memory performance profile for loading the data file, so it...

And it all ran in process.

Yes.

So it's not loading into memory.

Like, it doesn't read the whole file into memory.

So it...

But we'll talk a little bit more about that in a minute, but personally, I think that's pretty impressive.

There's not any other solution out there that can do both device detection, like intelligence from a cold start in under a second.

Right.

So the benefit of running it in process, unlike doing some out of process integration, like, for example, if you do a network call, or a, IPC, like, interprocess communication call, like, to other process.

So either unique sockets or TCP sockets, they would still take time, TCP sockets, probably 100s of milliseconds, unique sockets, probably milliseconds.

But this is submillisecond, uh...

Yeah.

There is no interprocess or network communication happening here, so everything is the same memory spacing process.

So very, very quick.

This is the benefit of, you know, this kind of integration.

The go together is going to, with CA is going to make it fast, and then the fact that it's all in process, it gives us that extra benefit as well.

Sorry, I just love that.

That is so fast.

Sorry, talk us through what we really came here to see, which is the two properties, two groups of properties being returned together.

Right, so, in this example, I just wanted to highlight that we feed a mixed kind of evidence.

We feed here the device detection, related evidence, which is user agent, and we feed the IP address as evidence, and that allows us to get two sets of properties, but we feed them into different engines, actually.

So I just wanted to highlight that we construct two engines, and they just work alongside in the same process, as you mentioned.

So there is this device detection engine, which is the engine, and then alongside it, there is IPI engine, and then we can feed all evidence to both engines.

They will filter out the evidence that is important to them.

So, like, what evidence is relevant to device detection, it will use irrelevant.

It will, you know, discard.

So, yeah, they will do their, their part in detecting those properties.

And we just output them.

But I think the real, where it really shines is in the web example, so we can...

Yeah, let's go and have a look at that.

So this is returning everything in the console, again, handy to look at as a developer to start with, before you get all the extra overhead of the HTTP to worry about.

But it looks a lot prettier, doesn't it, in the combined web example.

Right.

So, mixed web, I think.

Actually, we could get and start with WebUI, I think, is the example that we wanted to show.

So it listens on 8080.

So if I go to, I think I still have the same reverse proxy, yeah.

Oh, look at that.

Easy.

Right, so we've got the same device detection.

IP intelligence results as the previous example that we were looking at.

Now, we also have the device detection results on the side, like, side by side.

We can see both.

So I guess if we, for example, pretend to be an android device, and let me actually try to...

So this is Galaxy Z, whatever.

You can zoom a bit more there, currently.

Yeah, like, maybe 100%, 125, yeah, like this.

So, let me refresh the page.

So, yeah, so it recognised this is a galaxy, Z fold.

Android device, and, well, there is a combination with the IP intelligence.

So we kind of pretended to be a different device than we are.

But anyway...

But the IP is the same, so we're seeing the same results for that at the moment, yeah.

I think we can actually override IP with something else.

Like, we can pretend to be somewhere else, like, supplied as a parameter.

So here we are actually in...

Oh, that's really cool.

So you can see, like, low confidence location there, which is, really, we're saying, we don't know enough about this IP address to really give you something of useful, that's useful.

Yeah, so this, I think, cover is the main features that we wanted to show you, maybe we can add.

I'd quite like to add price band into here, if we can.

Can we do that?

Sure.

Show people how easy it is to add another property.

Yeah, so that's a prize band here.

And what was it?

The, connection type, I think, we wanted to...

Yeah, connection type.

We'll add that to the, IP intelligence properties, yeah?

Right, so let me actually find the.. The list of IP intelligence.

Oh, sorry.

I made it in the wrong example, so...

Sorry.

So, yeah, we wanted to add, um.. Connection type.

Yeah.

So that there is a mixed, right?

So connection type.

Connection type, and then...

One too many curly brackets.

Right, and then.

Price bending, yeah.

To what you're seeing here is that again, because we haven't got the strongly typed accessors for the results, so we're basically putting in the keys, which is the same as the values in the property dictionary.

Again, if that's something you'd like to see.

Please let us know.

So we've now got a price banned.

Pretty expensive device, I guess.

Yeah, it's US dollars and it's the release price. The device, not the current device.

So that would have been the upper end, usually release price in US dollars globally.

Right.

So yeah, this is a broadband connection we're at right now.

And so this IP address that we supply, actually, is a broadband.

If I remove this parameter.

I think it's still gonna say broadband.

Yeah, because it's a broadband connection, just in this case, more likely to be in the United Kingdom.

But we don't have enough information about the diversity to populate those values.

Right.

okay.

Yeah, let's have a look at the startup then.

So, we talked earlier about how quickly we started up because of low memory, and we were explaining that a lot of the data remains on the, within the file on the disk, but some people, particularly if you're running a very high volume, business might be prepared to accept a couple more seconds that start up for even faster device detection and IP performance.

When execution starts, in particularly in a web environment, or, if you're, In analytics, and you're actually processing data for analytics, you might want to load everything into memory instead.

Right, so this is actually by default.

This example was used in memory, the console example.

So if I run it, you can notice a little lag between running the example and giving the results output, but if I switch it to low memory.

I think there is no leg.

Yeah.

So that's taking the data file, IP intelligence is larger than device detection, but in both cases, it works in the same way, so loading all the data into memory, versus just loading the initial headers into memory, which is what low memory is doing, or you've got balanced as another method.

Can we show that?

Yeah.

So this is loading a little bit more into memory at the beginning.

Almost no difference to low memory, really, is it?

Yeah, there was some delay, but for noticeable, I think, several milliseconds on this machine, but, like, if we have it, like, on a different server, for example, that might be less powerful, or, I mean, commodating hardware that might not be as fast, so...

Yeah, yeah, exactly, so it's gonna depend on your environment and what parameters matter to you.

You can run this in well under 100 megabytes of memory for both IP intelligence and device detection, or you can throw memory at it and have it use all that memory and benefit from faster, per, request performance, basically.

The important thing is that for both device detection and IP intelligence, it's all running in process in your application, on premise.

There's no network calls, and you can do it both together.

So that is the benefits of the engineering approach that we provide and bring to this environment.

So sticking with on premise.

We're getting towards the end of this session.

How do people update the data file?

Because, as we've seen?

The data's changing all the time, and they want to keep it up to date.

Right, so we are looking right at this configuration option, which is with auto update.

So if we switch it to true, then it will try to do, like, fetch the update, but to actually do this, we have to supply it with the various parameters, like how often you want to do it, but most importantly, where to take the data file from, for the IP intelligence.

We usually provide the...

Yeah, the...

Let me actually look it up.

So.

So there is a way to update the data file using the license key, but this would be more, this is supported currently by device detection, distributor service, but also there is a way to provide data update URL.

This is a custom URL where the data file would be hosted.

So, we actually have a pretty comprehensive recommendation page on, doing the, automatic data file updates, and at least various scenarios for how to do data file updates.

So there are, there is several ways to do it.

So, for example, you can use the engine itself, that, it will, it has a data, update service built in, and it will fetch the data file regularly.

It will check the data file for updates regularly at regular intervals and fetch it if it is updated.

You can also use the file system watcher feature.

The, um...

The feature, it's inscribed in this document, the file system, washer is the, um.. Is a feature that looks at the file in the file system, and if it gets replaced, then it will reread the new file and refresh the data in memory.

And also, there is a combination of those methods, which is a, instead of doing a, for example, you have a cluster of machines, and instead of every machine in that cluster, doing a HTB request to our distributor service, trying to fetch the new data file, you can instead have just one machine, download the data file, and then distribute that data file across all other machines through the, either network file system, or through, whatever other method you have, like, for putting the data file on other machines, and then the file system washer would pick up the change for every running instance.

So, it's quite flexible, like all of those options are supported in go, as well as in any other language that we have, in high level languages.

I mean, in, it's a sharp Java, go python, JavaScript.

I mean, no chess.

So these options are supported in go as well, so...

Very cool.

So you can basically get your new data file using a license key from 51Degrees, but if you've got a lot of machines, you probably don't want to do that.

You can then decide to distribute it yourself within your data centre within your environment and then you can use the file system or you can use an HTTP private endpoint if you want to.

And then you can do things like, say, always check on start or check every 120 seconds or randomise as well.

I think you've got there as well, so that you can basically not have all your machines updated exactly the same time, if they were to see a new file through, say, the file system watcher, for example.

Right.

Cool.

So, one of the things we've looked at there is the combination of IPI and DD coming together.

We're reporting the information honestly, so you can see kind of what we know.

So if it's a VPN, we don't necessarily know the country that the user of the VPNs in, but we can give you an idea of where we've seen the service area in practice for that IP address.

You saw that with the US example, and then we can give you some indicators around the kind of the reputation effectively of that IP address through those diversity figures, and things like location confidence, et cetera.

So you're not dealing with sort of black and whites, it's definitely VPN or it's definitely not a VPN or it's only in this country, when it might be in multiple countries.

You can actually get that more granular information about what's really going on.

And then what you can do is, you can then bring those that information together to form your own service.

So you might take crawler, for example, from device detection.

You might take the age of the browser from device detection.

In fact, we've got a few minutes before we need to wrap up.

Why don't we add browser age to that example?

Then we can try an older device.

Eugene can show you that.

So you can get this information, human probability.

You can bring that together, and then you could use that to form your own view as to what a suspicious activity might look like.

And clearly, that's going to be different, whether you're involved in, say, geo fencing for content, if you're involved in e commerce, or banking, et cetera, or advertising fraud, you're going to have different models that you're going to want to use for fraud.

We provide you those raw, refined ingredients, so that you can then use them to turn them into the service that you want to provide.

It's browser age.

Yeah, I just wanted to check...

Yeah, browser.

This continued age.

Really is.

So it's browser release age.

Browser release age.

Okay.

Yeah.

So just to explain it a little bit more about them, we record the months and years that the browser was first previewed, so it became, when it developed a preview, when it was actually released, so it became the main version of the browser or the operating system, and then when it was discontinued as well.

So clearly, we can see here, that was simple, wasn't it?

You can see the browser ages one month if we were to change the user agent.

We could do that.

We could do that in, we could go to console, but easier to go to devices. .

And then we can edit.

So if we edit one of those.

we are actually galaxy, something.

I take a Galaxy S5, for example, let's enable that.

That's quite an old device.

A Galaxy S5, yeah.

And I think the browser version will still stay the same, so it...

Let's see.

We all gonna learn something.

That's five at the bottom there.

Right, so we're gonna need to refresh.

No, I think, I think, the, let me close this thing.

So it's still, so the browser version still stays the same.

No, we're gonna have to change the user agent, let's do that.

But maybe, let me check if maybe I have...

If you scroll down, Does it go down to the bottom of this section here?

You can cut and paste the user agent under evidence.

oh, we don't have it on this one.

Oh, no, we do.

Yeah, so if you take the user agent.

Right?

If we can do that.

Not, not, not easy because we are, like, in this simulation mode.

Let me check if we can do it like this.

Yeah, okay.

Oh, yeah.

So, if we take that, well, what we'll do is, we'll change the version of crime, say, 142.

Right, and but we have to kind of supply the...

Okay.

Okay, just right, go back to the, list of devices, I said, scroll down from dimensions, go to edit, and, we can then do add custom device.

And.

And we can just change the user agent value to 140.

Yeah, that's fine.

Fine.

Okay, cool yeah.

And now let's use custom.

And if we click refresh.

21.

What's your age 21. 21 months?

Yeah, okay.

Cool.

So, this is the first time in this series of webinars where I've taught Eugene something.

And so there you go, that was a first.

So you can see there you've got browser raging months.

See, what you might be saying is okay if it's older than 2 or 3 months, very unlikely to be a real piece of consumer software because most people update their browsers automatically.

It's pretty hard to stay on the old version these days.

At least Chrome would stimulate you to update, it would show a little...

Yeah, exactly, yeah.

So to stay on an old version is hard.

So that might be an indicator.

So what you can do is take these values, human probability, location confidence, those diversity values, the crawler information, the age of the browser, et cetera.

And you can bring them together to form the service that you want to have around, say, fraud, for example.

You could bring other data in as well. That you might have.

You could maybe take some procession identifier, when you come to look at the diversity values, for example, you could look at where people log in, what's the sort of diversity that we see from different users who actually log in, and then that could help you understand for those anonymous users, whether they're likely to have a similar sort of pattern to registered users.

So we're giving you that data, so you've got something to work with, rather than always providing you Boolean values, which could be very, very misleading, particularly around country, for example.

So thank you very much, Eugene.

This concludes the series of planned webinars that we've got on focussing on developers, we really need your feedback.

So please contact us, whether come to the website, via the contact us page, or come to GitHub.com and raise your issues there.

Whatever works for you.

Let us know what you want, if you want new features, if you'd like us to do more of these. Webinars or how to sessions or expand some of the examples, we're very happy to do that.

We've always been customer led.

That's why we've focussed on delivering high performance, because that's what our customers tell us that they want, and they want to consume these services in the simplest way possible.

So that you, as a developer, can get on with adding business value, not worrying about tinkering and dealing with CSV files, or separate servers, or whatever else it might be.

You can just go into GitHub here. Go, you can get running with that module.

If you're using other languages, we've got packages in those package managers as well.

We can integrate them together.

So thank you very much for your time.

Thanks for listening.

Thank you, Eugene, for being with me for this series of webinars.

Thank you very much.