Privacy Bulletins

Our normal data collection practices are described in the FAQ. Whenever we need to temporarily change (increase) our data collection, we will describe here what we're doing and what the impact is.

2023-11-16: Privacy Policy update

What we're doing
We are updating our Privacy Policy to add mention of optional coarse location data collection. For the exact changes, see the GitHub commit.
Why we're doing it
We are adding optional coarse location data collection to some client platforms.
When we're doing it
This will be in effect on 2023-11-17T00:00Z.

2023-05-08: Privacy exception: Possible exposure of client IP addresses

Affected applications
Psiphon Android and Psiphon Windows running the Conjure tunnel protocol, which is enabled only for certain countries and ISPs.
What happened
Authentication for Conjure stations connecting to the Conjure registrar was mistakenly removed in a refactor that was introduced around the end of October 2022.
Impact

It was possible for any actor aware of the issue to connect to the Conjure registrar and obtain a list of active registration information, including associated client IP addresses.

Once the issue was discovered in late April 2023, logs were monitored and no suspicious connections to the Conjure registrar were observed.

Resolution
A fix, restoring authentication, was implemented and is now deployed.

2023-02-01: Privacy Policy update

What we're doing
We are updating our Privacy Policy. We removed links to advertising partners that we are no longer using. For the exact changes, see the GitHub commit.
Why we're doing it
We're not using those advertising partners anymore, so links to them are no longer relevant.
When we're doing it
This will be in effect on 2023-02-01T00:00Z.

2021-10-06: Minor Privacy Policy update

What we're doing
We are updating our Privacy Policy. We modified the text of a heading, with no change in meaning. For the exact changes, see the GitHub commit.
Why we're doing it
To avoid potential confusion caused by the previous heading.
When we're doing it
This will be in effect on 2021-10-06T00:00Z.

2021-09-09: Privacy Policy update

What we're doing
We are updating our Privacy Policy. We are adding information about my.psi.cash. For the exact changes, see the GitHub commit.
Why we're doing it
To ensure the Privacy Policy accurately reflects our data practices.
When we're doing it
This will be in effect on 2021-09-09T00:00Z.

2021-05-12: Privacy Policy update

What we're doing
We are updating our Privacy Policy. We are adding information about PsiCash accounts. For the exact changes, see the GitHub commit.
Why we're doing it
To ensure the Privacy Policy accurately reflects our data practices.
When we're doing it
This will be in effect on 2021-05-13T00:00Z.

2021-05-11: Privacy Policy update

What we're doing
We are updating our Privacy Policy. We are making the information about email server logging more accurate. For the exact changes, see the GitHub commit.
Why we're doing it
To ensure the Privacy Policy accurately reflects our data practices.
When we're doing it
This will be in effect on 2021-05-12T00:00Z.

2021-01-26: Privacy exception: Rare accidental logging of sensitive information

Affected applications
Psiphon for Windows v160.
What happened
A change was introduced to the Psiphon Windows application which resulted in the potential for some logs emitted by the bundled executable to be classified as crash logs. This allowed those logs to bypass the measures put in place to avoid logging sensitive information. If the user subsequently submitted a feedback and opted-in to including diagnostic information, then these logs would be shipped to Psiphon.
Impact
On 2021-01-26 at 8:23am EST a single user feedback containing a log which included the file path of the Psiphon executable on their computer was discovered. Fortunately, the file path did not reveal any personally identifiable information (PII). No known external leak of this data occurred. No other feedbacks containing sensitive information were found.
Resolution
On 2021-01-26 at 11:45am EST code was deployed to immediately redact any occurrences of these diagnostic messages found in user feedbacks shipped from Psiphon clients. The Psiphon Windows application was patched in version 161.

2020-11-27: Possible use of ACCESS_COARSE_LOCATION permission by 3rd party advertising SDKs

Affected applications
Psiphon Android (downloaded from Google Play) prior to v314; Psiphon Pro prior to v314.
Background
Psiphon clients use the ACCESS_COARSE_LOCATION permission in order to determine the WiFi BSSID. The WiFi BSSID is used to remember internal Psiphon settings that work best on different WiFi networks. The WiFi BSSID is only stored locally, and is not transmitted to Psiphon servers. Versions of the Psiphon client for Android that use 3rd party advertising SDKs direct those SDKs not to use the ACCESS_COARSE_LOCATION permission for location-aware advertisement targeting.
What happened
One of the 3rd party advertising SDKs used in Psiphon clients for Android no longer has a setting to prevent it from using location services for location-aware advertisement targeting. Additionally, new 3rd party advertising SDKs were added to Psiphon clients that also do not have a setting to prevent the use of location services for location-aware advertisement targeting.
Impact
It is possible that 3rd party advertising SDKs used by Psiphon clients for Android have been using location services for location-aware advertisement targeting when the ACCESS_COARSE_LOCATION permission is granted.
Resolution
All Psiphon clients for Android v314 remove the ACCESS_COARSE_LOCATION permission to prevent 3rd party advertising SDKs from using location services for location-aware advertisement targeting. Psiphon clients for Android now use a less precise mechanism for distinguishing between WiFi networks in order to remember internal Psiphon settings that work best on different WiFi networks.

2020-11-09: Privacy exception: Rare accidental logging of upstream proxy credentials

