Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Whitelist domains when privacy.trackingprotection.enabled is true?

393 views
Skip to first unread message

Ant

unread,
Nov 27, 2015, 12:08:24 PM11/27/15
to mozilla-sup...@lists.mozilla.org
Hello.

http://www.ocregister.com shows many missing images.onset.freedom.com
images in my web browsers because I have enabled
privacy.trackingprotection.enabled in my Firefox/Iceweasel v42's
about:config. Is there a way to whitelist this domain?

Thank you in advance. :)
--
"... Let's go pour these (peas from a can) onto an anthill I've found."
--Strong Bad (Witness the Cheatar! episode)
Note: A fixed width font (Courier, Monospace, etc.) is required to see
this signature correctly.
/\___/\ Ant(Dude) @ http://antfarm.ma.cx (Personal Web Site)
/ /\ /\ \ Ant's Quality Foraged Links: http://aqfl.net
| |o o| |
\ _ / If crediting, then use Ant nickname and AQFL URL/link.
( ) Chop ANT from its address if e-mailing privately.
Ant is currently not listening to any songs on this computer.

WaltS48

unread,
Nov 27, 2015, 12:34:08 PM11/27/15
to mozilla-sup...@lists.mozilla.org
On 11/27/2015 10:21 AM, Ant wrote:
> Hello.
>
> http://www.ocregister.com shows many missing images.onset.freedom.com
> images in my web browsers because I have enabled
> privacy.trackingprotection.enabled in my Firefox/Iceweasel v42's
> about:config. Is there a way to whitelist this domain?
>
> Thank you in advance. :)

Not that I can find. It uses the disconnect.me block lists.

--
Linux Mint 17.2 "Rafaela" | KDE 4.14.2 | Thunderbird 45.0a1 (Daily)
You don't need zero-days when machines wherever are packed with old-days.
Go Bucs! (next season) Go Pens! Go Sabres! Go Pitt!
[Visit Pittsburgh]<http://www.visitpittsburgh.com/>
[Coexist · Understanding Across Divides]<https://www.coexist.org/>

EE

unread,
Nov 27, 2015, 1:19:29 PM11/27/15
to mozilla-sup...@lists.mozilla.org
Ant wrote:
> Hello.
>
> http://www.ocregister.com shows many missing images.onset.freedom.com
> images in my web browsers because I have enabled
> privacy.trackingprotection.enabled in my Firefox/Iceweasel v42's
> about:config. Is there a way to whitelist this domain?
>
> Thank you in advance. :)

Other than seeing the tiny images for the classifieds, I see no images
on that page, and also no indication that there are supposed to be images.

WaltS48

unread,
Nov 27, 2015, 1:30:18 PM11/27/15
to mozilla-sup...@lists.mozilla.org
I see all of the images on the page, but I don't have the pref enabled,
or use NoScript or any script blocking extension. I also switched to
uBlock Origin, because ABP was blocking things when disabled.

Ant

unread,
Nov 27, 2015, 2:36:17 PM11/27/15
to mozilla-sup...@lists.mozilla.org
>> http://www.ocregister.com shows many missing images.onset.freedom.com
>> images in my web browsers because I have enabled
>> privacy.trackingprotection.enabled in my Firefox/Iceweasel v42's
>> about:config. Is there a way to whitelist this domain?
>>
>> Thank you in advance. :)
>
> Not that I can find. It uses the disconnect.me block lists.

