"Firefox builds a fence around cookies, limiting them to the site you’re
on so trackers can’t use them to follow you. With early access, you’ll
help optimize this feature so we can keep building a better web for
everyone."

Would you activate this? Why or why not?

On 6/3/2022 8:59 PM, Bob F wrote:
> "Firefox builds a fence around cookies, limiting them to the site you’re on so trackers can’t use them to follow you. With early access, you’ll help optimize this feature so we can keep building a better web for everyone."
>
> Would you activate this? Why or why not?

They know how advertisers track people.

And cookies is just one mechanism.

In fact, with cookies completely wide open, sites
will still say things like "Don't block cookies because
we need those". When in fact, they are actually complaining
about storage areas other than the cookie file. While in
the year 2022, cookies are still set, no web developer really
expects them to be there on a subsequent visit.

Any time someone uses terminology like "cookies", you
know they're full of shit. That's not how browsers are
abused for best persistence.

*******

https://samy.pl/evercookie/

EXAMPLE

Cookie found: uid = undefined

Click to create an evercookie. Don't worry, the cookie is a
random number between 1 and 1000, not enough for me to track
you, just enough to test evercookies.

+-------------------------------+
| Click to create an Evercookie | <===
+-------------------------------+

After clicking the button, do your very best to clean the
caches on the browser. Then, revisit that URL above. Did
the cookie value get "recovered" ? Then you still have some
mechanisms on board which are caching visit info.

pngData mechanism: undefined
etagData mechanism: undefined
cacheData mechanism: 657 <=== missed some cleaning spots
userData mechanism: undefined
cookieData mechanism: undefined
localData mechanism: null
globalData mechanism: 657 <===
sessionData mechanism: null
windowData mechanism: 657 <===
lsoData mechanism: undefined
slData mechanism: undefined

One of the concerns is about "cookie theft" via cross-site exploit.
Even though site "X" may do a lot to store persistent info,
site "Y" may try to steal it.

It's all a bit like leaving an apple pie on
a window sill to cool. And then being surprised
when the pie is gone.

Paul

In article <t7eap7$qm0$2@dont-email.me>
Bob F <bobnospam@gmail.com> wrote:
>
> "Firefox builds a fence around cookies, limiting them to the site you�re
> on so trackers can�t use them to follow you. With early access, you�ll
> help optimize this feature so we can keep building a better web for
> everyone."
>
> Would you activate this? Why or why not?

Even though I'm not a tekkie, I can almost promise you they're lying
one way or another to hide the real truth regarding your being
tracked.

All this tracking crap and AV's filling my machine with all kinds of
intrusive crapola is why I dumped those p.i.a. "security" measures
and simply operate with a freebie sandbox program. Screw worrying
about all that crap, plus it's a hell of a lot cheaper than what all
those "security" proggies cost today. Matter of fact, I'll bet a lot
of those "security" proggies also gather a ton of info about you.

Been operating with this sandbox for years without a problem.

Bob F wrote:

> "Firefox builds a fence around cookies, limiting them to the site
> you’re on so trackers can’t use them to follow you. With early
> access, you’ll help optimize this feature so we can keep building a
> better web for everyone."
>
> Would you activate this? Why or why not?

This has been in Firefox since version 86, but only in Strict security
mode, by default. That is, if you configure Firefox to use Strict
security mode (about:preferences#privacy, Enhanced Tracking Protection
aka ETP) then you already have the Total Cookie Protection (TCP). Most
users don't use Strict mode, and use the Standard security mode which is
the default. All Mozilla is doing is preparing to migrate TCP from
Strict mode to include it into Standard mode, and, of course, first
doing as an experiment to determine what negative impact TCP may cause.
Up to you if you want to participate in the study of the experiment.

Strict mode already provides a warning that some sites may break at that
level of privacy. Mozilla has not yet offered me the TCP feature in
Standard security mode (I have studies disabled in Firefox), so I'll
have to wait until Mozilla pushes TCP into Standard security mode in a
later GA release. Only then can I see if TCP added to Standard mode
also displays the same warning about possibly breaking some sites that
is noted in Strict mode.

I don't see how enforcing the domain restriction on access to cookies
should cause a legitimate failure of a site to use its own cookies. TCP
just ensures the site that created the cookie is the only site that can
access the cookie which was the privacy model intended for cookies in
the first place. In the past, the web client was /supposed to/ ensure
that the domain that accessed a cookie .txt file was the domain that
owned the cookie (which unfortunately may not the same as who wrote the
cookie). It was possible for one domain to open and write to a cookie
file, but the domain listed within the cookie was for another domain, so
a visit to the other domain would allow that other domain to read the
data the prior domain wrote into the cookie.

Firefox added cross-site cookie protection a very long time ago to plug
that privacy hack. That protection has been in Firefox ever since ETP
was added, or maybe even earlier. Mozilla isn't detailed in just how
TCP isolating a cookie into a "domain jar" ensures further privacy.
Just what additional tracking or abuse via cookies gets neutered by
using "jars" to isolate cookies is not well detailed. Possibly a good
privacy feature, but little in-depth information.

This hasn't been important to me due to how I configure Firefox to purge
ALL locally cached data on its exit (which also thwarts HSTS super
cookies), and I don't leave Firefox running between uses. When done
using Firefox, I exit it which purges all locally cached data. I do not
leave Firefox loaded until its next use.

https://blog.mozilla.org/security/2021/01/26/supercookie-protections/:
Firefox 85 partitions all of the following caches by the top-level
site being visited: HTTP cache, image cache, favicon cache, HSTS
cache, OCSP cache, style sheet cache, font cache, DNS cache, HTTP
Authentication cache, Alt-Svc cache, and TLS certificate cache.

https://www.theregister.com/2021/01/27/firefox_85_crumbles_supercookies/
Firefox 85 fights back by using “a different image cache for every
website a user visits.

Perhaps that means also HSTS super cookies aren't a problem anymore, and
why the demo site by RadicalResearch disappeared to test if HSTS super
cookies could still be used for tracking (which previously to thwart
required flushing the site preferences in Firefox, like on its exit).
Looks like the "cookie jar" scheme is another isolation aka partitioning
scheme to prevent abuse of that type of local storage. FF 85
"partitioned" lots of locally cached data to restrict what domain can
access what locally cached data, and FF 86 added cookies to the same
type of protection, but only in Strict mode. Now Mozilla wants to add
TCP to Standard privacy mode. "Systematic network partitioning makes it
harder for trackers to circumvent Firefox’s anti-tracking features, but
we still have more work to do to continue to strengthen our
protections." Looks like the "more work" included partitioning of
cookies, too, and not just in Strict mode.

The protections added in FF 85 were a good thing. I don't see migrating
TCP from Strict to include in Standard mode as a bad thing. The only
sites that might puke on the isolation of their cookies are those that
are trying to abuse their intended purpose. I'm using Strict mode for
now which gives me TCP. Unless it severely impacts my web browsing,
I'll stick with Strict mode for now, and won't care if TCP gets added to
Standard privacy mode.

Client-side protections have no effect on sites that cooperate with each
other to share visitor data. Nothing client-side can deter server-side
data sharing. It's easier to abuse cookies to transport data from one
site to another. Server-side processes to share data is a bit more
difficult to setup, but not when the libs and scripts are readily
available to build that data transport between servers.