NotHereToPlayGames

Has anyone figured out what .css entry/entries can be tweaked to fix this nuance? I'm in v13 and I think this nuance exists in earlier versions also but not 100% sure on that. When you are in settings and on the Advanced tab, open the Content settings dialog. Take note of how everything is positioned on the Content settings dialog - particularly the header title. Now open any of the Manage buttons. Another dialog will open above the Content settings dialog. But the header title of the Content settings dialog disappears and everything below it shifts up. Watch the small portions of the Content settings dialong that are still visible along the left edge of the Manage dialog that is now on top, close the Manage dialog and you'll watch everything shift back down and the header title reappear.

Got it, thanks!

Settings - Lab remove Magnifier utility (enabled website dialog never seemed to work so opting to just remove)

removed decompress with 360 from download section (this downloads a "360zip" utility and this is broken once we removed all of the telemetry - plus, we all have our own preferred archive utility external to our browser)

saving these two to-do's for a future rebuild -- 1) Location Bar -> convert Chinese copy paste helper to English (.png) 2) Page Utility -> convert Chinese video tips to English (.png)

ported Humming Owl's v12 "shared.ydstatic.com", "95001111", "googleapis" and "gstatic" entries by dots -- have not tested remainder of entries in Humming Owl's list has already been replaced (or did not exit in v13).

Do you recall why the below section was replaced for v12? - Offset (h) = 02bc54a0 Replaced the "68 74 74 70 3A 2F 2F 73 6F 2E 33 36 30 2E 63 6E 2F 73 3F 71 3D 25 73 26 73 72 63 3D 33 36 30 63 68 72 6F 6D 65 5F 61 64 64 72 26 69 65 3D 75 74 66 2D 38 00 68 74 74 70 3A 2F 2F 77 77 77 2E 62 61 69 64 75 2E 63 6F 6D 2F 62 61 69 64 75 3F 77 6F 72 64 3D 25 73 00 68 74 74 70 3A 2F 2F 63 6E 2E 62 69 6E 67 2E 63 6F 6D 2F 73 65 61 72 63 68 3F 71 3D 25 73 00 26 69 65 3D 00 26 75 65 3D" hexadecimal code by 00 hexadecimal values

removed adfilter exceptions (adfilter functionality already disabled but now exceptions list is empty) (see Humming Owl's notes) removed default search engines (see Humming Owl's notes)

Settings - UI Style functionality has already been broken, removed more items (see Humming Owl's notes), removed from GUI

Thanks!

Disregard. This "might" be related to Settings - Advanced -> HTTPS/SSL -> intercept certificate risk option (I don't use this option but at the same time am mindful to not "break" any options that I don't use but that others may opt to use).

Settings - Basics removed and disabled search engine built-in fallback (see Humming Owl's notes)

I've also opted to remove the root directory sslblock.zip. This was used in earlier versions but I have yet to witness this page ever be displayed in v13. From the best I can gather, all ssl cert errors are displayed via clicking the padlock icon in v13's address bar. That and as far as lightweight, fast, and efficient, I'm content with just the ssl error code in the title bar and a completely blank page in the content area. My only way of really testing has been this site -- https://badssl.com/

I just ran an SRWare Iron v48 (could not find a v49) first-run and saw two Google connections and one Microsoft connection all within 10 seconds of launch. Then it proceeded to connect to some Google Translate IP Addresses when navigating around in the settings pages. At that point, I exited because this has become a total and complete waste of time in my view. And I may have missed a few because I had to set the startup page to about:blank - which should be the out-of-the-box default for ALL browsers (you can't really catch all startup shenanigans when it is loading a "default page"). We really are blowing this single solitary gstatic connection way out of proportion. Because EVERYTHING that I have looked at shows us to have 360Chrome down to one single solitary gstatic connection with no unique identifier of any kind and every other browser on the planet is making SEVERAL "connections" that nobody seems to really even care about. No offense guys, as I've reported over and over, this project isn't about compiling Iron 2.0 (but we can't call it that now, Iron makes first-run connections also!), it is about creating a browser we can "trust". We will never satisfy the Archie McPhee Tin Foil Hat crowd. I wholly and fully "trust" 360Chrome - even moreso after watching connections being made by other browsers whose user-base just trusts them blindly without question.

There's a search feature? <just joking...> The maintenance caught me offguard, lost a fairly lengthy in-process post but it is what it is

I wasn't surprised, to be honest. I used to use Comodo Firewall and setting up rules for Firefox was always very tricky and time-consuming (unless you just wanted to tell Comodo to "trust" Firefox, which was never my route!). Firefox has always done some very strange stuff on startup. They conducted their test in a similar fashion to how I tend to - NO STARTUP PAGE (it's tricky to isolate first-run shenanigans if you throw a startup page into the frey), no profile, launch and let it sit there for TEN MINUTES without opening anything, don't go to any web site, don't open any settings page, don't click anywhere, just let it SIT THERE. Then click around in the GUI while still monitoring net traffic. Then close and relaunch and continue to monitor net traffic. My 360Chrome v13 build 2206 only has the ONE gstatic connection and it has no unique identifiers that I can find (I welcome anybody to screencap evidence to the contrary because that would shift priorities). But just citing its presence is kinda propaganda, smear tactics, undo paranoia, you can decide for yourselves how to "label" it. I myself (until proven otherwise) find it not only HARMLESS, but it's been there for DECADES in all Chromium builds. Again, I am of the persuasion that IF it was NOT harmless, then there would have been a hanging in the town square and the revolution would have been televised. Or something like that...

A must-read for everybody following this "gstatic" connection in 360Chrome -- https://brave.com/popular-browsers-first-run/ Firefox v86 made 2,799 network requests to 8 domains on its first-run, 9 telemetry requests were made, 3 telemetry requests were made 10 minutes after Firefox was closed, new requests were made on second-run. The writeup also discusses Chrome v89 (cites 91 network requests) and reports no observed personal information or unique identifiers. I'm finding the ONE solitary first-run-only gstatic connection to be HARMLESS and won't be spending time on my end to axe it. I will port any findings to my rebuild but I'm seeing it as HARMLESS and "excessive paranoia" - time to put on our Archie McPhee Tin Foil Hat. I don't deny that the article is a Brave "marketing" writeup, but at the same time they would be "tarred and feathered" for any false and misleading "propaganda".

i can hereby confirm that the --no-first-run switch does NOT prevent that first-run gstatic connection (only tested in v13 build 2206). Nor does it effect startup time for the first launch after a reboot (which for me is generally right around 5.5sec versus 0.4sec for every launch thereafter). [MyPal, NM, and Basilisk also have this first-launch-after-reboot lag, possibly a side-effect to running all as "portable".]

re: --no-first-run From what I have read, I have very low expectations on this command line switch and would not chase the rabbit down this rabbit hole. The "first run" that this command line switch entails is more along the lines of the "welcome" page which 360Chrome does not employ anyway (though it might "coincidentally" break that v11 first-run popup for selecting theme). I'll be confirming later but again, this switch is all about that "welcome" page that orginal Chrome/Chromium will display on first run. Not saying with full certainty that it will not fix that first-run gstatic, but I have very low expectations at this point.

I have a very VERY strong hunch that this was simply an "accident" and that the developers of 360Chrome did not test in xp x86 sp2 and have zero interest in xp x86 sp2. I have an equally strong hunch that the developers also did not test in win 2000, win 98, win 95, or win 3.1 and nor did they test on a Commodore 64 or VIC-20.

Do you have additional details on the googleapis and gstatic modifications?

Okay, I decided to put my money where my mouth is. I think you'll agree this to be proof. We know that UA-CH did not exist in Chrome 80 and we know that UA-CH is enabled by default in Chrome 92. html5test.com gives that "imitates" in the results for Chrome 80 and for Chrome 92 - has nothing to do with UA-CH (which I "think" was your claim, not sure? I can't follow your posts at times). And as my geometry teacher used to say -- Q. E. D.

