Okay, so I think we are good to start, please welcome Damien Closchard.
He will talk about posgurskwell anonymizing privacy, but the privacy.
This is a very actual topic, so yes, welcome, and thank you.
Thanks a lot, are you here with me?
It's all right, let's go.
So my name is Damien Closchard, and one of the co-founders of Dalibo, which is a French posgurskwell
company, basically.
And I also an active member of the French posgurskwell community, if you've done some posgurskwell
in France, you probably know me for that.
So what brings me here?
Why am I here before in front of you?
Like five years, seven years ago, actually.
Someone asked me to anonymize a database, and I say, well, easy, quick.
I'm going to do it for next week.
So I just got a bunch of PLPG scripts to do it.
I just named it posgurskwell anonymizer, because it was for the topic.
And somehow I'm still there, seven years later, still working on it.
The funny things is, I never actually anonymize the database, in fact, but I did a tool
to an anonymizer to do it.
So this is my story.
And I'm here to talk about the privacy and how you can protect that.
So I'm going to go a little bit on the definition of what privacy is before going to a
more concrete example, and yeah, the principles of data protection and how to do it in
with posgurskwell anonymizer, because that's the thing I did, but those principles could
be used with other tools, too, okay?
So the paradox of privacy, so yeah, basically, it's a strange concept, basically, privacy,
because compared to other concepts like your private property, private properties, quite
well defined, I think we all know that this computer is mine, but this is not mine, okay?
This is very clear, but privacy is not so clear, actually.
So yeah, we could do 45 minute essay about what is privacy and pretty sure we would all
write different things about what is private, what is intimate for you.
And actually, it's all, it's also, so it's different between people, it's different between
eras and also it's different between regions, okay?
Someone in Asia may think privacy means something else, all right?
So yeah, and basically, it's quite new, it's new in the history of humanity, it's a new
thing, because basically, 200 years ago, everybody slept in the same bedroom, all right?
So there was no intimacy in the sense that we talk about it now, you know, in the villages
of everybody knew everything about everyone.
If you had secret, maybe the only way to talk about it was to go to the local priest.
And even that, do you remember that thing?
So that was, yeah, 40, 50 years ago, trying to explain that to a teenager now, you know?
We had three hours, had this book, and in this book, there were the names and the phone
numbers of everyone in the area, okay?
Asked two pieces of that.
I mean, I could give you a piece of paper now in this room, ask you for your phone numbers
in your names.
We would give you, would you give me your names and your phone numbers?
Yeah, maybe someone, but probably not at all.
So you see, it's relatively new, it's evolving, and basically, this is just the beginning.
As we, as our life is getting more and more and more digitized, in reverse, we want more
and more privacy.
It's never going to stop, we will, our, I would say that the grand children of our grand
children will look at us just like we look at those poor guys.
They will find privacy like a basic human right, actually.
Okay, so, but no, no, no, everyone agrees with me about that, and then some guys, some people,
like this one, Eric Schmidt, that would say something like, if you have something that you
don't want anyone to know, maybe you shouldn't be doing it in the first.
Right?
Yes, in the comments, and now, well, this guy is a CEO of Google, was a CEO, is not a CEO at
the time, but as this time, but he was, and this is the stupidest argument about privacy
that you can either bring in a discussion, right?
We all have the right to privacy, it's not, yeah, you can publish anything you want, but
you also have the right to hide things.
All right?
So, yeah, of course, Big Tech companies, they want, they don't want this definition
of privacy, because basically, the business model is collecting and selling new data.
So, of course, they want to redefine what the meaning of privacy is, right?
And so, there's a market for personal data that is blooming currently, so at this point
right now, in 25, so that's a broker industry is worth 2,000 billion, yeah, and this
is just ungary, okay?
And you've got this for companies, do you know any of these companies, anyone here knows
of what?
Oh, yes.
Does some of you work for them?
I can ask, just asking, just asking, well, this guy doesn't know about you, you're probably
in one or the five of them, they sell you data on every day basis, and they make a lot
a lot of money, and you probably never give your consent for that, all right?
And so, thing is, that's just the top five, they're about 200 of them, okay?
And the five, the top five are bigger than redat on their own.
So, yeah, in theory, legally, you can send a letter to each one of them and ask for them
to remove your data, and probably, probably, they will do it.
But then next month, you will have to do it again, and you will have to do it for all the 200
companies that have brokers that take this, then you will have to share, to look for new ones
that will appear every day.
So, of course, capitalism has a response for that, so you can hire companies that will
write these letters for you, and it will only cost you 10-door apartments.
So, this is a great example of our capitalism, we'll sell you the disease, and then sell
you the coronavirus.
All right, so the black market is rising, because these guys, the needs of data, it's
hard to get, and it's cheaper on the black market, basically.
All right, of course, I have no way to prove that taking your data on the black market,
I can sue me for saying that, but I'll take the risk.
So, yeah, this market is absolutely not regulated, and GDPR does not change anything about that.
And so, logically, the number of data breach is just exploding.
Last year, the number of notification people received went up for three hundred percent.
All right, you know those notifications, where you receive an email, when they say,
oh, we value your data privacy, and we may have lost some of our data, but yeah, keep stay with us.
All right, we have this email devices.
So, this is a battle, basically, people want more privacy and take companies, want more data.
All right, and so, if you are a possessive data on any kind of DBA, actually,
you're writing the middle of this right now.
So, your target for the data leaks, and you have the responsibility of the data you hold.
All right, so we're going to war.
Just, we're going to try to apply, you have to have a matter, if you want to win this war.
So, we're going to check six basic principles for this battle.
So, first one is privacy by design, which basically means
your masking policy should not be written by, should be written by the application developers.
It's something you should do at the start of the project.
You don't do that at the end of the project, once the database is in production, it's too late.
You need to think about it right now, right?
When you add a colon, when you add a new feature, just ask yourself, okay, what impact does it have
on the privacy of our users?
Right.
Then you need role separation.
As a DBA, you're going to give access to a lot of people to the data.
So, don't just give them just one role, just separate the role and give different rules to different roles.
I take so far, it's a quick introduction.
I'm going to say AASF for now, but
this is a basic principle in security.
It's not just for database.
It's just the idea that you should reduce the places where your data is, okay?
Data minimization is basically the opposite of big data.
Big data is completely dead.
This data is officially illegal.
You should not collect data if you don't have a real usage for it, right?
Which means when I don't know, maybe in your form, in your forms,
you collect the birth date of your users.
What do you use that for?
Is it useful to have the birth date of every users you have?
Probably not.
Maybe, I don't.
But you have to think about it.
And you can't have this philosophy or let's collect everything and maybe let
turn two years or four years, we will find something useful to do with this.
It's not possible.
Risk evaluation, like I said, the concept itself of privacy is always evolving.
The technologies are evolving.
You have new kinds of attacks, new ways to to to to to
who only need to be constantly
evaluate your policy.
And last one is privacy by default, which is potentially simple.
If you don't know if the colon is contained,
the private data, you should treat it like if it contains private data, okay?
If you don't know, you know.
Okay, so again six principle,
I'm going to show you how you can implement them
with post-resculine animator.
But again, you could do that with any of the tools.
So what is this?
This is an open source post-res extension.
And it's been production for the last five years,
I guess it's written in Rust and PGSQL.
I did a talk yesterday about Rust and Rust extension
in Post-res.
It should be on the first-day website
in a few hours, I guess.
You can install it through RPM, DBR, Dr. Ansible,
whatever.
It's also available on most cloud platforms,
such as Google Cloud as your crunching area, et cetera.
And we do have a lot of experimental tutorials.
So digital, digital, digital for the known French people.
It's the Ministry of Finance.
And I, and I, and I, and I, and I,
is the National Research French Research Agency.
Well, they've found their gave us money
to develop this technology.
So what is it?
It's a masking engine.
So you have different ways to mask your data.
You can do static masking dynamic, dumps, et cetera.
I'm just going to talk about the free first one.
Because that's enough for you to understand,
but you, there's a lot of way to mask that, actually.
And it's also masking toolbox.
So it's, at the same time, is what you want to mask
and how you want to mask the data.
And there's a lot of different ways to mask the data,
depending on what you want to do.
You've got pseudonymization.
You have noise.
You have fake data.
You have partial destruction, generalization.
You can also manipulate images.
So again, I'm not going to go into each one of them,
but you get the ID.
OK, let's go.
So I have installed the extension.
It's a binary extension.
I need to load it to my data.
So the best way to do it would be to use session
prelude library.
All right, practice fairly simple.
And then connect to the data as a gain
and just create the extension.
And that's it.
Let's go.
And let's implement privacy by design.
So again, privacy by design is a declarative approach
of anonymization.
We are going to write our masking rules inside the database
model.
All right?
And but how can we do that?
How can we add metadata inside the tables
and inside the database model?
Well, there is this thing called security label.
That probably most of you don't know.
It's a feature of post-vascular access.
It's SQL.
And you can, with this, you can attach label metadata
on objects in your database.
All right.
So let's get to an example.
So I've got the table.
People and they have an ID, first name, last name, and phone number.
All right.
Let's go.
So what I want to do is, in my database model,
this line that is just going to say how this
current, so in this case, the colon is last name.
And this is how I'm going to replace it to the mask user.
So I'm going to replace it.
I'm going to mask it with the function dummy last name,
and function dummy last name, which is a generic last name,
any kind of last name.
But so this is just like putting a constraint on your colon.
You would say that last name for example,
is not new, or maybe there's a, I don't know,
some kind of check on this.
And it's quite the same thing, actually.
You're just saying, oh, this is colon.
This is how I'm going to apply transform this colon when I need to.
So you can also destroy the data.
In here, I'm replacing the data with a function,
but I can also just replace it with the value,
with a static value.
And so if you get just one thing to keep from this talk,
is that destruction is the best and an amazement.
Yeah, you can install you something you have destroyed.
So again, with data minimization, we'll talk about it later.
But yeah, if you want to be sure that some data will not leak,
just replace it with a static value.
But a third example is, for example,
we want the phone to be partially destroyed.
So we're going to just destroy the digits in the middle of the phone number.
And if we, then I'm going to apply those frameworks on the table people.
And here I am.
So the table has been statically masked.
It's now, if it's done forever.
And as you see, the idea has disappeared this new.
The first name is the same.
I didn't mask it.
The last name is a fake last name, but it's as schema model.
OK, let's go with world separation.
Again, you're going to have some rules that will be masked.
So the masking rules will be applied automatically
for these people.
And by definition, so a mask rule will be a redoney.
But while the mask rule will be a redoney,
the other rule will be able to read the data and write the data.
So let's go.
We're going to create a new rule, which is sky net.
And is around connect.
We're going to activate transparent dynamic masking for him.
And we're going to say, again, with the security label,
that this rule is masked.
And we're going to go, actually, I'm going to give it
the residual data, redone data, a privilege
to because it's easier because I could do things.
Early, the more subtle, but let's go with this.
So now, when sky net will connect,
it will connect to the people's table.
It will try to read the people's table, and it will be masked.
And as you see, the last name has changed, because every time
it will query the data, the function will be called again.
So we will see, for the fake data generator,
we will see different fake data every time.
But for the phone, it will be always the same result.
But now, if I connect back as a normal user, as postgres,
sorry.
The data is actually changed for the people,
because it's a viewer.
It's called masked.
So we can re-changer that in the row,
which is when you read it, it just changes on the fly when you read it.
Yes, sorry.
So the question is, is the data change on the view
or change on the fly?
It's changed on the fly, actually.
Basically, what's happened is that the select clause
will be intercepted.
And I'm the extension will rewrite the query
to display this.
But actually, the masked rule doesn't even know
is masked.
All right?
What if you have it in the index?
Will the mask be available?
No, if you...
Do you repeat the question?
Sorry.
What about the index?
Yes, the index is not masked.
So it's still useful in that case.
So basically, this is it.
You have masking rules written by the post-res administrator.
Some guy, a regular user, can read and write the data.
And the mask can only read the mask data.
All right, let's go.
We're going to talk about attack surface reduction.
OK, this one, I think it's going to be a clear example
for you all.
Let's say we have a prediction database
with an user DBA, and you've got the developer
and data scientists and they want the data.
The developer wants to run some tests with realistic data.
And the data scientists need to, I don't know,
run a weekly reporting BigQuery about the start,
about the company and everything.
All right.
So what happens to worst case scenario is this?
You're going to send the real data to both those M
that are going to have a copy of the data on the desktop.
Maybe one of them has a Windows laptop, all right?
Just stay.
And so yeah, you're still fast.
The attack surface is everyone.
So if I want to steal your data, I'm not going to target this,
because this is very hard, because you're a very good DBA,
and you have protected this area very good.
And I'm going to attack this guy, or maybe this guy.
Maybe I'm just going to store this laptop on the bus.
Or maybe I'm just going to put some kind of trojan
off in this guy, PC, all right?
So we don't want that.
This is the worst scenario.
So what most people would do is this,
is extract the data, transform it, and then push it
to this, to this two environments.
This is nice.
This is good, I'm not judging this.
It's correct.
But as you see, the attack surface is not
reduced that much.
So those two guys are not an attack vector now,
but you've got a new guy in the loop in the pipeline.
And this guy is also a vector of attack, right?
So in some ways, you've reduced the surface,
but the world pipeline is a bit more complicated.
And of course, in the edge of AI.
So you have this now.
A lot of new startups saying, oh, just send us your data,
and we have a new AI thing that will analyze this.
So this is the worst ID in the entire story
of the type privacy first, because there's someone
in this cloud, which will be basically
able to see the logs of this AI things.
And you don't even know how the AI has been trained.
You don't even know what they do about it.
So yeah, this is a nightmare.
So what we want to do is this.
We reduce the surface of attack to this,
but which is, as I said earlier, very secure,
because you're very good DBA.
And we're going to either push the data with an analyzer
dump, which we'll pitch it up, right, to this environment.
Or we're just going to give access to this guy.
So it doesn't have a copy anymore.
It's just allowed to connect to the prediction.
But it is masked.
So you won't see a personal data.
All right.
So let's do it.
We can reduce this PG dump thing, the anonymous dump thing.
Well, again, we're going to create a new user,
a new hole, which will be used just for the dumps.
And we will activate transparent dynamic masking.
We're going to say this masked, and let's go.
Now I'm just going to use PG dump with this user.
And I'm going to get a masked dump.
And now with this anonymous dump,
I can share it everywhere on my network.
I can send it by email to someone.
It's completely out of the surface attack,
because there's no personal data in the dump.
Of course, if you use PG dump with a regular user,
you will get a dump with a regular data.
So we're going to use this dump to refresh environment.
And this is, again, this is a regular PG dump.
It's not a wrapper, and you can use any kind of option you
use with a classic PG dump.
And notably, the custom function format works.
OK.
So let's go again, next principle is data minimization.
So in most case, when you analyze something for someone,
they don't really need all of the data.
A sample of the data is sufficient for tests,
for analytics, for demo, for training data.
Most of the time, just one small part of the entire data
set is enough.
So this is called sampling.
Maybe did you know that Postgres already
are this?
And this close calls that are simple as any one ever
used it here?
Oh, two guys.
Great.
So yeah, Postgres are this already,
since I don't know, years and years.
And you're able to say, I just want this fraction
of the result.
So let's say we have a big HTTP log table with the date
with the IP address that you are all everything.
So we're going to put a security label on the IP address
thing, so we're just going to destroy the IP address.
We don't need it for the stats, for example.
And you were going to just send 10% of the table
to the mask users.
So we'll see one or two percent of the table.
The mask users will see only 10% of the table.
All right.
And we can also sample with RLS policies.
Another great feature of Postgres.
Again, we used our role-level security policies here.
OK, yeah, good.
So basically, role-level security policies
is like filters, you're going to make
at the role-level of each table.
And so with this one, again, we're going to apply those rules.
So this is, again, pure SQL, nothing fancy.
So we're going to create a policy on the logs.
And we're going to say that we're going to apply this rule
only for the mask user.
Any users that has, if the user, the current user as a mask,
and we're going to only apply it for the values
that are six months old.
So the mask user will only see the latest data.
Only the data that has six months of the last six months.
All right?
OK.
I really like this example, actually.
OK, let's go with risk evaluations.
This one is hard.
It's not where we still have a lot of work to do in this area.
But we have two features for that.
One is called K and Animiti.
And the other is a detection function.
So let's go.
And talk about K and Animiti.
It's an industry standard, basically.
You will find it on other tools too, hopefully.
And it says that it's a factor that computes the risk
of re-identifying someone within your data set.
So maybe you applied your masking rules,
but just feel some guy that is on edge case
and you're still able to find one unique person
within your data set.
Right?
So it's just a function, actually,
that you can run on your table.
And it will try to guess how many single people you can find.
No, not how many single, but how difficult it
would be to identify someone.
So here's the factor is free, which is good,
but not good, not the best way.
The higher the value is the better.
All right?
If you want, it means that there's one guy
that is your unique guy unit in your data set.
And we also have a detection function.
So we're going to scan all your tables and all the columns.
And with U.S. ticks, we're going to try to guess
that maybe this customer first name colon
doesn't have a masking rule.
And maybe this one is a dialectite identifier.
So it's not perfect.
I think we have a lot of areas to improve this one.
But this one is like a checker and a void
to miss one colon.
And finally, privacy by default, like I said,
if you don't know, if a colon is all the personal data,
just mask it by default.
So again, we're going to take the HTTP log table.
And so yeah, we have a date, the IP address, et cetera,
and we're going to just activate the privacy by default parameter.
And instead of masking the data, we're going to unmask the data.
So now, we've activated privacy by default.
So everything is going to be masked.
And we're going to unmask the thing we want to see.
So maybe, yeah, maybe as a log URL, we want to see it.
So we're going to unmask it.
I'm going to say it's not masked.
And the date, we're going to just keep the year.
And we move the month and the date.
So we generalize the date.
And so with this, once I animate the table,
what I get is, OK, the date has been changed.
I just keep the year.
The IP address has disappeared.
For the present, I jump, I took the default value.
So I have the default value of this current.
And I unmask the URL.
Right.
OK, I'm almost finished now.
So yeah, the battle for privacy is happening right now.
Whether you want it or not in the middle of it.
So you have a responsibility.
And you also target for our data rigs.
So you need to step up and take actions.
But you don't have to take all actions or at once.
You can improve things on iterations.
And so the first things first, the one you need
to do is privacy by design.
So you need to go talk to the developers about privacy
and ask them which current old private data, which one
is OK to publish, et cetera, et cetera.
And if, because maybe if this is a software that you
bought, you need to go and reach the editor of software.
And say it's their responsibility, their software.
They have designed a database model.
It's up to them to tell you how you should apply masking
upon this thing.
It's not up to you to reverse engineer
that that is a model to guess which current should
be masked or not.
It's their responsibility.
It don't let them avoid that responsibility.
And once again, they can do it with processing measure.
It's free to open source.
If you want to do it with another tool, maybe they
would want to develop their own tooling.
Maybe a lot of editors know right now,
we would provide you with their own scripts.
I would say that it's just like running your own crypto
or running your own database, the backup scripts.
It's nice.
It's fun to do, but basically, just don't reinvent
so we'll use a proper masking tools.
Do not reinvent your own masking tools.
I did it.
I know what it cost.
Then once you've done this, yeah,
philosophical, you have this philosophical mindset
on doing privacy by designing everything else is easier.
Once you've said everything, we had something
we think about privacy at the very beginning,
everything else is easier.
And so the next steps are wall separation.
Attacks surface reduction.
And finally, that I meanization, a privacy
by default, extra.
So of course, you can do it as there was a war one,
but that's my advice.
And do not fight alone.
Get a team.
Because again, it involves a lot of different talents
to this.
So you have to have the developers with you.
You have to have the system in the DPO,
the software editor, if that's a software that you both,
etc., etc., yeah.
Do not do this by yourself on your own.
You need it's a teamwork.
And again, different strategies for different use case.
There's not one single strategies that was for everyone.
You even have some database where you
have multiple masking policies.
So maybe one policy just for GDPR.
And another policy for, I don't know, commercial secrets.
And commercial secrets are not concerned
by GDPR or the world's world.
So different tools, different techniques
for different contexts.
And that's about it.
So yeah, the extension is available on GitLab.
I've wrote a four-hour tutorial, if so,
if you want to try it as a documentation,
you can try the tutorial.
And you can contact me if you have any questions.
And also, if some people already use the extension
in the world, I should have as a beginning.
Does anyone already use the extension?
OK, one guy, yeah, good.
So if anyone's listening on GitLab,
then there's a server right now where
I try to get feedback from the users to know
what they do with the extension.
So yeah, you can answer that if you're using it.
And that's it for me.
So please do not move, wait for the end of the questions
to move it easier for me to answer if that's not.
OK.
That was very interesting, Tolk.
Thank you.
Any question?
Ooh.
All right, yeah, sure.
I have a question.
One more.
OK, so just a bit for the phone.
And after this one, OK.
Hey, thanks for the great talk.
I have a question.
Can you use logic or replication with the Mascad data?
I thought because sometimes dumping a big database
is very time consuming and still we
want to have Mascad data somewhere
on the staging environment, let's say.
Yeah, that's a great gratration.
We actually, so currently, we are in V2.
And we're working on D3, person 3.
And so we are working on something
that we were going to call the masking logical decoder
when you can subscribe to the prediction
and have your logical replication, but with the masking
rules are placed on the fly.
So yeah, it's not ready at all, but yeah,
we're really thinking about that a lot of people.
You can, for most of some people,
can not, well, as I say, as well as this.
Yeah, a lot of people cannot do this,
because there's too much data.
It takes too long, OK?
So yeah, again, because maybe the regular dump
will took one hour.
But depending of how much rules you have on your data set,
the anonymized dump will take maybe three hours.
All right?
It does a cost.
OK.
Yeah, thanks.
I was wondering about determinism in the masking.
So is it deterministic also across different databases?
If I have the same input values in one of my databases,
anonymized according to the same rule, it will end up
fully consistent across my data?
Yeah, actually, it depends.
You choose.
So you have some, where is it?
All right.
Yeah.
So among these types of masking rules,
some of them are deterministic.
Meaning that we always return the same result
for the same value, all right?
But some are completely random.
So basically, random and faking are always different.
But if you want to have the same fake value across
different database, this is called pseudo-sudo-sudo-neemization.
And so pseudo-neemization is not anonymization.
It's not the same thing.
Because there's a way to go back, because there's a deterministic,
once there's a deterministic transformation,
you can always go back.
So you need to be very careful about that.
And the GDPR regulation is very clear that if you have
done pseudo-neemization, your data is still
a concern about a still personal data, actually.
My question is a bit of a follow-up.
The table's simple functionality.
Well, that always return the same end elements,
or will it's a completely random sample on each and every call?
Now, it's a random sample.
It's random deadbossed.
You can't know which one we want.
If you want something deterministic,
you need something like that.
So if you want to use that function to limit the accessibility
of some analyzer, if he calls the function off
enough, he can still get your full data set.
Yeah, that's a good question.
So this is linked to another topic
called differential privacy, where at some point
with some of this, actually this, you have also
when you have noise.
If you put noise upon, for example, a date of birth,
the masking roll can ask for the date of birth multiple times.
And the noise will be applied with the same
a random function upon it.
So it's going to find out the truth at some point,
just by doing the mean of all the results he got.
So this is an area we're working on, which is called
differential privacy, but for now, yes,
you need to somehow track how many times your mask roll
will access to the data and how close they are getting
to the truth.
Just a little addiction to the table sample.
Is support solving?
So it's possible, maybe it's possible to repeat
at least the same that set.
Yeah, sure.
Yeah, you can define a sort, and so the salt will be
used in a good point.
Great talk.
I wanted to ask if someone has an already established database
that is not anonymized at all.
Was the best approach to go on about that?
Yeah, so the question is what to do when the database
is already in production?
Yeah, it's a worse scenario, because you need to look
at the database model and try to guess what
the developers try to do.
So if you can just try to find the people that made it,
otherwise, yeah, just privacy by default,
just add on those and everything is private.
Can I ask another question?
The sampling of the database, how does it work with foreign keys
and relationships?
Yeah, that's a very, very good question.
So basically, the exception does not guarantee
use that foreign keys will be respected.
So you can't break.
Yeah, it's up to you.
You can check it or you can destroy it.
But yeah, it's up to you to decide whether or not
you want to keep a referential integrity, right?
Because in some cases, it's important to break
referential integrity.
But for some user use case, you want to keep it.
It really depends, actually.
So there's no doubt rise about that.
If you do, it's like a not new, yeah, in this example,
for example, there's a not real concern from the ID.
But I'm putting a new value, all right?
And so the user will get a result that there's
not respect to the database schema.
But I do it in purpose.
Of course, yes.
OK, thank you for the talk over here.
Did you measure the overhead and performance impacts
of the extension?
Because if you do it on the fly, it has to.
Yeah.
So over it, it really depends on different factors.
So there's a number of lines, the number of rules you have,
and the complexity of rules.
Of course, this kind of rule is very fast.
Destroying is fast.
But generating a random value is very slow.
But the thing's to understand this with different strategies,
the cost is not paid by the same users.
With dynamic masking, the cost is paid by the mass troll.
So you can say, OK, your mass troll, you're
going to pay for this.
So you're going to have a very, very slow result
whereas the normal user with regular performances.
Whereas, if you do anonymized dumps,
the price is paid by everyone, right?
So it depends on who pays the cost.
In the use case of a mask troll, why would I
when do I need to use a mask troll instead of simply
restrict and access to some columns?
So I could grant a data scientist from your example
with access to the required columns only.
And just restrict access to the columns, which you actually
mask.
Maybe I don't see the whole picture here.
When do I need to mask a data instead of simply
restrict and access to this data?
Oh, but maybe because this is data scientist, for example,
he needs to run some queries upon, sorry, I get fast.
Now, this one, yeah.
So maybe he wants to run stats over the years.
And he wants to make some stats about the ASK test logs.
So he needs the year.
He's going to group by year.
So you can just erase the day and the months,
but you keep the year, right?
I see.
So that's called generalization.
And it's enough for him.
But so he has access, but he does a different access.
So when even more granular control is required,
yes, and sizes, data, for example, one part
is visible, but another is not.
Yeah.
OK, thank you.
And you can write your own, of course.
So the main use case for this is noise QL and JSON data.
So because if you ask JSON data,
it's going to be a nightmare to mask,
because there's no schema.
And so probably you're going to have to write your own functions
to go deep inside the JSON values to modify them.
You mentioned that indexes are not masked.
But if I'm a mask user, and I do a query,
it says that select from user swear or last name
is corner, would I get Sara Spellman or would
query it's actually a little unnomized data?
OK, the result, if you have an undistimistic value,
the query will change every time.
Yes.
The result will change every time.
Again and again.
No, I mean, the queries are actually going to match
against the masked values, not against the original value.
So right.
Yeah, no, you're going to mask it against the masked value,
not to really value it.
OK.
So it won't work.
You cannot if where name is gone, now it won't work.
But I need to go actually.
Just take a picture.
Yes.
Thank you very much.
I'll be outside if you have questions.
Sorry.
Privacy.
It's amazing.