So we have 8, 7, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6,
We get a chance to talk about this urgent topic of small data.
I believe that we are all, or that have been at some point, been hoarding data in our lives.
At some point, when I first started to work with data a little bit more serious, about 10, 15 years ago,
that time I was a product manager for a big media site.
We were a bit naive.
We were trying together as much data as possible about our readers,
because we wanted to improve the reading experience.
We wanted to improve the reading time and business.
I think we didn't do too much harm at that time because the systems were also very immature.
But looking back, I can wonder now, why did no one ask the question,
like, can you find these insights in other ways, other options?
And it's getting worse, it's getting worse.
So if we work with, today, with health data, for instance,
also people I know who are really, really engaged in that,
who are hoarding data to make better medicines, to make more precise medicines,
which is a really good cause.
I have several people in my nearby who suffers from severe diseases,
and could really use some good, more precise medicines,
but no one really asks that question today either.
So that's what we're going to talk about today.
We're working with the project Ernest Tapir,
which is one of the purposes is to find cyber threats in the data,
in this, in this queer data, and in cyber crime,
the hoarding of data is really getting troublesome.
So my name is Ulika Vincent, and I've been working with this project,
the Ernest Tapir for about two years, and I recently picked up coding again,
a couple of years ago, which was a very good idea, my life got better.
And I'm working together with Michael Kulberg,
who is one of the founders of the project, and also data architect,
and a lot of other things, too.
So first I'm going to just give you a short overview of what our project is about,
and then Michael will get into a little bit more detail.
So, first, before introducing the Ernest Tapir project,
I want to introduce our way of working,
and the big data is to come a very common way,
it's the salvation of all knowledge in the world.
You gather as much data as possible,
you try to comply with laws by doing checkboxes,
and you try to protect the sensitive data with all kinds of chills,
and try to make customers and others trust you.
But we are trying to do, or what we are doing, actually,
not just trying, is that we work with very sensitive data,
but we want to collect minimum to get the insights needed.
Oh, they come, oh, sorry, can't walk around.
Sorry.
And we try every day to find ways to throw away data,
as soon as possible.
We want to distribute the storage of the data,
and instead of just filling in checkboxes,
we want to be compliance by the sign,
and we do protection by sort of differential privacy.
So, what is the Ernest Tapir?
The Ernest Tapir is a privacy first,
open source platform with localizations for analytics
on DNS query data.
And it runs on tapir runs next to the recursive resolver,
for those of you who might not know the queries
that are sent when you ask you or your application
do a look up on the internet,
passes a recursive resolver.
And we upload events and aggregates to a cloud analytics platform.
And publishes observations back to the edge,
that can take some action of it.
Just to give a very quick view on how the data looks like,
if you're not doing this every day.
This is what happens when I load BrusselsTime.org.
This is all the DNS queries sent.
So, here you can find a lot of interesting things, both threads,
such as botnet, etc.
but also leaks of identifiable information about you.
But we want to look at this data to observe it
and to find strange things and bad actors.
And it's toxic.
Some design principles we are using aggregation,
where we separate data sets really.
And we try to make or we're doing individual tracking
impossible by design.
And you can't after our aggregation,
we can't do reverse engineering to find it.
So, we also work with minimization.
Other solutions often do minimization after extracting
the ETL process.
But we do transformational minimization at the source.
But the main idea is that when we do aggregation,
instead of looking at individual traces,
then we won't be able to have any data that can be used.
I tried to teach my children this.
Like, data you share will probably be leaked every day.
And we as developers or analysts or product people
should be aware of this.
We also kind of working with differential privacy,
which is that the results from our observations
won't differ in a significant way.
If you're individual browsing behavior is in the data
or not to simplify it.
And it has the reliability.
So you can always, always state that it's not possible
to find you in the data.
Another thing we're doing is that we want to publish
these observations to the public and partners third parties.
By doing that from the start,
design the system to share the data,
then we will make better priorities every day
because otherwise the ISPs who run the NSTA peer on their resolvers
would entrust us.
They would never share the data.
When they know we're going to publish it.
So it has to work in our architecture.
So to summarize,
stop the pathological hoarding we're saying.
Well, over to Michael.
Thank you.
Okay.
So I need to get into the box.
I don't like boxes, but I'll stick to this one.
So I'm just going to go into the technical stuff for a little bit.
Because everyone keeps asking me about the technical bit.
And we've created this analysis platform.
And this is how the current sausages are made.
And some useless details are with land data.
And we use bark and nuts and stuff to analyze it.
And we have microservices.
And Jupiter hub is the interface to meet analysts.
So this was the quick review of the technical part of analysis.
When it comes to the segmentation part that we've mentioned,
this is an overview.
Basically, you have internal stuff that ISPs don't want us to see.
And that was with throw away.
And then we have the ones that we sort of already know about.
Those we gather up and aggregate and throw away stuff.
And basically say, oh, I really can't put up with Google this week.
So everything under Google goes into a bucket.
And I just know I'm in a Google query store.
Then we have unique events where we're interested in unique events.
Because there's an in cybersecurity.
Typically, 90% of all new domains are malicious in some way.
So having those domains available is a very good way of predicting what's going to go bad in a short term.
So the first time we see any of these domains, we send them.
But we disconnect them from any other queries or any user information, etc.
So we just basically get a domain that says, oh, this one's new.
Or at least that server thought it was new.
And then we need to figure out if it's actually new.
And then we have the things that are in between.
Now, when you guys are going shopping or you're walking down the street and you're looking at all the places you pass,
you create a pattern of where you are.
And that pattern is in itself an identifier.
So as you saw the queries that came from this newspaper,
so one of the newspapers I know about, they have like 380 queries for their front page, basically.
And there's a number of different ad tokens that will identify you in different ways.
And when your computer connects to a network, it will typically go check if if you're running Windows,
it's going to ask, are there in updates available?
And then you have all your software that also wants to know about updates, all these things create patterns.
And those patterns are both interesting, but also identifying and, well, toxic.
So those end up in the bucket over at the end, where we currently we're throwing them away,
because we built all the other stuff.
But we do need a local analysis platform that aggregates this data and removes the patterns and identifying information.
So this is the segmentation part.
And for this data, well, this is where it ends up being, and it's probably not readable.
But here we have our histograms and it's basically Google and counts.
Well, these are sketches, and this is a null sketch.
The sketches will identify you if you have two few of them.
So we have a hard cut off for these, where you won't really have a sketch until the number of users passes specific number.
And our current number is 20.
So at the point where you're one of 21 or so users, there's going to be a sketch here to be able to handle the,
well, I lost the word, but anyway, user count is one of those with cardinality problems, right?
So to handle cardinality of users, we use, each of those sketches are hyperlog log sketches to maintain an approximation of the users across time.
When it comes to events, these are the events.
Like, well, this one is really interesting.
So as a WCDN app will come with higher and lower cap letters.
That's a strategy for adding more bits into DNS.
That's why it's upper load case letters.
They just show up once from each server.
And we aggregate them centrally to see if they're actually completely new or if they just show up late somewhere.
And the methods we use for doing this, well, it's a patchy spark.
I picked this particular one because an interesting fact that we learned the hard way is that a patchy spark is running on JVM,
but actually it doesn't know about 64 bit unsounding numbers.
So you actually have to do some really weird stuff too.
If you're using a bit string on your analysis or your data collection platform,
and you're sending that up and you're using a 64 bit string to indicate things,
there's only going to be 63 of them available in Scala.
So basically we just replace them with letters and use that.
So when it comes to sharing this data,
data commons is a fabulous idea.
I love it. I really want to share this data.
Sharing data is a bit tricky.
I don't know if you guys remember this,
but Strava made interesting boxes on the maps in Afghanistan,
and in the architects.
So that was unfortunate.
And this is because they're sharing data,
and they weren't really thinking that this would in any way be problematic.
Netflix also had this prize where he was supposed to do things with their recommendation system.
And it turns out that if you have very specific tastes in which movies you watch,
yes, it is possible to find you in aggregated data.
And this is one of the concerns we have for our data,
because I mean the chances that there is someone asking some really odd questions is pretty high.
I know for a fact that I would probably stand out,
but that makes it hard to share the data.
So when it comes to, when we've been working on this to create data that we believe we can share,
we've had a very basic design strategy.
And as we design it as well as we can,
and we try to break it, like really break it,
and then we redesign it, and then we go back to trying to break it.
And at some point we'll probably want someone else to try to break it as well,
before we hand over all the data.
There's also a tricky part about this data since it's related to security research, et cetera.
Chances are that any publication of the data needs to be somewhat delayed,
so that all the security people get a chance to sort of make sure that they fixed all the stuff that potentially could fall out from this data.
So, but having this as your goal,
actually put some pressure on you to think a number of times about your data before you release it to anyone.
And this, I don't think it's unique for DNS data.
I think this is something that can be applied to a number of different types of data,
coming from networks and computers.
I can think of a number of things there, but it would be interesting to know about other areas where this could be applied.
So, if you have ideas where you can use these strategies in some really wild other field,
I would definitely be interested in nobody.
So, I believe that is the main gist of what we're doing.
So, I think we'll leave a lot of time for questions, I hope.
Yeah, I can, I can just mention also that we would love you to try to break our model.
So, if you like to contribute in some way or just follow our work on even if you're not in the DNS world,
it could be interesting to exchange experiences.
Please reach out to us by email or most of them are linked in,
or check out the site and rep of because it's,
I didn't put it here, but we have the rep on GitHub and just reach out for any,
and a, a fetch to try to break our model.
Yeah, questions.
Then maybe I can have a question to you.
Do you enter the project that you can read on the view and that there's view there,
or do you just log in and research what these are looking for?
So, what we do?
Yeah, you put the question.
The question was, if we are filtering filtering the,
the means from the user and the NSTP doesn't make filtering decision.
The NSTP which is a bit different from other solutions that makes filtering decisions.
We publish observations to the resolver operator where we, for instance,
can, an observation can be that it's a new domain, low rank,
a sudden ramp up and things like that.
And then there is a module in the NSTP.
We call the policy processor, which can take these observations,
and decide in the policy together with other sources,
such as list, etc., and set the response on that domain.
Okay, now I've got three observations from TAPI.
Plus, this domain has these characteristics.
Okay, let's filter it.
So, TAPI just observe.
We want to, and not decide if it's a bad or a good domain.
Yeah.
So, and the question I would like you to bring home is,
like, when did I throw away data later?
Thank you.