Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Monday October 23 2017, @09:09AM   Printer-friendly
from the Digital-Arms-Race dept.

Submitted via IRC for TheMightyBuzzard

The popular content blocking extension uBlock Origin blocks CSP reporting on websites that make use of it if it injects neutered scripts.

CSP, Content Security Policy, can be used by web developers to whitelist code that is allowed to run on web properties. The idea behind the feature is to prevent attackers from injecting JavaScript on websites protected by CSP.

CSP reports any attempt of interfering with the site's policies in regards to scripts to the webmaster. This happens when users connect to the site, and is used by webmasters to analyze and resolve the detected issues.

[...] Raymond Hill, the developer of uBlock Origin, replied stating that this was not a bug but by design. The extension blocks the sending of CSP reports if it injects a neutered Google Analytics script.

Source: https://www.ghacks.net/2017/10/19/ublock-criticized-for-blocking-csp/


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by FakeBeldin on Monday October 23 2017, @12:02PM (6 children)

    by FakeBeldin (3360) on Monday October 23 2017, @12:02PM (#586291) Journal

    uBlock is for user security, CSP is for the website's own security. Big surprise that they don't always coincide.

    If you as a site owner want more lax uBlock settings for your site, feel free to put up a banner. Just like those "hey you're blocking our ads" banner. I'm sure it'll work out well - every visitor who has uBlock origin and cares about your site knowing when your site messes up, will surely expect to have to relax their settings.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 4, Informative) by takyon on Monday October 23 2017, @12:12PM (1 child)

    by takyon (881) <reversethis-{gro ... s} {ta} {noykat}> on Monday October 23 2017, @12:12PM (#586294) Journal

    Actually, one or more of my extensions (probably Adblock) seems to detect some of those banners and block them (more accurately, it asks me if I want to block them, and I just say no). I think it might be based on a curated list, idk.

    Still... yup. Blocking Google Analytics is scriptblocking 101.

    --
    [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
  • (Score: 3, Informative) by FakeBeldin on Monday October 23 2017, @12:31PM (3 children)

    by FakeBeldin (3360) on Monday October 23 2017, @12:31PM (#586299) Journal

    uBlock is for user security, CSP is for the website's own security.

    Case in point:
    The security feature enabled by CSP reporting (i.e.: fixing the site) isn't dependent on one user. It's dependent on at least one of the users doing it, not on all.
    On the other hand, the security feature of uBlock origin is to block. So whenever uBlock fails to block, it fails.

    Given that uBlock's market penetration is ridiculously low, the chance that the only visitors to your site who would trigger CSP reporting are uBlock users is infinitesimal. I.e., this is an absolute non-issue.

    • (Score: 2) by Pino P on Monday October 23 2017, @03:05PM (2 children)

      by Pino P (4721) on Monday October 23 2017, @03:05PM (#586357) Journal

      The security feature enabled by CSP reporting (i.e.: fixing the site) isn't dependent on one user. It's dependent on at least one of the users doing it, not on all.

      Testing using the CSPRO header depends on at least one user viewing each individual document. But a lot of sites are so big that one user rarely if ever sees the whole thing, resulting in incomplete test coverage. So yes, you may need multiple users to hit different subsets of the documents on a site.

      Given that uBlock's market penetration is ridiculously low, the chance that the only visitors to your site who would trigger CSP reporting are uBlock users is infinitesimal. I.e., this is an absolute non-issue.

      If the majority of your users end up using other ad or script blockers that have the same bug as UBO, that could cause poor coverage as well.

      • (Score: 0) by Anonymous Coward on Monday October 23 2017, @05:49PM

        by Anonymous Coward on Monday October 23 2017, @05:49PM (#586449)

        So yes, you may need multiple users to hit different subsets of the documents on a site.

        Multiple!= all. All non-UBO users should be sufficient.

        If the majority of your users end up using other ad or script blockers that have the same bug as UBO, that could cause poor coverage as well.

        It's not a bug. It's a properly implemented security and privacy feature.

      • (Score: 0) by Anonymous Coward on Monday October 23 2017, @06:25PM

        by Anonymous Coward on Monday October 23 2017, @06:25PM (#586473)

        But a lot of sites are so big that one user rarely if ever sees the whole thing, resulting in incomplete test coverage.

        Only a few hackers in the world are interested in pwning that just one person who happens to be viewing a particular document on a website that nobody else in the world is interested in.

        And if that person is running ublock I think he would want everything blocked, including reports.

        If that person isn't running ublock and got pwned I don't think he cares that the website got a CSP violation report or not.

        If that person wasn't pwned but his browser noticed the attempted CSP violation, I think that person would want the browser to notify him and stop running anything else from that site. His browser sending reports and more data to that site is not what he would want. If he wishes he can go tell the site himself, but given that he's the only one in the world being targeted I think he has more important things to do (like maybe leave the country ;) ).

        If that person was a security researcher testing the site, he should be getting the report from the browser side (e.g. click on "violation details"). Not from the browser telling the server side "guess what my user nearly got pwned". That's how it would work if the browser makers and standards bodies were actually interested in security and not more insidious ways for tracking people.