mixit

@djole123 So, I'd already started investigating how I could remove the integrity check so you could try out further compatibility with OneCore API, when it suddenly occurred to me that this would be a waste of time, at least for me. The thing is, the only reason I'm using a Chinese derivative of Chromium is because it's deliberately compatible with XP as-is, and one of a handful of (also Chinese) still useful versions remaining. AFAIK 360 SE v14 has no provisions for XP x64, so I have no reason to pick it over other brands, because adding Chinese "goodies" to Google's is not something I'm interested in when I have more choice. Since this is really a case of having to use OneCore to run "a" Chromium clone on XP x64, 360 SE v14 has no advantages for me. The extra layers the Chinese have added to it would also probably make it less stable on OneCore. One more consideration: OneCore API binaries Github page says it's currently compatible with Chrome 102, but this v14 is based on 108, judging by its user agent string, so the chances of it working right now don't seem very high. I'm not at all opposed to you or anyone else using these Chinese browsers as a choice even if you have other options, but with all things being equal, I myself would choose something else. I'd probably start my trials with plain Chromium - to minimize the number of potentially troublesome features. In any case, best of luck, and don't let what I just said stop you if you want to proceed with getting 360 SE v14 working on XP x64 using OneCore API. And apologies for being so "I-my-me" above , I just wanted to make clear that I'm not claiming to represent the general sentiment around here.

@djole123 Can't say anything specific as I haven't fiddled with OneCore API, but these browsers have their own integrity/signature check (not based on Authenticode). If you haven't modified the original files in any way, apparently OneCore API lacks (has stubbed?) something this integrity check needs to pass properly. Assuming the integrity check is the only problem and the browser is otherwise workable with OneCore (not guaranteed with such complex software), the check could probably be patched out like it has been with modded 360 v13 browsers. You could try asking (via Googletrans) here or here on a Russian-language forum also frequented by the people who did the patching, or at least those who know them and can ask them about it. Maybe they've already done it for v14 as well, I don't follow these topics very closely. (I could maybe do the patching myself once I've checked out how they did it, but I don't know when I'd get to it, and I'm not as familiar with x64 as I am with x86. In any case it's much easier/faster for those who've already gone through it.) Edit: I believe @grey_rat is also a member there, maybe he could ask about it for you. Then again, as a Serbian you may be able to do it pretty easily yourself (I didn't notice your country at first). Edit2: Oh, and welcome to the forum! Didn't notice this was your first post, either.

I guess I shouldn't have been so categorical, this actually is somewhat of a problem for automated captcha solvers.

Scroll up on this page.

Why Cloudflare deems features like site isolation necessary for "connection security" of their customers is anyone's guess. It's not as if the very latest Chromium couldn't be run headless or embedded or puppeteered with automated clicks, with all the feature gimmicks thus available to botters. And if someone is actually going to hack a site, verifying that they're human sure isn't going to keep them out. I seriously doubt that a significant amount of "bad" traffic to these sites comes from browsers that were commandeered because the user had turned off site isolation... Mostly what this seems to accomplish is gatekeeping against older browsers.

So this cookie is only set by the Store and not by Gmail or their other services? Sorry for asking again, but saying "everything web-based Google works" doesn't really answer this part for me. The reason I'm asking is that it seems a bit unlike Google to only track Store users in a permanent way and not everyone with a Google account. When this tracking feature was first introduced, it seems to have applied to Google accounts in general (I say this based on reading a few articles from the time), but of course 360 may have made any number of changes to what Google had in place.

13.5.1030 should also pass if Disable site isolation in chrome://flags/ is set back to Default. Browser restart is needed for this to take effect. After restarting, double-check in chrome://flags/ that the change actually took - 360 occasionally doesn't save its state properly upon shutdown. If the setting is OK, https://mybrowseraddon.com/webrtc-control.html should work. Tested with a freshly unzipped 360ChromePortable_13.5.1030_rebuild_7_ungoogled profile, YMMV if other settings have been customized. The reason this works in 13.5.2022 is that the distribution doesn't include a pre-set \User Data\Local State the way 13.5.1030 does, so there are no customized preferences loaded from it.

Glad to be of service. I should have checked if this was already included before tagging @roytam1 ... In my feeble defense, I don't actually use Serpent - I'm still on self-built pre-drama Centaury (in combination with 360 and occasional VM browsing with the officially "in" browsers) but it turns out it actually has it too, disabled by default. At least it's nice to occasionally have a browser problem we can solve on our own without endlessly waiting for "upstream". I have to say, I almost missed the SSL problem because we've been totally conditioned to always look at the JS console as of late I wonder what's up with Mega and this single-cipher thing, though...

