radiobrowser-api icon indicating copy to clipboard operation
radiobrowser-api copied to clipboard

Misuse of API

Open sphh opened this issue 7 years ago • 49 comments

If you look at today's changes of "BBC World Service" (ID: 86408) and "Radio Paradise" (ID: 87600), you could get the impression that a script has gone wild.

Could there be a way to stop such "wars"? (BTW I have great respect for the person(s) undoing the changes every time!)

One way I could think of, would be to give a user the ability to lock a station for a certain time (let's say a day or so). If that can only be done via the web interface (hence requiring human interaction), this would make it more complicated for a script to do it.

Maybe it should still be possible to edit the locked station via the web interface during the locked-down period?

What do you think?

PS: The url streams are always changed to point to a url shortening service with the short url ending in "Flutike" + a number. Googling for "Flutike radio" turns up the page https://xux.ro/program-inregistrare-radio-online/. The IP addresses where the changes were made from also points to Romania. Some other Google hits shows that Flutike owns a database of 20000+ radio stations, so I can think of that our friend there tries to upload all his radio stations to radio-browser. I tried to contact him via the contact page https://xux.ro/contact/ to tell him politely that something might go wrong at the moment, Either the message was not sent (I never got over the spinning button...) or our friend has not received or read my message, because he never replied and the changing of these two stations did not stop.

sphh avatar Feb 21 '18 21:02 sphh

thank you for reporting this! at the moment, the api is completely disconnected from the frontend. so i cannot decide, if an input comes from the frontend at www.radio-browser.info, or from somebody else. i could add a parameter, but one could easily mimic it. at the moment i do not have a solution, i really don't want to remove the possibility to edit stations. it would take the essence of what radio-browser is away. maybe i should not allow changes of the stream address if the automatic check says its ok? but still, there is much possibility for mischief. I am still fighting with myself how to handle this things properly. i try to look at wikipedia, how they deal with things. maybe add logins, for edit. but also wikipedia does allow edits without login. please, i am open to sugestions, feel free to add them. when i created this service, i always thought there is more good than evil in this world. and i am still holding on to that. maybe we could give the good side, a little edge. something or some way to make it harder for the bad side....

segler-alex avatar Feb 21 '18 21:02 segler-alex

it would be possible to limit the amount of edits of a station in 24 hours. that that still would make the last edit the winner :(

segler-alex avatar Feb 21 '18 21:02 segler-alex

Personally I don't think this is done out of mischief. (I hope, I'm wrong, because I also Believe In The Good).

You just gave me an idea: If the frequency of edits increase suddenly, the editing will be blocked and the station reverts to the values before that sudden increase in edits. So nobody is a winner and everything stays as it was.

sphh avatar Feb 21 '18 21:02 sphh

Now our friend does not uses the url shortening anymore, but http://sc1 for url and favicon, breaking many, many stations.

Can we do anything against it? Replay the database and locking it for some time?

sphh avatar Feb 22 '18 00:02 sphh

And as a quick measure could you please block changes coming from xxx.xxx.xxx.xxx? (Preferably silently ignoring it?)

sphh avatar Feb 22 '18 12:02 sphh

i added an iptables (firewall) rule, to block all packets from the ip address

segler-alex avatar Feb 22 '18 13:02 segler-alex

Danke, Alex! That was a quick and solid solution and it should quieten down these changes for now.

sphh avatar Feb 22 '18 15:02 sphh

Hi Alex,

Could you please also block this IP ASAP: xxx.xxx.xxx.xxx (disabled)

sphh avatar Feb 22 '18 20:02 sphh

And here are two IP addresses he used previously: xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx [disabled]

sphh avatar Feb 22 '18 20:02 sphh

done, but i think this is not a good solution...

segler-alex avatar Feb 22 '18 21:02 segler-alex

No, it's definitely not, because as soon as his modem connects again, he will have another IP...

But I spend the last hour reverting every change he made.

Any ideas how to solve this? Maybe only accepting changes which do not break the radio station or remove the homepage and/or favicon? Locking the whole database for a cool-down period? I don't know ...

sphh avatar Feb 22 '18 21:02 sphh

Here's one idea: Could you add a field for each radio station to the database, where you can leave messages regarding the changes made. Some changes are well founded but not so obvious. If I could leave a message, I could argue why I made these changes (or reversed some other's changes).

sphh avatar Feb 23 '18 14:02 sphh

