“offloading”

hi, I don't hope setting your network to less secure is the answer. Although this would fix a lot of problems ;) I think the culprit is: Wed Dect2 10:04:29.904 Driver Event: _bsd_80211_event_callback: APPLE80211_M_ROAM_START (en0) I have the same issue, which is very annoying for video calls. (MBPro 2015/Big Sur and Fritzbox 7580 with Mesh using FB-Extender 3000) No other devices seem to experience this issue. My current knowledge is: Running a ping --apple-time 192.168.188.110 -i 0.1 13:21:12.730147 64 bytes from 192.168.188.110: icmp_seq=3750 ttl=64 time=1.214 ms 13:21:12.836592 64 bytes from 192.168.188.110: icmp_seq=3751 ttl=64 time=3.009 ms Request timeout for icmp_seq 3753snip- Request timeout for icmp_seq 3787 13:21:16.694166 64 bytes from 192.168.188.110: icmp_seq=3788 ttl=64 time=3.420 ms 13:21:16.805075 64 bytes from 192.168.188.110: icmp_seq=3789 ttl=64 time=4.709 ms and a tail -f /var/log/wifi.log Tue Dec 15 13:21:12.857 Driver Event: _bsd_80211_event_callback: APPLE80211_M_ROAM_START (en0) Tue

You say Xcode Previews has no security concern? You also say health could not be un-installed yet is allowed the capabilities of offloading the app. The purpose of Xcode Previews is to back door in to your device effortlessly sandboxed while testing your own apps in real time as you edit them, this can also be done remotely . And that is a security concern . I have researched and done some brushing up on this app since the launch of the iOS being installed to my device while connected via apple car play to my cars navigation and entertainment system that alternatively fried and damaged my vehicles electronics . This occurrence has also been acknowledged by apple that such an error occurred within the CarPlay features due to an accidental exploit during the update and that acknowledgment had since been de-published from community forums. Back in late December 2021. So don’t bother looking anymore. However the forums at XDA may still have the sources . I am no developer, even though I had researched th

Has anyone found ways to improve compatibility with other system extensions? That is a really, really hard problem which doesn't really have any easy answer. The first thing to understand here is what the problem actually is. Architecturally, an ES client has two primary concerns to deal with: Process individual events quickly. Minimize activities that generate additional events. In the basic case, the second concern is easy to overlook. It's easy enough for a client to mute its own helper processes (direct workers) and the work being done by other processes like Apple's daemons are (typically) relatively small. As long as the client has certain amount of parallelism, number two can often be relatively hidden. That breaks down once you hit this scenario: Some users are experiencing performance problems when running our extension alongside other system extensions At that point, what you basically have is a pipeline of ES clients which are both generating AND approving auth events for each other. Performance pr

Hi all, I'm looking for the specifications for the accelerometers used in current iPhone and iPad devices, including the sensitivity and the update rates possible. We've never published any formal documentation about what the exact capabilities of the hardware were. However, I have a word of caution around this: Despite the documentation saying it's 100Hz, I've not yet found it to be better than 50Hz on any of iPhone SE, 8 or 11, nor iPad mini or Pros. Having worked with many developers using CoreMotion, I've seen the same pattern happen MANY times: A basic motion analysis engine is implemented, typically using the real time API and the with a target queue. The main thread or other busy thread are entangled with that algorithm, either because the code is running directly on that thread or because of implicit relationships which aren't as visible. Testing begins and the results are somewhat positive, however, there are issues with random data glitches or other oddities in the data. The assumption is made that

Can you clarify the circumstances in which mach ports are leaked? Well, the unhelpful (and slightly flippant) answer is basically anytime they're not properly deallocated when they're no longer useful. More practically, the whole reason mach ports create issues IS that it's often quite difficult to connect any given mach port with the specific component responsible for managing that unit. In terms of run loop semantics specifically, I think you'd (potentially) generate a leak anytime you destroy an thread without removing/stopping all of it's input sources*. *Strictly speaking, that isn't necessarily a guaranteed leak. For example, some of our frameworks register thread destruction handlers so to handle clean up. However, at that point you're relying on the details of our own implementation, which is never ideal. Also, keep in mind that this isn't just about mach port leakage, but could involve any other resource who's management happened to be tied to that thread. The while loop in the original post is in a

The practical follow-on question: what entitlements exist today for block device ioctls (DKIOCGETBLOCKSIZE, DKIOCGETBLOCKCOUNT)? I'm not sure what you mean here. Having said that, the short answer is that I'm not aware of any entitlements relevant to this area of the system. The open question is whether the sandboxed extension can create and bind a socket at a path reachable by privileged tools outside the sandbox (e.g., /var/run/zfs/zfsd.sock). If that's permitted without a special entitlement, this blocker is resolved for us. First, just to clarify, privilege (that is, running as root) as such doesn't actually matter here. Your FSKit extension can basically talk to whoever it wants (particularly through a socket), so any protection you're doing needs to be something you implement, not the system. I haven't played around much with what's actually possible, however: Your FSKit extension has access to an app group container as well as its own and any tool you write can have access to the same location. If you