You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
DAP-13 has a few task parameters which define the "valid" time window in which client reports are accepted:
task_start: The time from which the Clients will start uploading reports to a task. Aggregators MUST reject reports with timestamps earlier than task_start.
task_duration: The duration of a task. The task is considered completed after the end time task_start + task_duration. Aggregators MUST reject reports that have timestamps later than the end time, and MAY choose to opt out of the task if task_duration is too long.
(this has been refactored somewhat over time, but previous DAP drafts had similar parameters)
Janus has never implemented this check for the Helper aggregation codepath. We should consider doing so. Despite the MUST, I think this isn't mandatory because:
A Leader aggregator which follows the DAP protocol will never send a report which should be denied by this check, so we are spec-compliant as far as can be observed by correct protocol interaction.
A malicious Leader aggregator cannot bypass the privacy/robustness properties of DAP due to the lack of this check, so we are OK in practice.
Still, it would be easy to implement this, and it might be better to protect ourselves from pointlessly aggregating "bad" reports from a misconfigured/buggy Leader.
The text was updated successfully, but these errors were encountered:
DAP-13 has a few task parameters which define the "valid" time window in which client reports are accepted:
(this has been refactored somewhat over time, but previous DAP drafts had similar parameters)
Janus has never implemented this check for the Helper aggregation codepath. We should consider doing so. Despite the MUST, I think this isn't mandatory because:
Still, it would be easy to implement this, and it might be better to protect ourselves from pointlessly aggregating "bad" reports from a misconfigured/buggy Leader.
The text was updated successfully, but these errors were encountered: