Privacy Transparency for Umbraco Packages #18548
Replies: 6 comments 2 replies
-
|
Wow, this is some great work by you the Security and Privacy Team @alanmac 👏 Packages Team notified! ✅ |
Beta Was this translation helpful? Give feedback.
-
|
I really like this idea and I think the manifest would be the place for this. The only concern I have it that you need to be able to trust what the package creator is saying. You are at the mercy of what the package developer declares and if the developer is truthful. Unless you actually want to check packages as Umbraco HQ, it should be clear in the marketplace that there is no guarantee that it's accurate. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @Luuk1983, I agree — the marketplace listing should be clear that the privacy transparency information is a declaration of the package developer and is not a guarantee by Umbraco. As you point out — HQ will not be reviewing packages to validate alignment (although this could be an idea to explore in the future should a package developer which to gain independent attestation). Another idea as an additional layer of assurance could be to do a code analysis of open source packages on submission and produce a transparency report that summarises third party endpoints leveraged by the package. This information could be made accessible alongside the transparency information submitted by the package dev. Thanks for your input! |
Beta Was this translation helpful? Give feedback.
-
|
All on board with this, and really like the idea of having the Apple-style manifest as I think this will help people categorise their data usage into the proper categories. Something that needs thought is the ability for packages to consume the data vs whether the package does out of the box. For example, Umbraco Forms collects data but the extent and categorisation of the data itself is really down to the developer/editor. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @Rockerby . Thanks for your comment. This is a great point — some packages facilitate use of personal data which is defined by the implementer of the solution, and as such what the package will process can't be necessarily fully defined by the package developer. My view on this is that it is up to the package developer to declare what data the package does process and why. The declaration can also make clear that the implementer has the ability to define the type and use of additional personal data based on how the package is configured, but at a minimum the developer should be informed of how the package uses personal data at its baseline. In the case of Umbraco Forms, which could process all sorts of personal (including sensitive) data, the solution provider would ultimately need to ensure that the information in their privacy policy accurately reflects how they use personal data, including for packages like Umbraco Forms. |
Beta Was this translation helpful? Give feedback.
-
|
Great work on this @alanmac! And great feedback @LottePitcher @Luuk1983 @Rockerby #h5yr Definitely some things there to think about and discuss on our next call. I'm still learning about the privacy side of things myself - Alan is our expert :) |
Beta Was this translation helpful? Give feedback.
-
|
Thank you! Fabulous! |
Beta Was this translation helpful? Give feedback.
-
|
As a follow-up, we had helpful feedback from the Package Team suggesting that closed source packages (e.g. Umbraco Forms) could be good candidates to initially roll out a privacy transparency feature, as inherently it is more difficult for those installing closed source packages to inspect their use of personal data. I think this makes a lot of sense. |
Beta Was this translation helpful? Give feedback.
-
tl;dr; (too long; didn’t read;)
The Umbraco Community Security and Privacy Team have been discussing opportunities to enhance the domains of security and privacy in Umbraco and its ecosystem. One of the opportunities identified is to enable package developers to provide useful information regarding how packages use personal data via the package information that is provided in the Umbraco Marketplace, with a view to enabling Umbraco developers to implement privacy-respecting Umbraco solutions.
Why Transparency Matters
Proposed Approach
The team is seeking feedback on this idea and we'd love to hear from you!
Background
The Umbraco Community Security and Privacy Team have been discussing opportunities to enhance the domains of security and privacy in Umbraco and its ecosystem. One of the opportunities identified is to enable package developers to provide useful information regarding how packages use data (in particular personal data) via the information provided in the Umbraco Marketplace, with a view to enabling Umbraco developers to implement privacy-respecting Umbraco solutions.
Terms used below
Before I dive in, to help frame the discussion I'll level-set on a few of the terms I use to flesh out the idea below.
Stakeholders:
Why is transparency important?
Transparency is the foundation of privacy compliance, ensuring individuals understand how their data is used, enabling informed choices, and empowering individuals to exercise their rights effectively. Getting transparency right for Umbraco packages makes it easier for those developing and providing Umbraco solutions to identify applicable privacy requirements that flow from the 'what, why and how' of package data use. Effective transparency facilitates user-centric design and ultimately, Privacy by Design.
Who benefits from increased transparency?
Umbraco Developers: With effective transparency, Umbraco Developers are enabled to facilitate privacy requirements. They are able to adequately inform those they are implementing solutions on behalf of (i.e. the Umbraco Solution Provider) regarding privacy considerations that arise from using the Umbraco package and any downstream impact that may have on the solution, including the information that needs to be made available to Umbraco Users. For example: if a package collects data relating to users for analytics purposes - there may be consent & choice requirements to implement. If the package transmits personal data to third parties (e.g. Cloud Service Providers), possibly resulting in cross border transfers of personal data, there may be additional safeguards that are necessary for the Umbraco Solution Provider to put in place to facilitate such transfers (e.g. contractual & technical safeguards etc.).
Umbraco Solution Providers: Umbraco Solution Providers often bear ultimate responsibility for meeting privacy legal requirements, including ensuring that they are able to facilitate individuals' privacy rights. In order to facilitate this, they need to know how personal data is being used by the Umbraco solution and its packages to adequately inform end-users and ensure that the product that's provided to users processes personal data in line with users expectations. If transparency information is available for each package included in a solution, the solution provider is armed with the information they need to meet privacy requirements, such as ensuring that key customer-facing transparency mechanisms (e.g. Privacy Notices) include the information that needs to be communicated to individuals.
Procurement Stakeholders: These stakeholders may range from one individual within small orgs to entire functions in large enterprises. They are responsible for sourcing and selecting vendors, services and solutions to meet business needs. Procurement, with Third Party Risk Management partners facilitate ensuring that the solutions the business want to onboard are within the organisations risk tolerance, including with respect to meeting privacy requirements such as those flowing from regulations such as GDPR in the EU and CCPA in the US. With transparency information readily available within the Umbraco solution package chain to procurement stakeholders, privacy due diligence is easier to perform, resulting in a smoother procurement process.
Umbraco Users: Users of Umbraco , whether it be individuals maintaining the solution or those benefiting from the products or services the solution delivers (i.e. you and me!) are provided with the information that enables them to exercise their privacy rights. Additionally, effective transparency drives implementation decisions, which if done well can result in a better user experience, empowering users to better understand and control their how their personal data is used and enhancing trust with users.
Why add a transparency feature to the Umbraco Marketplace?
The Umbraco Marketplace provides information relating to packages. Providing privacy-related information alongside other package information, enables Umbraco Developers considering the package to make informed decisions regarding its use.
Understanding how data is used by packages is essential to facilitate Umbraco Developers in facilitating compliance with various security and privacy regulatory frameworks across the globe, including the EU & UK General Data Protection Regulation (GDPR), the US California Privacy Rights Act (CPRA), Canadian Personal Information Protection and Electronic Documents Act (PIPEDA) and more.
Providing information relating to what data is collected and used, why and how it is used, is essential in enabling those with compliance obligations to identify and take the actions necessary to meet those obligations. These include:
In addition, providing transparency information facilitates user-centric design, enhances trust and provides assurance, both for those procuring and providing Umbraco solutions and the end users who benefit from using them. Getting transparency right is the cornerstone that enables meeting individuals privacy rights and ensuring that they maintain control of their personal data.
What are others doing?
While there are examples of CMSs (e.g. Joomla) providing hooks for package developers to specify information relating to personal data use, I haven't yet observed examples of CMSs leveraging such information in their equivalents of the Umbraco Marketplace. I think this represents an opportunity for Umbraco to take the lead.
Outside of the CMS ecosystem, Apple provides a good example of how this idea can be implemented with its Privacy Manifest and Privacy Nutrition Labels concepts. With Privacy Manifests, SDK developers specify what data is used and how it is used by the SDKs that App developers integrate into their apps. In turn, App developers are facilitated to make the necessary design decisions to meet compliance requirements, including populating the Privacy Nutrition Label information that gets displayed to end users in the App Store to ensure that they are adequately informed regarding application data use prior to App download.
A Possible Umbraco Approach
A proposed approach to facilitate Umbraco Developers providing data transparency information within their packages could be to provide for collecting such information via manifest files, as Apple does with their Privacy Manifest. The manifest file is a concept already leveraged by Umbraco packages and would seem a good candidate to build on for this feature. Information such as the categories (types) of data used and the reasons a package uses data could be specified within the manifest file. ISO standards such as ISO 19944 provide a defined taxonomy of data categories that can be referenced to ensure consistency when describing data use.
Including privacy transparency information in package submissions could be optional to begin with. The intention is not to introduce significant friction for package developers, but rather to empower developers to enhance the information included in their package submission where it makes sense to do so. Package developers who see the value of including the information for users of their packages can do so, and where it is submitted, it can be displayed in the Umbraco Marketplace.
Request for Comment
There is a lot more thinking that needs to go into this idea to make it a reality and I'd love to hear your thoughts about how you think it could work. Do you see value in the ability to provide privacy transparency information within Umbraco packages? What are your ideas on how best to implement it?
Looking forward to hearing your thoughts!
Beta Was this translation helpful? Give feedback.
All reactions