Thanks. :(
--
"The constant creeping of ants will wear away the stone." --unknown

VanguardLH

unread,
Nov 27, 2015, 6:15:02 PM11/27/15
to mozilla-sup...@lists.mozilla.org
Ant wrote:

> http://www.ocregister.com shows many missing images.onset.freedom.com
> images in my web browsers because I have enabled
> privacy.trackingprotection.enabled in my Firefox/Iceweasel v42's
> about:config. Is there a way to whitelist this domain?

When the half-filled shield icon appears at the left of the addressbar
(to clue you to Firefox having blocked some content using its inbuilt
tracking blocker), there is an Options button. Although plural, there
is only one option: Disable protection for this site. If you elect to
disable protection (allow the content), the icon changes to a
half-filled shield with a red diagonal line across it. Also, the site
gets added to the capability.policy.maonoscript.sites setting. However,
this block disable is only valid during the current web browser session.
Once you exit and later load Firefox again, the tracking content will
get blocked again. There is no whitelist to retain your decision across
web browser sessions - as you have discovered.

As with Firefox's redirection blocker, their tracking blocker also does
not show just what was blocked. You often don't know to where a
redirection points that Firefox blocked and you don't get a list of what
tracking content got blocked. No information. The blocked images are
from a different domain and we all know about the use of web beacons
(any size) for tracking.

It is not uncommon for a site to show content from a different site
(that is not ads but, say, images for articles). I forget which site
(maybe cnn.com) that shows images from turner.com to tie into their
articles. Since Firefox's blocker has no user-configurable options
(beyond unblocking only for the current web browser session), you're
stuck with whatever Disconnect.me puts in their blocklist. To have more
control means not using Firefox's blocker and using a more robust
blocker add-on. With Adblock Plus, uClick [Origin], Ghostery, or
NoScript, you could whitelist the content source that you want to see.

*By the way*, I don't think the cross-domain image blocking is due to
Mozilla incorporating the Disconnect.me block list. Disconnect.me would
be blocking tracking objects in a web page. Most likely Firefox's own
tracking blocker is blocking on cross-domain images. If you read
http://www.freedom.com/newspapers/community.html, you'll see the
OCregister.com site is their own. They provide content digital content
to other newspapers, too. So here is a site, ocregister.com, that has
content delivered from another of their sites, freedom.com, but that
content is from a different domain. I doubt freedom.com is in the
Disconnect.me blocklist. Disconnect.me says they have a list of 5000
trackers (small by comparison with other add-on blockers) but I could
not find an actual list of what trackers they block. Firefox's tracking
blocker probably has more logic than just using the Disconnect.me block
list so it looks like it is also blocking cross-domain images to prevent
use of web beacons for tracking. Looks like Firefox is blocking more
than just what is in Disconnect.me's blocklist; i.e., for now, it's a
dumb blocker (for its own logic) and relies on a too-short block list.

I thought Firefox's inbuilt tracking block feature was considered
experimental and that Mozilla is planning to drop it. It uses the
Disconnect.me blocklist but that's a pretty small list (probably to
accommodate its use on mobile devices that have little memory or disk
space). Hopefully the rumors about the demise of Firefox's tracking
blocker are that it's current incarnation will expire and Mozilla will
put some real effort into producing a usable blocker: one with user
configurability (whitelisting, whether cross-domain images are allowed
and of what minimal dimensions, and info on what got blocked so users
can make an intelligent decision BEFORE whitelisting and having to then
review the whitelist).

If you install any other blocker add-on (e.g., NoScript, AdBlock Plus,
Ghostery), the Disconnect.me list is superfluous as the other lists
swamp it. Because there is no configurability of Firefox's tracking
block feature, and because I use uClick Origin (to replace the AdBlock
Plus memory hog) along with Ghostery and NoScript, there is no added
advantage in using Firefox's blocker: the larger lists already includes
the targets in Disconnect.me's small list. Web beacons are usually too
small to see or made transparent so I don't necessarily want to block
images coming from a different domain (but NoScript handles that,
anyway, so I can decide to allow for the current web browser session or
whitelist that content source).

Firefox's blocker: no whitelist
allow is only for current session
no info on what got blocked
3rd party add-ons: whitelist available
allow is available for current session or permanent
info on what got blocked

Ant

unread,
Nov 30, 2015, 7:03:47 PM11/30/15
to mozilla-sup...@lists.mozilla.org
FYI. http://rottentomatoes.com is another web site that doesn't like
this. :(

On 11/27/2015 7:21 AM, Ant wrote:
> Hello.
>
> http://www.ocregister.com shows many missing images.onset.freedom.com
> images in my web browsers because I have enabled
> privacy.trackingprotection.enabled in my Firefox/Iceweasel v42's
> about:config. Is there a way to whitelist this domain?
>
> Thank you in advance. :)
--
--
"If someone makes you angry, I think the thing to do is tie them down to
the ground, cover them in honey, and then release a swarm of killer ants
on them. That way, you can hit them over and over again and say, 'Hey!
I'm just trying to help!' and they can't really get mad at you." --R.M.
Weiner

B00ze

unread,
Nov 30, 2015, 7:46:16 PM11/30/15
to mozilla-sup...@lists.mozilla.org
On 2015-11-27 17:11, VanguardLH <V...@nguard.LH> wrote:

> this block disable is only valid during the current web browser session.
> Once you exit and later load Firefox again, the tracking content will
> get blocked again. There is no whitelist to retain your decision across
> web browser sessions - as you have discovered.

Are you sure? I just visited Rotten Tomato, and my little shield had a
red line through it, from the last time I disabled the blocker. I just
closed the tab, quit FF and reloaded/re-visited, and my red line is
still there; seems it remembers my choice. I use FF38 (and I have about
200 tabs opened, it *is* possible I have another Rotten Tomato tab
opened somewhere; I looked for one and did not find it, but it's
possible that my FF retains my blocking preference because of that).

Regards,

--
! _\|/_ Sylvain / B00...@hotmail.com
! (o o) Member-+-David-Suzuki-Fdn/EFF/Red+Cross/Planetary-Society-+-
oO-( )-Oo Friday the 13th Pt. 25 - Jason takes the Enterprise!

VanguardLH

unread,
Dec 1, 2015, 6:40:54 AM12/1/15
to mozilla-sup...@lists.mozilla.org
B00ze wrote:

> VanguardLH wrote:
>
>> this block disable is only valid during the current web browser session.
>> Once you exit and later load Firefox again, the tracking content will
>> get blocked again. There is no whitelist to retain your decision across
>> web browser sessions - as you have discovered.
>
> Are you sure? I just visited Rotten Tomato, and my little shield had a
> red line through it, from the last time I disabled the blocker. I just
> closed the tab, quit FF and reloaded/re-visited, and my red line is
> still there; seems it remembers my choice. I use FF38 (and I have about
> 200 tabs opened, it *is* possible I have another Rotten Tomato tab
> opened somewhere; I looked for one and did not find it, but it's
> possible that my FF retains my blocking preference because of that).

When I visit there and elect to allow (get the red line through the
half-shield icon), exit Firefox, reload Firefox and revisit that site,
it's back to a half-shield with no red line; i.e., the site is not
whitelist on a revisit in a NEW web browser session.

Even Mozilla mentions that the allow function is per web browser
session. There is no permanent whitelist of allowed sites. Alas,
trying to search on "firefox tracking protection" is swamped with newer
articles about the feature enabled by default in private mode in the
latest version 42.

While you have to change the private.trackingprotection.enabled to True
to get it to work in a normal instance of Firefox, Mozilla has made it
the default when you start a private mode instance of Firefox v42.

privacy.trackingprotection.enabled = false (global default)
For non-private mode instance of Firefox.

privacy.trackingprotection.pbmode.enable = true (private mode default)
For private mode instance of Firefox.

So 2 settings for the same blocking logic and Disconnect.me blocklist
but Mozilla defaulted to enabling it only in private mode. However, if
the global setting is enabled, it is also used in private mode
(according to https://wiki.mozilla.org/Security/Tracking_protection).

Desiree

unread,
Dec 1, 2015, 6:42:12 AM12/1/15
to mozilla-sup...@lists.mozilla.org
On 11/27/2015 5:21 AM, Ant wrote:
> Hello.
>
> http://www.ocregister.com shows many missing images.onset.freedom.com
> images in my web browsers because I have enabled
> privacy.trackingprotection.enabled in my Firefox/Iceweasel v42's
> about:config. Is there a way to whitelist this domain?
>
> Thank you in advance. :)
>

Install Lightbeam. You control Fx tracking protection there but you
can't whitelist. Use the list view. Tracking Protection is persistent
across sessions. You can block third party sites in Lightbeam in list
view and Tracking Protection remembers that. In graph view, if tracking
protection is working correctly you should see NO connections between
sites. Lightbeam is flaky on Fx 42 (but then Fx 42 is the most flaky of
any recent Fx version) and may disappear from Tools list and its icon
may disappear from the right side of the address bar. You may have to
reinstall it but it still will usually remember settings and sites
visited.

You can see the details for exactly what has been blocked on a site by
clicking on Tools/Web Developer/Web Console and then highlighting
Security tab. That site has tracking protection blocking a large
number of gifs and jpeg's. That's a bit puzzling to me as generally
gifs and jpeg's aren't trackers. I happen to have Ghostery working (it
is very flaky on Fx 42) at the moment. I went to ocregister.com and to
my surprise Ghostery only found one tracker and I also had Fx tracking
protection shield show up and details showed a bunch of gifs and jpegs
being blocked.

