As far as I can tell these end up duplicating functionality provided by Base64Utilities (exposed to the web through Source/WebCore/page/WindowOrWorkerGlobalScope.idl). And it would be non-standard if that would mean they continue to be exposed in other contexts, such as ShadowRealms or worklets. On the other hand, if we need these to be exposed in PAC files we probably need something more complicated.
<rdar://problem/109155613>
(In reply to Anne van Kesteren from comment #0) > As far as I can tell these end up duplicating functionality provided by > Base64Utilities (exposed to the web through > Source/WebCore/page/WindowOrWorkerGlobalScope.idl). And it would be > non-standard if that would mean they continue to be exposed in other > contexts, such as ShadowRealms or worklets. > > On the other hand, if we need these to be exposed in PAC files we probably > need something more complicated. Hey Anne, thank you for filing this! Please note that atob() / btoa() are only exposed for JSC shell (Tools/Scripts/run-jsc), along with ~100 other utility functions (e.g. createGlobalObject()), and not for any kind of web content. With that in mind, could you please expand your concerns regarding ShadowRealms / Worklets?
Do we use the JSC shell for PAC files? Or does that also have its own runtime? If it's not exposed anywhere I don't have any concrete concerns.
(In reply to Anne van Kesteren from comment #3) > Do we use the JSC shell for PAC files? Or does that also have its own > runtime? Can't tell for sure: tried grepping "FindProxyForURL" PAC, seems like we don't support that anymore? Also the latest radar on PAC is from 2011 it seems like it was implemented via JSC API so in a safe way w/o JSC shell. JSC shell has plenty of dangerous methods that greatly increase security risks, so it's not used anywhere around user-land code.
Thanks!
Correct, PAC file support doesn't use the jsc shell, and never did. It is implemented in CFNetwork using JavaScriptCore, of course.