Hi!
spriver:
> the Tails Project wants to have a social contract […]
> Now we want your help and want to hear your opinion: feel free to
> comment and/or edit the draft, be encouraged to discuss it on the ticket
> or as an answer to this mail.
Here we go! Amazing work, thanks :)
> Through our community standards and the code we write and deploy, we
> provide tools that empower all people
I'd rather not reduce what we collectively produce to "code".
How about:
Through our community standards, the tools we build, document,
translate and promote, we provide tools that empower all people
?
> and advance these rights.
I have two concerns with this:
* The text doesn't make it clear to me which rights this refers to.
* I'm no big fan of the "rights" idea, but we can perhaps agree on
something once the above is clarified.
Just dropping this piece of text doesn't seem to lose anything IMO: we
already have "empower all people".
> Tails will always be free to use, remix, adapt and distribute.
I think we should not ignore the exception we make for firmware here,
and try to be upfront about it, e.g. as we tried to do on our License
page:
https://tails.boum.org/doc/about/license/
> When we write new components of the Tails system, we will license
> them in a manner consistent with the Debian Free
> Software Guidelines.
In there, "new" suggests to me that there have been exceptions in the
past. Are there any? If not, let's be clearer and instead write: "All
the components of Tails that we create ourselves are, and will be,
licensed in a manner […]".
> work on usability issues which we include in Tails
Seems that there's a few words too few or too many in here, no?
> Mistakes sometimes happen. We will be honest about them and fix them
> when they are reported to us.
I wonder if "when" is too vague or too precise here. On the one hand
it suggests we promise to correct every mistake we make (which seems
impossible to me, or just a bad idea, as pretty often we have other,
higher priority things to do); on the other hand it is very vague wrt.
the timing, and doesn't promise much in the end, which may make the
text a bit weak, particularly wrt. mistakes that affect users' safety.
So I wonder if we could perhaps be more precise, and make a stronger
commitment, about a better defined set of mistakes, i.e. those that
affect the safety of Tails users.
What do you think?
> 5. We will not hide problems
>
> Our entire bug report database is and will stay open for public view
> at all times. Reports that are filed here will promptly become
> visible to others.
I'm not sure we can reasonably promise this. Currently, a great part
what qualifies as "bug reports" filed to us is sent to our help desk,
and only some of that is published; e.g. I'm pretty sure that many
problems experienced by Tails users never make their way to Redmine,
because our help desk deems them not important enough to be worth
fixing. Also, our help desk is researching a Request Tracker tool
they'll use, and I bet that some of its content might qualify as
a subset of "Our entire bug report database".
Taking a step back, what matters most *to me* about the "we will not
hide problems" statement is not claiming that we're aiming for full
transparency, for two reasons: first, I'm not sure we can easily agree
about this being a worthy goal, ideologically speaking, within the
project; second, this would require spending lots of energy to
sanitize and publish lots of information that won't be very useful to
anyone; third, the next paragraph states that there are exceptions
anyway so it'll never be full transparency.
What matters to me is rather:
* Except when some kind of responsible disclosure is deemed best for
our users, we will not *actively* hide problems that affect Tails
users, e.g. we won't be dishonest about our mistakes and the limits
of Tails. This is already kinda covered in the paragraph about
mistakes earlier, and in the next statement about honesty.
So perhaps we don't need additional text to state this.
* We want to produce Tails in a way that encourages participation,
which requires publicly documenting what can be improved. This is
somewhat off-topic in a section titled "We will not hide problems",
so I suggest we create a new section about how Tails is produced,
that would include this bit and the "As Tails is created in
a transparent manner […]" that feels slightly out of place in the
"4. We will never harm our users intentionally" section.
> 6. We are honest about the capabilities and limits of Tails and
> related technologies
I think that "related technologies" is way too broad. How about
"technologies it relies upon" instead? This is what matters, right?
> fits their security needs
This feels unnecessary after "adequate for their use case", so I would
drop it.
> whether it can and should be trusted
I would prefer the active voice, a phrasing that doesn't suggest
there's a universal (sic) answer to this, and a concept of trust
that's not binary, e.g.:
We encourage users to inform themselves and decide whether Tails is
suitable for their use case and how much they can trust it.
> We provide and explain methods of verification so that anyone can
> ensure that they downloaded a genuine copy of Tails.
This feels out of place in a section titled "6. We are honest about
the capabilities and limits of Tails and related technologies".
I'm not sure why mentioning this specific security feature of the
Tails ecosystem (and not any other such feature) is very relevant in
our social contract.
Cheers,
--
intrigeri
