uazo / cromite

Cromite a Bromite fork with ad blocking and privacy enhancements; take back your browser!
https://www.cromite.org/
GNU General Public License v3.0
3.22k stars 74 forks source link

Browser may not be secure error on Google Signin when Desktop Site is turned on #1023

Open lordarcadius opened 4 months ago

lordarcadius commented 4 months ago

Preliminary checklist

Can the bug be reproduced with corresponding Chromium version?

Yes

Are you sure?

Yes

Cromite version

123.0.6312.122

Device architecture

arm64

Platform version

Android 14

Android Device model

Samsung Galaxy S23+

Is the device rooted?

No

Changed flags

No flags changed

Is this bug happening in an incognito tab?

No

Is this bug caused by the adblocker?

No

Is this bug a crash?

No

Describe the bug

When you try to Sign in to Google Account and the desktop site is turned on, it says "App or Browser may not be secure" instead of showing password screen.

This doesn't happen in Mobile site though.

Steps to reproduce the bug

Now you will see the error.

Expected behavior

It should let me sign in to my Google account.

Screenshots

Details

![Screenshot_20240419_175250](https://github.com/uazo/cromite/assets/13603567/5f93bd1d-21e8-43e6-b02e-968f2512b404)

uazo commented 4 months ago

Can the bug be reproduced with corresponding Chromium version?

Yes

Are you sure?

Yes

how should I interpret it? In any case, it works for me, it's a big problem not being able to reproduce it.

lordarcadius commented 4 months ago

I am attaching a video to reproduce this issue. Please check.

Video: https://photos.app.goo.gl/EQe6iAsgbugnsN728

lordarcadius commented 4 months ago

@uazo I even tried building Chromium myself and the Vanilla Chromium doesn't have this. This issue comes when we merge Cromite or CalyxOS patches. I think some patches are creating this issue. I couldn't figure which ones.

uazo commented 4 months ago

I think it is some limitation imposed by google for no reason. If you change via setting the desktop user agent to

Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36

it works without problems. one should ask google directly for explanations, but I don't think they care.

uazo commented 4 months ago

Anyone else noticed the gap between the JavaScript JIT and the Timezone override in Site settings in the video, why is there ?,

see https://github.com/uazo/cromite/issues/811

lordarcadius commented 4 months ago

I think it is some limitation imposed by google for no reason. If you change via setting the desktop user agent to

Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36

it works without problems. one should ask google directly for explanations, but I don't think they care.

This user agent is working because it's not the user agent of a desktop. If you put something like Windows or Linux, you'll get same error. And as I said, this issue occures only after merging your patches. Maybe there is some patch causing this issue.

uazo commented 4 months ago

tried with bromite and even brave, same result, but kiwi works. it is impossible to read the js code of that site, I don't think I can do anything with it.

Maybe there is some patch causing this issue.

if you want to try and work out which one it is, by slowly removing the various patches, rebuild and test, you are welcome! the first one you could try to remove is the client hint (Client-hints-overrides.patch): if you do, tell me and I will assign you the task

lordarcadius commented 4 months ago

tried with bromite and even brave, same result, but kiwi works. it is impossible to read the js code of that site, I don't think I can do anything with it.

Maybe there is some patch causing this issue.

if you want to try and work out which one it is, by slowly removing the various patches, rebuild and test, you are welcome! the first one you could try to remove is the client hint (Client-hints-overrides.patch): if you do, tell me and I will assign you the task

I will let you know about this.

uazo commented 4 months ago

I will let you know about this.

I thought about it, I was wrong. it is a big problem that needs to be addressed and understood. I will try it too.

mainly because it constrains the use of the browser and that is something I do not want. Furthermore, it seems that the time used for adding new features I am working on (such as the platform fido webauth) is lost because, for google, the browser is not secure. @lordarcadius thanks for the report (and for patience)

lordarcadius commented 4 months ago

I will let you know about this.

I thought about it, I was wrong. it is a big problem that needs to be addressed and understood. I will try it too.

mainly because it constrains the use of the browser and that is something I do not want. Furthermore, it seems that the time used for adding new features I am working on (such as the platform fido webauth) is lost because, for google, the browser is not secure. @lordarcadius thanks for the report (and for patience)

Glad to help. I will also try to fix it from my end. Also, I found another issue, Google Meet should work when desktop mode is enabled in Bowser. It fails to even start. It works pretty well in Vanilla.

uazo commented 4 months ago

by changing the useragent from

Mozilla/5.0 (X11; Linux) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36

to

Mozilla/5.0 (X11; Linux) AppleWebKit/537.36 (KHTML, like Gecko) Chromium/124.0.0.0 Safari/537.36
                                                                 ^^^^^^

the site allows me to log in. I do not understand whether it is a bug in the algorithm used by google to identify the browser, because, to say that a browser is safe just because the useragent is changes seems like a joke to me.

lordarcadius commented 4 months ago

by changing the useragent from

Mozilla/5.0 (X11; Linux) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36

to

Mozilla/5.0 (X11; Linux) AppleWebKit/537.36 (KHTML, like Gecko) Chromium/124.0.0.0 Safari/537.36
                                                                 ^^^^^^

the site allows me to log in. I do not understand whether it is a bug in the algorithm used by google to identify the browser, because, to say that a browser is safe just because the useragent is changes seems like a joke to me.

Exactly, it sounds stupid if Google is doing it. Maybe we should look more deeply into it.

uazo commented 4 months ago

Exactly, it sounds stupid if Google is doing it.

no, I don't think so, after all, google knows all the secrets of chromium, and if there is that check, it must serve some purpose.

I have come across this bug (https://issues.chromium.org/issues/40390690), concerning the ProcessPerSite flag. The bug, by the way, listed as fixed, but doesn't actually look fixed to me. all iframes in fact have a mobile useragent in javascript but via network the desktop useragent instead. and this is also common behaviour in brave and kiwi. I'm investigating to see if somehow that flag has something to do with it.

uazo commented 4 months ago

I am desperately trying to understand the motivation, but it seems to be very complex. I am heartened, however, to realise that google's scary message is perhaps a bit far-fetched. Comparing brave and kiwi (the only ones to provide an x64 version - do you know any others?) the former works, as I would have expected, but the latter should not pass, being in my opinion still at version 115 even though it says it is at version 124. However, I will come back to this issue, first I will close the other bugs.

lordarcadius commented 4 months ago

I am desperately trying to understand the motivation, but it seems to be very complex. I am heartened, however, to realise that google's scary message is perhaps a bit far-fetched. Comparing brave and kiwi (the only ones to provide an x64 version - do you know any others?) the former works, as I would have expected, but the latter should not pass, being in my opinion still at version 115 even though it says it is at version 124. However, I will come back to this issue, first I will close the other bugs.

Sure.

I know it's totally unrelated to this thread, but do you have any idea how URL navigation works in Chromium especially on Java layer. When URL is launched manually in a tab then loadUrl function of NavigationController is called. But which function of which class is called when the user clicks on a link in a webpage? Because NavigationController isn't called on hyperlink clicks.

This is the problem I am facing: https://groups.google.com/a/chromium.org/g/chromium-dev/c/CQ8qV1YWHIY?pli=1

uazo commented 4 months ago

but do you have any idea how URL navigation works in Chromium especially on Java layer

if navigation starts from the user, java informs the browser (which is in native) in the way you described. the other navigations request starts from blink and is forwarded to the browser via mojo inter process calls. I don't remember the flow exactly by heart, but when I fix this I'll tell you.

lordarcadius commented 4 months ago

but do you have any idea how URL navigation works in Chromium especially on Java layer

if navigation starts from the user, java informs the browser (which is in native) in the way you described. the other navigations request starts from blink and is forwarded to the browser via mojo inter process calls. I don't remember the flow exactly by heart, but when I fix this I'll tell you.

Alright, I will wait. But if you can give at least some Java class name which is part of the flow then maybe I can look into the flow myself.

uazo commented 4 months ago

This is the problem I am facing: https://groups.google.com/a/chromium.org/g/chromium-dev/c/CQ8qV1YWHIY?pli=1

ah, if you ask them they surely know more.

I simply want to block the URL and load an Error url like I did in the NavigationControllerImpl class.

but you're missing the point, you have to work on the urlloaders (or on the throttles) for blocking and interstitials to alert the user. the former you can see for example in the adblock patch or in the firewall patch, while for the latter I don't know yet, but I'll have to figure it out with https://github.com/uazo/cromite/issues/171

uazo commented 4 months ago

But if you can give at least some Java class name which is part of the flow

there is no java class, everything is native side.

lordarcadius commented 4 months ago

But if you can give at least some Java class name which is part of the flow

there is no java class, everything is native side.

Okay. Thanks for the help man.

lordarcadius commented 1 month ago

Hi @uazo,

Did you get the chance to look into this issue?

Also, I have something important to discuss with you. Since I have no other method to connect with you, shall we connect over email? Please drop your email or reach out to me at vipul@primeos.in