Re: [Tails-ux] Wireframes for DAVE 2

intrigeri:
> 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"?

This link will be there. It will change label depending on what the user
did already on the page and will display either:

- Skip download: when page loads
- Skip verification: after the user click "Download ISO image"
- Next: after the verification is successful

My question is whether we want to put, for example, another scary
warning in a popup when the user clicks on "Skip verification".

I'll try to do that anyway if that's easy enough as I already have some
text to explain why verification is useful :)

>>> 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!
>
> :)

>From my paper tests (only 3) nobody went down the page andcared at all
about this OpenPGP thing they didn't know about. So it was
definitely fine, even unfolded. But it's true that the fact that this
was on paper maybe limited how much people would scroll "just to have a
look".

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

Sorry, I meant "in the *way* it is introduced".

You'll find in attachment how the current version of this section looks
like. The links will display the toggled sections.

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

Yeah, it think that was the idea: to avoid having people download a new
key each time (for simplicity and also for TOFU). But you're right that
the date is also another critical piece of info that needs to be trusted
every time. And we're also not explaining very clearly right now the
(hypothetical) problems of importing the key more than once.

So all-in-all, I think that this indication about "importing it only
once" is not very helpful. So I removed it and instead added the date
when the signing key was last updated (just for info).

If you think that's helpful, I'll have to find a way of "automating" this.

I created #14711 to track "Tell people to update the key on failure" but
I won't work on this myself as part of the update to DAVE 2.

I already have quite a few more exciting things that are slightly
off-topic but that I want to do while I'm mangling those pages :)

> 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.
And it doesn't help people to know when updating the key is useful and
when not which is what we're trying to improve here. We could decide to
instruct people to download a new key every time, but this would be
orthogonal to the download method, whether it's HTTPS or gpg2.