now he is changing the links and the name, to break the streams.... i can prevent him from changing the stream to a non functioning one. but the name ... :(

segler-alex avatar Apr 10 '18 21:04 segler-alex

This guy is still trolling. I think that registration should be a requirement to editing. That could stop this madness.

wolfmanfp avatar Apr 15 '18 17:04 wolfmanfp

It's easy to register another account ... If the objective is to make it easy to get new radio stations, registrations might be counter-productive, too.

Another option would be the following suggestions:

  1. Adding a new radio station does not need a registration and the changes will become visible immediately. It should be impossible to add a radio station which name already exists (forcing unique names and removing the possibility to overwrite an existing radio station with a fake one).
  2. Changing an already existing radio station does not need a registration either, but the changes should be reviewed by "someone".

I can think that the "someone" takes care of a couple of radio stations. For example they care about the radio stations for their own country, so they will review them. These reviewers must register and can select the radio stations they take care of, e.g. using the existing filters. If it is easy to accept changes (e.g. by just ticking them), it should be easy to do.

If there is no reviewer for a certain radio station (or the reviewer does not act in a certain time window), the changes will be applied immediately.

Downsides are:

  1. Someone would have to program this additional feature...
  2. The reviewers must be administered.
  3. There is some work for the reviewers.

sphh avatar Apr 16 '18 11:04 sphh

i suggest the following:

  • stations are not editable at all any more. maybe only when link is broken, and then only when the newly provided link works.

at the moment i do not allow the stream url to be changed to a broken one. thats why the guy got angry, and changed everything else...

segler-alex avatar Apr 16 '18 18:04 segler-alex

i also think to disallow deletion of currently working streams.

segler-alex avatar Apr 17 '18 07:04 segler-alex

For example they care about the radio stations for their own country, so they will review them.

I basically do that now for Hungarian stations.

wolfmanfp avatar Apr 18 '18 13:04 wolfmanfp

Hi, now more stations are being destroyed: http://www.radio-browser.info/gui/#/topclick

Possible solutions:

  1. Static IP blocking - easy to circumvent with Tor / VPN and requires keeping IPs.
  2. Registration with email.
  3. Dynamic IP blocking - do not allow e. g. more than 3 request / hour.
  4. Automatic request processing - not possible to find all issues.
  5. Trusted reviewers - could be time consuming and could require sharing some administrative privileges by segler-alex.
  6. Disallow station editing - painful for honest users, especially when stream address changes - could be used temporarily until a better solution is found.

Each of these solutions used separately would be of little help but combined together they could help mitigate the problem by making it boring and tiresome to trash the database.

Registration by email will link requested changes with an account so rogue users can be banned. Do not allow e.g. more than 3 changes per hour. Ban user after a few of fake requests. Keep all email addresses forever and do not allow registering an account with already used address. Do not allow temporary email services (domains). Also some email services allow setting up multiple aliases for incoming email and this can't be helped but still after being blocked a joker will need to setup a new email (difficult to automate on public services), then register and finally request nasty changes just to make his new shiny account blocked again:)

Solution 3 (Dynamic IP blocking) alone certainly doesn't fix the problem but is easy to set up and most honest users don't need the ability to change a lot of stations in a short time frame. Allow e.g. max 3 requests per hour. It will slightly raise the bar for our friend and will cost him more effort. Return appropriate error message when a request was rejected. I think using solution 2 and 3 together doesn't bring any benefit - one is enough - email registration is better but probably requires a lot more work.

Automatic request processing (Solution 4) would reject any request with invalid data and send back a message with explanation why this change request was rejected. Check if any addresses are correct, e.g. is the stream URL streaming anything? Do not allow duplicate stream addresses. Also only a limited amount of change requests (e.g. 5) for a station could be allowed in the database at any given time to prevent a "request flood", either legitimate (when many users want to correct station's stream URL after it was changed by a broadcaster) or rogue (when a single user spams the system).

In this 'broad phase' many fake requests could be just filtered out without human intervention (time wasting).

After a request survives 'broad phase' it can be then reviewed by trusted persons (Solution 5). segler-alex would of course have the power to appoint and degrade reviewers to prevent any abuse. The success of this solution depends of course on how many create/change requests are there daily. Could a handful of volunteers manage to process them? I don't think that this is a big problem if a request is processed after a few hours, it's certainly better that a ruined database:)

Also each request could have an ID (kept for some time) so a requester could check its status e.g. via API or in a web browser.

That's all, thanks.

EDIT: It seems someone has just fixed the stations.

atomblender avatar Apr 19 '18 00:04 atomblender

I think the best way to do this is to have edits reviewed if they're done too fast or too often from a certain address or towards a certain station.

ghost avatar Apr 19 '18 19:04 ghost

Today I see almost 150 trashed stations. I wonder if he even changes ip?

atomblender avatar Apr 19 '18 21:04 atomblender

Hi. I am here just to say that I am using the nextcloud app for radio, then noticed that a lot of radio names are now named "Bull headed German ..... I will ruin your list ... and i have all the time for this". I was afraid I was hacked, but it seems it actually is an angry user from around here (and I am not german, so it was not a message for me). To find the culprit, I think it is easier to just find who did you pissed recently. Can those changes be reverted, or restored from a previous backup? sure fixing 150 stations vs restoring from backup is worth, then applying some of the rules above from atomblender? Thanks

Leorivasc avatar Apr 20 '18 04:04 Leorivasc

Personally, I feel the best first step would be e-mail registrations that need to be manually approved. It puts some delay between these attacks and allows blocking the obvious troll before it gets started. If not enough, a good second step would be requiring changed made in the first month or so to be accepted manually

TheLastProject avatar Apr 20 '18 05:04 TheLastProject

i added his ip adress to the firewall.

segler-alex avatar Apr 20 '18 05:04 segler-alex

i disabled deletion

segler-alex avatar Apr 20 '18 06:04 segler-alex

i wrote a small revert script before work in the morning. but i have to go to work now. i will fire it up and disable editing as soon as i have time

segler-alex avatar Apr 20 '18 07:04 segler-alex

i reverted most of the stations and disabled edit someone suggested i could add captchas but for now i will let it deactivated, i think it is ok for most people to add new ones the good stations already have good metainfo, so it does not need chaning anymore a station entry is not like wikipedia entry, it is only metainfo, so it is possible to do it right the first time. what do you think?

segler-alex avatar Apr 20 '18 09:04 segler-alex

please check if i broke something. i programmed this in i hurry

segler-alex avatar Apr 20 '18 09:04 segler-alex

Most of them are back. Thanks a lot for the hard work!

Leorivasc avatar Apr 20 '18 10:04 Leorivasc

The only problem will be when a station stream url changes so it can't be played. Other urls like homepage and favicon are useful but not critical. Hopefully people will not create duplicate station entries just to have urls fixed. But for now it's ok and stations seem reverted to the previous state. Thanks.

atomblender avatar Apr 20 '18 10:04 atomblender