Previously I was able to enable/disable Blok using private browsing windows- as of today, both Nightly and Dev Edition are refreshing the page when you click on the disable/enable link but the status is not updating.

Just spotted this, and thought adding a "close" button may be nice, if user's just want to dismiss the Block header completely without doing anything.

Re: https://github.com/mozilla/blok#run-it

Run it

1. Go to about:config and set xpinstall.signatures.required to false
2. Download the .xpi
3. In Firefox, "Open File" and select the .xpi

When the add-on blocks tracker requests, you will see a Blok notification bar
like the screenshot.

Currently we're linking to a hard coded XPI (Spoiler alert: The link 404s anyways), but we should probably either just link to the /web-ext-artifacts/ directory and let the user grab the latest signed XPI from that page, or we should always just make a copy of the latest signed XPI and rename it to "latest.xpi" and then link to that add-on. We'll want a static filename to point to for Test Pilot anyways, as we won't want to constantly be going into the Test Pilot admin and pointing to the latest versioned XPI filename. We'll also need to think about hosting the update.rdf, if we don't already have that system in place.

See https://developers.google.com/safe-browsing/v4/urls-hashing#canonicalization

• Remove all leading and trailing dots
• Replace consecutive dots with a single dot
• If the hostname can be parsed as an IP address, normalize it to 4 dot-separated decimal values. The client should handle any legal IP-address encoding, including octal, hex ...
  • and fewer than four components
• Lowercase the whole string

• #1: Only block 3rd-party requests if the request domain isn't in the same "group" as the origin domain
  • #23
• #16: Do not block iframe requests to one of its ancestors' top-level domains
  • #18

Unzipping the /web-ext-artifacts/blok-0.1.7-fx.xpi, there are a few interesting results:

$ unzip blok-0.1.7-fx.xpi
$ tree

├── META-INF/
│   ├── manifest.mf
│   ├── mozilla.rsa
│   └── mozilla.sf
├── README.md
├── coverage/ (EMPTY)
├── css/
│   ├── contentscript.css
│   ├── feedback.css
│   ├── foundation.min.css
│   └── toolbar.css
├── disconnect-blocklist.json
├── disconnect-entitylist.json
├── feedback.html
├── icons/ (EMPTY)
├── img /
│   ├── banner.png
│   ├── blok.png
│   ├── screenshot.png
│   ├── tracking-protection-16.svg
│   └── tracking-protection-disabled-16.svg
├── js/
│   ├── background.bundle.js
│   ├── background.js
│   ├── canonicalize.js
│   ├── contentscript.js
│   ├── feedback.js
│   ├── lists.js
│   ├── log.js
│   └── toolbar.js
├── manifest.json
├── package.json
├── tests/
│   ├── blocklist-fixture.json
│   ├── test-canonicalize.js
│   └── test-lists.js
├── toolbar.html
└── web-ext-artifacts/ (EMPTY)

8 directories, 30 files

$ ls -lh

drwxr-xr-x   5 pdehaan  staff   170B Jul 28 16:28 META-INF
-rw-r--r--   1 pdehaan  staff   1.6K Jul 27 14:48 README.md
drwxr-xr-x   2 pdehaan  staff    68B Jul 27 14:48 coverage/
drwxr-xr-x   6 pdehaan  staff   204B Jul 27 14:48 css/
-rw-r--r--   1 pdehaan  staff   260K Jul 27 14:48 disconnect-blocklist.json
-rw-r--r--   1 pdehaan  staff   196K Jul 27 14:48 disconnect-entitylist.json
-rw-r--r--   1 pdehaan  staff   1.7K Jul 27 14:48 feedback.html
drwxr-xr-x   2 pdehaan  staff    68B Jul 27 14:48 icons/
drwxr-xr-x   7 pdehaan  staff   238B Jul 27 14:48 img/
drwxr-xr-x  10 pdehaan  staff   340B Jul 27 14:48 js/
-rw-r--r--   1 pdehaan  staff   719B Jul 27 14:48 manifest.json
-rw-r--r--   1 pdehaan  staff   1.6K Jul 27 14:48 package.json
drwxr-xr-x   5 pdehaan  staff   170B Jul 27 14:48 tests/
-rw-r--r--   1 pdehaan  staff   1.7K Jul 27 14:48 toolbar.html
drwxr-xr-x   2 pdehaan  staff    68B Jul 27 14:48 web-ext-artifacts/

