Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate and remove expand_bbox call #2316

Open
mmd-osm opened this issue Jul 16, 2019 · 6 comments

Comments

@mmd-osm
Copy link
Contributor

commented Jul 16, 2019

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 comment has been minimized.

Copy link
Contributor

commented Jul 16, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented Jul 16, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jul 29, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jul 29, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented Jul 29, 2019

@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

This comment has been minimized.

Copy link
Collaborator

commented Jul 30, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.