Category: Legislative Compliance

I just reviewed Canadas anti-spam legislation & it looks like we're currently not complying with it.

http://fightspam.gc.ca/eic/site/030.nsf/eng/00285.html

# Express consent (rules for implied consent are too difficult to satisfy)
# Name of the Sender
# Address of the Sender.
# A way of getting in touch with the sender. (phone number, domain name, email address) For us, a simple domain name would be ideal.
# Easy unsubscribe mechanism.

I just reviewed an email I received from a user watch at dev.tiki.org. We comply with (maybe) #1. 2-5 we do not comply on.

A lot hinges on if the emails we send out are considered "Commercial Electronic Messages" but we don't appear to fall in the exception list, so I'm guessing that means almost all our messages are considered CES, including watches.

There is implied and also explicit consent. It looks like most of our emails are explicit concent emails, so that makes things easier. However if no specific action was taken to request an email, it falls in "implied consent" and there is a 2-year limitation on this clause. That would be a lot of work to program, so I suggest that we place a line in our Terms and Conditions that states that we may send occasional emails, and require them to agree to these upon registration. This would seem to cover our basis in making a strong case for explicit consent. The onus is upon us to prove that explicit consent has been granted. The empty toggle box concent is mentioned as "acceptable" under these regulations.

Now that we have explicit consent (and can prove it) we need to comply with the required information in an email. For Tiki already has the name and domain name, but perhaps we need a field for the business address in the preferences somewhere.

We also need an "easy unsubscribe mechanism" so if someone creates a "user watch" we need to include a link to an unsubscribe page. Or a page that unsubscribes them. I'm sure we already have this within tiki, we just need to generate the link and include it in user watches, and other emails.

It would also be nice if we had some generic compliance built into Tiki. So the solution taken is not specific to *.tiki.org and everyone else needs to come up with there own solution. More and more legislation is playing a larger role in how business on the net is conducted.

I would love to see a generic feature in Tiki called something like Terms, Conditions & Privacy Policy. Where terms, conditions and privacy policy can be (almost) auto generated based on selected options. This then could be integrated into the user registration form as part of the standard process.

A German court has ruled that websites that utilize Google fonts possibly violate the GDPR, and the owner of such a site is liable for that.

At first look, this sounds over the edge, but when looking deeper, the court's legal findings are stringent. If a website loads Google fonts, it makes the browser of users load the fonts from Google, thereby compromising personal data to Google.

If the user in question did not agree to this disclosure of personal data to Google (and the site owner can prove that), than it is a clear violation of the GDPR. The user then doesn't know about this disclosure of data, and cannot do anything to prevent this.

Therefore it is advisable that all demo Tiki stuff, including themes, be either stripped of Google fonts, or the fonts should be loaded directly from the site, or the users of such themes be told that the unaltered use of these themes comprises a GDPR violation, which can be fined (for companies) with up to 20 million Euro or 4% of a year's turnover (not profit!), whichever is higher...

The cookie consent mechanism has this bold claim:

__"Complies with EU Privacy and Electronic Communications Regulations."__

First of all, let me express my thanks that someone has undertaken the task of creating a feature that at least tries to adhere to laws and regulations. Many IT systems do not even have that.

But the bold claim is only partially fulfilled. You ''can'' make cookie consent compliant with regulations, but it does not tell you how. And some defaults are ''not'' compliant.

To elaborate:
There is an option "Cookie consent disabled" with description
"Do not give the option to refuse cookies but still inform the user about cookie usage.". Enabling this would be a clear breach of regulations. In the European Union every user must be given the right to deny setting cookies. Luckily this one is default off.

This also implies that the setting "Cookie consent alert" with description "Sorry, cookie consent required" and hint "Alert displayed when user tries to access or use a feature requiring cookies." is non-compliant. The user has a right to refuse, and you cannot block his/her access upon that. It is okay if functionality is reduced (like remembering sessions), but you cannot block access.

There is a "Cookie consent question", "Specific question next to the checkbox for agreement. Leave empty to not display a checkbox." with this default text: "I accept cookies from this site.". That's not a question, that's an answer :-)

"Specific question next to the checkbox for agreement. Leave empty to not display a checkbox." Hm, no checkbox? Ask a clear question, one that users can answer binary "Yes" or "No".

The default label for consent is "Continue", which is not compliant. The label must clearly tell an medium level informed user what it does. Therefore it cannot be labelled "Continue". It can be changed, but this is the default.

Also, any kind of consent checkbox must not be preset!

So, I see the spirit of the devs to help admins be compliant, but this needs some brushing up to really enable admins to be on the right side of the law :-)

I see that for some areas outside the EU one might want to be less adherent to EU laws and therefore might want to force users to accept cookies. But a GUI of a function that claims compliance should not encourage that. So either claim this and offer only compliant options or display advice or even alerts when admins click on settings that would make them breach compliance... Or have one checkbox "compliant settings only" or something like that.