Most curious are the empty /coverage/, /icons/ directories (/icons/ was renamed to /img/ in #63), and /web-ext-artifacts/.

I'm guessing now that we've merged #43 we'll also have a /docs/ directory in the next build.

We probably (maybe?) can remove the following things from the generated XPI add-on:

• /coverage/
• /docs/*
• /icons/
• /tests/*
• /web-ext-artifacts/
• /img/*.png (add-on may only need *.svg files)
• /js/background.js (? since we have a browserified /js/background.bundle.js)
• /README.md
• /manifest.json (? not sure if needed in the .XPI or just to build the XPI)
• /package.json (? not sure if needed in the .XPI or just to build the XPI)

Clicking "report a problem" button updates the header text but no longer opens a modal window.

https://github.com/mozilla/blok/pull/23/files/3d8ab1a2dec6229bd3b080432b9a29a9e71a5730#r70981482

please try making the labels bold and send a screencap for design review

If a user neglects to select a radio button but enters text & clicks Submit the modal does not display any error messages [nor does it submit].

Follow-up to #2 for the rest of https://developers.google.com/safe-browsing/v4/urls-hashing#canonicalization

From #11 ...

For example, these are all first-party:

• www.facebook.com and facebook.com
• www.facebook.com and sdk.facebook.com

while these are third-parties:

• blah.cloudfront.net and foo.cloudfront.net

We need to make sure that real TP is disabled to make sure that the breakages come from the add-on:

• privacy.trackingprotection.enabled = false
• privacy.trackingprotection.pbmode.enable = false

We should probably also detect Privacy Badger, uBlock, ABP, etc. and ask users to disable them.

I clicked the "This page works well" but the toolbar still stays visible and obscures my page. Not sure if we want to auto-close the toolbar after 3-4 seconds after the user gives feedback.

Ref: #78
Ref: #81

Probably into a new module, and then write tests.

Playing with JSON validation using eslint-plugin-json and it spotted one error (bad-json) in disconnect-entitylist.json:

$ ./node_modules/.bin/eslint --ext=.json .

/Users/pdehaan/dev/github/mozilla/blok/disconnect-entitylist.json
  1153:5  error  Duplicate key 'Adsrevenue'  bad-json

✖ 1 problem (1 error, 0 warnings)

Code in question is:

    "Adsrevenue": {
        "properties": [
            "adsrevenue.net"
        ],
        "resources": [
            "adsrevenue.net"
        ]
    },

    "Adsrevenue": {
        "properties": [
            "adsnative.com"
        ],
        "resources": [
            "adsnative.com"
        ]
    },

I'd guess that in this case the .net domain is getting overwritten by the .com domain entry. Or not, what do I know, man.

And my minimal .eslintrc file is:

extends: eslint:recommended

plugins:
  - json

If we're getting this from an upstream provider, we may be out of luck — but still worth investigating and possibly filing a bug with them.

Per #33 (comment),

Turns out injecting standard was pretty trivial by adding the eslint-config-standard config (and a couple plugins) as dev dependencies:

$ npm i eslint-config-standard eslint-plugin-{standard,promise} -D`

Then tweak the ESLint rules to extend the standard config:

extends:
  - eslint:recommended
  - standard

Finally run $ npm run lint -- --fix to run ESLint and auto-fix any auto-fixable errors:

$ npm run lint

> [email protected] lint /Users/pdehaan/dev/github/mozilla/blok
> eslint .

/Users/pdehaan/dev/github/mozilla/blok/js/background.js
    9:5   error    Identifier 'current_active_tab_id' is not in camel case          camelcase
   10:5   error    Identifier 'current_origin_disabled_index' is not in camel case  camelcase
   11:5   error    Identifier 'current_active_origin' is not in camel case          camelcase
   12:5   error    Identifier 'blocked_requests' is not in camel case               camelcase
   13:5   error    Identifier 'blocked_entities' is not in camel case               camelcase
   14:5   error    Identifier 'allowed_requests' is not in camel case               camelcase
   15:5   error    Identifier 'allowed_entities' is not in camel case               camelcase
   16:5   error    Identifier 'total_exec_time' is not in camel case                camelcase
   17:5   error    Identifier 'reasons_given' is not in camel case                  camelcase
   49:5   error    Identifier 'current_active_origin' is not in camel case          camelcase
   50:5   error    Identifier 'current_origin_disabled_index' is not in camel case  camelcase
   56:29  error    Identifier 'current_origin_disabled_index' is not in camel case  camelcase
  172:5   error    Identifier 'current_active_tab_id' is not in camel case          camelcase
  179:11  warning  'actionPerformed' is defined but never used                      no-unused-vars
  179:30  error    Identifier 'current_origin_disabled_index' is not in camel case  camelcase
  180:29  error    Identifier 'current_origin_disabled_index' is not in camel case  camelcase
  181:29  error    Identifier 'current_origin_disabled_index' is not in camel case  camelcase

/Users/pdehaan/dev/github/mozilla/blok/js/canonicalize.js
   1:70  error    Unnecessary escape character: \           no-useless-escape
   2:45  error    Unnecessary escape character: \           no-useless-escape
   3:71  error    Unnecessary escape character: \           no-useless-escape
  19:62  error    Unnecessary escape character: \           no-useless-escape
  26:7   warning  'isIP4Decimal' is defined but never used  no-unused-vars

/Users/pdehaan/dev/github/mozilla/blok/js/lists.js
  37:12  error  Identifier 'category_name' is not in camel case  camelcase
  39:9   error  Identifier 'entity_count' is not in camel case   camelcase
  41:25  error  Identifier 'entity_count' is not in camel case   camelcase
  44:16  error  Identifier 'entity_name' is not in camel case    camelcase
  47:18  error  Identifier 'main_domain' is not in camel case    camelcase
  50:15  error  Identifier 'domains_count' is not in camel case  camelcase
  52:31  error  Identifier 'domains_count' is not in camel case  camelcase
  53:37  error  Identifier 'main_domain' is not in camel case    camelcase

✖ 30 problems (28 errors, 2 warnings)

I may let somebody else pull the trigger on this, since it looks like somebody will better domain knowledge than me to refactor the variable names into camelcase (or disable the Standard camelcase rule, if appropriate).

(Without running with the --fix flag, you should get ✖ 70 problems (68 errors, 2 warnings) from ESLint after switching to standard.)

The Blok graphic on http://testpilot.dev.mozaws.net/experiments needs a higher resolution image- it currently displays as stretched.

http://imgur.com/a/4xPWx

currently the buttons have barely any padding on the bottom and should have equal top and bottom padding of gray

... You get the idea.

Enabling Blok brings up an option for a tour - which is currently blank. This issue is a placeholder for adding the Blok tour.

https://github.com/mozilla/blok/pull/23/files/3d8ab1a2dec6229bd3b080432b9a29a9e71a5730#r70982649

Click the Report a problem button in the Blok toolbar.

I can't seem to scroll down the feedback form to the Submit button. Scrolling seems to scroll the page in the background, not the feedback form.

Workaround: Resize the window higher to see the bottom of the form.

When a user clicks the Blok page action, show them a button to disable protection and ask them why they disabled it, so we can quickly and easily learn why users are disabling protection.

Design:

https://www.dropbox.com/s/nbkkatjfhhr2xbj/sk3.png?dl=0

form controls assets are here:
http://people.mozilla.org/~shorlander/styleguide/styleguide-buttons/form-controls.html

Copy:

https://docs.google.com/spreadsheets/d/19JAW3XkhfkRbAeGKia3loRMZou96_HUVoBxSh3f1oEQ/edit?ts=578e51f8#gid=0

[Affected versions]:
- Firefox 48 and up.
- Blok 0.1.7

[Affected Platforms]:
- All Linux.

[Prerequisites]:
- Latest Blok add-on (0.1.7) is installed.

[Steps to reproduce]:
1. Navigate to cnn.com website.
2. Observe how the Blok bar is displayed in relation with the website content.

[Expected result]:
The Blok bar is displayed above the website content whithout affecting the view of page elements.

[Actual result]:
Blok bar is rendered over the website content, making content unreadable or unaccessible.

[Notes]:
- Attached a screenshot of the issue.

Per #33 (comment)

Currently we're including 3rd party Foundation CSS code in the repo (see /css/foundation.min.css).

It'd be nice if we included this via something like Bower or Node as a dependency.

Closest I can guess, we could do something like:

$ npm i foundation-sites -D

Then add a package.json postinstall hook to copy the file into /css/:

"postinstall": "cp ./node_modules/foundation-sites/dist/foundation.min.css css/foundation.min.css",

Or, we could write some Node script to copy the file, but that seems a bit more verbose (although probably a bit more cross-platform friendly):

const fs = require('fs')
const path = require('path')

const cssPath = require.resolve('foundation-sites/dist/foundation.min.css')
const cssDest = path.join(__dirname, '..', 'css', 'foundation.min.css')

fs.createReadStream(cssPath).pipe(fs.createWriteStream(cssDest))

Opening "report a problem" and then closing the modal or clicking Cancel updates the page header to "You have reported a problem".

Discussion also happening at https://bugzilla.mozilla.org/show_bug.cgi?id=1288196

Questions we want to ask the data

• What are the most popular broken sites?
  • How are they broken?
    • How might we fix them?
  • Is there an anti-blocker in the page
• Which trackers are most commonly involved with breakage?
  • What tracking techniques are they using?
• How much time & bandwidth are users wasting with trackers?

Currently:

"Report a problem"

{"originDomain":"www.redditmedia.com","trackerDomains":["ssl.google-analytics.com","www.google-analytics.com","sb.scorecardresearch.com"],"feedback":"page-problem"}

Breakage report

{"originDomain":"www.redditmedia.com","trackerDomains":["ssl.google-analytics.com","www.google-analytics.com","sb.scorecardresearch.com","static.adzerk.net","z.moatads.com"],"breakage":"layout","notes":""}

"This page works well"

{"originDomain":"www.redditmedia.com","trackerDomains":["ssl.google-analytics.com","www.google-analytics.com","sb.scorecardresearch.com","static.adzerk.net","z.moatads.com","static.adzerk.net","z.moatads.com"],"feedback":"page-works"}

What's possible:

Blocked requests

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/WebRequest/onBeforeRequest#details

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/WebRequest/onBeforeSendHeaders#details

Allowed requests

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/WebRequest/onCompleted#details

STR:

1. Go to http://testpilot.dev.mozaws.net/experiments/blok
2. Click "Enable Blok"

Expect results:
Blok is installed & enabled

Actual results:
The install hangs & 1468880237073 addons.xpi WARN Download of https://github.com/mozilla/blok/blob/master/web-ext-artifacts/blok-0.1.xpi?raw=true failed: signature is required but missing is shown in the browser console.

Suggest shortening copy to say:
'Disable blocking for this site' (remove tab)

Also may want to reference the add-on name in the copy at the top, like 'XXX Add-on' blocked 15 requests that may be tracking your browsing."

We can have our copywriter weigh in as well...

Mock here:
https://www.dropbox.com/s/pf2oxhjqxujzawl/Screenshot%202016-08-03%2017.26.48.png?dl=0

Pending review by copywriter but use as placeholder

Currently, users have a tendency to report some Web sites breakage to webcompat.com. When we have identified that it is a perceived issue created by tracking protection, we close it as a duplicate of Bugzilla: trackingprotection (look at the long list of SeeAlso).

A couple of things from this. Users (in the current Firefox setup) seem to not understand what is happening.

Maybe the shield could provide more information.

Something that helps the users

• understand what has been blocked
• understand why these specific domains are on the block list
• change the control list
• add to the exception list
• etc.

It would be ideal if pages saved reported data instead of clearing it upon refresh or a new tab view.

icons are here:
https://www.dropbox.com/sh/zeqmkbgozbjx4my/AAAzG3i0RNFSzDwZamcVwefEa?dl=0

$ git rev-parse HEAD # cb8d191c9bbf92f957441322f0e9ac59d5d1cd90

Steps to reproduce:

1. $ rm -f web-ext-artifacts/*
2. $ npm run build-dev
3. Drag generated web-ext-artifacts/blok-0.1.2.zip into Firefox Nightly about:addons to install.
4. Browse around GitHub (or whatever)

Actual results:

actionRequests is undefined (background.bundle.js:182)

log('blocked ' + actionRequests.length + ' requests: ' + actionRequests)

— via /js/background.js:181

Moving the shield to the left side of the identity block will make it more visible as someone scans a site url or checks its security states (lock icon).

Recommend using the existing shield icon but making it in color so that it stands out more than the existing gray version.

For placement, I could imagine putting it behind the carrot like we do for some notifications like passwords/plug-ins - it would give it some separation from the main icon set since this is a plug-in.

I have Blok 0.1.1 installed, and was browsing https://github.com/mozilla/activity-stream/blob/master/fabfile.py and noticed that Blok header is telling me that it has blocked trackers and if I open the Browser Console (Tools > Web Developer > Browser Console), it tells me:

undefined is not a valid URL. (background.bundle.js:49)

// Determine all origin flags
originTopHost = canonicalizeHost(new URL(requestDetails.originUrl).host)

— via /js/background.js:48

[Affected versions]:
- Firefox 48 and up.
- Blok 0.1.7

[Affected Platforms]:
- All Linux.

[Prerequisites]:
- Latest Blok add-on (0.1.7) is installed.

[Steps to reproduce]:
1. Navigate to cnn.com website.
2. Click on "Disable Blok for this website" text button from the displayed bar.
3. Observe the new displayed message in the Blok bar.

[Expected result]:
"Blok is disabled. Parts of this site may be tracking your activity."

[Actual result]:
"Blok is disabled. Parts of this site my be tracking your activity."

[Notes]:
- Attached a screenshot of the issue.

Since merging https://github.com/groovecoder/blok/pull/5 the popup sometimes shows the wrong state of protection (enabled/disabled) and the wrong count of requests blocked.

First step: get reliable steps to reproduce

Might consider using something better than background page window scope variables for state management. 😉

Looks like we probably want to add web-ext as a devDependency instead of assuming it's installed globally.

$ npm run build-dev

> [email protected] build-dev /Users/pdehaan/dev/github/mozilla/blok
> npm test && MODE=dev npm run bundle && web-ext build


> [email protected] test /Users/pdehaan/dev/github/mozilla/blok
> tape tests/**/*.js | faucet

✓ canonicalizeHost plain host is plain
✓ canonicalizeHost leading and trailing dots are trimmed
✓ canonicalizeHost consecutive dots are consolidated
✓ canonicalizeHost ip4 addresses decimal, hex, and octal
✓ canonicalizeHost lowercase everything
✓ canonicalizeHost test everything together
✓ allHosts returns single element for trackertest.org
✓ allHosts returns multiple elements for tracky.track.trackertest.org
# tests 14
# pass  14
✓ ok

> [email protected] bundle /Users/pdehaan/dev/github/mozilla/blok
> browserify -d -t envify js/background.js > js/background.bundle.js

sh: web-ext: command not found

Sub-task of #11 ...

The platform code also treats the following load as first-party:

• top-level page is www.facebook.com
• there is an iframe to game.superfarmers.com
• that iframe loads sdk.facebook.com/leaderboard.js

While game.superfarmers.com and sdk.facebook.com are third-parties, sdk.facebook.com is considered first-party with the top-level page (www.facebook.com) so we load it.

See http://searchfox.org/mozilla-central/rev/ef24c234ed53b3ba50a1734f6b946942e4434b5b/netwerk/base/nsChannelClassifier.cpp#95-117

please make gradient of bar:
gradient #414141 to #606060

and styling to match these specs:

1px dropshadow

[4:03]
.Infobar {
background-image: -moz-linear-gradient( 90deg, rgb(65,65,65) 0%, rgb(96,96,96) 100%);
background-image: -webkit-linear-gradient( 90deg, rgb(65,65,65) 0%, rgb(96,96,96) 100%);
background-image: -ms-linear-gradient( 90deg, rgb(65,65,65) 0%, rgb(96,96,96) 100%);
box-shadow: 0px 1px 0px 0px rgba(42, 42, 42, 0.004),inset 0px 1px 0px 0px rgba(255, 255, 255, 0.1);
position: absolute;
left: 2396px;
top: 607px;
width: 1200px;
height: 27px;
z-index: 2081;
}

Current output:

$ ./node_modules/.bin/addons-linter web-ext-artifacts/*.zip -o text
Validation Summary:

errors          0
notices         0
warnings        0

$ git rev-parse HEAD # cb8d191c9bbf92f957441322f0e9ac59d5d1cd90

Steps to reproduce:

1. $ rm -f web-ext-artifacts/*
2. $ npm run build-dev
3. Drag generated web-ext-artifacts/blok-0.1.2.zip into Firefox Nightly about:addons to install.
4. Browse around GitHub (or whatever)

Actual results:

blockedRequests[requestTabID] is undefined (background.bundle.js:145)

blockedRequests[requestTabID].push(requestTopHost)

— via /js/background.js:144