remote-help-assistant team mailing list archive

[Erpiu <pierre.fischer@xxxxxxxxxx>]

Hi everybody,

Here is my feedback on Andrew's various proposals :

Proposals 1 and 2 :
That's a nice idea, which should allow us to provide unexperienced users
(on the sharer side) with a straightforward solution. 
A few comments about it :

When the software on the sharer side  is configured in the proposed
"simplified" operating mode and whenever the saved key of the helper
needs to be changed  (for any reason), it should also be possible to do
it remotely without "sitting at the sharer's computer".  I suggest there
is a quite easy way of setting the software back into the standard
operating mode, ie an unexperienced user should be able according to
instructions given to him on the phone to reset the configuration option
("which is not editable from within the assistant"). For instance this
could consist in editing or simply removing a hidden file.

While considering Andrew's proposal, we could perhaps go a little bit
further and imagine three operating modes :
a) the standard mode, which is the current one, where helper and sharer
check their keys and where the sharer can select the computer he wants
to connect to.
b) a "preferred" mode, where the software, when in sharer mode, can
choose to connect to its "preferred" helper, without needing to give any
IP address and check keys. This "preferred" helper is one computer to
which the user was connected previously in "standard" mode and that the
user selected as such by checking an option "Make this helper my
preferred helper for the next time"
c) a "forced preferred" mode, which is the mode proposed by Andrew,
where the software always runs in sharer mode and connects to its
preferred helper. This mode is set through the configuration option as
proposed by Andrew or even by the user on the sharer side who could
check an option "From now on, I'd like to always run the software this
way with my preferred helper".

These are just ideas....

Proposal 3 :
I fully agree on this proposal. Having such an online documentation will
allow us to explain unexperienced users the benefits of the software
and, at the same time, to provide technical people with appropriate
level of details that will make them confident enough in the Remote Help
Assistant approach. Last but not least, as proposed by Andrew in 4),
this will allow us to simplify the user interface.

Proposal 4 :
As already discussed with Andrew, it's important to have a very
consistent user interface and to always use the same term to refer to a
given notion. Thanks to the online documentation, we can now use
simplified terms to refer to quite complex notions. Displaying
fingerprints as dates is a great idea that make their checking very
easy. But speaking only of dates throughout the whole software to refer
to the related notion (ie public keys) makes me a little bit
uncomfortable. In messages such as "Check their dates", "Their dates
have changed", "I trust these dates"... we completely forget the
underlying  notion of security. In the French translation I did, I've
used the term "key" and explained in a short sentence that keys are used
to secure the link and are displayed as a series of dates for
convenience. But, as stressed by Andrew, the term key is likely to
confuse non-technical users.
Perhaps, terms such as "passport" or "ID" would be more suitable. We
would use a term that non-experienced users will understand and that
still corresponds to the reality. Computers would swapped their
respective passports (to check their identity), these passports would be
displayed as a series of dates to make the checking process easier, the
"change of a passport" would raise an important warning.....
Again, these are just ideas for discussion. 

Proposal 5:
I fully agree on Andrew's proposal related to the way of handling a bad
key (or bad dates, or bad passport...)

I've jumped only recently into the project and I don't know what has
been discussed until now. So, whenever the suggestions here above have
already been discussed, please let me know. I don't want to make you
re-open subjects that have already been decided.

Regards,

Pierre Fischer (aka Erpiu)

Attachment: smime.p7s
Description: S/MIME cryptographic signature