[Tails-ux] Greeter mockups

Delete this message

Reply to this message
Autor: spencerone
Data:  
A: tails-ux
Assumpte: [Tails-ux] Greeter mockups
Hey,

>>
>> Spencer:
>> Word. So a low-tech resolution is needed, then, yeah? Maybe a simple
>> background image and dialog color/font changes are enough to spoof
>> another OS.
>>
>
> Alan:
> Things aren't that easy. Please see
> https://tails.boum.org/blueprint/update_camouflage_for_jessie/
>


This page details what is needed to accomplish the existing approach to
Desktop Camouflage, which seems effective, but convoluted due to the
micro-version releases that need accommodating. What I am suggesting
mostly addresses the booting experience, but could still be effective
for entire sessions. The Greeter could easily load Tails with an OS
specific background and custom window color/typeface swap. Easily, as
in one or two of the listed requirements instead of all; maybe only a
way to enable the specified settings and the respective themes. This
presumes that background, colors, and fonts are so universal that they
don't require a unique theme for each 0.0.x release.

But, if the attack requires more than what I am suggesting to be
effectively protected against, or, if there is more to the difficulty of
upkeep than the version compatibility count, please ignore this.

>>
>> Word. Here[0] is the requested info. It is also on the blueprint[1].
>> It is a .pdf.
>>
>
> May you please send me the source of this PDF so that I can modify the
> blueprint?
>


Here ya go[0].

[0]: GreeterRationale.zip

>
> Also I'd like to go through past threads and explain other
> choices we've made before, in order to present a comprehensive summary
> of things.
>


Cool, if you come across designations that need my explaining, let me
know. Or, if you want me to do the search, I'm down, though I would
have to defer to others for explanations.

>>
>> *Redline Document* A document with pixel-perfect alignment/spacing
>> callouts used to
>> establish designated composition of elements, and then track their
>> changes. A DIY visual ticket/bug/change tracker, if you will.
>>
>
> If it's fine to you, I'd like to:
>
> - finalize the presentation of our proposal and call for
> reviews/comments (this month)
> - start integrating things in Glade/GTK and ask this list for comments.
>


Sounds good; exciting! If you need anything, hit me up. I am on the
updated Flow, now, but there is still some bandwidth.

>
> I don't think that this document is needed, but if you do, feel free to
> create it and point me to documentation on how to use it.
>


No need. It only does two things.

• Helps developers implement details set by designers - Glade makes this
unnecessary
• Allows change tracking - Glade might offer something like this, or we
can just start visually capturing and comparing dialogs at each
iteration, or, and I recommend against this, we can track changes in
Redmine.

I am not certain of the value in recording such minor changes, other
than to just be as open as possible, but given the amount of existing
tickets and things to manage, it might be wasteful.

Wordlife,
Spencer