proposal: Add Networked Plugin Rules

[KazWolfe]

Adds a proposal for restrictions/guidance around networked plugins.

[KazWolfe]

Debating making SSL a hard requirement for official servers as well as requiring a valid certificate. This will effectively force a domain name as well, but I think that's alright? (Is there a cost issue with this?)

EDIT: SSL enforcement has been added to the latest draft of this document. Leaving this thread open for posterity.

[Blooym]

I honestly think this should be a hard requirement - Domain names are relatively affordable and using LetsEncrypt for SSL is easy and free.

[KazWolfe]

Ah, I forgot to update the comment. I've updated the proposal to require SSL now.

I'm still a bit mmmm about requiring a domain name, since it is a cost burden on developers who may not necessarily be able to afford it, but I suppose there are services like afraid.org and NoIP for home-hosted official servers.

Something to note: plugin devs do not need to require SSL if they're implementing custom home servers. This requirement only applies to the officially-run and officially-shipped default server.

[KazWolfe]

Add a section noting that any analytics ID must be user-resettable at any time.

[Infiziert90]

I don't think uploads should be opt-in
Most users don't care, so if they don't even bother to opt-out, why would they bother to opt-in

Same principal as silent agreement, you got informed that information may be uploaded, you can opt-out here, done
Example for this practice are both SubmarineTracker and Tracky, they inform the user and give them some hours to opt-out before any upload starts

Also dalamuds Universalis upload isn't opt-in either, as far as i remember

[NotNite]

These plugins either have large focus on data collection (RNG) or are explicitly designed for it, which is a different court compared to something like Simple Tweaks installation information. IMO whether opt-in is required should become a case by case basis.

[KazWolfe]

I clarified this point a bit - opt-in is intended for plugins collecting "non-essential" information; that is, any information that is not required for a plugin to do its job. This would include things like how many people are using what features, any sort of census information (e.g. how many Miqo'te are using this pluign), and similar.

Things that are "essential" for a plugin's function (that is, if you don't want to submit that data, why are you even using this plugin) don't need an opt-in as the opt in is the very act of installing the plugin - or, ideally, a consent screen forcing a decision.

The intent here isn't to block telemetry as much as it is to encourage devs to consider the data they're collecting, why they're collecting it, and what that data is going to be used for. Any data collected should serve a purpose of some sort, and that purpose should (overall) be in line with our project's values.

[KazWolfe]

See also goatcorp/Dalamud#1547, which will make Dalamud responsible for Analytics ID generation in a compliant fashion.

[KazWolfe]

This one is also very sticky - there are some cases where this is unavoidable, but expressing that as a hard and fast rule is difficult. The intent here is to avoid "GM installs plugin and goes on a banning spree", but maybe this isn't a problem?

[NotNite]

Consider that GMs aren't the only people who would want this data. Malicious actors seeking to gain information on players may mass scrape services for accounts (see the recent Discord spy.pet drama).

[KazWolfe]

I think this is ready for @goatcorp/plugin-approval to review and add any final feedback.

[KazWolfe]

This is not being included in this proposal due to the fact that it will devolve into endless debate, but I do want to add a section on data that may not be collected by mainline plugins. I may turn this into a secondary proposal in the future, but I'm also putting it here just so it exists.

Certain types of data may not be collected by plugins:

• Any information on other installed plugins or utilities.
• Any information about the user's device, such as hardware or software configurations.
  • Collection of OS and graphics driver versions are permissible for diagnostics purposes.
• Information about other players, including customize data.
  • Client-side aggregation of information may be permissible depending on use case, design, and intent.

Other data types may be excluded based on PAC's discretion. The above list is non-exhaustive.

[philpax]

This seems entirely reasonable to me; apologies for the significant delay on the review. The only thing I'd change is the use of the word "curios"; it's unlikely that most will be familiar with that.

Other notes:

• Do we grandfather existing plugins or ensure they meet these requirements?
• Is it worth including examples of plugins that would or would not pass these restrictions?

Otherwise, I'll hand it over to @goaaats .

[KazWolfe]

Will change the use of curios on my next lint pass.

Do we grandfather existing plugins or ensure they meet these requirements?

My intent with this proposal was to codify (more or less) our existing rules and various opinions in a single clear format. As such, I don't think there are any plugins that need to be grandfathered, at least in terms of general data collection compliance.

Plugins that currently use HTTP-only communication or IP addresses for connections should not be grandfathered, however.

Is it worth including examples of plugins that would or would not pass these restrictions?

See above - it's somewhat difficult to create a list of non-compliant plugins at the moment since there aren't really any in the official reposet. We could create such a theoretical list as an addendum, if that would be beneficial?

[philpax]

Makes sense. As always, we should encourage people to ask about their plugin idea before they implement it, but I don't think that's exclusive to this PR. Nice work!

[philpax]

@goaaats reminder