1. 79
  1.  

  2. 20

    I imagine this means that if you had e.g. Disqus embedded on a bunch of sites, you’d need to log into Disqus in each one. Is that correct?

    (I think I’d be fine with that. Just curious what the user-visible effects are.)

    1. 15

      Yes. And Like-buttons will also break.

      1. 6

        Thankfully those seem to have gone out of fashion somewhat?

        It’s kind of ironic that the centralization / silo-ification of the web (“people just stay on facebook all the time and don’t care about interacting with facebook from embedded widgets on random articles”) is making this amazing privacy improvement palatable for mainstream users.

      2. 10

        i admittedly have a very limited understanding of browser technologies, but everything described in the section on what they’re doing was how i imagined cookies already working in my head. i’m kind of … used to being horrified by browsers, by now, but yeah, learning how things used to work was an eye-opening lesson in how awful most browsers are. holy shit.

        1. 10

          In a better world, the way “things used to work” is how you’d want them to work. Shareable cookies do add value, they’re just very easy to abuse. I also don’t think this technically limits the tracking, though it may require it to make more network requests; it’s hard to stop two cooperating websites from communicating in order to track you, and adtech tracking is hosted by cooperating websites.

          1. 1

            I don’t understand why it couldn’t be a permission. « xxx.com wants to access some of your data from yyy.com [Review][Allow][Block] »

            1. 1

              Well, it’s more that xxx.com wants to access your data from xxx.com, but one xxx.com is direct and one is embedded in yyy.com’s page. The point I’m making on is that this is impossible to block if yyy.com and xxx.com are working together, which in the context of ads they always are. As one possible “total cookie protection” break, yyy.com could set a cookie with a unique tracking ID specific to yyy.com, redirect to xxx.com with the unique tracking ID as a URL parameter, and have xxx.com redirect back to it. Your xxx.com and yyy.com identities are now correlated, and neither site had to do anything browsers could reasonably block.

        2. 9

          As a developer working for a company that makes an embedded video player that’s used across the internet: this semi-breaks some user preferences, like remembering volume and preferred caption language — now they have to be set per embedding domain instead of applying globally when they’ve been set once.

          And it thoroughly breaks our debug flags: during a tech support conversation, we can have users enable or disable certain features to track down where a bug is coming from. The UI for that is a page on our domain (the domain the embed is served from). Now users can set those flags, but they won’t actually do anything, because they won’t be readable on the domain where they’re really needed.

          We could possibly move the UI for that inside of the embed to make it work again, but A) it would look and feel bad, and B) it probably won’t happen for a browser with a 3% share.

          The Storage Access API offers very little help in this context: we can’t have the player pop up a permission request dialog for every user on every player load just to check whether they even have a debug flag set, so there would have to be some kind of hidden “make debugging work right” UI element that would trigger the request.

          1. 6

            Disclaimer: I trust you know this far better than I do, I’m just curious.

            I can see how this Firefox feature breaks that functionality, and it sounds like unfortunate collateral damage.

            For volume control, is that better handled by either the browser or the OS anyway?

            For their preferred caption language, can the browser’s language be inferred from headers?

            If a user wishes to override their browser’s language, it sounds plausible that this should be at the domain-level anyway. Perhaps I want native captions on one site, and foreign captions on a site I’m learning language from?

            And it thoroughly breaks our debug flags: during a tech support conversation, we can have users enable or disable certain features to track down where a bug is coming from. The UI for that is a page on our domain (the domain the embed is served from). Now users can set those flags, but they won’t actually do anything, because they won’t be readable on the domain where they’re really needed.

            How does Safari handle this?

            1. 2

              For volume control, is that better handled by either the browser or the OS anyway?

              Arguable. Browsers don’t do anything helpful that I know of, and the OS sees the browser as one application.

              For their preferred caption language, can the browser’s language be inferred from headers?

              We default to the browser language (which generally defaults to the OS language) but there are reasons why some users tend to select something different for captions. It’s not the end of the world, it’s just annoying.

              How does Safari handle this?

              I’m unsure, sorry. I don’t see a ticket about it, and I don’t have any Safari-capable devices on hand.

            2. 1

              Interesting, thank you. The caption and volume preferences thing sounds annoying. But on the other hand, it won’t be any worse for you than it is for your competitors which is… something, at least.

              You may want to take a look at how YouTube and Brightcove (off the top of my head) handle the debug part of this – right-clicking on a video provides all sorts of debug and troubleshooting information.

              1. 2

                We have that too, but it’s a different feature. We didn’t put the controls in there because we can give them a nicer presentation if they’re not stuck inside of an iframe :)

          2. 20

            (Disclaimer, I work for Firefox. Not on privacy though. :)).

            People may think this is technically uninteresting because they may have used custom settings or addons to block or isolate third-party cookies.

            That is true. I think the truly remarkable thing is that Firefox managed to pull it off for all users and by default. i.e., showing the ability to reduce and willingness deal with potential breakage for users without the technical background.

            1. 5

              It’s awesome. I hope Firefox’s market share is still big enough to “force” site owners to unbreak their stuff though. Otherwise we might start seeing “best viewed with Google Chrome” or some such soon…

              1. 2

                we might start seeing “best viewed with Google Chrome” or some such soon

                This is already true. I’m forced to use this terrible chat client called Symphony and it will only run on Chrome/Electron.

            2. 17

              I really like this. By my read, it brings the main benefits of container tabs to every site, by default. Now, AFAICT, I only need to use container tabs when I actually want to be logged into different accounts on the same site at the same time in different tabs. (So container tabs are still useful for keeping my login to my customer’s google apps separate from my personal google apps, etc.)

              I wonder how long it will be before adtech starts to circumvent this on a regular basis.

              1. 6

                adtech already uses other data besides cookies to fingerprint and track you, such as display resolution. See https://github.com/arkenfox/user.js for an even more restrictive starting point in firefox.

                1. 3

                  I’ve certainly seen tech demos of other tracking techniques. I was specifically wondering whether other approaches were currently common “in the wild” and whether they would get more common as cookies get sensibly restricted by browsers.

              2. 3

                I would like it if there were a user agent that took a more adversarial approach to the modern web; start with the idea that it shouldn’t leak data, and be willing by default to break applications by being principled. I guess I should get to coding with nyxt.

                1. 5

                  The problem, I think, is that such a browser would need to gain a lot of market share to drive an improvement in the situation.

                  Firefox broke the original browser monoculture by offering new features that allowed people to do things they couldn’t do before (like tabs, extensions, and general performance). Early Firefox users had to put up with breakage, but it was worthwhile because they got new features. Then, as Firefox got more popular, sites started working better on it because their owners didn’t want to lose traffic.

                  It just so happened that Firefox was also philosophically superior to IE (for many of us). Unfortunately, “philosophically superior” alone simply isn’t a good enough reason for most people to put up with breakage. And yes, I consider (most) data leakage a philosophical issue because it doesn’t (usually) impact an individual directly, it impacts groups, in the aggregate.

                  So if someone came up with a browser that didn’t leak any data, but added few or no other (widely desirable) features, then sure, a handful of people would use it, but not enough to force site owners to make their sites work with it. So the breakage would never go away and the broader situation would remain unchanged.

                  Anyway, my point is that a highly principled stand doesn’t seem like a great strategy in this case, if you actually want to improve the wider situation. If, on the other hand, you just don’t like the idea of personally leaking data, then sure, go for it!

                  1. 4

                    Oh, for sure. I am under no illusions about my relationship with the larger world of technology. My manager at Apple used to tell me “Apple would go broke if we made software for you” and he’s right. But, nyxt exists, so …. hmmm.

                    1. 1

                      I haven’t gotten into nyxt development, but there’s a ton of stuff I’d like to add, starting with “cosmetic” element blocking (like uBlock Origin).

                2. 3

                  Good for privacy, bad for usability. As we slowly make the web worse in an attempt to slow down the adtech that will eventually track you no matter what… Maybe blocking ads by default would be better for users?

                  1. 2

                    Wait, is this just third party cookie blocking? That’s really what it sounds like.

                    Well not quite: it still allows third parties to identify repea visitors by having a separate cookie jar, but that isn’t necessary.

                    1. 4

                      It’s like third party cookie blocking, but less strict. It will accept third party cookies, but only into a per-site cookie jar. It provides a lot of the benefits of third party cookie blocking, but breaks fewer things. That said… I still have third party cookie blocking on for my personal, non-work browser.

                      1. 1

                        So essentially Mozilla is finally doing what safari has been doing for almost 20 years now?

                    2. 2

                      I like the feature, and it means I can get rid of the temporary containers etc which I always hated managing (but did anyway because I am a nerd).

                      I guess one downside is that it might make SSO more cumbersome?

                      1. 0

                        So gmail will stop working? Or firefox will add an exception as usual?

                        1. 12

                          That’s not how the feature works.

                          1. 1

                            Care to explain why not?