Re: [Tails-ux] Wireframes for DAVE 2

Hi,

sajolida:
> intrigeri:
>> Where does the "Skip download" link point to?

> This link always points to the next step in all its different forms:

> - Skip download
> - Skip verification
> - Next

> Depending on how painful or intrusive we want to be we could add a popup
> or something scary (on top of the small warning sign).

> Do you think I should work on this right now or that we can keep this
> idea for the future?

I lack the background context and rationale behind this link to have
a useful opinion here, sorry. Besides, do you mean "this" == "adding
that link" or "this" == "add a popup or something scary"?

>> sajolida:
>>> I'm also sending the detailed OpenPGP instructions for the sake of
>>> completeness but please don't review them in details because that's out
>>> of scope for this project. But you're welcome to comment on how they are
>>> integrated and whether they would be problematic for people not
>>> interested in following them.
>>
>> At first glance it makes the whole page much bigger and more daunting.
>> Perhaps make the text toggleable and hidden by default?

> Good idea! My rationale for displaying it fully from the start is that
> it's at the bottom of the page ("below the fold" in the jargon) and it
> won't bother people who don't want to read it. But I also don't really
> see a downside in hiding it behind a toggle, so I'll try that!

:)

>> Also, the way it's presented (at the bottom of the page) does not make
>> it obvious to me that this verification method can replace the
>> other ones.

> Right now I'm actually advertising them as something "optional" that you
> can do "on top of".

ACK

> But you're right, people should feel like they can do OpenPGP *instead*
> of the other ones. At least in terms of security it's equivalent (at
> long as they verify the date carefully).

> So I'll change this in the same it is introduced

Missing word?

> but I don't think I
> will go as far as changing the structure of the page to accommodate more
> space for it. I'll see...

Sure, agreed.

>> I don't know if that's part of the "detailed OpenPGP instructions"
>> I should not review; feel free to just drop a note about this
>> somewhere in your todo list and ignore my comment for now:
>> FWIW, in supported_browser.pdf I read "All our ISO images are signed
>> with the same signing key, so you only have to import it once":
>> I understand we want to avoid exposing the user to importing
>> a potentially wrong key the 2nd and further time they verify the ISO,
>> but we see many reports (e.g. on our XMPP support channel and
>> tails-dev@) from users having issues because they try to verify our
>> ISO using an outdated signing key that they imported a while ago and
>> that hasn't our current subkeys.

> Yeah, that's a bit out of scope but that seems important. I just didn't
> want people to review all the little steps in details.

> I removed a note about the transition to our new signing key that
> happened in 2015 but you're talking about something different here.

Absolutely.

> We could also:

> - Tell people when the signing key was updated last. They might be able
> to relate this to when they did the verification last time, though
> that might be hard for them to remember.

> - Add a step for them to verify the validity of the key. With a command
> to output info about the key and compare it with what they should
> expect from an updated key.

> - Tell people to update the key on failure.

> - Combine these three options depending on the cost/benefit of each :)

"Tell people to update the key on failure" seems the best option to
me: it does not add any mandatory step one must follow every time,
does not require to have good memory of such nitty-gritty details, and
it does handle the failure mode that happens ~1/year. The main
drawback I guess is that it adds another conditional ("if failure
then") to the doc, which can be hard (for you) to structure properly
and (for users) to follow.

Now, I don't remember very clearly why we don't make users download &
import the signing key from our website every time they want to do
OpenPGP verification. I guess that's explained in the upcoming design
doc but I'm too lazy to find the branch right now. Was the idea to
avoid having to trust our website + the connection to it every time,
i.e. benefit from some kind of TOFU? But then if we can't trust that,
then we can't trust the rest of the OpenPGP verification doc either,
which IIRC includes another critical piece of info: the signature date
(that's intended, if I'm not mistaken, to protect against mirrors
serving an outdated ISO with its valid signature, both renamed to
pretend it's the latest one).

Another option would be `gpg2 --recv-keys $FINGERPRINT'; we could not
do that in the past, but I *think* the context as changed because
recent GnuPG now do check that the downloaded key's fingerprint
matches the one passed on the command line, but I might be
mis-remembering so if we go this way, someone should double-check and
verify what distros have a good enough gpg2. Regardless, we still need
to trust our website + the connection to it, otherwise $FINGERPRINT
can't be relied upon, so quite likely this idea is useless.

Cheers,
--
intrigeri