Deprecate and remove expand_bbox call

[mmd-osm]

Expanding Bounding Box API endpoint was once added to work around some performance issues during changeset upload. Today, it isn't necessary in any way from a functional point of view. Could we possibly deprecate and remove it from the API code?

By looking at the production logs, are there any applications still using this endpoint? If it isn't used anymore, could we do this even for API 0.6?

Link: https://wiki.openstreetmap.org/wiki/API_v0.6#Expand_Bounding_Box:_POST_.2Fapi.2F0.6.2Fchangeset.2F.23id.2Fexpand_bbox

[woodpeck]

This is all total vapourware and nobody knows if it's ever going to be implemented, but in the course of hardening the API against vandalism I want to build a feature that will allow admins (or other sufficiently privileged accounts) to block certain areas from being edited at all.

The threat scenario goes a bit like: "Nationalist web site in X country activates its readers to set up OSM accounts and edit the Y boundary which is disputed by X", and all of a sudden we get thousands of different new users every day making edits to the boundary. In that case I would like to be able to simply lock down that area for editing for a while even if it has some unwanted side effects.

Now the way I was planning to implement it is to latch onto the internal mechanism that expands the bbox, which (in the Rails code) is called before attempting to save any object changes; I would then have that code check for rectangle intersection with anything on the block list, and throw an exception in case of such intersection. Problem solved! (It would also kill all world-spanning changesets because of their large bbox intersecting with the blocked area but I have little sympathy for them anyway.)

If this ever gets built then I could imagine editors wanting to "pre-flight" a changeset upload by sending an expand_bbox call in advance, which would essentially then serve as a "tell me if I am even allowed to upload a changeset with this bbox".

But this is just offering a thought - by all means get rid of expand_bbox now and we can still add a specific preflight_bbox later if what I described here ever gets implemented. As a side note, any coders interested in hardening the OSM website against vandalism are welcome to contact DWG to discuss our wishlist ;)

[mmd-osm]

I could imagine editors wanting to "pre-flight" a changeset upload by sending an expand_bbox call in advance, which would essentially then serve as a "tell me if I am even allowed to upload a changeset with this bbox".

I think a better way would be to publish such restrictions in the /api/capabilities call (i.e. by providing a list of "locked objects/bbox of the day"), and have editors react accordingly. The changeset upload call would simply reject any upload not adhering to the rules. Previous discussions about a 32k member limit for relations already showed that other approaches will most likely not work, in particular everything that would start looking at restrictions only very close to the upload itself. In most cases there's no meaningful way for a user to continue editing in this case.

Overall, I don't think expand_bbox is really suitable for this use case, and I'd assume you'd need much more fine granular rules to handle vandalism.

[mikelmaron]

As a side note, any coders interested in hardening the OSM website against vandalism are welcome to contact DWG to discuss our wishlist ;)

Is that wishlist posted somewhere @woodpeck?

[woodpeck]

Many items are in gravitystorm#32 but we do have a few other, more wide-ranging ideas on a DWG-internal wiki page. Happy to filter, format & post them somewhere but I don't know what the best place is - unsure if this repo is the right place for "wishiist" issues that might or might not get worked on in the next couple of years?

[mmd-osm]

@woodpeck: I think it would be good if you could break down the wishlist to a list of self-contained, functional requirements, and most importantly, prioritize the list according to what DWG deems relevant. Leave out every bit of technical and implemenation related detail, just focus on the functional aspects ("I as a DWG member want to ..."). I would post each requirement as a separate issue. Maybe @gravitystorm volunteers to keep all those requirements in his repo.

[gravitystorm]

I think it would be good if you could break down the wishlist to a list of self-contained, functional requirements, and most importantly, prioritize the list according to what DWG deems relevant.

I wouldn't worry about doing that right now - as ever, we're short on people to implement the ideas, not the ideas themselves! I would encourage any time available to be spent on writing code.

For clarity, the issues on my tracker are just things that I'm interested in doing at some point or ideas that are not fully thought through yet, and a place to keep those ideas when I don't want to lose them in the 450+ open issues between here and trac.

[mmd-osm]

Let's get back to the original topic: is anyone aware of actual users of expand_boox that might break once we remove the endpoint and send an HTTP 404 instead? (possibly based on current log file findings)

If not, I will go ahead and create a pull request to remove this API endpoint.