Zendesk support for cookie-restricted browsers (Safari, Chrome, Firefox)

Return to top
Have more questions? Submit a request

118 Comments

  • Joseph Crivello

     

    I am blown away that Zendesk would now claim to not know what the problem is here after it has been explained and discussed in great detail over the course of years in this thread. Caroline Kello seemed to explicitly acknowledge the problem in her post three months ago, but now doesn't think that there is a problem? I don't even know where to start with this. Hard to believe...

    2
  • Krzysztof Żelechowski

    Chet, did you try my work-around?

    0
  • Tiago Soromenho

    I agree that it is really ridiculous that Caroline Kello seems oblivious to all the previous comments, the documentation of the issue in this thread, and the issues that so many of us continue to have.  But there might be a reason she's unaware of the painful history:

    The top / original article has been updated with instructions (for mac/safari) _that actually work_! (I just tried it out). I am now able to login with Safari, whereas it's been years since I had to use Firefox only to be able to login.

    Seems like there is now a pop-up that asks whether or not to allow Zendesk to use cookies.  The prompt is general, and doesn't share what cookies/scope that we're allowing them to access, but I would assume fairly safely that we're authorizing Zendesk to store and access cookies associated with our host-mapped domains, instead of storing them in the third party sites. If so that IS a huge improvement!

    I think the issue may be that this change was not communicated in the comments. Last comments were from Nicole Saunders about three months ago, and then nothing.  This fix seems newer than that -- even if the top article says it was last modified 5 months ago. I know I've tried to do what the article mentions many times since, and this pop-up feels new; I don't recall seeing it before, nor it working, certainly.  I might be wrong, and for some unrelated mysterious reason, it now works for me... (always a possibility, I suppose.)

     

    2
  • Chet Farmer

    I tested with Safari before I replied. The stated instructions don't work, and I have yet to see a workaround that is acceptable.

    0
  • Michael Bierman

    @Tiago Soromenho This is what I see on Safari (macOS) 

    If I logged out and back in I skip the extra dance back and forth (at least for now). I don't know how long lived this workaround is in Safari. 

    I do know that it does not work whatsoever in Chrome which means variants like Edge and Brave also don't work. 

    I find it appalling that zendesk has not solved this problem by now. 

    2
  • Tiago Soromenho

    Michael Bierman - I also see that yellow "Cookies required to use Safari" screen when I log out, clear cookies associated with my domain, and try to log back in. (To clear only those cookies, on Safari menu, go to Preferences > Privacy. Make sure "Prevent cross-site cookies" is checked, which is what is preventing Zendesk from working properly. Click on "Manage Website Cookies" button, and on the resulting screen, type in your domain name. When it appears on the list below, click on it to select it, and click on the "remove" button.  

    With my cookies all cleared for that domain, I then click on that "Continue" button in the yellow "Cookies required to use Safari" warning box, and it then shows me a screen like this:

    When I click on "Continue" it goes back to that same screen with the same "Cookies required to use Safari". Clicking on "Continue" again gives me this pop-up:


    When I click "allow" the page behind it refreshes and now the yellow "Cookies required to use Safari" prompt disappears and I can log in.

    If I then log out, I don't get the yellow "Cookies required to use Safari" again. Although sometimes I do get it again, not sure why the inconsistency. Clicking "continue" on it, I get the "Safari Cookie Requirements" page, clicking "continue" returns to the page with the yellow warning, and clicking "continue" a third time gets me to the login page without the yellow warning nor the pop-up. Kind of silly, but that's the way it seems to be working for me.

    If I clear my cookies again for my domain, it resets everything and I have to get to that Safari "Allow" pop-up again.  It could be that this is a new Safari thing to make an exception and allow a third party site (Zendesk) to access cookies placed on another domain (mine, with the support. hostmapped subdomain.)  My Safari version is: 14.1.1 (15611.2.7.1.6, 15611) -- If it is, I don't know of a way to check and manage what those exceptions are, other than in the cookie itself (because once that cookie is removed, the prompt appears again.)

    As to Chrome, ever since I fully removed it from my Mac, it has run so much faster that I'll not consider installing it back any time in the near futures (Get a program from the Apple Store called Little Snitch and then open Chrome and Safari. You'll see that with each new window/tab, Chrome sends out data packets to 50 or destinations, to Safari's only 2 or 3.)

    Given how inconsistent this login issue is, I'd say there are certainly some flaws in its implementation, and given the history of this issue, it is unfortunately not too surprising.  But we do need to continue to provide these feedbacks because it's obvious their QA process isn't catching these flaws. I am glad, however, that there does seem to be progress (some, even if by Apple and not Zendesk.) even if the communications haven't been stellar...

    1
  • Caroline Kello
    Zendesk Product Manager

    Stepping back a bit to understand if there’s something I’m missing in this discussion:

    Login on hostmapped accounts using Firefox and Safari (including iOS) leverage the Storage Access API flow (implemented in H2 2020) - this is called out in this article and is a flow that takes the user through explicitly allowing a Zendesk cookie to be dropped and accepting it allows the user to log in. Nothing should be broken here and users should be able to log in. If the issue is that this flow isn’t working and you’re still not able to log in, that’s something we need to get more details on and understand what’s not working.

    If the issue we’re discussing is the fact that we have this Storage Access API flow at all; I do agree that the login flow shouldn’t rely on third-party cookies and it is our intention to remove the use of them across the platform. We’re currently working through a couple of options and putting those forward for validation, once we have more insight there I will bring proposals to this group for feedback as well.

    0
  • Brett Bowser
    Zendesk Community Team

    Tiago Soromenho Thanks so much for jumping in here and sharing the steps you took to log in!

    Michael Bierman and Chet Farmer Appreciate both of you clarifying that the workaround provided is indeed not working for you and I think that's where the confusion was coming from! I'm going to create a ticket for both of you so we can look at this internally and figure out why exactly it's not working. You both will receive an email shortly stating your ticket has been created so if you do have any additional information to provide feel free to reply back to that email.

    I understand this can be frustrating but do know we hear you and we appreciate you sharing your concerns with us!

    0
  • Brett Bowser
    Zendesk Community Team

    Peter Steinberger Just want to confirm with you as well, is the issue that the work-around provided in the above article is not working for you either? If so, I can create a ticket for you and get it assigned over to the appropriate team.

    Let me know!

    1
  • Chet Farmer

    The workaround is LITERALLY ALLOWING CROSS-SITE TRACKING.

    I will not do that. It's not an acceptable path for me, or for my customers. So no, it's not "working".

    Until & unless you change this expectation, there's no point in you creating a ticket for me.

    3
  • Joseph Crivello

    Chet Farmer +1

    Enabling cross site tracking is a completely unacceptable "work around" for many reasons. First and most obviously, Zendesk is asking its users to degrade the security of their ENTIRE BROWSING EXPERIENCE across all websites. Second, it requires end users to follow a convoluted process to implement the workaround which requires handholding from an agent. This makes it completely impractical for almost all of the use cases that are being complained about in this thread. It is just so obviously unacceptable that the mere proposal of it as the sole workaround (for years now) rises to the level of being insulting. The message being sent here again and again is that Zendesk doesn't care about the customers of its core product.

    3
  • Michael Bierman

    @Tiago Soromenho Correct, if the cookies are intact this is only a problem in Safari the first time you login. Of course cookies don't always remain intact and functional. 

    But yes, the Safari experience is better than other browsers when visiting a zendesk powered portal, but Chrome based browsers are still fully broken. I can't think of anything else in my daily workflows that are browser specific. This isn't 1990. 

    0
  • Michael Bierman

    @Brett Bowser as best I can tell things are working as designed. The design is just poor.

    As @Joseph Crivello said, requiring Enabling cross site tracking is a terrible approach that puts users at risk and undermines state of the art browser security.

    Looking at my Chrome settings again, the problem could be that I have, "Block third-party cookies" set on. I don't recall if this is Chrome's default but I think that is what Chrome calls the Safari setting in @Tiago Soromenho's post.

    So it is likely that if I am willing to lower security for all websites perhaps even Chrome can use this workaround. Since Chrome is my primary browser I will keep the setting where it is. But that forces me to compromise Safari and switch to it if I want to easily sign into a zendesk powered portal. 

    1
  • Chet Farmer

    "Block third-party cookies" is indeed the default now for Chrome and Safari, and that's the crux of the issue. NO USER SHOULD TURN THIS OFF, FOR ANY SITE. Asking a user to do is absurd.

    1
  • Peter Steinberger

    Brett Bowser I - like the others - missed that the article here was updated with the new flow. I tested this locally and it seems to *mostly* work. The process seems a bit wonky (required some browser reloading) but given I also run macOS Monterey, it might just be a beta issue. After some trying it worked. The process and multiple tabs and reloads and alerts is everything but smooth though.

    For the latest complaint I'll circle back why it didn't work for them - it is possible that it's an existing cookie that interferes here (like others mentioned as well), which again shows how fragile the current hack is.

    I can also confirm that this hack works on iOS 15b3. (However, Twitter Auth seems broken there)

    It is good to hear that future improvements are planned - logging into a support system shouldn't be so difficult.

    3
  • Tiago Soromenho

    Chet Farmer, Joseph Crivello -- I think you guys are missing that this does NOT "allow cross site tracking" in a general manner. The "Allow Cross-site tracking" should remain OFF.

    The issue here is that IF you access the Zendesk through a subdomain like "https://support.your-company.com" the actual service (Zendesk) is not where your domain is hosted. They need to set a cookie (which admittedly is old tech) with your session ID. They can't do that _because_ their servers are not associated with your domain, just one of your sub/domains is mapped to theirs.  

    The issue is that before, the browsers either allowed ALL cross-site tracking or NONE.  What Apple has enabled in Safari now is to allow an exception to be made on a PER CASE basis.  Clicking the "Allow" button on the pop-up does NOT enable ALL cross-site tracking.

    Again, this is ONLY when the Zendesk service is exposed to you or your customers in a domain-mapped url like support.your-company.com.  If you were to access Zendesk using their provided sub-domain with your company ID (usually your-company.zendesk.com) this is not an issue.

    4
  • Chet Farmer

    I spent years as a web developer. I understand what's going on, Tiago.

    The stated workaround explicitly allows Zendesk to track visitors across the web. That's not an acceptable path for me, for my people, or for my customers.

    0
  • Tiago Soromenho

    Hi Chet Farmer -- Do you have any evidence of your claim?  

    My understanding of the Safari documentation is that the exception is specifically to allow Zendesk.com to set a cookie on a customer's browser whose scope is your-domain.com. Meaning that only Zendesk can read your-domain.com cookies (and possibly only THAT cookie that it set itself, but that I'm not sure about.)

    https://support.apple.com/guide/safari/prevent-cross-site-tracking-sfri40732/14.0/mac/11.0

    And specifically the paragraph (emphasis mine):
    "Social media sites often put Share, Like, or Comment buttons on other websites. These buttons can be used to track your web browsing—even if you don’t use them. Safari blocks that tracking. If you still want to use the buttons, you’ll be asked for your permission to allow the site to see your activities on the other websites.

    The prompt that allows that exception specifically states: Do you want to allow zendesk.com to use cookies and website data while browsing "your-domain.com"?

    It doesn't say "Allow zendesk.com to use cookies on other websites" which would instead indicate that then, yes, it could put a cookie on your browser and retrieve it from any other site it partners with.

    Hence I don't understand the mechanism by which you believe that Zendesk can track visitors across the web? Even if a customer (or a CSR) has visited your support.your-domain.com site has received a cookie from Zendesk whose scope is your-domain.com, and either go visit say, google.com or get-away-adventures.com, those sites _cannot_ access any cookie whose scope is your-domain.com, whether it was placed by your site or Zendesk.

    The previous issue that we all had an issue with is that Zendesk needed to place a Zendesk.com scope cookie while the site accessed had a url/domain of support.your-domain.com and it needed the user to open up their cross-site tracking option in order for Zendesk to place and retrieve its own cookie on your site. With this new "exception" capability from Safari, this is no longer needed, and we can continue to keep our "cross-tracking" setting turned off, as it should be.

    Hence, what am I missing that gives you the belief that they can track visitors across the web? Can you explain the mechanism you see at work here? I'm genuinely interested as it's very possible I am overlooking something.

    3
  • Chet Farmer

    Any x-site access is anathema to most people today.

    Zendesk's failure here remains a problem.

     

    1
  • Max McCal
    Zendesk Product Manager

    Hi, all - I wanted to summarize what I hear to be the concerns raised in this thread. There are some very good concerns, and we know the current situation is not optimal.

    Sign in on host mapped accounts was completely broken by changes made in certain browsers behavior. We’ve resolved this in late 2020 for Safari (incl. iOS), Firefox and Edge by using the Storage Access API. This has introduced a new experience during the sign in flow where we explicitly ask for permission to drop a Zendesk cookie only for the duration of your browsing. This does not require cross-site tracking to be enabled. This article has been updated to reflect this new experience. 

    This new sign in flow is not our end state solution. It’s been put in place to allow any sign in at all for Safari, Firefox and Edge browsers, given their new restrictions. We intend to fully cease using third party cookies as part of our login experience for host mapped accounts. 

    This will be a complex change and take time. We’re validating proposals at the moment, and  will share progress with this thread. For now, login on host mapped accounts is not broken, but it’s suboptimal. We’re aiming to improve this, and we appreciate all your feedback along the way.

    3
  • Jon Yergatian

    Caroline Kello and Max McCal - There's clearly a lot of opinions and frustrations being expressed in this thread so it's great to see your input and acknowledgement of the issue. 

    To my understanding, Chrome will be adopting similar changes as Safari and Firefox later this year. If true, this would mean the workflow created using the Storage Access API would need to be ported to Chrome as well. I guess my question is two fold:

    1. Is Zendesk aware of this upcoming change? if so;
    2. Does it influence the timeline as you work towards removing the use of third party cookies from the login experience?
    0
  • Caroline Kello
    Zendesk Product Manager

    It's my understanding that Google has delayed their plans for blocking third-party cookies until 2023, if they stick to that new timeline we will have our changes in place well before Chrome implements their restrictions. If for some reason they move the timeline earlier again, our best approach is to leverage the Storage Access API which I believe Chrome is adding support for

    1
  • Michael Bierman

    @max, it is suboptimal for most browsers and broken for the browser with dominant market share. So really poor situation overall.  

    0
  • Jon Yergatian

    Caroline Kello - I stand corrected. Thanks for sharing that link!

    1
  • Mark Kono

    Using Firefox, the initial window comes up about cookies but when I click on Continue, it simply reloads the current page and does not take me to the secondary page to sign in.  Therefore I'm stuck in a loop.  I've checked my cookie settings and made adjustments but still get that same window repeat.  I'm forced to use Chrome which is slow and slows down my computer significantly.  How can I remedy this with using just Firefox?

    1
  • Caroline Kello
    Zendesk Product Manager

    Hey Mark - are you using Firefox on iOS?

    0
  • Mark Kono

    Hi Caroline-

    I'm on a PC at work using Windows.  I haven't had any issues at home on a MBP.

    0
  • Michael Bierman

    The “sub par” experience in Chrome on iOS where we had to do the tap dance between sites no longer works at all. Unless I’m willing to allow all third party access to all sites, I can’t login to zendesk portals at all as shown below. 

    After what two years of being broken, I don’t expect that this will be fixed anytime soon. 

     

    1

Please sign in to leave a comment.

Powered by Zendesk