Google Phishing alert breaks all access

webmink

I have Cryptpad 4.11 installed on a Raspberry Pi via Yunohost on a single-purpose subdomain. Everything was working as expected, but Google has decided to flag the domain as phishing (they do this all the time - they hate self-hosters). Now they have done this, I can't open anything in Cryptpad in Chrome under ChromeOS even after clicking through the warning - it times out on the Load Drive step.

Image description

Is there a work-round for this? As Google takes at least three days to unblock a false positive this is going to be a serious issue.

Thanks

Simon

Mathilde

Hello Simon,

Thanks for reaching out and for your interest in CryptPad!

As explained by someone in our Instance admins Matrix chat, it's not something related to CryptPad itself, there is an entire thread on YunoHost forum covering these cases.

CryptPad maybe fail to load because of Chrome overwriting security headers, disabling service workers, etc. Could you check the Google Chrome documentation? I found this article who may be useful: https://support.google.com/chrome/answer/99020#zippy=%2Cview-the-entire-unsafe-page

Hope this helps!

webmink

Hi Mathilde!

As I indicated on Matrix, I am well aware of the reasons for the Google redlisting. I have handled it as I usually do.

The Google chrome documentation does not help; it merely tells you to click the over-ride in the red screen and proceed anyway. But as I stated in the OP Ihave done that and the loading of CryptPad fails anyway. Ludo elsewhere suggested manually visiting the second domain to clear the warning there too, but in my case I have set both domains to be the same and loading still fails.

There's something else going on that probably needs understanding, since it's clearly not OK to have all access to CryptPad made impossible by a Google domain warning like this.

Cheers

Simon

Mathilde

Hey Simon!

I'm sorry you had to experience this. Did you managed having your domains unlisted by Google?

I do understand and share your concerns about Google hegemony and nefarious impact on the web. But as I understand how web browsers and especially Google Chrome works, there is little we can do about it.

If your web browser decide arbitrarily to block your from accessing some domain because of a bundled mechanism (i.e. making requests to a private Google server that list domain names freshly registered), we can't force it to behave differently. As a workaround I would recommend using Mozilla Firefox instead, which is a web browser not owned by a despicable corporation like Google LLC.

Regarding the fact that bypassing the warning doesn't work it's probably because Google Chrome is also blocking some important security features required by CryptPad to work. I'm just guessing here because I haven't been able to find any documentation about this on Google support website. Just listing a few things CryptPad require:

Ability to execute JavaScript
Not overwriting Content Security Policies (CSP)
Support shared workers (or web workers if those aren't supported)

If your web browser is blocking one of these basic capabilities, CryptPad won't load.

I would recommend to bring this to Google developers, opening or participating in an already open topic on their community forum. If you have sufficient knowledge to share debug information, you can also directly open a bug report for the Chromium projects.

In case I would have not properly understood your request, please accept my apologies and don't hesitate to share your ideas about how we could deal with this on CryptPad's level.

Best wishes,

webmink

Yes, I was able to get the domains unlisted quite quickly using the approach I documented. The Community Forum is not a good place to ask - as you will find if you scroll through, the developers there just direct you to the Search Console if you report a red-list problem. This is also not specifically a Chromium issue, as only CryptPad exhibits the issue I am reporting.

I'm sure you are right about the general reasons for the instance becoming inaccessible. However, I believe we will see more and more people facing this issue going forward and it would be good to understand why CryptPad uniquely fails when other similar packages do not (for example, HedgeDoc does not fail once the initial red screen is bypassed). It's relatively easy to get a domain redlisted (unfortunately) so it would be good to gather information about exactly what the problem is for CryptPad and maybe identify some work-arounds or even fixes.

May I suggest using this thread to gather evidence from others as they encounter the problem? Perhaps you could direct people here. May I also ask if you can direct me (and them!) to documentation that would help me to gather the information developers would need to disagnose the point(s) of failure? I will then gather information next time it happens.

Cheers

Simon

Mathilde

As suggested by my colleagues a way to bypass this could be to load the sandbox domain first. On our flagship instance for example:

cryptpad.fr is the main domain
sandbox.cryptpad.info are the sandbox domain & subdomain

Loading the sandbox domain first, bypassing the error. Then coming back to the main domain & bypassing the error there, will make CryptPad load as expected.

If I recall properly your messages on Matrix, you mentioned you didn't setup two different domains for your instance. We strongly recommend against doing this, it will lead to an insecure configuration and will put your users data at risk.

I also took a quick look at your instance and could see that it's already way outdated. I'm sorry but as much as I'd like to help we simply can't support CryptPad old versions and buggy configurations.

webmink May I suggest using this thread to gather evidence from others as they encounter the problem? Perhaps you could direct people here. May I also ask if you can direct me (and them!) to documentation that would help me to gather the information developers would need to disagnose the point(s) of failure? I will then gather information next time it happens.

In any case everyone is welcome to share their feedback regarding this issue on this thread. If that is reproduced by someone using an up-to-date instance, properly configured as per our recommendations, we'll definitely see what we can do about it.

webmink

Note that I have not installed Cryptpad manually but am using the latest "official" Yunohost package for it, which configures the instance as described. I am not knowledgeable enough to change what it does in the ways you suggest within Yunohost, which is managing the Nginx configuration. Both the version installed and the configuration used are the ones applied by the package. I assume everyone using that package is in the same position. If it's wrong, maybe someone should intervene (I am sorry, it cannot be me)?

Mathilde

We are grateful for the community building packages for this kind of project (we love YunoHost, really) but it isn't an official package from the CryptPad team. The only official source code we release is on the GitHub project repository, everything else is third party.

However, @Guillaume, a community member, has been working on fixing this with this GitHub branch and was gathering feedback on our Instance admins channel a few weeks ago. Maybe you can also test it and provide them with some feedback so this could be merged on the YunoHost app repository?

webmink

It looks like it is ready to go, no clue why it's not been completed.

Guillaume

yep it is almost ready to go...

it hasn't been completed because is not finished yet we still need to work on it
I saw that some felow yunohost community member started works on it yesterday.
https://github.com/YunoHost-Apps/cryptpad_ynh/pull/145

I have started another test now to see where we are at and what is left to solve
https://ci-apps-dev.yunohost.org/ci/job/4580

but if you feel adventurous you can still install the test version on your server.
In your yunohost server when you are on the screen to select the app to install you can scroll to the bottom of it and add this link to install the testing version

https://github.com/YunoHost-Apps/cryptpad_ynh/tree/testing

that is of course temporary and mostly for tests purposed and not for production environements.

reading above mathilde comment, it might be wise to implement in yunohost_cryptpad app the same implementation that loads sandbox domains first...I shall see in details how this translate into nginx conf.

webmink

I unfortunately don't have a test system available at the moment (working on it...), but thank you.

Yes, it would seem a good idea to try to implement the two-domain approach that is recommended; I assumed it had not been done in the Yunohost package for a technical reason.