Re: [Tails-dev] Testing the ISO Verification Extension

Borrar esta mensaxe

Responder a esta mensaxe
Autor: Giorgio Maone
Data:  
Para: The Tails public development discussion list
Asunto: Re: [Tails-dev] Testing the ISO Verification Extension
Status update as of latest commit (extension version 0.2.1) follows.

On 12/11/2015 17:38, sajolida wrote:
> 2. The extension is great because it preserves its state even if you
> close the tab. You can open it again and the result of the verification
> is still there. Still, I think we should reset its state in some cases:
>
>   - When the download is finished and the user clicks on the "next"
>     button. :maone:

Done: once you click "Next", the filesystem browser is shown with the
file highlighted while in the background the page gets reloaded and goes
in its initial state.

>
> 3. Regarding resetting the state of the extension, we were wondering how
> this interacts with the Private Browsing of Firefox. Is is reseted when
> going in and out of Private Browsing?

The extension syncs with the download manager, hence if a download has
been initiated from a private window it won't be available anymore once
you close that window (even though if you already have the UI opened in
another window it will still show its state until reloaded).
Of course the state is not persisted across sessions if the download
started from a private window.
>
> 4. We looked at the SSL information embedded in the code (conf.json) and
> there's the fingerprint of the certificate for tails.boum.org. According
> to the specification on
> https://tails.boum.org/blueprint/bootstrapping/extension/#index5h2 it
> should instead include "root certificate of the authority expected to
> sign the certificate of https://tails.boum.org/". We don't want the
> extension to break when boum.org renew their certificates. :maone:

Done, maybe.
Now you've got the flexibility of choosing to pin the domain cert, the
issuer's (CA's) cert or both.
I decided not to let you pin on the actual root, but on the nearest
issuer in the chain (Gandi, in your case), because it seemed to me that
pinning on a root CA which has many resellers (like "The UserTrust
Network", in your case) would have sensibly reduced the security of this
setup.
If you actually prefer the root to be tested, rather than the
intermediate, I'm gonna implement it as a further option.

>
> 5. In 2cf4737 you added a class to the <html> tag. We can't really do
> that in ikiwiki. So is it possible to move this somewhere else in the
> code? Maybe on #download-and-verify? :maone:

Yes, just move the "dave.js" <script> element down in the page so that
it runs after the element has been inserted in the DOM. :tchou: ?

>
> 6. We changed the user-visible strings about the supported browser in
> 0e7d362. I hope this didn't break anything.

Everything should be still worked as expected.
> 7. We added an alternative display between outdated Firefox versions and
> unsupported browser vendor in 67f4e01. Giorgio: do you think you can
> adjust the sniffer accordingly?

I don't believe it's a good idea, as users may be just faking their UAs
and getting things even more confused.
One change which I believe would be more useful would be adding direct
links to the extension(s) packages with a "I'm actually using Firefox >=
38" and "I'm actually using Chrome >= 44" labels, so people can override
our sniffing if misleaded by privacy countermeasures and install the
extension right away (at least on Firefox, the browser add-on installing
machinery will perform its own, much more reliable, version checking at
that point).
>
> 8. We'd like to change the display of progress information:
>
>   - download speed from Kb/s to KB/s
>   - downloaded size from MB to MiB
>   - displayed ETA to adjust to "1 minute" and "seconds" (keeping in
>     mind that all user-facing strings should be in our HTML so that
>     people can translate them)

>
> Giorgio: is that possible? I guess we need to embed "minutes",
> "minute", "seconds", and "second" in the HTML.

Done. You can still the old measure units as well, they're both
accounted for.

In order to let you hide/show your measure unit fields automatically via
CSS depending on the current count, DAVE is setting a
'data-value="${currentValue}"' attribute on the parent element, with the
same value expressed in different measure units (properly floored) or
"???" if floor(value_in_unit) gives 0.
So,

<span data-value="1">
<span class="eta-mins">1</span>
<span class="plural">minutes</span>
<span class="singular">minute</span>
</span>
<span data-value="90">
<span class="eta-secs">90</span>
<span class="plural">seconds</span>
<span class="singular">second</span>
</span>

Will just display
1 minute

and

<span data-value="???">
<span class="eta-mins">???</span>
<span class="plural">minutes</span>
<span class="singular">minute</span>
</span>
<span data-value="20">
<span class="eta-secs">20</span>
<span class="plural">seconds</span>
<span class="singular">second</span>
</span>

will give
20 seconds.

Look at the current dave.css to see how the magic is done.

>
> 9. There's no way of going back to the previous steps using the "Back"
> button of the browser. That was no specified in the wireframe and we're
> wondering whether that's needed at all but apparently, in other such
> scenarios of step-by-step processes inside a single page, sometime the
> "Back" button of the browser is mapped to going back to the previous
> step. For example, right now, as the extension remembers its state,
> there's no way of canceling the download once it started (you can only
> "pause" it). But this particular case can be solved differently maybe.

You've got a "Cancel" button now.
>
>
>
> 11. Once the download is over it should go from #download-button to
> #download-text. :maone:

Done
>
> 13. The #download-button-size is updated with the download URL once
> clicked; but on the wireframe the ISO size remains displayed. Granted,
> now that we have more complete progress indicators that would be a
> duplicate information. Maybe we can empty this completely then? :maone:

Unless I'm misunderstanding, it all depends on the classes set on the
HTML elements, so you can decide at any time.
>
> 14. When clicking the download button, we're proposed an alternative
> between "Open with [Archive Manager (default)]" and "Save File". I
> understand that this corresponds to the Content-Type sent by the HTTP
> server. But in our scenario it doesn't make sense to open the ISO image
> with any other application (as we want people to verify it before doing
> anything, and then mostly likely to install it on a USB with special
> instructions). So Giorgio, since you have very special powers on web
> browers, could we do something to propose saving only? Maybe overriding
> the MIME type or jumping straight to the saving dialog?

I'm gonna try, not done yet.

>
> 15. In attachment you'll find a patch to change the Tails logo from
> white on purple to purple on white :)
> I hope that's the proper image format. :maone:

Done.


--
Giorgio Maone
https://maone.net