Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Firefox Mozilla The Internet

Another Tor Browser Feature Makes It Into Firefox: First-Party Isolation (bleepingcomputer.com) 93

An anonymous reader writes: Unbeknown to most users, Mozilla added a privacy-enhancing feature to the Firefox browser over the summer that can help users block online advertisers from tracking them across the Internet. The feature is named First-Party Isolation (FPI) and was silently added to the Firefox browser in August, with the release of Firefox 55. FPI works by separating cookies on a per-domain basis.

This is important because most online advertisers drop a cookie on the user's computer for each site the user visits and the advertisers loads an ad. With FPI enabled, the ad tracker won't be able to see all the cookies it dropped on that user's PC, but only the cookie created for the domain the user is currently viewing. This will force the ad tracker to create a new user profile for each site the user visits and the advertiser won't be able to aggregate these cookies and the user's browsing history into one big fat profile. This feature was first implemented in the Tor Browser, a privacy-focused fork of the Firefox browser managed by the Tor Project, where it is known as Cross-Origin Identifier Unlinkability. FPI was added to Firefox as part of the Tor Uplift project, an initiative to bolster the Firefox codebase with some of the Tor Browser's unique privacy-focused features. The feature is not enabled by default. Information on how to enable it is in the linked article.

This discussion has been archived. No new comments can be posted.

Another Tor Browser Feature Makes It Into Firefox: First-Party Isolation

