Re: [Tails-ux] Wireframes for DAVE 2

Hi,

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

OK, sounds great.

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

Fine. Not a blocker IMO.

I tend to briefly prefer explaining up-front why verification is
useful (as a motivating factor to follow the recommended path) than
warning when "Skip verification" is skipped, but I trust your
expertise more than mine :)

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

Great :)

> But it's true that the fact that this
> was on paper maybe limited how much people would scroll "just to have a
> look".

Possibly.

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

Looks good.

I'm not sure I understand what use cases the "basic OpenPGP
verification" is useful for, but I expect some design doc will clarify
it for me some day so you don't have to explain me everything every
time I have a doubt :)

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

Sounds nice if it's not too much work to automate.

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

Sure.

Cheers,
--
intrigeri