Extend token API to support flag for personally identifying information

This is very bad... Am I the only person how care about personal data? For now I'm doing this with below code, but this is not save and false positives may occour, too.

We should think about implementing something like a prefix or an info that defines if a value could contain personally identifying information. This becomes more and more an issue and so many people do not follow the data protection rules. Additionally a way to only return tokens *without* personal identifying data in token_tree view.

/**
 * Validate if a string contains forbidden tokens not allowed by privacy rules.
 *
 * @param $token_string
 *   A string with one or more tokens to be validated.
 * @return boolean
 *   TRUE if blacklisted token has been found, otherwise FALSE.
 */
function _googleanalytics_contains_forbidden_token($token_string) {
  // List of strings in tokens with personal identifying information not allowed
  // for privacy reasons. See section 8.1 of the Google Analytics terms of use
  // for more detailed information.
  //
  // This list can never ever be complete. For this reason it tries to use a
  // regex and may kill a few other valid tokens, but it's the only way to
  // protect users as much as possible from admins with illegal ideas.
  //
  // User tokens are not prefixed with colon to catch 'current-user' and 'user'.
  //
  // TODO: If someone have better ideas, share them, please!
  $token_blacklist = array(
    ':author]',
    ':author:edit-url]',
    ':author:url]',
    ':author:path]',
    ':mail]',
    ':name]',
    ':uid]',
    'user:edit-url]',
    'user:url]',
    'user:path]',
  );

  return preg_match('/' . implode('|', array_map('preg_quote', $token_blacklist)) . '/i', $token_string);
}

Well nobody have said he do not care, but for the simple reason that I seems to be the very first asking for this it shows clearly that nobody cared about it - until now :-)

I'm not sure about the design of such a feature. From the placeholder structure it's very difficult to maintain a list. Every module names the variables how it likes and a generic naming that could be catched is not really available. It may also be a good idea to simply rename some placeholders to be generic and maybe prefix them in a way that makes it possible to run a regex on it. Today this is not easy if not impossible.

You are completly wrong!!! A Drupal user account makes an individual personally identifyable (IP, Email, names, timestamps, etc). Additional to this usernames very very often contain real names. You are NOT allowes to push this data to the Google analytics system.

@Dave: Can I get your support for adding a personal-identifying-data = TRUE flag (or any other named flag) to the token info and follow up requirements? If there is no explicit === FALSE we default to TRUE. I hope you can share your ideas so I'm not implementing something that has no chance to get in.

Idea:

• We expect that a module that does not support personal-identifying-data flag contains data that is privacy relevant.
• If a token has personal-identifying-data = FALSE explicitly set, we expect that this token can be used.
• token_tree need to allow filtering for personal-identifying-data = FALSE items
• hook_token_element_validate() and/or token_scan() need to be able to check for this boolean value or token_scan() need to just refuse it as an invalid token.

Example:

  // Current user tokens.
  $info['tokens']['current-user']['ip-address'] = array(
    'name' => t('IP address'),
    'description' => 'The IP address of the current user.',
    'personal-identifying-data' => TRUE,
  );