Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide guidelines for mitigation algorithms #3

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Provide guidelines for mitigation algorithms #3

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
7aa1f87
Provide guidelines for mitigation algorithms
arskama Oct 30, 2023
d8be602
fix to non-normative section
arskama Oct 31, 2023
1871894
fix milliseconds
arskama Oct 31, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 24 additions & 3 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -854,7 +854,7 @@ <h3>Supporting algorithms</h3>
<ul>
<li>
set |observer|.{{PressureObserver/[[ObservationWindow]]}} to an [=implementation-defined=] randomized integer value in
milliseconds within an [=implementation-defined=] range, e.g., random between 300000 and 600000 (5 and 10 minutes).
milliseconds within an [=implementation-defined=] range.
</li>
<li>
set |observer|.{{PressureObserver/[[MaxChangesThreshold]]}} to an [=implementation-defined=] randomized integer
Expand All @@ -870,6 +870,20 @@ <h3>Supporting algorithms</h3>
</ul>
Run the [=reset observation window=] steps and start a timer to re-run the steps when the observer.{{PressureObserver/[[ObservationWindow]]}}
time has passed, using different randomized values.
<aside class="note">
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure that is really a note...

Implementers are advised to use:
<ul>
<li>
a range in milliseconds between 300000 and 600000 for |observer|.{{PressureObserver/[[ObservationWindow]]}}.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a range between ... in milliseconds ?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a range between 300.000 milliseconds (5 minutes) and 600.000 milliseconds (10 minutes) for |observer|.{{PressureObserver/[[ObservationWindow]]}}.

</li>
<li>
a range in between 50 and 100 changes for |observer|.{{PressureObserver/[[MaxChangesThreshold]]}}.
</li>
<li>
a range in milliseconds between 5000 and 10000 for |observer|.{{PressureObserver/[[PenaltyDuration]]}}.
</li>
</ul>
</aside>
</p>
<p>
<aside class="note">
Expand Down Expand Up @@ -1363,14 +1377,21 @@ <h4>Break calibration</h4>
at runtime when this mitigation is running continuously. Any attempts to recalibrate
will similarly be mitigated against.
</p>
<div class="note">
<aside class="note">
This mitigation, if applied too often, can deteriorate the pressure state detection reliability.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

deteriorate is a very strong word, also why is this more or a problem when done often? Not a fan of the "applied"

Therefore it is targeted for longer calibration attack processes.
Implementers are advised to apply the mitigation to a randomized time value in milliseconds
within a range between 120000 and 240000 (2 and 4 minutes).
Faster calibration processes can be mitigated by [=rate obfuscation=] mitigation.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it is clear what "faster calibration processes" refers to.

When can you calibrate fast? and when can you calibrate slowly?

You calibrate when you have focus and we need to make sure to somewhat invalidate that calibration. We dont even have to do it between a special time window, we could even do it whenever another page gains indirect focus and starts receiving telemetry data. - that should work just fine now that I am thinking about it - or just use slighly different thresholds per origin

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Faster calibration processes, I m thinking of something like you are doing with the demo...
We chnage the state very fast (5-10s) and we are trying to figure out in a short time period what state belongs to what load.
slower I was thinking that you are one in a while trying to increase the work load... every minute...
So the frequency of load change would be really low.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but I think it is very confusing wording because they reader doesn't know about the demo etc

</aside>
<aside class="note">
Modern browsers throttle background tabs using [=implementation-defined=]
heuristics in order to reduce resource usage. For example, after a period of
no user interaction a background tab can be throttled that will influence
the global pressure state of the system. This built-in feature of modern
browsers further improves the effectiveness of the break calibration
mitigation.
</div>
</aside>
</section>
<section>
<h4>Same-origin restriction</h4>
Expand Down