Project:Adtech

From Wikibase Personal data
Jump to navigation Jump to search

Overall strategy

Philosophy

The right of access is a tool to provide accountability for profiling, beyond challenging consent or legal basis. It is actually complementary.

The right of access allows to probe the entire ecosystem, strategically. Using this strategy requires to blend knowledge of law and technology.

Strategy

  • Ignore the average end user. Focus on investigator, who is a blend of:
    • legal scholar;
    • tech auditor;
    • strategic litigation NGO;
    • educator;
    • data protection authority confidante;
    • journalist (for amplification).

It is a technical and human, but secondary, problem to break the one-brain barrier within civil society -- does require to overcome traditional barriers, like attribution (but Open Science strategies can mitigate).

  • Build up reliable facts separately in the technical and legal domains.
  • Work (hard) to reconcile the two, and refine the reconciliation by iteration.

Key factors

Increase utility of information obtained through SARs in order to further the goals of people here.

  • Knowing flows of data from a technological standpoint (but: limited auditing capacity, we are partly blind);
  • Knowing purposes for each data processing operation, including transfers;
  • Knowing the legal positioning of the services, including over each data transfer (data controller vs data processor);
  • Knowing to whom the user is identifiable, and how (including if more information is provided).

Tactics

  • Classify services, based on business presentations. Enter at each step of the process through access requests.
  • Same service can exist at all scales, attack all of them
  • Filing a SAR is cheap, but takes time. Make it easier (schema.org lobbying, for instance --> Art 40.2.f).
  • Carpet bombing is A-OK, at high frequency (reducing time lag for responses).
  • Makes it easy to comply with access requests (standards, such as openGDPR)

The landscape

  • PREFIX pdio: <https://wiki.personaldata.io/entity/>
    PREFIX pdiot: <https://wiki.personaldata.io/prop/direct/>
    PREFIX pdiop: <https://wiki.personaldata.io/prop/>
    PREFIX pdiops: <https://wiki.personaldata.io/prop/statement/>
    PREFIX pdiopq: <https://wiki.personaldata.io/prop/qualifier/>
    #defaultView:Graph
    SELECT ?item ?itemLabel ?_image WHERE {
      ?item pdiot:P28 pdio:Q370.
      SERVICE wikibase:label {
        bd:serviceParam wikibase:language "en" . 
      }
    OPTIONAL { ?item pdiot:P47 ?_image. }
    }
    LIMIT 100
    

adtech mess (embedded)

 we need ontologies or a glossary
  • PREFIX pdio: <https://wiki.personaldata.io/entity/>
    PREFIX pdiot: <https://wiki.personaldata.io/prop/direct/>
    PREFIX pdiop: <https://wiki.personaldata.io/prop/>
    PREFIX pdiops: <https://wiki.personaldata.io/prop/statement/>
    PREFIX pdiopq: <https://wiki.personaldata.io/prop/qualifier/>
    SELECT ?item ?label ?_image WHERE {
      ?item pdiot:P3 pdio:Q33.
      SERVICE wikibase:label {
        bd:serviceParam wikibase:language "en" . 
        ?item rdfs:label ?label
      }
    OPTIONAL { ?item pdiot:P47 ?_image. }
    }
    LIMIT 100
    

datasets about the adtech ecosystem (embedded)

  • PREFIX pdio: <https://wiki.personaldata.io/entity/>
    PREFIX pdiot: <https://wiki.personaldata.io/prop/direct/>
    PREFIX pdiop: <https://wiki.personaldata.io/prop/>
    PREFIX pdiops: <https://wiki.personaldata.io/prop/statement/>
    PREFIX pdiopq: <https://wiki.personaldata.io/prop/qualifier/>
    SELECT ?item ?label ?_image WHERE {
      ?item pdiot:P3 pdio:Q1588.
      SERVICE wikibase:label {
        bd:serviceParam wikibase:language "en" . 
        ?item rdfs:label ?label
      }
      
    OPTIONAL { ?item pdiot:P47 ?_image. }
    }
    LIMIT 100
    

partners lists (embedded)

  • "historic" Lumascape picture
  • PREFIX pdio: <https://wiki.personaldata.io/entity/>
    PREFIX pdiot: <https://wiki.personaldata.io/prop/direct/>
    PREFIX pdiop: <https://wiki.personaldata.io/prop/>
    PREFIX pdiops: <https://wiki.personaldata.io/prop/statement/>
    PREFIX pdiopq: <https://wiki.personaldata.io/prop/qualifier/>
    #defaultView:Graph
    SELECT  ?object ?objectLabel ?rgb ?subject ?subjectLabel 
    WHERE {
      VALUES (?object ?rgb){
           (pdio:Q110 "FF0000")
           (pdio:Q495 "00FF00")
           (pdio:Q559 "0000FF")
           (pdio:Q153 "333333")
           (pdio:Q491 "888800")  
           (pdio:Q807 "008888")
           (pdio:Q492 "880088")
           (pdio:Q498 "440000")
           (pdio:Q810 "004400")
           (pdio:Q556 "000044")
           (pdio:Q504 "004444")
           (pdio:Q874 "444400")
           (pdio:Q834 "440044")
        }
      VALUES ?predicate {
           pdiot:P3
           pdiot:P28
        } 
      ?subject ?predicate ?object
      SERVICE wikibase:label {
        bd:serviceParam wikibase:language "en" . 
      }
    }
    LIMIT 1000
    

