隱私公告

我們正常的資料收集實踐已在FAQ中描述。每當我們需要臨時更改(增加)資料收集時,我們將在這里介紹當中的過程跟影響。

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

我們在做什麼
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.

2019-12-11: Privacy Policy update

我們在做什麼
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.

2015-06-01: Privacy Policy update

我們在做什麼
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.

2014-04-17: Enable S3 bucket logging

我們在做什麼
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.)