X-Git-Url: https://git.cworth.org/git?a=blobdiff_plain;f=meetings%2Fhd2015.mdwn;h=21f80756ebedb24aff7d02ecbefd755103ee2725;hb=bbdcbf63583351af9c0954cb92316f5bb3a8509a;hp=3511e5525bee9072526ab61b1e91cc1869dd1b61;hpb=f175a1114189a236135149daf4d8f279d88104ea;p=notmuch-wiki

diff --git a/meetings/hd2015.mdwn b/meetings/hd2015.mdwn
index 3511e55..21f8075 100644
--- a/meetings/hd2015.mdwn
+++ b/meetings/hd2015.mdwn
@@ -7,6 +7,13 @@ What, Where, When
 
 * Video streaming should be [available](https://wiki.debconf.org/wiki/DebConf15/Videostream/Amsterdam)
 
+* We will probably use
+  [gobby](https://packages.debian.org/jessie/gobby) for collaborative
+  editing. Unfortunately the infinote backend for emacs-rudel seems
+  not work. After installing gobby (>= 5.0), run
+
+      % gobby infinote://gobby.debian.org/debconf15/bof/notmuch-privacy-and-security
+
 
 Agenda
 ======
@@ -29,30 +36,42 @@ Moving parts for secure e-mail
 
 Security and privacy concerns
 -----------------------------
-* privacy leaks rendering messages
 * message-id collisions
+* rendering "rich" messages
+  * network access in front ends
+  * safe rendering of HTML
+* rendering security information
+  * spoofing signatures
+  * partially signed messages
 * Oops I just sent...
   * wrong key selection during composition
   * reply (message mode defaults)
+  * opportunistic signing and encryption
+  * using markup for security
 * inline PGP
-
-* webmail authentication/authorization (multiple users?)
-* webmail message escaping (XSS, etc)
+* webmail
+  * authentication/authorization (multiple users?)
+  *  message escaping (XSS, etc)
 * shell injection
 * terminal escape sequences
 * S/MIME support
   * signatures
   * encryption
+  * integration with other keyrings
 * reproducible builds:
   [sphinx man pages](https://reproducible.debian.net/rb-pkg/testing/amd64/notmuch.html)
+* decryption happens in the CLI rather than the UI
+  * when using the UI and the CLI on different machines (so called "remote" mode), this leads to some undesirable and odd behaviour:
+    * decrypted content is passed across a potentially insecure channel (though usually ssh)
+    * the CLI needs access to keys, which can be awkward or impossible
 
 Usability as security?
 ----------------------
 
-* indexing encrypted mail
+* Indexing encrypted mail
+  * incremental re-indexing?
 * Memory Hole protected headers
-* key selection indicators during composition
-
+* Key selection indicators during composition
 
 Breakout sessions
 -----------------
@@ -63,31 +82,3 @@ Reportbacks
 -----------
 
 
-
--------------------------
-
-
-more complete agenda:
-
-        * S/MIME signatures and encryption
-            * test suites
-            * integration with other keyrings
-            * signature only (easyish) versus encryption (more work)
-        * Improving the security of the Emacs MML mime composer
-            * automated "encrypt-when-i-have-keys-available" mode or other convenience functions?
-            * can an adversary force signatures based on quoted text?
-            * generate memory-hole-style messages
-        * Searching of GPG encrypted mail
-            * possible implementation mechanism: "notmuch reindex --with-filter=decrypt"
-        * Auditing and fixing "webbug" style problems in front ends
-            * can we instruct emacs to restrict all network access from notmuch?
-            * what other frontends might call out to the network?
-        * Making notmuch build reproducibly
-            * https://reproducible.debian.net/rb-pkg/unstable/amd64/notmuch.html
-        * Protect against spoofed signature verification?
-            * how do we deal with multipart messages where only a subtree is signed?
-            * are other sorts of spoofing possible?
-        * read and display memory-hole-style messages
-        * "safe" ways to display html parts (e.g. without text/plain alternatives)
-
-