Add keyboard lock (harmful).

This adds it as a harmful position, although it could also be written as
a defer position based on the feedback in mozilla#196.

activities.json

@@ -470,6 +470,18 @@
     "title": "HTTP Client Hints",
     "url": "https://tools.ietf.org/html/draft-ietf-httpbis-client-hints"
   },
+  {
+    "ciuName": "mdn-api_keyboard_lock",
+    "description": "This specification defines an API that allows websites to capture keys that are normally reserved by the underlying host operating system. It is intended to be used by web applications that provide a fullscreen immersive experience (like games or remote access apps).",
+    "id": "keyboard-lock",
+    "mozBugUrl": "https://bugzilla.mozilla.org/show_bug.cgi?id=700123",
+    "mozPosition": "harmful",
+    "mozPositionDetail": "This API is designed in a way that makes giving appropriate signals to the user more difficult than it should be.  It would be easier to do so if the API were more integrated into the fullscreen API and the keys to lock were less configurable.  Having the set of keys be less configurable also reduces the risk of content being broken in some browsers but not others.  The proposal also needs to address the security implications in the context of multiple screens (where fullscreen only covers one, and thus other windows are still visible).",
+    "mozPositionIssue": 196,
+    "org": "Proposal",
+    "title": "Keyboard Lock",
+    "url": "https://wicg.github.io/keyboard-lock/"
+  },
   {
     "ciuName": null,
     "description": "This specification defines an API that allows websites to convert from a given code value to a valid key value that can be shown to the user to identify the given key. The conversion from code to key is based on the user\u2019s currently selected keyboard layout. It is intended to be used by web applications that want to treat the keyboard as a set of buttons and need to describe those buttons to the user.",