Because it breaks a lot of things like SSO providers (although I completely agree with you, screw that, make it the default and add exceptions as necessary like Mozilla is doing now).
I've had third party cookies completely disabled for years, and first party cookies only allowed by exception. It works fine on everything I use except for whatever it was Atlassian were (are?) doing with their very odd collection of about two dozen domains they round tripped through on authentication.
To be honest though, browser fingerprinting makes this mostly irrelevant unless you carefully use a script blocker with a whitelist too. Any domain that includes trackers that drop third party cookies almost certainly includes scripts that can fingerprint you and send results to a server without using a third party cookie.
(A bit of OT)... which is why I am considering SPAs to be complicit in 'evilness'. All these webpages that require js for no real reason is generally making the web insecure and implicitly hostile and difficulty to navigate. Very few have the mental overhead to evaluate each site, so most just let any page do what ever it wants. Tracking and miners be damned.
This is just my hunch as I work in analytics and deal with cookies a lot but both Salesforce and Atlassian appear to intentionally trade off the third party inconvenience because their products are enterprise (you have to log in for work) and they rely on upsell/cross sell across their products which they host on different top level domains. So forcing the third party cookie helps immensely with their sales and retention, and doesn't hurt usage because it's often required for work and if you need to work around it, you usually can find a way if you are so inclined.
If they had used the same domain for their products historically and just separate subdomains they wouldn't have to make this trade off, but it probably also helps with third-party ad networks/segmentation to get folks to turn it on anyways.
Weirdly for me Atlassian doesn't work when I have the spoof referrer enabled in about:config. Like why does referrer, a property that is a header, define whether my login is valid or not?
I've worked on (non-Atlassian) SSO projects where the provider used the referrer to send the client to the page-after-logout (and occasionally page-after-login) if they weren't set as parameters in some circumstances.
Here's a reference to a F5 device providing SAML SSO services and having a similar issue:
I actually had a member of Atlassian's "security dev team" tell me in a support ticket I opened about being unable to login with referer headers disabled that:
> since we cannot discount the possibility of malicious users programatically generating tokens and forcing them upon users, we check the referer header to ensure that the request chain was initiated in the one place that we're comfortable with: id.atlassian.com
I had the same problem and tracked it down to uMatrix's quite reasonable spoof-referrer default, which breaks nothing else. Just Atlassian's sign-in, which seems to bounce you around to several domains before it lets you in.
Not only does redirect based login work, it's an inherently better model than sharing cookies.
With shared cookies nothing stops site A from taking a copy of your cookie and using it to impersonate you on site B. With redirect based login the identity provider has to authorize each application that is being accessed and each site has its own session cookies.
The main problem is dealing with globally revoking access but that's usually solved with shorter termed session cookies that periodically need to be refreshed from the identity provider.
Site A can’t access 3rd party cookies. Cookies only can be accessed by the domain they are created on. Otherwise any site could toss a 1x1 image pointing to any website and steal the cookies.
Could a site fix this by delegating a subdomain or CNAME to the SSO provider like sso-company.example.com so that the cookie is still using the same domain, but pointing the IP to the SSO provider? Assuming the SSO provider supports this, that is. I believe OKTA supports this method.
I mean effectively today hardware you or your boss owns is doing most of the work of tracking yourself.
This is making them have to allocate resources to achieve the same effect. Like taking lojack off of your car and phone, and making 'Them' have to tail you and scour security footage like in the old days. It's more expensive. Expensive things do not scale, so you have to prioritize who is worth the cost. People who are under legitimate suspicion of causing harm. Less 'by-catch' to use a commercial fishing concept.
When it's cheap to harass everyone, nobody is 'safe'. But when terrorists can't be tracked at all, nobody is 'safe' either. So we have checks and balances.
I regularly use nginx to reverse proxy third-party API calls. I use it to protect API keys.
In my case, I strip all cookies and sensitive headers. One must keep in mind that the browser will treat it as a first-party request and the security implications that has. You may have to filter or modify cookies/headers.
well sso providers would still work, if it was made correctly?
sso works without cookies. if I implement google sso I would not login via the google supercookie
there is a state parameter? so If I want to have a cookie that passes stuff, I can just store my stuff inside a cookie and pass the stuff inside the state param, there are so many possibilites via openid (which is super easy), I do not know how saml2 works, which might be different tough.
I know of a token system that some questionable engineers started pushing session state into and since it shipped before anyone noticed, walking that back turned out to be quite a chore. What was supposed to be a couple hundred byte cookie started hitting max cookie length warnings in other parts of the system.
When people need to keep a door open, if they don't see a doorstop in the immediate vicinity after two seconds of looking, some will just use whatever heavy object that is closest and consider the problem 'solved' instead of managed.
I needed data, I didn't know where to put it, this thing can give me data, boom, solved.
Not a huge loss, if you depend on federated logins its just a matter of time until Google or Facebook's algorithms decide to ban your account without explanation or recourse and then how do your users access your site? All you'll be able to do is try to shame the companies on social media and hope enough people are outraged that the company takes notice.
