NotHereToPlayGames

So I updated my profile today and upgraded my NoScript 11.2.4.0 to 11.2.10.0. Thouroughly unimpressed! For example, when you load MSFN with a clean cache, the page displays "while" it is loading. You get the broken menu and a long list of menu items because the menu hasn't fully loaded yet but the browser is trying to render what portions have loaded. Reminds me of how Opera had a setting to display pages "instantly" or after 1 second and pages would just "look better" if you told Opera to WAIT 1sec before displaying the page. Watching the page "flow" into existence while resources are loading is a bit "tacky" in my opinion. Confirmed by reverting back to 11.2.4.0 and the "page flow" went away. Upgraded again to 11.2.10.0 and the "page flow" tackiness returned. Anyone else notice this issue with the latest NoScript? Maybe it's something that showed up in a version somewhere between 11.2.4.0 and 11.2.10.0?

v13 build 2206 rebuild 2 file size == 90.0 MB v13 build 2206 rebuild 3 file size == 70.2 MB login resources have been removed (which also removed Avatar context menu [may bring it back in a later rebuild to use as dropdown for chrome URLs]) @Humming Owl's v12 modfications have been ported to v13 -- no more gstatic connection on First Run --- I have not tested for possible side effects but will report if I do find any all settings pages fit in one 1920x1080 viewport - it always bugged me that you could be three dialogs in, close that third dialog, and the second dialog defaulted itself back to the top and you have to find where you were at, just annoying so I fit all to one page https://dl.dropboxusercontent.com/s/qyyimm3h58r3963/360Chrome%202206%20rebuild%203%20-%20unran%20-%20MSFN.zip

@Humming Owl - have you observed any of your modifications breaking 'internal' Unicode support? As an example, in Modified v12, you have an entry where you changed "Edit Search Engines(&E)..." to "Edit Search Engines..." And both the original and the replacement entry are THREE DOTS. But a Unicode entry of … instead of ... (highlight each of those and you will see that one is one character (unicode horizontal ellipsis) and the other is three characters (three dots) will be shown as a square in the GUI (ie, unicode support is broken). Another example, there is an entry in your notes where you changed "More…" (original with unicode horizontal ellipsis) to "More..." (you replaced unicode horizontal ellipsis with three dots, directly above "speeded" to "Speeded" entry in v12 notes) - did you do this because of a square being rendered in your GUI? I ask because the original untouched 360EE (v13 at least) does allow unicode characters but somewhere along the line both you and I are now using non-unicode throughout. I don't know "where" along the lines that the original unicode support broke but at the same time we haven't broke unicode support for the web pages that we are rendering, only the text strings of the GUI.

Thanks to some suggestions by @Humming Owl from his Modified v12, I can hereby report that v13 build 2206 rebuild 3 makes ZERO connections on First Run. Let it sit open for 20 minutes on about:blank without visting any sites, never made any connections in that entire 20 minutes (this was the case for rebuild 2 also, aside from First Run gstatic connection within seconds of launch). Navigated every settings page, never made any connections the entire time (never actually tested this in rebuild 2, it might have done a favicon connection in the Search Engines settings, not positive). Closed and relaunched three times, never made any connections (this was also the case for rebuild 2). I should be ready to upload v13 build 2206 rebuild 3 sometime tomorrow.

Task Manager memory usage, no extensions, no page visited -- v13 build 2206 rebuild 2 == 83,508K v13 build 2206 RuPack == 81,700K v13 build 2206 rebuild 3 == 80,388K

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.