You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In hosting guidance for publishers it might be helpful to add some information about making sure that a publisher's data is genuinely open data and accessible programatically / via a bot / software.
We've previously seen instances where anti-ddos, bandwidth savers, anti-bot, reCapture, cloudflare / other CDNs using "are you human" as well as web browser assumptions being made (such as javascript and SSL certificates that are bundled with common web browsers like firefox). It's quite a technical subject but could be mentioned in a high level way.
We recently published https://iatistandard.org/en/guidance/publishing-data/publishing-files/publishing-without-access-restrictions/ for IATI. We found that when talking to people directly about this issue, we get frequent requests to "tell us your IPs/useragents and we'll allow it" so we wanted a resource we could point to that explained why that wouldn't be enough for an open data standard. Our resource also acknowledges that putting some security on is understandable (last section of "why we need ...." page).
In hosting guidance for publishers it might be helpful to add some information about making sure that a publisher's data is genuinely open data and accessible programatically / via a bot / software.
We've previously seen instances where anti-ddos, bandwidth savers, anti-bot, reCapture, cloudflare / other CDNs using "are you human" as well as web browser assumptions being made (such as javascript and SSL certificates that are bundled with common web browsers like firefox). It's quite a technical subject but could be mentioned in a high level way.
The text was updated successfully, but these errors were encountered: