[Discussion] New instances rules

[SamantazFox]

trafficstars

I'd like to (re)open discussion regarding the new instances rules that were added in fd84d13b855934035b7b5ccb457c692007f11b32. I know that those have already been discussed a bit in #74 & #76, but I'd like to collect the thoughs of the (currently in the list) instance owner themselves on that matter.

I'm myself, quite against any kind of tracking and advertisement (1) in the official list. In my opinion, the official instances list must be curated from any sort of anti-user system, as users will be sent on one of those when they use the automatic instance redirect option. And as a user myself, I wouldn't land on an instance filled with ads or trackers.

So @tio-trom, @unixfox, @artemislena , @hys0star, @TechnicalSuwako, @FireMasterK, @RiversideRocks, @namazso, @ItsSt0ne, @mintphin and @11Tuvork28, what are your thought on that?

Of course @iv-org/developers too!

(1): I don't consider writing "this instance is sponsored by [brand]" in the banner as an advertisement. Such things may be tolerated, imo.

[SamantazFox]

PS: while we won't come back on some rules, like the mandatory publication of the source code, because of AGPL license, I want to have your thoughs on ads/tracking, and if you encounter(ed) any difficulties with the previous or current rules.

[89Q12]

I think it is paradox to put any sort of tracking/ads/analytics in any instance because I personally use Invidious just to escape youtube tracking. Therefore I think its not a good idea to put tracking/ads/analytics in but to be clear I also don't see banners like you mentioned not as ads.

[namazso]

Tracking should clearly be disallowed since it's against what Invidious stands for. As for ads, I think they aren't a problem as long as it comes with no tracking (but maybe should be restricted to banner). If ad funds are used to run the instance, is that sponsoring or no? I don't think we want to be the one to decide.

[SamantazFox]

I think it is paradox to put any sort of tracking/ads/analytics in any instance because I personally use Invidious just to escape youtube tracking. Therefore I think its not a good idea to put tracking/ads/analytics in but to be clear I also don't see banners like you mentioned not as ads.

@11Tuvork28 Mhh, yeah. Thanks for your input :)

If ad funds are used to run the instance, is that sponsoring or no?

I'd say no. Sponsoring is when a specific company or other organization provides ressources (hardware or monetary) for an instance to run. Similar to what is done with some IRC networks (libera.chat, e.g)

I don't think we want to be the one to decide.

The idea is for us to gather the opinions of everyone. we'll then see if anything has to be changed, e.g if some rules (like uptime) are too strict, or if everyone agrees that analytics (even selfhosted) are bad, we'll change that.

[ItsSt0ne]

These rules don't really have any effect on my particular instance, so I'm fine with them, and agree with the sentiment of having the instance list curating to the extent of having a baseline for privacy, maintenance, and reliability. One rule that seems to be vague or otherwise not very helpful to these ends is the requirement to list anti-bot protection. If the goal is to protect privacy, I don't really see how that advances it, since analytics is already covered. If the goal is to let users know beforehand that an instance may be blocking him or her, then it's only arguably saving a click, especially since it seems what most people are using allow configuration that may allow said user regardless. Think it would be more helpful to understand the reasoning behind the rule, and either remove it for redundancy or have a rule that addresses the requirement more directly (maybe stating what exact protections there are, what blocks are in place, etc.) Overall a positive change, and wouldn't be discontent with the rules as they are now.

[tio-trom]

I think it is a big irony to have something like invidious that is meant to get rid of ads and trackers and make youtube user friendly, to then have invidious instances add ads and trackers. I mean probably they should be allow to do anything they want with their instances, but for the official invidious list would not be a good idea to let such instances on the list. I want to escape youtube's ads and trackers and use invidious to then see other kinds of ads and get tracked!?

As for "sponsored by" that's still an advertisement regardless of the intent. I agree that's less aggressive than other forms of advertisement, but I think I am old enough to realize that such ads will never be just that, they will morph and become more aggressive.

But overall I think is a good idea to not let ads and trackers on any instances on your official list.

[tio-trom]

One last point, I think is unfair to remove the ads from my youtube videos via invidious, to then advertise your stuff while people watch my videos. Even "sponsored by" at the top of the page when people come across my youtube videos, I think you are using my content to make a profit, be it monetary or get free hosting or whatever. This may be a great reason for youtube to say that invidious is profiting off of youtube's content and servers. But if you are purely a platform that removes ads and trackers, then you are like an ad-blocker, and not an ad-blocker that blocks some ads and insert theirs. So it may be a good idea overall for the invidious project to protect itself from giving reasons to youtube to take invidious down.

