mirror of
https://gitlab.com/hagrid-keyserver/hagrid.git
synced 2023-02-13 20:55:02 -05:00
about: reorder FAQ entries a bit
This commit is contained in:
parent
ecef952ce3
commit
61d644beda
1 changed files with 49 additions and 47 deletions
96
dist/templates/about/faq.html.hbs
vendored
96
dist/templates/about/faq.html.hbs
vendored
|
@ -2,13 +2,46 @@
|
|||
<div class="about">
|
||||
<center><h2><a href="/about">About</a> | <a href="/about/news">News</a> | <a href="/about/usage">Usage</a> | FAQ | <a href="/about/stats">Stats</a> | <a href="/about/privacy">Privacy</a></h2></center>
|
||||
|
||||
<h3 id="no-sign-verified"><a href="#no-sign-verified">Why not sign keys
|
||||
after verification?</a></h3>
|
||||
<h3 id="sks-pool"><a href="#sks-pool">Is this server part of the "SKS" pool?</a></h3>
|
||||
|
||||
The <span class="brand">keys.openpgp.org</span> service is meant for key
|
||||
distribution and discovery, not as a de-facto CA. Client implementations
|
||||
that want to offer verified communication should rely on their own trust
|
||||
model.
|
||||
<p>
|
||||
No. The federation model of the SKS pool has various problems in terms
|
||||
of reliability, abuse-resistance, privacy, and usability. We might do
|
||||
something similar to it, but <span class="brand">keys.openpgp.org</span>
|
||||
will never be part of the SKS pool itself.
|
||||
</p>
|
||||
|
||||
<h3 id="federation"><a href="#federation">Is keys.openpgp.org federated? Can I help by running an instance?</a></h3>
|
||||
|
||||
<p>
|
||||
For the moment, no.
|
||||
We do plan to decentralize <span class="brand">keys.openpgp.org</span>
|
||||
at some point.
|
||||
With multiple servers
|
||||
run by independent operators,
|
||||
we can hopefully improve the reliability
|
||||
of this service even further.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Several folks offered to help out
|
||||
by "running a Hagrid server instance".
|
||||
We very much appreciate the offer,
|
||||
but we will probably never have an "open" federation model like SKS,
|
||||
where everyone can run an instance and become part of a "pool".
|
||||
This is for two reasons:
|
||||
</p>
|
||||
<ol>
|
||||
<li>
|
||||
Federation with open participation requires all data to be public.
|
||||
This significantly impacts the privacy of our users, because it
|
||||
allows anyone to scrape a list of all e-mail addresses.
|
||||
</li>
|
||||
<li>
|
||||
Servers run as a hobby by casual administrators do not meet our
|
||||
standards for reliability and performance.
|
||||
</li>
|
||||
</ol>
|
||||
|
||||
<h3 id="non-email-uids"><a href="#non-email-uids">Why is there no support
|
||||
for identities that aren't e-mail addresses?</a></h3>
|
||||
|
@ -68,6 +101,16 @@
|
|||
on a solution.
|
||||
</p>
|
||||
|
||||
<h3 id="no-sign-verified"><a href="#no-sign-verified">Why not sign keys
|
||||
after verification?</a></h3>
|
||||
|
||||
<p>
|
||||
The <span class="brand">keys.openpgp.org</span> service is meant for key
|
||||
distribution and discovery, not as a de-facto CA. Client implementations
|
||||
that want to offer verified communication should rely on their own trust
|
||||
model.
|
||||
</p>
|
||||
|
||||
<h3 id="revoked-uids"><a href="#revoked-uids">Why are revoked identities not
|
||||
distributed as such?</a></h3>
|
||||
|
||||
|
@ -118,47 +161,6 @@
|
|||
upload keys that can only sign.</li>
|
||||
</ol>
|
||||
|
||||
<h3 id="sks-pool"><a href="#sks-pool">Is this server part of the "SKS" pool?</a></h3>
|
||||
|
||||
<p>
|
||||
No. The federation model of the SKS pool has various problems in terms
|
||||
of reliability, abuse-resistance, privacy, and usability. We might do
|
||||
something similar to it, but <span class="brand">keys.openpgp.org</span>
|
||||
will never be part of the SKS pool itself.
|
||||
</p>
|
||||
|
||||
<h3 id="federation"><a href="#federation">Is keys.openpgp.org federated? Can I help by running an instance?</a></h3>
|
||||
|
||||
<p>
|
||||
For the moment, no.
|
||||
We do plan to decentralize <span class="brand">keys.openpgp.org</span>
|
||||
at some point.
|
||||
With multiple servers
|
||||
run by independent operators,
|
||||
we can further improve the reliability
|
||||
of this service.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Several folks offered to help out
|
||||
by "running a Hagrid server instance".
|
||||
We very much appreciate the offer,
|
||||
but we will probably never have an "open" federation model like SKS,
|
||||
where everyone can run an instance and become part of a "pool".
|
||||
This is for two reasons:
|
||||
</p>
|
||||
<ol>
|
||||
<li>
|
||||
Federation with open participation requires all data to be public.
|
||||
This significantly impacts the privacy of our users, because it
|
||||
allows anyone to scrape a list of all e-mail addresses.
|
||||
</li>
|
||||
<li>
|
||||
Servers run as a hobby by casual administrators do not meet our
|
||||
standards for reliability and performance.
|
||||
</li>
|
||||
</ol>
|
||||
|
||||
<h3 id="older-gnupg"><a href="#older-gnupg">
|
||||
I have trouble updating some keys with GnuPG. Is there a bug?
|
||||
</a></h3>
|
||||
|
|
Loading…
Reference in a new issue