Tested in firefox, got the same warning:
So as the warning says, the sandbox URL is the problem.
(The links if used in a document instead of rich text doesn't raise this problem)
I just reported it as a detection problem. does anyone has a workaround?
Also, dunno if this is the cause of another bug ->
setting links as a popup windows in rich text doesn't seem to work.
Hello @luiiuuuiiiii , welcome to the forum.
Please describe more specific, what you are / were doing, to get this warning. This information is missing. You mention in your second posting "links in a document instead of rich text", so I guess this is the trigger?
Info for others: "sandbox.cryptpad.info" is the offical so called sandbox domain of cryptpad.fr .
This may be a bug in the rich text app or the domain is newly blacklisted somewhere - or something like that.
Please give additional info as described (or more if you like) so that hopefully the CryptPad team can give a hint. Thank you.
Disclaimer:
I am NOT part of the CryptPad team and I do not speak for the CryptPad team. I am a user helping other users. I got moderation user rights for the forum from the CryptPad team to help a bit, because we all are the community, but that's all.
AlexQ
Hello @AlexQ, thanks for your reply!
Sorry I didn't describe it better.
I'm working on a rich text document at cryptpad.fr.
Does any link in a rich text document trigger the warning?
Yes, any link in the richtext document will trigger this problem.
Did it work correctly some time before now?
Yes, I had the normal experience, indeed just now, it works normally on another cryptpad server I have access to, but not on a cryptpad.fr. So I assume it must be the problem of the sandbox.cryptpad.info url.
or the domain is newly blacklisted somewhere
This indeed sounds like the problem. Normally the sandbox url always asks when clicked on external link "You are about to leave cryptpad.fr. Are you sure you want to visit 'xxxxxx'?"
I am trying to create a document that I can share with clickable links. I tried creating a regular document, but in the shared version, the links are not clickable. I tried creating it as a rich-text document, but when I test the shared version and click the links, I get this in Chrome and am not able to open the links. Is there something I should be doing differently to be able to share a document with clickable links?
Hello,
You did nothing wrong, it's just another fuck up from Google. And other web browsers who bundle Google services such as "Google Safe Browsing". It can easily be disabled on Mozilla Firefox.
Hope this helps!
I reported the issue using the form Firefox let you fill for this purpose when visiting the page.
We had the same issue in the past with Microsoft Defender SmartScreen. We got the URL unblocked in a few days. However, as Google is a blackbox we can't interact with (are humans still working at Google??), there is not much we can do about it right now regarding the Google Safe Browsing issue.
The easiest, quickest workaround for this on the user side is to disable this functionality on your web browser.
For more information about where this privacy functionality comes from our side, you can read about it in our documentation: https://docs.cryptpad.org/en/dev_guide/basics.html#content-security-policy-csp-and-security
Mathilde thank you, I did the same.
It's just a bit annoying when sharing a lot of links using richt text doc becomes inconvenient.
I found that it's not sandbox.cryptpad per se, it's the /bounce url.
so if the blacklist doesn't resolve (I hope it will soon..)
perhaps the workaround must be to somehow skip/change the bounce url.
Hello,
luiiuuuiiiii perhaps the workaround must be to somehow skip/change the bounce url.
Skipping it isn't an option as it's a core privacy functionality of CryptPad. However, we though about changing the URL on our flagship instance.
The only issue we see with this is that it will likely end up being flagged as phishing as well by Google. Also, with the submitted reports for false-positive, they wouldn't be able to replicate the issue anymore. Ideally we would like the issue to be fixed on Google's end for good.
As mentioned in an earlier post, Google Safe Browsing services can easily be disabled client-side, directly from your web browser. If you care about your privacy, it's likely something you'd want to do anyway. Otherwise all your browsing history is automatically sent to Google on real-time, leaking quite a lot of information about yourself and/or your activities.
Mathilde For more information about where this privacy functionality comes from our side, you can read about it in our documentation: https://docs.cryptpad.org/en/dev_guide/basics.html#content-security-policy-csp-and-security
I've read the linked section, but I'm struggling to understand the connection to this issue.
I do understand that the document contents are rendered inside an iframe with the origin sandbox.cryptpad.info (and I can see this in the browser's developer tools Inspector as well). But why would that mean that links inside the document need to be bounced through that domain?
Mathilde As mentioned in an earlier post, Google Safe Browsing services can easily be disabled client-side, directly from your web browser. If you care about your privacy, it's likely something you'd want to do anyway. Otherwise all your browsing history is automatically sent to Google on real-time, leaking quite a lot of information about yourself and/or your activities.
Note that, at least in Firefox, this is not the case (not sure about Chrome). As explained in Firefox's documentation, the list of blocked sites is downloaded from Google in bulk, and the browser's check against that list is done locally.
It seems to have been fixed on Google side, can anyone confirm?
Mathilde it's still red on my side..
luiiuuuiiiii thanks for your feedback. 
Same here.
In any case, even if Google fixes it on their side, the question of why this bouncing is necessary in the first place remains. Would someone be able to share more information about that?
HighCommander4 as I understood, this is actually exactly the step where to prevent potential dangereous link...
I think a productive solution now is to (temporally) change the /bounce/ url for example to /rebond/
or use the same link behaviour as in onlyoffice document (altohough this might not be so elegant..).
