Advanced search

On other websites (6185)

• The new GDPR data protection regulation and potential consequences on Piwik

  7 September 2017, by Piwik Core Team — About, Privacy

  GDPR is a new data protection related regulation in Europe. GDPR stands for General Data Protection Regulation.

  The purpose of this European regulation is to strengthen and unify data protection for all individuals within the European Union. This also includes entities outside Europe willing to do business with European citizens. GDPR is a set of processes you need to follow within your organization to protect the privacy of European citizens.

  GDPR will start to apply in May 2018. It is recognized to be dissuasive because of the potential penalty of up to 4% of the yearly turnover, in case of infringement.

  Many articles have been written about GDPR including our previous article. Few of them are explaining how it will affect web analytics vendors: this is what this article is about.

  Am I really impacted by GDPR if I am a Piwik user?

  As Piwik can collect personal data, the answer is yes. Piwik analytics data is impacted by the GDPR.

  As GDPR is a general concept, we decided from the official guidelines to assume what will be the potential consequences on the use of Piwik.

  There are 2 potential scenarios we can identify:

  • 1 – You are collecting personal data with Piwik
  • 2 – You are not collecting personal data with Piwik

  1 – Personal data collection with Piwik

  According to GDPR: IP addresses, cookies, UserID are personal data.

  IP addresses are personal data, so you will have to anonymize them unless you receive explicit consent from the visitor. Please view the following article in order to learn: how can I anonymize IP addresses in Piwik?

  According to GDPR, cookies are personal data too. But as all cookies are not created equal it may be possible that some need to require user consent whereas other not. Whatever will be the final decision, you can learn about the first-party cookies created by Piwik and how to disable all tracking cookies in Piwik?

  User ID, you are impacted if the User ID you assign is specific to an individual or if you can cross the User ID data further and find back the individual personal data.

  Any extra personal data you may collect with Piwik, it could be for example: first names, family names, e-mail address… You are able to collect such data using custom dimensions, custom variables…

  What are the rules I have to comply with?

  By collecting personal data, you will have to respect EU citizens rights, which include:

  • The possibility for them to view the data you collected on them
  • The possibility to rectify some data concerning them
  • The possibility to delete their data when they request about it

  As you can imagine, for the first obligation, you will have to export all the data. So if a user is requesting it, you will have to export the data linked to his IP address(es). It can be easily exported as a .csv file for example.
  In order to do that, just create a segment according to the IP address of the user who requested it and then export the “Visitor log” report.
  If the personal data is not linked with the IP address but other attributes such as User ID or a custom dimension, you can provide the same data export by using the segment function and filtering on the personal data field.

  The data edit and deletion process on Piwik is a bit trickier as it currently requires administration system skills. We are planning to develop a new plugin for GDPR compliance (which will be available for free on the Marketplace). This plugin will let you edit and easily delete data of a particular user. Currently you can delete a specific user’s data by accessing the Piwik database and directly delete the different records for this specific user.

  2 – You are not collecting personal data with Piwik

  Unfortunately it is not because you do not collect personal data that you will not be affected by GDPR.
  The details of GDPR are not confirmed yet and GDPR could involve enabling the DoNotTrack setting by default on all browsers.
  Yes, you read it well, by default, unless the internet user uncheck this option, Piwik respecting DoNoTrack would not be able to track any user. If one needed to collect data anyway, Piwik Log Analytics and server-side tracking can be considered.

  If you need help regarding how to set up your Piwik installation in order to be GDPR compliant:

  Contact us

  Do you have a Piwik experience you would like to share with the community? Please share it with us by contacting Piwik core team.

