Bug reports on any software

Woah.. that question triggered a lot of homework for me and I still can’t concretely answer it. From a GDPR standpoint, I’m not sure. The Working Party 29 covers data portability in doc wp242. This bit touches on it:

By granting access to data via an API, it may be possible to offer a more sophisticated access system that enables individuals to make subsequent requests for data, either as a full download or as a delta function containing only changes since the last download, without these additional requests being onerous on the data controller.

There are requirements that the procedure be easy for data subjects. It’s worth considering the main motivation for Article 20: to facilitate competition ultimately to give consumers choice. It was written with services like Twitter and Facebook in mind, whereby a corporate commercial service wants to make it as difficult as possible to switch to a competitor.

So you can imagine that the mere existence of an API may not satisfy the requirement that a full download be easy if the API is designed to impose much logic in the consumer code. OTOH, the WP29 opinion only mentions ease for the data subject, not necessarily ease for the new data controller. So if the current data controller makes an API available but makes getting a full data set a complex task of searching for content and grabbing one record at a time, I’m not sure how that would play out in a court.

I actually think the wp242 falls short because it’s only 15 pages and leaves a lot of questions. What if a data controller offers an API, but the API includes a CAPTCHA that the new controller must solve? The new controller would have to implement code to redirect the CAPTCHA to the data subject, which the old controller could make very painful to thwart data subjects exercising their Art.20 rights.

Guess I would have to dig into case law to know more.

GDPR aside, from a practical standpoint, if the API were enough then why have clients? The API is only ½ the solution, which needs a client. If there are no clients to fetch the data, then users are not getting their data. Alternatively a Lemmy server fetching data from another in a migration would not call for a client app, but that’s not happening either.

Mastodon’s web UI includes an archive fetch feature that give users a tarball. That feature is not in the API; it’s unique to the web UI. Kensanada wrote a client to grab user’s data using the API (which has no archive interface, just an interface to search and grab one record at a time). So the mastodon API is a bit haphazard and excludes the simple tarball fetch that the web UI has. He had to write the code to detect if the same record was fetched 3 times, it then concluded that all the data has probably been fetched after a certain amount of repetition occurs. I think users can configure how many duplicates might imply that all data was grabbed, but it’s a bit shitty that the API creates that situation of uncertainty. You don’t really know if you have received all the data from the Mastodon API. It’s an example of the existence of an API falling short of expectations.