Imagine that all cross-origin requests are counted against the frame's size. Then the size of the cross-origin resource is trivially leaked by the policy. For example, set a max size of 2KB and then load a cross-origin resource in the frame, did it violate? If yes it's bigger than 2KB. Rinse and repeat to find the exact size.
We'll never be able to leak no information about the size of the cross-origin resource, but ideally we can leak no more information that can already be obtained via other side channels, such as network timing the vast majority of the time.
One way to get there is to cloak the response size by fuzzing the enforced max size. For example, the developer says 100KB but the UA actually enforces 100KB + some secret random value. Information is still leaked this way: the distribution of violations to non-violations tells you how close your resource is to the max size. If most (but not all) samples violate the size policy, then the resource is just under max_size. If very few samples violate the size policy, then the resource is near max_size - max_random_pad. And if it's 50/50, then the resource is somewhere around max_size + average_random_pad_value.
The fuzzy approach is safer the fewer the samples that the attacker can gather. So I propose limiting the total number of size policy violations to some constant value per top-level-page navigation, and after that point all frames with a size-policy on the page are frozen.
I'll write up a less hand-wavy doc with specific values and attach it to this issue.
Imagine that all cross-origin requests are counted against the frame's size. Then the size of the cross-origin resource is trivially leaked by the policy. For example, set a max size of 2KB and then load a cross-origin resource in the frame, did it violate? If yes it's bigger than 2KB. Rinse and repeat to find the exact size.
We'll never be able to leak no information about the size of the cross-origin resource, but ideally we can leak no more information that can already be obtained via other side channels, such as network timing the vast majority of the time.
One way to get there is to cloak the response size by fuzzing the enforced max size. For example, the developer says 100KB but the UA actually enforces 100KB + some secret random value. Information is still leaked this way: the distribution of violations to non-violations tells you how close your resource is to the max size. If most (but not all) samples violate the size policy, then the resource is just under max_size. If very few samples violate the size policy, then the resource is near max_size - max_random_pad. And if it's 50/50, then the resource is somewhere around max_size + average_random_pad_value.
The fuzzy approach is safer the fewer the samples that the attacker can gather. So I propose limiting the total number of size policy violations to some constant value per top-level-page navigation, and after that point all frames with a size-policy on the page are frozen.
I'll write up a less hand-wavy doc with specific values and attach it to this issue.