Recherche avancée

Sur d’autres sites (5879)

• France rules Google Analytics non-compliant with GDPR

  11 février 2022, par Erin — Privacy

  Breaking news : The French Data Protection Agency, CNIL (Commission nationale de l’informatique et des libertés), has concluded that the use of Google Analytics is illegal under GDPR. The CNIL has begun issuing formal notices to website managers using Google Analytics.

  This follows the January 2022 Austrian Data Protection Authority’s decision to declare Google Analytics illegal to use under GDPR.

  Google Analytics GDPR breaches continue to spread through the EU

  Since the invalidation of the Privacy Shield framework, an agreement between the EU and US that allowed the transfer of data to certified US companies, the CNIL and other EU data protection authorities have received numerous complaints regarding data transfers collected during visits to websites using Google Analytics.

  "It’s interesting to see that the different European Data Protection Authorities all come to the same conclusion : the use of Google Analytics is illegal. There is a European task force and we assume that this action is coordinated and other authorities will decide similarly."

  About the CNIL’s decision

  In this model case, the CNIL has found that an unnamed website’s use of Google Analytics is non-compliant with GDPR because it had breached Article 44 which prohibits the transfer of personal data beyond the EU, unless the recipient country can prove adequate data protection. 

  Under the GDPR, personal data covers a range of identifiers including email address, race, gender, phone number to name a few, but the less obvious identifiers include IP addresses or cookie IDs, for instance. 

  The CNIL’s decision was based on the fact that the US does not meet GDPR sufficient levels of data protection as a result of US surveillance laws. Therefore, the unnamed website’s use of Google Analytics created risks for their website visitors when their personal data was exported to the US. 

  At the time of writing, it is unknown if the CNIL has issued a fine for the GDPR breach. However, the website manager of the unnamed website has been ordered by the CNIL to comply with the GDPR and, if necessary, stop using Google Analytics under the current conditions.

  "One thing we’re certain of is that these decisions will continue to roll out throughout the EU and potentially beyond.

  Other countries are imposing their own privacy regulations that closely mirror the GDPR like Brazil’s General Data Protection Law (LGPD), India’s Data Protection Bill, New Zealand’s Privacy Act and Canada’s Personal Information Protection and Electronic Documents Act (PIPEDA) to name a few.”

  The CNIL offers an evaluation programme to help website managers determine whether web analytics solutions are exempt from collecting data prior to users’ agreement to opt-in through consent screens. Matomo, for instance, is a leading Google Analytics alternative that has been recommended by CNIL and is exempt from tracking consent. 

  

  English translation : “This is why I anticipated this announcement, gradually moving the analytics of my sites to @matomo_org since several weeks !

  “The @CNIL believes that the use of @googleanalytics is a violation of #GDPR”

  Immediate action required for Google Analytics users

  The CNIL and other EU-based data protection authorities have made their stance on Google Analytics clear and inaction will likely result in fines, which under the GDPR, can be up to €20 million or 4% of the organisation’s global turnover – whichever is higher.

  Based on the CNIL’s formal notice to the model case’s website manager, Google Analytics users should take immediate action to remove any chances of personal data being transferred to the US or find a Google Analytics alternative that is GDPR compliant. 

  

  English translation : “The CNIL considers that the use of Google Analytics is a violation of the GDPR. I use @matomo_org and I welcome it *winking face* It will squeal tires among growthackers who are slaughtering. Opportunity to look at alternative tools”

  Ready to begin your journey to GDPR compliance with Matomo ? Start your 21-day free trial now (no credit card required) and take advantage of our Google Analytics importer so you don’t lose any of your historical data. 

  Try 21-day free Cloud trial

  What does this mean for Matomo users ?

  As the GDPR continues to evolve, our users can rest assured that Matomo will be at the forefront of these changes. With Matomo Cloud, all data is stored in the EU or in your country of choice when you self-host on your own servers with Matomo On-Premise.

  Conclusion

  Google is in the EU’s crosshairs and organisations that continue to use their tools will be the one’s left to clean up the mess – not Google. Now is the time to act. Search for a Google Analytics alternative and close your compliance gaps today. 

  Join over 1 million other websites using Matomo now. Give Matomo a try with a 21-day free trial – no credit card required. 

  Try 21-day free Cloud trial

  We’d like to also bring attention to the privacy-fighting efforts from noyb and Max Schrems, as this should not go unnoticed. noyb is an independent, non-profit organisation that relies on the support of individuals. Support privacy by supporting noyb – donate or become a member now. 

  Contact details for media :

  For quotes or interviews, please email marketing@matomo.org

