Thank you once again for coming for the last talk of the day, at least for you.
With me, Thomas Persson, he's a business developer at Digitalist Sweden, he has worked with tracking
digital analytics since 2010 and has been a contributor to open source since 2007.
What happens under the hood when you visit a website and what data is actually shared
about you and who can actually access this data?
In this talk, Thomas will answer these questions.
Please begin.
All right.
Thank you.
Yeah, I'm getting a bit tired now.
Last session, for me at least, for this day, I'm really looking forward to having a long
weekend after this, but let's push it over the finish line.
So in this presentation, I will talk a little bit more on a higher level about privacy on
the web and what type of data and try to explain what happens under the hood when we're visiting
websites and also talk about personal identifying information in relation to web analytics and
then finally give you some examples of how to manage this in Atom.
So let's get started.
Let's see if I can just find that correct window.
So yeah, I got the presentation already, so I will skip that.
You probably know Digitalist at the time, so I will skip that so we can move forward.
But here's the kind of issues we have right now with privacy and the reason why I think
a lot of organizations are moving away from tools like Google Analytics, but basically
any cloud provider that is not provided by the EU and trying to do the simple explanation
here at least.
So this is me.
I'm a citizen in Sweden.
I live in Stockholm.
So if I go to stockholm.se where I can find a lot of information to me as a citizen.
I live in Sweden, so that means that we have a law in Sweden called OSL.
It's a Swedish law about publicity and secrecy.
It's been in place for quite some time and that law applies to me as a Swedish citizen.
And it applies to the organization running stockholm.se.
We also have GDPR, which is a European law and that applies to both of us as well since
EU is the level above us, so to speak.
To provide this service, stockholm.se probably has a lot of service providers.
They probably have a company doing their hosting, their development and so on.
Maybe design work or whatever.
So a lot of actors are involved in this work and they all apply to these laws.
So when stockholm.se write an agreement with these companies, these laws apply.
OSL and GDPR applies to these contracts.
The problem though is that when you start to write contracts with companies that are
not part of the European Union, like for instance if you use Office 365 or if you sign up for
Google Analytics on your site, the problem here is that Microsoft or Google or other
companies or basically any cloud provider, they live under other laws.
And in this particular example, we have something called the FISA 702 and that means that even
though we write a contract with Microsoft, these laws will override that and Microsoft
can't do anything about that, even though they would like to.
So this is kind of the main problem with using cloud services and what FISA 702 actually
says here is that if any American governmental institution basically requests for data, they
in a Microsoft facility, they have to give it to that organization and they can't stop
that in any way, at least not right now.
So this means that any data that is stored in a facility owned by Microsoft or Google
or whatever, and it doesn't matter if their physical servers are in Europe, you have to
think about it as if it's readable by the American public organizations and we'll look
into a little bit more about the problems with this later on.
So we will also look into the actual details.
So Google Analytics is obviously what we discuss when we talk about Matomo.
So yes, we need to think about when you use Google Analytics that we are leaking data
to foreign powers like NSA and so on.
We also have to think about that we're actually leaking personal data without having a consent
and this is an issue with GDPR in Europe.
We're also selling data about our visitors and that's more related to Google specifically.
But historically, this started with quite big, when the whistleblower Edward Snowden
with that didn't start though then, but it actually got really, really clear to us that
when he shared the NSA documents about what was happening, people started to realize how
big this really was.
So we talked about the law called FISA, it's actually called Foreign Intelligence Violence
Act.
It was a law created in the USA to actually protect the American citizen because there
has been a lot of surveillance going on, phone surveillance mainly and other things without
any regulations in the United States.
It was actually created to protect American citizens.
9-11 was the event that happened and that really changed how the American states started
to act differently.
So people at NSA has described this in many, many places that there is a time before and
after 9-11 and we'll see a little bit more about the statistics.
They basically changed the laws to make it even easier to supervise the society and in
particular people that are not members of the United States.
So Europe is a target market for this.
There are a lot of systems in place at NSA.
Some examples are systems called Upstream or Prism and Treasure Map.
This is basically systems that are snooping on internet traffic, phones, and etc.
And they have direct access to data centers at Google, Microsoft, Amazon, etc.
So it's really a large scale.
Also we have to know that internet traffic is passing through United American borders
and this means that it often gets stuck in this system called Upstream.
We'll look into more details about how easily this actually happens and what type of data
they can actually tap into.
So is this really a problem in a country like Sweden?
Is this really something that government agencies use to approach Swedish citizens?
So Sweden is a rather small country in Europe.
We have about 10 million citizens.
But the interesting part here is that Google, Amazon, Microsoft, and a lot of other companies,
I think it was about 50 companies in the beginning after the Snowden incident, have started to
report how often they leave data to public agencies in the States.
So this is the data from Google.
And as you can see, the growth here is pretty massive.
So they have left out information about 235,000 accounts the first six months of 2020.
The data is a bit lacking behind, but the numbers are actually growing.
So the same period in Sweden, we had 370 cases from Google where they handed out information
and you can think about this as, okay, maybe this is information that the Swedish police
is asking from NSA to give them.
But that data is actually not included here.
This is only data requested that American organizations ask for.
So we don't know what this is and it's totally out of our control.
I did a research and checked for Google, Microsoft, and Apple and as you can see, there's quite
a lot of information handed out.
And if you summarize this, it's actually eight times a day data is requested about Swedish
citizens from these four companies.
So there's no doubt that this is a huge, huge problem.
And because of this, we need to change the way, and I think this is extra critical if
you're a public organization handling citizen data or whatever, it goes for private companies
as well, but super important.
So what I usually say is that the public sector needs to secure our infrastructure.
We need to use open technologies such as Matomo, but that's just one thing of the problem.
We need to secure the traffic between the residents and the authorities so it never
leaves Europe.
This is another problem that we saw that if the internet traffic just passes through United
States, it's much probable that it gets stuck in this surveillance network.
So let's go into details of the web.
So what happens when I visit five websites under the hood?
So I did a little animation with a plugin called Lightbeam for Firefox.
So what we're seeing here is what happens, these are requests that's happened under the
hood, and this is actually public sector websites are related in Sweden, and you can see the
spider diagram on the left that all of them under the hood request information from Google
in this case.
They're using Google Analytics basically.
So that means that Google can profile all these visits not only on these particular
websites, but they can create profiles on individual level of pretty sensitive sites.
So yes, they use Google Analytics, and we need to remember that this is something that
Google sells, of course.
The 3% of the revenue two years ago, I think, was coming from ad sales basically.
So it's a huge problem.
So it's not just about the privacy and that they're leaking data, we're actually selling
their behavior to Google.
And Google is just one part of the problem.
You need to be aware of everything you do on your website.
So this is another Swedish, it's actually the government website in Sweden, and I've
been picking on them for a few years now.
The good thing is that they have actually changed this now.
So if you go to this site, they actually change how it works, and I think I affected them
a bit.
But the example is still good.
So if you go to a page called contact on the Swedish government site, and you look under
the hood, you do a request in your browser, and it's sent to their server, and back we
get HTML.
You all know this.
And in this HTML, we're actually requesting 33 other resources from six different domains.
And for each of these requests, the way internet works is actually we're sending my IP address
from my browser to every server.
And if we dig down in this and look into a specific one of these requests, it's a little
JavaScript called find.js, and it's coming from this domain, dl.episerver.net.
And what's interesting here is that with this request, we're actually also sending something
called the header.
The header contains another information that is called the referrer.
We're also having information such as the language in my browser.
We can see what browser I have in the user agent, et cetera, et cetera.
So basically the information shared with this server, dl.episerver.net, is the same kind
of information that you use when you track data in Matomo, meaning all the sites that
we request for information just to present our website is basically able to do the same
profiling that we can do with Matomo or any other tool on our website.
So you really need to control what type of resources you include on your websites, and
they have to be within the European Union if you're a European company.
All right.
So there are some web standards where you can actually try to block this.
There's something called the referrer policy, and if you set this to no referrer, you actually
can block sending the referrer information.
The problem though is that this standard is not respected by Microsoft, so all Microsoft
browsers will send that anyway, and it's also not respected by iPhones.
So Safari and iPhones will send that even though you try to block it, meaning quite
a few percentages of the visitors you will have on your website since it's quite common
software combinations or hardware combinations.
All right.
So to summarize, we do 26 calls.
Eight of these calls goes to four different domains in the United States, and in all these
we share the IP address and the URL, meaning that all these domains can basically start
profiling our visitors.
All right.
So the next thing, because that's really about the URLs and the IP addresses that are sensitive
information that we need to manage and handle in our Matomo installation, for instance.
But what about personal data in general?
So personal data can be defined as simple things as IP addresses, as we mentioned before,
email addresses, zip codes, social security numbers, et cetera, et cetera.
This list you've probably seen.
This means that when we're setting up tracking, we do not want to store these things in Matomo.
And usually this is not something people do, even though there are issues, of course, sometimes.
But more problematic is the thing, the fact that data in combination with other data that
identifies an individual is also to be considered as personal data.
And the best example I have on this is when you start to store location information.
So in this example, I have a little village in Sweden with 55th inhabitants.
It's called Lomtresk.
So now you know a bit of Swedish as well.
The interesting part here is if you store that dimension of data together with your
page views, you can start to get problems pretty quickly.
So think about the other meta information or metadata you store in analytics or in your
Matomo installation.
The first one would be, like, let's say we have a custom dimension with the profession.
Or maybe someone has been searching for a job.
Or something that we can identify a job role here.
Or we can identify that this is the language is Turkish in the browser.
And maybe we can identify that this is a woman.
We can think about how quickly, how easy it starts to get to identify this person just
from these quite anonymous combinations of data.
We can continue.
Just an unusual mobile phone would actually be a problematic thing here.
Maybe everyone in Lomtresk knows who has an iPhone of a specific model.
Or you can find that in an image on Facebook or whatever and start to identify visitors
here.
So that leads us to that personal data is not something fixed.
We need to continuously monitor this and we need to continuously be able to act.
And what we also need to know is that when we include other services on our website,
visitors sharing this information with them.
So if you add, most of them are big in Sweden, but it's a lot of things that you need to
look into and make sure that you're not sharing data with.
I actually created a little tool.
It's actually a JavaScript.
So if you go to my GitHub profile, what this one does is that I'm actually going to show
you.
So if I copy this code and I can basically do this on any website.
So let's do it on atomocamp.org and see if we are okay here.
I'm going to open the inspect.
We're going to just paste this little script and what it will do is to start a request.
Okay, this one was pretty good.
We only included one external script and the country it was requesting was Germany.
So let's do this at the Swedish government again and see how well they are behaving.
I'm going to go there and I'm going to paste the JavaScript and now we're requesting a
lot of websites and I can actually see that they improved since I picked on them.
From all of these sites, we are pulling different scripts and here you can see the country from
where they are requested.
So they did pretty good.
That was not the scenario six months ago and this is good because this means that even
though they share data with these players, they're even in Sweden here so if they have
a contract with them not to share data with anyone else, we're actually legally safe.
Which wouldn't be the case if the country of the scripts would be the United States
and one very common thing is to use CDN networks to load JavaScript for instance and that would
be a problem.
So what do we do when the accident occurs?
So since storing personal data is something you should actually plan for that you will
do, that's usually how I talk to my clients.
You can't really stop this from happening.
You need to plan for when it happens.
So you have to have routines in place to act when you find personal data in your analytics
and this is the action plan I usually show.
So first we need to assess how severe this is.
I mean how sensitive is the data that we have leaked?
As quickly as possible we prevent further collection.
So data is not collected more than necessary.
In Sweden we actually have to decide within 72 hours after the incident, we notice the
incident to our reporting organization basically for GDPR and data leakage.
What we need to do after this is of course to try to clear or anonymize the data.
We need to document the incident and potentially inform the victims like if users' data was
really sensitive we might have to contact them even and then I usually say that let's
have a retrospective to see if we can avoid that this happens again.
Maybe this is about training because most of these mistakes are personal but not always.
Sometimes there are technical solutions.
Clearing data though is something that we need to work pretty much with and that's actually
something that is possible if you're using Matomo but it's not necessarily easy just
because you can.
So deleting data in Matomo usually looks like this.
First of all you have to find the data, you have to identify the actual visitors and the
raw data.
So you have to find the visitor IDs that are affected.
You need to delete these visits, I will show you some examples soon and then you need to
reprocess your visitor log so that the aggregated data reports are updated.
So for instance if you find an email address in your page view report you would first need
to find the visitors that sent this data in and delete those and then you need to reprocess
your aggregated reports for the dates when that data was stored.
So that's quite a big job to do that.
One thing you can do to start monitoring this is actually to use a plugin called the alert
plugin and in that plugin you can start to set up rules to identify personal sensitive
information and I will show you an example of this.
So what you do is that you for instance if you want to start monitoring your page views
you can set up an alert and you can use the regular expression.
In the example here I'm matching a date but I will give you some and then if we have more
than one page view containing a date I will get an alarm or a report that at least highlights
that I need to look at this.
So an example here is that you can find a lot of regular expressions online.
So in this case I have the example of an email address.
So let's monitor if we have email addresses in our events or our page views and ping me
if that happens.
Finally you can combine these into a long string so you don't have to create individual
reports for every monitor you have.
The drawback of this is that the alert plugin will only process once a day or every night.
You can't do that more often and it's also hard to identify something like a name or
something like that.
So it's only data that is quite easy to identify that you can find this way.
Once you find it you can use a tool called GDPR tools and try to delete things that way.
You need to find the visitor ID and when you do so you can delete that.
You can also use the API, the example below.
If you have a lot of data you can create a script and call the API many times.
I can also show you what is a bit problematic.
So in this case I look at the pages report and now I'm just simulating but let's say
that this is my name on our site so it's not really personal data.
But what if I wanted to delete this information because it's sensitive?
So what I would do is to click on this one, segmented visitor log.
So when I click this one I will actually get the visits and in this case I even have a
little JavaScript in my browser so I actually have a little button here that allows me to
delete this directly.
But otherwise you can hover on the IP address and you can actually find the visitor ID up
there.
You can probably see it in the screen.
This is the information that you need to grab and then use in the GDPR tools and apply
it here.
It's called visitor ID.
You can actually steal this little number.
So as you see it's starting to get quite time consuming.
If you have a lot of personal data this is a terribly time consuming job.
This little JavaScript helps me.
What it actually does is that it calls the API.
I have just created a link to that.
It's actually this little line here and I automatically add the ID visit to delete it.
So the idea I have for the future is to actually build a PII monitoring plugin for Matomo.
That plugin would first of all set up some predefined rules to identify things like email
addresses, credit card numbers, et cetera, so that we have alarms.
I would also set it up to watch more types of data directly like events, page views,
refer URLs.
You can come up with a lot of ideas.
I would also make it possible to add exceptions.
After you try to identify something or identify something that is actually okay.
So we want to add an exception to that.
I would also like to make it easy to delete data so the report would actually give me
all the visitor IDs and make it possible to delete them directly.
I would also like to be possible to just anonymize the data and not maybe delete it.
So let's say I found a credit card number but I still want to have the traffic stored
in my website.
I just want to anonymize that information.
But that's not really possible today unless you write SQL scripts.
So these are kind of the ideas that I have around this plugin.
It shouldn't be too hard to do the basics.
The hard part is of course to start monitoring combinations of data.
Like it would be impossible almost to do what I showed you with the small village Lundträsk
and identify those individuals.
Alright, so the last slide actually or the second last slide.
But usually this is what I recommend people to look into if you want to secure your web
analysis.
So first of all collect consents from your visitor and inform them that you are tracking.
This is all from the GDPR.
Check your data collection.
Find the obvious collection of personal identification information and set up your Matomo instance
properly.
That means anonymizing IP addresses, not storing data longer than needed, etc, etc.
Also make sure to manage the quality of your application.
So they are not sending personal identification information because that's normally one of
the issues we have when we get bad data.
It's often the applications that are wrong.
Also make sure to secure your technical infrastructure.
The service has to be within Europe and it has to be owned by a European company.
You can't use cloud providers in Europe because you're invalidating GDPR by doing so.
Also make sure to limit the time for how long you store data.
Make sure to have processes in place to monitor data and make sure that you know how to act
when you find problems.
Alright, so that was the last slide.
I think it's time for questions.
Thank you for this very interesting talk.
If there are any questions, please post them or write them down in the corresponding chat.
There's been some small discussion of the privacy test and I will share it if it's alright
for you.
Yeah, I saw that.
Nice, Lukas.
That one, of course, is a good thing.
So who wants to help me write the PII plug-in, Lukas?
Are you ready to help?
Check my calendar.
Yeah, of course.
It's the same here, I think.
But it's definitely just something I think a lot of people would appreciate.
Alright, so if we don't have more questions, I'm going to say thank you for today and hope
you enjoyed it.
I'm pretty tired now, so I'm going to have a really nice weekend with my family, maybe
go out and pick some mushrooms and yeah, be outside.
There would be one last question that you would be willing to answer.
Is there any other kind of information apart from cookies and JavaScript code, codes sent
to third parties?
Anything you basically include, so it would be fonts, images, anything.
Anything you request might actually share that information.
Thank you for that.
And if there aren't any other questions, which I think there aren't, then yes, enjoy a long
weekend.
Yes, thank you.
Let's see.
Maybe more questions coming, we'll see.
Oh yeah, a ton of them.
Maybe they're just thanking you for the great talks.
We'll see.
Two seconds.
It seems to be the case that there aren't any more questions coming.
Let's have a nice weekend.
That sounds good.
So let's call it here.
Yeah.
As always, if there are any other questions, you can still be asked.
And yeah, have a great day, have a great weekend.
Thanks for your talks.