• Google’s YouTube Uses FFmpeg

  9 February 2011, by Multimedia Mike — General

  Controversy arose last week when Google accused Microsoft of stealing search engine results for their Bing search engine. It was a pretty novel sting operation and Google did a good job of visually illustrating their side of the story on their official blog.

  This reminds me of the fact that Google’s YouTube video hosting site uses FFmpeg for converting videos. Not that this is in the same league as the search engine shenanigans (it’s perfectly legit to use FFmpeg in this capacity, but to my knowledge, Google/YouTube has never confirmed FFmpeg usage), but I thought I would revisit this item and illustrate it with screenshots. This is not new information— I first empirically tested this fact 4 years ago. However, a lot of people wonder how exactly I can identify FFmpeg on the backend when I claim that I’ve written code that helps power YouTube.

  Short Answer
  How do I know YouTube uses FFmpeg to convert multimedia? Because:

  1. FFmpeg can decode a number of impossibly obscure multimedia formats using code I wrote
  2. YouTube can transcode many of the same formats
  3. I screwed up when I wrote the code to support some of these weird formats
  4. My mistakes are still present when YouTube transcodes certain fringe formats

  Longer Answer (With Pictures!)
  Let’s take a video format named RoQ, developed by noted game designer Graeme Devine. Originated for use in the FMV-heavy game The 11th Hour, the format eventually found its way into the Quake 3 engine as well as many games derived from the same technology.

  Dr. Tim Ferguson reverse engineered the format (though it would later be open sourced along with the rest of the Q3 engine). I wrote a RoQ playback system for FFmpeg, and I messed up in doing so. I believe my coding error helps demonstrate the case I’m trying to make here.

  Observe what happened when I pushed the jk02.roq sample through YouTube in my original experiment 4 years ago:

  
  
  

  Do you see how the canyon walls bleed into the sky? That’s not supposed to happen. FFmpeg doesn’t do that anymore but I was able to go back into the source code history to find when it did do that:

  
  
  

  Academic Answer
  FFmpeg fixed this bug in June of 2007 (thanks to Eric Lasota). The problem had to do with premature colorspace conversion in my original decoder.

  Leftovers
  I tried uploading the video again to see if the problem persists in YouTube’s transcoder. First bit of trivia: YouTube detects when you have uploaded the same video twice and rejects the subsequent attempts. So I created a double concatenation of the video and uploaded it. The problem is gone, illustrating that the backend is actually using a newer version of FFmpeg. This surprises me for somewhat esoteric reasons.

  Here’s another interesting bit of trivia for those who don’t do a lot of YouTube uploading— YouTube reports format details when you upload a video:

  
  
  

  So, yep, RoQ format. And you can wager that this will prompt me to go back through the litany of unusual formats that FFmpeg supports to see how YouTube responds.