Lumascape-like (embedded)

A prototype

Precise questions

GDPR Article 15 (Q845)-related questions


Tag management

Bidding process

Top-down, bottom-up, maximizing utility

The goal of SARs could be to maximize utility in understanding the ecosystem.

Hence the goal of litigation should be around expanding the reach of SARs, in order to "flatten" the ecosystem.

This has two advantages: better competition, more transparency.

In particular, for every role, there is a possibility of picking a small player with this role, a huge one, or one with dual roles. Each of those situations will lead to different outcomes for the SAR, all valuable.

Scaling effects

Indirect SARs sound complicated and unhelpful. I am not sure: you get a lot of allies in putting pressure on the service providers, who sometimes masquerade as GDPR data processor (Q841). The costs and effects have a completely different scaling factor, and also an impact on the choice of jurisdiction.

GDPR Article 20 (Q846)-related questions

  • All boils down to: what is provided by the data subject?
  • Why do this? Because then we can transfer more easily to researchers to understand better the ecosystem.

GDPR Article 26 (Q842)-related questions

GDPR Article 26 (Q842) gives the right to information about the "essence of the contract" in joint-controller situations. What does this cover?

Adtech experiments

Consents

Consents are interesting data points, that should be within the scope of Access and (it seems) Portability.

Privacy Shield

Tremendous tool for choosing jurisdiction, at no cost.

Involves Europeans, but also Americans, whose data goes abroad. Drives a wedge between Facebook Ireland and Facebook Inc, etc.

Facebook's Replacement IDs

Crucial in the context of WhatsApp/Messenger/Instagram merger.

Facebook implements the entire ecosystem into one product. This is a challenge for them in blurring between pseudonymization and anonymization. They implement all of this into one big association table. See Irish Data Protection Commissioner audit of Facebook's practices (2012) (Q860), page 46 of 57.

What next?

Question on what is observable in RTB

There is a bias in what researchers study. What is it?

Links to competition

Privacy is a dead-end for enforcement. It will always boil down to consent and design, and always be abused in unaccountable ways, in order to get the first users to adopt new intrusive technologies. And then it will expand progressively to everyone (cf. Facebook's experiments to get my consent in order to use facial recognition).

On the other hand, tracing data flows -- which is possible thanks to data protection law -- helps define exactly the assets that are being shared. It's not just about raw (personal) data, it's also about the consents associated to this data, as well as its identifiability. Once all this is taken into account, we will have a better understanding of the personal data market, and will be better able to assess dominance of some players over that market. This might open the door to a more reasoned antitrust action.

Observations on right of access

GDPR Art. 15 (Right of Access)
1. The data subject shall have the right to obtain from the controller confirmation as to whether or not personal data concerning him or her are being processed, and, where that is the case, access to the personal data and the following information:
   * the purposes of the processing;
   * the categories of personal data concerned;
   * the recipients or categories of recipient to whom the personal data have been or will be disclosed, in particular recipients in third countries or international organisations;
   * where possible, the envisaged period for which the personal data will be stored, or, if not possible, the criteria used to determine that period;
   * the existence of the right to request from the controller rectification or erasure of personal data or restriction of processing of personal data concerning the data subject or to object to such processing;
   * the right to lodge a complaint with a supervisory authority;
   * where the personal data are not collected from the data subject, any available information as to their source;
   * the existence of automated decision-making, including profiling, referred to in Article 22(1) and (4) and, at least in those cases, meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing for the data subject.
2. Where personal data are transferred to a third country or to an international organisation, the data subject shall have the right to be informed of the appropriate safeguards pursuant to Article 46 relating to the transfer. 
3. The controller shall provide a copy of the personal data undergoing processing. 2For any further copies requested by the data subject, the controller may charge a reasonable fee based on administrative costs. 3Where the data subject makes the request by electronic means, and unless otherwise requested by the data subject, the information shall be provided in a commonly used electronic form.
4. The right to obtain a copy referred to in paragraph 3 shall not adversely affect the rights and freedoms of others.


Schema.org suggestion

Someone should suggest to schema.org to add GDPR related terms (like "data controller", "access request email endpoint", etc).

Observation on OpenWPM

OpenWPM has split up into a testbed for mass crawling, and a web extension which is separate (currently used in a second project, for mass reporting to Mozilla).

Relevant items

Interesting queries