Well, in cases when there's weak secrecy vs "complete secrecy" in the form of "no connection possible", the former might be handier. As with other ciphers, these could be disabled in about:config settings when not needed, couldn't they?

@AstroSkipper, you wouldn't by any chance have *.mega.co.nz in your [SSL Pass-Thru] section in config.ini, would you? I just downloaded ProxHTTPSProxy 1.5.220717 and it was there in the default .ini file. After removing it, I was able to download from Mega without problems. Edit: Correction, on another try there were "temporary errors", but they really were temporary this time and the download still completed fine.

Ah, that's unfortunate then... I just saw cipher mismatch failures with this (IMHO pretty unusual) single-cipher host and assumed that was the likely main culprit. Well, even if there's a proxying workaround, I think it'd still be a good idea to enable these ciphers in Serpent itself for compatibility reasons, especially considering how trivial the patch looks.

Since the launcher can delete anything in the profile, are you talking about just using the "normal" in-browser means? And is this something peculiar to the Google Play Store and not happening if someone signs into their Google account for Gmail or another service? I know you guys talked about this cookie a while back but I didn't pay very close attention back then and I only use Google for search and translation.

This actually doesn't look like a JS thing but rather a cipher incompatibility, as at least some Mega download servers seem to be for some reason using TLS_RSA_WITH_AES_128_GCM_SHA256 exclusively and Firefox only enabled it (and TLS_RSA_WITH_AES_256_GCM_SHA384) with bug 1638369 in version 78. Seems trivial for @roytam1 to implement, so probably not a problem for long (if this is all there is to it).

Happy New Year!

No need to worry, I most certainly don't "have" that - my notes on this are from April and it's not something seen since. I'm pretty sure it had to do with the podcast server having moved subdomains to where the existing certificate didn't apply, but if there was any real MITM involved, that would have been very much first-party , i.e. me temporarily intercepting SSL traffic. But the only files that coincide with the timestamp on those notes are some of those podcasts I never got around to listening. How very exclusive! BTW, not to nag too much, but why post like this when you can edit? I mean when you're not talking on separate subjects or replying to different people, and there are no intervening posts by others.

@NotHereToPlayGames @Humming Owl I just remembered I forgot to report a yet another stray Chinese UI string I saw a while back. It shows up when downloading from a "dangerous" site; IIRC there was a certificate problem with a not at all suspicious podcast host when I saw it. I'm too lazy to look for a suitably problematic site right now, but you can simulate it if you search for 85 E4 00 00 00 8D 86 F8 02 in chrome.dll (2022) and temporarily replace that 85 there at the beginning with 84. Then when you hover over the d/l button, all downloads should be red and have that message attached (if the filename is too long, you can see it in the tooltip). The string is "（来自危险网址）": EF BC 88 E6 9D A5 E8 87 AA E5 8D B1 E9 99 A9 E7 BD 91 E5 9D 80 EF BC 89 A fairly literal translation would be " (from unsafe URL) ". In any case, it's UTF-8, and should be padded with spaces to full length of 24. I also recommend starting with a space before the paren, because Chinese parentheses are double-width and have the space "built in".

