Difference between revisions of "Project:Adtech"
(159 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
− | This is a | + | = 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 == | ||
+ | * [https://lumapartners.com/wp-content/uploads/2017/01/2y103ITnIXmg2.lPu6ncZsis.wcn8DVuYIUfyLrC9cdQiWUhfOdDLq6-1024x768.png "historic" Lumascape picture] | ||
+ | |||
+ | * 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 = | ||
+ | == Datasets about the adtech ecosystem == | ||
+ | * [[WebXray domain ownership list]] | ||
+ | * [[Related datasets]] | ||
+ | |||
+ | = Visualizations = | ||
+ | {{Project:Adtech/Visualizations|state=collapsed}} | ||
+ | |||
+ | = A prototype = | ||
+ | * {{Q|102}} | ||
+ | * [[Addressing_adtech/Guardian|An example request]], generated directly from {{Q|855}}. | ||
+ | |||
+ | = Ontology = | ||
+ | See [[Project:Ontology/Adtech]] | ||
+ | |||
+ | = Precise questions = | ||
+ | == {{Q|845}}-related questions == | ||
+ | * What is the impact of a {{Q|839}} on a {{AllQ|495}}? | ||
+ | ** Is this helpful for understanding {{Q|519}}? {{Q|520}}? | ||
+ | ** More specifically a SAR on an {{AllQ|559}}? Is it different than for a {{AllQ|522}}? | ||
+ | *** What is the legal situation of {{Q|399}}, successor to {{Q|398}}? | ||
+ | * What traces are left by {{Q|523}}? Which are accessible through {{Q|839}}? | ||
+ | * Which {{AllQ|110}} or {{AllQ|834}} set the {{AllQ|838}}? | ||
+ | ** When are they shared? | ||
+ | ** Is deciding the {{Q|838}} enough to make an entity a {{AllQ|96}}? What about if you decide how they can be shared? | ||
+ | *** {{Q|546}} for instance facilitated the selling of an {{Q|496}} by {{Q|840}} of people more "likely to be constipated". This was determined (?) through the use of {{Q|539}}. | ||
+ | |||
+ | |||
+ | === Tag management === | ||
+ | * What is the impact of an indirect SAR on a {{AllQ|504}} | ||
+ | * Can a SAR tell you for whom an {{AllQ|503}} fired? | ||
+ | ** Is the legal situation different for a SAR on {{Q|70}}? | ||
+ | === Bidding process === | ||
+ | * What is the impact of a(n indirect) SAR on a {{AllQ|498}}? | ||
+ | * Can you know whether {{AllQ|497}} was triggered? | ||
+ | * What was the value of the transaction? | ||
+ | |||
+ | === 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 {{Q|841}}. The costs and effects have a completely different scaling factor, and also an impact on the choice of jurisdiction. | ||
+ | |||
+ | == {{Q|846}}-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. | ||
+ | |||
+ | == {{Q|842}}-related questions == | ||
+ | {{Q|842}} gives the right to information about the "essence of the contract" in joint-controller situations. What does this cover? | ||
+ | * Can we learn more about {{Q|848}} or {{Q|847}} through this? | ||
+ | * Can we know how {{Q|127}} {{Q|849}} is done? Is a {{Q|850}} used? This has direct impact on identifiability (to whom?) | ||
+ | * Can we learn more about the structure of each agreement involved in {{Q|523}}? | ||
+ | |||
+ | == Adtech experiments == | ||
+ | * {{Q|188}} and subclasses help get feedback quicker | ||
+ | * {{Q|858}} defines a {{Q|94}} | ||
+ | ** There are problems with the [https://vendorlist.consensu.org/vendorlist.json "purposes" defined in the consent framework]. | ||
+ | * Through cookie manipulations you can consent very flexibly. A/B test on the entire IAB, agree to A on odd day, B on even day. | ||
+ | |||
+ | == 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 {{Q|860}}, 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). | ||
+ | * [https://twitter.com/CartoCharles/status/1130367901767262209 Think OpenStreetMap, not Google Street View or Tesla] | ||
+ | * --> Build toolkits/diffuse computing?! | ||
+ | |||
== Relevant items == | == Relevant items == | ||
* {{Q|107}} | * {{Q|107}} | ||
Line 6: | Line 155: | ||
* {{Q|518}} | * {{Q|518}} | ||
* {{Q|370}} | * {{Q|370}} | ||
− | * | + | * {{Q|110}} |
− | + | * {{Q|495}} | |
− | + | * {{Q|559}} | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | } | ||
− | |||
− | |||
− | * | ||
− | + | == See also == | |
− | + | * [[Project:GetYourData]] | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− |
Latest revision as of 22:56, 6 February 2020
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
Datasets about the adtech ecosystem
Visualizations
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... we need an ontology (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
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 map of the 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:Q110.
SERVICE wikibase:label {
bd:serviceParam wikibase:language "en" .
?item rdfs:label ?label
}
OPTIONAL { ?item pdiot:P47 ?_image. }
}
LIMIT 100
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:P37 pdio:Q495.
SERVICE wikibase:label {
bd:serviceParam wikibase:language "en" .
?item rdfs:label ?label
}
OPTIONAL { ?item pdiot:P47 ?_image. }
}
LIMIT 100
data management platforms (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:P37 pdio:Q559.
SERVICE wikibase:label {
bd:serviceParam wikibase:language "en" .
?item rdfs:label ?label
}
OPTIONAL { ?item pdiot:P47 ?_image. }
}
LIMIT 100
identity resolution services (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/>
#defaultView:Graph
SELECT ?item1 ?item1Label ?rgb ?item2 ?item2Label
WITH {
SELECT ?predicateFilterValue ?predicateFilterValueRGB WHERE {
VALUES (?predicateFilterValue ?predicateFilterValueRGB) {
(pdio:Q110 "EEEEEE")(pdio:Q495 "222288")(pdio:Q559 "8822222")
}
}
}
AS %predicateFilterValues
WITH {
SELECT ?predicate ?subjectValue ?objectValue ?predicateRGB WHERE {
VALUES (?predicate ?subjectValue ?objectValue ?predicateRGB) {
(pdiot:P111 pdio:Q495 pdio:Q559 "EEEEEE")(pdiot:P111 pdio:Q495 pdio:Q559 "222288")
}
}
}
AS %predicates
WITH {SELECT ?node ?nodeRGB WHERE {
?node pdiot:P3 ?predicateFilterValue.
INCLUDE %predicateFilterValues.
BIND(?predicateFilterValueRGB AS ?nodeRGB)
}
}
AS %nodes
WITH {SELECT ?subject ?object ?edgeRGB WHERE {
INCLUDE %predicates.
?subject pdiot:P3 ?subjectValue.
?object pdiot:P3 ?objectValue.
?subject ?predicate ?object.
# This is filtering for each edge twice, potentially a huge waste: |E|*|V| instead of |V|
BIND(?predicateRGB as ?edgeRGB)
}
} AS %edges
WHERE {
{ # The caption's nodes:
INCLUDE %predicateFilterValues.
BIND(?predicateFilterValue AS ?item1).
BIND(?predicateValueRGB AS ?rgb).
}
UNION
{ # The caption's edges:
INCLUDE %predicates.
BIND(?subjectValue AS ?item1).
BIND(?objectValue AS ?item2).
BIND(?predicateRGB AS ?rgb).
}
UNION
{
INCLUDE %nodes.
BIND(?node AS ?item1).
BIND(?nodeRGB AS ?rgb).
}
UNION
{
INCLUDE %edges.
BIND(?subject AS ?item1).
BIND(?object AS ?item2).
BIND(?edgeRGB AS ?rgb).
}
SERVICE wikibase:label {
bd:serviceParam wikibase:language "en" .
}
}
LIMIT 10000
A prototype
- Deliveroo (Q102)
- An example request, generated directly from Guardian adtech investigation (Q855).
Ontology
Precise questions
- What is the impact of a Q839 on a data management platform (Q495)(all)?
- Is this helpful for understanding cross-device tracking (Q519)? probabilistic fingerprinting (Q520)?
- More specifically a SAR on an identity resolution service (Q559)(all)? Is it different than for a data broker (Q522)(all)?
- What is the legal situation of Adobe Marketing co-op (Q399), successor to Demdex (Q398)?
- What traces are left by real-time bidding (Q523)? Which are accessible through Q839?
- Which adtech company (Q110)(all) or adtech product (Q834)(all) set the marketing segment (Q838)(all)?
- When are they shared?
- Is deciding the marketing segment (Q838) enough to make an entity a data controller (Q96)(all)? What about if you decide how they can be shared?
- Turn Inc (Q546) for instance facilitated the selling of an audience (Q496) by Weather Channel (Q840) of people more "likely to be constipated". This was determined (?) through the use of geolocation data (Q539).
Tag management
- What is the impact of an indirect SAR on a tag manager (Q504)(all)
- Can a SAR tell you for whom an advertising tag (Q503)(all) fired?
- Is the legal situation different for a SAR on Google Tag Manager (Q70)?
Bidding process
- What is the impact of a(n indirect) SAR on a ad exchange (Q498)(all)?
- Can you know whether ad impression (Q497)(all) was triggered?
- What was the value of the transaction?
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.
- 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) gives the right to information about the "essence of the contract" in joint-controller situations. What does this cover?
- Can we learn more about anonymization (Q848) or pseudonymization (Q847) through this?
- Can we know how unique identifier (Q127) hashing (Q849) is done? Is a hashing salt (Q850) used? This has direct impact on identifiability (to whom?)
- Can we learn more about the structure of each agreement involved in real-time bidding (Q523)?
Adtech experiments
- data rights service (Q188) and subclasses help get feedback quicker
- IAB Consent Framework (Q858) defines a IAB vendors list (Q94)
- There are problems with the "purposes" defined in the consent framework.
- Through cookie manipulations you can consent very flexibly. A/B test on the entire IAB, agree to A on odd day, B on even day.
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).
- Think OpenStreetMap, not Google Street View or Tesla
- --> Build toolkits/diffuse computing?!
Relevant items
- advertising technology (Q107)
- adtech company (Q110)
- adtech ecosystem buy side (Q517)
- adtech ecosystem sell side (Q518)
- adtech ecosystem (Q370)
- adtech company (Q110)
- data management platform (Q495)
- identity resolution service (Q559)