Dev/sdwdate

An optimization problem. There are conflicting goals.

goal: Saving remote server resources → implementation: use HEAD (implemented)
- (similar to curl --head HEAD)
- is what sdwdate uses.
- Tails discussed using GET instead of HEAD for Tails htpdate but rejected that. ^[archive]
goal: Fingerprinting resistance at remote server level. → implementation: Hide outdated user agent version numbers (not implemented)
- similar to --user-agent curl or even a fake user agent.
- Disadvantage being that this user agent makes use really unique.
- Hiding version number might not help with security either. If a user was running a vulnerable version, an adversary could just try out every exploit independent of version number in user agent. The only solution are timely software upgrades by the user.
- Tails-dev - Faking htpdate user agent worth it? ^[archive]
goal: Maximization of security of sdwdate (implemented) → implementation: use most remote code execution resistant backend (such as curl vs full web browser vs python3 requests) for url_to_unixtime
- Use python3 requests since (implemented in memory safe python3 code) instead of curl (implemented in unsafe memory language C).
goal: Maximization of fingerprinting resistance from viewpoint of remote server → implementation: emulate being a full browser by using selenium or similar. (not implemented)
- Convincingly emulating being a browser is impossible. Changing the user agent is insufficient. The only way of convincingly emulating being a browser is to actually run a browser.
- Running a full browser inside sdwdate however would mess up security. Also very difficult to implement. Running a full browser GUI with an invisible X server and then somehow only exacting HTTP DATE header from the GUI. Also might actually worsen the web fingerprint of sdwdate since sdwdate would fetch and run any tracking (google analytics) script that the remote server has. Then also which browser? Tor Browser + selenium? Keep that browser updated. Seems way too complex to implement.