Since I still use 1030, I actually used it to develop this patch before applying it to 2022. So, for 1030: Drop Share URL QR Code from Chrome mode page context menu: 89 F9 68 6D 1A 00 00 68 4F 81 00 00 EB 0F 68 6D 1A 00 00 68 4F 81 00 00 Drop Share URL QR Code from Chrome mode link context menu: 89 F1 68 6D 1A 00 00 68 50 81 00 00 EB 0F 68 6D 1A 00 00 68 50 81 00 00 Drop Share URL QR Code from IE mode page context menu: 6A 00 68 D5 08 00 00 FF 75 08 FF 15 E4 B1 EA 16 EB 5E 68 D5 08 00 00 FF 75 08 FF 15 E4 B1 EA 16 68 E4 25 00 00 FF 75 08 FF 15 E4 B1 EA 16 68 D5 08 00 00 FF 75 08 FF 15 E4 B1 EA 16 68 E4 25 00 00 FF 75 08 FF 15 64 B2 EA 16 68 D5 08 00 00 FF 75 08 FF 15 64 B2 EA 16 Drop Share URL QR Code from IE mode link context menu: 8D 7D E8 68 6D 1A 00 00 57 E8 41 58 17 FB EB 3A 90 68 6D 1A 00 00 57 E8 41 58 17 FB Drop Share URL QR Code from IE mode image link context menu: 8D 45 D8 68 6D 1A 00 00 EB 43 90 68 6D 1A 00 00 Drop Share image location from Chrome mode image context menu: 89 F9 68 6E 1A 00 00 68 51 81 00 00 EB 0F 68 6E 1A 00 00 68 51 81 00 00 Drop Share image location from IE mode image context menu: 6A 00 6A 0F 53 FF 15 E4 B1 EA 16 83 F8 FF 74 3C EB 4A 6A 0F 53 FF 15 E4 B1 EA 16 83 F8 FF 74 3C Drop Translate to English from Chrome mode page context menu: 8D 86 F0 02 00 00 50 E8 2F 9E 72 FE E9 E6 00 00 00 90 50 E8 2F 9E 72 FE As for your questions, I used the obvious suspect for such things. But its free version or Ghidra or OllyDbg should work just as well. Finding the locations isn't too hard with the source code for Chromium available, don't really need to decompile or use the debugger. It takes quite some time to disassemble/analyze a huge DLL like this one, though.

It's also included in the Windows 7 SDK (GRMSDK_EN_DVD.iso), still freely available straight from MS. Those who don't want to install the whole thing can use something like lessmsi to extract ReBase.exe from \Setup\WinSDKTools\WinSDKTools_x86.msi and its adjacent cab1.cab. And those who don't want to download the entire 500+ MB SDK from MS can use Archive.org's browsable ISO content to only get these two files.

IIRC, it was mentioned somewhere in the notes by the Russian crew that 360chrome originally had a custom DLL signature check (i.e. not dependent on Authenticode), which for modding purposes has been patched out for chrome.dll and the rest, but not for chrome_elf.dll for security reasons.

Been meaning to post these @feodor updates from the Russian-language forum, because sooner or later someone's going to ask again. December 4: December 14: I presume he means that heavy parallel disk activity during builds is causing disk corruption when power is suddenly cut, so building on a RAM disk would help with that.

Seems to originate from Dr Dobb's (source code links are dead there, but it's available here). @AstroSkipper might appreciate how period correct this little program is.

@UCyborg An excellent approach!, works as intended on my XP x64. It's pretty funny that even though I've already personally modded this DLL, it didn't even occur to me to consider such "invasive" methods at this point - typically when people have these kinds of issues, they don't want to start modding as the first thing (breaking file signatures is "bad"! what will anti-virus say?! ), so you kind of condition yourself to try and find configuration-based methods first and foremost. But since we're modding anyway, this is highly appropriate! For those who want to use this method for other applications, it seems that libase.exe doesn't like file signatures (my 1030 chrome.dll still had it while 2022 doesn't), which you can remove for instance with delcert.exe, available from here.

I think this "one empty tab at startup" metric may actually not be all that useful, because if you open up a bunch of of additional tabs to fill out all available memory (for example pile up Youtube videos) and then close them all, the initiall processes' working sets[1] have gone down to the lower bounds reported here and appear to stay there afterwards, even though their private bytes values stay at the upper bounds. YMMV, but that's what I saw just now - even working with settings pages and dev tools it that tab didn't make them go up again. Edit: I'm pretty sure though that this particular metric isn't the only reason @AstroSkipper says he can't use 360 on a low spec system. [1]Thanks @msfntor for the reminder. My XP x64 daily driver has 32 GB RAM, so these two values tend to stay pretty close, making me forget about the difference.

Possibly because I have that column set up further back so I'd have to scroll to see it and "out of sight, out of mind".

For me, Dencorso was the soul of this place from when I first started visting here til he slowly waned from the forum. He was the first one to reply to my first post/thread here, and to my great surprise pinned it moments later! I remember back during the 2017 crisis situation of the forum possibly disappearing, he'd PM people in charge of projects and pinned threads to make backups of everything important and be ready to regroup elsewhere to keep this community alive. I wish I'd talked to him more, but that's entirely on me... I'm not going to repeat all the good things that have already been said above about this exceptional person, but I would like to paraphrase Den's next-to-last status update (which I think in itself can be considered the manifesto of current MSFN). Indeed EoL != EoS (in this case End of Spirit) and the spirit of Dencorso can be kept alive here for as long as we all care to. May he rest in peace.