Screenshot of Stardust's website.
Stardust: Research Findings
Stardust is a New York-based astrology-themed period tracking app that has recently risen in popularity, having received a spike in downloads in the U.S. following the overturning of Roe v. Wade.
Long Read
Post date
6th May 2025
Go back to the full report page
Stardust is a New York-based astrology-themed period tracking app that has recently risen in popularity, having received a spike in downloads in the U.S. following the overturning of Roe v. Wade. According to its website, the app takes a de-identification approach to users' privacy by utilising a third party 'security system' operated by Rownd, “an authentification platform that stores your contact information for us [Stardust] so that we cannot associate your health data with your real-world identity”. In theory, this means that Stardust manages users' period input data while Rownd stores the users’ identifiable account data like their name and sign-up email in such a way that Stardust cannot link users' input data with their unique account profile managed by Rownd. Notably, Rownd is not named in Stardust's Privacy Policy, only on the website. To get started on the app, we were required to create an account via Google. By signing up with our Google account, it was made clear that our user agreed to Google sharing their name, email address, and profile photo with Stardust (Figure 7.1).
Figure 7.1. Screenshot of the sign-up page with Google allowances.
After connecting our account with Google, we completed Stardust's onboarding questionnaire, which asked for our purpose for using the app (e.g., for period tracking), our date of birth (which was required) and a range of period information like our latest period and birth control method. During this process, we noticed a plethora of URLs from Rownd's API in the web traffic:
Figure 7.2. The Request shows Rownd is processing our 'intent: sign_up'
Figure 7.3. Rownd's API responds with 'sign_in_method: google', as we signed up via our Google account.
Note that all these and following calls to Rownd by Stardust occurred over the Cloudflare CDN, which is not named in Stardust’s Privacy Policy. Rownd utilizes Cloudflare for the delivery of their authentication services. We’ve already discussed Cloudflare’s security layer above, and Rownd also clarified that robust TLS (transport layer security) encryption is used by Cloudflare between Rownd and its communications with the client, including between Cloudflare.
While using the app, with every update we inputted, the Stardust API requested a 'rowndToken' associated with our account. In theory, this links all our account data managed by Rownd (e.g., first and last name, log-in email) with that unique token:
Figure 7.4. The Stardust API requested a 'rowndToken' for this user.
Figure 7.5. The response shows the birth control entry we inputted for this unique rowndToken. Note that the Stardust API here reads 'null' for the data points for 'firstName' and 'lastName' but did seem to have access to the ‘birthday’ data point.
In Figure 7.5, we can see that the Stardust API did not appear to have access to the first and last name of the user for the specific ‘rowndToken’ (‘null’ for these fields), but it did appear to output the accurate birthday of the user provided during our sign-up.
As for processing with the Rownd API, everything from our Google email to our last sign in time to our Google ID was being processed by the Rownd API over Cloudflare:
Figure 7.6. See 'email', 'first_name' and 'last_name' which were extracted from our Google account after we linked the account to Stardust.
In Figure 7.6, we can also see detailed information about our sign-in and active times. These fields appeared in the web traffic for calls to Rownd every time we launched the Stardust app and logged in via Google.
As we'll discuss later, the offshoring of user authentication to a third party is an interesting approach to de-identification where, rather than not collecting account-based user data (e.g., email for sign-up), Stardust assigns this process off to a third party.
When it came to our in-app use of inputting our cycle information, our cycle data indeed appeared to be logged in the web traffic and sent to Stardust's own API as we exhibited above in Figure 7.5. In the below example, too, we can see our temperature information we recorded for the specific start date being sent to Stardust’s API:
Figure 7.7. The API requested the date for our entry.
Figure 7.8. In response, our inputted 'temperatureUnit' and 'value' was logged.
We could also see all the symptoms we recorded and our period start date as well as predicted dates we'd recorded under 'my-logs':
Figure 7.9. The dates requested for the entries to be logged for this month's cycle.
Figure 7.10. The response that includes a list of all the symptoms ('attributes') logged for those dates under the entry 'my-logs'.
We noticed a few appearances of other third parties, such as US-based MixPanel, which is an analytics service for developers to measure the performance of their product and marketing, with 'all your data, in one place'. It was difficult to discern in the web traffic what data was being requested, as the data in the request and response was encoded, so we cannot conclusively say whether the data sent to MixPanel represented device-related data or other data. We also noticed one appearance of AppsFlyer in the web traffic, though it did not appear that personal data of note was being requested. Notably, AppsFlyer was one of the few third parties mentioned by name in Stardust's Privacy Policy.
Like many of the other apps, Stardust also appeared to have integrated with Firebase, which meant the collection of certain device-related data for its Crashlytics crash reporting tool (see URL on the left-hand side):
Figure 7.11. See 'features' and 'crashlytics' in the URL.
We also saw several appearances of US-based OneSignal, which is a third-party push notification integration for sending app notifications to a user. We did not enable notifications in our test, so the request from OneSignal occurred only when we first launched the app (likely as part of the app's build). However, even in this case the third party did appear to extract some device-related data:
Figure 7.12. See 'language', 'timezone', 'device_model'. Note we see 'enabled:false', which means we have not yet enabled push notifications. This does not mean the data is not being collected, just that notifications for this device have not been enabled
Figure 7.13. The response for the above request assigned us a 'onesignal_id' for our device and other related information for when notifications are enabled.
Another third party that appeared in the web traffic was Revenue Cat, which facilitates in-app purchases. We did not subscribe to anything in Stardust, so we cannot say with certainty what would be shared with Revenue Cat beyond the standard subscription-related information (e.g., payment info) and what we see below, such as sign in times. However, we did notice that Revenue Cat operated over third party cloud server 'envoy', which is run by US-based ride-sharing company Lyft.
Figure 7.14. See 'server: envoy'.
Note that none of these third parties (Rownd, Firebase, Mix Panel, OneSignal, Revenue Cat, envoy), nor Cloudflare, were named in the Privacy Policy. The only third parties disclosed were AppsFlyer and optional integrations like Google Fit, Apple Health and Oura Ring. There was general mention of tracking technologies like 'cookies, pixels and SDKs' being used to collect interaction information about users, but no specifics were provided. For an app that claims to engineer privacy into its implementation, it appears that its Privacy Policy perhaps falls short of comprehensive, transparent disclosures.
Read more
- Our Research Methodology
- Research findings from the apps
- Analysis: What does this all mean?
- Conclusion and Recommendations
What can I do?
If you want to make sure we can keep doing work like this you can donate now to make sure PI can keep holding governments and companies to account.
Related learning resources