Affected applications
Psiphon iOS prior to v1.0.48; Psiphon Android prior to v302; Psiphon Windows prior to v158; Psiphon Library prior to v2.0.12.
Background
Psiphon clients enable users to connect through upstream proxies. Users manually configure upstream proxy settings, including any required credentials. Psiphon logs network error messages to diagnostics included in feedback that users submit to Psiphon; and logs network error messages with connection failure metrics automatically sent to Psiphon. When a connection to an upstream proxy fails, related errors are logged.
What happened
Internally, upstream proxy settings are represented as a URL and parsed with Go’s net/url. url.Parse error messages echo back the URL, which will include credentials when present. This error, containing credentials. was logged to diagnostics and connection failure metrics, causing credentials to be exposed to Psiphon. This situation was exacerbated by failure to URL encode user input upstream proxy settings, making the parsing failure more likely.
Impact
Diagnostics containing upstream proxy credential and connection failure metrics were shipped to Psiphon and stored, for the "User Activity Data" retention period, on our internal systems. No known external leak of this data occurred.
Resolution
Code was deployed to immediately redact any occurrences of these diagnostic messages found in user feedbacks and connection failure metrics shipped from Psiphon clients. All related diagnostic messages and metrics were deleted from Psiphon’s systems. Clients were updated to strip URLs from upstream proxy URL parse error messages before shipping errors to Psiphon.

2020-11-09: Privacy exception: Rare accidental logging of network request destination on Psiphon iOS VPN

Affected applications
Psiphon iOS VPN versions 1.0.43, 1.0.44, and 10.45 (https://apps.apple.com/us/app/psiphon/id1276263909).
Background
Psiphon’s iOS VPN application uses the “VPN On Demand” feature provided by iOS to ensure that the VPN is restarted in the event that the device is rebooted or the VPN crashes. The first network request made after the device is rebooted, or the VPN crashes, will trigger the configured “VPN On Demand” rules to start Psiphon and queue network requests until Psiphon has re-established its connection and is ready to transit traffic again.
What happened

On June 25th, 2020 we released a change which logged metadata provided by the OS when the VPN was started. We chose to log this metadata because in testing it included non-sensitive information such as whether the VPN was started by the OS due to “VPN On Demand” rules or the user starting the VPN from Psiphon’s UI. On July 21st, 2020 it came to our attention that the destination hostname, or IP address, of the first network request which triggered Psiphon to be started after a device reboot, or crash in the VPN process, was included in this metadata.

Once logged, the metadata could be included in a feedback submitted by the user through the in-app feedback form. Provided that the user did not opt-out of including diagnostic information with their feedback.

When a user submits a feedback it is encrypted with a public key, which is paired with a private key that we own and keep secret. This ensures that only our feedback servers can decrypt and read the contents of a user’s feedback once it is sent out over the internet. The encrypted feedback is uploaded over TLS. Once the feedback reaches our servers it is decrypted, stored for a limited amount of time and then deleted.

Impact
Fewer than 10 logs which included the network destination of a request originating on the client were stored on Psiphon’s servers.
Resolution
On July 22nd, 2020 a fix was released in Psiphon iOS VPN version 1.0.46 and the sensitive logs were deleted from Psiphon’s servers. Also, code was deployed to immediately redact any occurrences of these log lines found in user feedbacks shipped from the affected client versions as they are decrypted on Psiphon’s servers.

2020-06-19: Privacy exception: Accidental user IP retention

What happened
We use AWS S3 to host websites, client applications, and remote server lists. We discovered that logging had been enabled for many of our S3 resources since June 2015. These logs include IP addresses of users who accessed those resources.
Impact
We found no indication that any logs were obtained by any external party, so this is not a user data breach. However, it is a violation of our Privacy Policy.
Resolution
Logging has been disabled for user-accessible S3 buckets and all logs have been deleted. We are working on a system to keep track of privacy exceptions and issues, and investigating AWS resource auditing.

2019-12-11: Temporary data retention extension

What we're doing
We are temporarily halting User Activity Data pruning, effectively extending the data retention period.
Why we're doing it
We need to keep granular activity data longer to give us time to analyze recent censorship events.
When we're doing it
This will be in effect starting 2019-12-12T00:00Z. It will be in effect for one month. We will update this bulletin if it needs to be extended beyond that.
Update
User activity data retention was returned to normal by 2020-04-10.

2019-12-11: Privacy Policy update

What we're doing
We are updating our Privacy Policy. We are changing the retention period of User Activity Data from 60 days to 90 days. We also expanded the information about Privacy Bulletins. For the exact changes, see the GitHub commit.
Why we're doing it
To ensure the Privacy Policy accurately reflects our data practices.
When we're doing it
This will be in effect on 2019-12-12T00:00Z.

2015-06-01: Privacy Policy update

What we're doing
We are updating our Privacy Policy. This includes merging into it the answer to the FAQ question “What information does Psiphon collect?”.
Why we're doing it
The Privacy Policy page is now the only place users need to check for Psiphon's privacy and data collection policies. It has been updated to reflect use of advertisements, analytics, and logging for some of our websites.
When we're doing it
This is in effect by at least 2015-06-01T00:00Z.

2014-04-17: Enable S3 bucket logging

What we're doing
We are enabling access logging for one website Amazon S3 “bucket” (i.e., storage container). (For technical reasons, we run dozens of copies of the website in different S3 buckets.)
Why we're doing it
We are doing this to determine how many accesses there are to the “remote server list” stored in the bucket. This will help to give us an idea of how many users are failing to connect.
When we're doing it
Logging will be enabled from 2014-04-17T15:00Z to 2014-04-18T15:00Z.
What user data will be collected
The logging will collect IP addresses, user agents, and timestamps of access to one website. When that data is processed, we will have a count of users divided by geographic region that have accessed the file in question.
How long the data will be retained
The data will be retained no more than one week. We will be keeping the count of users longer — possibly indefinitely.
How many users are affected
We don't know for sure yet how many users will be affected (that's why we're doing this), but we suspect it will be fewer than 10,000 users.
Who besides Psiphon Inc. will see this data
The access logs are also stored in an Amazon S3 bucket, so Amazon will have access to the logs. (However, Amazon serves the files, so they can already access this information.)