canmove, Confirmed users
1,537
edits
Privacy/Reviews/Telemetry: Difference between revisions
Jump to navigation
Jump to search
→Fingerprinting
m (→Architecture) |
|||
| Line 132: | Line 132: | ||
In this section, the privacy champion will identify areas of user data risk and recommendations for minimizing the risk. | In this section, the privacy champion will identify areas of user data risk and recommendations for minimizing the risk. | ||
=== Fingerprinting === | === Fingerprinting / Tracking === | ||
Based on metrics that are similar from day to day, an individual user might be fingerprinted and tracked across time. Someone with consistent day-to-day browsing habits may have the same memory usage, speed, etc; it is likely that the machine's attributes will also have an effect on the measurements taken so a combination of browsing habits and machine attributes could be a fairly detailed "fingerprint". | Based on metrics that are similar from day to day, an individual user might be fingerprinted and tracked across time. Someone with consistent day-to-day browsing habits may have the same memory usage, speed, etc; it is likely that the machine's attributes will also have an effect on the measurements taken so a combination of browsing habits and machine attributes could be a fairly detailed "fingerprint". It is important to identify and eliminate duplicate entries, however, so some unique ID must be maintained for a short window of time. | ||
''Required Action'': | ''Required Action'': | ||
To minimize fingerprinting risk, it is crucial to ensure that arbitrary web sites absolutely cannot access the telemetry data while it's stored on the client. Additionally, the data should be transmitted from the Client Component to the Server Component over a secured (and preferably authenticated) channel; this means SSL/HTTPS must be used. | To minimize fingerprinting risk, it is crucial to ensure that arbitrary web sites absolutely cannot access the telemetry data while it's stored on the client. Additionally, the data should be transmitted from the Client Component to the Server Component over a secured (and preferably authenticated) channel; this means SSL/HTTPS must be used. Any data that is no longer needed should be erased from our servers, and a unique ID used for duplicate elimination should be short-lived. | ||
''Recommendation'': If possible, the SSL certificate fingerprint should be hard coded into the client and verified before transmitting data so the client can be sure the server where it is sending data is indeed the Telemetry server (and not an attacker intercepting traffic). | ''Recommendation'': If possible, the SSL certificate fingerprint should be hard coded into the client and verified before transmitting data so the client can be sure the server where it is sending data is indeed the Telemetry server (and not an attacker intercepting traffic). | ||
{{ResolutionBox|{{resolved|Required action completed, SSL used on server and invalid certificates cause connection to drop. Recommended fingerprint-hardcoding not implemented.}} }} | {{ResolutionBox|{{resolved|Required action completed, SSL used on server and invalid certificates cause connection to drop. Recommended fingerprint-hardcoding not implemented. Duplicate-removal unique ID is session-only and reset for each new session.}} }} | ||
= Conformity to Private Browsing Mode = | = Conformity to Private Browsing Mode = | ||