Not the person you're replying to, but: I just use a separate, dedicated Chrome profile that isn't logged into anything except what I'm working on. Then I keep the persistence, but without commingling in a way that dramatically increases the risk.

edit: upon rereading, I now realize the (different) prompt injection risk you were calling out re: the handoff to yt-dlp. Separate profiles won't save you from that, though there are other approaches.

▲

bartek_gdn 10 hours ago | parent | next [-]

That's also my approach, built quickly a cli for this with lightweight session management

https://news.ycombinator.com/item?id=47207790

▲

sofixa 12 hours ago | parent | prev [-]

Even without the bash escape risk (which can be mitigated with the various ways of only allowing yt-dlp to be executed), YT Music is a paid service gated behind a Google account, with associated payment method. Even just stealing the auth cookie is pretty serious in terms of damage it could do.

▲

mh- 12 hours ago | parent [-]

Agreed. I wouldn't cut loose an agent that's at risk of prompt injection w/ unscoped access to my primary Google account.

But if I understood the original commenter's use case, they're just searching YT Music to get the URL to a given song. This appears[0] to work fine without being logged in. So you could parameterize or wrap the call to yt-dlp and only have your cookie jar usable there.

[0]: https://music.youtube.com/search?q=sandstorm

[1]: https://music.youtube.com/watch?v=XjvkxXblpz8

	▲	sofixa 12 hours ago \| parent [-]
		Oh, that's true, even allows you to play without an account. I can swear that at some point it flat out refused any use unless you're logged in with an account that has YT Music (I remember having to go to regular YouTube to get the same song to send it to someone who didn't have it).