[AppStream] Adding agreements to AppStream

Richard Hughes hughsient at gmail.com
Thu Apr 5 17:44:12 UTC 2018


Hi all,

We have three fuzzy requirements in our enterprise distribution at the moment:

 * show a localized warning when you enable the LVFS firmware remote
for the first time -- consisting of paragraphs and bullet lists
 * show a localized agreement to explain a privacy policy for a web
service (e.g. to comply with the GDPR)
 * show a localized End User Licence Agreement after a package is installed

I'm super tempted to suggest an <agreement> tag upstream that allows
us to do all three in a common way. The LVFS already has a metainfo
file and so the privacy policy can be included (and translated) there.
Each remote could grow it's own component which allows us to add some
kind of warning text when enabling the remote. Currently the fwupd
remote .ini format doesn't include any kind of warning, but we can
trivially include a link to the upstream https:// link so it gets
downloaded and shown to the CLI or GUI user.

Another customer has asked us to investigate including EULA text in
metainfo files; whilst I really think that EULAs should be agreed to
by the *end* user (i.e. the one opening the GUI app for the first
time) it seems various lawyers disagree on what "end" means. We either
let the lawyers do something horrific (for instance doing an
interactive prompt in an rpm scriptlet) or we give them the tools to
do it properly, with translations and proper formatting.

The GDPR is new legislation that all companies doing business in EU
must adhere to. Each company needs to do a privacy policy (such as
https://fwupd.org/privacy ) -- but other companies are a lot less
transparent. I was hoping to include a privacy policy for the various
web-technologies we use in the GNOME desktop, and make it possible to
review them in the users native language in something like the
gnome-control-center privacy panel. No designs yet, as we have no data
for a mockup.

The proposals would look something like this in XML format:

<component type="desktop">
  <id>org.gnome.Software</id>
  <name>GNOME Software</name>
  ...usual contents for a desktop app...
  <agreement type="eula">
    <agreement_section>
      <description>
        <p>
          If it breaks, you get to keep both pieces.
        </p>
      </description>
    </agreement_section>
  </agreement>
</component>

and:

<component type="source">
  <id>org.lvfs.stable-remote</id>
  <name>Linux Vendor Firmware Service (stable firmware)</name>
  <agreement type="warning">
    <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 updates for
          compatibility with your system.
          All the content is instead provided 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>

and finally:

<component type="general">
  <id>org.fwupd.lvfs</id>
  <name>Linux Vendor Firmware Service</name>
  <agreement type="GDPR">
    <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>
    ...lots of other content...
    <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_detail>
      <name>Firmware Reports</name>
      <value key="what">
        Machine ID (hashed), failure string and checksum of failing file,
          OS distribution name and version.
      </value>
      <value key="why-collected">
        Allows the hardware vendor to assess if the firmware update is
working on
        real hardware.
      </value>
      <value key="where-stored">
        MySQL database on fwupd.org.
      </value>
      <value key="when-copied">
        Backed up to off-site secure LUKS partition weekly.
      </value>
      <value key="who-has-access">
        The hardware vendor (filtered by the QA group) and the DPO.
      </value>
      <value key="wiped">
        When the firmware is deleted.
      </value>
    </agreement_detail>

  </agreement>

</component>

This additionally has agreement_detail as a tag name, which I included
so I could format the "w" words into a table when converting it to an
HTML file. It also means you get to think about all the values -- I've
tried to make them easy to understand. I could just include them as an
agreement_section and use more words.

Comments very welcome, and sorry for the over-long email. I've got a
test branch implementing this API
https://github.com/hughsie/appstream-glib/commits/wip/hughsie/privacy-gdpr
if you're interested in longer XML examples.

Richard.


More information about the AppStream mailing list