5 ms·

Reading that bug, it sounds like it was fixed in https://chromium.googlesource.com/chromium/src/+/51cd319fd6aac5ff056fa323d7072b917a7b1a7b https://chromium.goog

by bla2 8y ago

Reading that bug, it sounds like it was fixed in https://chromium.googlesource.com/chromium/src/+/51cd319fd6aac5ff056fa323d7072b917a7b1a7b https://chromium.googlesource.com/chromium/src/+/51cd319fd6a... and the bug status is just incorrect?

kodablah 8y ago
That appears to be for blocking JS (and opt-in only via disabling JS on the site hosting the PDF). I am unfamiliar w/ the internals of PDFs (especially concerning JS invocation), but can you request an image from a third party site without scripting? Also, what if I want the PDF's features to work and I just want to filter web requests like I do every other page out there (e.g. to remove the referrer header)? That web requests in PDF content types are not subject to the same approach as web requests in HTML content types is the problem. Disabling all JS is a blunt instrument akin to telling someone that being able to disable JS for other webpages is as good as more nuanced ad block extension.
- ldarby 8y ago
  You seem to be in favour of some JS running but not other JS - how can software tell the difference? What do you mean by "nuanced ad block extension"? Do they just have a massive blacklist of bad actors to block?
  - kodablah 8y ago
    > You seem to be in favour of some JS running but not other JS No, sorry if I was unclear. What I'm in favor of is my extensions being able to handle/filter web requests on PDFs the same as they do for webpages, irrespective of JS settings. JS is only under discussion here because of the linked commit and I'm saying that's not good enough.
    - ldarby 8y ago
      Ok, anyway I agree with that completely, which is why I disabled PDFs opening automatically and have to click to open (via a standlone reader, not browser plugin). It's basically the same situation as the bad old days of having Flash load automatically and it making whatever requests it wants...
    - sangnoir 8y ago
      However, you probably don't want your Cloud-to-Butt extension reading/modifying requests made by your password-manager extension - which is how I understood the NOFIX comment.
tomvangoethem 8y ago
The bug still seems to be present. You can use the testing on our website: navigate a Chrome browser with an ad-blocking extension to e.g. https://wholeftopenthecookiejar.eu/data/extensions/AdBlock/chrome/3.22.1 https://wholeftopenthecookiejar.eu/data/extensions/AdBlock/c... and click pdf-iframe-submitForm. If the result shows cookies, it has not been fixed.
- ldarby 8y ago
  That's not what the fix was. Disable JS on the site, that should prevent the pdf running JS as well. (although it might prevent the pdf loading in the first place...). As kodablah pointed out, it's not a useful fix. edit to clarify: sorry I thought you thought that fix was trying to fix the bug, but you weren't, so this comment doesn't make much sense.

by bla2 8y ago

kodablah 8y ago

That appears to be for blocking JS (and opt-in only via disabling JS on the site hosting the PDF). I am unfamiliar w/ the internals of PDFs (especially concerning JS invocation), but can you request an image from a third party site without scripting? Also, what if I want the PDF's features to work and I just want to filter web requests like I do every other page out there (e.g. to remove the referrer header)? That web requests in PDF content types are not subject to the same approach as web requests in HTML content types is the problem. Disabling all JS is a blunt instrument akin to telling someone that being able to disable JS for other webpages is as good as more nuanced ad block extension.

ldarby 8y ago
You seem to be in favour of some JS running but not other JS - how can software tell the difference? What do you mean by "nuanced ad block extension"? Do they just have a massive blacklist of bad actors to block?
- kodablah 8y ago
  > You seem to be in favour of some JS running but not other JS No, sorry if I was unclear. What I'm in favor of is my extensions being able to handle/filter web requests on PDFs the same as they do for webpages, irrespective of JS settings. JS is only under discussion here because of the linked commit and I'm saying that's not good enough.
  - ldarby 8y ago
    Ok, anyway I agree with that completely, which is why I disabled PDFs opening automatically and have to click to open (via a standlone reader, not browser plugin). It's basically the same situation as the bad old days of having Flash load automatically and it making whatever requests it wants...
  - sangnoir 8y ago
    However, you probably don't want your Cloud-to-Butt extension reading/modifying requests made by your password-manager extension - which is how I understood the NOFIX comment.

tomvangoethem 8y ago

The bug still seems to be present. You can use the testing on our website: navigate a Chrome browser with an ad-blocking extension to e.g. https://wholeftopenthecookiejar.eu/data/extensions/AdBlock/chrome/3.22.1 https://wholeftopenthecookiejar.eu/data/extensions/AdBlock/c... and click pdf-iframe-submitForm. If the result shows cookies, it has not been fixed.

ldarby 8y ago
That's not what the fix was. Disable JS on the site, that should prevent the pdf running JS as well. (although it might prevent the pdf loading in the first place...). As kodablah pointed out, it's not a useful fix. edit to clarify: sorry I thought you thought that fix was trying to fix the bug, but you weren't, so this comment doesn't make much sense.