proposal: Add Networked Plugin Rules (#27)

* proposal: Add Networked Plugin Rules

Adds a proposal for restrictions/guidance around networked plugins.

* update some wording to be softer

* Add exposure rule

* Update wording on telemetry to be clearer

* Clarify de-anonymization should not be possible

* Tweak HTTPS note

* try to make linter less annoyed

* pr comments

* ???????

howd that get there

* Data collection must be done for public interest

- Reword some things

* fix clunky wording

* There aren't official servers, just maintainer-run ones

* i can grammar good

* tweaks

* Add new suggestion: version checking/MOTD

* Remove curios, add topical restriction

docs/plugin-development/restrictions.md

@@ -82,6 +82,81 @@ 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 maintainer-run backend services,
+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, or otherwise improve or augment
+    the game and player experience.
+  - Plugins must use 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.
+  - Collected data must be topical to the plugin in question. For example, a
+    plugin providing Party Finder features may not record information about
+    which face type is the most popular among its users, but _may_ collect
+    analytics to find which face type is most likely to create Ultimate clear
+    parties.
+- 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 by the Plugin Approval Committee. Factors such as the
+developer's intent with the data, the necessity of the data to collect, the
+abuse potential of the data collected, 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.
+- Plugins and backend servers should implement version checking logic such that
+  outdated clients are properly handled. Plugins and backend servers should also
+  consider implementing MOTD or notification systems to inform users of planned
+  outages, impending upgrades, deprecation notices, maintenance, and similar
+  status updates.
+
+[lets-encrypt]: https://letsencrypt.org/
+
 ## How are plugins reviewed and approved?
 
 [This page documents our plugin submission process](plugin-submission), and the