GDPR compliance

[p-vitt]

I'm using isso on a blog in germany, thus I need to fulfill the General Data Protection Regulation requirements. To do so, I have some questions:

• How to deactivate setting the session cookie? I don't want to set cookies at all, and the isso cookie is the only one.
• How to deactivate the ATOM feed API?
• What information is stored in the database? Up to now I know about ip address, name (optional), mail address (optional) and website (optional). Is there more personally identifiable information stored?

[wastedepository]

Disclosure: I'm not involved in the development of Isso in any way.

I'm not sure about the answers to questions 1 and 2, but aside from the fields you mention, the times at which a comment was created and last edited are stored. You can use a cookie blocker and see if you're still able to make posts, but you will not be able to edit posts.

Is GDPR really going to affect the storage of a lightweight commenting system? Isso has no mechanism for advertising or sending your data to subscribers. All Isso really tracks in the database is partial IP addresses (see vincentbernat's comment below) and posting times of comments. I would assume that the usage of partial IP addresses means that Isso is GDPR-compliant on this point, as partial IP addresses fall under the concept of pseudonymization and cannot be used to directly identify a person.

Regarding cookies: Isso uses cookies to allow users to edit posts and to remember the usernames that they last used to make a post. Isso could abandon the use of cookies in favor of a purely IP address-based post-editing solution, although doing so would be a bad solution that would not work well for people behind routers or with dynamic IP addresses. In any case, from a privacy-based standpoint, it is better to store details in cookies that the user can easily delete, instead of storing IP address-based information on the server.

There is a different issue related to the GDPR that is of interest to me, regarding "the right to be forgotten". The way Isso works, all commenting, from a user perspective, is effectively anonymous. (Although partial IP addresses associated with comments are stored server-side, I assume this is simply to give admins the ability to identify potential general sources of spam.) Because there are no real user accounts, if you were to disable cookies or delete a cookie, or simply wait a few minutes after you post a comment, you can no longer edit that comment. Is that GDPR-compliant, particularly if a user voluntarily discloses information that supposedly identifies who they really are, such as their unverified email address? I have no idea. Maybe it depends what the GDPR means by "personal data". If the removal of the option to edit old posts does break GDPR compliance, it would be ironic, because Isso is actually very privacy-conscious, by the fact that all posting is effectively anonymous. If the GDPR mandates that users must be able to delete their old posts, the GDPR would be forcing Isso to actually track much more information on users than Isso does currently. Perhaps a good compromise is a situation where you make it clear in your terms of service that any comment which contains personally identifiable information about someone can be deleted on request. This seems like it would comply with GDPR rules on the subject. There is a similar discussion related to this topic here.

As a side note, it's easy to tell what information is stored in the database. Just run:

sqlite3 sqlite> .open /path/to/isso.db sqlite> .schema sqlite> select * from comments;

[vincentbernat]

If you are using nginx, you can use this:

 location / {
  proxy_pass http://localhost:8080;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header Host $host;
  proxy_set_header X-Forwarded-Proto $scheme;
  proxy_hide_header Set-Cookie;
  proxy_hide_header X-Set-Cookie;
  proxy_ignore_headers Set-Cookie;
 }

The ATOM feed can be disabled by not configuring it. If base is empty, the API endpoint will always return 404. What is the relation with the GDPR?

The IP address is stored partially. For IPv4, the last byte is omitted. For IPv6, the last 10 bytes are omitted. This should make the IP address a non-identifiable information.

[p-vitt]

Thanks for the replies. The following is what I learned the last days about the GDPR. As I'm not a lawyer, this isn't necessarily correct. Please feel free to improve.

Is GDPR really going to affect the storage of a lightweight commenting system? Isso has no mechanism for advertising or sending your data to subscribers.

Yes, it is. GDPR is not about advertisement, it is about what and how data is stored. And the comment system allows the user to add personal data, e.g. his name or his email address and it also stores an ip address. Thus sites using isso have to declare that those data is stored and for how long.

The same with cookies. All sites using isso have to declare that they use cookies and what information is stored within these cookies.

Just let me sketch a basic GDPR declaration: When you add a comment, we indefinitely store

• a pseudonymized IP address (IPv4: last byte is omitted, IPv6: last 10 bytes are omitted)
• your name, if provided
• your email address, if provided
• your website address, if provided When you add a comment, we also store a session cookie on your computer containing your name, your email and website address, if provided. If you want to keep the possibility to delete your comments, please provide some data, e.g. your mail address, to identify your comments later on.

About the atom feeds: In a GDPR declaration/terms of service generator I was asked whether comments are accessible via feed. I don't know why this is of any interest, but as I don't want to provide a comment feed, I want to disable this completely. I guess I could also do this with some .htaccess statements pointing the feed url to nothing. However, having this configurable would be more elegant. So, thanks for the hint with base.

[vincentbernat]

The session cookie doesn't contain your name. It only contains the ID of the message along with a hash of the content, signed by a secret key. The cookie enables you to modify/delete your message. It is only kept for a short time since comments can only be edited/deleted for a short time (max-age in the configuration).

Name, email and website values are stored in user's local storage. They are never sent back to the server and are only used to pre-fill the appropriate fields.

[p-vitt]

The session cookie doesn't contain your name. It only contains the ID of the message along with a hash of the content, signed by a secret key.

True. Sorry, I was mislead by this local storage which contains the name, mail and website, but this seems to be a browser cache. Cookies show up in another bin. Sorry for that confusion. And thanks again for the replies.

[arno01]

@p-vitt thank you for the GDPR declaration sketch! I think this could be added as a file to this project somewhere, if you have the latest version of the GDPR declaration sketch, please paste it here or update. I can create a PR for adding it to the isso project.

[p-vitt]

@arno01 I actually use it more or less unchanged (but translated, though).

Besides, I guess this topic is settled by now? So I'll close this issue. If there is still need to discuss this any further, fell free to reopen.

[Feuerfuchs]

I'd just like to clarify how isso's ATOM feed is affected by the GDPR.

About the atom feeds: In a GDPR declaration/terms of service generator I was asked whether comments are accessible via feed. I don't know why this is of any interest, but as I don't want to provide a comment feed, I want to disable this completely. I guess I could also do this with some .htaccess statements pointing the feed url to nothing. However, having this configurable would be more elegant. So, thanks for the hint with base.

I can only guess what generator you used, but the one I use asks the same question for the reason that a comment subscription feature must implement a double-opt-in mechanism before users are actually subscribed.

Unfortunately, that assumes that a comment subscription works like a newsletter, i.e. users have to enter their email address and will then receive notifications about new comments on there. Due to § 7 II UWG, you have to make absolutely sure that the recipient is the same person as the one who submitted the email address and therefore wants to receive these emails. That can be ensured with a double-opt-in. Now, the UWG is German law, but I assume that under the GDPR you have to take similar measures to make sure the user consented to receiving emails.

However, RSS/ATOM feeds like the one generated by isso are way different: They exist as a static list on your server and you, as a webmaster, don't send any kind of notifications to your users. Instead, it's the user who actively accesses your feed using their browser or a dedicated feed reader. Checking how this relates to the UWG, the sole act of accessing the feed is a conscious decision by the user. Automatic updates are not part of your website but rather a feature of the user's feed reader, so you don't need to account for that. Checking the requirements of the GDPR (i.e. how data is collected), accessing the feed is exactly the same act as visiting a regular page on your website. That should be covered by your privacy policy section about server access logs.

So in essence, there is no need to worry about isso's ATOM feed in relation to the GDPR. :)

[JarJak]

Is this project GDPR ready?

[p-vitt]

GDPR is not about software, but about information. Software can't be GDPR ready. Only the use of software can or can not be according to the GDPR. At least that's how I understood the GDPR.

[JarJak]

I mean, does this app display all required informations, commitments and settings for EU user?

[blatinier]

GDPR is about informing users and gather consent in an explicit way. This is the job of the project using isso. The thing we should improve is providing some insight into what and how is stored stuff in isso. If you read previous messages of @p-vitt you have a good draft for a declaration.

I will repeat myself but it's not isso job to show the disclaimer and collect the consent since it's self-hosted and probably your website has more to do with GDPR than only isso (I'm thinking analytics systems, ads, tracking, connected pages, etc…)