[wiredsis]

No problem! While a lot of people use Invidious to escape Google's intrusive advertisement, such a rule could ensure people don't take advantage of a possible loophole.

[hys0star]

Instances shown in the list must be safe. However, using a tracker and Clownflare is not safe to look at. It is not a problem to use trackers and Clownflare for Invidious. But I don't think these instances should be listed. If you have to use trackers and Clownflare, I don't think you should disclose your instances to the list at all.

[hys0star]

It would be a good idea to display instances using trackers or Clownflare separately.

[wiredsis]

It would be a good idea to display instances using trackers or Clownflare separately.

Agreed! I forgot Clownflare included trackers. Guess having people die under their business is not their only mistake.

[SamantazFox]

So, something like 2 or 3 lists would be a good idea:

• the official one, 100% curated from tracker/ads/MitM
• the medium-quality list, where we put probatory and outdated, but otherwise clean, instances
• the low quality list, which contains trackers/ads or use CF/MitM

[TheFrenchGhosty]

@ItsSt0ne

Think it would be more helpful to understand the reasoning behind the rule

Most antibot protection use cookies or JavaScript, so that way it's clear where those come from.

[ItsSt0ne]

Most antibot protection use cookies or JavaScript, so that way it's clear where those come from.

Do agree with disclosing this, though it was brought up in #148 that there are many methods that don't affect end users. I think it's redundant, given that those changes should fall under either AGPL or rules 9/10, and people should just feel free to disclose what their changes are and how they impact end users (such as trom.tf referencing modifying CSS).

[FireMasterK]

The first rule:

1. Instances MUST have been up for at least a month before it can be added to this list.

Seems absolutely pointless to me... I don't understand the reasoning behind this, and I only see this as a waste of hosting costs, which can be quite expensive at some geolocations.

I've also whitelisted /api/v1/stats for all IPs on my instances to further comply with the new rules.

[TheFrenchGhosty]

Seems absolutely pointless to me... I don't understand the reasoning behind this, and I only see this as a waste of hosting costs, which can be quite expensive at some geolocations.

We keep adding new instances that go unmaintained after a months and never get updated. We basically want instances to updated and to be kept updated for at least a month before we add them to the list.

[SamantazFox]

The first rule:

1. Instances MUST have been up for at least a month before it can be added to this list.

Seems absolutely pointless to me... I don't understand the reasoning behind this, and I only see this as a waste of hosting costs, which can be quite expensive at some geolocations.

We don't want user to be directed to an instance, they create an account, and loose everything because the instance is never maintained afterwards. This is not the best experience of invidious

[ItsSt0ne]

We don't want user to be directed to an instance, they create an account, and loose everything because the instance is never maintained afterwards. This is not the best experience of invidious

Might be better to implement some sort of trial period for instances in that case. It's a lot easier to run an instance for less than ten people than it is to have one open and visible to the public. Not sure on the implementation, but I think being able to run a very small instance for a month is not much an indicator of being able and willing to run it long-term.

[trentwiles]

After thinking it over I think that any sort of analytics should be forbidden.

As for making multiple lists, that just looks like it will confuse end users more. Why not just remove instances that use trackers?

[syeopite]

So, something like 2 or 3 lists would be a good idea:

* the official one, 100% curated from tracker/ads/MitM

* the medium-quality list, where we put probatory and outdated, but otherwise clean, instances

* the low quality list, which contains trackers/ads or use CF/MitM

As everyone said already, this is confusing. it's just better to have a single list. Though, I think a similar idea could work. Basically, there should only be one official list, with all of the restrictions we've agreed upon here. However, there should also be a standardized way to record instances and their respective attributes down for an instance list, something like what #76 uses.

For example:

    - url: https://example.com
      country: US
      status:
        url: https://status.example.com
        # The image and text attributes below are for anyone that wishes to render the list into something more user friendly.
        image: assets.example.com/status/invidious-uptime
        text: Status Page
      privacy_policy: https://example.com/privacy_policy
      ddos_mitm_protection: null
      owner: example
      modified: yes
          source: https://github.com/example/invidious
          changes: https://github.com/example/invidious#changes
      ads: yes
      sponsors: yes

Naturally, this would allow the community to create lists of their own, with varying restrictions. Integration can then been built into Invidious, which would allow an (advanced) user to select which list they'd want to use, and the specific attributes they'd want / don't want on the instance they get automatically redirected to.

