Hi all,
I'm not sure I agree with this advice I'm afraid, or at least it risks
underplaying what you need to consider. Tim is right that it very much
matters whether you are processing data, but "processing" doesn't have
the meaning that you and I might put on it day-to-day. It means doing
pretty much anything at all, including simply storing or transmitting it
- or enabling some other party to do the same, which is what happens if
you put various scripts or assets on your pages, for example. Every
cookie is transmitted by their nature, and every cookie is stored, at
least on the user's machine, so it is all "processed" in the GDPR sense.
All the same some kinds of data are not within the scope of GDPR - stuff
that isn't "personal" - but "personal" is again probably broader than
you might imagine. It essentially means that the data could be related
to an individual (note that it doesn't have to be a named individual -
after all you can be profiled without someone knowing your name, and
this profile used in all sorts of ways invisible or harmful to you or
others).
If you are processing the sort of data that /is /covered, there are a
number of legitimate reasons that you can claim for doing so, but the
principal "lawful basis" that we rely on in our game is consent - and
this really is /not /the same as just informing someone that cookies are
being set. It is definitely not the case that you can consider that it
is sufficient to tell people that you are using cookies (or doing other
kinds of processing) and then to consider it to be consent if they carry
on using your site. Admittedly many, many sites do just this, and I'm
confident that they are not GDPR-compliant. If you offer no choice, it's
not consent. Some sites offer some form of consent mechanism and make it
so difficult to say no that they are arguably not getting consent even
then (hi Oath!). But it is also really, really important to note that
consent must be obtained for each kind of processing (not individually
for each cookie, necessarily, though you might want to enable that
granularity. But for each kind of processing). And you can't then use
the same data for another purpose without consent. "purposes" aren't
standardised, but you tend to see them as things like "measurement" or
"personalisation". You might be able to rely on other lawful bases
though, for example "legitimate interests" or your public task.
Not all cookies are within the scope of GDPR (they may have no privacy
aspect) and other are exempt. If a cookie is strictly necessary for
offering the service i.e. the website can't run without it, that's
reason enough for you to place it. Likewise cookies required to operate
a cookie consent solution! There is also an exemption for basic web
stats uses because they are considered non-privacy intrusive (at least
this is the intention of the ePrivacy Regulation, which isn't yet
adopted but is meant to tell us all how to implement GDPR in the real
electronic world). But again, it can't then be used for other purposes
without consent.
As Tim says, where you can offload this reponsibility to someone else
that's a great plan. GDPR after all goes much further than cookies
anyway, and if you do get into storing data yourself for e.g. ticketing
there's a whole lot more you need to consider. If another company is
doing that for you on their own site, they are doing the processing and
I'd agree with Tim that you should be able to leave it to them to get
the relevant consents. But quite likely your are doing other things
involving processing in the GDPR sense on your own site too.
Finally-not-finally, if you want to do this properly i.e. be fully
within the law, note that consent is meant to be evidenced and
revokable. Some cookie control solutions literally store the consents of
users in a database with an audit trail, and update these should a user
change their mind. Others do something similar client-side. But
revocation is as important, and it means that you need to build in the
ability for users to change their mind and to purge cookies set on your
site. This is possible for first-party cookies but it is basically
impossible for third-party cookies - these would need to be purged by
the user, or the service that set them. This makes it extra important
that you never allow third parties to set cookies before you get any
consent that you will rely on, otherwise your users are stuck with them.
It is perfectly possible, and you can continue to use all those
third-party embedded scripts and media as now, but you just need to take
great care before putting them on the page.
This is about GDPR and CCPA, of course, but I'd plead with you not to
look at this as just a legal PITA. This stuff is for all our benefits.
Yes, you could say you'll only do this for customers in the EU, but
shouldn't all museums should have the interests of their users at heart?
And doesn't that include not facilitating intrusions into their privacy?
We have responsibilities other than to the law. And yes, the laws are
arguably a bit clumsy or awkward to live with, but the reason for that
is really that a whole ecosystem has grown up with minimal moderation
from anyone other than tech companies, who have been able to percolate
privacy-toxic practices through the entire web. It doesn't have to be
this way, and maybe these laws can start to wean us at least off some of
the bad habits we've developed (as website owners, or as tech giants!)
over the years. Then it will get easier.
If I could point you to a couple of blog posts, this one from Maciej
Cegłowski (the guy behind Pinboard) is just generally excellent on why
we should all care about privacy - in fact think about it in terms far
greater than individual consent and so on, and instead as a society
develop an culture of "ambient privacy", being a common good that we all
need to protect for mutual benefit:
https://idlewords.com/2019/06/the_new_wilderness.htm
And far less interesting or sweeping, this is one of a series of posts I
wrote, hmm, a year ago now. It digs into GDPR as pertains to cookies and
the like, and later posts get more into the question of what this means
for running websites and getting consent, as well as how to do it.
Things have evolved a bit in the interim but not fundamentally as far as
I know.
https://medium.com/sesamoidish/what-is-the-deal-with-gdpr-the-cookie-directive-and-the-eprivacy-regulation-c6b20f4e66b
All the best,
Jeremy
-------------------------------------
Dr Jeremy Ottevanger
Director, Sesamoid Consulting Limited
t: +44(0)1787 475 487
m: +44(0)7865 887 887
e: [email protected]
w: https://sesamoidconsulting.co.uk/
twitter: @jottevanger
LinkedIn: www.linkedin.com/in/jeremy-ottevanger
On 04/03/2020 17:23, Tim Schwartz wrote:
Hey Andrew,
We implemented GDPR for https://www.aam-us.org/ and a number of other
sites. A lot of it depends on if you are actually processing data or not,
or using cookies to track people. But for GDPR specifically it only matters
that those from the countries are informed, so you likely don't need to
change anything for your US customers. It looks like you are only
collecting data on your ticketing site, I would suggest offloading all the
GDPR and CCPA to them and the subdomain they use, not on your main site.
Feel free to follow up with me directly if you have more questions.
-tim
On Wed, Mar 4, 2020 at 3:02 AM Amalyah Keshet <[email protected]>
wrote:
Andrew:
The consultancy I work for does comprehensive GDPR compliance training.
If you like you can contact me off list.
Amalyah Keshet
On Tue, Mar 3, 2020, 02:02 Andrew Fox <[email protected]> wrote:
Does anyone have any experience making a museum website CCPA and/or GDPR
compliant? Right now I'm getting mixed messages from both our legal
counsel
and our marketing team who are in contact with their media agency.
A quick and far from thorough survey of museum websites suggests that
most
aren't doing anything to address it yet, but I'd love to hear from anyone
who has.
Thanks!
*Andrew Fox*Senior Web & Interactive Developer
Fine Arts Museums of San Francisco
415.750.3615
_______________________________________________
You are currently subscribed to mcn-l, the listserv of the Museum
Computer
Network (http://www.mcn.edu)
To post to this list, send messages to: [email protected]
To unsubscribe or change mcn-l delivery options visit:
http://mcn.edu/mailman/listinfo/mcn-l
The MCN-L archives can be found at:
http://www.mail-archive.com/[email protected]/
_______________________________________________
You are currently subscribed to mcn-l, the listserv of the Museum Computer
Network (http://www.mcn.edu)
To post to this list, send messages to: [email protected]
To unsubscribe or change mcn-l delivery options visit:
http://mcn.edu/mailman/listinfo/mcn-l
The MCN-L archives can be found at:
http://www.mail-archive.com/[email protected]/
_______________________________________________
You are currently subscribed to mcn-l, the listserv of the Museum Computer
Network (http://www.mcn.edu)
To post to this list, send messages to: [email protected]
To unsubscribe or change mcn-l delivery options visit:
http://mcn.edu/mailman/listinfo/mcn-l
The MCN-L archives can be found at:
http://www.mail-archive.com/[email protected]/
_______________________________________________
You are currently subscribed to mcn-l, the listserv of the Museum Computer
Network (http://www.mcn.edu)
To post to this list, send messages to: [email protected]
To unsubscribe or change mcn-l delivery options visit:
http://mcn.edu/mailman/listinfo/mcn-l
The MCN-L archives can be found at:
http://www.mail-archive.com/[email protected]/
