Note: I'm not any type of lawyer. I'm not an intellectual property
lawyer. I'm not an EU law lawyer.
I'm just a (former?) designer who has to be informed about
intellectual property issues and read a lot of information on the GDPR
from other websites and lawyers. And I may misunderstand any or all
of it. But I'm trying to help my clients (some on PmWiki, thankfully
most US and only dealing with local customers) understand this stuff,
and deal with my own business information and needs at the same time.
Not everyone using PmWiki needs be concerned about the GDPR, but many
of us do. I run a life coaching website with a PmWiki website, a
large mental health resource, and a private consulting business — in
the States. But my clients disclose a great deal of personal
identifying information that could be stigmatizing/grounds for
discrimination to me. From as simple as gender or gender-identity
issues and sexual orientation to mental health diagnosis and physical
health information. Or if I'm editing or formatting a book manuscript
from someone in the EU — that counts.
On Jun 27, 2018, at 10:10 AM, Petko Yotov <5...@5ko.fr> wrote:
On 22/06/2018 00:40, Criss Ittermann wrote:
What I see as material problems are:
Removing people from Diffs — mentioned in a thread on the PmWiki
Users
list — if they request their data to be completely removed from the
site. That can be tricky — there's a difference between being an
author (of an original article or section thereof, thus possessing
copyright to the creation) vs. editor. Removing a diff in the middle
of a chain of diffs can materially change a wiki page in ways that
don't work. If someone fixed a typo, it's now a typo again — and
that
would be OK I suppose. But if someone added a paragraph that was
later edited & added-to — now the context for further changes is
missing.
You don't need to remove their edits (the diffs), their edits are not
personal information. Personal information in page history are only
their name and IP address.
We need to write a recipe that takes an author identifier (username or
e-mail) and possibly an IP address (although some IP addresses may
forward thousands of users), then reads all pages with full history
and pseudonymizes or anonymizes these bits: just rewrites the "author"
and "host" page attributes with some string like user20180627T1322.
As long as it is impossible to guess or recover the personal
information from the files on your server by other users, or in case
of a breach, it may be enough.
The GDPR appears to require people be able to be "Disappeared" and if
their contributions are their copyrighted information, then their
contributions need to be removed.
https://thegdprguy.com/right-to-erasure/
From what I understand they also need to be able to have a download of
all their contributions. They can back up their contributions or all
their contributed copyrighted work — or both download/back-up and have
it all deleted.
So, for example: I have a large PmWiki website (kinhost.org) in which
people may have shared personal information on a live wiki page. They
may have disclosed their sexual orientation, different names they go
by online, etc.
The contributions itself, signed with their name or Internet handle,
are personal identifying information and disclosures, and they have
the right to erase their contributions.
Yes, they volunteered the information just like one volunteers a
Facebook post or Tweet. That doesn't block their right to have it
backed up &/or removed entirely.
And if I want to be erased, I have the right to have all of my
information removed from the website — perhaps because it may affect
future employability. Like if I felt someone might hold my
contributions to PmWiki against me (yes, I'm making something up), I
have the right to have all my information on the PmWiki.org site
removed. One could argue whether that would include my plug-ins and
the documentation thereof. Is it still my copyright? Is my name in
the document? It's a rough consideration — but it's something
required to think about especially with PmWiki having authors from
around the world.
It's the nature of my wiki (being a mental health resource) that these
disclosures are more likely, and much more likely to be stigmatizing
or the basis for discrimination — but the fact that this type of info
is still in a Diff would be a problem.
Making sure all email & comment forms have a required checkbox (not
checked already) asking permission to share/email/store personally
identifying information. Though that's pretty easy if you know how
to
use PmForm.
If you use "explicit consent" as sole legal basis for collection and
processing of personal information you need to explain each and every
different purpose for this collection and processing, with individual
checkboxes, where people may select some or all checkboxes.
Yes.
In most cases, it would simply be for email storage (unless I was
specifically tracking people in a CRM or putting them on a newsletter
email list etc.). And someone could request I go into my email and
delete their emails from my personal files or my IMAP or wherever it's
stored.
The basic PmWiki contact email should have an example of this. I know
I wrote the honeypot recipe for Pmform for example.... so I will have
to (both for my own sites' sake and for PmWiki in general) see about
contributing a fix for this issue. It's the need to track/log
permissions that's a real thorn.
Actually, in the case of emails, it could be tracked in the email that
comes to the addressee really. They're the one storing the email
anyhow.... so the wording of the consent and what's checked.
The checkbox being a required field stops the email from being sent
without consent, so it's a self-limiting issue in the first place. At
least that's how I set up a Mailchimp form — 1 checkbox, and it's
required. Without explicit consent, the email form doesn't work.
Note that besides "explicit consent" there are 6 other cases for legal
basis for this -- if you are in at least one of these cases, you don't
require explicit consent.
As a not-a-lawyer, I can't defend these 6 cases as easily as I can
write a disclosure/privacy policy that explains why I have someone's
information, how it will be used, and where it's kept/security info.
I don't think I fall under these cases except perhaps IP address info
on my server, but it's easier for me to tell people the web logs have
their IP address and it's on a rotation to be deleted automatically
than it is for me to figure out if I'm an exception to the privacy
policy rules or defend an exception in court.
I've already figured out that in several cases I'm NOT an exception to
their under-the-radar under 250 employee rules. I don't need to hire
someone to be my GDPR expert, but I do need to follow just about
everything else. Both for my life coaching business AND for my
consulting business because it handles business information & other
people's copyrighted materials or trade secrets. And my community
resource site also — it's about mental health info. Bingo. Hits the
mark for the GDPR.
One of these cases is "legitimate interest of your company or a third
party" (for example usage statistics, software troubleshooting),
another one is "legal obligations" (for example it is required by law
to store the server access logs for 2 years, and they contain the IP
address which is considered personal information by the GDPR), and yet
another one is "fulfill contractual obligations with person", and
"perform tasks at person's request" (for example they request the
creation of an account, or request notifications, or request password
recovery).
I believe the safest thing to do would be to explain that these are
your reasons for having their information in a privacy policy, rather
than assume that one can let it ride because one is covered with legit
reasons.
That means, if you have some "terms of use" which may be considered a
contract, one single checkbox may be enough.
A flag with a link to the policy, an "Accept" button and a log of who
has accepted with a server timestamp.... "Who" may be IP address, or
Author name if entered. But it must be explicitly collected, making
this tricky. It can't just be stored in their cookie.
Mailchimp is now saving an electronic "copy" of a person clicking that
they want to receive "email" from you. If you have several checkboxes
for GDPR acceptance, it tracks how many one has checked.
Record keeping is part of the GDPR....
It can be a text log I would imagine, or it could be stored in
SiteAdmin on the PmWiki back-end. But the text of the
form/notification agreed to probably should be tracked along with the
checkbox checked and time & some way to identify "who" like IP/Author.
I wish it weren't complicated — but it is. And it's necessary.
At any rate, you need a simple, plain text summary of your use of
personal information.
Getting explicit permissions before setting ANY cookies (not "if you
use this site you agree to cookies....") which should be in a pop-up
with a checkbox, and the permission has to be tracked though I have
no
idea how you'd trace it (just on IP?).
For a PmWiki cookie, only a session ID, and probably the "Author"
cookie are considered personal information, you can send other cookies
without the need for consent.
It's still a cookie, and from what I can tell you're not allowed to
set cookies without express consent. So the cookie can't be set until
they agree to accept it. Even if it's "only" a session ID.
If you have a legitimate interest (usage information, editor
accountability, security, troubleshooting), you don't need explicit
consent.
Where does it say this? Everything I've read makes it our
responsibility to get that consent before ALLOWING the cookie to be
set. So for our security on both ends we need explicit consent before
allowing comments, emails to us, or edits/authoring on our wikis.
From people in the EU at least, but as more countries decide they like
this policy, I expect this to catch on for other countries.
(Especially when they see the type of money the EU makes on
compliance.)
BTW the IP address is also personal information, it is crazy that by
law we have to store the server access logs with the IP address, and
people need to consent before. This is a Catch 22 abomination, when
someone opens the site, the server immediately stores the log entry,
and if they do not consent the server stores another log entry.
Yes, the IP address is personal identifying information. It says so
directly in the GDPR.
I believe the people who wrote the parts about cookies and IP
addresses were somewhat ignorant about how the internet works, and
they did not get help, which was stupid.
Actually, I think they meant it no matter how difficult it is for
admins and software authors. And we can blame it on Big Data, but yes
their tracking is completely obnoxious, and after retargeting pixels
and Google's gmail using targeted advertising based on email content —
this is 100% necessary for the protection of individuals. So even
though it's inconvenient, and even though I'm in the US, I actually
think they're doing the right thing and it's our responsibility to our
users and admins to make this more secure and explicit for them to be
able to use this software.
It may or may not come from ignorance — but it really doesn't matter
now that it's law. Fight to change it if you're in the EU, and I'd
disagree with you as a person who doesn't like their kids being a
bunch of statistics in some advertisers' databases — but it's there
now. Hopefully the EU wouldn't come after someone as small as me, but
they can. And maybe they will lest they be accused of only going
after big corps with big bankrolls.
In the meantime, I'm scrambling to cover my butt.
And you can't say "using this site constitutes you agree to our
privacy policy or terms of service" — you need a material checkbox
agreeing to it, with a link, and that checkbox use has to be tracked
somehow (just like email form & comment form permission, and just
like
the cookie-setting issue — everything has to be tracked).
If the software is written in a way that it refuses to go forward
unless the checkbox is checked, wouldn't this be enough?
If it actually doesn't allow use of the site, yes, but implied consent
is NOT allowed. So if a cookie is set without explicit consent you're
in violation. And if they continue to use the site without explicit
consent, it does NOT count as consent, even if you claim it does
(according to the GDPR).
Is there a way to disable cookies unless logged in as an author or
admin? That would be a quick way to put a stop to at least part of
the problem.
Then the PmWiki login could have a GDPR-compliance checkbox.
As most of my sites are only edited by me, it would help because I'm
the only one it needs a cookie for — why put a cookie on visitors? I
don't need that.
I took Google Analytics off my sites (before GDPR stuff) because I
don't want to be responsible for their handling my traffic and knowing
which IPs go to which pages of my sites — people are logged in in
Gmail and Google or YouTube — Google knows exactly who they are and
doesn't need to know they have mental health issues of any type. I'm
scrambling to remove a call to Google Fonts off one of my sites so the
fonts are embedded rather than pulled from Google thus identifying my
web visitors.
This is pretty serious.
A neat thing WordPress did is they have plug-ins supply "Suggested
wording" for privacy policies to cover that they're in use on the
site. When the user is on the back-end there's help documents for
creating a privacy policy, and for example Akismet suggests some
wording for your privacy policy. WordPress overall gives suggested
wording (which covers general cookies, and mentions that you have to
put your analytics etc. into the document).
Indeed, you probably need to mention that you outsource analytics to
external companies and embed content from other platforms like videos
or maps.
Yes. Done.
There is a JS program that can be useful, Tarteaucitron ("Lemon pie"
in French):
https://github.com/AmauriC/tarteaucitron.js
It can be configured to delay the loading of external resources like
analytics and videos until the visitor accepts these individually and
explicitly, and the visitor can see and delete individual cookies.
Very nice. Sexy. lol — wouldn't work for people with JS blocked....
and since embedded content isn't always done with JS, it would
probably not work for me. I'd have to require JS to use this
plug-in....which kinda defeats the purpose of the good reasons to
block JS. :/
Crisses
_______________________________________________
pmwiki-devel mailing list
pmwiki-devel@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