Something is screwy at that site because the moz dev who was in charge
of Fx tracking protection before she left Mozilla earlier this year said
in her blog that one or the other (disconnect or Ghostery) will
basically get there first and obliterate the other from doing anything
to stop tracking. Ghostery usually gets there first. I've never seen
the Fx tracking shield show up if Ghostery was working correctly until
now at ocregister.com.

http://i.imgur.com/woaFx6p.png

https://addons.mozilla.org/en-US/firefox/addon/lightbeam/?src=discovery-learnmore

http://monica-at-mozilla.blogspot.com/2015/03/how-do-i-turn-on-tracking-protection.html

https://github.com/mozilla-services/shavar-prod-lists/blob/master/disconnect-blacklist.json

B00ze

unread,
Dec 1, 2015, 8:21:40 PM12/1/15
to mozilla-sup...@lists.mozilla.org
On 2015-12-01 04:29, Desiree <mele...@medscape.com> wrote:

> Something is screwy at that site because the moz dev who was in charge
> of Fx tracking protection before she left Mozilla earlier this year said
> in her blog that one or the other (disconnect or Ghostery) will
> basically get there first and obliterate the other from doing anything
> to stop tracking. Ghostery usually gets there first. I've never seen
> the Fx tracking shield show up if Ghostery was working correctly until
> now at ocregister.com.

I've been running both Firefox's and Ghostery together and I have not
seen a problem, they both show-up sometimes and block different things.
At first I thought Ghostery was preventing Firefox's blocker because I
never saw both together; I even opened an issue on Ghostery's website,
and then a day later, I hit a site where both were blocking different
things. In any case, the devs at Ghostery promissed they would look into
this...

Regards,

--
! _\|/_ Sylvain / B00...@hotmail.com
! (o o) Member-+-David-Suzuki-Fdn/EFF/Red+Cross/Planetary-Society-+-
oO-( )-Oo Fire at Will. No, No WORF! Not Commander Riker!

Ant

unread,
Dec 1, 2015, 9:04:13 PM12/1/15
to mozilla-sup...@lists.mozilla.org
On 11/27/2015 7:21 AM, Ant wrote:

> http://www.ocregister.com shows many missing images.onset.freedom.com
> images in my web browsers because I have enabled
> privacy.trackingprotection.enabled in my Firefox/Iceweasel v42's
> about:config. Is there a way to whitelist this domain?

