Subscribe by email, free
Your daily briefing for podcasting and on-demand
A map with pins pushed into it
Image: Z via Unsplash

Podcast app sent your location to any podcast publisher

· By James Cridland · 10.1 minutes to read

Exclusive

Podnews can reveal that Rova, a free radio and podcast app from New Zealand company MediaWorks, has been putting user privacy at risk by voluntarily sending information to any podcast publisher that could be used to track individual users of their app.

The company, and the Google Play Store, failed to disclose this behaviour; however, after our investigation, the company is to release a new version of their app.

A tale of three downloads

Hello Doha

Download 1

On Oct 22 at 14:59:05, a logged-in user using Rova played a podcast.

That user had opened the app on their Pixel 6 Pro, running Android 13, about twenty seconds earlier at 14:58:44.

We’ll call that user 2b8b3113-b0d5–4189-b0b9-d31c0cdfcf61 - because that’s the listener ID that Rova has given them.

The user’s GPS co-ordinates, reported by their phone, were 25.2613,51.6012 - revealing that they were in Hamad International Airport in Qatar.

Rova automatically supplied all this information to the podcast publisher, which did not request it.

Hello Christchurch

Download 2

Earlier, on Oct 5 at 13:07:56, a user on a Samsung Galaxy S8, running Android 9, played a podcast on Rova.

They’d already been using Rova for some time: opening the app at 12:38:04.

This was a different user, with a different listenerID. They were listening in Papanui, a suburb to the North West of Christchurch in New Zealand. (We’ve withheld their details).

Rova automatically supplied all this information to the podcast publisher, which did not request it.

Hello Brisbane

Download 3

On Oct 23 at 09:55:04, a user using Rova played a podcast.

It was the same logged-in user that we saw earlier in Qatar: using Rova’s listener ID 2b8b3113-b0d5–4189-b0b9-d31c0cdfcf61.

This time, they’d opened the app at 09:54:53; taking just ten seconds to find the podcast they wanted to listen to.

The user’s GPS co-ordinates, reported by their phone, were -27.4595,152.9629 - a suburb of Brisbane, Australia.

Rova automatically supplied all this information to the podcast publisher, which did not request it.

What’s going on?

The downloads in Qatar and Brisbane were from our Editor, who used this app while researching this story.

The download from the Samsung Galaxy S8? We’ve no idea who that is: but Rova has voluntarily told us a lot about them already - enough to let us track this listener on every listen they make (and begin to make a database of their location).

Podnews did not request this data, and have no contractural relationship with Rova. Like any podcast app, our open RSS feed is listed in their podcast directory.

Normally, when an app downloads a podcast, it just asks for a filename like…

https://podnews.net/audio/podnews221021.mp3

A podcast host (Podnews hosts its own podcast) sees this request, along with a user-agent and the IP address of the person making the download. By itself, this contains no personal information. The IP address isn’t that helpful for geo-targeting, either.

However, we’ve spotted that the Android version (only) of the Rova app is adding a lot of user data to this podcast request. Here’s what Rova sent us, in the download URL:

https://podnews.net/audio/podnews221021.mp3
?companionAds=true
&aw_0_awz.appVers=422
&aw_0_1st.version=7.5.6-exoPlayer2.12%253Aandroid33
&aw_0_1st.ts=1666450743867
&aw_0_req.permissions=1CCC1CCC001C00
&calendar=0
&aw_0_1st.playerId=rova_Android_exoPlayer_v1
&aw_0_1st.cb=1666450743.61949
&aw_0_1st.sessionid=1666450724797.827164
&aw_0_req.appState=fg
&sdkiad=1
&aw_0_req.bundleId=com.mediaworks.therock
&aw_0_req.tapOpp=true
&aw_0_awz.listenerid=2b8b3113-b0d5-4189-b0b9-d31c0cdfcf61
&aw_0_req.lmt=0
&aw_0_req.wopp=0
&aw_0_req.userConsentV2=
&aw_0_1st.gpslat=25.2613
&aw_0_1st.gpslong=51.6012

