Jump to content

mixit

Member
  • Posts

    222
  • Joined

  • Days Won

    10
  • Donations

    0.00 USD 

mixit last won the day on January 6 2023

mixit had the most liked content!

1 Follower

About mixit

Profile Information

  • OS
    XP Pro x64

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

mixit's Achievements

242

Reputation

  1. @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.
  2. @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.
  3. I guess I shouldn't have been so categorical, this actually is somewhat of a problem for automated captcha solvers.
  4. 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.
  5. 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.
  6. 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.
  7. 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...
  8. 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?
  9. @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.
  10. 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.
  11. 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.
  12. 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).
  13. 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.
×
×
  • Create New...