Meeting minutes
First item: Addressing code points and privacy
Simulation results for noise injection
Simulation to help determine value of adding noise and how much noise needs to be added, also compare with existing loading methods (like unicode range)
Simulation assumes that a system for the initial subset will also work for augmentation
Count up pages that match the subset with the additional codepoints
Tested against unicode range convention, no additional noise, additional codepoints with equal weights, and additional codepoints weighted by frequency of occurrence
Even with latin, not adding noise means that a significant (but small) percentage of pages only have ~10 matches
Unweighted noise doesn't help all that much, weighted noise does
Japanese: with no noise a significant number of pages can be uniquely identified. Adding noise definitely improves over doing nothing.
Summary: Adding noise improves the situation, weighed noise works better, different scripts have different noise requirements
Additional findings: Number of added codepoints for a given request should also be randomized. Should change the spec to avoid re-requesting codepoints. Might consider adding a unicode-range in IFT font-faces to allow the client to scope the initial request.
Further testing upcoming.
Malicious content is out of scope for the noise question
Will probably wind up with two recommendations: CJK and non-CJK
Some of the group has reviewed the explainer for TAG, others will review it soon
<chris> We could do with signals from Mozilla - Jonathan Kew, Martin Thomson
Next topic: Range Request and CORS
(The question is what circumstances a preflight request can be avoided when doing multi-range requests
)
Next item: Review remaining issues.
<chris> https://
There was an updated QUERY spec published may 10th but only with minor changes