Beacon opt-out method for modpacks

[Madis0]

I've read your article about the newly added telemetry, and the options to disable it.

In modpack context, unfortunately it seems that the options are only usable in MultiMC-style modpacks, not for example, ones hosted in Modrinth or Curseforge. Therefore I suggest adding a third way to disable the feature, e.g. via a config file.

Edit: I was informed of quilt_loader.txt, this seems very suitable for this purpose.

[Jamalam360]

I don't think it should be a modpack makers decision, it should be up to the user

[Madis0]

As a modpack creator, I disagree.

It is up to the user, when the user creates their own game instance. But when they download a modpack, the expectation is that the experience is already curated for them, which sometimes also means RAM management, Java flags and the like.

Why RAM and Java flags are not distributable in Modrinth/CurseForge packs is a question for another day, here I'd rather draw a parallel with the dependency overrides feature which is also a modpack-oriented config file.

[Jamalam360]

That doesn't really answer my concern. Let me phrase it more clearly:

Why should a modpack creator be making this decision on behalf of the user? Why would they make that decision, if they could?

It will likely be based upon personal thoughts about Quilt's 'telemetry', whereas your example of RAM management doesn't involve personal feelings.

[Madis0]

Why should a modpack creator be making this decision on behalf of the user? Why would they make that decision, if they could?

Some possible reasons include:

• Not trusting the way this telemetry works
• Saving bandwidth
• Not trusting the server telemetry is sent to
• Not wanting to appear in the count

and these values can be had:

• by the user about this telemetry specifically
• by the user about all telemetry
• by the modpack about this telemetry specifically
• by the modpack about all telemetry

So if the user knows and trusts the telemetry stance of a modpack, it is disingenuous if the modpack uses a mod loader in which it cannot disable the telemetry for every user by default.

[Jamalam360]

That answers the second question, but not the first. The modpack creator has no right to be making this decision on behalf of the user, imo.

[Madis0]

Users choose modpacks to make decisions for them, including mods, configs, resource packs, worlds... How is this any different?

Edit: as I listed the reasons before, telemetry is not just a matter of "personal feelings". It has several real implications, which may benefit or harm the user, and if the user trusts the modpack, they do not have to decide about each criteria separately.

[Patbox]

That answers the second question, but not the first. The modpack creator has no right to be making this decision on behalf of the user, imo.

Isn't that kinda point of modpacks? To have ready collection of mods created by someone, without having to decide which mods to add or how to configure them? This also doesn't prevent users from enabling it if they want to.

[Jamalam360]

this also doesn't prevent users from enabling it if they want to.

The chance of anyone doing that is minimal, let's be honest :( I wouldn't do it, out of laziness.

• Saving bandwidth is a non-issue. This request is tiny. There are much bigger fish to fry in terms of network requests.
• The rest of your reasons are personal feelings. They're about trust (apart from not wanting to be in the count, which is a personal opinion as well).

'Modpacks' do not hold values about telemetry. Modpack creators however, do. Allowing this would be allowing the modpack creators personal thoughts on (this) telemetry to be pushed onto the user, at the expense of Quilt.

Finally, you talk about trusting a modpack and it's decisions. Most of us forget that most users are not interested in all of this. They just want something that works for them - if the mod (or mod list in the case of modpacks) is attractive, and there are pretty photos in the description, I'd take a bet that most people aren't that bothered about the creator's stance on telemetry and how that affects them.

[EDIT] Also, I really don't think you can liken this to 'mods, configs, resource packs, worlds...', it's obviously different

[Patbox]

