privacybadger
privacybadger copied to clipboard
EFForg
Help users avoid breaking the Web for themselves
Now that we fixed submitting user-set sliders with error reports in #2001, we regularly get error reports where the page is broken because of a domain the user manually told Privacy Badger to block. One such domain is ajax.googleapis.com, a CDN used to deliver popular JavaScript libraries.
We want Privacy Badger to be an install-and-forget, no-configuration necessary tool. We still prominently show sliders in the popup, however. Regardless of what we say above the sliders, users see them and think, "aha! let's block everything, better safe than sorry."
We are going to want to rework the popup to make it more helpful to more people. A list of domains is TMI for most users. Redesigning the popup is complicated though. Are there any simple tweaks we could make to help users avoid breaking the Web for themselves?
We could see if the user has any user-blocked domains on the page they clicked to file a broken site report on. We could then show a message warning them that the page may be broken because of their customizations.
We could show a warning icon next to (or otherwise highlight) yellowlisted domains the user marked for blocking. The yellowlist here would act as proxy for a list of domains known to break websites (the yellowlist is probably good enough to start with).
Any other ideas?
This issue will probably take several related enhancements to resolve. I suggest opening a separate PR for each distinct improvement.
Some example reports:
Site-specific CDNs:
fqdn: www.linkedin.com
userblock: static.licdn.com,media.licdn.com,www.google-analytics.com,www.google.com,d1j5o6e2vipffp.cloudfront.net
message: everything. Linkedin only showed a few random buttons in the browser and nothing else
fqdn: bandcamp.com
userblock: s4.bcbits.com
message: CSS-Files sems blocked. Website not in regular Layout � simple HTML-Look
fqdn: www.mlb.com
userblock: www.mlbstatic.com,prod-gameday.mlbstatic.com,cdn.krxd.net,www.googletagmanager.com
message: I blocked everything and now it won't load ... can't undo it now ..
Content CDNs:
fqdn: www.hulu.com
block: 20554339p.rfihub.com,googleads.g.doubleclick.net
userblock: a248.e.akamai.net,service.maxymiser.net,tags.tiqcdn.com,www.google-analytics.com,connect.facebook.net,platform.twitter.com,assetshuluimcom-a.akamaihd.net,c.betrad.com,beacon.scorecardresearch.com,stags.bluekai.com,cdn.getambassador.com,ibhuluimcom-a.akamaihd.net,http-e-darwin.hulustream.com
usercookieblock: NULL
message: video's will not play with privacy badger on.
url: http://www.mountvernon.org/the-estate-gardens/the-mansion/the-new-room/
userblock: s3.amazonaws.com,www.google-analytics.com,www.googleadservices.com,connect.facebook.net
message: Images won't load
Shopify:
url: https://bombas.com/collections/womens-socks#main-content
userblock: cdn.shopify.com,cdn.optimizely.com,ajax.googleapis.com,v.shopify.com,usermatch.krxd.net,bat.bing.com,s.yimg.com,tag.bounceexchange.com,cdn.taboola.com,analytics.twitter.com
usercookieblock: s.amazon-adsystem.com
message: can't load the page entirely
fqdn: www.the-citizenry.com
userblock: cdn.shopify.com,v.shopify.com,www.googleadservices.com,bat.bing.com,ajax.googleapis.com
message: can't see site without turning off privacy badger
JavaScript CDNs:
fqdn: www.yelp.com
userblock: ajax.googleapis.com,www.google-analytics.com,www.google.com,connect.facebook.net,secure.quantserve.com,fonts.googleapis.com,fonts.gstatic.com
message: Filter options don't work when privacy badger is enabled
fqdn: www.dustinhome.se
userblock: ajax.googleapis.com,tracker.bannerflow.com
message: page/pictures wouldn't load
url: https://e.vnexpress.net/news/video/the-tale-of-saigon-s-thu-thiem-peninsula-3746147.html
userblock: ajax.googleapis.com,www.googletagservices.com,www.google-analytics.com,platform.twitter.com,syndication.twitter.com
message: content BLOCKED
url: http://www.kicker.de/news/fussball/bundesliga/startseite.html
userblock: imasdk.googleapis.com,cdn.jsdelivr.net,script.ioam.de,cdn.interactivemedia.net,dyn.emetriq.de,tag.aticdn.net,www.googleadservices.com,im.banner.t-online.de,s3.amazonaws.com,homad-global-configs-eu-fra.schneevonmorgen.com.s3.amazonaws.com,hgc-cf-cache-1.svonm.com,www.youtube.com,www.hotdogsandads.com,www.tisoomi-services.com
Top user-blocked domains in error reports so far:
+-------+-------------------------------------+
| count | userblocked_fqdn |
+-------+-------------------------------------+
| 879 | www.google-analytics.com |
| 596 | connect.facebook.net |
| 545 | www.facebook.com |
| 415 | www.google.com |
| 394 | www.googletagmanager.com |
| 352 | fonts.googleapis.com |
| 301 | www.googletagservices.com |
| 282 | ajax.googleapis.com |
| 208 | platform.twitter.com |
| 178 | staticxx.facebook.com |
| 151 | fonts.gstatic.com |
| 144 | www.googleadservices.com |
| 143 | googleads.g.doubleclick.net |
| 128 | cdnjs.cloudflare.com |
| 128 | sb.scorecardresearch.com |
| 121 | pagead2.googlesyndication.com |
| 114 | www.gstatic.com |
| 114 | apis.google.com |
| 104 | www.youtube.com |
| 94 | securepubads.g.doubleclick.net |
| 93 | ssl.google-analytics.com |
| 88 | c.amazon-adsystem.com |
| 71 | adservice.google.com |
| 68 | s3.amazonaws.com |
| 67 | bat.bing.com |
| 64 | js-agent.newrelic.com |
| 60 | stats.g.doubleclick.net |
| 54 | maxcdn.bootstrapcdn.com |
| 51 | static.doubleclick.net |
| 50 | cdn.shopify.com |
| 45 | s7.addthis.com |
| 45 | v.shopify.com |
| 45 | syndication.twitter.com |
| 45 | ad.doubleclick.net |
| 44 | static.chartbeat.com |
| 44 | static.criteo.net |
| 43 | tags.tiqcdn.com |
| 42 | ib.adnxs.com |
| 39 | cdn.krxd.net |
| 39 | dpm.demdex.net |
| 38 | assets.adobedtm.com |
| 37 | cdn.optimizely.com |
| 35 | imasdk.googleapis.com |
| 33 | bam.nr-data.net |
| 32 | code.jquery.com |
| 32 | cdns.gigya.com |
| 30 | script.ioam.de |
| 29 | js-sec.indexww.com |
| 29 | accounts.google.com |
| 28 | cdn.taboola.com |
| 28 | mc.yandex.ru |
| 27 | widgets.outbrain.com |
| 26 | pubads.g.doubleclick.net |
| 23 | secure.quantserve.com |
| 21 | cdn3.optimizely.com |
| 21 | static.ads-twitter.com |
| 21 | secure-us.imrworldwide.com |
| 21 | nexus.ensighten.com |
| 20 | use.typekit.net |
| 20 | graph.facebook.com |
| 20 | consent.cmp.oath.com |
| 19 | s.yimg.com |
| 19 | b.scorecardresearch.com |
| 18 | s.pinimg.com |
| 17 | jsc.mgid.com |
| 17 | s.ytimg.com |
| 17 | maps.googleapis.com |
| 17 | tpc.googlesyndication.com |
| 17 | secure.adnxs.com |
| 17 | cm.g.doubleclick.net |
| 17 | acdn.adnxs.com |
| 16 | analytics.twitter.com |
| 16 | counter.yadro.ru |
| 16 | s0.2mdn.net |
| 16 | static.hotjar.com |
| 15 | tags.crwdcntrl.net |
| 15 | ssl.gstatic.com |
| 14 | stats.wp.com |
| 14 | www.sdad.guru |
| 13 | static.licdn.com |
| 13 | fastlane.rubiconproject.com |
| 13 | z.moatads.com |
| 13 | cse.google.com |
| 13 | www.tns-counter.ru |
| 13 | i.ytimg.com |
| 12 | pixel.advertising.com |
| 12 | s0.wp.com |
| 12 | ads.rubiconproject.com |
| 12 | translate.google.com |
| 12 | d1z2jf7jlzjs58.cloudfront.net |
| 12 | js.ui-portal.de |
| 12 | secure-dcr.imrworldwide.com |
| 11 | tags.bluekai.com |
| 11 | www.summerhamster.com |
| 11 | bcp.crwdcntrl.net |
| 11 | c.go-mpulse.net |
| 10 | logx.optimizely.com |
| 10 | js.stripe.com |
| 10 | pixel.quantserve.com |
| 10 | whos.amung.us |
| 10 | assets.pinterest.com |
| 10 | edge.quantserve.com |
| 10 | i.ebayimg.com |
| 10 | ad.crwdcntrl.net |
| 10 | cdn.onesignal.com |
| 10 | as-sec.casalemedia.com |
| 10 | t.co |
| 10 | cdn.digitru.st |
...
About a fifth of all user reports contain one or more user-blocked domains. So that's the ceiling on self-inflicted breakage.
If you look at the top user-blocked domains (above), we do want quite a few of them blocked while blocking certain other domains is likely to break page contents. For example, while reports where the user chose to block ajax.googleapis.com, cdnjs.cloudflare.com or maxcdn.bootstrapcdn.com make up a much smaller proportion of all reports, it still comes out to hundreds of reports per month.
I have a suggestion for stopping people from clicking on sliders randomly in an attempt to solve their problem- perhaps they could be categorized by something a non-developer might recognize as friendly? Privacy Badger the software clearly already has code that knows that something is a font or a non-tracking Javascript library. A developer would also likely make the right eyeball call by url ID alone, but a non-developer wouldn't. GUI header categories that show up in the existing popup on the same header level as "The domains below don't appear to be tracking you", but labeled "Fonts", "Extra Site Content", "Trackers", and "Unknown" seem like they might go a long way, but still provide transparency (and block-ability if totally necessary) As an example, the Ghostery plugin does this categorization for tracking-type stuff already- it separates out Ads from Site Analytics, for example. Does doing the categorization on the benign stuff seems reasonable for Privacy Badger to do?
If this is useful I can build and submit a PR for it.
Reworking how we display domains to the user is not a bad idea! As I wrote above, a list of raw domains is "TMI" for most people. My concern has to do with how much work reworking the UI entails as compared to other tweaks we could try in order to help people avoid breaking the Web for themselves. Remember that ultimately the list of domains is a power user feature, not meant for the majority of Privacy Badger users. Splitting the list into categories should help, but so should hiding the sliders by default, for example. We should also consider the users who already chose to block all these known-to-break-stuff domains.
What about only showing the domains that were blocked by user options?
Ok so we could:
- Add an expand/collapse accordion for the sliders rather than having the scroll table take up all the screen space it does now, which visually emphasizes it as import and something people should regularly look at....
- ... but still show the user overrides that Privacy Badger would normally have placed on the 'The domains below don't appear to be tracking you' list.
- Add a category of some kind to the list item for each url that would caution the user to think twice before blocking content (or help them understand why not to do it)
- Add a contact link of some kind for reporting wrong categorizations that would let power users improve privacy badger?
I like these ideas! I suggest breaking them down into as many independent improvements as possible. We don't need to figure out how to hide sliders and do domain categorization at the same time. By the way, between these two, slider hiding seems like a stronger mix of impact/implementation difficulty.
Thoughts on hiding sliders:
- Sliders should be hidden by default.
- We should show something useful/informative/fun in their place instead. You can review what other privacy tools show for some ideas. It would be great though to showcase what makes Privacy Badger different (#1675). Ideas very much welcome!
- Slider hiding can be a toggle on the options page, to reduce what needs to change in the popup. Users who want to see the sliders for whatever reason can restore them by visiting options. We could show a tip to this effect to existing users the first time they open the popup. Having the toggle live in options becomes less attractive if users often want to see the sliders on some pages but not others though ...
- Good idea to always show any customized sliders!
I don't think the current UI (a) shows whether the slider has been manually adjusted or (b) gives a way to reset it to Privacy Badger's recommendation, which seems important. Imagine a user had manually set example.com to red. Prompted by a hint from a UI like what @troy-lamerton illustrated, she realizes the change might have broken something wants to restore it. Currently, she doesn't know if Privacy Badger had originally recommended yellow or green.
-
re. domains that would be better not to block: what matters is that doing the wrong thing needs to become more difficult. For instance, we can make it require multiple clicks. So, I agree on a category of domains that PB considers better not to block - separate from the other domains, still viewable but more hidden - requiring someone to click on a link that warns of "advanced functionality" or similar.
-
re. domains that PB blocks I would make it more explicit that PB autonomously detect what should be blocked and blocks it. Perhaps by simply writing it explicitly "PB thought it best to block this <>" in addition to labeling differently those domains that the user manually decided to block, as per @troy-lamerton's suggestion
I've worked on some mockups based on this issue and some usage for a while on my end.
I've read a number of comments about reducing the obviousness of the domains. I think this is a good way to go, requiring users to take an additional step to engage with advanced settings.
I've also been working on an overhaul of the UI to address the look and feel.
I'd like to submit a PR if others think this will help address some of the UX issues above.
I've not done any work on some other comments like categorizing, returning control of trackers etc.
@cwattrus, these are beautiful!! @ghostwords, what do you think of this? Is this the direction you imagined? I'll reach out to our engineering & design team here to see what they think, and get back once they have feedback. Thank you for putting so much time and thought into this!
Displaying a warning after a user blocks a domain that is known to break some pages might help because users will be aware of the fact that they probably broke it by blocking the domain.
@cwattrus Thank you for the mockup! I think this is on the right track. I'm on leave with limited availability; sorry I can't provide more detailed feedback at this time ... Here are some first thoughts though:
Can we break up the changes into smaller pieces/several stages? The mockup changes (rearranges) a bunch of functionality not all of which is slider-related ... What's the smallest set of changes we can make to address the biggest problem in this issue? We could follow up this first stage with further improvements (such as design fixes). I just think breaking up and minimizing the changesets will maximize our chances of shipping fixes.
Perhaps we should open a new issue (or PR, but I don't advise writing code just yet) to continue discussing your proposal. Thanks again!
@ghostwords, thanks for the response.
I'm happy to do whatever is easiest for you. I do think it's best to get started with code. It's easy to get stuck discussing intangibles when it comes to UX. I'll see if I can break out a small impactful change and make a PR.
To get familiar with the code and concepts I've worked on reworking the UI on the options pages and will submit a PR for that in the week.
I opened #2359 to hide the "domains below don't appear to be tracking you" section in the popup by default for new Privacy Badger users. This should help new users break less of their Web experience by accident.
A problem with blocking all *.cloudfront.net domains by default is that there maybe be a handful used for tracking purposes the user is willing to tolerate.
One kind of troublesome cloudfront.net fully qualified domain is of the form xxxxxxxxxxxxxx.cloudfront.net where each "x" represents a lower-case letter [a..z] or a decimal digit [0..9] and the 14 character string is randomly generated per logon attempt when the Web site does not find at least one particular such URLs beginning with a random string that it already associates with a specific user logging onto said site.
In PrivacyBadger, there are two URLs beginning with 14 character strings as described above, for example "ab1234567890cd.cloudfront.net" and "ij0102030405mn.cloudfront.net" that I need in order to log onto an online game and a forum related to that game which I have been playing for several years.
Somewhere in figuring out how these thrid-level domains with randomly generated third-level names work, I learned to change the bar setting in PrivacyBadger to yellow for each cloudfront.net URL in the pair that is associated with the game and the related forum.
But, that somehow resulted in there being no default setting for the second-level domain, "cloudfront.net". I have been told that cloudfront.net is yellow-listed in PrivacyBadger by default and took the time to verify this on github.org . There is one thing I CANNOT seem to get an authoritative answer about:
How do I keep a small number of those random third-level domains with [random characters].cloudfront.net URLs that I wish to (partially) allow (set to green or yellow) and have cloudfront.net set to red (black-isted) by default so largre numbers of unwanted third-level cloudfront.net domains do not get marked red and added to the list of user-controlled domains on my computer?
I became aware of this problem when I got tired of seeing tracking cookies with cloudfront.net URLs that were not placed on my machine for my benefit. Three or four sites I used to use often, including the ones related to the game I mentioned above had sets of one or more RanGen third-level domain names that I marked as yellow so I would run into hassles logging into those sites.
It would be wonderful if I could add back just the 2nd-level domain "cloudfront.net" to PrivacyNadger and set it to red so that all *.cloudfront.net fully qualified domains would be rejected and not added to a redlist which would grow to gargantuan size if each rejected domain was added to the redlist.
I have several tools I use deal with cloudfront.net and other domains I consider bad (evil?) in most cases but may want to allow to some extent, including Ghostery, NoScript, uBlock Origin, uMatrix, uBO-scope, as well as PrivacyBadger.
If PrivacyBadger was not from Electronic Frontier Foundation, an organization I have liked since news of its founding in 1990 by three people I knew of who were rather famous in their own fields of endeavor, I might never have tried it out, but now that I know it is very good at what it is designed to do I use it it conjunction with NoScript and the first two of the three "u[Whatever]" programs written by Raymond Hill.
Raymond is a skilled programmer I am sure I could learn new and useful things from and he shares my attitude block (tracking) cookie by default and use the most simple means possible to allow the few remaining to get through with just enough permissions to allow their host program function.
The feature needed to allow a small number of cloudfront.net URLs with randomize 14-character first parts to be yellow or even green-listed while having cloudfront.net and all other third-level domains stemming from it red-listed by default and not saved individually by PrivacyBadger once a session with the site that uses them ends seems to be something that would enhance PrivacyBadger for many (most?) users and not cause any significant degradation in its performance nor make it noticeably more complex for people who have no need or desire to use such a feature.
In closing, I guess I am frustrated at not being able to have a great utility such as PrivacyBadger set up with documented hooks so a programmer could fork off of it in a very specific, limited manner to add some features it does not yet have.
If someone who knows their way around the PrivacyBadger project would be kind enough to get assigned to the modification I propose and also assign me, I would love to help make it happen.
Regards, Mark Gibson
P.S. My landlord, a Harvard educated corporate attorney, frequently chided me to keep brevity in mind when I write to someone else, especially him. He has been a wonderful landlord so far and I know he is right about my lengthy expositions -- but coronavirus-induced social isolated tend to make me much more verbose than usual. I hope I cannot stick to that excuse for many more weeks...
We have to remember that it should be as simple as possible, without removing the more complex functionality that advanced users desire. Far too often I see older family members unintentionally breaking their web experience because of privacy badger or other plugins. @cwattrus mockups are great and I think they are a huge step in the right direction. BUT I showed the improved mockups to someone non technical and their immediate piece of feedback was "what does the orange cookie looking middle icon do?" They got red and green, but what is Yellow, perhaps it could be visualised better?
Hi @pseacrest, take a look at the various PRs shown above your comment to see the progress we've been making.
The biggest recent change was collapsing the slider list by default as of Privacy Badger version 2021.6.8. The sliders aren't really meant to be used by most users. What's important is a summary of what happened on the page and the "Disable for this site" button.
Our next step is to re-evaluate how big of a problem this remains by reviewing user error report statistics.
Let me know if you have feedback regarding our latest UI or thoughts regarding what else we could do to help users avoid inadvertently breaking the Web for themselves.