FYI. http://rottentomatoes.com's log in fails with this
privacy.trackingprotection.enabled being set to true as well. :(
--
"This is the ant. Treat it with respect. For it may very well be the
next dominant lifeform of our planet." --Empire of the Ants movie

Christian Riechers

unread,
Dec 2, 2015, 5:36:00 AM12/2/15
to mozilla-sup...@lists.mozilla.org
On 12/01/2015 07:02 AM, VanguardLH wrote:
> B00ze wrote:
>> VanguardLH wrote:
>>> this block disable is only valid during the current web browser session.
>>> Once you exit and later load Firefox again, the tracking content will
>>> get blocked again. There is no whitelist to retain your decision across
>>> web browser sessions - as you have discovered.
>>
>> Are you sure? I just visited Rotten Tomato, and my little shield had a
>> red line through it, from the last time I disabled the blocker. I just
>> closed the tab, quit FF and reloaded/re-visited, and my red line is
>> still there; seems it remembers my choice. I use FF38 (and I have about
>> 200 tabs opened, it *is* possible I have another Rotten Tomato tab
>> opened somewhere; I looked for one and did not find it, but it's
>> possible that my FF retains my blocking preference because of that).
>
> When I visit there and elect to allow (get the red line through the
> half-shield icon), exit Firefox, reload Firefox and revisit that site,
> it's back to a half-shield with no red line; i.e., the site is not
> whitelist on a revisit in a NEW web browser session.

This may be due to private browsing mode.
https://support.mozilla.org/en-US/kb/tracking-protection-pbm#w_turn-off-tracking-protection-for-individual-sites

> Even Mozilla mentions that the allow function is per web browser
> session. There is no permanent whitelist of allowed sites. Alas,
> trying to search on "firefox tracking protection" is swamped with newer
> articles about the feature enabled by default in private mode in the
> latest version 42.
>
> While you have to change the private.trackingprotection.enabled to True
> to get it to work in a normal instance of Firefox, Mozilla has made it
> the default when you start a private mode instance of Firefox v42.

With tracking protection enabled in normal mode via the pref below,
disabling protection for a specific site is remembered across browsing
sessions.

VanguardLH

unread,
Dec 2, 2015, 6:47:33 AM12/2/15
to mozilla-sup...@lists.mozilla.org
Christian Riechers wrote:

> With tracking protection enabled in normal mode via the pref below,
> disabling protection for a specific site is remembered across browsing
> sessions.

Then where is the whitelist (to remember across web browser sessions)?
WHICH pref? Global blocking or private mode only blocking?

B00ze

unread,
Dec 2, 2015, 8:29:59 PM12/2/15
to mozilla-sup...@lists.mozilla.org
I'm lost. My Firefox remembers for Rotten Tomatoes, but forgets for
another site (I disabled tracking protection, closed the tab, reopened
it, and tracking protection was enabled again)...

Best Regards,

--
! _\|/_ Sylvain / B00...@hotmail.com
! (o o) Member-+-David-Suzuki-Fdn/EFF/Red+Cross/Planetary-Society-+-
oO-( )-Oo Luke, use The Force, not your fingers.

Christian Riechers

unread,
Dec 3, 2015, 12:52:44 PM12/3/15
to mozilla-sup...@lists.mozilla.org
Global blocking (as mentioned above).

It works exactly as described in the support article posted before
(which you snipped).
I did try this only with FF 43 beta though.

»Q«

unread,
Dec 3, 2015, 1:57:13 PM12/3/15
to mozilla-sup...@lists.mozilla.org
In
<news:mailman.8119.144916516...@lists.mozilla.org>,
Works in Fx 42.0 also. Site preferences aren't read or saved in private
mode AFAICT, so whitelisting always has to be done per-session there.

VanguardLH

unread,
Dec 3, 2015, 9:44:55 PM12/3/15
to mozilla-sup...@lists.mozilla.org
What items are included for cleanup/purge on exit from Firefox? I
suspect Site Preferences might be where the tracking whitelist is kept.
It was posted here earlier under the thread titled "Unpatched browser
weaknesses can be exploited to track millions of Web users", and I
tested, that leaving on Site Preferences allows tracking you across web
browser sessions. You get a unique ID if Site Preferences are retained
across web browser sessions. To test, go to:

http://www.radicalresearch.co.uk/lab/hstssupercookies

With everything selected to clear on exit except Site Preferences in
Firefox, I got the same unique ID assigned to me in different web
browser session. That was for non-private mode. In private mode, Site
Preferences are not retained so I couldn't be tracked.

So I suspect you don't clear all the same items as I do on exit from
Firefox. I used to clear everything on exit but then I would lose the
password for Firefox's Sync. So I deselect clearing passwords on exit
but still leave disabled saving site passwords. Only my Sync password
is saved in Firefox's password manager.

Since the issue was about using Firefox's tracking protection, I figured
the folks using it would also be clearing items on exit from Firefox.
Guess there are users that want to prevent tracking using blocklists but
neglect about tracking using a feature in most web browsers. I don't
want to rely on when I happen to remember running CCleaner (which
includes clearing of Site Preferences) after using Firefox.

So the difference in noted behavior for the Firefox tracking block is
very likely due to how you and I differ in what we clear on exit. I had
forgot about the clear on exit setup.

Christian Riechers

unread,
Dec 4, 2015, 6:23:19 AM12/4/15
to mozilla-sup...@lists.mozilla.org
I'm not clearing Site Preferences after using Firefox. And I wouldn't
want to let CCleaner mess with my Firefox profile.
In my view the gain in security when using HSTS is greater than the risk
of being tracked.


VanguardLH

unread,
Dec 4, 2015, 10:12:59 AM12/4/15
to mozilla-sup...@lists.mozilla.org
https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

"It allows web servers to declare that web browsers (or other complying
user agents) should only interact with it using secure HTTPS
connections,[1] and never via the insecure HTTP protocol."

It's a server controlled features. Don't need the server telling the
client anything. Simply don't have an HTTP page (instead of relying on
redirecting visitors from HTTP to HTTPS). HSTS is nothing more than a
server-side managed policy, a request to the client, not a protocol.

"The HSTS header can be stripped by the attacker if this is the user's
first visit. Google Chrome, Mozilla Firefox, Internet Explorer and
Microsoft Edge attempt to limit this problem by including a "pre-loaded"
list of HSTS sites."

Same is noted at:

