While checking over add-ons in the review queue, there is (at least) one add-on that sends back telemetry information to a server.
To be clear, these add-ons have not been accepted and as far as I can see none of the approved add-ons send telemetry.
It seems the current terms of service on extensions.blender.org prevent this as long as:
The add-on respects “Allow online access” (where disabling online-access prevents any telemetry from being sent over the internet).
The add-ons permissions include network, with the description including telemetry.
I’m uneasy about accepting extensions that send telemetry for a few reasons.
Many users will enable Allow Online Access in their preferences so updates are available, but may not want extensions to be uploading details about their system to some 3rd party.
What is “reasonable” for an add-on to upload as telemetry is debatable and could easily include information users would not want being sent over the internet.
Once an extension has been accepted, updates to the extensions could change what is sent in the telemetry, sending more user data than users originally accepted - for example.
Options
Not a comprehensive list, just some options for how we might handle this.
Prohibit All Telemetry
If sending information to a server isn’t necessary for the extensions operation, disallow it.
If developers really want to write extensions that send user information to a 3rd party, they can host their own extensions or setup a repository that allows this.
This has the advantage that there are no grey areas when we review extensions. We just don’t accept it - no quibbling about when it is/isn’t okay - if an extensions does this it’s clearly violating extensions.blender.org policies.
Allow Optional Telemetry
The extension may send telemetry to a server but it must be optional & off by default.
In addition to this, we could have global preference similar to Allow Online Access which allows telemetry to be sent by add-ons as long as they respect the telemetry option.
This has the advantage that there is one place to enable/disable telemetry.
Allow Telemetry
Accept extensions that upload telemetry as long as it’s clearly stated in the permissions and respects online access.
Since there are extensions that include telemetry uploading logic waiting for review it’d be good to settle on a policy sooner than later.
Prohibiting all seems more sensible to me, but I think of situation in future where official Blender extension might want to send data, like Blender ID add-on or something for opendata.blender.org. i think its fine to have “double standard” there, because we can guarantee safety in blender.org ecosystem, but cant for anything else.
Picking which one to allow seems to me like too much responsibility for a moderator, something that can get you in a trouble if someone abuses permission once accepted and I wouldnt feel comfortable accepting that risk.
So: prohibit all, but still add new permission in case official Blender decides to use it in the future
My preference leans more towards the total ‘Prohibit All’.
Having said that, I could be OK with the ‘Allow Optional’ depending on exactly how it is implemented and that the user has total control over what is or isn’t sent, on a per addon basis and any control is independent from the current ‘Allow Online Access’ option.
This of course put extra work on those doing the review to make sure any said addon does in fact follow the rules. Which would mean checking network activity, etc to see if stopping telemetry does in fact stop any data.
As for a flat out ‘Allow Telemetry’, that would be a total NO from me.
I would put myself in the ‘Prohibit All Telemetry’ camp as well.
I’m already worried about the scalability and maintainability of the official repository since everything has to be reviewed. Having gray areas will likely cause some reviewers to choose inconsistently with others.
I think that collecting telemetry in general aligns more with commercial products which is a different mindset than what the official repository is for. I feel like if an extension developer wants to send user data back to their own servers, then they should be responsible for hosting the add-on on their own repo.
Allowing extensions to send telemetry increases the overhead for reviewing extensions - especially the internal discussions we’ll need to have regarding grey-areas of what is acceptable to send - documenting this, ensuring extensions are following these rules & handling concerns raised by users who believe extensions are breaking the rules.
At this point in the project - I think it’s too much burden on reviewers to have to handle these decisions.
An argument has been made that a Blender open-data extension might need to send telemetry.
Even in this case I don’t think we would need to silently send user data to Blender’s servers.
If an add-on has a button “Send my system specs to XYZ.org” … and the purpose of the add-on is to collect a data-base of bench-marks / system-specs. Then this is at least doesn’t fall under the category of silently sending my system specs to a 3rd part. Even in this case, what is sent needs to be very clear to the user.
This has the following implications:
If an extension is collecting & sending telemetry automatically … we can request it be removed in review without discussion.
The rare cases when an add-on might want to send system specs with benchmarks to a web-site, it’s allowed as long as it’s an explicit user action.
I’d suspect we wouldn’t have more than a few add-ons making use of this, it’s such a corner case.
We could re-evaluate this once the extensions site and system is working well, bugs fixed etc (maybe a year or so)… in principle opt-in automatic-telemetry-collection could be OK, although given the option I’d still rather prohibit all (long term).