221–230 of 339 posts
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.
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.
Earlier quoted context omitted.
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…
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 ju…
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?
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…
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?
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?
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.
Earlier quoted context omitted.
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 ju…
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.
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?"
Earlier quoted context omitted.
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…
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.
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.
Privacy wins aside, can anyone please help educate if third party single sign ons will still continue to work?
Earlier quoted context omitted.
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.
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…
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.
Earlier quoted context omitted.
> 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 iFr…
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.