Comment by JimDabell

Comment by JimDabell 2 days ago

1 reply

I’m not sure the linked document makes a good case for this. My initial reaction was that I didn’t understand why they made a point of it being declarative when the permission that results requires imperative code to function.

I think the point behind this is to stop websites from spamming permission popups by moving the permission prompt to page content and making the contents browser-controlled not website-controlled. I think that’s a better model, but it doesn’t really solve the annoyance of having the “fake” permission prompt followed by the real one, does it? Won’t websites just alter their “enable notifications” fake popup to include this?

I also don’t see how this solves the “no easy undo” problem. Won’t websites just remove that element once they gain permission? Or worse, they could spoof it and fake the undo.

josephcsible a day ago

> I also don’t see how this solves the “no easy undo” problem. Won’t websites just remove that element once they gain permission? Or worse, they could spoof it and fake the undo.

You're describing the "no easy undo for allow" problem. Google doesn't care about that and doesn't want to fix it, since they want more of your data, not less. This element is just to have a solution to the "no easy undo for block" problem.