• Long Overdue MediaWiki Upgrade

  5 février 2014, par Multimedia Mike — General

  What do I do ? What I do ? This library book is 42 years overdue !
  I admit that it’s mine, yet I can’t pay the fine,
  Should I turn it in or should I hide it again ?
  What do I do ? What do I do ?

  I internalized the forgoing paean to the perils of procrastination by Shel Silverstein in my formative years. It’s probably why I’ve never paid a single cent in late fees in my entire life.

  However, I have been woefully negligent as the steward of the MediaWiki software that drives the world famous MultimediaWiki, the internet’s central repository of obscure technical knowledge related to multimedia. It is currently running of version 1.6 software. The latest version is 1.22.

  The Story So Far
  According to my records, I first set up the wiki late in 2005. I don’t know which MediaWiki release I was using at the time. I probably conducted a few upgrades in the early days, but that went by the wayside perhaps in 2007. My web host stopped allowing shell access and the MediaWiki upgrade process pretty much requires running a PHP script from a command line. Upgrade time came around and I put off the project. Weeks turned into months turned into years until, according to some notes, the wiki abruptly stopped working in July, 2011. Suddenly, there were PHP errors about “Namespace” being a reserved word.

  While I finally laid out a plan to upgrade the wiki after all these years, I eventually found that the problem had been caused when my webhost upgraded from PHP 5.2 -> 5.3. I also learned of a small number of code changes that caused the problem to go away, thus kicking the can down the road once more.

  Then a new problem showed up last week. I think it might be related to a new version of PHP again. This time, a few other things on my site broke, and I learned that my webhost now allows me to select a PHP version to use (with the version then set to “auto”, which didn’t yield much information). Rolling back to an earlier version of PHP might have solved the problem easily.

  But NO ! I made the determination that this goes no further. I want this wiki upgraded.

  The Arduous Upgrade Path
  There are 2 general upgrade paths I can think of :
  

  1. Upgrade in place on the server
  2. Upgrade offline and put the site back on the server

  Approach #1 is problematic since I don’t have direct shell access, though I considered using something like PHP Shell. Approach #2 involves getting the entire set of wiki files and a backup of the MySQL tables. This is workable since I keep automated backups of these items anyway.

  In fairly short order, I was able to set up a working copy of the MultimediaWiki hosted on a local Linux machine. Now what’s the move ? The MediaWiki software I’m running is 1.6.10. The very latest, as of this upgrade project is 1.22.2. I suppose it’s way too much to hope that the software will upgrade cleanly from 1.6.x straight to 1.22.x, but I guess it’s worth a shot…

  HA ! No chance. Okay, next idea is to march through the various versions and upgrade each in turn. MediaWiki has all their historic releases online, all the way back to the 1.3 lineage. I decided that the latest of each lineage should upgrade cleanly from anything in the previous version of lineage. E.g., 1.6.10 should upgrade cleanly to 1.7.3 (last in the 1.7 series). This seemed to be a workable strategy. So I downloaded the latest of each series, unpacked, and copied all the wiki files over the working installation and ran ‘php update.php’ in the maintenance/ directory.

  The process is tedious and not without its obstacles. I consider this penance for my years of wiki neglect. First, I run into the “PHP Parse error : syntax error, unexpected T_NAMESPACE, expecting T_STRING” issue, the same that I saw years ago after the webhost transitioned from PHP 5.2 -> 5.3. I could solve this by editing assorted files and changing “Namespace” -> “MWNamespace” (which is what MediaWiki did by version 1.13). But I would prefer not to.

  Instead, I downloaded the source for PHP 5.2 and compiled it in a separate directory, then called ‘/path/to/php/5.2/bin/php update.php’. Problem solved.

  The next problem is that a bunch of the database update scripts are specifying “Type=InnoDB”. This isn’t supported by modern MySQL databases. Now, it’s “Engine=InnoDB”. A quick search & replace at the command line fixes this for 1.6.x… and 1.7.x… and 1.8 through 1.12. Finally, at 1.13, it was no longer necessary. As a bonus, at 1.13, I was able to test the installation since Namespace had been renamed to MWNamespace. I would later learn that the table type modifications probably could have been simplified in by changing “$wgDBmysql4 = true ;” to “$wgDBmysql5 = true ;” somewhere in LocalSettings.php.

  Command line upgrading worked smoothly up through 1.18 series when I got a new syntax error :

  <br />
