proposal: Add Networked Plugin Rules

docs/plugin-development/restrictions.md

@@ -82,6 +82,71 @@ start debugging performance issues is through the Plugin Statistics window,
 which can be found through Plugins > Open Plugin Stats in the dev menu
 (`/xldev`).
 
+## Can my plugin talk to a backend server I run?
+
+Plugins are permitted to communicate with special backend servers, though there
+are certain considerations and requirements that must be met:
+
+- Plugins should take care to send the minimum amount of data necessary to do
+  their job. Whenever feasible, plugins should hash information about the local
+  player (such as the player's Content ID or name) on the client side so that a
+  server-side data breach does not reveal information.
+- Plugins may collect additional non-essential information for telemetry,
+  analytics, or statistical purposes, provided the user is given a chance to
+  review what data is being collected and for what purpose.
+  - Users must opt in to additional telemetry collection, but this may be done
+    as part of a "welcome to this plugin" experience forcing an explicit choice,
+    or via a global Dalamud setting.
+  - Additional data collection must be done for the public interest. That is,
+    the extra information should go back to improvement of the plugin, provide
+    the public with statistics or dashboards, facilitate the creation of curios,
+    or otherwise just improve the game and player experience.
+  - Plugins must use either a pseudo-random identifier (or no identifier) for
+    any analytics data. If an identifier is used, it must not contain or be
+    derived from any personal information and must be resettable at any time by
+    the user purely on the client side. Developers are encouraged to design any
+    analytics systems so that a user cannot be deanonymized even with full
+    access to the raw datasets.
+- Plugins must take care to not expose a list of other plugin users or allow an
+  easy way to test whether a specific user is using any plugin. Users may list
+  themselves in a public directory if they so choose, but this risk should be
+  identified to the user.
+- Any maintainer-run server for a plugin must use encrypted communication via
+  HTTPS (or an equivalent), and must have certificates issued from a trusted
+  certificate authority such as [Let's Encrypt][lets-encrypt]. Plugins must
+  connect to servers via DNS name to prevent data from going to stray IP
+  addresses.
+
+The appropriateness of data (both essential and non-essential) being submitted
+to backend servers is ultimately subjective, and will be handled on a
+case-by-case basis of the Plugin Approval Committee. Factors such as the
+developer's intent with the data, the necessity of the data to collect, and how
+things are communicated to users will all affect what any given plugin would be
+allowed to collect. Developers planning to submit user data should expect to
+receive feedback on feature design and architecture from both PAC and the
+community as part of the review process.
+
+Plugin developers running backend servers should also consider the following as
+part of their plugin's design. The below bullet points are not rules, but are
+instead guidelines and recommendations designed to improve the overall plugin
+experience.
+
+- Plugins should offer the ability to connect to a user-defined backend server
+  rather than the maintainer-run server. This allows users more control over
+  where their data goes, and allows plugins to survive should a developer lose
+  interest or stop working on a project.
+- Backend servers should be available under an Open Source license, with the
+  code available for inspection by interested users. Servers should also be
+  relatively simple to deploy, allowing users to run their own servers if they
+  want.
+- Plugins should support dual-stack communication, and the backend server should
+  be aware of IPv6 addresses and be able to handle them properly, including rate
+  limits if necessary.
+- Plugins using WebSockets or similar should implement connection retry logic to
+  gracefully handle connection interruptions.
+
+[lets-encrypt]: https://letsencrypt.org/
+
 ## How are plugins reviewed and approved?
 
 [This page documents our plugin submission process](plugin-submission), and the