Comments Filter:
  • by Anonymous Coward

    This seems like the kind of feature that should be enabled by default when using a private browsing window, or using the "never remember history" option in the settings page.

    • by mspohr ( 589790 ) on Monday November 20, 2017 @03:09PM (#55588965)

      I naively thought that this was the default behavior for cookies. Why would anyone think it was a good idea to allow random people to read cookies from any domain?
      Cookies should be confined to a single domain where I am viewing content, not intrusive ad networks.

      • Re:Private browsing (Score:4, Informative)

        by Luthair ( 847766 ) on Monday November 20, 2017 @03:19PM (#55589041)
        I'm not sure you understand the scenario. These are third-party cookies that the browser would receive via headers when the tracking network was included on another site The tracking networks cookie would only appear on the headers to that network and could not be read by other sites.
        • Thanks for the additional information. I guess my question now is why would a browser allow random third party domains set cookies when viewing a site?

          • by Luthair ( 847766 )
            All but Safari which turned it off a few years ago iirc. There have been some legitimate uses like Google's login services.
          • Re: Private browsing (Score:5, Informative)

            by Anonymous Coward on Monday November 20, 2017 @04:27PM (#55589769)

            If the browser loads a resource from a domain, that domain can set a cookie for itself via HTTP headers (or if the resource is a script, through the script). That's normal, isn't it? But this is also true if that resource comes from a "third party" domain, i.e. one which is different from the domain of the web page itself. Example: You are looking at slashdot.org, which loads a script from taboola.com. Then the taboola.com script can set a cookie for taboola.com. Slashdot.org can not read that cookie, but if a page from a different domain also loads a script from taboola.com, that script can (normally) read the cookie for taboola.com. That cookie usually contains a tracking ID, so when many sites on the web load a taboola.com script, taboola.com can track you across web sites. With first-party isolation, the third party cookie can still be set, but it is only readable when the third party resource is loaded in the same first party domain context where it was set. Something else you can do (and probably should do) is disallow third party cookies altogether or at least make them expire when you close the browser. If you do the latter, first party isolation still helps by preventing in-session tracking.

            • by mspohr ( 589790 )

              I understand how this helps advertisers but I really don't want to help advertisers. I can't think of a legitimate use for this "feature".
              When I'm viewing a website such as cnn.com, I don't want random ad networks to be able to set or read their cookies. If I'm on cnn.com the only cnn.com should be able to set and read cookies.
              I'd like to disallow third party cookies ...
              For instance, Chrome doesn't have this option. They do have a "do not track" option which I have set but that doesn't seem to do anything.

              • I can't think of a legitimate use for this "feature".

                It wasn't a feature per se. It was simply how things worked under the same-origin policy. The browser loads what it's told to load, and each cookie is accessible to its parent domain. Advertisers started abusing this default security posture.

                Blocking third-party cookies and first-party isolation are responses to that abuse.

                Both of those options are far simpler than fundamentally changing the same-origin policy. There would need to be a consensus on an alternative security model across the whole ecosystem: b

      • Re:Private browsing (Score:4, Informative)

        by Fahrvergnuugen ( 700293 ) on Monday November 20, 2017 @03:46PM (#55589365) Homepage

        It's trickier than that...

        What happens when you insert the facebook or adsense code on your website is that you are actually including content hosted by the ad network.

        Your browser is then loading that content from that ad network because in addition to loading mygreatwebsite.com, you are also loading ads.adcompany.com or whatever.

        The cookie from the ad network is linked to ads.adcompany.com. The same cookie is being set for every website that serves content from that same ad network, and so they are able to build a profile on you.

        The bigger an ad network gets, the more websites it is installed on, the more clear the profile becomes.

        I guess (I don't know the details of it) what this feature is doing, is preventing any cookies that differ from the domain displayed in the URL from being loaded. I'm not sure how exactly this is different from private browsing.

        • Re:Private browsing (Score:5, Informative)

          by sexconker ( 1179573 ) on Monday November 20, 2017 @04:52PM (#55590029)

          I guess (I don't know the details of it) what this feature is doing, is preventing any cookies that differ from the domain displayed in the URL from being loaded. I'm not sure how exactly this is different from private browsing.

          No, it's in the summary.

          This is isolation, not blocking. Plenty of sites won't work if you outright block 3rd party cookies.
          What this does is allow the cookie to be set and sent back in future requests, but it's one cookie per ad domain AND per visited site.

          If you go to pussy.com and it loads a tracking asset for ass.com, Firefox sets a cookie for ass.com.
          If you go to pussy.com again and it loads a tracking asset for ass.com, Firefox sends the same cookie back.
          So ass.com can track you on pussy.com.

          If you then go to titties.com and it loads a tracking asset for ass.com, Firefox sets a separate cookie for ass.com.
          This way, ass.com can't track you across pussy.com and titties.com as a single user by use of their cookies.

          They will still try (and generally succeed) at such tracking via browser fingerprinting, timing, meta analysis, and the good ol' IP address.

    • Private browsing? Maybe on your local network... On the internet there's no such thing.

  • Waterfox Is Better (Score:4, Informative)

    by NicknameUnavailable ( 4134147 ) on Monday November 20, 2017 @03:04PM (#55588935)
    This is just Firefox trying to be a source of telemetry. Waterfox [waterfoxproject.org] is based on Firefox, but removes all the telemetry, sponsored ads, etc plus a bunch of security holes the Firefox team isn't addressing.
    • by mikael ( 484 )

      What about the security risk from: Allow running of all 64-Bit NPAPI plugins

      Those were the biggest security risk. You could have a secure browser, but one dodgy plugin allows all that spyware crud to creep back in.

      • It's up to the user to decide what is and isn't safe to install on their machine. That part was put in place specifically because Firefox blocked "unapproved" AdBlockers (all the ones not sending telemetry back themselves or who blocked Firefox partner sites.)
  • Is this how it works? My understanding that tracking cookies will be a) multi-domain and b) will also include add network domain. For example, Taboola cookie would be still accessible across all sites that use Taboola. Is this not the case?

    I configure browser to wipe all my cookies on browser close, and frequently close it. I recommend others to do the same.
    • From what I’m reading, this change will address those multi domain cookies. One site will add a Taboola cookie and will be able to read it, but if another site attempts to access the Taboola cookie, Firefox will pretend it isn’t there, and the second site will the proceed to create its own Taboola cookie. So cookies for 3rd party domains are still allowed, but they are sandboxed per domain in the browser.
    • by Luthair ( 847766 )

      Basically the tracking network would set a cookie header on the HTTP request for a JS coming from their server, then when the user visits some other page which also includes the tracking network the original cookie would be sent back to the tracking network connecting the user across the two sites.

      I presume with FPI firefox treats the third party cookie given on site-A and the third party cookie given on site-B as distinct and will only send them in the context of those particular sites which prevents the

    • by dissy ( 172727 )

      Is this how it works? My understanding that tracking cookies will be a) multi-domain and b) will also include add network domain. For example, Taboola cookie would be still accessible across all sites that use Taboola. Is this not the case?

      That is the case in IE, but in all other browsers no, a cookie can only be set for a domain if sent by a server on that domain.

      But look at slashdot as an example. When you go to slashdot.org, you are loading content from 4 separate host/domains.

      slashdot.org can set a cookie that gets sent back to slashdot.org
      But you are also loading content from other domains:
      a.fsdn.com content is loaded and can set a cookie, which gets sent back to a.fsdn.com
      gstatic.com content is loaded and can set a cookie, which gets s

  • Wonder what would be the work around for the trackers and advertisers. I've already done a lot to keep my footprint as small as possible but I know I'm still getting tracked in some ways I can't stop if I want to be able to do useful things online. Like paying my bills. And I personally question the usefulness of things outside of the plain browser identifier. I don't get why any site I visit would need to probe what addons or if javascript has been executed. Maybe I don't do enough site programming to "get

    • >Wonder what would be the work around for the trackers and advertisers.

      You answered your own question! "or whatever it's call when the server sending out the ads does the tracking itself."

      They'll do their best to get a decent fingerprint of your system, and their tracking accuracy will be reduced (probably by far less than we'd hope or expect).

    • by AHuxley ( 892839 )
      Re "Like forcing more websites to have signins to be useful."
      Sites will just have a members section. Pay by CC.
      Dont want to pay with a CC?
      Run some code on the gpu/cpu for some time and get a one time, a day, month, year or much longer account.
      Running a gpu/copu for some time for a site will get around the needs for ads, tracking, the policy connected to using social media ads.
    • by mikael ( 484 )

      They will go back to using whatever unique ID's are available on the system. Remember CPU-ID? Where special CPU instructions mapped onto web-browser script keywords allowed a website to know your CPU. Now they could access the UUID of your file system.

  • Seriously? (Score:4, Insightful)

    by DontBeAMoran ( 4843879 ) on Monday November 20, 2017 @03:29PM (#55589161)

    With FPI enabled, the ad tracker won't be able to see all the cookies it dropped on that user's PC, but only the cookie created for the domain the user is currently viewing.

    Why the fuck isn't that by design? Who's the moran who decided not to include that in the specifications?!

    • I imagine this was from before the web became a spying/ad mess. The idea back than was you were loading third-party content because it didn't make sense for everyone to have a huge copy of those images/a javascript library (probably predates JS).

    • by Dracos ( 107777 )

      Cookies were added in HTTP/1.1 (RFC 2068 [ietf.org]) in 1997 after two years of specification development. Lots of things about cookies were naively permissive, but it took years to realize this. HTTP/2 (in 2015) did nothing to address cookie flaws.

    • by mikael ( 484 )

      Sometimes the cookies are used to store your username/password so that you can log in automatically in on the website, even though you have opened a new window.

    • With FPI enabled, the ad tracker won't be able to see all the cookies it dropped on that user's PC, but only the cookie created for the domain the user is currently viewing.

      Why the fuck isn't that by design? Who's the moran who decided not to include that in the specifications?!

      It is by design and it is in the specification, always has been. Sites can only set cookies for the domain that serves the content.

      sexconker posted a good explanation: https://news.slashdot.org/comm... [slashdot.org]

  • I'm surprised we haven't heard about hosts files yet...

  • They'll just link the separate cookies together with ETags. Unless you're also going to have a separate file cache for each domain too.... not a bad idea actually.

  • That is a cool feature that won't break anything (except the sites tracking you across multiple domains - which is the point here).

    Why do they hide it? To don't piss off Yahoo/Yandex/Baidoo sponsors? I guess (sane/informed) people love it so make it DEFAULT!

  • The add-on, First Party Isolation, linked from the article, to

    https://www.bleepingcomputer.c... [bleepingcomputer.com]

    is something of a turd. There is no indication that it is doing anything. The preference page has no controls. The icon that is placed in the menu bar shows no state information—supposedly if you click on it, the FPI feature will be disabled for five minutes. There is absolutely no indication that anything happens when you click on it. plus, the icon is so hard to see that at first I thought there was no ico

    • by pr0nbot ( 313417 )

      Later in the article:

      The second method of enabling FPI is by modifying parameters in the about:config settings page. To access this page, users must type about:config in the address bar and press Enter.

      Once they reached the about:config page, they can search for "firstparty," and the two FPI parameters will appear.

      To enable FPI, users must set "privacy.firstparty.isolate" to true by double-clicking it. The second parameter — "privacy.firstparty.isolate.restrict_opener_access" — works by lowering

  • Ghostery does basically the same thing, and probably better. It works with the new version of firefox. (it's a WebExtension)

    https://www.ghostery.com/ [ghostery.com]

Pascal is not a high-level language. -- Steven Feiner

Working...