Actually, since you requested I run a test, I'll submit a test in return. We know that UA-CH started with Chromium 84 (some sites report 85 but I see several that cite 84, so worst case we will call it 84). So here is a test for you - run that html5test (which I personally think is flawed, but I don't have much experience with it) using Chromium/Chrome EIGHTY and fake a Firefox user agent. My hunch (I welcome you to screencap proof that I am wrong) is that running that "test" using Chrome 80 and faking a Firefox user agent will give you that "imitates" result - so it has nothing to do with UA-CH, would you agree?

You seem to be confused on just what UA-CH does (or I am?) The agenda of UA-CH is to BYPASS the user agent completely. Detection based on UA-CH would detect your true browser REGARDLESS of whether you were faking a user agent or not. The html5 detected the faked user agent, so it has nothing to do with UA-CH, the "imitates" can be due to a hundred different things, various "combinations" that throw out the word "imitates" when Condition A plus Condition B is met. The whole agenda has very little to do with "privacy" or "telemetry" - though I would classify you as a bit more "extremist/alarmist" than I would classify myself. "Not that there's anything wrong with that." (A Seinfeld reference.) The purpose is for the website to know if you are on a MOBILE device versus a DESKTOP and to send the proper code for a proper rendering. If they succeed in rolling out this platform (way too early, not even sure if it exists "in the wild yet", just 'on paper') then those of us that FAKE user agent strings to FORCE a "heavy" web site to send us code based on less "hungry" javascript, as an example, will no longer be able to do that. The website will DETECT our TRUE "fingerprint" regardless of what we tried to FAKE by using the very old and everybody-knows-it "trick" of sending a FALSE user agent string. That's my understanding thus far at least. I'd be more than happy to read any respectable website link you may have that may indicate otherwise. The html5 test doesn't show me what I need to see as "proof". A "real" test that proves UA-CH is in fact "functioning and enabled" would be a test that reports "You faked your user agent to tell me you are Firefox on Linux, but I know better, you are really Chrome 86 on Win XP x64". Just catching XP x64 would really prove an advance to me, as almost all of these "test sites" including html5test.com refers to my XP x64 as Windows Server 2003. So that alone tells me that html5test isn't very "advanced".

Also as an FYI -- UA-hints does not function (by default) in 360Chrome v13 build 2206. The User-Agent Client Hints became available with Chromium 84 and was gradually enabled on Chrome Stable as each release became available. In Chromium 84, it was disabled by default and you had to enable it with this flag -- about://flags/#enable-experimental-web-platform-features The feature was not enabled by default until the release of Chromium 89. Reminder - 360Chrome v13 is based on Chromium 86 and is thusly disabled by default. Below are screencap's from a test site that demonstrates if you have this feature enabled or not (I pulled the enabled via Chrome 92 from Win 7 VM). The key section to look at is the "Subsequent Request" being empty after we sent an "Accept-CH" header. And of course I shouldn't have to remind everyone that you are protected even further by only allowing white-listed javascript.