Prevent drivers from spamming map editors with update requests (URs)
Waze volunteer map editors have, over a number of years, have raised concerns about the ability for app users, whether intentionally or unintentionally, to submit a high volume of map update requests through the app and other sources. This issue has been consistently raised by volunteer editors at all levels, including editors, area managers, state and country managers, as well as local and global champs who are on the ground editing the map daily. It has also been discussed at local, mega, and global meetups.
To date, this security concern has not yet been addressed, which is why I am submitting this as a UserVoice suggestion. At present, it is possible for a single driver to submit a very large number of update requests in a short period of time, for example 20 within a minute. Introducing reasonable limits on the number of reports that can be submitted within a defined timeframe is essential to combat map abuse, reduce unnecessary workload for volunteer editors, and improve the overall quality of map updates.
On behalf of the volunteer editing community, we respectfully ask that Waze consider implementing measures to prevent excessive or repetitive map update submissions, so that editor time can be focused on meaningful and accurate reports.
-
Max Booster commented
This issue is seriously important, but proper regulation is equally crucial.
For example, those who create multiple reports on the same segment, but not all at the same locations within the segment, and try to report where and how the speed limit changes along the entire segment shouldn't be affected. They might have trouble reporting how the speed limit changes at every point along a single, large segment (e.g., 5 kilometers). Therefore, the regulation should be based on a logic that won't create problems (in my opinion, for example, based on coordinate differences at certain intervals).
-
Damien Peden
commented
I totally agree with this. I also think as others have mentioned that trust level should be factored into rate limiting, this would help the likes of editors needing to do multiples in a small area when mapping on the road.
-
rdnnk commented
Agree, must only be possible to submit multiple in short time for high confidence users/higher level editors. And no response to questions on multiple UR -> also block.
-
Anonymous commented
Yes.. agree.. same situation to deal with spam UR in indonesia as well
-
Paliano_6 commented
I totally agree it's really annoying to find reporters reporting dozens of times in the same spot
-
LostInMyMaps - Volunteer Editor commented
Thanks, everyone, for your votes so far. To be clear, this suggestion is about implementing reasonable rate-limiting. Do users need to be able to report 60 URs in 1 minute? No, that's unreasonable. I will defer to Waze to implement it in a reasonable and dynamic way that could even consider a user's trust level. There are ways to be smarter about this than what's occurring now. :)
-
DarkestWays
commented
Inasmuch as I'm in favour of preventing spam, this may, however, have unintended consequences for editors who raise multiple URs in succession while driving. They may do so to mark various locations, just so they can come back to them to apply relevant fixes. Especially so now that we see usernames on URs. I'm one such example.
Perhaps, in addition to rate limiting drivers on the number and frequency of reports they can generate, there should also be a trust level system applied, whereby seasoned editors aren't impacted by such limits.
-
maporaptor commented
This is a constant issue and is rather annoying. Here in Melbourne, Australia we had this user make multiple URs and PURs in the one spot clogging up the map! We need limits on URs and PURs!
-
Scoota - Volunteer Waze Editor
commented
Concur the ability to just spam the map with URs is incredibly wasteful of the finite time volunteers have available to administer the map. It would be appreciated if this investment for volunteers time is optimised by removing obvious duplicates and intentional/unintentional duplicates.