So, putting these pieces together a bit, and spurred a bit by @grin’s other thread on this topic, I was thinking of a similar solution to what Minh outlined earlier today. A simple reverse proxy, managed by the community, that the editors use OSM credentials to authenticate against, and the proxy requests the imagery using the API key that it keeps to iteself. It then sets rate limits per user, per zoom level, and these can be adaptive (similar to some of the changeset discussions), based on various account metrics, including age. Registration could be automatic, or separate, with a captcha or something to make abuse a bit harder.
But that all assumes that, from the story above, the only reason Maxar cut off imagery access was because of abuse. If we stood up a reasonable prevention against abuse and prevented any sharing of their API key, would we get access back?
I’d be happy to put some development time into something like this and potentially hosting the gateway service, especially if we can get a small group together. But I don’t want to do it without at least some reasonable assurance that it’d result in them providing access again. Who can go about brokering something like that?
people get individual access to the imagery, using their OSM account (by getting access to a proxy, or getting live Maxar keys, at their option),
abusers can be disabled individually instead of disabling everyone, and
new permissions may have various prerequisites, including edit history, account age, community trust score, whatever, to prevent new accounts to be used as repeated abuse points. Basically if someone is disabled, then they stay disabled for a period of time possibly depending on the kind and magnitude of the abuse.
A possible problem, or at least a question will be how to actually determine whether an access is abuse or not, but the mentioned rate limits (based on normal paremeters of real life editing) may work well.
Another way is that we get individual keys from Maxar (which we assign to individuals, possibly with time limited automated rotation if they are actual live keys) so they also can verify/check abusive traffic as well as disable them individually by their taste. That depends on whether they want to do its management themselves or rather delegate it to OSM(F); I think we can accept any of them.
(This way we can also handle key handovers and stolen keys, since they are all connected to a specific individual, who can be disabled for good.)
@Spatialia@grin quite good ideas, but let me give you a little insight in what has already happened behind the scenes on the “OSMF+friends” side of things: A group consisting of some OSMF board members, some people from HOT and myself have worked together back in June/July and actively suggested to Maxar to get such a solution in place (or, in fact, any other solution which would be acceptable by both Maxar and OSM). This even resulted in one person spontaneously flying to a conference to talk in person about this very idea with a Maxar representative. Unfortunately, our efforts had not been fruitful at the time.
OK, thanks for the update @tyr_asd. I appreciate the effort you all put in to find a resolution. It sounds like there are bigger issues at play than just authentication then and a community project can’t resolve this.
