Update CSS filter #998
Update CSS filter #998
Conversation
There was a problem hiding this comment.
Looks good to me.
Besides: you don’t have to make the PRs this small — just a balance that’s easy to review. I can review 5-6 CSS properties in one sitting, the PR just shouldn’t take more than 10 minutes to review (if possible! If that’s not possible, because the change is intrinsically hard, that’s OK!) and when it’s reviewed the changes should only be to address review comments, avoiding to add new stuff to review (that could spark more review comments). Basically making it easy to progress to a state where the PR can be approved and later merged.
|
Merged — thank you! |
|
@torusrxxx if you want to do a directed search for missing features, you could see what’s missing for the defcon page to render correctly. If you have pyFreenet3 installed ( |
|
I know a lot of important missing features, but most of them require significant changes to how the filter works. First one is media query. A lot of media types were deprecated, only Next one is CSS variables. The use of CSS variables has become widespread, especially for dark mode support. But CSS variables are hard to filter, because it can be of any type with any value and defined anywhere. Since we filter all CSS files, it's still possible to ensure all CSS variables does not contain external links. However it also means almost all of our filter code becomes useless. Currently A third one is font awesome. A lot of places use these nice icons. This requires filters for font files. The threat model for font files is yet unknown. There are many known exploits targeting color profiles, fonts like this one for Windows that are already patched, but it's still possible for the user to run an unpatched operating system. It's not possible to look for every exploits of every operating system. So, either we have to ask users to use patched operating systems, or we can't support font awesome. The same is also true for WebP, where we have a known exploit for lossless encoding that is already patched, but we still block all WebP images with lossless encoding because we aren't sure whether the user patch the browser and operating system properly. |
|
Variables may be hard, yes. For font awesome (and other fonts) the issue is clear, though: these are dangerous, because they can be executables doing anything. Where’s the harm from continuing to support many media types? We have pretty old sites. Media queries for mobile features look orthogonal to that check, so they can be added. However they have to be sanitized. Look at how Tor Browser sets fixed sizes to the displayed area. This is necessary to prevent individualized tracking — and the same is true in Freenet: we can’t have pixel-perfect media queries, because these would enable tracking. |
|
I don't think fonts are that dangerous. Fonts can contain executable but certainly they cannot do anything they want, for example sending web requests. Otherwise there will be a patch to fix it. Fonts are optional in web pages (the font awesome icons will be missing), but they are essential in PDF. PDF files will be broken if the embedded fonts are removed. There are many libraries to read and write PDF, I think it will be possible to filter PDF just like HTML one day. |
|
The risk is that such a patch may be too late: if they leak privacy for some time, the damage is done and cannot be repaired. That’s why we usually err on the side of privacy. We’re not perfect, but we try to avoid risks that could be higher than the reward. That said: limited PDF support may be possible (most tools do not support it completely), but it’s a huge task that needs careful checking. |
|
Another off topic question: Is there any plan or patch to support SVG? If there is, I would like to see whether I can help on that. |
Add dominant-baseline