Open theDanielJLewis opened 3 years ago
I've asked Bryan Barletta of Sounds Profitable, a weekly podcast ad-tech newsletter that's part of Podnews, to take a look at this.
https://github.com/opawg/podcast-hosts contains the capabilities of podcast companies. It doesn't include a consent opt-in, but does contain the possible privacy elements that each host is capable of. It's open data, and I'd welcome additions and corrections.
Yes, I think it could be helpful to automatically bring that in, too.
Even if the structure or idea of this changes radically, I still think it's a good thing to bring up. Getting out ahead of a real issue.
I've asked Bryan Barletta of Sounds Profitable, a weekly podcast ad-tech newsletter that's part of Podnews, to take a look at this.
https://github.com/opawg/podcast-hosts contains the capabilities of podcast companies. It doesn't include a consent opt-in, but does contain the possible privacy elements that each host is capable of. It's open data, and I'd welcome additions and corrections.
Bryan is a voice that is missing here. His input would be welcome for a few of these tags.
Sorry for the delay, not sure how I missed this! I want to start by saying I'm pro privacy but also pro advertising/adtech.
Right now, there are only a few areas of the world where privacy regulation is enforced that covers IP address as PII. Some companies are making choices to apply the regulation worldwide if they're required to adhere to it by operating in one of those areas. Other's say they are, but aren't. And many more are keeping the regulated and unregulated areas separate.
From a user perspective, the idea of giving consent per podcast could be very off putting. Listeners are "overcast users" or "apple podcast users". Based on the information available to the apps/players vs what's sent to the podcasts themselves, I would heavily agree.
Putting aside that some of the podcast apps are small enough business wise to not have to adhere to some of the privacy regulations out there, I want to share an example: When Apple launches their consent framework for sharing IDFA, if the user doesn't consent, the developer still gets the users IP address, user agent, and the content they're accessing. Same goes if I opt out of cookies. The only thing that regulates IP address is country/state specific policies coming out.
Ultimately, the podcast player itself should be responsible for asking consent of the listener across the board, not just for the IP/UA/content, but for every action the app takes and data they want to gather. If the user opts out, then that should be passed by the player to the host, for the host to adhere to and share that opt out with any other tracking services they use as well. Spotify has more to lose from a user opting out than The Daily does.
What I think might not sit well here is that those companies wouldn't be motivated to offer opt outs anywhere they're not legally required to offer them. I'm also not clear on if they did offer it, if a host or publisher would be required to adhere to it, same as in the example you've listed above. But what I do know is that there are major publishers out there that want to know if their listeners are consenting or not in the territories they're legally required to know that information for, and right now the apps do not provide that data when ultimately it's their responsibility.
I would love to set up a longer conversation about this and be a part of helping get it adopted as I think right now, we're living in a legal grey zone of people making assumptions and listener privacy (at least where its legally mandated) is absolutely not being protected.
I would love to set up a longer conversation about this and be a part of helping get it adopted
That’s a good idea. What form should that discussion take? The complexity of privacy related tags really lie outside of the tag structure itself. So GitHub discussions might be a poor place for that discussion. A round table on a podcast with a few vested voices might be good.
Yea, I think this would do best with voice. Happy to join whatever you think is best.
10-4.
I’ll ping @jamescridland and see if we can put something together.
You can reach me directly: bryan@soundsprofitable.com
Last year at this time, we got into a lot of these issues at the PRX event in NYC (https://www.podcastprivacy.org/). Andrew at PRX would be an excellent contact too.
The PRX event on privacy that was a fully private event, and people outside the US were locked out from contributing? Ah, yes, that one. When PRX wants an inclusive discussion on privacy, they're welcome to come asking. (Still sore about this one).
I'd love to have this considered for the next phase of the Podcast namespace.
Whereas more companies are adding increasing levels of tracking and attribution, and whereas more regions are instituting new regulations to protect privacy and personal data, I propose a new
<podcast:privacy>
tag to enable both disclosure and consent (when needed).Here are some example of how the tag could be implemented:
The presence of the
consent
attribute will trigger the player's interface to offer consent options. Ifconsent
isoptional
, then the podcast can be streamed or downloaded regardless of consent, but every download request will include adonottrack=true
parameter that all redirects and hosting providers should honor.consent='false'
would be the same as omitting the attribute.If
consent
isrequired
, then the podcast can be streamed or downloaded only if consent is given. If consent is denied, then the podcast will not be playable.Omitting
consent
will neither display a consent form nor change anything about streaming or downloading.updated
would be the date of the privacy policy's last update. When a user responds toconsent
, the date of consent and date of the policy should also be saved by the client app. If the date of the policy is later than the date of consent (or there is no date of consent after the privacy policy's date), then the app should trigger the consent form again. Or maybe more simply, if the date changes to anything other than the date the user consented to, trigger consent again.I believe this will help podcasters and podcast-service providers comply with privacy regulations, it will keep podcast-consumers informed of their data usage, and it will help podcast-app developers ensure the privacy of their users (and might even win over their interests in supporting the Podcast Namespace).