[HN Gopher] Firefox rolls out Total Cookie Protection by default...
___________________________________________________________________
Firefox rolls out Total Cookie Protection by default to all users
Author : BoumTAC
Score : 703 points
Date : 2022-06-14 13:16 UTC (9 hours ago)
(HTM) web link (blog.mozilla.org)
(TXT) w3m dump (blog.mozilla.org)
| stvnbn wrote:
| I see this and I ask why it hasn't been this way since the
| beginning? why it took so long to have it?
| Terry_Roll wrote:
| I think OS Telemetry will see to it that its not private!
|
| However this will make it easier than it currently is, to work
| out who is data sharing illegally.
| Sytten wrote:
| Does someone have a link about the technical details for
| developers that it might affect (SSO, cookies for subdomains,
| etc). This is just a marketing post.
| wisniewskit wrote:
| There is some detail here: https://developer.mozilla.org/en-
| US/docs/Web/Privacy/Storage...
| GordonS wrote:
| Also keen to see something like this. Firefox surely
| (hopefully!!) isn't going to block cookies across subdomains,
| or a whole bunch of things are going to break. Would love to
| see confirmation though...
| flipbrad wrote:
| Cool. Just a heads' up that I had to disable it on Zendesk and
| Asana so they could talk to each other - you might experience
| similar issues.
| beej71 wrote:
| When I was blocking 3rd-party cookies on Chrome, I couldn't log
| into the IRS site. I figure that might happen here, too.
| shrikant wrote:
| Can concur, this broke Zendesk integration with Jira so I had
| to disable it for our Jira setup.
| zzyzxd wrote:
| Zendesk has been like this for me since forever. Every time I
| need to use it to talk to a vendor, I roll my eyes for 2
| seconds and open my backup browser which does not have 3rd
| party cookie restriction.
| lemoncookiechip wrote:
| EDIT: Nvm, I found it. Thank you.
| gbN025tt2Z1E2E4 wrote:
| This will only further entrench the big players (google,
| facebook, etc) while making it impossible for new & small players
| to compete. All of the services the big players offer effectively
| make working without universal cookies trivial.
|
| For the small players though, without massive ad-supported
| service offerings like Gmail, Facebook (as a platform), etc, this
| will screw them completely.
|
| Mind you, I'm a HUGE privacy advocate, so I like the new Firefox
| functionality... but the unintended side effects cannot be
| ignored.
| ddtaylor wrote:
| Do we want anyone tracking us? I don't really care about the
| _size_ of something that is tracking me - I care about the
| tracking itself.
| rcMgD2BwE72F wrote:
| Firefox really needs to implement two features:
|
| 1. Cookie Auto-Delete (see https://github.com/Cookie-
| AutoDelete/Cookie-AutoDelete/wiki/...), where cookies and local
| data are automatically deleted some time after closing the tab.
| You can, of course, whitelist Websites to exclude them.
|
| 2. Firefox multi-container extension, to assign some websites
| (domains and subdomains) to a container by default so that you
| can visit some specific Google sites without being logged in
| (e.g Web search, News, Maps...) but still open Gmail and be
| connected to your account.
|
| You can make this more intuitive and combine that in a single
| button: "Do not forget. Optionally, open website in
| <container>".
|
| This would drastically level the playing field, as one can
| continue to use some Google/Apple services for work (e.g Play
| developers console, Google calendar...) but all visit to other
| properties would not be tracked. No need to switch between
| browsers, profiles or containers, this is automatic.
|
| I've been using this set up for years now, and it works
| perfectly - just add uBlock and I don't care about cookies, and
| you'll ever see an ad or a cookie prompt ever again. Perfect.
| pid-1 wrote:
| (1) totally exists, that's always how I configure all my FF
| installs. You also can add exceptions, although I don't use
| this feature.
| ridgered4 wrote:
| Unless I'm missing something, this only triggers on browser
| close. I sort of agree with the proposed tab closer with
| timer trigger idea, since I almost never close the browser
| on my main machine.
| drexlspivey wrote:
| Is that basically the PrivacyBadger plugin integrated into
| Firefox? Can I uninstall it now?
| ghostwords wrote:
| Hi, Privacy Badger dev here.
|
| Total Cookie Protection helps by keeping all third-party
| cookies isolated to the site they were set on. This means
| tracker domains will no longer get their cookie identifiers
| persisted across different sites.
|
| However, tracking isn't limited to cookies. If unblocked,
| trackers can still use techniques like browser fingerprinting
| and cookie syncing. They could also just track you via your IP
| address, or, most likely, via some combination of different
| techniques.
|
| Trackers can also collect sensitive information such as your
| email address, or even become vectors for delivering malware.
|
| Outside of privacy/security concerns, unblocked trackers can
| slow down websites and waste your bandwidth.
|
| To learn about how Privacy Badger works, visit
| https://privacybadger.org/#faq
| letmeinhere wrote:
| Does this obviate the need for [Facebook
| Container](https://addons.mozilla.org/en-
| US/firefox/addon/facebook-cont...)?
| wisniewskit wrote:
| Facebook Container is a stricter form of protection for
| Facebook specifically, so no, you should continue using it if
| you're interested in isolating Facebook.
|
| Total Cookie Protection is about isolating third party
| cookies/web storage, without breaking as much of the web as
| simply blocking third party cookies does.
| craigmart wrote:
| What kind of protection does Facebook Container have other
| than deleting cookies outside of the container?
|
| For my case Total Cookie Protection is enough, but if you
| want the same protection of Facebook Container for every
| website (i.e. session cookies which are deleted each time you
| restart the browser) you can install Cookie AutoDelete or use
| the built-in option to delete cookies at restart
| (whitelisting websites where you need permanent cookies).
| wisniewskit wrote:
| It also blocks network requests made by third-party sites
| to FB. So unless you're already running ETP with the
| content blocker on (strict mode, private browsing mode) or
| another ad blocker kind of addon that also blocks FB
| strictly, then that's an additional measure.
| nightpool wrote:
| In which way is Facebook Container "stricter"? Are you aware
| of any potential third-party tracking vectors that Firefox
| does not currently mitigate, but Facebook Container does? The
| only possible difference I can see is that Facebook Container
| keeps sites "shared" via Facebook inside of the Facebook
| Container, so if you navigate from e.g. Facebook -> CNN,
| facebook can only see the history of CNN pages you've visited
| inside of the Facebook container. Otherwise, clicking on a
| share link from Facebook (with, e.g., a unique query
| parameter) would allow Facebook to correlate their CNN.com
| facebook cookie with their Facebook.com cookie, getting
| (retroactive) access to _all_ of your CNN history. So maybe
| that 's one reason to continue to use Facebook Container
| ape4 wrote:
| Yeah, its not really stricter but its different /
| complementary. Together Facebook Container and Total Cookie
| will stop more cookies.
| wisniewskit wrote:
| I'm not sure if it offers any stricter cookie-specific
| behavior, but it also blocks network requests Facebook
| makes on third party pages. So unless you're running in ETP
| strict/custom mode with the content blocker on, or in
| private browsing, or maybe an ad blocker that also blocks
| FB in general, that's probably worth noting.
| mello151 wrote:
| You asked what I was wondering except I was thinking of the
| [Multi-Account Containers](https://addons.mozilla.org/en-
| US/firefox/addon/multi-account...)
|
| I think Cookie Protection does solve the problem that I used
| the containers for. I wasn't really using it to keep accounts
| separate, per se, but more to keep companies like Google from
| snooping and sneaking peeks at my other cookies.
| [deleted]
| DoubleGlazing wrote:
| I know Firefox has a small market share, but this is the sort of
| feature other browsers may adopt. Maybe not the big boys like
| Chrome or Edge, but I could see all the niche privacy focused
| browsers implementing it and maybe even Safari given Apples
| claims to support user privacy. If a certain percentage of
| browsers started to use similar functionality I could tracking
| companies starting to develop countermeasures.
|
| In fact I've already encountered one site that gave me a popup
| telling me to enable third party cookies. It was one of those
| dodgy sites that scrapes and copies Stack Overflow content and
| the JavaScript that enabled it was very clunky - but it worked.
| I'm surprised there aren't more websites already doing something
| similar.
| alasdair_ wrote:
| > Maybe not the big boys like Chrome or Edge
|
| Firefox has essentially the same market share as Edge.
| jaywalk wrote:
| This is a fantastic way to do this. I wish Safari worked the same
| way instead of just completely blocking third-party cookies.
| CharlesW wrote:
| Can you explain why? Apple did this two years ago and I haven't
| personally seen any side effects, but Safari's also not my
| primary browser.
| jaywalk wrote:
| It makes my life harder as a developer. I've got some widgets
| (hosted by me) that are embedded on my customer's websites,
| and because of Safari I can't use cookies for things like a
| shopping cart. I have no need for the cookies to be
| accessible from another website, even if it's got the same
| widget embedded, so this implementation by Firefox fits my
| use case perfectly. Unfortunately that doesn't change what
| Safari does, so it doesn't help me.
| CharlesW wrote:
| Ah! I can see how that'd be a PITA, thanks for explaining.
| hericium wrote:
| About 90% of Mozilla's income comes from Google.
|
| If this would prevent tracking, Google would not allow Mozilla to
| release it.
| ars wrote:
| Google's income will not change if they don't track.
|
| If they can't track, then each ad has less value. But then the
| advertiser has more budget available to spend on advertising.
|
| Net result is no change for advertisers, or Google. But they
| users will see more, less targeted ad.
|
| So that's my prediction as the result of this: We'll have more
| ads, but each will be less personalized.
| [deleted]
| ajvs wrote:
| Google would still have to fund Mozilla to prevent more
| anticompetition charges being levied their way regardless.
| uBlock Origin is a far greater threat since it blocks the more
| powerful JavaScript-based tracking, and you can see exactly how
| that's being managed with the move to Manifest v3.
| dahart wrote:
| When will the browsers take care of handling the cookie options
| for all the sites, so I can declare my preferences once and
| everyone stops putting up a popup? Surely this is already in the
| works?
| 6510 wrote:
| Right, the consent window should have been a browser thing so
| that it is always the same and so that it follows the laws and
| cant involve dark patterns.
|
| By reading this message you agree with it.
| fleddr wrote:
| The answer is similar to the DNT (do not track) debacle.
|
| When you give users a clear, informed, singular choice that
| would be sticky across their entire web/app experience, the
| choice in itself essentially becomes obsolete. Since pretty
| much nobody opts-in.
|
| You saw the effect with Apple's new "do you want to be
| tracked" permission, which has a disastrous impact on
| Facebook. Consider that this is still a per-app permission,
| imagine the impact when its a single permission across all
| apps.
|
| As users we may say "good" and "this is what we want", but I
| don't think we can truly oversee what impact that would have.
| sdze wrote:
| Firefox + ublock origin is my trusted porn browser.
| Sohcahtoa82 wrote:
| I hope you add Incognito Mode to that.
| sharno wrote:
| Wish there was a feature or extension to auto accept cookie
| banners on websites
| dev_tty01 wrote:
| Is this better or worse than Safari's "Prevent cross-site
| tracking" feature?
|
| https://support.apple.com/guide/safari/prevent-cross-site-tr...
|
| It appears Safari is just blocking the cookies, while Firefox is
| isolating the cookies. I guess Safari has to keep track of who to
| block while Firefox just isolates everybody. Are there other
| benefits to the Firefox approach?
|
| Frankly, I have a hard time understanding why this Cookie Sandbox
| approach wasn't implemented a long time ago. I get that 25 years
| ago we weren't concerned about privacy, but there has been plenty
| of time to fix this. Advertiser influence?
| lmkg wrote:
| I believe this is _part of_ the "Prevent cross-site tracking"
| feature. I do know that Webkit/Safari has had this feature for
| a while now, under the name "Partitioned storage." Safari has a
| handful of other policies under the "Intelligent Tracking
| Prevention" banner, like blocked or ephemeral cookies for non-
| first-party domains.
|
| Firefox is playing catch-up with this feature. The announcement
| says "...making Firefox the most private and secure major
| browser _available across Windows and Mac_. " Note the part
| that I've emphasized.
| 8bitsrule wrote:
| 3 hours later it says "... across Windows, Mac and Linux."
| mmis1000 wrote:
| Sites that use cross site resource will still work. Except the
| cross domain resource provider will always see the same domain
| coming to get resource.
|
| For example, if you are on Site A and use cross site resource
| from Site C. The site C will get a cookie C('A)
|
| And in another day, you visited a Site B that also use resource
| from Site C. The site C get a cookie C('B).
|
| And C('A) != C('B)
|
| Although these cookie are both issued by Site C. They are
| associated to different first party domain and can't be
| connected directly.
|
| It's just like you open a private browser session for every
| site you visit.
|
| I think it is a extension usage from Firefox's container
| technology.
| dev_tty01 wrote:
| Thanks. In case anyone is interested, I looked around a bit
| more and found these descriptions of Safari's (Webkit)
| intelligent tracking prevention starting from 2017 (in
| reverse chronological order):
|
| Safari Tracking Prevention background:
|
| https://webkit.org/tracking-prevention/#intelligent-
| tracking...
|
| Blog posts about tracking prevention updates:
|
| https://webkit.org/blog/11545/updates-to-the-storage-
| access-...
|
| https://webkit.org/blog/10218/full-third-party-cookie-
| blocki...
|
| https://webkit.org/blog/9521/intelligent-tracking-
| prevention...
|
| https://webkit.org/blog/8613/intelligent-tracking-
| prevention...
|
| https://webkit.org/blog/8311/intelligent-tracking-
| prevention...
|
| https://webkit.org/blog/8142/intelligent-tracking-
| prevention...
|
| https://webkit.org/blog/7675/intelligent-tracking-
| prevention...
|
| Here is their tracking prevention policy definition:
|
| https://webkit.org/tracking-prevention-policy/
| grishka wrote:
| Why not abolish third-party cookies altogether? There are very
| few good uses for them.
| celestialcheese wrote:
| Chrome has on the roadmap to do exactly this. [1]
|
| Turns out, Getting rid of 3rd party cookies concentrates power
| in the ad world in the hands of those with the most 1st party
| data (and active session cookies). Google, Facebook, Amazon and
| Apple. [2]
|
| The tracking debate is contentious and has a lot of folks on
| here who are privacy maximalists, and I'm not trying to debate
| the ethics of ads.
|
| But in terms of utility, 3rd party cookies are the backbone of
| ad-tech auctions and targeting, and currently give the non-
| Goog/FB/Amazon ad providers a way to compete on performance
| advertising.
|
| Digital ad markets are expected to be nearly $565b this year,
| and the Tri-opoly of Google/FB/Amazon have 68% of the market.
| 32% of the market depends on 3rd party cookies to have a chance
| at competing. [3]
|
| 1 - https://privacysandbox.com/intl/en_us/open-web/#how-works-
| on... 2 - https://www.siliconrepublic.com/business/googles-
| privacy-san... 3 - https://www.emarketer.com/content/google-
| facebook-amazon-acc...
| exyi wrote:
| You can turn them off. However, most single-sign-on stuff will
| break without them :/
|
| (at least MS accounts just don't work)
| grishka wrote:
| Single-sign-on stuff can be fixed by redirecting through the
| authenticator domain and passing the token or whatever back
| as a url parameter.
|
| > You can turn them off.
|
| Of course I did, long ago. The issue is that they're on by
| default. And defaults matter a lot because most people don't
| change them.
| agluszak wrote:
| Why weren't separate cookie jars the default in the first place?
| I know that browsers other than Firefox have no real incentive to
| protect your privacy, but I'm wondering why cookies were designed
| to be shared among different pages in general
| pwg wrote:
| Cookies first appeared in Netscape on Oct 13, 1994 [1]. In 1994
| the 'web' was a very different place and the current
| environment of web tracking and invasive advertising companies
| simply did not exist. And no one saw the privacy invading
| potential at the time.
|
| [1] https://en.wikipedia.org/wiki/Browser_cookie#History
| PaulDavisThe1st wrote:
| > And no one saw the privacy invading potential at the time.
|
| Maybe not the privacy invasion potential but ... As we got
| started building amzn in the fall of 94, it was a no-brainer
| decision to _not_ use cookies even though they were just
| arriving. The controversy around the idea was intense and it
| was far from clear that they would be a success as a
| technology. It is likely true that there was more attention
| being paid to the "what? it lets a remote server create a
| file on my driver?" angle than the privacy one.
| shubhamkrm wrote:
| How did you manage session information without using
| cookies?
| PaulDavisThe1st wrote:
| http://yourdomain.com/path/to/something?SESSION=af2828c11
| 9ae1
|
| and yes, all URLs in every page were rewritten during
| page generation to include the session ID.
| marshray wrote:
| Didn't that break bookmarks?
| PaulDavisThe1st wrote:
| This was 1994. Web technology was barely even emergent.
| jeltz wrote:
| Yes, but someone here quoted an RFC showing that while people
| may not have understood this in 1994 they did in 1997. And
| now 25 years later the privacy issue was fixed.
| dec0dedab0de wrote:
| The web was designed to be highly interconnected. Deep linking
| is a feature. Cookies are set via headers. If you load an image
| from another domain, the headers from that domain could set
| their own cookies, and your browser will give each domain every
| cookie it has set.
|
| That is, cookies aren't shared, they're locked down to the
| domain that set them. It's just that some domains have content
| loaded by millions of pages. This change won't protect you much
| if you have a relatively stable IP address without many users
| on it, because your IP is still in the third party domains
| logs. This welcome change makes it harder to differentiate
| people on the same IP, or to track a browser as it changes IPs.
|
| As I'm typing this, I'm remembering how helpful IPv6 is for
| people who want to track everyone.
| tialaramex wrote:
| If you need Onion Routing then you need Onion Routing. IPv6
| Privacy Addressing gives you roughly the same properties you
| had with IPv4 NAT except now when you _did_ want a stable
| address you 've got one.
|
| Multi address is much healthier in IPv6, so it's reasonable
| for your browser to even spin up an address associated with a
| Porn tab, and then destroy it again when you close that tab,
| while still using your other IPv6 address for a post you make
| meanwhile to Hacker News. It's also reasonable (while it was
| often likely to cause mysterious problems in IPv4) to give
| your local web server a long-lived IPv6 address while your
| web browser's address changes every hour.
| diea wrote:
| Hmm... I think IPv6 might be actually better. Apple for
| example will generate and use a temporary IPv6 which changes
| every few hours to protect your privacy.
| Xylakant wrote:
| Cookies were invented at Netscape like 25 years ago, nobody
| considered the current situation.
| _jal wrote:
| Yes they did. It was foreseen, look at the sibling comment
| where the issue was discussed in the spec. They just punted,
| just like they did with https and CAs. (And Javascript, for
| that matter, although that's less directly security-related.)
|
| The concern was being first to market, not with solid
| engineering.
| ravenstine wrote:
| There are legit cross-domain use cases. A good example is how
| someone here mentioned (comment seems deleted though) account
| sessions being shared between Atlassian products like JIRA and
| BitBucket.
|
| The problem with that is domains are a poor way of representing
| ownership that can be trusted. If the web was rebuilt from
| scratch, a better approach might be to allow cookies to be
| shared between secure sites using the same certificate. But
| that adds more complexity that I'm not sure is worthwhile. The
| web can absolutely get away with not having shared cookies.
| notriddle wrote:
| There's no technical reason why this has to be hard. If jira
| was at jira.atlassian.com and bitbucket was
| bitbucket.atlassian.com, they would have the same origin,
| plus they would make the relationship between them visible to
| any moderately savvy user. It's only complicated because they
| allow their marketing dept to make it complicated.
| filmgirlcw wrote:
| I think that's unfair. By tying things to domains that way,
| you also make it potentially difficult to change URL
| structure (look at how long the various go.com domains
| lasted across all Disney/ABC properties. I know of teams
| that had very real problems years later b/c the infra was
| still based on domain stuff that was setup 15 years prior
| when the parent company thought internet portals were worth
| spending billions on), not to mention if you want to spin-
| off or sell an asset. Or if you acquire an asset!
|
| To say nothing of SSOs, where you might not want to carry
| your login across, but you'd like to have the option of
| saying "yes, I'd like to use this account here too" and
| then authenticate.
| Macha wrote:
| Also if you sign into Google, notice you bounce through
| YouTube for what I assume to be similar reasons
| oefrha wrote:
| You do realize acquisitions occur?
| notriddle wrote:
| So use a 301 redirect.
| abdullahkhalids wrote:
| Business operation complications are not a valid reason
| for the violation of the rights of humans.
| dylan604 wrote:
| you do realize reorganization occur after acquisitions?
| vman81 wrote:
| There are also legit use cases for leaving all your doors
| unlocked. But they usually aren't really worth considering
| when you are installing your doors/locks.
| Groxx wrote:
| Isn't this solved with a login redirect? Just return a signed
| ID and set up cookies on the other end with that. Granted,
| it's one more redirect per domain than before per login
| period, but that's hardly onerous.
|
| Domains that want to collaborate together can still do so.
| layer8 wrote:
| > allow cookies to be shared between secure sites using the
| same certificate
|
| Or maybe encrypting cookies using the site certificate, which
| would still allow cookies to be shared with domains having a
| different certificate, but the server needs the correct key
| for decryption.
| exo762 wrote:
| Ciphertext leaks information via its size and its presence
| / absence.
| dylan604 wrote:
| yeah and so? how is this information useful? if the
| actual useful information is encrypted, then size is
| meaningless as it is just random text until decrypted.
| presence/absence? you have a cookie or you don't?
| recursive wrote:
| You say the size is meaningless. But sometimes it may
| actually be meaningful. And presence/absence is
| information also. Not much, but it definitely exists.
| dylan604 wrote:
| In what way? If I'm storing 255 bytes of
| username/email/credentials/settings/etc, but pad in some
| fun way to 512 bytes prior to encryption, what in the
| world does knowing that the cookie is 512 bytes do you?
| You have no idea what data is stored. You don't know if
| there are 512 bytes of actual data, 128 bytes with lots
| of fluff, or anything at all other than 512 bytes. Hell,
| it could be 0 bytes of data and 512 bytes of random data
| that I submit to every single person that visits the site
| just to fuck with people like you! You seem like you need
| something to do ;-)
| recursive wrote:
| If the contents of the cookie is a JSON array of recently
| viewed items, then the size is correlated to whether I've
| been actively viewing items recently.
|
| Adding random padding makes it harder to get a signal,
| but with a high enough sample size, it's still possible
| to get some information. If you always pad to a fixed
| size, then there's probably no useful information.
|
| At the moment, I think I have enough to do, but I'll
| probably be looking for something new in the next few
| weeks. Got any novel single player video game
| recommendations?
| dylan604 wrote:
| >If
|
| That's are really big word in that sentence. You have
| _NO_ idea, like 0, what is stored in an encrypted cookie.
| To even think you do is just pure folly.
| [deleted]
| c0balt wrote:
| While I'm not a friend of tracking via cookies nor tracking in
| general there is some utility there. For example SSO may be
| done over cookies, like oauth iirc. I don't know of many other
| use cases though that couldn't be contained with header etc.
| tyingq wrote:
| RFC2109, from 1997, had this:
|
| _8.3 Unexpected Cookie Sharing
|
| A user agent should make every attempt to prevent the sharing
| of session information between hosts that are in different
| domains. Embedded or inlined objects may cause particularly
| severe privacy problems if they can be used to share cookies
| between disparate hosts. For example, a malicious server could
| embed cookie information for host a.com in a URI for a CGI on
| host b.com. User agent implementors are strongly encouraged to
| prevent this sort of exchange whenever possible._
| hedora wrote:
| It's really weird that they claim there privacy work started
| in 2015. Netscape Navigator add cross site cookie blocking at
| some point, and firefox has always (?) had it.
|
| The innovation here seems to be that they further partition
| by the URL in the address bar.
|
| It's frustrating that browsers have been fighting and losing
| this war for 25 years. (Presumably they still don't block
| browser fingerprinting, so sites will just move to that
| instead...)
| CodesInChaos wrote:
| Internet explorer used to ask the user before saving
| cookies.
|
| And the server had to declare what cookies would be used
| for in machine readable form (P3P) which the browser used
| to decide if it want to allow the cookie (google blatantly
| lied)
|
| And more recently DNT.
|
| A graveyard of failed attempts at improving privacy
| nieve wrote:
| FIrefox used to ask, then it would ask if you set the
| right preference, and then it stopped asking entirely. I
| was very disappointed in them.
| staticassertion wrote:
| It's not possible to block browser fingerprinting since
| it's a range of techniques and heuristics based on numerous
| features. There's no "turn off fingerprinting" button you
| can just press.
| sillysaurusx wrote:
| Whonix says hello. https://www.whonix.org/
|
| I was planning to use it exclusively when I was working
| on a system to fight cartels, so I got pretty deep into
| these kinds of questions. Whonix has its own problems but
| it's the best solution available.
|
| The communities are interesting too. One fellow was
| trying to download map data, which confused me initially.
| Why was he so fixated on maps? It's because if you're in
| the middle of a warzone, there's obviously no cell
| service, and it might be a few weeks before you reach an
| area with wifi. Remarkably prescient given that this was
| 2013 or so.
|
| But you're right in general that there's no way to do it
| that isn't a pain in the ass for most people. "I can't
| resize my browser window? Really?"
| staticassertion wrote:
| I'm sure that the techniques used in Whonix can reduce
| the number of valuable features used in fingerprinting
| but you can't "solve" fingerprinting without every single
| user switching over to something like this.
| mdp2021 wrote:
| It is possible to enable obstacles to fingerprinting.
|
| In Firefox, it is configuration entry
| privacy.resistFingerprinting
|
| Some details (the list is not exhaustive):
|
| > _* Your timezone is reported to be UTC; * Not all fonts
| installed on your computer are available to webpages; *
| The browser window prefers to be set to a specific size;
| * Your browser reports a specific, common version number
| and operating system; * Your keyboard layout and language
| is disguised; * Your webcam and microphone capabilities
| are disguised; * The Media Statistics Web API reports
| misleading information; * Any Site-Specific Zoom settings
| are not applied; * The WebSpeech, Gamepad, Sensors, and
| Performance Web APIs are disabled, etc._
| roughly wrote:
| I've got this enabled - the only one that's been more
| than a mild pain in the ass is the UTC timezone change.
| Always takes a minute to remember why a site is telling
| me my appointment is at 2:30 in the morning.
| jszymborski wrote:
| Is there a way to reset the timezone but have all the
| other protections? Timezone provides pretty low
| information relative to the pain it causes me when I show
| up to my meeting 5 hours later.
| zagrebian wrote:
| Why didn't cars have safety belts in the first place?
| pas wrote:
| the web was directly bolted on top of the classic client-server
| network model. there was no concept of a website, just a bunch
| of requests needed to render whatever the markup (and the
| dynamic scripting stuff) wanted.
|
| the interaction of those is completely left as an exercise to
| the (standards) readers. initially only remote code execution
| was a problem (eg. cross-site scripting), then the usual cross-
| site request forgery problems. and sure, there was all the
| usual gimmicks with list of sites you probably visited because
| it was possible to fingerprint by CSS plus exploiting cache
| timings.
|
| initially framesets were all the jazz. you got free hosting and
| the provider just put your stuff inside a FRAME and the ad went
| above in a different frame.
|
| serious sites had money to pay for hosting and SSL certs. and
| even if someone stole some credit card numbers the solution was
| easy, just use paypal!
|
| privacy was seen as something to think about only when someone
| asked you a/s/l (age, sex, location), so basically when
| interacting with other humans in chat rooms (or on forums).
|
| ...
|
| of course slowly but surely software (more exactly the
| Internet) is eating the world. being online is the default.
| Alphabet, the 8th on the Fortune 500 list doesn't even have
| brick and mortar stores (oh well, there's one in NYC and during
| this year's Google I/O they announced the second, also in NYC).
| dahart wrote:
| > Why weren't separate cookie jars the default in the first
| place?
|
| Tracking today is an interaction between cookies and pages, not
| really because cookies were designed to be shared between
| domains. Because of that, ads on web pages are a reason that
| information gets shared across sites. Any ad or other iFramed
| content that's served on a site can get the domain name of
| where it's be served from and then access the iFrame domain's
| cookies, which enables tracking.
|
| The cookie jar language might be a tiny bit
| oversimplifying/confusing in the sense that cookies are already
| separated from each other according to the cookie's domain -
| they're already in separate jars in a way, and this feature is
| changing how they partition the jars. Assuming even the most
| strict privacy settings, tracking cookies and scripts are often
| in iFrames and may not have the ability to directly read other
| cookies from the web site in your URL bar, and the web site
| might not be able read the tracking cookies. It's not that
| cookies themselves are being shared per se. It's that (say)
| Facebook is allowed to put an iFramed tracker on some site, and
| Facebook can then get a tracking blip when you visit that site
| and add it to a Facebook-only cookie. Total Cookie Protection
| is going to put cookies that only Facebook can see in a
| different jar for each separate site you visit, making it so
| that Facebook can't read it's own cookies across different
| sites.
| nybble41 wrote:
| > Total Cookie Protection is going to put cookies that only
| Facebook can see in a different jar for each separate site
| you visit, making it so that Facebook can't read it's own
| cookies across different sites.
|
| Won't this break some basic features like being logged in to
| Facebook (or similar services, e.g. Disqus) for the purpose
| of embedded comment sections on other sites? They don't use
| cookies only for tracking buttons after all. It would be...
| annoying... for every site to require a separate login.
| dahart wrote:
| Yes, it might break embedded features like comments unless
| you whitelist the allowed uses. I would assume Firefox
| handles this thoughtfully, but I haven't tried the new
| cookie jars yet, so I don't know what the UI looks like or
| allows.
| nybble41 wrote:
| Elsewhere they mentioned that there are exceptions for
| "popular" SSO systems, but I have a hard time imagining
| any exception that would allow a shared login for
| Facebook comments while blocking Facebook tracking across
| sites. These are essentially the same mechanism.
| datavirtue wrote:
| Why can't the browser can handle the login?
| Agamus wrote:
| The solution still seems to be to:
|
| 1. Use Firefox, block .js by default, and selectively allow.
|
| 2. Set browser to block cross-site cookies, and to purge all
| cookies when closing browser.
|
| 3. Avoid tabbed browsing, and restart browser after using a
| website.
|
| I've been doing this since about 2006. It's inconvenient, but
| gives some peace of mind.
| galaxyLogic wrote:
| How about just using the "Delete Cookies" -feature of the
| browser? And maybe there's a plugin that would make that
| one-click process?
| dahart wrote:
| That'd certainly prevent most tracking, yeah. This new
| Firefox feature should make #2 and #3 unnecessary.
|
| I think this feature by Firefox is great, and privacy
| options are getting objectively better, if slowly. But the
| cynic in me guessing that server side tracking methods are
| going to start getting secretly better, if they haven't
| already.
| madacol wrote:
| I'm not sure about #3. there's still sessions,
| localstorage, indexDB, etc
| MauranKilom wrote:
| 2 and 3 are "browse in private mode", to make thing simple.
| KatrKat wrote:
| The solution is political action. You're describing a
| workaround that only a few of the most concerned people
| will be willing to use.
| Agamus wrote:
| Agreed, the solution is to work with others toward a
| solution.
|
| In my defense, I don't see it as a workaround - I
| wouldn't use it any other way.
|
| There was a time when one didn't need to do this, but the
| internet has become more cumbersome to use. Easy-
| breezy... just make it muscle memory, and don't look
| back!
| kevin_thibedeau wrote:
| I'd replace 3 with self-destructing cookies.
| madacol wrote:
| To reduce the burden use extension Temporary containers, so
| each tab opens into a clean environment.
|
| And use Firefox container to auto-open domains on specific
| containers where you want to keep sessions or have a shared
| profile among various domains
| datavirtue wrote:
| The site owners place the Facebook crap on their
| site...therefore enabling Facebook to track you across any
| and all sites that embed the tracker. Facebook and other
| tracking companies are so ubiquitous (most sites have
| multiple trackers) that they end up getting a feed of Sally's
| activity across the web...via the cookie loophole.
|
| Cookies need restricted to the URL in the address bar.
| Anything else is like a side effect or unintended and
| woefully non-transparent consequence of sneaky fucks
| harvesting your information (clicks, keystrokes, and
| metadata) via JavaScript and cookies.
| mastermedo wrote:
| I remember losing a bet a while back, because I was naive enough
| to think that was how cookies worked in the first place. Why did
| other sites ever have access to cookies they didn't create was
| beyond me.
| Sohcahtoa82 wrote:
| > Why did other sites ever have access to cookies they didn't
| create was beyond me.
|
| They don't.
|
| If you go to example.com, and it loads an ad on tracker.com,
| then tracker.com will create a cookie. example.com WILL NOT be
| able to see that cookie. Likewise, if you were to log into
| example.com, tracker.com WILL NOT see the example.com cookie.
|
| What happens (Without third party cookie blocking or FF's TCP)
| is if you then go to anothersite.com, and it also loads an ad
| from tracker.com, then the same cookie sent to it while
| visiting example.com will be sent, resulting in tracker.com
| knowing that you visited both sites. The admins of both
| example.com and anothersite.com will then be able to look at
| analytics and see that the visitors of their site also visit
| the other.
|
| At no point is one site ever able to see a cookie they didn't
| create. Otherwise, this would be a MASSIVE security hole as it
| would make session stealing trivial.
|
| However, a site _is_ able to see a cookie they created _while
| visiting another site_.
|
| Maybe this is what you meant, but it wasn't entirely clear.
| dangrossman wrote:
| You don't need access to cookies you didn't create to do cross-
| site tracking.
|
| Think: Disqus or Facebook comments at the end of articles,
| which used to be pretty ubiquitous. You'd be logged in and able
| to comment on any website using a cookie set by Disqus or
| Facebook, so you wouldn't have to log in or register on each
| individual website.
|
| This Total Cookie Protection will break that. Your Disqus-set
| login cookie set on site A won't be visible when you're on site
| B, so you won't be logged in to Disqus there.
| lucasyvas wrote:
| How does this relate to the existing tracking protection settings
| - should I turn off "block all third party cookies"?
|
| That setting breaks a few things, but mostly works OK. I'm
| confused which protection level this new capability corellates
| to.
| lmkg wrote:
| This is strictly in-between allowing third-party cookies and
| blocking them. They are allowed, but isolated to prevent data
| sharing.
|
| Previously: Site A has a facebook Like button, which iframes in
| facebook.com and sets a third-party cookie for facebook.com.
| Site B does the same. Site B can see that you previously
| visited Site A, and if you have a Facebook account, then
| Facebook can connect your browsing activity on both A and B to
| that account.
|
| New feature: Site A's Facebook Like button iframes in Facebook,
| and sets a cookie on facebook.com. This is a _different_ cookie
| than the one Site B sets for facebook.com. The cookies cannot
| tell that you 're the same person. If you have a Facebook
| account, your browsing activity on A and B is not connected to
| your Facebook account.
| ziddoap wrote:
| This seems to be a middle-ground.
|
| You can more confidently allow third-party cookies, which means
| that certain features that broke with the blocking of all
| third-party cookies will now be able to work, but you maintain
| most of the protections that you gained when you used to block
| them.
| lucasyvas wrote:
| So.. Standard? or Off? Ever since this has been announced, I
| understand how it works, but the browser does not communicate
| at all which setting level it maps to, or if I even need ETP
| on at all and it's just always on.
| ziddoap wrote:
| It appears that cookie isolation is _always on_.
|
| If you want to further mitigate risk, you adjust your
| settings block all third-party cookies.
| wisniewskit wrote:
| Total Cookie Protection is already on by default in private
| browsing mode, or strict ETP. Also Firefox Focus on
| Android. It's being rolled out to everyone in the standard
| ETP mode now.
|
| It's currently controlled by setting
| `network.cookie.cookieBehavior` to `5`. (There is also a
| similar setting for private browsing mode which is already
| 5 by default).
| ajvs wrote:
| ETP Strict
| ajvs wrote:
| Total Cookie Protection is the same as the Tor Browser's first-
| party isolation sandboxing - third-party cookies can't be used
| to track you across sites because they're only accessible
| within the domain they were created on. So you don't have to
| block 3rd-party cookies anymore, since they'll be sandboxed and
| unable to be used for tracking.
| wisniewskit wrote:
| To be precise, it's third party cookie/storage partitioning,
| with web compatibility fixes to keep sites working.
| asicsp wrote:
| This might help:
|
| > _Total Cookie Protection offers additional privacy
| protections beyond those provided by our existing anti-tracking
| features. Enhanced Tracking Protection (ETP), which we launched
| in 2018, works by blocking trackers based on a maintained list.
| If a party is on that list, they lose the ability to use third-
| party cookies. ETP was a huge privacy win for Firefox users,
| but we've known this approach has some shortcomings. If a
| tracker for some reason isn't on that list, they can still
| track users and violate their privacy. And if an attacker wants
| to thwart ETP, they can set up a new tracking domain that isn't
| on the list. Total Cookie Protection avoids these problems by
| restricting the functionality for all cookies, not just for
| those on a defined list._
| legalcorrection wrote:
| I wonder why Microsoft doesn't make Edge a privacy-oriented
| browser. I'm surprised they think they can make more from the
| data economy than they would gain by seriously hurting Google et
| al.
| fritigern wrote:
| Since when does Microsoft care about privacy?
| Nextgrid wrote:
| Microsoft went all-in on "growth & engagement" since Windows 8.
|
| Why sell OSes for money when you can get "engagement" instead?
| ravenstine wrote:
| Because Microsoft has had a history of caring about privacy?
|
| I'd expect something like this from Apple with Safari, but not
| Microsoft. M$ can't even give its own developer base privacy by
| allowing all telemetry to be disabled.
| legalcorrection wrote:
| Companies don't care about jack shit. Tim Cook doesn't
| "believe in" privacy, he thinks it helps sell devices (and
| that lack of privacy could lead to scandal that would _hurt_
| sales).
| ravenstine wrote:
| Whether one company is effectively more private than the
| other has nothing to do with what the company actually
| believes. It doesn't really matter what they believe. When
| you compare the two companies, Microsoft arguably has a
| greater history of embedding tracking in its products than
| Apple. This isn't to say that Apple doesn't track anything.
| As far as I'm aware, Apple didn't help the NSA bypass
| encryption or build backdoors into its OS.
| ntoskrnl wrote:
| There's too much money to be made foisting payday loans on the
| dwindling userbase. https://www.howtogeek.com/769427/microsoft-
| edge-wants-to-giv...
| legalcorrection wrote:
| Those aren't payday loans, but interesting nonetheless.
| itsbits wrote:
| They have a private experience setup available(not private
| mode).I don't remember name but as soon as you install edge, it
| asks what level privacy you want to manage. That I guess should
| be fine.
| bityard wrote:
| > making Firefox the most private and secure major browser
| available across Windows and Mac.
|
| Which one do they think is the most private and secure browser
| for Linux?
| harry8 wrote:
| Maybe they figure most linux users can tweak the settings,
| install & configure plugins on whatever browser they're using
| to harden things up with the hassle overhead they can live
| with..?
|
| Shoutout for firefox's cross OS, cross device syncing. "I found
| that and I have that it open in a tab on my desktop" and now
| it's open on my phone. Send another tab from phone to laptop
| where it's easier to work on. Really good stuff.
| Groxx wrote:
| Lynx probably
| smolder wrote:
| You'll be happy to see they've edited the announcement to
| include Linux now, likely in response to this or the other
| comment like it. :)
| madmax108 wrote:
| I wonder if there's anyone from any advertising/ad-targeting
| companies on HN who can shed some light on if/how much this
| change may affect their "product".
|
| Asking this since I know friends working at companies that were
| DRASTICALLY affected by the Apple advertising changes in terms of
| user targetability (and hence revenue) and I'm wondering if this
| change will be similar.
| unicornporn wrote:
| Firefox has a sub 8% market share, so I doubt this will make a
| drastic change to how they operate.
| rkk3 wrote:
| Surprised it's even that high, I tried to switch to Firefox
| the other month for privacy but gave up because it crashed on
| me it-least once a day.
|
| Edit: thanks for the downvotes, I would have preferred if it
| worked but it didn't. I tried basic troubleshooting,
| disabling extensions etc. but didn't find it usable on macOs
| Monterey, think it doesn't play well with youtube.
| tristan957 wrote:
| I have used Firefox for 7 years and never had it crash
| once.
| raxxorraxor wrote:
| I used it for a similar time if not longer and I think it
| crashed < 10 times. In the last years it was mostly just
| single tabs failing and probably was just another website
| with some endless js loop anyway.
|
| Extremely stable compared to almost any other software.
| Perhaps the parent means the mobile version. If not I
| would expect something is wrong with the system, even if
| visiting the worst pages of the internet.
| feanaro wrote:
| Not even Firefox Android crashes for me.
| CivBase wrote:
| I have also used Firefox for a similar time and although
| I can't say it has _never_ crashed for me, it has at
| least proven to be a bit more stable than my experience
| with Chrome.
| dylan604 wrote:
| care to share what sites were causing your "crashing"?
|
| no? then hello downvote for just making unsubstantiated
| claims that goes totally against the grain of typical
| experience.
| lamontcg wrote:
| Been using firefox for multiple years now with no crashing
| issues, pretty much ever.
| dang wrote:
| Probably you were downvoted because your comment took the
| thread on a generic tangent - indeed into one of the most-
| trodden areas on HN. Generic tangents are easy to fall into
| (of course) but make threads less interesting, which is why
| the site guidelines ask people to avoid them.
| https://news.ycombinator.com/newsguidelines.html
|
| Unpredictable/whimsical/curious tangents are still ok. Just
| not the predictable ones.
|
| More explanations here if anyone wants them:
|
| https://hn.algolia.com/?dateRange=all&page=0&prefix=true&qu
| e...
|
| https://hn.algolia.com/?dateRange=all&page=0&prefix=true&qu
| e...
| gspr wrote:
| I don't think I've ever used another browser for as long as
| Firefox has existed. I think I can count crashes on one
| hand.
| permo-w wrote:
| I switched to ff a month or two ago for the integrated
| tree-style tabs extension that you can't get on chromium-
| based browsers
|
| I didn't really have any huge problem with firefox
| specifically, but Brave just feels a bit slicker, the
| adblocker is in-built and stronger, and it manages multiple
| windows better, so I've slowly switched back to brave for
| general use, and use ff for work and projects
| geekamongus wrote:
| Strange...it's been rock solid for me for years, across
| multiple devices and OS's. I cannot remember the last time
| FF crashed.
| YetAnotherNick wrote:
| Cookies are the easiest way to shore and share information but
| far from the only way. If it affects someone's product, it is
| not hard to fingerprint browsers.
| krrrh wrote:
| It does seem relatively more difficult to fingerprint Safari
| on iOS which at least takes a sizeable % of web browsing out
| of the equation.
| jalk wrote:
| Not in an ad targeting company, but given Firefox current
| marketshare and their previous anti tracking measures, I doubt
| this will make a that much of a difference. But if the feature
| attracts loads of Chrome users then at least the ad companies
| relying on third-party cookies will feel it. Obviously if you
| are currently targeting Firefox users and your company is not
| in the current tracker list then I assume you will see
| significant drop
| tamha wrote:
| I work in advertising. this change is nothing compared to what
| Apple did. Edit : It's better than ETP.
| samstave wrote:
| UIs there a dashboard of somesort where I can see all the
| tracking/cookies bullshit affecting me?
| eslaught wrote:
| How is this different from the old privacy.firstparty.isolate,
| and do I still need that/should I keep that enabled?
| kuon wrote:
| I've been blocking cookies actively for a long time, and except
| some technical embeds (for example STEP file viewer on misumi) I
| had zero issue.
|
| This is great news. I really hope we will not lose firefox. I'm
| not saying it is better than chromium, but I think it is
| important that it exists.
| corentin88 wrote:
| Reminds me of what Google Chrome (and others browsers) did for
| cache. That's clever, not 100% sure this will prevent tracking,
| but at least it makes tracker's life a bit harder.
| ajvs wrote:
| Yes these are each subsets of State Partitioning[1], of which
| cache has also been partioned in Firefox for some time now.
|
| [1] https://developer.mozilla.org/en-
| US/docs/Web/Privacy/State_P...
| eps wrote:
| Oh, do elaborate what did Google Chrome, a browser built for
| balls-deep tracking of its users, do for cache?
|
| It is a jolly good story I'm sure.
|
| Bringing up Chrome in a context of user privacy tech is a
| phenomenally tone-deaf thing to do, even if it's technically
| relevant.
| thatguy0900 wrote:
| To some extent chrome only cares about google being able to
| invade your privacy, if google can get information a
| different way anyway then its a good thing to block it for
| everyone else
| Taywee wrote:
| Tone policing is irrelevant and annoying. Technical relevance
| and accuracy trumps any of your personal feelings on Google,
| and I say that as a person who generally detests Google.
| suprfsat wrote:
| Gaining security and privacy by partitioning the cache
| (October 6, 2020)
|
| https://developer.chrome.com/blog/http-cache-partitioning/
| robin_reala wrote:
| Probably best to say "Safari (and other browsers)" given that
| they were seven years ahead of the competition on this one.
| ape4 wrote:
| So what about things besides cookies and cache? Is there
| anything else that might be shared between 3rd party sites?
| 0daystock wrote:
| > Firefox is rolling out Total Cookie Protection by default to
| all Firefox users worldwide
|
| What does "rolling out" mean? That Mozilla has the ability to
| modify my browser without my knowledge or explicit update
| installation? How do I get "Total Protection" from this
| capability?
| hans_castorp wrote:
| > What does "rolling out" mean? That Mozilla has the ability to
| modify my browser without my knowledge or explicit update
| installation?
|
| It seems obvious to me: it means "when you install the next
| scheduled update".
| ajvs wrote:
| If your browser is set to update automatically, then yes you'll
| get this feature. It's not a flag being switched on remotely,
| it comes with an update.
| ohthehugemanate wrote:
| It means in the next update this feature flag will be enabled
| by default for all users. If you don't update (or presumably,
| update and disable the flag), you won't get it.
| GNOMES wrote:
| > Mozilla makes its complete cookie protection (Total Cookie
| Protection aka TCP) standard in its Firefox browser. For new
| users who get Firefox, the feature is enabled by default. In
| general, the aim is to achieve the changeover for all users,
| including existing customers, by August 23, 2022.
|
| https://www.realmicentral.com/2022/06/14/firefox-makes-total...
| easytiger wrote:
| If anyone wonders how bad the situation RE cookies is there is a
| local newspaper owner in the UK called reach PLC who own 100+
| newspaper websites.
|
| Their cookie allow dialog has over 700 data share partners, not
| including their own "legitimate interest" cookies. The dialog
| looks like this [1] and cannot be resized and is lazy loaded
| (i.e. you have to manually scroll to have the page load all of
| them with a few visible each scroll). And its slow so it takes a
| while and doesn't play well with the mouse in the iframe. There
| are even ones not in english or latin characters [2]
|
| [1] https://imgur.com/a/ciuRWSx [2]
| https://i.imgur.com/4yc6Flo.png
|
| Anyway i lazy loaded all of them and there are 753 (the html just
| to display it is > 1 megabyte $ xmllint
| --format reach2.html | grep qc-cmp2-list-item-header | tail &&
| xmllint --format reach2.html | grep qc-cmp2-list-item-header | wc
| -l <button role="listitem" class="qc-cmp2-list-item-
| header" aria-label="Yieldmo, Inc." aria-live="polite">
| <button role="listitem" class="qc-cmp2-list-item-header" aria-
| label="YOC AG" aria-live="polite"> <button
| role="listitem" class="qc-cmp2-list-item-header" aria-
| label="YouGov" aria-live="polite"> <button
| role="listitem" class="qc-cmp2-list-item-header" aria-label="ZAM
| Network LLC dba Fanbyte" aria-live="polite"> <button
| role="listitem" class="qc-cmp2-list-item-header" aria-
| label="Zemanta, Inc." aria-live="polite"> <button
| role="listitem" class="qc-cmp2-list-item-header" aria-
| label="zeotap GmbH" aria-live="polite"> <button
| role="listitem" class="qc-cmp2-list-item-header" aria-label="Zeta
| Global" aria-live="polite"> <button role="listitem"
| class="qc-cmp2-list-item-header" aria-label="Ziff Davis LLC"
| aria-live="polite"> <button role="listitem"
| class="qc-cmp2-list-item-header" aria-label="zillian sa" aria-
| live="polite"> <button role="listitem" class="qc-
| cmp2-list-item-header" aria-label="Zoomd Ltd." aria-
| live="polite"> 753
|
| It's crazy
| qxxx wrote:
| please someone fix the internet... I don't want to see any cookie
| popups on each site and accept / decline each cooke first only so
| I can see the content I want. I don't care about all these
| cookies and this should be managed by a browser. I hope what
| Firefox did is the beginning of such a fix.
| neop1x wrote:
| Yes. Browsers should be required to show a cookie settings
| dialog once and then send the selected answer to all websites
| in a header. And websites should be required to read the header
| and behave according to it. The problem would be solved quickly
| that way...
| [deleted]
| Animats wrote:
| I've had third party cookies blocked for ten years. Some sites
| don't work. I don't use those sites.
| bombcar wrote:
| What has become very annoying is so many sites are using "third
| party cookies" for whatever asinine "single sign on" product
| they've been sold. The number of redirects my browser undergoes
| when I log into my health insurance portal is mind boggling.
| hestefisk wrote:
| Would love for Safari / iOS to follow suit.
| xnorswap wrote:
| Does this affect single-sign-on implementations?
| jaywalk wrote:
| It shouldn't. SSO doesn't typically work by sharing cookies,
| which have always been limited to a single domain in the first
| place.
| jrochkind1 wrote:
| I'm not sure about that. It depends on where the boundaries
| of the "cookie jar" are (through redirects and such). And I
| suspect it will effect it, in order to accomplish it's
| purpose. After all, what is tracking but a sort of "SSO" you
| don't know about.
|
| (OK, technically tracking is less powerful than SSO, since
| only the third-party needs to know your "single" identity,
| the first-party website doesn't actually know it, where in
| SSO it does)
|
| I mean, to be clear -- I mean the new thing might make you
| enter your username and password to SSO login on each site,
| whereas ordinarily if you have an active SSO session you
| don't need to re-enter username and password to login with
| SSO on a new site. Will it break SSO even if you are fine re-
| entering username and password every time you SSO login? I am
| not sure, but I definitely wouldn't be confident 'no' without
| more details/testing.
| mmis1000 wrote:
| Those work by redirect you on top level domain (the url you
| see in url bar) shouldn't be affected. They don't even
| share cookie directly anyway. (Which is just.... standard
| oauth)
|
| Those work by enbedded into pages (iframe) or popups may.
|
| The biggest offender of this kind of usage is probably
| facebook comment / disqus comment.
| jrochkind1 wrote:
| Makes sense.
|
| The difference will be (I predict) that when you are
| redirected to the SSO, you will _always_ have to enter
| your username/password, or at least once per "first
| party" site you are logging into.
|
| Whereas right now, sometimes when you get redirected to
| the SSO/oath, it already knows who you are, and you don't
| need to log in again -- you just get invisibly redirected
| back, and/or just have to click a button saying "yeah,
| it's cool". But with the cookie sandboxes, you'll always
| have to actually enter username and password to your SSO.
| Because the cookies that would have told the SSO(/oauth
| provider) that you have an active auth session, from when
| you logged in earlier today or whatever -- won't make it.
|
| Or maybe not, depending on how it's implemented -- but if
| a redirect is enough to defeat it and make it think
| you're in a different sandbox, then I expect all the
| trackers will be able to defeat the sandboxing with
| careful use of redirects. So.
| mmis1000 wrote:
| Ad don't redirect you on top level domain anyway (except
| for some malicious ad). And silent popup these days don't
| even work.
|
| If the site is willing to redirect you directly to
| another site. I guess they can share data by themselves
| anyway?
|
| I think sabotage of silent tracking pixel/ajax tracking
| is enough for most usage without breaking the web.
| abofh wrote:
| It would break things like medium.com's constant prompt to
| login with this list of google accounts, but it wouldn't
| break SSO - SSO itself is typically handled by a series of
| redirections, and at the time you're redirected _to_ the
| SSO server, you're giving your cookies to _them_, then
| you're redirected back with a signed response and get
| cookies for the _destination_ domain - at no time during
| the exchange does the SSO server need to directly talk to
| the relying party.
|
| Implementations may of course vary.
| ajvs wrote:
| It shouldn't. "Exceptions are made for cross-site cookies when
| they're needed for non-tracking purposes, such as those used by
| popular third-party login providers."[1]
|
| [1] https://blog.mozilla.org/security/2021/02/23/total-cookie-
| pr...
| xnorswap wrote:
| So only the popular third-party login providers are excused?
|
| That feels worrying for competition, does it not entrench the
| current login providers?
| ajvs wrote:
| Probably yes, but it shouldn't be difficult to get an
| exception by posting a request to the Firefox bug tracker.
| In the meantime users can disable Enhanced Tracking
| Protection on the specific site with the new SSO provider.
| Vladimof wrote:
| Total** Cookie Protection
|
| **: Not total
|
| It sounds like the "Full Self Driving"** from Tesla... got
| to love the new-speak.
|
| **: Not fully self-driving....
| svieira wrote:
| SSO, probably not - embedding, possibly.
|
| If you're just worried about logging in through
| sso.coolcorp.com to third-party.corp using any of the normal
| methods (OAuth, SAML, Kerberos, etc.) then you're probably
| fine.
|
| If you're worried about composing a page made up of lots of
| custom embedded components and those components _don't_ use SSO
| (or if they do, but they authenticate invisibly using an iframe
| instead of authenticating entirely server-side) then you may
| have some things to switch up.
| calvinmorrison wrote:
| > You may have some things to switch up.
|
| Or rather a large logo that says "Please use a supported
| browser."
| throwaway0x7E6 wrote:
| with mozilla's 2% browser market share, as a developer you
| don't need to worry at all
| robin_reala wrote:
| Given the number of Firefox users that block Google
| Analytics, I wouldn't be convinced about a 2% figure.
| Sohcahtoa82 wrote:
| You can block Google Analytics all you want. Unless
| you're spoofing your User-Agent, servers still know what
| browser you're using.
| ale42 wrote:
| It also depends who the users are... given that Firefox
| tends to be used by many technically-inclined users,
| sysadmins, etc. (at least according to what I observe
| around me), it might be users you might want to consider,
| depending on what you're offering...
| ghusto wrote:
| I've never understood the thinking that went behind allowing one
| site to see the existence of another site's cookie in the first
| place. I don't think I'm even coming at this with the security
| hindsight of decades, it's just common sense, isn't it?
| mdavidn wrote:
| Sites can't see the existence of other sites' cookies. They
| can, however, request resources from other sites. Those
| requests, in turn, would send third-party cookies, if any, to
| the third-party server _and_ save new third-party cookies in
| response. "Tracking beacons" abuse this behavior to correlate
| user behavior across many web sites.
| aimor wrote:
| I never understood it (third party cookies getting external
| information) either. Same thing with the referer request
| header, or user agents, or disabling the right-click menu, or
| editing the browser history, or opening new windows, or
| changing scroll behavior, or replacing the cursor icon, or
| autoplaying videos. There are reasons to want to do these
| things. In some cases it's difficult for the browser to prevent
| them. But I'd sure like it if the standards and browsers were
| on my side, not the side of those nefarious web developers.
| ComodoHacker wrote:
| A site isn't allowed to see another site's cookies, common
| sense doesn't fail you.
| ghusto wrote:
| No, but I said see the _existence_ of. Or am I wrong there?
| Ha, I should really know this :P
| ComodoHacker wrote:
| I'm not a front end guy, but AFAIK no, even the existence
| of. Apart from various hacks, of course.
| feanaro wrote:
| Sites A and B both include content from the spying website S,
| which sets some cookies. Now S can correlate your visits to A
| and B because it's able to read its own cookies.
|
| This change makes it so that requests A -> S (requests from A
| to S) and B -> S are treated as A -> S1 and B -> S2 instead.
|
| Now S1 cannot read cookies from S2 and vice versa, even though
| they are the same site.
| Renaud wrote:
| It's not that one site is seeing another site.
|
| It's that multiple sites will serve content (ads, Javascript
| libraries, like buttons) from a common site (eg an ad network)
| that uses its own domain. That domain is allowed to get the
| cookie for itself because it is referenced by multiple site,
| that's how this type of tracking works.
|
| If you go to bbc.com, it still won't be able to see cookies
| from cnn.com, but say if advert.com is included by both sites,
| then it will see that you visited them both. That's the power
| and great danger that things like facebook and google sense
| represent.
|
| The owner of the sites get some stats for free by using these
| services, but the biggest benefit is for google and facebook to
| be able to track what users are looking at accross the web. And
| you just need to be identifiable on one site that you visit
| (say, FB or gmail) for them to know _exactly_ who you are.
|
| From what I understand, Firefox will only allow advert.com to
| get the cookie it created when being loaded as part of bbc.com,
| but it won't be able to read its own cookie from cnn.com, it
| will have to create a new, separate one, thus breaking the link
| tracking you between sites, or at least making it harder to
| connect the dots.
|
| Everyone should use FF.
| Sohcahtoa82 wrote:
| > Everyone should use FF.
|
| Wouldn't simply installing an ad/tracking blocker like uBlock
| Origin be just as effective, if not moreso?
| titusjohnson wrote:
| Not with Google hamstringing extensions w/ Manifest v3, no.
| robin_reala wrote:
| uBlock Origin works best on Firefox anyway:
| https://github.com/gorhill/uBlock/wiki/uBlock-Origin-
| works-b...
| [deleted]
| johannes1234321 wrote:
| Isn't it better to remove the different root problems
| isntead of having plugins working around?
| Sohcahtoa82 wrote:
| Personally, I use uBlock Origin more to block obnoxious
| ads than to block the tracking.
|
| I'm not sure I really care that much about tracking,
| honestly. So what if reddit knows I bought a toaster on
| Amazon recently? What are they going to do with that
| data, show me toaster ads? I'm going to be blocking that
| ad. Sell the fact that I bought a toaster? Whatever. It's
| all going to be so advertisers can personalize
| ads...which I will be blocking.
| cpmsmith wrote:
| There's some overlap, but ads aren't the only thing using
| this. Google Fonts is the classic example of something that
| does add value (nice fonts) to a webpage, and as such isn't
| blocked by most adblockers (including uBO) by default, but
| is still able to use this for tracking because the same
| domain serves the font files on every website using them.
| taftster wrote:
| Very insightful response. The tendency is to look at the
| cookie problem as an advertising problem. Whereas, there
| are other cross-origin use cases that are not adverts but
| pose the same tracking threat. Anything on a CDN (like
| common javascript libraries) share this trait.
| ajvs wrote:
| It's a legit usecase for Single-Sign On providers. However this
| functionality has been mainly abused by ad trackers, and has
| thus been curtailed.
| i2shar wrote:
| Can you elaborate how? From what I know, the two most popular
| implementations - SAML and OIDC don't rely on 3rd party
| cookies. They rely purely on HTTP redirects.
| dmw_ng wrote:
| Does anyone know if this covers network-layer state like keep-
| alive or TLS session reuse?
| jokoon wrote:
| I really want to enable resist fingerprinting, unfortunately it
| disables dark theming on github, ddg and other websites.
|
| I wish I could add an exception rule to this...
| Saint_Genet wrote:
| I guess you could set up custom stylesheets, at least for sites
| you commonly browse.
| TAForObvReasons wrote:
| The time-based light/dark mode setting requires the current
| time. It is not currently accessible from CSS and is blocked
| by resistFingerprinting
| imbnwa wrote:
| Does that for extensions like Dark Reader Pro too?
| mlindner wrote:
| I've had it on a for a while and I don't seem to have any
| issues getting dark theming to stick.
| 8organicbits wrote:
| For GH you can set your theme preference in your account
| settings.
| ajvs wrote:
| Dark Reader extension has made me never notice this was a
| thing.
| [deleted]
| dizhn wrote:
| When Mozilla comes out with a feature like this it usually
| whitelists google, microsoft and similar big sites so people can
| still log in across their network. Anybody know the current list
| for this feature?
| wisniewskit wrote:
| Yes, you can follow the meta-bug here to see the current issues
| we're working on resolving in a better way:
| https://bugzilla.mozilla.org/show_bug.cgi?id=1537702
|
| Perhaps unsurprisingly, Microsoft logins are the most glaring
| exceptions right now (Teams, Logins, Office, Live), and we're
| working with MS to see if we can find an acceptable fix (or
| work-around while it's fixed). There are also exceptions for
| github.dev and history.com right now.
|
| It's worth mentioning that these aren't simply exceptions which
| blanket enable tracking for those sites, it's just to work
| around specific breakage.
|
| We're also working around some other specific site logins or
| features breaking, which would not break if sites called the
| new requestStorageAccess API appropritately. We're using
| SmartBlock to shim those cases until the sites can fix it
| themselves.
| daveoc64 wrote:
| What is the "better way" here?
|
| There is a legitimate use case for having login/identity
| stuff on a different domain - many of the largest companies
| in the world are doing this.
|
| How can this issue be solved without either confusing users
| through the requestStorageAccess API, or forcing everyone to
| use a single domain for everything?
| wisniewskit wrote:
| Right, Total Cookie Protection has been baking for a while
| to try to minimize that kind of breakage, and we're already
| in discussions with other browser vendors and companies to
| get everyone onboard on the Privacy CG.
|
| In a nutshell, adding new case-specific web APIs seems to
| be the likely way forward here. There are proposals
| floating around like an "is logged in" API, the Federated
| Credential Management API, and so on.
|
| I'm not sure there's ever going to be a perfect solution
| for everything, but I would certainly rather have users
| more informed and empowered about their privacy than they
| currently are (even if some folks prefer to just "allow
| all").
|
| I guess we'll just have to wait and see which proposals win
| out, and in the meantime rely on heuristic-based solutions
| like Total Cookie Protection to iteratively get us to a
| better place.
| GRBurst wrote:
| Very cool to see more privacy by default in Firefox.
|
| It is still a lot of effort to have clear separations in every
| browsern...
|
| I am using Firefox containers with the temporary containers
| plugins (with history deletion enabled) as well as cookies auto
| delete plugin (which supports containers).
|
| Therefore, everything is usually isolated in a container inside a
| tab and only white listed cookies are kept in the named
| containers.
| chasd00 wrote:
| given that Electron is really just a featureless browser
| shouldn't it be straightforward to make your own browser now? An
| address bar, navigation, and bookmarks ought to be enough to get
| you there. Seems like you should be able to make a browser for
| your specific needs/wants pretty easily these days. I'm not
| suggesting some sort of money making venture where you're
| beholden to investors to try and turn revenue with it but more
| just like a utility. Like a script or something... maybe that's
| the way to think about it, something cobbled together quickly to
| read websites.
| pvg wrote:
| _given that Electron is really just a featureless browser
| shouldn 't it be straightforward to make your own browser now?_
|
| That's not what Electron is but there are piles of fork-ish
| browser projects out there statistically nobody uses. This also
| answers the second question in the negative - it is not
| straightforward to make your own browser that's as useful as
| the browser you're likely using.
| Sohcahtoa82 wrote:
| > > given that Electron is really just a featureless browser
| [...]
|
| > That's not what Electron is
|
| I mean...isn't it?
|
| Forget the idea of what it's used for and just look at how it
| works. It's a framework for making apps that uses Chromium
| for rendering and a Node backend. Strip off the Node backend
| and you're left with Chromium.
|
| And Chromium on its own is a web browser. Electron just
| doesn't show the controls for it.
|
| As far as I'm concerned, Electron is a featureless web
| browser with a backend added to do things a browser normally
| can't do on its own, like reading local files without
| presenting a dialog.
| pvg wrote:
| _a backend added_
|
| That's a huge change which allows for things like turning
| XSS into RCEs. It's a bit like 'why can't you make your own
| street legal sports car by removing the rear spoiler and
| replacing it with a jet engine'.
| bitwrangler wrote:
| It would be nice to allow users to create "trusted tuples" to
| list small groups of domains that are allowed to share their
| cookies. For instance: Zendesk, Asana, Jira, etc.
|
| But have each tuple listed still be isolated from the other, only
| domains listed together in a single list could share a cookie
| container.
| laerus wrote:
| Probably that is the use-case for the official multi-account
| containers plugin.
| TheNewsIsHere wrote:
| I tend to agree, but as someone who uses this plugin a LOT, I
| have some complaints.
|
| If I decide I want, say, an Azure Portal container then I
| cannot have login.microsoftonline.com assigned to a different
| container -and- configured to automatically open in that
| container.
|
| If I do that, I need to have a combined Azure + Office 365 +
| anything-I-need-to-authenticate-to-Azure-AD-for container.
|
| It's a good solution but with its lack of flexibility I find
| it's too far in the direction of security versus convenience.
| bitwrangler wrote:
| I use multi-account containers too, and I like it. This is
| exactly my point, instead of mapping each domain into a
| single container, any domain could exist in one or more
| "trusted tuples"
|
| Maybe another way to think of it is like a one-to-many
| join. A domain would not "belong" to a single container,
| but have tags to associate with 1+ containers.
| InCityDreams wrote:
| ...as opposed to 'nested tuplets'? /fz
| emsixteen wrote:
| Little bit of an aside, but what's the use-case for Asana here?
| zagrebian wrote:
| > small groups of domains that are allowed to share their
| cookies
|
| Could you explain how this could be beneficial to the user?
| 89vision wrote:
| for non-dark pattern use cases where it is beneficial from a
| usability standpoint to share cookies across domains
| zagrebian wrote:
| Well, what are those use-cases? That is what I asked.
| bitwrangler wrote:
| Yes, I think there are some cases where a user might want
| to opt-in and allow cookies to be shared across a specific
| set of domains. The main reason I could think of it to
| allow cross-site business integration to continue to work
| as (currently) designed.
| rdsubhas wrote:
| Privacy wins aside, can anyone please help educate if third party
| single sign ons will still continue to work?
| jalk wrote:
| I don't think they rely on third party cookies. You are
| redirected to the SSO provider which then issues a token which
| it transports back to the requesting site through other means
| than cookies (i.e. post body / query string)
| Strom wrote:
| Depends on the specific implementation, but in theory this
| doesn't limit any functionality for SSO. Data can be shared via
| mechanisms other than cookies.
| kayodelycaon wrote:
| This feature protects domains, not sessions. SSO relies on
| passing tokens over redirects, not cookies. As long as your
| redirected, the SSO uses their own first party cookies. You
| would be logged in to the SSO provider no matter who redirected
| you there.
| three14 wrote:
| And can someone explain how I'm supposed to _implement_ SSO? We
| have a bunch of subdomains that support SSO by communicating
| with an iframe that has the logon status stored, but it appears
| that the iframe wouldn 't have access to its own data anymore.
| Is that right?
| notriddle wrote:
| Subdomains shouldn't be a problem unless your base domain is
| in the Public Suffix List.
|
| According to MDN:
|
| > More specifically, Firefox double-keys all client-side
| state by the origin of the resource being loaded and by the
| top-level site. [1]
|
| They linked the definition of a "site" to the HTML5 spec,
| which says this:
|
| > To obtain a site, given an origin origin, run these steps:
| [2]
|
| > 1. If origin is an opaque origin, then return origin.
|
| > 2. If origin's host's registrable domain is null, then
| return (origin's scheme, origin's host).
|
| > 3. Return (origin's scheme, origin's host's registrable
| domain).
|
| The HTML5 spec refers to the site's registrable domain
| according to the URL spec:
|
| > A host's registrable domain is a domain formed by the most
| specific _public suffix_ , along with the domain label
| immediately preceding it, if any. [3]
|
| Public Suffixes are defined according to a database that you
| have to explicitly register in [4]. If you aren't sure
| whether your base domain is registered as a public suffix,
| then it probably isn't.
|
| [1]: https://developer.mozilla.org/en-
| US/docs/Web/Privacy/State_P...
|
| [2]: https://html.spec.whatwg.org/multipage/origin.html#site
|
| [3]: https://url.spec.whatwg.org/#host-registrable-domain
|
| [4]: https://publicsuffix.org/
| three14 wrote:
| Thanks! I actually got as far as your [1], but incorrectly
| assumed that 'site' meant 'origin', so thank you for
| explaining.
| wisniewskit wrote:
| It depends on the specific third party login service. Some rely
| on third party storage-sharing, and there are web compatibility
| measures built into Total Cookie Protection to allow those to
| keep working.
|
| One is that the login service can request access from the user
| using a new web API (requestStorageAccess). Another is
| heuristics which apply when the user interacts with the page in
| a way which implies a login might be taking place.
|
| In these cases, specific third parties can be granted access to
| allow the login. There are some more details here:
| https://developer.mozilla.org/en-US/docs/Web/Privacy/Storage...
| ezfe wrote:
| Single sign on doesn't need cookies. The data is passed in the
| URL when redirecting back and forth between the website and the
| SSO provider.
| fancl20 wrote:
| Before anyone jumps to why Chrome doesn't block third-party
| cookies, some context:
|
| Regulators did warn Google NOT TO block third-party cookies
| before they provide a replacement, UK CMA accepted the latest
| proposal from Google: https://www.gov.uk/government/news/cma-to-
| keep-close-eye-on-...
|
| Apple's tracking rules also raised a lot of anti-trust concerns,
| giving advertisement in App Store unfair advantages among other
| ad platforms. Latest from German Government:
| https://www.bundeskartellamt.de/SharedDocs/Publikation/EN/Pr...
|
| Banning third-party cookies will increase the gap between Google,
| Microsoft, Apple and other ad platforms, because they can still
| track you based on your account (e.g. Gmail, Hotmail, iCloud).
| It's a huge red flag for antitrust cases they are facing
| (especially Google).
| [deleted]
| [deleted]
| mywittyname wrote:
| Yet another reason that we need to ensure that third party
| browsers are being used and in active development.
| dahart wrote:
| Ah that's very interesting. This really goes to show how
| powerful companies get when they have decent market share in
| the browser space while they have products on the web that have
| decent market share in other spaces, when there are grave
| concerns about what they do on either side of a decision.
| Chrome has been damn convenient from a dev perspective, and
| damn good, but the list of reasons I should be reaching for
| Firefox more often seems to be growing.
| de6u99er wrote:
| >Total Cookie Protection creates a separate cookie jar for each
| website you visit.
|
| Means third parties win't be able to identify you qccriss sites
| through cookies. Means the Google Ads cookie or Floc ID will be
| different for each site you visit.
| ComodoHacker wrote:
| Just to clarify, Total Cookie Protection in Firefox is not the
| same as blocking third-party cookies. Firefox will accept
| third-party cookies and send them back, but only on this
| particular site. So third parties (read ad networks) will be
| able to track you on any site, but not across sites (without
| some other means of tracking).
| bpodgursky wrote:
| Yeah, which is why sites are all requiring logins nowdays, so
| they can use server-side ID syncs.
| logifail wrote:
| > so they can use server-side ID syncs
|
| Does this only work if you use the same email across
| multiple sites?
|
| If so it's yet another reason to use a different email
| address with every site you sign up at.
| Vinnl wrote:
| Which incidentally Mozilla also has a product for:
| https://relay.firefox.com
|
| (Disclosure: I work on Firefox Relay :) And yes, I know
| some people also have their own domain with unlimited
| email addresses.)
| logifail wrote:
| > I know some people also have their own domain with
| unlimited email addresses
|
| A friend of mine does it the hardcore way, through DNS.
| He adds MX records for subdomains corresponding to the
| name of the site he's signing up for. Lets say his domain
| name is example.com:
|
| bob@hilton.example.com bob@ycombinator.example.com
| bob@firefox.example.com and so on
|
| He also does it for friends(!) meaning when he gives you
| "his" email, it's always of the form
| bob@<yourname>.example.com
|
| If he tires of you or your comms get too spammy, he just
| bins the relevant DNS record. No more mail from you!
| EmilyHATFIELD wrote:
| Is there any plans to support naming my different relay
| addresses? :)
|
| The service is awesome but it's quite confusing to know
| which one to use on which websites and which one to
| delete etc
| altncatchfire wrote:
| I've been following Firefox Relay features for a bit now.
| Is there a difference between the service offered by
| Firefox Relay premium to the free DuckDuckGo Email
| Protection?
|
| Do you believe DDG will also eventually move to the
| subscription model for these features (unlimited aliases,
| reply to sender)?
| quotehelp9128 wrote:
| I'm sorry to bother you (and rest of HN) about your
| product in an off-topic thread, but I noticed [?]Relay
| Premium[?] is available in limited countries. Considering
| some countries in that list are part of EU, what are the
| limitations why I'm not able to subscribe to the premium
| service? Or is there a way to join Relay Premium while
| not in listed countries (for example, having credit card
| issued by a listed country)?
| Ayesh wrote:
| > Does this only work if you use the same email across
| multiple sites? At a huge risk of EU regulars cracking
| on, it is quite possible to track a user across multiple
| accounts by simply using a cookie that lives long enough
| (say, 30 days) to establish the connections between
| multiple accounts.
|
| For a server-side ID sync, you don't even need user
| accounts. Just a unique ID set in a cookie will do.
| nightpool wrote:
| How would this work when the cookie ID is different for
| every different embedding (first-party) context? That's
| the whole point of total cookie isolation.
| robin_reala wrote:
| If you don't want Firefox to do even that, you can go to
| Settings, click on Privacy & Security, then choose the Strict
| option. It'll warn you that it might break sites, but you can
| always turn it off on a site-specific level by clicking on
| the shield in the address bar and turning off the toggle.
| account42 wrote:
| Be aware though that this will make firefox tell sites that
| you want a light color scheme instead of doing the more
| sensible thing and indicating no preference.
| robin_reala wrote:
| Interesting. I'm a light mode user, so hadn't seen that.
| Nemo157 wrote:
| Though IIRC from some bugginess I was noticing a while
| ago, only to the JS API, it will still obey the dark
| color scheme media query (but sometimes inconsistently, I
| would load the same page in multiple tabs and sometimes
| get dark or light schemes).
| PaulStatezny wrote:
| This chain of replies containing only pertinent facts to
| inform the reader exemplifies what's so great about
| Hacker News. :-)
| TekMol wrote:
| they can still track you based on your account (e.g.
| Gmail, Hotmail, iCloud)
|
| Really? I don't think so. How would that work? If you visit
| www.somesite.com - how would javascript on that site identify
| you via Gmail?
| candiodari wrote:
| Okay:
|
| 1) you visit to www.somesite.com
|
| 2) it serves an ad <iframe
| src="www.google.com/givemeanad?userforme=waps&hespent=500"
|
| 3) your browser does a request to google. It sends:
|
| a) your login cookie from your gmail session (or ...)
|
| b) the referrer header tells it which site to serve the ad on
|
| c) any information the site itself wants to attach to the
| request
|
| 4) Google/Microsoft/Apple store this information and can
| provide advertisers with your identity, all sites you visit
| that have their ads, the "flow" (what you visited in what
| order, e.g. how far did you get in an ordering funnel) and
| any information those sites share about your account on their
| site.
| nightpool wrote:
| Okay, but: a) is blocked by site partitioning, b) doesn't
| have per-user tracking information, and c) only works (of
| course) if you've explicitly signed in with Google on that
| site. I don't think Google supports third-party tracking
| for ads via that personalization path yet, but plenty of
| non-Google advertisers do: they take your hashed email
| address and use that to replace their third-party tracking
| cookies. This is what the ad community is hailing as their
| "privacy first" approach that breaks Google's "monopoly"--
| sending your email address to every single advertiser who
| they partner with.
| lucideer wrote:
| What application are you using to visit that site?
| pilsetnieks wrote:
| Because Google's, Apple's and Microsoft's accounts
| specifically are tied to their particular browser and/or OS,
| not just the websites you're on.
|
| So are Firefox accounts but they probably don't have the
| numbers to engage in any particularly egregious behavior.
| nightpool wrote:
| Are you saying that Google is using their control of the
| user agent to specifically tie a Google auth cookie to an
| individual third-party-context web request even when third
| party cookies are blocked? If so, that would be a major
| scandal. What evidence do you have that this is the case?
| TekMol wrote:
| What kind of mechanic are you describing? Are you saying
| the browser is phoning home, telling Google which sites you
| visit?
| pilsetnieks wrote:
| Yes. You can turn it off, though, if you take Google at
| its word.
|
| https://support.google.com/websearch/answer/54068?hl=en&c
| o=G...
| chefandy wrote:
| Well, Chrome obviously does if you're 'signed in' to
| Google and haven't turned off their sync settings...
| which I imagine is the most common end user path, and
| chrome is the most popular browser.
| https://www.google.com/chrome/privacy/
| [deleted]
| sampa wrote:
| It's nice, but is that so hard for Mozilla to tell in which
| version it will appear? Is it the current version or is it the
| next 102 version (which releases in 2 weeks, but then why they
| say it "rolls out"?)
| ridgered4 wrote:
| Looks like it's already in v101.0.1. It's under the Settings |
| Privacy and Security tab with a new checkbox to allow you to
| "Test Pilot our newest..." It is not automatically checked for
| me.
|
| I think the change might just be they will be setting that
| checkbox to on now? Although I don't remember seeing this
| option until now.
| rebelwebmaster wrote:
| Mozilla occasionally rolls out features in the current release
| via remote mechanisms. So it's rolling out to existing v101
| installs now. I would assume that v102 will also ship with it
| on by default.
| seanhunter wrote:
| If you want to enable it early, I believe you can go to
| about:config and set network.cookie.cookieBehavior to 5
|
| Likewise you can keep enhanced tracking protection in general
| but disable partitioning (total cookie protection) by setting
| it to 4
|
| https://support.mozilla.org/en-US/kb/total-cookie-protection...
___________________________________________________________________
(page generated 2022-06-14 23:01 UTC)