https://blog.mozilla.org/security/2012/11/01/preloading-hsts/

This is as stupid as using WOT (Web of Trust), SiteAdvisor, or other
whitelists of "good" sites. Such lists barely touch 1% of all available
sites so their promotion for security is misleading.

I suspect that users that attempt to avoid web tracking (e.g., clearing
items on exit, including Site Preferences) would end up losing the
whitelisting after first visit to an HSTS-policied site. So all visits
to an HSTS site would be a first visit. As you noted, you could leave
Site Preferences intact between web browser sessions if you didn't care
about tracking, but the subject of this thread is/was about using
Firefox's inbuilt tracking blocker, so why bother using it if you don't
care about the next-gen method of tracking?

To me, HSTS is a remembrance of Content Advisor in IE: users that
employed CA were relying on sites to rate themselves. Uh huh. Burglars
always leave truthful calling cards after a burglary, too, uh huh. For
compliant clients, HSTS is servers telling client to use HTTPS and TLS.
Why the need for a policy is a site ONLY has an HTTPS page and only
provided TLS connects? That would also force client (well, the users)
to use the proper URL that the site doles out, not what the users think
should be the URL, port, and encryption.

Heard of the HTTPS Everywhere add-on that tried to default the
connections to HTTPS? Yeah, it also had a whitelist (called rulesets
there since they don't just list domains but use rules to define where
and when to apply the forced switch from HTTP to HTTPS). "Enabling
HTTPS encryption automatically on sites that are /*known*/ to support
it". See https://www.eff.org/https-everywhere/atlas/. It did not
always attempt to connect using HTTPS because that did not always work.
A site using HTTP doesn't necessarily have an HTTPS page, especially if
there is nothing to secure there; e.g., it's public information and
there are not accounts there (you need a secure connection and
encryption for a site showing you an ASCII chart). Also see
http://tinyurl.com/oawj5bw, which hints why simply switching from HTTP
to HTTPS (to see if HTTPS was available) introduces a security
vulnerability - and is probably why HTSTS was established as a
server-side policy requesting compliant clients to begin with an HTTPS
connect (although the policy is sent via HTTP so is vulnerable). Yep,
the add-on had a limited whitelist, too, just like HSTS, so very little
of the web was covered.

HSTS is just a server-side policy trying to get clients to use HTTPS if
that is what a site wants you to use when connecting to them. It's
something that good sites use, not malicious sites. Expecting HSTS to
protect you is like expecting sites to rate themselves (for Content
Advisor) or like expecting sites to honor the Do Not Track request in
the HTTP header your client sends to a web server. Yeah, great when
connecting to a good site but is that where you need the protection on
the connection (since once connected the site can still track or attempt
nefarious deeds)?

This thread was about tracking (Firefox's inbuilt tracking blocker due
to inquiry about the privacy.trackingprotection.enabled setting), not
about trying to protect the connection. HSTS does NOTHING to protect
you from tracking. The *connection* security of HSTS relies on a valid
(non-attacked) first visit, your client whitelisting that connection,
and is only about ensuring you get an encrypted session. Tracking is an
entirely separate issue, like a car's door locks are separate of its GPS
vehicle tracking.

Don't you update your programs that have security updates? Sure you do.
So HSTS is waiting for a security update to get past abusing it for
tracking. Actually it will probably dies, like the DNT header, once
clients are written to default to HTTPS connects instead of HTTP and
auto-switching (perhaps with an optional user prompt) to HTTP is HTTPS
results in a 404 error. When clients begin to default to HTTPS (and
only fallback to HTTP on a 404 error) then HSTS will be superfluous
along with its HTTP vulnerability on first visit or with clients not
caching the first-visit result. HSTS is only needed because of the
historical default of clients using HTTP as the initial protocol.

As for tracking, HSTS is irrelevant - other than its vulnerability for
abuse to track. If you use a site's HTTPS page and navigation continues
from that starting point, HSTS isn't involved.

EE

unread,
Dec 4, 2015, 3:58:08 PM12/4/15
to mozilla-sup...@lists.mozilla.org
Clearing Site Preferences is a ridiculous idea. It stores the
exceptions you make to data handling. If you have a problem with popups,
for example, would you want to clear out your cookie exceptions? Would
you want to clear out your passwords?

VanguardLH

unread,
Dec 4, 2015, 6:21:40 PM12/4/15
to mozilla-sup...@lists.mozilla.org
EE wrote:

