This has been used as an attack vector in the past: spot reasonably popular plugin; make author an offer; inject whatever tracking/other malwate stuff new owners want (typically after a delay).
So now we'd have to trust the author to do thorough vetting of a potential buyer and also not sell if vetting is inconclusive. And this against an adversary aiming to cheat their way past vetting.
Might be a cynical take, but it is not one without reason.
As a sibling comment points out, this is due to the permission model. This doesn't let the author entirely of the hook though: the permissions model created the situation, the author chose a particular path. The consequences may not have been foreseen by either, but they do exist and affect users.
>the permissions model created the situation, the author chose a particular path.
perhaps the most reasonable or even only possible path if they wanted their plugin to be able to do what they wanted it to do, which was to keep sites and from messing with your copy and paste functionality - in other words to prevent minor maliciousness.
on edit: sure, to provide the smoothest behavior, but really if it wasn't smooth people would be irritated and not want to use it. I know if I was implementing for myself I would want it to be smooth.
I understand the whole "bad things can be done" perspective, but here for some reason I fall under a "trust but verify" perspective instead.
So now we'd have to trust the author to do thorough vetting of a potential buyer and also not sell if vetting is inconclusive. And this against an adversary aiming to cheat their way past vetting.
Might be a cynical take, but it is not one without reason.
As a sibling comment points out, this is due to the permission model. This doesn't let the author entirely of the hook though: the permissions model created the situation, the author chose a particular path. The consequences may not have been foreseen by either, but they do exist and affect users.