From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc: Eric Wong <e@80x24.org>, meta@public-inbox.org, a.fatoum@pengutronix.de
Subject: Re: Indicating the mirror's origin
Date: Mon, 19 Jun 2023 08:09:16 +0200 [thread overview]
Message-ID: <20230619060916.iyqknpe3wl2xtlvz@pengutronix.de> (raw)
In-Reply-To: <20230615-focal-erosion-poop-df8246@meerkat>
[-- Attachment #1: Type: text/plain, Size: 1925 bytes --]
Hello Konstantin,
On Thu, Jun 15, 2023 at 10:47:46AM -0400, Konstantin Ryabitsev wrote:
> Now, I want to be able to add other external public-inbox repositories to be
> mirrored on lore.kernel.org, but with some clear indication that we're not the
> origin of that data, we're merely mirroring it. Any GDPR removal requests need
> to be sent to $ORIGIN and we'll just propagate any changes.
I think this is the part that won't work. In my understanding, if
someone requests that their data is removed from *your* system, you
won't be able to say "But the data is only a copy from that system over
there, direct your request at them." Yes, if the source of the data
removes the offending content, you can just sync and so remove the
content in your copy, too. But if the operators of the source don't
(because they don't cooperate, or because the relevant people who can
remove the content are on vacation or because they are in a different
jurisdiction or just because the plaintiff doesn't care about their data
at the source), you would need to have a way to remove the content.
Either by removing the content locally in your copy in a way that you
don't get it back in the next sync, or by shutting down that complete
particular archive. Without a visible pointer about the origin of the
copy the situation is identical, so I don't see an advantage when
implementing it, at least not for this purpose.
But maybe I'm missing something or in your jurisdiction things are
different than in (my inexpert understanding of) ours. (Note, I don't
wanna say that if you get such a request to delete some content, we
won't cooperate, but if I were in your position, I wouldn't want to rely
on that kind of cooperation.)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2023-06-19 6:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-14 18:42 Indicating the mirror's origin Konstantin Ryabitsev
2023-06-14 20:18 ` Uwe Kleine-König
2023-06-14 20:56 ` Konstantin Ryabitsev
2023-06-14 23:50 ` Eric Wong
2023-06-15 14:47 ` Konstantin Ryabitsev
2023-06-19 6:09 ` Uwe Kleine-König [this message]
2023-06-20 2:37 ` [RFC] support publicinbox.$FOO.appendHeader in read-only endpoints Eric Wong
2023-07-05 14:27 ` Ahmad Fatoum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://public-inbox.org/README
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230619060916.iyqknpe3wl2xtlvz@pengutronix.de \
--to=u.kleine-koenig@pengutronix.de \
--cc=a.fatoum@pengutronix.de \
--cc=e@80x24.org \
--cc=konstantin@linuxfoundation.org \
--cc=meta@public-inbox.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).