I'm gonna be out of this.
Right.
Here's Orica.
We're gonna be talking about open source, DNS traffic analytics.
All right.
We're gonna be here on the ground.
We're gonna be there.
We'll be too loud.
We'll be right.
We're just out of the middle of the race.
Oh wow.
Sorry, I had to...
Um, hi.
The world outside for STEM is full of creeps.
You know.
Uh, and many of them on the...
Oh, well, come on.
Ah.
Okay, let's...
It's good to get to use this one.
Yeah.
We're about there.
Um...
What do you want?
Yeah.
Hi.
Okay.
So, do you hear me?
Yes.
Good.
So, the world outside for STEM is full of creeps.
And many of them on the internet,
and some of them can be observing the DNS.
And that's not really true.
Okay.
My view of humanity is much brighter than that.
I believe if we were all that bad,
we would probably have been on a long time ago.
Still, there is...
There are a lot of creeps in the DNS.
Um...
And when we talk about creeps in the DNS topic,
project, we're not only talking about the usual suspects,
but net, et cetera.
We also talk about creeps like this.
That move identifyable information into DNS.
With the cook-a-law and other things,
more and more, both good guys or evil guys,
move this kind of information into DNS.
So, this is also creep activity.
This is from Swedish loading a Swedish newspapers site.
Um...
It looks a little bit like it could identify something.
So, that's also creeps.
My name is Elrika.
Vincent.
Like my belgo friends on sisters would...
My tab said,
and I've been working with the DNS topic project for about two years.
Um...
With analytics.
And I recently picked up coding again a couple of years ago.
And that was a good decision.
My life got better.
That's your understanding.
And in the topier project,
I work together with these guys.
And probably some of you would recognize some of these faces, at least.
And I'm here with Mikael Kulbal in the corner,
who's been working with the DNS a little bit longer than me.
And we will answer any questions together.
And also, this guy in the hat.
Oh, I think some of you know him already.
And if you haven't seen the other guys,
you probably will bump into them if you keep going to DNS events like this.
So, what's the next up here?
The next tab is an analytics platform for DNS queries.
And it's open source.
It's open data, we aim for open data.
And it's based on local decisions on the resolver.
It's run on the recursive resolver.
This is probably obvious for you, but still show it anyway.
So we call it topier edge and topier edge
since data up to topier core.
But we do it in a different way than others.
And I'm going to tell you what we do differently.
And why this matters.
Also, the topier platform,
it collects the events and aggregates from several edges.
So it's a collaborative platform.
Where several operators can use the same feed to get results.
But the main purpose of DNS copy is really to make DNS queries.
DNS query data transparent and visible for others.
And do it in such a way.
So there's no risk to threaten your routing behavior or your activity in DNS.
We need to work with addressing the challenge of DNS query data.
No one really wants to touch this if they could choose.
But we do, because we want to offer an alternative to other solutions.
And doing it such a way that all of you can be safe with your routing.
So to make a very simple and short overview,
the topier edge reads DNS top information.
Data and creates events and aggregates.
No DNS queries lives the result where the unique queries.
It's events and aggregates are.
Which are analyzed in the topier core.
And observations from topier core are sent back to.
And published back to the edges.
And also shared with the lay to public.
So this part we haven't built yet, the public part.
We're looking for funding for that one.
So how does the data look like?
I believe most of you know, I show you anyway.
This is what happens when you go to normal media sites.
It's for instance Brussels times.com.
It can look like this.
All these queries are sent.
It's pretty pretty nice, not.
So I was going to show one more thing here.
Also check for stem.org, of course.
It is a little too.
And it's not that bad.
First time only Google queries are sent.
And that's quite impressive.
I believe that Google has managed to, for almost every site in the western world,
getting a call.
That's quite impressive and pretty scary.
So in case you don't already have a tool like this,
and if you're curious about some website,
you could try this one in our repo.
It's a neat little tool.
So why do we want to even look at this data?
What can we see?
Well, the reason we look at it,
or we want to look at it is to find indications of bad or malicious activity.
And also find indications of the ugly ones,
but I call the ugly ones the ones who leak private data in the internet.
It's getting more and more common.
This one is the data is toxic, so it's difficult.
Here are some examples of the main.
Could be malicious domains, and it's from an old data.
So, well, looking at this data is a bad idea.
I think you agree on that, and I still get the question every time.
I meet someone who's really interesting in our project,
like, why are you doing this?
It's not good.
But we have to, because a lot of activity is moving there,
and it's kind of unseen.
The solutions that are installed in some places are not as keen on preserving the privacy,
as we are, I would say.
So common solutions, if I understand it right from my timing in this domain,
is that a lot of solutions for analytics on the queries work like this.
However, it's all where the query streams go up to cloud,
where a minimization is done, or save the minimization,
which is such a difficult word to say, so it should just remove it.
It doesn't work anyway.
So, I hope this is the last time you see that word.
And then the solution will make a decision, blocking decision,
and that's not always bad.
Sometimes you want to also say, it's not always that bad,
but the transparency and insight into what has been done is very,
can be very difficult.
The toxic data is not longer only here.
It's also in the cloud, and it becomes a target.
So, there's some bad things with the solution,
and that's why we want to do a different approach.
Where we do minimization and anonymization at the source,
at the resolver.
We don't create another target.
We publish events and aggregates only,
no query data, which don't make tapioid doesn't make any decisions
of about what's good or bad to means.
We just make observations of how different the means behave.
So, this is part of the difference,
it's different from other solutions,
it's that other are often driven by commercial interest.
Nothing bad with that, I've been a business person myself,
but it makes priorities tough sometimes.
You need the profit to keep going.
And also when you're funded only by governmental institutions,
we all know that the priorities can change
with the politics of the day.
We see that every day.
And then the data is saved in silos,
because that's where the business value is.
So, they don't want to share it.
And tapioid, we are not an nonprofit organization.
We will run for a long time,
financed by different kinds of organizations.
We want the balance.
We want to make them happy.
Not too happy, neither of them,
but enough happy to keep funding us.
And it's a collaboration.
We want to share the data, so it's a big difference.
So, the main thing is that data you don't have can't be lost.
As soon as you have it, you must assume that you will be hacked or leaked.
That I try to do that.
So, the main thing is that data you don't have can't be lost.
As soon as you have it, you must assume that you will be hacked or leaked.
That I try to learn my kids that too.
Your data, as soon as it will be leaked anyway.
So, we can do a lot of things without storing data.
We can observe the crowd, and that's what tapioid is about.
We don't want to observe individuals.
I want to mention one of the components,
that there are many several components,
and we want to go through the architecture today,
but I hope it's you're interested in knowing more details,
just with our task.
But because you can have presentations and demos of the details,
this is an overview.
But I want to mention this component,
policy processor, which is one that resolves at the edge.
It could possibly be run as a standalone component as well.
And it's the component that sets the policy.
So, there is a human in the loop,
who defines the policy, we will see that in a minute.
How it can look like, but also integrates other sources,
such as list.
And then process them and outputs an RPC,
that manages what the means are as soon.
And another component I want to mention in this overview,
is the local analytics and in, we're also looking for funding for that.
We haven't developed it yet.
Currently, we are discarding a lot of the means,
because they are just too sensitive to unique.
And with the local analyze,
we will be able to look at this unique domains,
categorize them, tag them,
and without needing to send anything unique up to core,
or publish anything unique.
And we can also use it to train a bird model
to be even quicker.
And I said on AI word,
the marketing will be happy.
So, but the same thing here,
if you're interested in how this work,
please reach out to us,
and you'll get more information.
So, but the point is,
identifiable browsing behavior, never ever list.
So, I'm going to show you,
very short demo,
it's not really a demo.
It's screenshots from a demo,
because the recording,
we had a bit too slow to show here.
But I will show you some screenshots.
This is the policy config,
in the NSTAPI.
This is actually part of the tapi celli,
where you can define certain policies.
And we're going to look at this policy,
which is a number of tapi tags,
number of tapi observations.
This result will accept
that tapi has published two observations.
But over that,
the response will be in NX domain.
I'm probably in real life,
the policy will look different
from a real operator,
but this is for demo.
So, we set a website,
an email website,
from the computer that runs this resolver.
And what happens,
we can see in the tool,
in the client,
we can see that papyr has published
an observation.
And this little flag,
six means that there is two observation.
It's a new domain and low rank.
Very intuitive.
It's, you can get an explanation of that.
So,
and here,
we can,
yeah, we go to another resolver
and dig the same domain.
And we get the response.
And then going back to first resolver,
we can see that
the observations have changed.
So, this means actually three observations.
The third one is that it's what we call
multi-new.
The domain has been seen for the first time
in multiple developers,
multiple edges.
And what happens,
on my first days,
where I look at the same domain,
I can no longer see it.
It's,
it's,
and the next domain,
we can see it will be here.
So,
that's,
what, that's the papyr loop,
really.
And make a policy definition
and then listening to observations
and possibly together with other sources,
we can make decisions,
what to response.
No data or an extermination.
So,
if you would like to,
to go home and try,
can you just do that?
We have the report open,
if you want to install and try,
tap here.
Currently,
you need to reach out to us.
Email is a good way.
LinkedIn is a good way.
You will find me,
my contact details are just reach out to us.
You need some keys,
and some a little bit of hand holding
to get it up and running.
And that's,
a report.
Another thing we're doing,
is to start to build a tap here community.
We do have a community chat,
so you're very much welcome to just join,
and listen in if you're interested.
In this,
or want to know more,
and then you can, of course,
leave the chat if it's too,
intimacy.
And if you happen to be in Stockholm,
we have a regular of the works,
for welcome,
and we might even adjust the date just for you.
If you show up,
and we're going to have,
some analytics labs too,
so if you're into analytics,
there will be chances to contribute online,
and experiment with the date.
Yeah,
that's about it.
Quick overview over this,
this important project.
Thank you.
Any questions or comments?
Yeah.
Where to start?
I didn't really adopt this,
you know,
top here,
an active report,
or does it just use data from in this tap,
and works for that?
It used data from the DNS tap.
So you currently run an on-bound,
and so it's not a resolar,
but you install it next to the resolar.
Well,
we are currently working in the media service provider.
Your voice is not being recorded right now,
right?
Yeah.
We are currently working with the mayor's service providers,
and it's within,
and it's all the edge within,
just for testing.
So we're not running the resolar itself.
Exactly.
Yes?
So what members of the community are looking for?
A primarily ask please,
or I will just be in some smaller,
like home,
home environments,
or...
Yeah.
So the question was,
what kind of community we're looking for,
and I will say,
both,
we have some small,
small operators,
but those who are small
needs to be aware of certain things,
you'll be able to accept certain things,
because the big ones are,
that's the data we're looking for.
But if you want to just test and try it out,
be chat with us,
and also we're looking for analysts,
who want to play around with the data
in one way or another.
That's...
And...
Yeah.
Your home user,
with a very small amount of devices connected,
the risk is really high,
that even though we are anonymized
and we tried to filter out,
we will be able to see you.
So we're looking to create
some sort of aggregation solution
between us and home users,
because we want to see all the queries,
but we also see that there's a high risk
issue that we have to solve,
and we haven't focused on that right now.
If you want to help,
please help us.
Yeah.
So basically,
we begin the modules of the better,
and...
what's the...
what's the treasure of my hand that uses,
okay, hundred plus.
Maybe me,
can you answer,
how many users would be,
okay,
why the treasure showed.
So we have a high cut-off
about 20 in terms of
when we're using
get to maintain
just half of the amount.
And that seems to work out,
but I'd say a hundred is,
okay,
but we're going to be one of a hundred,
right?
We're going to be able
to be identified as one of a hundred.
Yeah.
So the question was,
how many clients you need to be
to be drawn in the crowd?
Yeah.
And we have a treasure,
and we need to be around 20,
but that means
that you will be one of 20,
or in case of a hundred clients,
you will be one of a hundred.
So when we work with the large amounts,
the larger providers,
then it's strongly in the crowd.
But yeah.
We have a few testers,
actually,
but I don't want to kind of
homoperate this.
I just did it.
Yes?
Yeah.
So let's say,
items,
ones by the answer,
to be a lot.
It's not a way for me to tell
that my result for it's using
and stuffy.
Yes.
So,
aha.
Okay.
That was a good question.
Please don't wait for me,
as an individual,
to know if the DNS is running
tapir edge.
And yeah, what?
No.
Actually, we've got that question,
and the seminar,
we had in Sweden,
that can I work in my DNS
that I don't want to be loved by it?
And we said,
yes,
we would like to see you then
and see what you're doing.
But we won't look at you.
We will look at you.
Don't roll.
But that's an interesting thing.
We'll take it with us.
There are functions,
you know, doing a lot of operations.
So,
we are there.
You don't have a mechanism,
so we're dragging things to be not done.
Okay.
Good question.
Yeah?
Yes?
Right.
Do you have some public rest of the
you could do other things?
You have excluded,
because they are,
you know,
checking,
checking dialysis.
Yeah.
Which is what?
There is some analysis,
but looks like random something.
Yeah.
They are used for,
they could be used for tracking.
We don't know if they are,
but what tapidas will,
it will,
observe these domains.
And in this case,
when there are so unique,
there will be a category,
a tag on this.
So, this tag dot dot
domain dot,
example dot com,
could possibly be a privacy issue.
And we will make an observation,
publish an observation.
And then the resolver operator decides
what to do with the observation.
Okay.
So these domains
could be,
for privacy,
extraction of private data.
What should I do with them?
Should I just ignore?
Or should I do something or correlate
with some other sources and confirm
validate?
Okay.
This is,
but okay.
I will filter them.
But that's up to the operator.
I think that.
We all know what's going on there.
It's a chicken and egg problem for us.
We haven't got the data yet.
We know there's a lot of stuff hiding in there.
As soon as we're up and running,
we will not make a lot of noise
about how cooked this had moved.
What we can do to start with discussion
what we can do to prevent and highlight this.
But right now,
we haven't got the data,
but more than,
so please follow us
and help us with this stuff.
Yes.
I see one more question,
but I have to cut this off.
So please find Orica or...
Yes.
Thank you.