DCMS Code of Practice for App Store Operators and App Developers

On 9 November 2022 the Department for Digital, Culture, Media and Sport (DCMS) published a voluntary Code of Practice for App Store Operators and App Developers [1] (Code). DCMS published the Code alongside a response to the call for views that it issued on the draft code in May 2022.

The Code sets out minimum security and privacy requirements for app store operators and app developers. DCMS believes that the Code is the first of its kind, with an aim to protect consumers in the app ecosystem from various online threats relating to malicious and poorly developed apps by providing practical steps for app store operators and app developers to follow.

Audience and adherence

Different stakeholders are responsible for implementing different principles within the Code.  Yet the "Background" section in the Code clearly states that, given the role of app store operators in setting policies and processes for the app stores, they ought to take reasonable steps to verify that app developers and platform developers are adhering the Code.

The key stakeholders referred to, and defined within, the Code are as follows:

- App store operators (Operators) are the persons or organisations “responsible for operating the app store”.  An Operator will “have capability to add and remove apps” and also “decide on the requirements that apps will need to meet to be included in the app store, taking into account any legal requirements”.

- App developers (Developers) are the persons or organisations “which create or maintain apps on the app store”.  They are “responsible for ensuring their app meets the requirements of the app store, as well as any legal requirements”.

- Platform Developers are the persons or organisations “responsible for producing the operating system, default functionality and the interface that enables third parties to implement additional functionality, such as through apps”.

Business-to-business app programming interface providers are not required to comply with the Code.

Although the Code is voluntary, DCMS intends to assess stakeholders’ adherence to the Code, and there will be a period of nine months for Operators and Developers to achieve adherence.  DCMS’s initial focus will be on assessing Operators’ adherence, due to the fact that the majority of users access apps from Operator platforms.  It was intending to begin meetings with Operators from early 2023 to establish whether they have begun to change their practices in order to adhere to the Code, and also to request confidential written reports from Operators in spring 2023.

The eight principles

The Code sets out eight principles, and it is the responsibility of Operators, Developers and Platform Developers to implement the Code and the principles within it. The principles refer to “globally recognised security and privacy practices”.  Each principle is stated to be important, with no one principle taking precedence over another.  The principles are as follows:

1. Ensure only apps that meet the Code’s security and privacy baseline requirements are allowed on the app store

Primarily applies to Operators

Operators are responsible for ensuring that apps available on an app store are safe and secure, meaning that apps must meet the Code’s security and privacy baseline requirements. Understandably, DCMS’s view is that users should not be expected to ascertain whether an app is secure or not themselves. Under principle 1 Operators must:

- clearly set out security and privacy requirements for apps on the relevant app store, in a location that does not require purchasing access by Developers (and the app store’s security and privacy requirements should include those set out in principle 2);

- have a vetting process, including security checks, in which the above requirements are reviewed before approving app submissions and updates;

- provide an overview of the security checks undertaken for apps and updates in a publicly accessible location; and

- have a reporting system in place, so that users and security researchers can report malicious apps and Developers can report fraudulent copies of their own apps to the store (for which purposes reporting systems may take the form of visible contact details or a contact form).

Once it has satisfied itself that an app is clearly malicious, an Operator must make the app unavailable on the store as soon as possible (but within no later than 48 hours) and notify the Developer that the app has been made unavailable.  Operators are also urged to instigate a proportionate review of other apps produced by the same Developer.

Under Principle 1 Operators and Developers are also encouraged to consider working with independent parties to assess app security and privacy.

2. Ensure apps adhere to baseline security and privacy requirements

Primarily applies to Developers and Platform Developers

Principle 2 outlines the baseline security and privacy requirements to which all apps should adhere. Developers must:

- use industry-standard encryption, specifically for data in transit and where an app needs to encrypt data locally;

- ensure that the primary function of an app operates if a user chooses to disable its optional functionality and permissions;

- not request permissions and privileges which are not functionally required by the app;

