Privacybadger: Export user data not working
From Manage Data-->Export User Data, Download button just opens blank page with URL "moz-extension://" plus very long string, impossible to copy--when trying to copy in its entirety only results in "about:blank."
Note: Import User Data does work.
PB v2020.1.13
Browser: Waterfox Classic 2020.01
Does work properly in Firefox 68.4.2esr
9jkh
All 24 comments
My guess it's either something about the way we detect whether we should work around a Firefox bug, or the workaround itself (edit: or, it might be something about clicking Blob links). I don't think anything changed recently on our side though.
As I replied in https://github.com/EFForg/privacybadger/issues/2508#issuecomment-554383054, I'll review a patch with a fix for this if somebody contributes one, but otherwise we shouldn't spend time on a fix for an unsupported browser.
ghostwords
on 22 Jan 2020
No hope I take it for a simple workaround?
9jkh
on 22 Jan 2020
What is the output if you run the following code in the JavaScript console for Privacy Badger's options page?
chrome.runtime.getBrowserInfo((info) => {
console.log(info.name);
});
Not very good with Console, and this may not be what you want, but this is what I come up with:
chrome.runtime.getBrowserInfo((info) => {
console.log(info.name);
});
undefined
Waterfox
9jkh
on 22 Jan 2020
That's good, thank you.
ghostwords
on 23 Jan 2020
What if you run the following code in the console on the options page? (Sorry, the previous code I pasted was broken.) This should produce a data export.
function exportUserData() {
chrome.storage.local.get(USER_DATA_EXPORT_KEYS, function (maps) {
// exports the user's prevent webrtc leak setting if it's checked
if ($("#toggle_webrtc_mode").prop("checked")) {
maps.settings_map.preventWebRTCIPLeak = true;
}
let mapJSON = JSON.stringify(maps);
// Append the formatted date to the exported file name
let currDate = new Date().toLocaleString();
let escapedDate = currDate
// illegal filename charset regex from
// https://github.com/parshap/node-sanitize-filename/blob/ef1e8ad58e95eb90f8a01f209edf55cd4176e9c8/index.js
.replace(/[\/\?<>\\:\*\|"]/g, '_') /* eslint no-useless-escape:off */
// also collapse-replace commas and spaces
.replace(/[, ]+/g, '_');
let filename = 'PrivacyBadger_user_data-' + escapedDate + '.json';
// Download workaround taken from uBlock Origin
// https://github.com/gorhill/uBlock/blob/40a85f8c04840ae5f5875c1e8b5fa17578c5bd1a/platform/chromium/vapi-common.js
let a = document.createElement('a');
a.setAttribute('download', filename || '');
let blob = new Blob([mapJSON], { type: 'application/json' }); // pass a useful mime type here
a.href = URL.createObjectURL(blob);
function clickBlobLink() {
a.dispatchEvent(new MouseEvent('click'));
URL.revokeObjectURL(blob);
}
/**
* Firefox workaround to insert the blob link in an iFrame
* https://bugzilla.mozilla.org/show_bug.cgi?id=1420419#c18
*/
function addBlobWorkAroundForFirefox() {
// Create or use existing iframe for the blob 'a' element
let iframe = document.getElementById('exportUserDataIframe');
if (!iframe) {
iframe = document.createElement('iframe');
iframe.id = "exportUserDataIframe";
iframe.setAttribute("style", "visibility: hidden; height: 0; width: 0");
document.getElementById('export').appendChild(iframe);
iframe.contentWindow.document.open();
iframe.contentWindow.document.write('<html><head></head><body></body></html>');
iframe.contentWindow.document.close();
} else {
// Remove the old 'a' element from the iframe
let oldElement = iframe.contentWindow.document.body.lastChild;
iframe.contentWindow.document.body.removeChild(oldElement);
}
iframe.contentWindow.document.body.appendChild(a);
}
// TODO remove browser check and simplify code once Firefox 58 goes away
// https://bugzilla.mozilla.org/show_bug.cgi?id=1420419
if (chrome.runtime.getBrowserInfo) {
chrome.runtime.getBrowserInfo((info) => {
if (info.name == "Firefox" || info.name == "Waterfox") {
addBlobWorkAroundForFirefox();
}
clickBlobLink();
});
} else {
clickBlobLink();
}
});
}
exportUserData();
That works! Very cool. Thanks for all the work you put into this.
Hope I’m not overstaying my welcome, but I have one more question that probably doesn’t require any code. If this is the wrong place for this, I can put this where it belongs:
Waterfox originally had something like 300 tracking domains. But I exported over 1,000 from Chrome to WF (seems like Chrome has a default list like that, since there’s no way I could have acquired that many--don’t use Chrome all that often.) There are many hundreds which PB hasn’t yet learned to block, and I’m wondering if there is a way to move all of these to the middle slider positon without going through them one by one.
If this isn’t possible, no problem, I can live with this as it is. And thanks again.
9jkh
on 23 Jan 2020
You're welcome! Since it appears we identified the Waterfox incompatibility and it's a simple tweak, this bug will be resolved in the next Privacy Badger update.
ghostwords
on 23 Jan 2020
Each new update of Privacy Badger comes with pre-trained Badger data. New installations of Privacy Badger start with this data set.
You can reset Privacy Badger's data to the most recent pre-trained set at any point by clicking the Reset button under the Manage Data tab on the options page.
ghostwords
on 23 Jan 2020
I don't recommend manually managing Badger's blocking preferences. Please see https://github.com/EFForg/privacybadger/issues/2248#issuecomment-448274011 for more information.
ghostwords
on 23 Jan 2020
We may want to change the default state for not-yet-blocked trackers to "yellow" (cookie blocking): #1514
ghostwords
on 23 Jan 2020
You're welcome! Since it appears we identified the Waterfox incompatibility and it's a simple tweak, this bug will be resolved in the next Privacy Badger update.
Excellent! Thanks.
Been using it a fair number of years, but didn't know that PB now comes "'pre-trained"
Tried the Reset option. Before the Reset option, there were 1361 Tracking Domains listed in Waterfox. After Reset, down to 884, with only 4 allowed. Seems that the difference is mainly the removal of a vast number of the Allowed. Wondering which is better for blocking tracking? Without the former "Allowed" will PB not be inhibited from learning to block those formerly Allowed? And will PB now lose the benefit of what was already learned from the previous total of 1361 from years of use?
(Won't even begin to try to manually adjust any of the allowed. Even if it were desirable, I'd be doing this for hours on end.)
And a btw: the reason I wanted to be able to export the WF data was to import that data (merged from the Chrome default and the WF accrued) to Firefox, which had far less.
9jkh
on 23 Jan 2020
We may want to change the default state for not-yet-blocked trackers to "yellow" (cookie blocking): #1514
That seems like a good idea. Haven't come across a site set to yellow that breaks, and can always set to green if it happens, as poster in linked thread said.
Btw, edit button not working for me. Everything allowed in uBO, NoScript, and uMatrix, but just doesn't respond.
9jkh
on 23 Jan 2020
"Allowed" domains are potential trackers that Privacy Badger hasn't yet seen track on enough sites.
I suggest leaving Privacy Badger's sliders/data alone. The pre-trained data set should be a good start, and then your Badger should automatically learn to block whatever trackers you run into that were not caught in training for whatever reason.
When you run into something not working, you could try telling Privacy Badger to leave the site alone by clicking the "Disable Privacy Badger for this site" button inside Privacy Badger's popup while on the site. You can also let us know when a site is broken by clicking on the "Did Privacy Badger break this site? Let us know!" button in the popup. This helps us figure out which site fixes we should work on next.
ghostwords
on 25 Jan 2020
The heart of my question really is whether I would be better off with the roughly 900+ trackers imported from Chrome (Brave really) plus the learned ~300 imported from Waterfox and merged with the Chrome ones, total 1,361, or with that Chrome/Waterfox merged total after a “pre-trained" Reset, which comes to 884.
On Jan 25, 2020, at 11:44 AM, Alexei notifications@github.com wrote:
"Allowed" domains are potential trackers that Privacy Badger hasn't yet seen track on enough sites.
I suggest leaving Privacy Badger's sliders/data alone. The pre-trained data set should be a good start, and then your Badger should automatically learn to block whatever trackers you run into that were not caught in training for whatever reason.
When you run into something not working, you could try telling Privacy Badger to leave the site alone by clicking the "Disable Privacy Badger for this site" button inside Privacy Badger's popup while on the site. You can also let us know when a site is broken by clicking on the "Did Privacy Badger break this site? Let us know!" button in the popup. This helps us figure out which site fixes we should work on next.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
9jkh
on 25 Jan 2020
It shouldn't matter much, as I tried to say in my previous reply.
ghostwords
on 25 Jan 2020
Got it, thanks.
On Jan 25, 2020, at 16:57, Alexei notifications@github.com wrote:
It shouldn't matter much, as I tried to say in my previous reply.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
9jkh
on 26 Jan 2020
Quick, somewhat OT question: I'm looking for a way to bypass the redirect tracker guce.advertising.com, which is needed to login to AOL webmail. PB Tracker domains lists advertising.com, and I wonder if with that set to red, it will also block the sub-domain guce.advertising.com? Perhaps you might know?
https://i.postimg.cc/NFZzHzth/Screen-Shot-2020-01-28-at-10-29-19-AM.png
9jkh
on 28 Jan 2020
Yes, if advertising.com is blocked, guce.advertising.com will be blocked by default. You can override that and set guce.advertising.com to "yellow" or "green" using Privacy Badger's popup next time you are on a page that includes it.
ghostwords
on 28 Jan 2020
Very good to know, thanks.
On Jan 28, 2020, at 2:50 PM, Alexei notifications@github.com wrote:
Yes, if advertising.com is blocked, guce.advertising.com will be blocked by default. You can override that and set guce.advertising.com to "yellow" or "green" using Privacy Badger's popup next time you are on a page that includes it.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
9jkh
on 28 Jan 2020
Just checked again, and don’t know how far you can go with this, but at any point on logging in to AOL Mail, I have never seen advertsing.com (or guce.advertising.com, for that matter) come up in PB. PB shows “tracker free.” I know for a fact that it’s being allowed from uBlock Origin. Is it possible it’s being blocked by PB?
On Jan 28, 2020, at 4:16 PM, [email protected] wrote:
Very good to know, thanks.
On Jan 28, 2020, at 2:50 PM, Alexei notifications@github.com wrote:
Yes, if advertising.com is blocked, guce.advertising.com will be blocked by default. You can override that and set guce.advertising.com to "yellow" or "green" using Privacy Badger's popup next time you are on a page that includes it.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
9jkh
on 28 Jan 2020
EDIT: I didn’t put this very well in my earlier post. Re. never seeing advertising.com in PB on accessing AOL Mail. In other words, does advertising.com have to show up up in PB as a “potential tracker" in order for it to be blocked? Even if it doesn’t come up on loading a site which employs it (guce.advertising.com) is it still being blocked?
On Jan 28, 2020, at 4:54 PM, [email protected] wrote:
Just checked again, and don’t know how far you can go with this, but at any point on logging in to AOL Mail, I have never seen advertsing.com (or guce.advertising.com, for that matter) come up in PB. PB shows “tracker free.” I know for a fact that it’s being allowed from uBlock Origin. Is it possible it’s being blocked by PB?
On Jan 28, 2020, at 4:16 PM, [email protected] wrote:
Very good to know, thanks.
On Jan 28, 2020, at 2:50 PM, Alexei notifications@github.com wrote:
Yes, if advertising.com is blocked, guce.advertising.com will be blocked by default. You can override that and set guce.advertising.com to "yellow" or "green" using Privacy Badger's popup next time you are on a page that includes it.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
9jkh
on 29 Jan 2020
The popup should list whatever tracking domains were detected on the page. If you use other blockers, the popup is likely to list fewer domains (because your other blockers got to them first).
ghostwords
on 29 Jan 2020
Quite bewildering: Before you posted your most recent reply, I thought of that, and had already tried logging in to AOL Mail with absolutely any extension that might possibly be a blocker--even tangentially or remotely--disabled. Won’t give the list, as it’s too long, but even though a number of other PB trackers did pop up at several points in logging in and loading, advertising.com was never among them. uBO was disabled, but this is what comes up when it is enabled
https://i.postimg.cc/kGSVTKCk/Screen-Shot-2020-01-29-at-2-44-22-PM.png
Until quite recently, you would have been able to try to replicate this from huffpost, engadget and several other AOL/Verizon owned sites, but they have all now dropped this tracker, guce.advertising.com, except for AOL Mail. And unless you happen to have an AOL Mail account I don’t know of any way for you to see directly what I’m experiencing.
I won’t bother you with this any longer, unless you happen to have any further suggestions.
Thanks for you patience with this over these days.
On Jan 29, 2020, at 12:51 PM, Alexei notifications@github.com wrote:
The popup should list whatever tracking domains were detected on the page. If you use other blockers, the popup is likely to list fewer domains (because your other blockers got to them first).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
9jkh
on 29 Jan 2020
Related issues
cypherpunk
·
6Comments
andresbase
·
4Comments
hairetikos
·
3Comments
bitnik
·
5Comments
smarkwell
·
5Comments