The aw_0 data is connected with AdsWizz, a programmatic advertising system used by publishers to monetise their content.

AdsWizz is used by many different broadcasters. A competitor to MediaWorks in New Zealand highlighted how they had used AdsWizz to create “individually-targeted content delivered in close proximity to the locations our beachgoers were heading to”, in order to promote them Corona beer using a super-local surf report.

The use of AdsWizz is fine, as long as users have voluntarily given their consent for their location to be used. In this case though, Rova is giving trackable, private information about their users to every single podcast hosting company - and the podcast hosting companies haven’t asked for it.

The listenerID allows a podcast host to track an individual listener’s behaviour, even if they listen to different shows or use multiple networks.

The GPS co-ordinates are to 4 decimal places, or 10m of accuracy: if they’re accurate, that’s enough to recognise an individual street or large building.

This data was attached to every podcast request - and sent to every podcast hosting company. Most podcast hosting companies would hide this information from their users.

From DNS calls we’ve observed, Rova also appears to be sending data to Triton Digital, Xperi’s app development company All In Media, and to Adobe’s retargeting tool Demdex.

Get the free Podnews newsletter for more like this.
Our privacy policy keeps your data safe.
(Fill this in now; you won’t lose your place!)

Rova location permission

Are users giving consent?

Android’s location permissions require an app to ask for permission to access location.

Rova does this upon launch. An attempt to decline location permission takes you to a dialog box that tells you “I need a location”. You can still answer “I’m sure”; but next time you open the app, Rova once again asks for permission. (When you decline, however, Rova does not share your location).

In order to use Rova, you must register or log in with your MediaWorks account in order to use the app. The app asks for your gender, age and mobile number (“so Rova can get in touch with you if you win something”), although it appears these aren’t mandatory to fill in.

During that registration process, it asks you to check that you’ve read the terms and conditions. The link for the terms and conditions in the registration form just redirects to the MediaWorks homepage - and no terms and conditions are linked from that page.

Rova location permission

Is the data sharing clear in the Google Play Store?

No. The Google Play Store listing says that “no data is collected” and “no data is shared with third parties”. This is demonstrably false.

The app’s privacy policy link within Google Play links to a PDF called “Website terms of access”, which makes no mention of Rova. Under “what information do we collect”, it does not explicitly mention your location data: nor the fact that they share it with third parties.

Particularly, we’re surprised that the use of the location API within this app has not automatically added information that this app may have access to our location.

We asked Google Play for a statement about this, and how they verify developer claims. Given that the location request is visible in submitted code, we asked why they don’t automatically check this detail. They told us:

We work closely with the developer community to ensure they understand the importance of providing accurate information so users can make informed decisions about what apps they use. … Developers alone are responsible for making complete and accurate Data safety section disclosures for their apps. (click to expand their statement in full)

Google Play’s User Data policy requires developers to provide accurate information in their Data safety forms. We work closely with the developer community to ensure they understand the importance of providing accurate information so users can make informed decisions about what apps they use.

If we find that a developer has provided inaccurate information in their Data safety form and is in violation of the policy, we will require the developer to correct the issue to comply. Apps that aren’t compliant are subject to enforcement actions.

We also encourage app developers to independently assess their applications for mobile security best practices, using the Mobile Application Security Assessment program. Developers can work with an App Defense Alliance Authorized Lab to complete a security review and showcase this independent validation on their Data safety section. This security badge can help users feel more confident about an app’s commitment to security and privacy.

Only developers possess all the information required to reflect their data practices accurately in their apps’ Data safety section. Developers alone are responsible for making complete and accurate Data safety section disclosures for their apps.

Rova location permission

Is the data sharing clear in the Apple App Store?

Yes. It’s very clear.

