Re: [Tails-ux] Wireframes for DAVE 2

intrigeri:
> The minimum supported versions of the browsers will likely need to be
> updated for WebExtensions.

Yeap.

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

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

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

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

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