Leaderboard

The "iheart" URls referenced by @Art7220 fail to load fully in latest UXP browsers not because the platform (UXP) lacks support for Optional Chaining ("?.") and Nullish Coalescing ("??") operators, but because of lack of support for ECMAScript2018 RegExp features (e.g. "Named Captured Groups"); this is being demonstrated by the WebConsole error @UCyborg already posted, that one gets by trying to load either of https://v1011sacramento.iheart.com https://thenew1079.iheart.com in latest NM28/St52 Latest NM28 DOES NOT need extra polyfills for ("?.") and ("??"), as they are supported natively... The "core-js" project I linked to contains a bucketload of recent JS polyfills, but I have not taken the time myself to properly index exactly what (and I wish JSDelivr provided an easy way to just fetch ONLY the core-js polyfills one needs, instead of the whole core-js-bundle, but I couldn't figure it out myself ) ... NB that VM is a WE, so not supported in NM28; your UserScript Manager choice there boils down to Greasemonkey for Pale Moon, currently an abandonware ... 360EEv11 loads the "iHeart URIs" natively (which is yet another indication of how badly UXP fares in WebCompat ), so I had no need to use additional polyfills there for these... I suspect the real question is: "Can I use your userscript to "pay my water bills" in 360EEv11?" The answer is probably NOT (but you'd have to try it yourself...).

@tpao12 Standby does not work on newer motherboards under XP, I think this is mostly because of the graphik driver Dietmar

SyntaxError: invalid regexp group So, use different browser I guess... ... Recently, I have been toying with the idea of writing simple Violentmonkey userscripts to be used in latest Serpent 52.9.0 (and, possibly, 55.0.0) that fetch online polyfills for missing, native, Web APIs; the core-js bundle of polyfills does have ones for 'RegExp Named Captured Groups', so by the below VM userscript, // ==UserScript== // @name Add 'core-js-bundle' polyfills // @version 3.22.8 // @description Polyfills for ES3, ES5, ES6, ES7, ES2015, ES2016, ES2017, ES2018, ES2019, ES2020, ECMAScript3, ECMAScript5, ECMAScript6, ECMAScript7, ECMAScript2015 // @namespace core-js-bundle // @include https://*.iheart.com/* // @run-at document-start // @require https://cdn.jsdelivr.net/npm/core-js-bundle@3.22.8/minified.min.js // ==/UserScript== I was able to load OP's offending "iheart" URIs in St52: You can add additional URIs/domains that need this "treatment" via adding corresponding "// @include" lines... That web design is abysmal , probably coded by a 20yr old who's never accessed the web in a non-mobile device , but, what the heck... BTW, the "Listen Live" feature is geo-fenced (US IPs, only).

I think the short answer to your question is because we're enthusiasts, and because we can! (Oh, and we don't like being told by the likes of Microsoft that we can't do something!)

According to SSL Labs, Chrome 49 / XP SP3 supports the following protocols and cipher suites: https://www.ssllabs.com/ssltest/viewClient.html?name=Chrome&version=49&platform=XP SP3&key=136 Protocols TLS 1.3 No TLS 1.2 Yes TLS 1.1 Yes TLS 1.0 Yes Cipher Suites (in order of preference) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) Forward Secrecy 128 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8) Forward Secrecy 256 OLD_TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc13) Forward Secrecy 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) WEAK 256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) WEAK 128 TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) WEAK 128 TLS_RSA_WITH_AES_256_CBC_SHA (0x35) WEAK 256 TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) WEAK 128 TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) WEAK 112 I presume the above reflects XP SP3 fully updated until EoS, without any POSReady additional updates; NB that while Chrome 49 comes with its own TLS protocol support, it relies on the OS both for certificates (WinCert store) and supported cipher suites... For completeness, what additional (if any) cipher suites are added via the POSReady updates? To check, launch Ch49 (under XP SP3+POSReady) and visit https://clienttest.ssllabs.com:8443/ssltest/viewMyClient.html OTOH, the server "o.rthost.win" resolves into two IPv6 + two IPv4 addresses; e.g., "104.21.48.191" supports the following protocols and cipher suites: https://www.ssllabs.com/ssltest/analyze.html?d=o.rthost.win&s=104.21.48.191 Protocols TLS 1.3 Yes TLS 1.2 Yes TLS 1.1 Yes TLS 1.0 Yes This server supports TLS 1.0 and TLS 1.1. Grade capped to B. This site works only in browsers with SNI support. # TLS 1.3 (server has no preference) TLS_AES_128_GCM_SHA256 (0x1301) ECDH x25519 (eq. 3072 bits RSA) FS 128 TLS_AES_256_GCM_SHA384 (0x1302) ECDH x25519 (eq. 3072 bits RSA) FS 256 TLS_CHACHA20_POLY1305_SHA256 (0x1303) ECDH x25519 (eq. 3072 bits RSA) FS 256 # TLS 1.2 (suites in server-preferred order) TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) ECDH x25519 (eq. 3072 bits RSA) FS 128 OLD_TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc14) ECDH x25519 (eq. 3072 bits RSA) FS 256P TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9) ECDH x25519 (eq. 3072 bits RSA) FS 256P TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 128 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) ECDH x25519 (eq. 3072 bits RSA) FS 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 128 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 256 # TLS 1.1 (suites in server-preferred order) TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 128 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 256 # TLS 1.0 (suites in server-preferred order) TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 128 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) ECDH x25519 (eq. 3072 bits RSA) FS WEAK 256 As you can verify on closer inspection, there exist no common cipher suites between what the browser and the server support, so the OP is absolutely right; the same is indicated by SSL Labs Server Test: Notice how the server is configured to only support cipher suites (TLS_ECDHE_ECDSA_*) with Perfect Forward Secrecy (PF), which, on the one hand, is a good thing, but it may limit the connection ability of older clients... @roytam1, do you have any control on this? If you could add (on the server) support for (even just one of) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8) OLD_TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc13) which aren't deemed WEAK, Ch49/XP SP3 could connect over TLSv1.2... PS: For anyone vaguely interested, Chrome 49 / Vista SP2 (fully updated to EoS+TLSv1.2 support from WS2008SP2) can connect natively over TLSv1.2 via "TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)" :

As long as we're not talking about circumventing Windows activation in general, I'll let the conversation continue. I just want to make sure that if anyone else posts in this thread, do not discuss circumventing Windows activation but if you have issues like this that may rely on your copy of Windows being genuine and it is...then feel free to discuss. Thanks!

well i have made a test version but notice this one is only experimental del

Ok, I understand. Just to be sure then, In term of polyfill is there any difference? UXP-5.1.0 supports: std-queueMicrotask, dhl-optchain and tmx-optchain. From what I tested it seems 4.8.5 is good on those polyfill as well, and I think I can give the link to a modified palefill-1.11.xpi that supports NewMoon28, Serpent59, IceApe-UXP and BNavigator without overloading those on UXP-4.8.5+ here for people that are interested: https://github.com/RamonUnch/palefill/releases