Maybe its enough if users allow autosyncing with ntp once on the host and then manually alter it a little before turning this off on the host?NTP on the host isn't safe, since it's unauthenticated. And it's unpractical to make it safe (for reasons listed on the Dev/TimeSync page).
We’re defending against two different adversary capabilities here. Active attacks (disrupting host’s NTP) and passive eavesdropping.
The former, active attacks are more difficult to defeat. When the host clock is off by for example ~35 minutes, because of an adversary capable to trick NTP, then you’re always the one “who’s clock is off by ~35 minutes”. Since sdwdate fixes the time to something different from the host and since the result is non-predictable, as far I understand it, this should now get defeated by sdwdate.
Turning it off prevents active attacks in the future, and as long as the host clock is close to ntp time then I don't think users will stand out.Active attacks: see ~35 minutes example above.
This works out because, even if an adversary has already been doing global attacks during the event of a user's first sync, they (the adversary) would have done so subtly and not changed the time so much as to not draw attention.I guess most users won't report if their clock is too much off. We trained them pretty good to ignore the clock by using UTC timezone and having no first time wizard asking for their correct time zone.
Manually adjustment of a few seconds forwards or backwards is enough to muddy the watersIf it includes milliseconds, yes, but I haven't seen anyone before messing with milliseconds. I am glad this is now automated.