You can, it should be exposed as an config option (already is, but you can't define it in file). What's different from configuring a modloader to configuring a mod? Modloader is nothing more than a "core" mod, that you need to use for easier experience. In this case by being on by default quilt technically also decides for the user as they would likely be unaware about it.

[Jamalam360]

The fact that configuring a mod might mean increasing the chance of pink sheep spontaneously exploding, while configuring the mod loader is making a decision about the users privacy based on the perception of the modpack creator, in this case.

Also, yes configuring a mod loader can be a part of a mod pack. Just not this configuration

[falkreon]

That answers the second question, but not the first. The modpack creator has no right to be making this decision on behalf of the user, imo.

The blistering irony of saying this while opting users into a tracking beacon without asking them

[Jamalam360]

First of all, that's poorly phrased, I am voicing a personal opinion, I did not opt anyone into anything. Secondly, I think I already made it clear that I don't think this is a violation of anyone's privacy when we talked on Discord earlier and therefore I don't see a problem with the beacon being opt-out, and even if I did, work is already being done to add an option to the installer as far as I can see. Anyway, that's not what this issue is about so let's not go round in circles again

[gdude2002]

There are some merits to the idea of providing an instance-based setting, but I don't think modpacks should be the intended scope for it. If anything, depending on how flexible the implementetion is, this could be a terrible idea - it'd suck pretty hard if a modpack was able to opt someone in, instead of opting them out.

I think we can do better with providing ways to opt out, though. Servers, for example, need to have an easier way to opt in or out that will function within a restricted filesystem, something which is common on server hosting platforms and would likely need an instance level setting.

It's worth nothing that the java argument isn't necessarily intended for direct use by users either - it's been pointed out a few times that it was intended for launchers to expose this where possible and willing, and that (combined with the installer PR to add an opt-out checkbox) would address your concerns as well, from what I can tell.

More options are good, but this is overstepping what a modpack should be responsible for, imo. After all, there are users out there that would rather have the beacon request enabled, as unlikely as that may seem to someone that would prefer to disable it.

[Madis0]

My modpack currently disables non-essential network requests in 6 mods, plus Minecraft itself. Each one has a different reason behind it, be it a privacy concern, an unwanted extra feature or just practically unnecessary.

Still cannot understand why disabling it in the loader as well would be such "overstepping" and require special treatment compared to aforementioned changes.

Trying to convince users that the beacon is not bad while being very reluctant to give easy opt-outs is contradictory and does not increase the trust in the feature.

---

But to give some new ideas, how about:

• the environment variable/JVM flag overrides the config file when present
• the state of telemetry is listed in every usual loader log along with mods and the like, to notify users about whether it is enabled or not

[gdude2002]

Realistically, if your modpack doesn't clearly point out that it's disabling these things, and potentially if that isn't the primary point of the modpack, then I would consider it overstepping - if someone installs a tech modpack then I don't think they'd expect it to mess with that kind of thing.

One example I can think of that I've seen in the wild is modpacks that silently include a mod that intentionally breaks chat reporting, when the focus of the pack is completely unrelated. I'm sure you're actually telegraphing this since you seem to know what you're talking about, though.

---

Both of those approaches seem like good options to me.

[Madis0]

Important Monthly Active User Beacon Update

At 10:07 UTC, we received a message from the Starchildren which said that “the beacon is registering IP addresses”. However, they refused to tell us where so that we could fix the problem.

As a precaution, we have deleted the DNS record for the beacon server, meaning that the loader cannot send out beacon requests, and monthly active users are no longer being tracked for the time being.

Source (via)

This announcement should serve as an another reminder that any telemetry system has real implications - good and bad - that are not just someone's personal opinion.

I'm glad that the representative parties were quick to react, but as with malware issues (Fracturizer) and other problems Minecraft modding has had recently (creation of Prism Launcher) show, more precautionary options are a good thing.

[Jamalam360]

It's still personal opinion on how precautionary you want to be about telemetry.

[AliceDTRH]

I wouldn't really want a modpack to decide on whether or not I opt-in or out of a beacon, regardless of my opinion on the beacon.

[rbits0]

I don't understand the point of "the modpack shouldn't decide for me". If you want to make the decision, then you can change the config file yourself. The thing is, the majority of people using modpacks (at least Optifine replacement modpacks) are using it cause they don't know how to do that stuff themselves, they need the modpack to do it for them. They wouldn't even know that Quilt has telemetry, let alone know how to disable it.

The choice is not between the user and the modpack deciding, it is between Quilt or the modpack deciding, and I think modpacks should have the ability to decide if they want to. If you want to make the decision yourself, you still can.

[Jamalam360]

My point is that most users:

• are not as privacy concious as the minority of people that have voiced their opinions here
• do not mind this 'telemetry'
• could not care less about it, to be frank

...it defeats the purpose of a MAU count if one person can make a decision based on their personal opinions that could potential disable thousands of users beacons

[Madis0]

are not as privacy concious as the minority of people that have voiced their opinions here

That's why modpacks make the decisions for them. Like governments, you choose someone you trust to make some decisions for you.

do not mind this 'telemetry'

If they don't, it's easy to notice and re-enable then, because it is a clearly marked config file in their config folder.

could not care less about it, to be frank

Point 1 above.

...it defeats the purpose of a MAU count if one person can make a decision based on their personal opinions that could potential disable thousands of users beacons

Well, that's the goal? All methods of statistics collection have some margin of error, assuming they don't will only cause more problems.

A real-world example: a city wanted to change a bus route because they relied on travel card validation statistics and saw low activity in some bus stops. Guess what happened? Elders and children who did not have to validate their card protested against the change as they actually used the stops, then the city reverted the route.

[Jamalam360]

you choose someone you trust to make some decisions for you.

You have an inflated sense of what is going on here though. Most users find a modpack that has the mods they like, or has the best pictures in the description. They're not trusting the modpack author to do anything but get mods that don't crash from their point of view.

easy to notice and re-enable then

once again, 'could not care less'. It goes both ways. Couldn't care about it being enabled or disabled.

How is the goal to allow one person to disable the beacon for many people, that makes no sense? Of course there's margin of error: individuals who have a problem with it disabling it. That's very different to individuals who have a problem with it disabling it for people who have no opinion on it.

[AliceDTRH]

Modpacks are not a party in the data collection process, they aren't the one collecting data and they aren't the one the data is being collected from, why should they be allowed to change the data collection settings (regardless of whether or not it's a default).

[Madis0]

why should they be allowed to change the data collection settings

Because their goal is to curate the experience for the users, preconfigure various settings including mod settings, instance settings and loader settings. If specific data collection is harmful or unwanted for a specific modpack context, it should be preconfigurable, just like any other setting.

[Jamalam360]

Then we're back to the fact that it's an opinion that the beacon is bad and you're pushing that opinion onto other people at the expense of the MAU count, the reason for the beacon.

[AliceDTRH]

I'm not a lawyer but I feel like talking to one might be useful in deciding if this is a good decision if someone does decide to implement this.

That was not intended as a threat by the way, just that introducing a third party in data collection might be iffy. I think under the GDPR for example the modpack author might be seen as a joint data controller, for example. Not sure though; again, not a lawyer.

[Madis0]

That was not intended as a threat by the way, just that introducing a third party in data collection might be iffy. I think under the GDPR for example the modpack author might be seen as a joint data controller, for example.

This issue is not about extending data collection, only restricting. Similar to what Windows, Mac, Chrome give options for.

It is not a stretch to say that modpacks can be used in schools, LAN parties and the like, Minecraft is an educational game. My own modpack has also been deployed in a school.

There are reasons to restrict non-essential network activities: enterprise policies, (public) network rules, country laws (Quilt does have certain political activism), and yes, user preferences. Just because they may seem very theoretical at the moment, doesn't mean they will always stay so.

[AliceDTRH]

It is not a stretch to say that modpacks can be used in schools, LAN parties and the like, Minecraft is an educational game. My own modpack has also been deployed in a school.

In these cases the school owns the network and are allowed to ensure that their network is used responsibly and to protect students from inappropriate or harmful content. It's their network and (often) their hardware so they get to make certain decisions for users. That's not what's happening here.

[Jamalam360]

The school point is really scraping the bottom of the barrel. All of those reasons are the responsibility of the user to deal with;

'what if my network was used on an organization network that forbids the Quilt beacon somehow? Better disable it for every user of my modpack just in case' makes no sense, and that is your point if i understand correctly.

[Madis0]

'what if my network was used on an organization network that forbids the Quilt beacon somehow? Better disable it for every user of my modpack just in case' makes no sense, and that is your point if i understand correctly.

A "modpack" refers to any kind of prepackaged instance. An instance you share with a friend, a server that requires some clientside mods, a public set of mods and configs user chooses to install from a website, and yes, schools and other public environments. So even if you don't like that users could install such modpack from a website, you're discouraging other use cases as well.

Overall, having the option in a config file allows for:

• users to follow the instructions to create the file by reading a website
• users to download and copy a predefined config file
• not having to have admin permissions to edit a registry
• not having to scourge the web on how to change JVM arguments in their launcher or what they even are

[Madis0]

Ah, sorry. I thought we were talking about adding configs to these types of modpacks:

As mentioned in the first post. And not about prepackaged instances of Quilt?

Well, initially I didn't think that I'd need to elaborate on all use cases, so I only mentioned those in the OP which I was personally most interested in. But since you didn't like that reason/use case, I wrote down more reasons and use cases.

[AliceDTRH]

I think a config file outside of control of the (curseforge/modrinth type) modpack would not be a terrible idea, but I don't think that's what this issue was about, considering the title and description of the issue.

[Madis0]

I think a config file outside of control of the (curseforge/modrinth type) modpack would not be a terrible idea, but I don't think that's what this issue was about, considering the title and description of the issue.

If Quilt Loader looked for config files outside of where it is installed, that would be overreaching on their end, similar to - but not exactly* - the registry value. This telemetry affects only Quilt, only inside Minecraft - it doesn't make sense to store configs elsewhere. And when it is stored inside a Minecraft folder, it is by definition controllable by modpacks.

* By that I mean that there are programs which reasonably use registry values for some of their configs. But the programs themselves are more wide-reaching, like browsers or antiviruses. Not a mod loader for a game...

[AliceDTRH]

If Quilt Loader looked for config files outside of where it is installed, that would be overreaching on their end, similar to - but not exactly - the registry value. This telemetry affects only Quilt, only inside Minecraft - it doesn't make sense to store configs elsewhere. And when it is stored inside a Minecraft folder, it is by definition controllable by modpacks.

Fair enough. Thank you for the explanation. In that case I understand why Quilt went with java parameters instead.

[Jamalam360]

If Quilt Loader looked for config files outside of where it is installed, that would be overreaching on their end

That makes no sense. How is that overreach? Is looking for an environment variable also overreaching by that logic? A registry key doesn't make sense I'll agree with that.

A "modpack" refers to any kind of prepackaged instance.

Yes, and 'schools and other public environments' is such a small subset of users which, most importantly, almost certainly have an IT manager or team that can deploy an environment variable to all computers if they felt the need too - which I still don't believe they would

[AlexIIL]

Obsoleted by RFC#84