What is com.apple.WebKit.WebContent.CaptivePortal?

The CaptivePortal we are experiencing on our Internet appears to be more than just an initial check for the Internet. Given the things we can and cannot do on our devices I am assuming it is not 'all good". For example, such blocked websites and the inability to upload images or files to Apple Community forum and VirusTotal and the inability to share files from Google Drive.

It is also worth mentioning that Safari and other browsers on all the iOS devices are mysteriously beta versions, including the SpringBoard app.

In the WiFi setting the following appears:

Portal state
Captive portal detected

In the net.plist is the following:

In logs, com.apple.WebKit.WebContent.CaptivePortal creates the following (mostly non-typical) service stubs:

It regularly creates the 'implicit endpoint upfront', and then 'drains messages'.

(com.apple.WebKit.WebContent.CaptivePortal) <Notice>: created the implicit endpoint upfront
(com.apple.WebKit.WebContent.CaptivePortal) <Notice>: draining messages from com.apple.WebKit.WebContent.CaptivePortal

CaptivePortal also gets a number of warnings, these are some examples:

<Warning>: denied lookup: name = com.apple.distributed_notifications@Uv3, requestor = com.apple.WebKi[644], error = 159: Sandbox restriction
<Warning>: denied lookup: name = com.apple.tccd.system, flags = 0x8, requestor = com.apple.WebKi[644], error = 159: Sandbox restriction
<Warning>: denied lookup: name = com.apple.analyticsd, flags = 0x8, requestor = com.apple.WebKi[644], error = 159: Sandbox restriction
<Warning>: denied lookup: name = com.apple.audio.AudioComponentRegistrar, requestor = com.apple.WebKi[644], error = 159: Sandbox restriction
<Warning>: denied lookup: name = com.apple.audio.SandboxHelper, requestor = com.apple.WebKi[644], error = 159: Sandbox restriction
<Warning>: denied lookup: name = com.apple.windowserver.active, flags = 0x9, requestor = com.apple.WebKi[644], error = 159: Sandbox restriction
<Warning>: denied lookup: name = com.apple.analyticsd, flags = 0x8, requestor = com.apple.WebKi[1175], error = 159: Sandbox restriction
<Warning>: denied lookup: name = com.apple.windowserver.active, flags = 0x9, requestor = com.apple.WebKi[1175], error = 159: Sandbox restriction

I've included a snippet from a macOS log. Logs are typically long and boring, however it is interesting at times to watch particular events unfold where an action is initally denied and how it gets around that to succeed.

Though CaptivePortal is probably a legitimate process as part of connecting to the Internet, it is usually found in situations where control is required, such as a hotels WiFi for guests. Given the constant types of activities of com.apple.WebKit.WebContent.CaptivePortal and it’s friends I am assuming it has taken more control than necessary.

Hmm, if that is the case then it’s interesting that it operates from the path: /private/preboot/Cryptexes/OS/System/Library/Frameworks/WebKit.framework/XPCServices/com.apple.WebKit.WebContent.CaptivePortal.xpc/com.apple.WebKit.WebContent.CaptivePortal

/Applications/MobileSafari.app/MobileSafari doesn’t seem everything it’s meant to be if it’s truly a version from the AppStore.

Quite odd that WebKit and MobileSafari on iOS are running processes in kernel mode.

Possibly even more odd is why Safari WebKit is using AppleNeuralEngine.framework ANECompilerService with Espresso…

The path "/private/preboot/Cryptexes/OS/System/Library/Frameworks/WebKit.framework/XPCServices/com.apple.WebKit.GPU.xpc/com.apple.WebKit.GPU" does not align with the typical directory structure of iOS devices. It seems to resemble a macOS directory structure instead.

On iOS devices, the file system is structured differently, and the paths would typically start with "/var" or "/private/var" instead of "/private/preboot" or "/System/Library/Frameworks".

Quite often my iPad is listed on various platforms as being Mac OS X 10 which may explain the modified iOS in order to run beta apps without TestFlight.

The presence of a captive portal on a private network makes no sense. The additional recent discovery of various websites logging in through API’s when there is no need for it, along with the error messages I am seeing using Google chrome developer tool (login field modifications) suggests there is still an active WebKit vulnerability exploit, among other things.