Most users can and likely will just use the official list, though for those that wishes for less restrictions and more instances to choose from, the option is there.

[SamantazFox]

Basically, there should only be one official list, with all of the restrictions we've agreed upon here. However, there should also be a standardized way to record instances and their respective attributes down for an instance list, something like what #76 uses.

Mmmh, yeah. So one list, with strong filters by default, but where we could register other "lower-privacy" instances, right?

[TheFrenchGhosty]

Follow up to a discussion we had on Matrix:

Rules 11 restrict the design too much, specifically the "in the footer" requirement.

Some suggested replacement that were shared in the Matrix room:

• "explicitly indicated on the site" suggested by @vituperative
• "in the footer or in a dedicated page" suggested by me
• "or in a dedicated page (linked in the header or the footer)" suggested by me
• "linked from the front page" suggested by @vituperative
• "... In some prominent way, such as in the footer or a dedicated page with an easily accessible link." suggested by @syeopite

[namazso]

Just saw the pr and have some questions:

8. Instances using any type of anti-bot protection MUST be marked as such.

does rate limiting in nginx count as such?

10. Any system whose goal is to modify the content served to the user (i.e web server HTML rewrite) is considered the same as modifying the source code.

i have a simple nginx rule with a 302 to redirect /privacy to my own privacy policy. does this disqualify me?

[TheFrenchGhosty]

does rate limiting in nginx count as such?

That's to be discussed I guess (ping @SamantazFox ), the point of this rule is to "show" where the potential non-invidious cookies/JS come from (since most anti-bot use cookies and/or JS).

i have a simple nginx rule with a 302 to redirect /privacy to my own privacy policy. does this disqualify me?

We should add a exception for /privacy (ping @SamantazFox ). This doesn't disqualify you.

[unixfox]

does rate limiting in nginx count as such?

That's to be discussed I guess (ping @SamantazFox ), the point of this rule is to "show" where the potential non-invidious cookies/JS come from (since most anti-bot use cookies and/or JS).

There are no cookies or JS to enable when simple rate-limiting rules are applied.

[TheFrenchGhosty]

There are no cookies or JS to enable when simple rate-limiting rules are applied.

This is why it has to be discussed: do we require it only when cookies/JS are added, or do we always requires it.

[SamantazFox]

does rate limiting in nginx count as such?

Imho that souldn't count. Instance owners should be free to harden their servers agains abuse, as long as it doesn't require something client-side (JS/Cookies)

i have a simple nginx rule with a 302 to redirect /privacy to my own privacy policy. does this disqualify me?

Let's say that this is a hack because we're not yet providing the tools for you to easily give a privacy policy URL (like we recently did with the source code). So no, it's perfectly fine to do so.

---

Also, quite between the two points above: blocking some parts of the API using nginx rules or ensuring that a user has requested a wepbage before pinging the comments, captions or annotation endpoints should be considered basic hardening and should be allowed.

(That's something that sould be tracked in the instances list once rewritten, and we should also provide config options to disable the API if needed.)

[Ammako]

Piggybacking off of this to mention one instance (nerdvpn.de) which has recently started blocking access outside of certain whitelisted countries.

I'm interested in knowing what you think about the practice? I think that at the very least, the list of instances should include some kind of mention, to let users know when an instance is only available within certain regions (and, if possible, a list of regions within which the instance is available.)

Maybe there could be another list just for region-limited instances? For the time being there might only be this one, but there could end up being more in the future, and in that case it would be helpful to be able to tell them apart at a quick glance, against other instances who are available worldwide.

Also, while geo-restricting access isn't necessarily a problem on its own, there may be a little bit of a problem with nerdvpn.de in this case, because they've had users signing up to the instance over time before suddenly revoking access, without providing some sort of way for the users to retrieve or delete their data (aside from using a VPN, which users shouldn't be expected to have to use.)

Thoughts?

[trentwiles]

I'm not fully understanding why nerdvpn.de is doing this. Maybe this is a move to limit the number of people signing up or protest the Russia/Ukraine situation?

This is a screenshot from a Mauritius IP.

Before we make a decision I want to hear the server admins rationale behind this. (Also, isn't blocking Tor and VPNs a bit counterproductive for a privacy service?)

[unixfox]

For me an instance shouldn't block the access to a user, they can temporarily restrict the access with a rate limit method or a captcha (that work without JS ideally). But not completely disallow the access forever.

If a maintainer of an instance struggle to handle the load, they can always ask for help. They shouldn't take a harsh decision without consulting the Invidious team.