<?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>