Including network state is a privacy harm (and maybe not needed) about ift HOT 7 CLOSED

Could you explain further how an (optional) assignment to one of six speed buckets is a significant privacy harm?

(It may be, but it is not evident).

The privacy section already says

It is possible to set a connection_speed parameter, which may allow the Web font server to make better trade-offs in terms of size of update vs. number of requests. This parameter is optional. This might be used as a fingerprinting vector, although the values are bucketed and the same or better information is likely available by other means.

If the authors think this funcitonality would be useful for IFT,

The authors don't "think" this, but have clearly demonstrated it.

Given the significant impact of network speed, particularly for CJK fonts (see for example figure 23 which shows a median improvement of 90% on 4G, 55% on 3G but a median worsening of 220% on 2G, it is clear that ignoring network speed (throughput and latency) will result in significantly worse outcomes.

from ift.

There are a number of privacy issues that come from sharing network information as mentioned. The fingerprinting risk is one, but sharing information about network speed may help an attacker identify if a user is at home, at work or on a cell connection (and there for what times of day the user is at work vs home vs traveling). Sharing information about network speed might also help identify when the user is behind a VPN or anonymizing IP (for example, if the server sees different users connecting from one IP but reporting different network speeds). I'm sure this is not an exhaustive list.

The authors don't "think" this, but have clearly demonstrated it.

I appreciate the authors thing tailoring the size of updates / patches for IFT is useful, but im asking something different. Why can't the logic for the patch size to request be pushed fully in the client, where the client could combine what it knows about the network, along with other information available to the client, to make decisions about the size of patch update to fetch?

from ift.

That's a good point, I believe we should be able to accomplish what we need to by having the client use it's observed network conditions to inform the size of the request they make. Thus we can eliminate the connection speed field from the protocol. I'll create a PR with some proposed modifications.

from ift.

During the last call I believe there was a resolution to remove the field.

from ift.

The above PR removes the connection speed field, so I believe this is solved now.

from ift.

@pes10k so, the "privacy-needs-resolution" tag could be removed on this closed issue?

from ift.

done and done!

from ift.