- take steps to ensure that their apps adhere to security requirements, “data protection by design” requirements and broader requirements set out in relevant data protection law and other appropriate laws (and some of the relevant legal obligations under UK data protection law are summarised in Annex A to the Code);

- ensure that apps have a simple uninstall process;

- have a process in place readily to update and monitor software dependencies for known vulnerabilities; and

- provide a mechanism to enable users to delete locally held data, and to request deletion of their personal data.

3. Implement a vulnerability disclosure process

Primarily applies to Developers and Operators

Principle 3 requires all apps to have a vulnerability disclosure process which is created and maintained by the Developer, such as making the Developer’s contact details available, or including a contact form, within the app.

Operators must check that apps on their platform have a vulnerability disclosure process which is both accessible and displayed on their app store.  That process needs to ensure that vulnerabilities can be reported without making them publicly known to malicious actors.  App stores themselves also need to have a vulnerability disclosure process, to enable stakeholders to report vulnerabilities found in the store platform itself.

If a stakeholder submits a vulnerability disclosure report to an app’s Developer, and that Developer does not acknowledge that report within 15 working days, the stakeholder should be able to submit the vulnerability report directly to the relevant store Operator. Operators must assess the merit of reports and contact Developers if they deem the reports to be credible.  If, after a further 15 working days, the Operator has not received an acknowledgement from the Developer, then the Operator should make the app unavailable on the store.

The NCSC’s Vulnerability Disclosure Toolkit [2] is available online and seeks to help organisations to implement effective vulnerability disclosure process.

4. Keep apps updated to protect users

Primarily applies to Operators, Developers and Platform Developers

Developers must provide updates to fix security vulnerabilities within their apps and update apps when a third-party library or software development kit (SDK) receives a security or privacy update (consistent with UK data protection law). [3]

When a Developer submits a security update for an app, it is the Operator’s responsibility to encourage users to update their version of the relevant app.  Importantly, Operators are prohibited from rejecting stand-alone security updates without giving strong and clear justifications to the Developer. If an Operator refuses approval due to concerns that a Developer is malicious, the Operator has the benefit of flexibility in relation to the time period and detail of such feedback.

If an app has not been updated for two years, Operators are expected to contact the Developer to check whether the relevant app is still being supported. If no response is received within 30 days, then Operators must make the app unavailable on the store.

5. Provide important security and privacy information to users in an accessible way

Primarily applies to Operators and Developers

Principle 5 focuses on information that Operators and Developers must provide to users.  When an app is removed from, or made unavailable in, an app store, Operators must notify users and direct them to instructions that explain that users can remove the app from their device (if they wish to) within 30 days. According to the Code, making an app “unavailable” (as opposed to removing it) refers to when “an app is hidden from new users so they can’t download the app, but may still be on the app store so current users may be able to receive updates”.

Developers are obliged to provide the following information about an app’s behaviour: where a user’s data is stored, shared and processed within a privacy policy; when the app was last updated; and other relevant security information.  That reinforces the requirement for Developers to ensure compliance with existing UK data protection laws.

Operators must also display the following for all apps on their app store (e.g. in a dedicated security and privacy section):

- the jurisdictions where a user’s data are stored and processed for each app;

- the stakeholders that have access to a user’s data (including any third-party companies, the app’s organisation, specific governments etc. [and if a user’s data are not shared with anyone, that should also be displayed]);

- the purpose of accessing or using a user’s data (for which categories should include marketing, analytics and user services); and

- when the app was last updated, and any other relevant security information (along with the information linked to permissions described above for principle 2).

Such information will be provided to Operators by Developers, and should be clearly available to all users in an accessible format before purchase and download.  That is intended to enable users to make informed choices about which apps they do (and do not) choose to buy and download.

Finally, Developers need to provide information to Operators (and any users who install apps without an app store) about the permissions that an app may request such as access to contacts, location and the device’s microphone), and justifications for those permissions are needed.  Operators must display that information for all apps on their app store before purchase and download.

6. Provide security and privacy guidance to Developers

Primarily applies to Operators

