tosterkamp / random-redirect Goto Github PK

https://sanchez-24.de
Thanks.

The Jitsi Meet wiki has a list of Jitsi Meet instances.

Many of them are not in the server list. Maybe some could be added to further distribute the load between the instances.

With the last 1.7 release codimd was rebranded to hedgedoc.
See https://hedgedoc.org/history/ and https://github.com/hedgedoc/hedgedoc/blob/master/docs/history.md

To reflect this change I'll try to rename the relevant functions and links ;-)

Thanks a lot for this handy tool.

Perhaps it would be nice, if You can enhance the tool by some features:

1. Supply the Name of a Meeting Room

   that is, jitsi.random-redirect.de/TheRoomWhereWeMeet

   redirects to <a_random-jitsi-instance>/TheRoomWhereWeMeet

   (and perhaps jitsi.random-redirect.de‎?room=TheRoomWhereWeMeet should do the same)

2. Select only servers matching an regular expression RegEx=<reglar_expression>, a TLD="de" or something similar?

other possibilities (if these informations are somewhere available):

region=EU for the physical location of the resulting servers

GDPR=true

etc.

An Example:
jitsi.random-redirect.de/TheRoomWhereWeMeet?GDPR=true&RegEx="*.freifunk-*.de"

Greetings
HPM in VK

Firstly, thanks for providing this handy tool. I think I'd be great if the random results could be narrowed down by user-defined parameters, like:

• is the server hosted on Google, Amazon, Microsoft, Cloudflare etc.?
• how much attention is given to privacy? (For example, use of analytics or Google STUN servers with Jitsi, etc.)
• where is the server located?

I'd imagine using query parameters like ?location=eu for passing options.

I hope this feature request isn't out of the boundaries/goals of the project.

(https://jitsi.random-redirect.de) gives a 502

Many instances on the Jitsi Meet list use commercial services provided by Google/Alphabet, Amazon, Microsoft and/or Cloudflare which are suspected or even out-right known to spy on their users.

jitsi.random-redirect.de has a high chance of landing users on an instance with Google's STUN/TURN service and even a chance of sending them straight into Cloudflare or onto a Google or Amazon server. The users don't know about this. They don't know beforehand where they'll land. They don't know that the instance they land on is "dirty". And even if they knew, they couldn't do anything about it.

There is a way of knowing which instances are "dirty", and which are safe: The Jitsi Meet Handbook has a list of community-run instances with two columns which are important to check. One marks instances which don't use Google STUN/TURN; not even half of them avoid it.

The other one marks instances which run on Google, Amazon or Microsoft servers and/or through Cloudflare. This is the case with two instances on the random-redirect list: meet.ffmuc.net runs its Web frontend through Cloudflare which is relevant because it's the Web frontend which random-redirect redirects to. And meet.jit.si runs on Amazon AWS and uses Google STUN/TURN.

If data privacy protection is of any concern for random-redirect, all these instances should be removed from the list, and new instances should be checked before being added.

Hey,

since several days I am seeing some, probably broken, requests from your redirection system.

- - [14/May/2020:09:41:43 +0200] "GET /%0Arandom-redirect-test HTTP/1.1" 404 403 "-" "python-requests/2.23.0"

Just wanted to give a "hint hint".

Thanks for your service!