Web Excursions 2022-07-31
Snapchat's Probably Screwed
today’s piece will be in two parts.
First an examination of their growth/product and second, an in-depth guide/analysis of their role in the digital ad market.
The problems start, unfortunately, at slide 1.
Positioning: Snapchat is a camera company that doesn’t actually sell a camera.
how bizarre this claim is.
Snap is a company that utilizes other devices’ cameras to facilitate their messaging and entertainment app.
Focusing the mission of the company on being a “camera company” has led the organization in a totally fruitless exercise of hardware development
All of this is a distraction, a narrative mirage to distract retail investors.
This incorrect positioning is purposeful
because it allows the company the room to burn cash on vanity projects and enjoy an innovation premium in their stock price.
Almost all of its growth has come from international expansion (particularly in India).
The change that happened in 2018?
They released a functioning Android app.
Social media platforms’ ad efficacy is determined by 3 interrelated buckets of variables:
Ad Performance
How well the average ad does on the platform and how measurable are those results
determined by two variables: targeting and attribution
Ad Inventory: How many slots and formats of ad space does the platform have to sell
in their defense, they do have more typical video formats that other advertisers use.
Small businesses are better at static photos than they are at video.
If Meta is struggling to get advertisers to produce video ads, you can bet that Snap’s problems are even greater! Worse, only Snap is really pushing AR ads.
This means that this type of ad inventory will be limited to large-scale, enterprise marketing teams.
Ad Price
Whether ad inventory is determined via auction mechanics or contract sales
Ad price is a function of the volume of bidders, how much those bidders are willing to pay, and by which method the price is set.
attribution is where Snap really got in trouble.
Apple’s changes had affected them in a serious way (the stock price dropped 20% following this announcement).
This pattern of flip-flopping played out one more time with earnings in January being more positive than expected, than the most recent Q2 disaster.
Far less efficient than a bottom-up system.
As we discussed earlier, ATT has completely broken ad systems that relied on 3rd party tracking.
Simultaneously, the company blamed that macro conditions have caused a deterioration in companies doing brand deals.
The State of Mac Security
Over the last few months, much has changed in Mac security.
macOS 12.5 will be the last update to Monterey containing general bug fixes and enhanced features.
Although it still didn’t address a remaining serious memory leak, as far as I can see all other serious bugs have now been addressed, together with another fifty security vulnerabilities.
For those remaining on Big Sur, the update to 11.6.8 also brought plenty of fixes for vulnerabilities.
However, Catalina Security Update 2022-005 is likely to be its last as it slips into a quiet retirement
Apple has shifted emphasis to a new set of tools in XProtect Remediator, which appear set to take over from MRT most likely with the release of Ventura.
At present, Apple hasn’t provided any version of that new suite of tools to run on macOS earlier than Catalina.
There are widespread reports of increasingly unreliable macOS system and security data updates too.
Just because Software Update might reassure you that “your Mac is up to date” doesn’t mean that it is fully up to date at all.
This applies particularly to security data updates including XProtect and XProtect Remediator, most of all when you’re running a local Content Caching server.
check that your Macs haven’t quietly fallen behind with those updates.
work through the apps and bundles in
/Library/Apple/System/Library/CoreServices, or in earlier versions of macOS/System/Library/CoreServices.
Virtualisation on Apple Silicon Macs: 5 Hypervisors and Virtualisation
Central to virtualisation is software known as a hypervisor
The name is derived from it being the supervisor of supervisors.
two types of virtualisation.
Type 1, also known as native or bare metal, runs a hypervisor directly on its hardware, and the guest operating systems run on that hypervisor
E.g., VMware ESX Server and Microsoft Hyper-V.
Type 2, also known as hosted, runs a primary host operating system on the hardware, and hypervisors then run on top of, or in close conjunction with, that to deliver the same range of services to the guest operating systems.
E.g., VMware Fusion, Parallels Desktop and Oracle VirtualBox.
Handling problems
how the hypervisor deals with guests trying to run instructions which interact with the system state, so are deemed sensitive.
Sensitive, unprivileged instructions can’t be virtualised, and a hypervisor needs some method of handling them if a guest operating system is to be run virtualised.
The older approach: full or software virtualisation
requires the translation of sensitive instruction sequences before they can be executed, imposing performance overhead.
hardware virtualisation, HVM or HV
With the introduction of hardware support, running unmodified guest operating systems became simpler, as problem instruction sequences can be executed directly.
avoids any translation overhead
E.g.,
Intel’s VT-x feature set
ARM’s AArch64 virtualisation, sometimes referred to as its Virtualization Extensions
ARM Virtualization Extensions feature an additional ‘exception level’, EL2 hypervisor,
which offers stage 2 translation, EL1/0 instruction and register access trapping, and virtual exception generation.
Stage 2 translation allows a hypervisor to control which memory-mapped resources a VM can access, and
where those appear in the VM’s address space, augmenting the stage 1 translation controlled by operating systems.
Trapping allows a hypervisor to trap operations, such as those configuring low level controls, and emulate them where necessary.
Another important consideration with Type 2 hypervisors is support for hardware in the form of standard devices
Apple has separated these from its Hypervisor framework, introducing them in its higher-level Virtualization framework in macOS 12.
This provides an abstraction layer over I/O devices conforming to the Virtio standard (for most devices), and requires both the guest and host operating systems to support that standard.
When a guest passes requests to a front-end Virtio device para-driver, they are handled by a Virtio back-end driver, in turn interacting with the device.
Virtio support in the Virtualization framework limits the range of guest operating systems to Linux and macOS 12 and later
Apple’s appears to be the first to run at scale on SoCs with heterogeneous core types
macOS hypervisor currently treats its vCPUs as having identical cores, and
threads run on them are allocated to physical CPUs as if they all have the same high QoS.
Guest macOS thus ignores QoS and the normal core allocation scheme.
Virtualisation on Apple Silicon Macs: 6 Support Limits
Big Sur
Lightweight virtualisation doesn’t support macOS 11 Big Sur either as a guest or host,
except for command-line Linux systems (also supported on Intel Macs), and
even those have severe constraints on the devices they have access to.
Monterey
can host macOS Monterey and later, and command-line Linux systems, but with significant limitations.
It also lacks support for GUI Linux guests, as the Virtio ‘Scanout’ Graphics Device required isn’t available to Monterey hosts.
Virtio support in Monterey hosts and guests isn’t as complete as in Ventura
the lack of support for folders shared between the host and guest using the Virtio File System Device.
The only good workaround that I’ve found so far is to enable file sharing on the host, and connect to that using networking support in the guest.
Clipboard support through a Spice Agent Device isn’t supported in Monterey guests or hosts
Virtio Multiport Console Devices aren’t implemented for macOS 12 hosts or guests.
Rosetta 2 translation of Intel code running in a Linux guest isn’t available from a Monterey host,
unable to start macOS guests with start options, which currently includes starting in Recovery mode.
Ventura
Apple apparently doesn’t currently intend to support iCloud access from guests,
even those that have been granted the entitlement for a Bridged Network Device to interact directly with physical network interfaces on the host.
Other network authentication relying on the Secure Enclave of the host also appear to be unsupported.
Neither the Virtualization nor the Hypervisor frameworks include AMP support, to allow guests to allocate vCPUs to specific types of core on the host.