> Clearing Site Preferences is a ridiculous idea. It stores the
> exceptions you make to data handling. If you have a problem with
> popups, for example, would you want to clear out your cookie
> exceptions? Would you want to clear out your passwords?

Site Preferences, Passwords, and Cookies are separate items in the
clear-on-exit settings.

By the way, I used to clear passwords on exit but then I'd lose the one
needed for Sync to work in Firefox. I had to not clear it, set
passwords to save, log into my Sync account, exit Firefox, and the
reload Firefox to disable saving passwords. So I had passwords not
cleared on exit, no [more] site passwords getting saved, and only the
Sync password was stored in Firefox's password manager. I don't need
nor do I want Firefox to be saving my site passwords. I use an
algorithm that creates strong passwords but which I can remember in my
head. So matter which web browser I'm using and wherever that may be, I
don't to be hauling around a USB stick with passwords or using cloud
storage to keep multiple web browser instances in sync (which won't work
if the host is locked down, anyway). What good is Firefox's password
manager when you use a different web browser on the same host or use
multiple web browsers on different hosts some of which may not be yours?

Yes, I always clear cookies on exit from Firefox. Why wouldn't you
since that an old trick but still a valid trick to track you. A site,
through restrictions in the web browser, cannot read a cookie which was
written for a different domain but it can certainly write a cookie for
another domain. If you happen to visit the other domain, voila, they
can now read that cookie that the prior domain wrote. If a popup is
trying to write a 3rd party cookie, it gets blocked. The popup should
be from the site that I'm visiting, not lying to me by pretending it
comes from the visited site. If the popup writes a 1st party cookie
then it is allowed. Of course, the popup is not writing the cookie
anyway. The document (web page) you visit is doing that. I disallow
3rd party cookies, allow 1st party cookies during a web session, and
clear all cookies on exit from any web browser that I use.

It would be nice to not clear Site Preferences on exit from Firefox.
Some preferences are the zoom level, font selection, where you were last
navigate to within the site, and even login credentials, and session ID
so upon return they would know what you did last time, like if you had
some items added to a wishlist at a etailer (not their checkout cart
since that info is often retained in your account). Mozilla needs to
slice up Site Preferences as to what types of records are stored there
so users can decide which to retain and which to clear on exit instead
of accepting the whole mash up of site "preferences". A whitelist for
HSTS really isn't a preference. It's a connection security issue.

At one time, I used to even disable DOM Storage (local cache) in every
web browser. It is a mega cookie. While .txt cookie files are limited
to 4KB in size, DOM Storage is far larger (5 MB in Firefox, by default).
I would visit some crossword puzzle sites that wanted to download a
table of their matching answers so lookups were local while playing the
puzzle, but they didn't work if DOM Storage was disabled. While DOM
Storage is obviously another cookie-like means to assist in tracking big
time, I figured to disable it. Since later it seemed that DOM Storage
does not provide writing records for an off-domain (3rd party cookie)
then cross-domain tracking wasn't doable. It was more like allowing
just 1st party cookies, and that's okay with me - but get cleared on
exiting the web browser. If a site wants to remember "user data" across
web session, have me login an account there. They don't get to use my
computer for local storage of what should've been recorded up there.

During use:
- Don't save site passwords (I'll use my head-based algorithm).
- 1st party cookies accepted, 3rd party cookies blocked.
- DOM Storage enabled.

On exit:
- Yes, purge cookies.
- No, don't clear passwords (leaving only the Sync password).
- Yes, flush DOM Storage (aka Offline Website Data).
- Yes, flush Site Preferences (until Mozilla decides to slice it up to
provide granular config and addresses the HSTS vulnerability).
- Yes, clear history.
- Yes, clear form data.

Saving site preferences across web browser sessions is a convenience,
not a necessity or even a requirement. Claiming it is ridiculous to
clear it on exit or even enable it in the first place is what is
ridiculous. That's like saying you must use the desktop background that
Microsoft gives you as the install-time default, and claiming anything
else (like no wallpaper) is ridiculous. It's a convenience feature.
Just because a web browser gives you a "feature" doesn't mean you must
use it. I've changed many settings (via config UI or about:config) to
*my* preferences. So have many other web browser users. Site prefs is
just another user-configurable tweak regarding what behavior users want
on a revisit to a site. Too bad it can be abused to assign a unique ID
to you usable to track your navigation across the web.

