We are updating our Privacy Policy to add mention of optional coarse location data collection. For the exact changes, see the GitHub commit.

We are adding optional coarse location data collection to some client platforms.

This will be in effect on 2023-11-17T00:00Z.

Psiphon Android and Psiphon Windows running the Conjure tunnel protocol, which is enabled only for certain countries and ISPs.

Authentication for Conjure stations connecting to the Conjure registrar was mistakenly removed in a refactor that was introduced around the end of October 2022.

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.

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

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.

We're not using those advertising partners anymore, so links to them are no longer relevant.

This will be in effect on 2023-02-01T00:00Z.

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.

To avoid potential confusion caused by the previous heading.

This will be in effect on 2021-10-06T00:00Z.

We are updating our Privacy Policy. We are adding information about my.psi.cash. For the exact changes, see the GitHub commit.

To ensure the Privacy Policy accurately reflects our data practices.

This will be in effect on 2021-09-09T00:00Z.

We are updating our Privacy Policy. We are adding information about PsiCash accounts. For the exact changes, see the GitHub commit.

To ensure the Privacy Policy accurately reflects our data practices.

This will be in effect on 2021-05-13T00:00Z.

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.

To ensure the Privacy Policy accurately reflects our data practices.

This will be in effect on 2021-05-12T00:00Z.

Psiphon for Windows v160.

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.

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.

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.

Psiphon Android (downloaded from Google Play) prior to v314; Psiphon Pro prior to v314.

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.

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.

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.

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.

Psiphon iOS prior to v1.0.48; Psiphon Android prior to v302; Psiphon Windows prior to v158; Psiphon Library prior to v2.0.12.

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.

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.

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.

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.

Psiphon iOS VPN versions 1.0.43, 1.0.44, and 10.45 (https://apps.apple.com/us/app/psiphon/id1276263909).

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.

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.

Fewer than 10 logs which included the network destination of a request originating on the client were stored on Psiphon’s servers.

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.

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.

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.

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.

We are temporarily halting User Activity Data pruning, effectively extending the data retention period.

We need to keep granular activity data longer to give us time to analyze recent censorship events.

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.

User activity data retention was returned to normal by 2020-04-10.

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.

To ensure the Privacy Policy accurately reflects our data practices.

This will be in effect on 2019-12-12T00:00Z.

We are updating our Privacy Policy. This includes merging into it the answer to the FAQ question “What information does Psiphon collect?”.

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.

This is in effect by at least 2015-06-01T00:00Z.

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.)

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.

Logging will be enabled from 2014-04-17T15:00Z to 2014-04-18T15:00Z.

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.

The data will be retained no more than one week. We will be keeping the count of users longer — possibly indefinitely.

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.

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.)