[AppStream] Adding agreements to AppStream

Tue Apr 10 03:16:32 UTC 2018

2018-04-05 19:44 GMT+02:00 Richard Hughes <hughsient at gmail.com>:
> 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.

Sounds good. For that to work we need to have a "remote" component
type upstream first though.
I would suggest either type="repository" or type="remote", with a
preference for the first one as it feels more explicit.

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

While I would not want to add code for a feature that can be achieved
better some other way (showing the EULA on first run of the
application), if we add facilities to AppStream for GDPR & Co. anyway,
we could support EULAs upon installation of a program without much
overhead and pretty easily. So in that case, I have no objections.

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

That sounds like a great idea!

> The proposals would look something like this in XML format:
>
> <component type="desktop-application">
>   <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>

Looks good to me - but what's a "warning" type agreement? Is an
agreement a warning?

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

Uuh, that looks complex. For these sections, do we need machine
readable identifiers? If so, I would highly likely ask you to draft
the specification for that, because you are deeper into that matter
and have easier access to lawyers (at least it looks that way) who can
advise on what sections would actually make sense.

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

That looks more like an agreement_summary to me, the details are
actually in the <agreement/> full text.

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

I like long emails and apparently don't manage to produce shorter ones
by myself ;-)

What I am worried about is us potentially duplicating massive amounts
of text in AppStream data, because I guess many agreements will be
similar or the same, especially for projects which publish a lot of
software, like GNOME or KDE.
Therefore, I wonder if we should allow projects to define an agreement
template in some way, and then reference that:
    <agreement url="https://gnome.org/legal/privacy.xml"
id="gnome-privacy-agreement"/>
This would mean that appstream generators for distributions would have
to download the XML document and cache it somewhere for the software
center to download on-demand, or integrate it into the output XML.
This would also allow updating the document in many projects
immediately and translating it once, and not all over again for each
project.
The XML document referenced by the URL would just contain the
<agreement/> block.
Not sure if that is a good idea, but I feel like we might run into
trouble if your current proposal is accepted widespread (with lots of
data duplication, much larger collection XML/YAML files, projects
having problems to translate the agreements properly, ...).

Speaking of collection XML: Can we combine multiple different
agreements in the same document without issues? I assume the answer is
yes, but it's better to be sure.

For your <agreement_detail/> block (where I currently feel
agreement_summary is more accurate) each value tag would need a <p/>
paragraph child, so we can easily translate those texts as well (and
that would also be more consistent with the rest of AppStream). We
could potentially also only allow only one paragraph in there.

That's all I have right now, I will look at your current implementation next :-)

So, in general +1 from me for the feature in itself, but I'm not 100%
sure about the implementation details yet. It could be useful if you
would write a PR for the AppStream specification at some point (it's
simple Docbook) so we can be sure we agree on the same thing and
nothing is ambiguous, as this is quite a huge addition to AppStream.

Thanks a lot for the work!
    Matthias