I appreciate you mentioning you’re hearing my side of the argument, and to be clear I’m hearing yours and I agree with a lot of it up to the point that someone publishes their own PII intentionally, that’s the sticking point for me here.

So yeah if you’re talking only abstractly and intentionally ignoring the practical then we’re definitely talking past each other a bit. It’s hard to discuss rights that can’t be enforced and aren’t part of a specific legal code; normally if it isn’t law and can’t be enforced, it’s more of an idealistic goal than a right. GDPR is entirely based on “reasonable” precautions, it does not and cannot demand anything impractical of companies that haven’t violated the law. Imagine you’re giving @BoppreH actual advice about what to do, and tell me what he can realistically do that won’t cause him months or years of work and frustration, or ultimate failure to revoke and protect his published PII.

I should be in charge of my PII. I am in charge of my PII. What does “in charge” actually mean though? There are two specific issues here in this case that make the question of who should be in charge a moot question. One is that @BoppreH was in charge of his PII and chose to publish it. That is control over his PII that he exercised. His actual stated wish was for GPT-3 to somehow guess that his PII found on Google should not be indexed by GPT-3. A human wouldn’t do that, so why should a machine? My issue here actually does go straight to your question: if someone revokes intentionally published PII, that can cause harm to others. Imagine you write a biography and in it in a chapter about your best friend BoppreH, who agrees in writing to be featured in your book. You publish the book and six months later your friend says, “no, wait, I don’t like that anymore, I revoke it and I want all mention of me retroactively erased: I have a right!” What can you actually do? This could cause loss of income for you and your publishing company, distress and loss of friendship, lawyer fees, reprinting, destruction of unsold stock, costly time spent editing and renegotiating and redistributing. I’m imagining just a few of the many bad things that could happen with a book, but there are many analogous issues, and some unique problems too, with deletion of data online.

Have you considered the possibility that @BoppreH may have in effect signed multiple contracts stating that he agrees to publish personal information and not hold the publisher liable for it, or demand that it be taken down? (This is not an abstract question, this is what GitHub’s license states, for example, and others here pointed out that some of his PII was on GitHub.) How do you reconcile a so-called right to revoke PII with consensual contractual agreement to publish this PII? You’re arguing that this right to revoke should be allowed to override signed contracts without cause? There are so many legal & practical problems with that idea, I don’t know where to begin.

The other issue is that once information goes public, it cannot be reasonably contained. The transition from private to public is a one way street, it always has been, and it has never gone the other way, by and large. This is in fact codified into law in many ways (securities laws, for example, specify actions to take when insider information is leaked), and the fact that the publishing of information can’t be taken back has been the default assumption for humanity for a very long time.

The idea that somehow you can revoke something that’s published and public is a very new idea. The idea that it can be for any reason at any time even if you previously agreed to it is a very naïve idea that doesn’t yet exist in practice. It’s a good thing that there are specific exceptions, but in general unpublishing on a whim isn’t realistic. We already know that media companies haven’t been able to stop movie or song piracy with DMCA nor copy protection schemes nor fines & lawsuits, why would we think unpublishing personal information from the internet is even possible? Generally speaking, it’s not.