The “App Privacy” details are spelled out clearly, including Rova’s use of “precise location”. There is no difference between the functionality of the app on iOS and Android, so it’s curious to us why the privacy details are so different.

The app’s privacy policy links to the same PDF called “Website terms of access”, however.

Is this legal?

By supplying this information to third-parties who haven’t requested it, and who haven’t entered into a contractural agreement with MediaWorks, it is difficult to see how this app’s current behaviour agrees with New Zealand’s Privacy Act 2020 Principle 5 - storage and security of personal information - or Principle 12 - disclosure of personal information outside New Zealand.

MediaWorks responds

MediaWorks has given us this statement:

Earlier this year, we integrated the AdsWizz SDK into rova which has also enabled the sharing of geolocation data only, with our third party podcast providers.

While it does state within our privacy policy that we may share this data with third parties, there was an oversight on our part when submitting the app to the Play Store. We have since updated the settings within the Play Store and App Store to declare that we store geolocation and share this information. These updates are now waiting to be reviewed and approved by the Play and App stores.

On 30 September we released a new version of rova which stopped tracking precise geolocation and instead tracks 'device location estimate’. This estimate is accurate to within about 3 square kilometers (more information here). The latitude and longitude which you have noted here, while providing an exact location, is not likely to be the location of the user but rather a location within 3 square kilometers. We appreciate you raising this concern however and to make sure all our users are now covered, we will make our next app release a 'forced update’ so that none of our users, who are still on an older version of rova, will be sharing precise location data with us (or any third parties).

Also just to add, when our users download rova for the first time, they are served with a pop-up offering the option to share location or not. A user can continue to use rova without sharing their location data.

This initial response didn’t seem to answer our questions; so we asked for clarification that Rova will continue to send geo-location data, and individual listener identifiers, to third-party podcast hosting companies who they are not contracted with. We shared a draft version of this article with them. They responded:

We are underway with testing a new version of rova which will prevent the sharing of users’ geolocations with all third party podcasters. This new version will be submitted to the App and Play store (Fri Oct 28) and will go live once reviewed and approved by the respective stores (likely circa Thursday next week).

The app update released on 30 September to track 'approximate’ location “accurate to within 3km square radius” has now been rolled out as a 'forced’ update to prevent tracking the precise location of any of our users. Users can still opt to not share their location data and continue to use rova.

We have now taken all measures to rectify sharing users geolocation and once again would like to thank you for giving us the opportunity to comment.

We also notice that third-party podcasts have temporarily disappeared from the app.

Wrapping it up

We asked the founder of Sounds Profitable, Bryan Barletta, for his take. He told us: “For better or worse, podcasting has been on the forefront of advertising privacy thanks to limitations in what data we receive. As we explore a world where we collectively ask for more data, or as partners augment the data they do have, it’s critical that all sources of that data be acquired with consent and handled carefully. There is no data that is worth jeopardizing the relationship between podcast and listener.”

For our part, we remain concerned that listener identifiers and geo-location data were supplied, unbidden, to podcast hosting companies; and that neither MediaWorks nor Google Play seem overly concerned at the privacy implications for their users.

Indeed, after we contacted MediaWorks for a statement, we noticed another listen to our podcast - and another set of geo-location data supplied to us, within 500m of the MediaWorks office in Palmerston North. We think this is the phone (and listener ID) of a MediaWorks employee.

Programmatic advertising has a poor reputation for privacy - unfairly so, in most cases. The podcast industry needs to be squeaky clean on this, to retain listener and advertiser trust.

MediaWorks could, and should, have done better.

James CridlandJames Cridland is the Editor of Podnews, a keynote speaker and consultant. He wrote his first podcast RSS feed in January 2005; and also launched the first live radio streaming app for mobile phones in the same year. He's worked in the audio industry since 1989.

Readers and supporters

Gold supporters

Silver supporters

Support Podnews, and our industry

Get a global view on podcasting and on-demand with our daily news briefing