Also, inform admins that by law, site admins must inform their users about what kind of personal data is stored, where it is stored, and for how long. Commercial sites must also tell which persons are to be contacted if users want to get a copy of all that data, or who is to be contacted is someone wants that deleted.

Trackers are the de facto way Tiki treats data collected from users. These are personal data that directly fall under ''__many__'' legislative and other regulations. Primarily the EU GDPR, but -here- more importantly under the PCI, if they contain credit card or other payment data like bank account numbers.

Under PCI DSS credit card data must not be kept in the same database as personal data. They must be separated on all levels of processing, from technical to organizational. They cannot be processed under group logins, logins to systems carrying card data must use personalized login accounts etc. et. al.

There is one problem with trackers here: To my knowledge all trackers are kept in one DB, which is the DB the Tiki runs from. In order to comply with PCI DSS it will be necessary to have trackers with card data in a separate DB...

https://www.pcisecuritystandards.org/

Thanks
hman

Currently, German legislature is pondering the implementation of the dreaded article 17 (formerly Article 13) of the EU Copyright Directive into German law. Similar implementations must be under way in all member states.

This Article demands that "platform providers" (as general as this term sounds, this means everyone from Youtube down to a privately run Tiki installation) MUST provide online upload filtering of media that could possibly be copyrighted, which translates into "ALL media" AND a "red button" with which copyright holders are enabled to immediately (!) block content they find and deem infringes their held copyrights.

As the IT magazine "c't" informes, the proposed "German copyright service providers law" describes several stages that user uploaded media MUST go through before they may go online.

Platforms shall sign contracts with copyright organizations such as GEMA (for music) etc. Licensed content may go online directly. Other content will have to undergo online filtering. Depending on filtering results, content may be blocked or the copyright owner may be directly informed of the suspected infringement.

It has been speculated previously, that only VERY large companies like Youtube (Google) will at all be (technically) able to run such filter services, looking at the sheer amount of computing power and I/O bandwidth necessary. Youtube and Co could offer filter services for smaller platforms that lack the ressources, but possibly not free of charge. This has been critized as giving Youtube and Co. huge power and wide control over the internet, given the fact that technically there is no difference between filtering for copyright infringement and filtering for unwanted political content, in other words: Once installed, such filters could easily be used for censorship of the internet. This led to mass protest by young people all over Europe. The ruling conservative party promised angry voters that the implementation of the EU directive would not implement upload filtering, but apparently they broke their promise.

According to the government, filters SHALL be set to "mildly" filter, enabling the majority of content to go online, but mechanisms must be implemented for copyright owners to protest, as well as a "red button" with an immediate (!) takedown effect.

We upgraded to Font Awesome 5.x:
https://sourceforge.net/p/tikiwiki/code/67552

Please see:
https://github.com/syncthing/syncthing/issues/5236

TikiWiki stores personal data about it's users. Besides (!) the GDPR issues, there ia a VERY vulnerable situation for Tiki site admins:

The user preferences only know these three settings:
Male
Female
Hidden

According to a ruling of Germany's supreme court from last year, that constitutes discrimination, and entitles every user to sue the administrator (and win).

The German supreme court has ruled, that the law that defines the standards of record keeping by the government collides with the German constitution and therefore MUST be changed, so that every German citizen may be either
Male
Female
Diverse

Diverse is a bracket that includes all of the LGBT etc. in one label. This means that if any German citizen so chooses, he or she will be issued a new ID card or passport, where D will be written under gender.

If someone operating an IT system that forces users to enter either M or F, and does not have a selection D, this constitutes discrimination, and entitles the discriminated person to sue. And winning the suit would be a piece of cake.

Now the question arises "is this relevant"? People can choose "hide". Yes. Well, if a citizen opts to change his or her official record (they have to officially file a request to do so) in the German administration and request to get new ID card or passport, how likely will it be that such a person does not care if an IT system forces him or her to be labelled M or F? Highly unlikely, I think.

So to protect TikiWiki admins, you should as soon as possible introduce Diverse as third gender. And in the long run, because other countries supreme courts might not choose "diverse" as a bracket and include the full LGBT etc. list, gender should become a configurable and expandable entity. The number of legally correct gender entries may vary from country to country, so do not stick to 2 or 3...

Thanks
Hman
And just before anyone asks this: It's not about me. I do not need a D in the database, but I want my users to make such a choice for themselves (and be protected if anyone might want to make a case on this).

P.S: I believe there is no need to demo this, it's plain to see that TikiWiki only knows M, F and hidden.

{syntax type="tiki" editor="plain"}
For anything that is not related to a user-caused physical motion (ex: dragging, swiping, gesturing, etc.), this operating system accessibility setting should be honored to disable any animation that is purely cosmetic.

https://dev.tiki.org/Bootstrap-4-to-5-Migration-Checklist is the only page that has any mention of "prefers-reduced-motion", but if the Tiki.org front page (and other pages / sites I've seen) is any indication, this is not actually implemented throughout Tiki for non-essential animations.

