diff options
author | Richard Hughes <richard@hughsie.com> | 2018-03-14 13:29:25 +0000 |
---|---|---|
committer | Richard Hughes <richard@hughsie.com> | 2018-04-11 19:19:47 +0100 |
commit | 90341836a64b22104ee41ac4b9acd6299bc8aa3a (patch) | |
tree | d7870f815386c4b3e7a5664e0bbbec19fea61950 /data/tests | |
parent | 786a2c85c06ba82d41db9eb5490c964d3bd7754d (diff) | |
download | appstream-glib-90341836a64b22104ee41ac4b9acd6299bc8aa3a.tar.gz |
Add support for component agreementswip/hughsie/privacy-gdpr
This enables a lot of software to comply with the GDPR and also allows us to
show translated warning and EULA text to unsuspecting users.
Diffstat (limited to 'data/tests')
-rw-r--r-- | data/tests/example-eula.metainfo.xml | 18 | ||||
-rw-r--r-- | data/tests/example-gdpr.metainfo.xml | 396 | ||||
-rw-r--r-- | data/tests/example-remote.metainfo.xml | 28 |
3 files changed, 442 insertions, 0 deletions
diff --git a/data/tests/example-eula.metainfo.xml b/data/tests/example-eula.metainfo.xml new file mode 100644 index 0000000..516b79e --- /dev/null +++ b/data/tests/example-eula.metainfo.xml @@ -0,0 +1,18 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!-- Copyright 2018 Richard Hughes <richard@hughsie.com> --> + +<component type="desktop"> + <id>org.gnome.Software</id> + <name>GNOME Software</name> + ...usual contents for a desktop app... + <metadata_license>CC0</metadata_license> + <agreement type="eula" version_id="1.0"> + <agreement_section> + <description> + <p> + If it breaks, you get to keep both pieces. + </p> + </description> + </agreement_section> + </agreement> +</component> diff --git a/data/tests/example-gdpr.metainfo.xml b/data/tests/example-gdpr.metainfo.xml new file mode 100644 index 0000000..2bac8fc --- /dev/null +++ b/data/tests/example-gdpr.metainfo.xml @@ -0,0 +1,396 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!-- Copyright 2018 Richard Hughes <richard@hughsie.com> --> + +<component type="general"> + <id>org.fwupd.lvfs</id> + <name>Linux Vendor Firmware Service</name> + <metadata_license>CC0</metadata_license> + + <agreement type="privacy" version_id="1.0"> + + <agreement_section type="introduction"> + <name>Introduction</name> + <description> + <p> + We hold personal data about vendors, administrators, clients and other + individuals for a variety of purposes. + This policy sets out how we seek to protect personal data and ensure that + administrators understand the rules governing their use of personal data to + which they have access in the course of their work. + In particular, this policy requires that the Data Protection Officer (DPO) be + consulted before any significant new data processing activity is initiated to + ensure that relevant compliance steps are addressed. + </p> + </description> + </agreement_section> + + <agreement_section type="scope"> + <name>Scope</name> + <description> + <p> + This policy applies to all users who have access to any of the personally + identifiable data. + </p> + </description> + </agreement_section> + + <agreement_section type="dpo"> + <name>Who is responsible for this policy?</name> + <description> + <p> + As the Data Protection Officer, Richard Hughes + has overall responsibility for the day-to-day implementation of this policy. + The DPO is registered with the Information Commissioner’s Office (ICO) in the + United Kingdom as a registered data controller. + </p> + </description> + </agreement_section> + + <agreement_section type="processing"> + <name>Fair and lawful processing</name> + <description> + <p> + We must process personal data fairly and lawfully in accordance with individuals’ rights. + This generally means that we should not process personal data unless the + individual whose details we are processing has consented to this happening, + or where such collection is unavoidable and/or considered pragmatic in the + context, e.g. logging the number of downloads of a particular file. + </p> + <p> + We do not consider an IP address to represent a single user (due to NAT or VPN use), + and as such metadata requests are not considered personal data using the draft GDPR guidelines. + </p> + </description> + </agreement_section> + + <agreement_section type="accuracy"> + <name>Accuracy and relevance</name> + <description> + <p> + We will ensure that any personal data we process is accurate, adequate, + relevant and not excessive, given the purpose for which it was obtained. + We will not process personal data obtained for one purpose for any unconnected + purpose unless the individual concerned has agreed to this or would otherwise + reasonably expect this. + Individuals may ask that we correct inaccurate personal data relating to them. + If you believe that information is inaccurate you should inform the DPO. + </p> + </description> + </agreement_section> + + <agreement_section type="personal"> + <name>Your personal data</name> + <description> + <p> + You must take reasonable steps to ensure that personal data we hold about + hardware vendors is accurate and updated as required. + For example, if your personal circumstances change, please update them using + the profile pages or inform the Data Protection Officer. + </p> + </description> + </agreement_section> + + <agreement_section type="security"> + <name>Data security</name> + <description> + <p> + We keep personal data secure against loss or misuse. + Where other organisations process personal data as a service on our behalf, + the DPO will establish what, if any, additional specific data security + arrangements need to be implemented in contracts with those third party + organisations. + </p> + </description> + </agreement_section> + + <agreement_section type="storage"> + <name>Storing data securely</name> + <description> + <p> + All data is stored electronically. + All documents and code are held on a locked LUKS partition with a password + adhering to security best practices. + </p> + </description> + </agreement_section> + + <agreement_section type="retention"> + <name>Data retention</name> + <description> + <p> + We must retain personal data for no longer than is necessary. + What is necessary will depend on the circumstances of each case, taking into + account the reasons that the personal data was obtained, but should be + determined in a manner consistent with our data retention guidelines. + Anonymized user data (e.g. metadata requests) will be kept for a maximum of + 5 years which allows us to project future service requirements and provide + usage graphs to the vendor. + </p> + </description> + </agreement_section> + + <agreement_section type="transfer"> + <name>Transferring data internationally</name> + <description> + <p> + There are restrictions on international transfers of personal data. + We do not transfer personal data anywhere outside the EU without the approval + of the Data Protection Officer, unless required to do so by law. + </p> + </description> + </agreement_section> + + <agreement_section type="access-requests"> + <name>Subject Access Requests</name> + <description> + <p> + Please note that under the Data Protection Act 1998, individuals are entitled, + subject to certain exceptions, to request access to information held about them. + </p> + <p> + On receiving a subject access request, we will refer that request immediately + to the DPO. We may ask you to help us comply with those requests. + Please also contact the Data Protection Officer if you would like to correct + or request information that we hold about you. + There are also restrictions on the information to which you are entitled under + applicable law. + </p> + </description> + </agreement_section> + + <agreement_section type="processing"> + <name>Processing data in accordance with your rights</name> + <description> + <p> + We will never use identifiable vendor data for direct marketing purposes. + </p> + </description> + </agreement_section> + + <agreement_section type="transparency"> + <name>Transparency of data protection</name> + <description> + <p> + Being transparent and providing accessible information to individuals about how + we will use their personal data is important for our project. + </p> + <p> + We will ensure any use of personal data is justified using at least one of + the conditions for processing and this had been specifically documented. + </p> + </description> + </agreement_section> + + <agreement_section type="consent"> + <name>Consent</name> + <description> + <p> + The data that we collect is subject to active consent by the data subject. + This consent can be revoked at any time, but would end any vendor + relationship with the LVFS. + </p> + </description> + </agreement_section> + + <agreement_section type="portability"> + <name>Data portability</name> + <description> + <p> + Upon request, a data subject should have the right to receive a copy of their + data in a structured format, typically an SQL export. + These requests should be processed within one month, provided there is no + undue burden and it does not compromise the privacy of other individuals. + A data subject may also request that their data is transferred directly to + another system. This is available for free. + </p> + </description> + </agreement_section> + + <agreement_section type="forgotten"> + <name>Right to be forgotten</name> + <description> + <p> + A vendor may request that any information held on them is deleted or removed, + and any third parties who process or use that data must also comply with the request. + An erasure request can only be refused if an exemption applies. + </p> + </description> + </agreement_section> + + <agreement_section type="design"> + <name>Privacy by design and default</name> + <description> + <p> + Privacy by design is an approach to projects that promote privacy and data + protection compliance from the start. + The DPO will be responsible for conducting Privacy Impact Assessments and + ensuring that all changes commence with a privacy plan. + When relevant, and when it does not have a negative impact on the data subject, + privacy settings will be set to the most private by default. + </p> + </description> + </agreement_section> + + <agreement_section type="audit"> + <name>Data audit and register</name> + <description> + <p> + Regular data audits to manage and mitigate risks will inform the data register. + This contains information on what data is held, where it is stored, + how it is used, who is responsible and any further regulations or retention + timescales that may be relevant. + </p> + </description> + </agreement_section> + + <agreement_section type="breaches"> + <name>Reporting breaches</name> + <description> + <p> + All users of the LVFS have an obligation to report actual or potential data + protection compliance failures. This allows us to: + </p> + <ul> + <li>Investigate the failure and take remedial steps if necessary</li> + <li>Maintain a register of compliance failures</li> + <li> + Notify the Supervisory Authority (SA) of any compliance failures that are + material either in their own right or as part of a pattern of failures + </li> + </ul> + <p> + Please refer to the DPO for our reporting procedure. + </p> + </description> + </agreement_section> + + <agreement_section type="monitoring"> + <name>Monitoring</name> + <description> + <p> + Everyone who actively uses the LVFS must observe this policy. + The DPO has overall responsibility for this policy. + They will monitor it regularly to make sure it is being adhered to. + </p> + </description> + </agreement_section> + + <agreement_section type="consequences"> + <name>Consequences of Failing to Comply</name> + <description> + <p> + We take compliance with this policy very seriously. + Failure to comply puts both you and us at risk. + The importance of this policy means that failure to comply with any requirement + may lead to disciplinary action under our procedures. + If you have any questions or concerns about anything in this policy, + do not hesitate to contact the DPO. + </p> + </description> + </agreement_section> + + <agreement_section type="detail-misc"> + <name>Details: Firmware Vendor Information</name> + <description> + <p> + What: The hardware vendor name, password, GPG public key and content of original + uploaded firmware files.. + </p> + <p> + Why colected: Secure authentication, to allow any possible future audit and to provide + authorised users access to signed firmware files. + </p> + <p> + Where stored: MySQL database on fwupd.org. + </p> + <p> + When copied: Backed up to off-site secure LUKS partition weekly. + </p> + <p> + Who has access: The hardware vendor (filtered by the QA group) and the DPO. + </p> + <p> + Wiped: When the vendor requests deletion of the user account. + </p> + </description> + </agreement_section> + + <agreement_section type="detail-misc"> + <name>Details: Service Event Log</name> + <description> + <p> + What: IP address (unhashed) and REST method requested, along with any error. + </p> + <p> + Why colected: Providing an event log for checking what the various hardware vendors are + doing, or trying to do.. + </p> + <p> + Where stored: MySQL database on fwupd.org. + </p> + <p> + When copied: Backed up to off-site secure LUKS partition weekly. + </p> + <p> + Who has access: The hardware vendor (filtered by the QA group) and the DPO. + </p> + <p> + Wiped: When the QA group is deleted. + </p> + </description> + </agreement_section> + + <agreement_section type="detail-misc"> + <name>Details: Firmware Download Log</name> + <description> + <p> + What: IP address (hashed), timestamp, filename of firmware, user-agent of client. + </p> + <p> + Why colected: To know what client versions are being used for download, and to provide + a download count over time for a specific firmware file. + </p> + <p> + Where stored: MySQL database on fwupd.org. + </p> + <p> + When copied: Backed up to off-site secure LUKS partition weekly. + </p> + <p> + Who has access: The hardware vendor (filtered by the QA group) and the DPO. + </p> + <p> + Wiped: When the firmware is deleted. + </p> + </description> + </agreement_section> + + <agreement_section type="detail-misc"> + <name>Details: Firmware Reports</name> + <description> + <p> + What: Machine ID (hashed), failure string and checksum of failing file, + OS distribution name and version. + </p> + <p> + Why colected: Allows the hardware vendor to assess if the firmware update is working on + real hardware. + </p> + <p> + Where stored: MySQL database on fwupd.org. + </p> + <p> + When copied: Backed up to off-site secure LUKS partition weekly. + </p> + <p> + Who has access: The hardware vendor (filtered by the QA group) and the DPO. + </p> + <p> + Wiped: When the firmware is deleted. + </p> + </description> + </agreement_section> + + </agreement> + +</component> diff --git a/data/tests/example-remote.metainfo.xml b/data/tests/example-remote.metainfo.xml new file mode 100644 index 0000000..8da5996 --- /dev/null +++ b/data/tests/example-remote.metainfo.xml @@ -0,0 +1,28 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!-- Copyright 2018 Richard Hughes <richard@hughsie.com> --> + +<component type="source"> + <id>org.lvfs.stable-remote</id> + <name>Linux Vendor Firmware Service (stable firmware)</name> + <metadata_license>CC0</metadata_license> + + <agreement version_id="1.0"> + <agreement_section> + <name>Warning!</name> + <description> + <p> + The LVFS is a free service that operates as an independent legal + entity and has no connection with your distribution. + Your distributor may not have verified any of the firmware files for + compatibility with your system. + All firmware is provided only by the original equipment manufacturer. + </p> + <p> + Enabling this functionality is done at your own risk, so please do not + file issues with your distributor as they will not be able to help. + </p> + </description> + </agreement_section> + </agreement> + +</component> |