GDPR Avoidance

From MgmtWiki
Revision as of 13:01, 19 August 2020 by Tom (talk | contribs) (Other examples)

Jump to: navigation, search

Full Title

The GDPR is well-stocked with 40 different avoidance techniques.

The Indictment

  • Lawyers that charge client over $500 per hour have been at work first filling the GDPR with exemptions and now are teaching companies how to exercise those exceptions.
  • The net results of these legal efforts is that the [[GDPR_is_a_scam#The_GDPR_was_never_meant_to_apply_to_EU_Governments_or_Businesses| GDRP was enver meant to apply to EU Governments or Businesses].
  • This is not an indictment about legal activity as the lawyers have assurance that their exemptions are legal, but against the perversion of what appears to be a consumer friendly law that does not meet it objectives.

An Example

This example will show how one standard has been created with the sole purpose of skirting the GDPR law. It does this by claiming that its goal is to help companies reduce the cost of complying with money-laundering legislation. Since support for efforts to reduce international crimes like drugs or pedophilia has a high level of support, any effort to achieve those objectives should be a good idea. So, the OpenID Connect for Identity Assurance 1.0 specification[1] was created to allow the German banks want to right to send all of your credential information from driver's licenses and passport to their customers.

This analysis of the OpenID spec is comparing it to the prescriptions and proscriptions of the GDPR itself. It does not consider the exceptions. If you want an exception so that you can continue doing whatever it is that you do, hire an expensive lawyer. She will be happy to provide an opinion that the spirit and letter of the GDPR do not apply to you. The biggest exception is Article 1, paragraph 3 (A1P3) which allows free flow of data within the EU after it is first collected. So we focus on the first collection of data, which seems to be the only place the user has any control at all. First will skip over the 173 "whereas" clauses, which also prevent the implementation of the OCIA terms and go straight to the articles.

Data Minimization (A5P1d) - "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed (‘data minimisation’)" The issue for OCIA is "limited to what is necessary" there is no case made that the data collected in OCIA meets this restriction. Just because a bank claims that data is necessary does not make it so. It should be recognized that there is a long tradition of using personal attributes to determine assurance which is documented in NSIT 800-63 version one. The point is that alternate methods exist and were offered to the OCIA developers, but it was rejected because that "is not the way we do things". It should also be noted that the inadequacy of this clause was rectified in the California Legislation that would require a data processor to let the user know what data was required and what was desired, but not required. This capability has been built into OIDC from the time of OAUTH in the tags that could be included in the request for data. The lack of concern for this clause was made starkly evident by the exclusion of that feature from AuthXYZ. The author of that spec eliminated it because "it was never used, the request always claimed all data was required."

Other examples

There us plenty of evidence that the GDPR is nothing more than an effort to extract money from successful Silicon Valley companies. See the following stories:

  1. The EU Parliament voted to collect all residents biometrics data into a single data base.[2]
    1. The OpenID Foundation, OpenID Connect for Identity Assurance 1.0 (OCIA) https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html
    2. Catalin Cimpanu. EU votes to create gigantic biometrics database. Zero Day (2019-04-22) https://www.zdnet.com/article/eu-votes-to-create-gigantic-biometrics-database/