CODE is proud to be collaborating with the Data Transfer Initiative
I am grateful to the Data Transfer Initiative (DTI) for inviting CODE to participate in its work to establish a framework for trusted and safe third-party data transfers. This collaborative effort could be an important piece of the data portability puzzle, and we will be engaging with it seriously and constructively from the outset. As our first contribution, this blog sets out the principles that will steer CODE’s engagement with the project, alongside some initial proposals for a way forward.
While we recognise there are many potential contexts that such a framework might apply to in future when data portability is widespread, this blog is focused specifically on how the designated gatekeepers of core platform services (aka Amazon, Apple, ByteDance, Google, Meta, Microsoft) will implement the data portability requirements contained within the EU’s Digital Markets Act.
Setting cynicism aside
I have written previously about my lack of enthusiasm for the Data Transfer Project as the likely catalyst for game-changing data portability solutions. It just wasn’t realistic to expect the big tech platforms to voluntarily introduce tools to allow their users to transfer their data seamlessly to wherever they choose. It wasn’t in their commercial interests to do so.
I confess I was equally cynical about the project’s revamp under the new banner of the Data Transfer Initiative, now operating as a standalone body but still funded by Apple, Google and Meta.
But something has undoubtedly now changed. Effective data portability is no longer an outcome that the platforms can debate over or take time to perfect - it is now a much clearer legal requirement under the EU’s Digital Markets Act, and the UK will surely follow in the next year or two. Whether or not the platforms build and provide access to the tools is no longer up for debate. They must. The debate now moves to more nuanced questions around 'how' rather than 'if'.
Under these revised conditions, we view the DTI as a critical stakeholder with a great deal to offer, and I am delighted it is facilitating this collaboration to address one particularly important question: how will the gatekeepers determine which third parties can access their new data portability APIs? Or perhaps better framed another way: under what conditions might the gatekeepers reasonably block access to the APIs?
It is inevitable that we will be approaching this question from a very different perspective to the designated gatekeepers, but I am optimistic that the DTI can help to identify the common ground.
Establishing the appropriate baseline
We are more likely to find that common ground if all participants have a clear view of the appropriate baseline. While there are many hypothetical contexts where different types of organisations might engage voluntarily into data portability arrangements, the real-world context driving current action is legal obligation.
Although it may be desirable to have a broadly applicable framework in place that is future-proofed for all types of data transfers, a trust or permission framework is not a precondition for enabling effective data portability under the Digital Markets Act (DMA). There is no legal expectation set out in the DMA for the gatekeepers to vet third parties seeking access to the tools. In our view, the GDPR also does not place any responsibility onto the gatekeepers for the processing or security of data once it has been successfully transferred to a receiving data controller. Come the 7th March 2024, by which point the designated gatekeepers must submit compliance reports to the European Commission, the existence or otherwise of an agreed trust framework will not shield them from the consequences of non-compliance.
It is also the case that there are no explicit carve outs to the law to allow the gatekeepers to restrict access to the data portability tools. Any outcome that prevents EU users from transferring their data to a third party of their choice would be a clear breach of the law at that point. It is hard to imagine many scenarios that could justify this outcome, so we expect the gatekeepers to start the process with a presumption of acceptance, while tightly defining the reasonable exceptions to that rule.
Finally, it is important to be clear from the outset that CODE’s involvement in this collaboration, and I hope our endorsement of its output, will not infer our validation of the gatekeepers’ eventual approaches to DMA implementation. Having a sensible and joined-up approach to API permissions is important, but it is not a substitute for (nor does it take precedence over) full compliance with the law. CODE will engage with this process in good faith, on the firm assumption that the gatekeepers are in parallel developing tools to enable continuous and real-time access to data as required by the Act.
CODE’s principles for engagement
As we begin collaborating with the DTI and its partner organisations, we will consistently be steered by the following principles:
Denying users their legal rights is an extreme intervention
Ensuring valid user authentication is paramount
Consistent standards for consent must apply to all
Law enforcement should be left to the appropriate authorities
Reciprocity does not apply to the Digital Markets Act
API permission is not app review
Costs must not be prohibitive for small businesses
We have expanded on each of these below, highlighting a series of recommendations and red lines as we go. As noted above, those recommendations have been written with a particular focus on how a trust framework could apply in the context of DMA compliance. We recognise that in other contexts, including those that are engaged in voluntarily, other arrangements may be more suitable.
Principle 1: Denying users their legal rights is an extreme intervention
Authorisation of a third party to receive users’ data from a gatekeeper platform will be a two-stage process:
The first stage is likely to include a gateway where third parties have to request permission for technical access to the API. This will typically happen before any users have actually requested to transfer their data, so no user consent will have been sought at this stage. This kind of process is already common for many existing APIs, such as Gmail and Apple Health.
The second (and most important) stage will be the authorisation and consent by the user for the data transfer, which we expect to be initiated within the destination service. This will take place after the technical API connection has been made, and the user interface has been built by the third party.
As the data is legally owned by the user, it is the users’ decision that should take precedence. However, due to the practical need for technical access to be granted first, the gatekeepers will have the ability to restrict users’ choices. This situation should be approached with caution by the gatekeepers.
The direct consequences of being granted permission for technical access to the API at the first stage are extremely limited, as no data is automatically accessible at that point. The only immediate outcome is that users will have more choice over where they might transfer their data and what new services they might access. While it is understandable that gatekeepers may want to consider who has access to their technology to avoid repeating reputationally damaging mistakes of the past, we believe this can be achieved through a relatively light-touch information gathering exercise.
There can only be fairly serious justifications for gatekeepers to restrict users ability to exercise their legal rights to port their data directly to another service, enshrined in Article 6(9) of the DMA, and complemented by Article 20 of the GDPR. These might include having evidence that the third party is:
not who it says it is;
involved in criminal or terrorist activity;
based in a country without a comprehensive data protection regime; or
wilfully misleading its users about the nature of its business, including by concealing its data processing activities.
We would recommend introducing a light-touch information gathering exercise to guard against these specific risks.
Recommendation 1: incorporate a light-touch information gathering system into existing API permission portals, whereby the applicant could provide information on its company such as where it operates, verification of domain ownership, details of registration with a data protection authority, its legal basis for processing the personal data, and a description of the service or features the API access will enable for its users.
We recognise that the gatekeepers may want to introduce additional requirements in order for them to satisfactorily ‘vet’ the applicants. In this context, and in view of existing gatekeeper permissions frameworks, we accept there are some further pieces of evidence that could be provided without introducing disproportionate burdens.
Recommendation 2: to further protect users from bad actors, the third parties could be required to submit evidence that demonstrates they are not concealing their data processing activity from their users. This could take the form of screenshots or a short video demonstrating that data collection and processing intentions are not buried in privacy policies or terms and conditions.
Recommendation 3: to limit frivolous or speculative applications, the applicant could also be asked to provide some indicative evidence that they have, or reasonably expect to have, genuine demand from users to make the transfers. This could take the form of evidence from existing services and users, market testing, or user feedback.
Recommendation 4: to reassure the gatekeeper that data will be kept safe after the transfer, third parties should be asked to complete a security self-assessment, reporting on practices such as participation in vulnerability disclosure programmes and method for storing encryption keys. This form of self-reporting would be consistent with existing practice for many gatekeeper API permissions.
While we consider it reasonable for the gatekeepers to ask for this kind of assurance, the introduction of anything more onerous would serve as a costly and challenging barrier for many small businesses. This would ultimately restrict users’ choices and hold back competition in the sector.
Red line 1: third parties seeking access to the gatekeepers' DMA-compliant data portability APIs must not be required to undergo a disproportionate external security assessment or vetting process. The resource costs of engaging with such a process, along with the associated fees, would be prohibitive for small businesses that are in the early stages of development.
The gatekeeper also doesn’t just need to take the applicant’s word that it is a reputable and law-abiding company. There are other sources of information they could lean on to supplement factual information in the application. Firstly, in the context of DMA implementation, it is highly likely the applicant already has an existing commercial relationship with the gatekeeper, whether that is through the delivery of their app stores and web stores, the supply of cloud or advertising services, or even other API permissions. It has likely already been vetted comprehensively in various other contexts. Acceptance in those other contexts should be viewed as a positive signal, enabling further due diligence activity to be minimised. Secondly, there are other external signals that could be used to interpret the credibility of the company involved. For example, whether they are affiliated with or endorsed by recognised industry bodies such as the DTI and CODE, or whether their app store ratings are indicative of a legitimate company.
Recommendation 5: provide an opportunity within the application for the third party to submit optional supplementary information to support their credibility, such as membership of recognised industry bodies, certification for relevant industry standards, and details of existing ongoing commercial relationships with the gatekeepers.
Principle 2: Ensuring valid user authentication is paramount
The user should have the ultimate say on where they transfer their data to, for how long, and to what end. This is true in principle, and also by law. So the biggest question that the gatekeeper should be concerned about is whether it is genuinely the user making the request, and whether they have a reasonable understanding of what is happening.
This is one area where we accept that adding a small degree of friction into the process is necessary to protect the integrity of the system, and to ensure users are not having their data stolen without their knowledge. Thankfully this is not a new challenge, and there are widely used solutions available.
Recommendation 6: Apply the OAuth 2.0 protocol for authorisation, with standardised layout, content, and messaging across each gatekeeper platform as far as is possible. As well as confirming consent, this is also the point at which the user should select which categories of data they want to transfer, and for how long they want to authorise the third party to access it.
In addition to ensuring the individual is the one requesting the transfer, the OAuth process also acts as an additional affirmative action that the user must take, thus ensuring that the data transfer is an express wish of the user and not something that can happen passively in the background without their knowledge.
But this desire to ensure the user knows what they are doing could be taken too far. Users should not be nudged into sharing more data than they would like by exaggerated claims of benefits or through biased choice architecture. But equally, they should not be discouraged from doing so by overly cautious language and framing introduced by the gatekeeper.
Red line 2: gatekeepers must not mandate the inclusion of highly alarmist language within the OAuth choice architecture as a way of discouraging users from transferring their data.
Principle 3: Consistent standards for consent must apply for all
In their genuine desire to protect their users from bad actors, it may be tempting for the gatekeepers to begin examining the consent flows and mechanisms that third parties apply in advance of the OAuth consent screens, or even to start requesting detailed commercially sensitive information to assess whether the third parties are being fully transparent with their users. This would be extremely challenging to deliver in a fair and consistent way from a practical perspective, but also in reality the quality and validity of consent is often not such a black and white issue. The ideal degree of detail to provide users with at different stages of their decisions is often challenging to judge. Too little information may not be specific enough to enable an informed decision, but too much information may overwhelm and have the same effect. We believe it could set a dangerous precedent if the gatekeepers started making subjective assessments regarding the validity of consent for each and every applicant.
Most importantly, such an approach would raise questions of consistency regarding the gatekeepers’ own record with respect to consent. CODE’s members are united by the view that consent can only be meaningful when it is given explicitly, with a reasonable understanding of the consequences, and without undue influence or fear of penalty from withholding. We don’t believe consent can be secured through the fine print in a privacy policy, by offering take-it-or-leave-it terms for a must-have service, or by offering people the chance to buy their privacy back through a monthly subscription.
Red line 3: the gatekeepers should avoid making subjective judgements on the framing and choice architecture of the third parties’ consent mechanisms. This would extend well beyond their remits and raise questions of consistency.
If third parties are asked to make certain commitments regarding consent, we will expect the gatekeepers to demonstrate that they are meeting those same standards.
Principle 4: Law enforcement should be left to the appropriate authorities
While gatekeepers undoubtedly perform a valuable stewardship role within their ecosystems, they are not data protection regulators. Seeking to judge or determine precisely what can be done with the data by the third parties, e.g. by listing ‘acceptable’ and ‘unacceptable’ business models, would constitute a gross overreach of responsibility.
We recognise that one exception to this rule might occur where third parties operate predominantly in jurisdictions without a mature national data protection regime. In these circumstances, the third parties may reasonably be expected to provide additional assurances or detail about what activity they will carry out with the data, and how this is being communicated to users.
Recommendation 7: the API application process could include an additional layer of questions or commitments required of third parties that originate from jurisdictions without a mature or comprehensive national data protection regime, such as additional information relating to data processing intentions.
Principle 5: Reciprocity does not apply to the Digital Markets Act
In the context of data portability, CODE views reciprocity as an aspirational principle that is of greatest relevance to transfers of data between like-for-like service providers. For example, in the context of music streaming, it would make sense if a user could keep moving their playlists with them each time they switch to a new provider. Otherwise they might get stuck, and this could in turn serve as a barrier to choice and competition. However, we approach this issue with caution for two reasons:
As a data holder, building the capabilities and infrastructure for users to transfer their data to another service will be costly and resource-intensive. This isn’t a realistic expectation of smaller businesses that are attempting to get a foothold in a market.
Where data transfers are between different types of services, e.g. from an online marketplace to a personal data store or data union, the case for reciprocity is less clear. In that example, the user isn’t switching away from the original service, so the data is not so much moved as copied.
In general, we would therefore expect to see a careful and tailored approach to any discussion of reciprocity for data transfers, with a recognition there are some contexts where it is not appropriate.
One of those exceptions is the Digital Markets Act. The DMA applies to companies that have been designated as gatekeepers of core platform services. Those gatekeepers have been deliberately called out for special treatment in order to level the playing field in their markets. In that context, we consider it would be inappropriate for gatekeepers to mandate reciprocity of data transfers from the third parties requesting access.
Red line 4: we will not endorse an arrangement that mandates reciprocity of data transfers from third parties in the context of DMA implementation. This would undermine the intent of the Act.
Principle 6: API permission is not app store review
App developers have raised a great number of concerns about the operation of app store review processes over the years. We would be concerned about the potential for similar problematic conduct to arise at any new gateways, including API permissions.
In particular, the framework should guard against third parties needing to disclose commercially sensitive information, such as detailed information about business models, products in development, valuable IP, or their client base. The third parties in question are highly likely to be developing a product or service that competes in some way with one already owned by the gatekeeper, or alternatively they may be developing an innovative new product or service that the gatekeeper could easily replicate at larger scale.
Red line 5: the gatekeeper should not seek sensitive information about the commercial strategy of the applicant, or regarding its existing or intended client base.
The application process could also be particularly costly for third-party applicants if it drags on for an undefined period, or hangs over them as a looming threat that could be revisited at any time. The decision to grant access needs to carry some degree of certainty and finality to enable ongoing investment and innovation with confidence. Any non-cyclical review of access to the API must be triggered only in very exceptional circumstances, and involve constructive dialogue involving the third party.
Recommendation 8: review technical access annually in a light touch way, requiring confirmation that the API was in use during the year, and updated visual evidence that the third party’s data collection is still not being concealed or downplayed.
Principle 7: Costs must not be prohibitive for small businesses
Any permission framework must not prohibit small businesses from accessing the APIs due to costs or resources involved. For example, as well as being free to access, the API permission should ideally not involve or require substantial resources to engage with, nor should the third party be required to meet any minimum thresholds with respect to revenue.
Red line 6: third parties must not be required to pay a fee to access the APIs, or for any element of the application process.
What can CODE bring to the table?
We can share different perspectives and experiences of trying to help users exercise their existing rights to data portability, including an understanding of what causes frustration for users and what degree of friction will render the tools ineffective. We also have experience of accessing some of the gatekeepers existing APIs, including those that have some degree of restricted access. We can advise on the potential applicability of those existing frameworks and processes, and where improvements would be beneficial.
We will approach the process in a positive and constructive light, bringing solutions to problems where we see them. That is why we have sought to highlight some workable proposals in this blog, while also being clear from the outset on the issues that would cause us the biggest challenges.
We look forward to engaging with the DTI and its partners in this initiative, and we are hopeful it will deliver a framework that CODE can endorse - to the European Commission and beyond.
Comments