1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
|
* The current rules for when an Activity Entered is accepted allow it to
refer to an older activity than the last one. If echoing is disabled,
two Activity Entered could be sent, each pointing at the most recent
Activity Seen, and there would be no proof of the order of the two.
Reordering the two might cause different results though.
This is not only a problem when 2 developers are connected; it also
lets a single developer produce a proof chain that is ambiguous about
what order they entered 2 things.
Fix: Make a Activity Entered have a pointer to the previous Activity
Entered that was accepted, in addition to the existing pointer. Then
when one developer sends two Activity Entered that don't echo, there's
still proof of ordering. When two developers are typing at the same
time, only one of their inputs will be accepted. The client should only
consider an Activity Entered legal if it points to the last Activity
Entered that the client saw.
May as well make Activity Seen have a pointer to the last accepted
Activity Entered as well. This will make it easier when supported
multiple developers, as each time a developer gets an Activity Seen,
they can update their state to use the Activity Entered that it points
to.
* Leave the prevMessage out of Activity serialization to save BW.
Do include it in the data that gets signed, so it can be recovered
by trying each likely (recently seen) Activity as the prevMessage, and
checking the signature.
(If doing this, might as well switch to SHA512, since hash size does not
matter.)
* loadLog should verify the hashes (and signatures) in the log, and
refuse to use logs that are not valid proofs of a session.
(--replay and --graphvis need this; server's use of loadLog does not)
Everything else in debug-me checks a session's proof as it goes.
And, everything that saves a log file checks the proof as it goes,
so perhaps this is not actually necessary?
* Add a mode that, given a log file, displays what developer(s) gpg keys
signed activity in the log file. For use when a developer did something
wrong, to examine the proof of malfesence.
* gpg key downloading, web of trust checking, prompting
Alternatively, let debug-me be started with a gpg key,
this way a project's website can instruct their users to
"run debug-me --trust-gpg-key=whatever"
* How to prevent abusing servers to store large quantities of data
that are not legitimate debug-me logs, but are formatted like them?
Perhaps add POW to the wire protocol? Capthca?
The user's email address is sent to the server when starting a debug-me
session, and once the session ends, the server emails the log file
to that address. This serves two purposes:
1. It makes sure that the user gets a copy of the session log,
which the developer cannot delete.
2. Once the server has emailed the log, it's free to delete its
copy to free up disk space. Since servers don't have to retain
log files for long, this makes them unattractive to abusers
who might otherwise try to store large quantities of data.
* --server --replicate=host could connect to the other server and forward
sessions to it. It should be easy to make the replicate bi-directional,
so a developer could connect to the other server and their messages be
sent back to the first server.
|