• How to port signal() to sigaction()?

  28 September 2016, by Shark

  due to recent problems discovered with NDK12 and NDK13b2, i’m thinking of ’porting’ libx264’s use of signal() (and missing bsd_signal() in ndk12) to use sigaction() instead.

  The problem is, I’m not quite sure what’s the simple&fastest way to replace signal() calls with sigaction() ones.

  For all i see, it’s mainly used in x264-snapshot/common/cpu.c in the following manner:

  using the following signal handler:

  static void sigill_handler( int sig )
  
  {
  
      if( !canjump )
  
      {
  
          signal( sig, SIG_DFL );
  
          raise( sig );
  
      }
  
  
  
      canjump = 0;
  
      siglongjmp( jmpbuf, 1 );
  
  }

  This is the problematic x264_cpu_detect function... currently, i’m guessing i only need to tackle the ARM version, but i’;; still have to replace all occurances of signal() with sigaction() so i might just cover both of them to get the thing building...

  FYI - the NDK13 beta2 still has "unstable" libc and the build doesn’t fail on this part, but rather the first invocation of the rand() function somewhere else... So i’m out of luck and replacing the signal() calls might be better than just waiting for the official NDK13 release. I’m doing this to get rid of text-relocations so i can run the library (and doubango) on API 24 (Android N)

  the problematic part of function that invokes signal():

  #elif SYS_LINUX
  
  
  
  uint32_t x264_cpu_detect( void )
  
  {
  
      static void (*oldsig)( int );
  
  
  
      oldsig = signal( SIGILL, sigill_handler );
  
      if( sigsetjmp( jmpbuf, 1 ) )
  
      {
  
          signal( SIGILL, oldsig );
  
          return 0;
  
      }
  
  
  
      canjump = 1;
  
      asm volatile( "mtspr 256, %0\n\t"
  
                    "vand 0, 0, 0\n\t"
  
                    :
  
                    : "r"(-1) );
  
      canjump = 0;
  
  
  
      signal( SIGILL, oldsig );
  
  
  
      return X264_CPU_ALTIVEC;
  
  }
  
  #endif
  
  
  
  #elif ARCH_ARM
  
  
  
  void x264_cpu_neon_test( void );
  
  int x264_cpu_fast_neon_mrc_test( void );
  
  
  
  uint32_t x264_cpu_detect( void )
  
  {
  
      int flags = 0;
  
  #if HAVE_ARMV6
  
      flags |= X264_CPU_ARMV6;
  
  
  
      // don't do this hack if compiled with -mfpu=neon
  
  #if !HAVE_NEON
  
      static void (* oldsig)( int );
  
      oldsig = signal( SIGILL, sigill_handler );
  
      if( sigsetjmp( jmpbuf, 1 ) )
  
      {
  
          signal( SIGILL, oldsig );
  
          return flags;
  
      }
  
  
  
      canjump = 1;
  
      x264_cpu_neon_test();
  
      canjump = 0;
  
      signal( SIGILL, oldsig );
  
  #endif
  
  
  
      flags |= X264_CPU_NEON;
  
  
  
      // fast neon -> arm (Cortex-A9) detection relies on user access to the
  
      // cycle counter; this assumes ARMv7 performance counters.
  
      // NEON requires at least ARMv7, ARMv8 may require changes here, but
  
      // hopefully this hacky detection method will have been replaced by then.
  
      // Note that there is potential for a race condition if another program or
  
      // x264 instance disables or reinits the counters while x264 is using them,
  
      // which may result in incorrect detection and the counters stuck enabled.
  
      // right now Apple does not seem to support performance counters for this test
  
  #ifndef __MACH__
  
      flags |= x264_cpu_fast_neon_mrc_test() ? X264_CPU_FAST_NEON_MRC : 0;
  
  #endif
  
      // TODO: write dual issue test? currently it's A8 (dual issue) vs. A9 (fast      mrc)
  
  #endif
  
      return flags;
  
  }
  
  
  
  #else
  
  
  
  uint32_t x264_cpu_detect( void )
  
  {
  
      return 0;
  
  }

  So the question is really this: what would be the quickest/easiest//fastest way to replace the signal() calls with sigaction() ones while preserving the current functionality?

  EDIT:
  The reason i’m trying to get rid of signal() are these build errors:

  /home/devshark/SCRATCH/doubango/thirdparties/android/armv5te/lib/dist/libx264.a(cpu.o):cpu.c:function sigill_handler: error: undefined reference to 'bsd_signal'
  
  
  
  /home/devshark/SCRATCH/doubango/thirdparties/android/armv5te/lib/dist/libx264.a(cpu.o):cpu.c:function x264_cpu_detect: error: undefined reference to 'bsd_signal'
  
  /home/devshark/SCRATCH/doubango/thirdparties/android/armv5te/lib/dist/libx264.a(cpu.o):cpu.c:function x264_cpu_detect: error: undefined reference to 'bsd_signal'
  
  
  
  /home/devshark/SCRATCH/doubango/thirdparties/android/armv5te/lib/dist/libx264.a(cpu.o):cpu.c:function x264_cpu_detect: error: undefined reference to 'bsd_signal'

  I already know that this is a known NDK12 problem, that might be solved by bringing bsd_signal back to the libc in NDK13. However, in it’ beta state with it’s unstable libc - it’s currently missing the rand() function and simply waiting for it might not do the trick. But in the worst-case scenario, i guess i’ll just have to wait for it and retry after it’s release.

  But as it currently is, the prebuilt version of the library i want to use has text-relocations and is being rejected by phones running newer API / version of the android OS.

  EDIT2:
  I also know that signal() usually works by using sigaction() under the hood, but maybe i won’t get bsd_signal related build-errors... since i’m suspecting that this one isn’t using it. It’s obviously using bsd_signal, which may or may not be the same underlying thing :/