This article describes Zendesk support for popular, industry-standard browsers that restrict how cookies are recognized and used. This article contains the following sections:
Apple Safari browsers
Recent versions of Apple Safari browsers include Apple’s Intelligent Tracking Prevention (ITP) safeguards. To protect personal information, these safeguards can restrict how first-party and third-party cookies are recognized and used in the browser. In turn, restricting cookie usage has an impact on many popular, browser-based applications, including Zendesk.
To address the impact of cookie restrictions in Safari browsers, Zendesk has introduced a new flow that recognizes when you are using a Safari browser on a host-mapped domain and prompts you to authorize Zendesk to use cookies. While logging in, you will have to acknowledge several prompts to indicate your acceptance of cookies in the browser. This behavior will be the same for agents and administrators.
To log in to Zendesk using a Safari browser
- Navigate to your Zendesk sign in page using a Safari browser.
The sign in page displays a warning that cookies are required to use Safari. To continue signing in using Safari, you will authorize cookies to be stored on your device.
- In the Cookies required to use Safari box, click Continue.
A new page displays information about the cookie requirements.
- On the Safari cookie requirements page, click Continue to acknowledge the requirement.
- On the sign-in page, again click Continue.
You will be prompted by a Safari dialog box whether or not to allow cookies to be used by your Zendesk domain.
- Choose Allow in the Safari dialog box to allow Zendesk to use cookies and website data while browsing the domain.
The page reloads again, and there are no longer any warning messages displayed. You can now log in.
- Enter your credentials to complete logging in to Zendesk and click Sign in.
Google Chrome browser v.80
On February 17, 2020, Google released Chrome v.80. This release includes a change to cookies (the SameSite update) which requires Zendesk to explicitly label any Zendesk cookies that can be used on other sites. Cookies without the proper labeling won’t work in the Chrome browser. Zendesk has completed the cookie labelling requirement and is not expecting any issues, unless you're using incognito mode to sign in
On March 19, 2020, Chrome released a feature that blocks third-party cookies when using incognito mode. Therefore, you are restricted from signing in to a host-mapped domain in incognito mode. As a workaround, don't use incognito mode to sign in, or use the toggle located directly in the incognito browser window to disable the block on third-party cookies.
Continued support for Safari and Chrome
At Zendesk, we’re working to maintain and improve Safari and Chrome support. We will continue to find the best way possible to manage these ITP and cookie updates and provide you with the best experience possible for you and your customers. We recommend following this topic for the latest information and updates.
64 Comments
"We'll provide another status update the week of May 11."
Hi Nicole, any update on this by any chance? Thanks!
Nicole S. , Caroline Kello
Per the comment here (and all of the comments, in general) when it comes to Safari problems: https://support.zendesk.com/hc/en-us/articles/360034788653/comments/360004629033
> "We'll provide another status update the week of May 11."
Has there been any progress on this?
It looks like there hasn't, and that the only workarounds that will potentially work for Safari users are:
It sounds like others potentially have had luck without having to enable cross-site tracking globally by either:
But, I don't have a Safari browser to test at the moment, and I haven't seen other users verifying this.
Are these findings correct?
Is ZenDesk actively working toward native, seamless functionality with Safari still? If so, can we get these continued updates on progress as suggested?
By its silence, Zendesk is making it clear that they are not willing to prioritize this problem.
That's really unfortunate. Insisting that people reduce the security settings of their browser to use Zendesk is unacceptable, especially when the browser in question is the 2nd most popular option when mobile devices are taken into account.
The combination of "Zendesk is broken in Safari" and the woeful state of the ZenDesk iOS app means that Zendesk is utterly unusable on an iPad. Who thought THAT was a good plan?
If Zendesk has any intention of fixing this, they should set a timeline and stick to it. If they don't, they should say so, so that those of us who have many Safari users -- or who just wish to use ZenDesk on the go with an iOS device -- can migrate to some other service.
Hi Lisa Kelly
Can you please give us an update. Nicole wrote "We'll provide another status update the week of May 11." and now it's end of June.
I have forwarded your request to our Product Management team.
Don't tell people you're going to give an update and never bother. When I signed up for Zendesk this issue was pending a resolution and I decided to give you guys the benefit of the doubt. With this issue and other issues I've tried getting support on it's clear that Zendesk is going to be a big waste of my time and money so I'm cancelling. My so called account manager recently tried helping me with a billing issue I'm having (after no response for two whole weeks and me having to followup to get one) he has proven to be either completely incompetent or he just doesn't care... either way I'm out of here.
Kevin Tauber I totally agree with you. Promising an update and not delivering is really a no-go. But sadly I'm very much looked in with Zendesk. We have thousands of users and so much history inside Zendesk that I'm really reluctant about switching to another plattform.
Hi all -- Don't expect any response (in terms of fixes or recommendations) from Zendesk on how to fix this issue: It affects too few of their vast amount of users for them to care. On our team, most people with Safari (various OSes, versions) are able to use Zendesk. Only a few like myself are utterly unable to. I can't use it with Chrome either, while many others can. I can use it with Firefox (the only way I can leave comments like this) but others can't on Firefox either. So it's probably due to a confluence of various factors that we all have in common, but most others do not. If the Zendesk dev team is not able to recreate, they also can't really fix it. It's unfortunate, and I still blame their sub-par Authentication method, which I believe is at the heart of this issue, and pretty much unique to them. That bad decision / implementation / programming makes me question the rest of their platform, especially the security aspect, but as Tobias Linder-Geiger mentioned, switching is a level of effort in certain deeply integrated organizations' processes that is simply not worth undertaking when a solution is to simply use another browser, annoying as that is. So for now, I have firefox on my computer, solely for the purpose of accessing Zendesk. Maybe that's really the only solution for you all as well.
That's not a solution.
"So it's probably due to a confluence of various factors that we all have in common, but most others do not. "
That's being entirely to charitable, because it suggests the problem isn't well-understood. It is. It's trivial to recreate.
Zendesk is just choosing not to do anything about it.
Hi folks,
We wanted to firm up our plan before responding, as the last update I gave we were still deciding on the approach. We will be moving forward with the implementation of the Storage Access API to unblock the logins on Safari. This will require us to introduce a new flow for the login experience. We’re working with our Design team currently to scope out the best implementation of this. We expect to have further updates to share with you in mid-July. Thank you all for your patience as we work through the implications of this solution.
Thanks, Caroline
Caroline Kello -- We appreciate the update, thank you. However, until the issue is actually fixed, please understand our skepticism, as this is a long existing issue that has had a few similar promises and supposed fixes in the past without any actual resolution. However, I look forward to this fix/release and am keeping my fingers crossed for it to happen and actually solve the issue.
Chet Farmer -- Looks like maybe I was wrong about their devs understanding / being able to replicate the issue? Maybe it happened to one of them or their execs, and a fire was lit under someone's arse? Let's see what happens. I'm not holding my breath though. ; )
Er, yeah, you definitely were. This has been a well-understood problem from day one. Nobody was confused about the cause.
Caroline, ZenDesk made a commitment to provide an update by a certain time, and then failed to meet that commitment. Now you ask us to wait again for mid-July, which I just assume at this point actually means late August.
I'll believe it when I see it.
Totally understand that you're not very open to trusting me to come back with updates, as I failed to update when I said I would. Your scepticism is valid and I hear you. I'm promising to do better and the proof is in the pudding.
Caroline Kello so when will pudding be served? We are paying customers and are waiting for a solution since October 2019...
Hi everyone,
Work on the Storage Access API is progressing, we’ve implemented the new designs and plan on releasing this on Thursday July 23, 2020.
Here’s the new flow that is being introduced:
This behaviour will be the same for agents and end-users.
We’ll continue to test, there are still some kinks to be ironed out, but if things continue to progress well we’re on track for next week. I’ll let this post know closer to the date if something changes. Happy Friday!
Um, correct me if I'm wrong, but this still sounds like you aren't fixing the problem.
If Safari under normal security settings will not work with Zendesk, then Zendesk is BROKEN and needs to change. If you've taken months to come up with a scheme to tell Safari users to change their security settings, man, that's pretty ridiculous.
Am I wrong here?
Hey Chet Farmer,
Zendesk's solution here is reasonable, IMO. Rather than forcing the user to allow all cookies like was previously required, they're requesting specific access for Zendesk via the Storage Access API, a much better solution.
By asking the user to specifically allow only Zendesk to do this, you're not weakening the entire browser's security like we had to before by choosing an all or nothing cookie policy. If you trust Zendesk (and if you're using the platform, it's a reasonable assumption you do) this shouldn't be an issue to enable. Yes, it's an extra step, but it sounds like it's a one-time step from Caroline Kello's description. If you choose to keep the more restrictive Safari defaults in place, they continue to apply and protect you elsewhere on the web, you're just giving Zendesk a trusted exception.
Most modern applications on the web will require cookies to track user sessions and information, the idea that Zendesk operate in a cookie-less manner would be a pretty massive technical feat to pull off. In the meantime, we'd get nothing because it would take months if not years to do. I'm sure there are many other features we would like to see worked on in the meantime. IMO this change strikes a good balance between security, flexibility and speed of delivery.
I understand very well what cookies are, Dan.
This sounds like it's giving Zendesk rights to read ANY cookie instead of working to correct Zendesk's need to do cross-site access and scripting. That's not a good fix. It's in particular a bad fix given how long it took them to come up with it.
Let's wait and reserve the right to decide if their implementation is bad or not until they actually come out with it.
No offense to Caroline but I am relatively sure she is not one of the engineers. So, making assumptions based her wording from a technical standpoint is probably not the most accurate.
Based on my interpretation of her post, the restrictions would only be lifted for Zendesk. But, again, let's wait until we actually know what is happening.
That being said, I do feel that it is completely accurate to state that IF they are implementing as Chet suggested then that would not be a great idea.
As an aside, a very brief overview of the Storage Access API seems to clarify the issue a bit, according to the Storage Access API page,
Update time: it's now July 23 and the new flow that unblocks customers using hostmapping on Safari browser is available to everyone. This article has been updated with new details.
Please do let us know in this thread if you run into any issues.
Still broken. Login button never un-greys.
Chet Farmer
I have not had a chance to test it yet but what are you experiencing?
Are you getting the new notification?
Is it not letting you accept the notification?
What versions of Safari and OS are you running on?
Are you getting any new errors or the same old ones?
--------------
I want to make sure I test whatever you are using so I can be sure if the issue is fixed or not before telling my customers.
Hello,
I'm a browser engineer working on Firefox, and users of the pre-release versions of our browser experience the same breakage as Safari users experienced before this fix. Users of the normal release version of the browser may soon experience the same breakage on zendesk-supported sites. I've love to work with you to get ahead of that.
Firefox also supports the Storage Access API, and it requires less intermediate steps to use it in Firefox than are required in Safari. I've posted a summary of the differences necessary here: https://bugzilla.mozilla.org/show_bug.cgi?id=1540810#c29. Our implementation of the Storage Access API is fully documented here: https://developer.mozilla.org/en-US/docs/Web/API/Document/requestStorageAccess.
I'm happy to engage further if you have any questions.
Hi Steven,
Thanks so much for reaching out! The team is investigating the Storage Access API for Firefox and Edge in the coming weeks so we'll definitely reach out if we run into anything unexpected with Firefox. Much appreciated.
Cheers, Caroline
I've been following this discussion since April, when I could not login on the Backblaze support site to view an active support ticket.
It just happened again with a new support ticket. Fortunately, I knew this time to switch from Safari to Firefox. But Steven Englehardt's comment 17 days ago (2 back from this comment) indicates Firefox may not be an option much longer.
The "[Guide Q&A] End users can't sign in with Safari" topic indicates this problem was first reported on October 8, 2019. Is there any hope it will ever be fixed?
-- Ward
Is there any plan to address this ?
As you probably know, it's pretty common in corporate networks (and security conscious users) to enforce having 3rd party cookies disabled. This is stopping us using the host mapping feature where it's needed the most.
I understand you need essential cookies enabled but requiring third party cookies in order to be able to login is a very abusive approach. I'm not even mentioning that your cookie policy is not mentioning the requirement for 3rd party cookies for login: https://support.zendesk.com/hc/en-us/articles/360022367393-Zendesk-In-Product-Cookie-Policy
Thanks !
@Traian Vila - Thank you for sharing and agree
Caroline Kello,
May we please have an update in regards to the above comment?
"As you probably know, it's pretty common in corporate networks (and security conscious users) to enforce having 3rd party cookies disabled. This is stopping us using the host mapping feature where it's needed the most.
I understand you need essential cookies enabled but requiring third party cookies in order to be able to login is a very abusive approach. I'm not even mentioning that your cookie policy is not mentioning the requirement for 3rd party cookies for login: https://support.zendesk.com/hc/en-us/articles/360022367393-Zendesk-In-Product-Cookie-Policy"
Regards,
Emil
Hi all,
Our goal, ultimately, is to eliminate our use of third-party cookies, so that we will no longer be limited by different browsers’ cookie restrictions. Eliminating this dependency will also fix the issues that third-party cookies cause with host mapping and some integrations.
We’ll start by working on expanding the Storage Access API (as implemented for Safari) to other browsers that support it, while also investigating and analysing the impact of removing our use of third-party cookies. In order to accomplish this, we are dedicating time throughout the rest of this year and through 2021 to this project.
It will be a long process, as it requires significant analysis on the potential impacts to features and customer integrations, migrating those to first-party cookies, and the rewriting of no small amount of code. We will continue to keep this thread and article updated with information as we have it. Thank you all for your feedback and patience.
It is truly unbelievable that this issue hasn’t been resolved by now.
Most of the companies I know use zendesk for resolving customer issues. The failure to be able to login compounds the customer’s frustration because before they can deal with the issue that brought them to the zendesk portal they have to figure out how to login at all. At first I was frustrated with the companies I have relationships with until I realized their only fault was depending on zendesk in the first place.
This issue has been going on for over 18 months if I’m not mistaken. It is amazing that this was not a crop everything, holy s$#t fire drill. This is crucial to your mission.
As of right now Chrome and Microsoft Edge don’t work at all on iOS. Safari and Firefox work, but only if you do the multiple clock ‘Continue’ dance. On macOS chrome does work but safari still requires the “Continue” two step process.
chrome + edge have almost an 80% market share on desktops and 50% on tablets. How is it possible that this hasn’t been addressed yet?
I can’t believe in today’s world I have to switch browsers and perform ridiculous rituals just to logon to a support portal.
I can’t say I would ever choose or recommend zendesk based on the user experience it provides. Unfortunately, I do have to use it for some interactions. Perhaps it is the indirect relationship you have with many of the end users has shielded you from the pain that this brings to users.
Please sign in to leave a comment.