PHP Fatal error:  Call to a member function addMessages() on a non-object in /mnt/sdb1/archive/wiki/extensions/Cite.php on line 68<br />

  Best I could do was comment out that line. I hope that doesn’t break anything important.

  In the home stretch, the very last transition (1.21 -> 1.22) failed :

  PHP Fatal error :  Cannot redeclare wfProfileIn() (previously declared in 
  /mnt/sdb1/archive/wiki/includes/profiler/Profiler.php:33) in 
  /mnt/sdb1/archive/wiki/includes/ProfilerStub.php on line 25
  

  Apparently, this problem arises occasionally since 1.18. I found a way around it thanks to this page : Deleted the file StartProfiler.php. Who am I to argue ?

  Upon completing the transition to 1.22, the wiki doesn’t look correct– the pictures aren’t showing up. The solution was to fix the temporary directory via LocalSettings.php.

  Back To Production
  Okay, it all works again ! Locally, that is. How to get it back to the server ? My first idea was that, knowing that this upgrade process can succeed, try stepping through the upgrade process again, but tell the update.php scripts to access the database tables on multimedia.cx. This seemed to be working for awhile, even though the database update phase often took 4-5 minutes. However, the transition from 1.8.5 -> 1.9.6 took 75 minutes and then timed out. According to my notes, “This isn’t going to work.”

  The new process :

  1. Dump the database tables from the local database.
  2. Create a new database remotely (melanson_wiki_ng).
  3. Dump the database table into melanson_wiki_ng.
  4. Move the index.php file out of the wiki files directory temporarily (or rename).
  5. Modify the LocalSettings.php to talk to the new database.
  6. Perform a lftp mirror operation in order to send all the files up to the server.
  7. Send the index.php file and hope beyond hope that everything magically works.

  And that’s the story of how the updated MultimediaWiki came back online. Despite the database dump file being over 110 MB, it only tool MySQL 1m45s to transmit it all to the remote server (let’s hear it for the ‘–compress’ option). For comparison, inserting the tables back into a fresh local database took 1m07s.

  When the MultimediaWiki was first live again, it loaded, but ever so slowly. This is when I finally looked into optimization and found that I was lacking any caching. So as a bonus, the MultimediaWiki should be much faster now.

  Going Forward
  For all I know, I did everything described here in the hardest way possible. But at least I got it done. Unless I learn of a better process, future upgrades will probably look similar to this.

  Additionally, I should probably take some time to figure out what new features are part of the standard MediaWiki distribution nowadays.

• Revision 3265 : On passe un nouvel argument possible au formulaire permettant de lui ...

  18 avril 2010, par kent1 — Log

  On passe un nouvel argument possible au formulaire permettant de lui indiquer directement quel est le tri actuel Dans le cas d’une page recherche, on ajoute un critère de tri qui est points (pertinence)