This principle encourages information sharing and transparency.  Under principle 6, Operators must provide certain information and guidance to Developers, including signposting the Code to Developers before an app's submission and publicising upcoming changes to their Developer guidelines/policies. That provides Developers with the opportunity to understand the Code’s baseline requirements.  

Operators must dispense information on what is considered best security and privacy practice where such practice goes beyond the Code’s baseline requirements, such as providing information on other standards that have been produced.

In addition, Operators ought to support Developers in implementing effective supply chain management, e.g. by sharing relevant information and highlighting potential threat vectors across apps.

7. Provide clear feedback to Developers

Primarily applies to Operators

This principle clarifies what actions Operators should take when they decide to reject an app submission and/or to remove an app from their app store.

When an app submission is rejected, Operators are expected to give actionable feedback to the Developer, justifying the rejection and explaining what needs to be changed and/or fixed in order for the relevant app to be accepted by the Operator.  Separately, when an app is removed or made unavailable for security or privacy reasons, Operators must provide notice to the Developer and clarify the reasons for its decision. That offers Developers the opportunity to fix their apps so that they meet the necessary security and privacy requirements and can be reinstated on the relevant store.  

8. Ensure appropriate steps are taken when a personal data breach arises

Primarily applies to Developers and Operators

Principle 8 focuses on the sharing of information and providing guidance to users in the event of a personal data breach.  It requires Developers and Operators to inform the relevant stakeholders (e.g. Developers, Operators and library/SDK Developers) on becoming aware of a security incident in an app that involves a personal data breach.  Developers must also assess the impact of an incident and follow relevant data protection laws.

When a personal data breach occurs via an app, Developers must inform affected users and provide instructions to them, signposting how they should protect themselves (as users are likely to be less capable of assessing the risks associated with a data breach).  In addition, in the event of a personal data breach, Operators are encouraged to consider whether an app should be made unavailable to users.

Other considerations

While the Code itself is voluntary, Annex A highlights certain legal obligations under UK data protection law that are relevant to the Code, including under the Data Protection Act 2018 and UK General Data Protection Regulation.

Annex B sets out how a stakeholder can make a referral to the Information Commissioner’s Office (ICO) if they have information or evidence that indicates that an organisation (or individual) has poor security and/or privacy practices.  The ICO provided input on both Annex A and Annex B.

Annex C provides further information on the mechanism for allowing organisations to set up private, “enterprise” app stores for their employees, and the security measures that are required to be implemented.  

Comment

Operators and Developers who are properly informed and have comprehensive security and privacy measures in place already are likely to welcome many aspects the Code as a way to demonstrate that they meet the necessary baseline security levels, and to differentiate themselves from apps that do not comply with the Code.  That may help certain Developers gain consumer trust and be viewed as “secure” and “safe” app Developers, which could provide a valuable market advantage.

If implemented thoroughly, the Code should result in cleaner app stores, with greater visibility for apps that are transparent about their functionality, comply with baseline security requirements, and are regularly updated. That should be advantageous to Developers that embrace those principles.  Yet, along with Apple’s efforts to increase user control over privacy, the Code is also another step towards restricting background tracking of users, which (as we have seen with Meta) can have a significant impact on revenue for apps that primarily generate revenue through advertising.

This highlights the inherent tension in certain parts of the app market. Governments and regulators want to champion principles that protect users’ privacy, but policy developments that can have a materially adverse effect on revenue generation have to be implemented carefully.

Ultimately, the practical effectiveness of the Code will depend on the extent to which it is applied by Apple, Google and other app store operators.  DCMS say there will be a nine-month period for adherence, and that they will initially focus on assessing adherence by app store operators, but this is still clearly described as a voluntary code.  It seems likely that DCMS would look to in some way publicise a determination that a stakeholder is not complying with the Code, in the hope that users will naturally prefer app stores and apps that are understood to be compliant.  Yet it remains to be seen if that will be effective, and if it is not, whether or not DCMS will seek to make any or all of the Code mandatory.

‍

‍Written for Entertainment Law Review