Recent searches
No recent searches

Tiago Soromenho
Joined May 13, 2021
·
Last activity Oct 25, 2021
Following
0
Followers
0
Total activity
10
Votes
3
Subscriptions
2
ACTIVITY OVERVIEW
BADGES
ARTICLES
POSTS
COMMUNITY COMMENTS
ARTICLE COMMENTS
ACTIVITY OVERVIEW
Latest activity by Tiago Soromenho
Tiago Soromenho commented,
Hi @... -- 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.
View comment · Posted Jul 15, 2021 · Tiago Soromenho
0
Followers
2
Votes
0
Comments
Tiago Soromenho commented,
@..., @... -- 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.
View comment · Posted Jul 14, 2021 · Tiago Soromenho
0
Followers
3
Votes
0
Comments
Tiago Soromenho commented,
@... - 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...
View comment · Posted Jul 14, 2021 · Tiago Soromenho
0
Followers
1
Vote
0
Comments
Tiago Soromenho commented,
I agree that it is really ridiculous that @... 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 @... 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.)
View comment · Posted Jul 14, 2021 · Tiago Soromenho
0
Followers
3
Votes
0
Comments
Tiago Soromenho commented,
After more than a year of no longer having Zendesk access due to this issue, even following the updated directions of the article above, I was able to get it working by doing the following:
1) In Safari menu, select "Preferences" and then click on the last tab "Advanced" and select the last item in the bottom "Show Develop menu in menu bar."
2) When on your Zendesk login page with the "Cookies required" warning across the top of the page, select Menu > Develop > Disable Cross-Origin Restrictions:
3) Now click on the "Continue" link in the yellow warning box in the login page. It will ask you if you want to allow the site (likely something like support.yourdomain.tld) to allow cookies from another domain (zendesk). Say yes. It should then return to the main sign-in page without the warning. You can now disable the "Disable Cross-Origin Restrictions" to return Safari to its safe state, and in my case, I've been able to use Zendesk fine during that session.
4) It does seem that I need to enable "Disable Cross-Origin Restrictions" each time I sign in, but that's only for that sign-in page. Once it reloads without the warning, I just turn the restrictions back on again.
Not the most elegant solution, but it's better than having to keep opening another browser specifically configured with less safe settings just to be able to access Zendesk.
Hope this helps some of you!
View comment · Posted Apr 13, 2021 · Tiago Soromenho
0
Followers
1
Vote
0
Comments