I'd like to keep site prefs between sessions. I'd like if HSTS couldn't
be used for tracking. Until then, as long as the HSTS whitelist is in
Site Preferences with no option to opt-out of it, I clear all of Site
Prefs on exit. Mozilla doesn't give me a granular choice of what prefs
to retain. It's a mashup bucket of various "prefs" over which I have no
control: all gets retained across sessions or all gets cleared on exit.

»Q«

unread,
Dec 5, 2015, 10:15:40 AM12/5/15
to mozilla-sup...@lists.mozilla.org
In
<news:mailman.8238.144927129...@lists.mozilla.org>,
VanguardLH <V...@nguard.LH> wrote:

> EE wrote:
>
> > Clearing Site Preferences is a ridiculous idea. It stores the
> > exceptions you make to data handling. If you have a problem with
> > popups, for example, would you want to clear out your cookie
> > exceptions? Would you want to clear out your passwords?
>
> Site Preferences, Passwords, and Cookies are separate items in the
> clear-on-exit settings.

It doesn't clear cookies or passwords themselves, but clearing site
prefs does clear any exceptions you've set up; e.g., after clearing
site prefs you will get the 'Do you want Firefox to remember this
login?' prompt even though you've previously selected 'Never Remember
Password for This Site'. (But I'm not clear on why EE thinks it's a
ridiculous idea.)


EE

unread,
Dec 5, 2015, 1:47:39 PM12/5/15
to mozilla-sup...@lists.mozilla.org
If you have a problem with the way passwords are handled, do you also
want to clear out all your cookie exceptions, your image exceptions (if
any), or your exceptions for allowing addons to be installed? I doubt
that. That is why the idea of clearing out all the site preferences at
once is ridiculous.

»Q«

unread,
Dec 5, 2015, 4:41:12 PM12/5/15
to mozilla-sup...@lists.mozilla.org
In
<news:mailman.8281.144934124...@lists.mozilla.org>,
EE <nu...@bees.wax> wrote:

> »Q« wrote:
> > In
> > <news:mailman.8238.144927129...@lists.mozilla.org>,
> > VanguardLH <V...@nguard.LH> wrote:
> >
> >> EE wrote:
> >>
> >>> Clearing Site Preferences is a ridiculous idea. It stores the
> >>> exceptions you make to data handling. If you have a problem with
> >>> popups, for example, would you want to clear out your cookie
> >>> exceptions? Would you want to clear out your passwords?
> >>
> >> Site Preferences, Passwords, and Cookies are separate items in the
> >> clear-on-exit settings.
> >
> > It doesn't clear cookies or passwords themselves, but clearing site
> > prefs does clear any exceptions you've set up; e.g., after clearing
> > site prefs you will get the 'Do you want Firefox to remember this
> > login?' prompt even though you've previously selected 'Never
> > Remember Password for This Site'. (But I'm not clear on why EE
> > thinks it's a ridiculous idea.)
>
> If you have a problem with the way passwords are handled,

I don't.

> do you also want to clear out all your cookie exceptions,

Yes.

> your image exceptions (if any),

Yes. But I think you're talking about some browser other than Firefox
here.

> or your exceptions for allowing addons to be installed?

Yes.

> I doubt that.

Ok.

> That is why the idea of clearing out all the site preferences at once
> is ridiculous.

I'm still not clear. What is why?

[crossposted, followup set to mozilla.general, but please
crosspost and reset followup if a response is going to contain
some Firefox support content]

VanguardLH

unread,
Dec 5, 2015, 8:28:56 PM12/5/15
to mozilla-sup...@lists.mozilla.org
Oh, that's what you meant by ridiculous: there is no granularity to Site
Preferences to let users choose just what in that mashup of multiple
data types that should get cleared. There is way too much dumped under
one option.

There was a "Site Preferences" add-on but got abandoned (Mozilla should
really purge these from their addons site) and it stops working as of
Firefox 42. It gave some of the preferences that you could edit under
the catchall Site Preferences feature.

EE

unread,
Dec 6, 2015, 2:38:12 PM12/6/15
to mozilla-sup...@lists.mozilla.org
At least with Firefox, you can handle different types of data handling
separately. If you want to change the cookie exceptions, you have a way
to do just that by itself. If you want to change passwords, you can do
that easily. If you want to change who is allowed to install add-ons,
you have an interface for that. There is no need for an extension to
handle those things.

0 new messages