4 ms·

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 wha

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.

stilisstuk 6y ago
(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.
- edeion 6y ago
  SPA: single page application (I actually had to look it up... Shame on me.)
dastx 6y ago
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?
- roywiggins 6y ago
  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.
- nl 6y ago
  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: https://www.devcentral.f5.com/s/question/0D51T00007npfjw/chrome-browser-new-default-referrerpolicy-and-saml-problems https://www.devcentral.f5.com/s/question/0D51T00007npfjw/chr...
  - ratherbefuddled 6y ago
    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 Make of that what you will.
  - dastx 6y ago
    Providing this is the reason Atlassian uses the referrer, then this seems reasonable usage. Thanks for clarifying!
- Thorrez 6y ago
  Some sites use referer for CSRF protection. If they do that an you spoof your referer, they think you're being CSRF attacked and block it.
codezero 6y ago
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.
SamWhited 6y ago
> makes this mostly irrelevant Solving a problem isn't irrelevant just because there are other problems; there's definitely more to do, but this still has value.

stilisstuk 6y ago

(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.

edeion 6y ago
SPA: single page application (I actually had to look it up... Shame on me.)

dastx 6y ago

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?

roywiggins 6y ago
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.
nl 6y ago
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: https://www.devcentral.f5.com/s/question/0D51T00007npfjw/chrome-browser-new-default-referrerpolicy-and-saml-problems https://www.devcentral.f5.com/s/question/0D51T00007npfjw/chr...
- ratherbefuddled 6y ago
  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 Make of that what you will.
- dastx 6y ago
  Providing this is the reason Atlassian uses the referrer, then this seems reasonable usage. Thanks for clarifying!
Thorrez 6y ago
Some sites use referer for CSRF protection. If they do that an you spoof your referer, they think you're being CSRF attacked and block it.

codezero 6y ago

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.

SamWhited 6y ago

> makes this mostly irrelevant Solving a problem isn't irrelevant just because there are other problems; there's definitely more to do, but this still has value.