Notes on IME

src/SUMMARY.md

@@ -13,7 +13,9 @@
     - [Profile Encryption & Storage](./profile_encryption_and_storage.md)
     - [Android Service](./android.md)
     - [Message Overlays](./overlays.md)
+    - [Input](./input.md)
 - [Cwtch Servers](./server.md)
+    - [Key Bundles](./key_bundles.md)
 - [Development](./development.md)
 - [Deployment](./deployment.md)
 - [References](./references.md)

src/input.md

@@ -0,0 +1,22 @@
+# Input
+
+
+## Risk: Interception of Cwtch content or metadata through an IME on Mobile Devices
+
+**Status: Unmitigated**
+
+Any component that has the potential to intercept data between a person, and the Cwtch app is a 
+potential security risk.
+
+One of the most likely interceptors is a 3rd party IME (Input Method Editor) commonly used
+by people to generate characters not natively supported by their device.
+
+Even benign and stock IME apps may unintentionally leak information about the contents of a persons message e.g.
+through cloud synchronization, cloud translation or personal dictionaries.
+
+Ultimately, this problem cannot be solved by Cwtch alone, and is a wider risk impacting the entire mobile
+ecosystem.
+
+A similar risk exists on desktop through the use of similar input applications (in addition to software keyloggers),
+however we consider that fully outside the scope of Cwtch risk assessment (in line with other attacks on the security of the underlying 
+operating system itself).

src/key_bundles.md

@@ -0,0 +1 @@
+# Key Bundles

src/overlays.md

@@ -43,7 +43,28 @@ Another problem is that multiplexing all these overlays into one data store crea
 
 None of these problems are insurmountable, but they demonstrate a flaw in our initial assumptions about the nature of collaborative message flows and how we should be handling that data.
 
-## Invitations
+# Overlay Types
+
+As stated above, overlays are specified in a very simple JSON format with the following structure:
+
+    type ChatMessage struct {
+        O int    `json:"o"`
+        D string `json:"d"`
+    }
+
+Where O stands for `Overlay` with the current supported overlays documented below:
+
+    1: data is a chat string
+    2: data is a list state/delta
+    3: data is a bulletin state/delta
+    100: contact suggestion; data is a peer onion address
+    101: contact suggestion; data is a group invite string
+
+## Chat Messages (Overlay 1)
+
+The most simple over is a chat message which simply contains raw, unprocessed chat message information.
+
+## Invitations (Overlays 100 and 101)
 
 Instead of receiving the invite as an incoming contact request at the profile level, new inline invites are shared with a particular contact/group, where they can be viewed and/or accepted later, even if they were initially rejected (potentially by accident).
 

src/references.md

@@ -18,6 +18,8 @@
 
 * Lewis, Sarah Jamie. "Cwtch: Privacy Preserving Infrastructure for Asynchronous, Decentralized, Multi-Party and Metadata Resistant Applications." (2018).
 
+* Kalysch, A., Bove, D. and Müller, T., 2018, November. How Android's UI Security is Undermined by Accessibility. In Proceedings of the 2nd Reversing and Offensive-oriented Trends Symposium (pp. 1-10).
+
 * Renaud, K., Volkamer, M. and Renkema-Padmos, A., 2014, July. Why doesn’t Jane protect her privacy?. In International Symposium on Privacy Enhancing Technologies Symposium (pp. 244-262). Springer, Cham.
 
 * Rottermanner, C., Kieseberg, P., Huber, M., Schmiedecker, M. and Schrittwieser, S., 2015, December. Privacy and data protection in smartphone messengers. In Proceedings of the 17th International Conference on Information Integration and Web-based Applications & Services (pp. 1-10).