---

References:

* https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion
* https://webkit.org/blog-files/prefers-reduced-motion/prm.htm
* https://web.dev/prefers-reduced-motion/

https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Using_Media_Queries_for_Accessibility also says:

> this method of switching animation off according to the user's preference can also benefit users with low battery or low-end phones or computers.

I noticed in our -+vendor_bundled/composer.lock+- that some packages slipped in which are GPL or Apache licensed only (not compatible with LGPL), which might be a release blocker for us, namely:
* https://github.com/h5p/h5p-php-library
* https://github.com/h5p/h5p-editor-php-library (Although it claims MIT the https://github.com/h5p/h5p-editor-php-library/blob/master/composer.json says GPL only)
* https://github.com/BafS/Testify.php (license mentioned in https://github.com/BafS/Testify.php/blob/master/composer.json)
* https://github.com/farbelous/bootstrap-colorpicker (Apache 2.0)
* https://github.com/apereo/phpCAS (Apache 2.0)
* https://github.com/zetacomponents/Webdav (Apache 2.0)
* https://github.com/zetacomponents/Base (Apache 2.0)
* https://github.com/ahand/mobileesp (Apache 2.0)
+ {QUOTE(source_url=https://opensource.stackexchange.com/questions/5664/linking-from-lgpl-2-1-software-to-apache-2-0-library)}The incompatibility of Apache-2 and GPL-2 is well documented. If your software is a combined/derivate work with/of Apache-2 software, you cannot license that software under the GPL-2 and therefore cannot license it under the LGPL-2.1 either.{QUOTE}
* https://github.com/conversejs/converse.js (MPL 2.0) (not quite sure about this one but [https://dwheeler.com/essays/floss-license-slide.html|the diagram] does not indicate it is compatible with LGPL 2.1)
* https://github.com/kaltura/KalturaGeneratedAPIClientsPHP53 (AGPL 3.0)
* https://github.com/PHPCompatibility/PHPCompatibility (LGPL 3.0+ - not sure it can be included in LGPL 2.1)


{DIV(class=lead)}For more details see https://tiki.org/License{DIV}

{syntax type="tiki" editor="plain"}
Tiki has the option to interact with Google Analytics.

Now the first court rulings are there: Google Analytics directly violate the GDPR, therefore they are illegal throughout the EU. Fines are VERY heavy, so this must not be taken lightly. The fines range up to 20 million Euro or 4 percent of a year's turnover (sic! Not profit!), whichever is HIGHER.

Yes, Analytics is optional, and it's the decision of an admin, correct.

But IMHO Tiki should inform the admin when he/she activates this, that compliance with current law must be observed, and that Analytics can be (very) problematic in this regard. And to be on the very safe side, IMHO there should be a checkbox that spells out as confirmation "Yes, I am aware of the compliance issues imposed by this".

Since upgrading from LTS18.7 to 18.8, we are now unable to remove specific versions of a wiki page.
So whilst we can edit a page to hide profanity, obsenity and the like, we can not physically remove that version of the page.

This might also mean a site would be unable to fully comply with a "right to be forgotten" style request.

As an admin or suitably privildges user, go to page history, add tick in box for the version to be deleted. Then from the drop down menu at the foot of the page select Remove and click on the OK button.

The "Please confirm" pop up is shown and then click on Delete button.

The Error message "No version were selected. Please select one or more versions" is shown at the top of the History screen. The screen shows a selection tick against the version it's just failed to delete.

This bug seems closely related to at least two other recently filed bugs ....
[https://dev.tiki.org/item8065-Wiki-pages-cannot-be-deleted] and
[https://dev.tiki.org/item8128--No-users-were-selected-error]

{syntax type="tiki" editor="plain"}
On May 12, the US President issued an Executive Order that binds US agencies that software purchased needs a Software Bill of Materials (SBOM).

[https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/|Executive Order on Improving the Nation’s Cybersecurity]

A SBOM is a comprehensive (!) list of ALL dependencies. You have to list every (!) module, tool, library, whatever that Tiki relies on in a predefined, machine readable format. If you do not provide a SBOM, no US agency or office will be allowed to use Tiki.

The reasoning behind that is simple and clear: Unknown dependencies cause unknown cyber risks. As they are unknown, the impact of those can range from negligible to catastrophic. All dependencies must be tracked. If software that Tiki depends on does not get updated, features might break, or even worse, impose direct security threats through Zero Day exploits. Oh well, looking at some popular tool's outdated version history, you might not even need "0days" to break into other vendor's software, where the user (or admin) might not even be aware of the dependency. Or the depency of some other dependency.

Log4j was the last warning to the industry (and in this regard, Tiki must be considered to be part of the industry).

The machine readable format of SBOM makes it possible to discover the depencies of the dependencies. Nestings of a dozen or more levels are not uncommon...

Now the president took action. Tiki should react, IMHO. Tiki must react, or Tiki won't be usable by officials anymore.