Proposal: <podcast:private>

[daveajones]

This would be a simple tag to tell aggregators that this is a private/members only feed and therefore should not be included in a public index or directory:

<podcast:private>[Yes|No]</podcast:private>

I've been adding lots of regex's to the directory ingestion points to make sure they don't pick up private feeds. This would make that job easier, and protect the creators.

[cio-blubrry]

@daveajones today the hack to prevent a private podcast from showing up on most platforms is to not set the email address for the itunes:email tag. Apple, Google, and Spotify do not accept feeds when the itunes:email is not set.

[theDanielJLewis]

I'm conflicted over the necessity of this.

There are multiple methods to get private feeds. For example:

1. Account-specific randomized authentication string in the URL
2. HTTP authentication via username and password in the URL
3. HTTP authentication via login (I think most podcast apps support this)

Obviously, #2 presents a big security risk. #1 might be the choice of the podcaster to make available a "private" feed to the public (I think this was what you had to do with WishList Member in the early days, even if the podcast wasn't members-only). And #3 seems the preferred way to make a private feed publicly discoverable but still protected.

(Please ignore the issue links GitHub automatically added.)

[daveajones]

@daveajones today the hack to prevent a private podcast from showing up on most platforms is to not set the email address for the itunes:email tag. Apple, Google, and Spotify do not accept feeds when the itunes:email is not set.

We currently don’t expect/require a feed to implement the iTunes namespace. Does blubrry require the iTunes namespace for listing in y’all’s directory?

[daveajones]

I'm conflicted over the necessity of this.

There are multiple methods to get private feeds. For example:

1. Account-specific randomized authentication string in the URL
2. HTTP authentication via username and password in the URL
3. HTTP authentication via login (I think most podcast apps support this)

Obviously, #2 presents a big security risk. #1 might be the choice of the podcaster to make available a "private" feed to the public (I think this was what you had to do with WishList Member in the early days, even if the podcast wasn't members-only). And #3 seems the preferred way to make a private feed publicly discoverable but still protected.

(Please ignore the issue links GitHub automatically added.)

I wonder how many apps support #3. My guess is not many. But that’s a totally unscientific guess on my part.

[stuartjmoore]

1. Account-specific randomized authentication string in the URL

I believe Patreon does this with private feeds to keep things simple (HTTP Auth is an extra step of annoyance). But, apps may try and submit your feed to their directory or other recommendation service as a way of discovering new podcasts. A <podcast:private> tag would allow engines to reject non-public feeds.

[PofMagicfingers]

• Account-specific randomized authentication string in the URL

I'm up for this. At podCloud we use this method, to be compatible with as much player as possible, and sometimes I have to contact podcast apps to ask them to remove private feeds from public directories.

We do use itunes:block, that does the trick for most apps but it's not perfect.