Apple heeft publieke bètaversies van macOS 12 Monterey, iOS 15, iPadOS 15, watchOS 8 en tvOS 15 uitgegeven, zodat je nu nieuwe functies zoals SharePlay en Focus kunt testen.

Terwijl Apple deze bètaversies voor iedereen beschikbaar stelt, moet je ze zoals altijd vooral niet op een apparaat installeren dat je nodig hebt. Hoewel Apple de ontwikkelingsprocessen heeft verbeterd, zodat zelfs vroege bètaversies stabieler zijn dan vooheen, zul je toch gegarandeerd bugs, incompatibiliteiten en misschien wel datacorruptie tegenkomen.

Niet alleen is het noodzaak deze bètaversies op speciale test-apparaten te plaatsen, maar we raden ook aan je voornaamste iCloud-account niet te koppelen aan de bètaversies, voor het geval een bug hogerop voor problemen zorgt. Zo wil je niet dat een wankele bètaversie van Foto’s bijvoorbeeld al je zelfgemaakte albums verwijdert. Hoewel we altijd aanraden om reservekopieën te maken voordat je een nieuwe versie van een besturingssysteem installeert, en zeker van bètaversies, moet je deze alleen installeren op een apparaat dat je zonder erbij na te denken en zonder gevaar van dataverlies schoon kunt vegen.

We raden je aan wars te blijven van bètaversies van watchOS als je geen ontwikkelaar van watchOS bent. Voor Macs, iPhones, iPads en zelfs Apple TV’s zijn er manieren om een corrupte installatie te herstellen, dit is bij de Apple Watch echter niet het geval. Mocht je in de problemen komen, dan zul je de hulp van Apple in moeten roepen om je Apple Watch te herstellen.

Om een of meerdere bètaversies uit te proberen, ga je naar de Apple-pagina met publieke bètaversies, kies je vervolgens je besturingssysteem en volg je de instructies. Dat is meestal het installeren van een speciaal profiel op je apparaat, waarna je het besturingssysteem kunt updaten via Software-update.

Tot slot, denk eraan dat de belangrijkste reden om publieke bètaversies te testen het rapporteren van bugs is. Zorg er daarom voor dat je eerst het advies van David Shayer leest: “Hoe meld je bugs aan Apple zodat ze worden opgelost” (17 juni 2020).

T-Mobile heeft zich in de Verenigde Staten ontpopt tot een aantrekkelijke keuze voor wie op zoek is naar een snelle 5G-datadienst met goede dekking, zoals ik onlangs opmerkte in “De iPhone krijgt 5G, maar is het de moeite waard?” (19 november 2020).

De aanbieder staat voor de uitdaging gebruikers weg te lokken bij de mobiele reuzen AT&T en Verizon, die tot voor kort elk een groter marktaandeel hadden. De fusie van T-Mobile met Sprint heeft het speelveld vorig jaar gelijk gemaakt.

Om dat te bereiken is T-Mobile agressief geweest in het aanbieden van gratis "testritten". In 2014 leende het bedrijf mij een iPhone 5S om zijn dienst gratis uit te proberen. Dit was geen persvoordeel, iedereen kon er een lenen. De afgelopen jaren heeft T-Mobile wifi-hotspots met gratis 5G-diensten naar potentiële klanten gestuurd, die de apparaten vrijelijk aan anderen kunnen doorgeven voor hun proefritten.

In hun nieuwste testrit-variant biedt T-Mobile aan om gebruikers tijdelijk zijn dienst gratis te laten gebruiken op recente iPhone-modellen: de iPhone XS, XS Max, XR en later, via hun eSIM-capaciteit.

Een eSIM is het volledig digitale equivalent van een fysieke simkaart. Moderne iPhones hebben meestal een sleuf voor een fysieke sim en ondersteuning voor een eSIM, wat betekent dat de iPhone kan jongleren met diensten van twee providers. Apple noemt dit dual-sim.

Het is dit dual-simscenario dat T-Mobile slim uitbuit om je de dekking en snelheden te laten uitproberen.

T-Mobile's ‘Netwerk Test Drive’-programma voor de iPhone biedt een Test Drive-app die je snel door de stappen leidt om de dienst op je iPhone te activeren zonder je primaire service te wijzigen of op enigerlei wijze aan te tasten. Het geeft je onbeperkt spraak-en tekstverkeer met een toegewezen telefoonnummer, samen met 30 dagen of 30 GB van 5G data-service, afhankelijk van wat het eerst komt.

Instellen: dat gaat snel!

Om in aanmerking te komen voor de netwerk-testrit, moet je iPhone ontgrendeld zijn, met (uiteraard) de eSIM-functie inactief. Na het downloaden controleert de Test Drive-app of dit het geval is voordat je verder gaat.

De installatie verloopt daarna snel, zonder dat factureringsgegevens nodig zijn. De app leidt je door slechts een paar stappen om T-Mobile - aangeduid als "secundair" - in te stellen, naast de primaire provider van de iPhone.

Sommige van de instellingsopties kunnen verwarrend lijken, maar ik denk dat T-Mobile hier verstandige keuzes maakt. Het bedrijf raadt aan om je primaire provider als standaard te laten staan voor uitgaande telefoongesprekken, sms-berichten, iMessages en FaceTime-gesprekken, terwijl je de secundaire T-Mobile-lijn als standaard opgeeft voor mobiele data. Als je dan iemand belt of een bericht stuurt, komt dat van je gebruikelijke nummer en niet van het tijdelijke nummer dat T-Mobile aan je eSIM heeft toegewezen. Maar voor mobiele data is het uitgaande nummer niet relevant en dat is toch wat je meestal wilt testen met het T-Mobile-netwerk.

Maak je echter niet te veel zorgen over de standaardinstellingen, want je kan ook na afloop van de installatie van de Network Test Drive-app nog aan de mobiele instellingen sleutelen.

Ik heb nog nooit twee mobiele abonnementen naast elkaar op mijn iPhone gehad, dus het zien van twee signaalsterktebalken linksboven in het Control Center was nieuw voor mij.

Beide accounts zijn elders op de telefoon toegankelijk en in te stellen. In de Telefoon-app kan je kiezen welke lijn je wil gebruiken voor uitgaande gesprekken. Je zal misschien een aantal uitgaande gesprekken met vrienden willen voeren (waarschuw ze van tevoren voor het nieuwe nummer) om de spraakkwaliteit te evalueren.

In Instellingen vind je een heleboel opties waarmee je het meeste uit je testrit kunt halen. Je kunt:

• Je primaire provider tijdelijk deactiveren zodat je je volledig kunt onderduiken in de diensten van T-Mobile: Ga naar Instellingen > Mobiel netwerk, tik op je primaire abonnement en klik op de knop bovenin om deze lijn uit te zetten.
• Overstappen op bellen via wifi: T-Mobile ondersteunt deze functie wel, maar deze staat standaard uitgeschakeld. Ga naar Instellingen > Mobiel Netwerk, tik op T-Mobile’s mobiele abonnement en zoek naar Bellen via wifi.
• Schakelen tussen mobiele data toestaan: Als je twee actieve lijnen hebt, kan je deze functie gebruiken om de telefoon beide mobiele netwerken te laten gebruiken, afhankelijk van de dekking en beschikbaarheid. Je vind de schakelaar onder Instellingen > Mobiel netwerk > Mobiele Data.
• Een standaard-lijn voor bellen toewijzen: Zoek deze instelling onder Instellingen > Mobiel netwerk.
• Persoonlijke hotspot gebruiken: Je standaard-abonnement ondersteunt deze functie wellicht en T-Mobile ook tijdens het testen van het netwerk. Alle bestaande hotspot-instellingen (waaronder je wachtwoord) blijven zoals ze zijn; je gebruikt alleen data via een andere provider.

Voer, als je eenmaal alles hebt ingesteld, wat snelheidstesten uit om te zien hoe de T-Mobile-dienst presteert bij jou in de buurt. Op een iPhone of iPad kun je Ookla’s populaire app Speedtest gebruiken of zoek via Google op “speed test” voor Google’s interactieve snelheidstest.

Opkomst van de eSIM?

T-Mobile’s Network Test Drive is een slim marketing-truc, omdat het potentiële klanten meteen in contact brengt met de 5G-diensten van het bedrijf.

T-Mobile staat bekend om hun “middenband”-dienst (een bijkomstigheid van hun fusie met Sprint) die de balans houdt tussen dekking en snelheid. Het is niet zo supersnel als de high-band-dienst, die alle drie de providers in de VS bieden, maar die alleen beschikbaar is in enkele hoeken van bepaalde steden, terwijl de middenband een redelijk grote dekking heeft. Dit werkt in het voordeel voor T-Mobile — ook al is deze waarschijnlijk maar tijdelijk omdat de concurrentie ook overal spectrum inpikt — en daar maken ze mooi gebruik van.

Dit valt bij mij in goede aarde. Als ik zou overwegen om naar T-Mobile over te stappen, dan zouden een snelle installatie van de Test Drive-app en een paar minuten instellen me laten zien dat ik zou kunnen downloaden met snelheden boven de 100 Mbps — soms zelfs boven de 200 Mbps! — bij mij thuis in St. Paul en dat is meer dan het dubbele van wat ik krijg met mijn bedrade Comcast Xfinity breedband-abonnement. De upload-snelheden variëren nogal, maar bieden vaak veel meer snelheid dan mijn tergend langzame eencijferige Comcast-upload.

T-Mobile’s Test Drive is wellicht breder dan alleen maar de marketing van het bedrijf, met name als je kijkt naar het gebruik van eSIM. Het lijkt het startschot voor andere providers om ook dergelijke testritten aan te bieden aan mensen met iPhones en bepaalde Android-telefoons die één of meer eSIMs ondersteunen.

Zoals T-Mobile stelt, in marketingtaal die toch waar lijkt: “Bijna 90% van de mensen wil een mobiel netwerk proberen voor ze het aanschaffen. Maar draadloze netwerk-aanbieders zijn de enige bedrijfstak die de klanten dwingen om te kopen voordat ze het proberen.”

Als mensen eenmaal beseffen wat eSIM kan, wordt het misschien populairder voor ander gebruik. Apple heeft hier een lijstje van:

• Gebruik één nummer voor zakelijke telefoongesprekken en een ander nummer voor persoonlijke telefoongesprekken.
• Voeg een lokaal data-abonnement toe wanneer u naar het buitenland reist.
• Regel afzonderlijke abonnementen voor mobiele data en bellen.

Als eSIM-gebruik opeens enorm toeneemt in de komende jaren, dan is dat misschien wel dankzij T-Mobile. Ik ben in ieder geval overtuigd van het gebruik van een eSIM als een manier om een mobiel netwerk te testen.

Apple heeft op 23 juni 2021 een witboek gepubliceerd waarin het bedrijf terugvecht tegen de links-rechts-alliantie in de Amerikaanse politiek, die antitrust-wetgeving voor de huidige digitale tijd wil herdefiniëren. Het witboek, “Building a Trusted Ecosystem for Millions of Apps: The Important Role of App Store Protections,” tracht de ijzeren greep van het bedrijf op de iOS-App Store te rechtvaardigen, alsof het de gebruikers tegen malware en het wegfilteren van persoonlijke informatie en privé-gegevens wil beschermen.

Ik zal eerst een korte samenvatting van de belangrijkste punten in het document weergeven en vervolgens beoordelen of de positie van Apple redelijk is.

Apple waarschuwt tegen blijvende schade

De essentie van Apples argumenten is bekend, zowel bij de bezitters van Apple-producten als bij diegenen die de technologie van Apple of de antitrust-politiek volgen. Het bedrijf zet in dit witboek de argumenten op een gestructureerde manier uiteen. Het is een instructie voor de aankomende debatten in het Congress maar ook een poging van Apple om zich alvast te verdedigen tegen zes verwante wetsvoorstellen in het Amerikaanse Huis van Afgevaardigden, die er bijvoorbeeld voor zullen zorgen dat platformen open moeten staan voor concurrentie en meer toegang moeten verlenen aan gebruikers.

Er is ook regelgeving in de maak waar geen nieuwe wetten voor nodig zijn. De recentelijk benoemde voorzitter van de Federal Trade Commission, Lina Khan, ontwikkelde een visie voor een antitrust-analyse die beweert dat aan consumenten schade toegebracht kan worden, zelfs als door een monopoliepositie op korte termijn lage prijzen worden bewerkstelligd. Haar stelling maakt duidelijk dat het vervolgen van Apple in plaats van Amazon voor de prijzen van e-boeken door het United States Department of Justice eigenlijk geen zin had, omdat Amazon zo de markt verder kon domineren en controleren. Haar inzichten stonden haaks op het toen gangbare antitrust-gedachtengoed; haar aanstelling wijst op het voornemen van de regering Biden om afstand te doen van de nadruk op schade voor consumenten, zoals dat in het tijdperk Robert Bork gold, en een nieuwe weg in te slaan richting concurrentiebevordering. Khan won op 1 juli 2021 met 3 tegen 2 FTC-commissieleden een stemronde om een FTC-memo uit 2015, die de visie van Bork herbevestigde, te herroepen. Dit wordt gezien als een eerste stap richting beleidsverandering.

Door de veranderende wet- en regelgeving zal Apple waarschijnlijk verplicht worden om iOS en iPadOS voor sideloaden open te stellen, zodat een gebruiker software kan installeren buiten een officiële winkel om. Het Android-platform van Google staat dit al toe. Het ontwerpwetsvoorstel in het Huis van Afgevaardigden schrijft geen preciese wettelijke mechanismen voor, zodat Apple geen update van een app die vrije installatie toestaat uit hoeft te geven – het bedrijf moet alleen de mogelijkheid scheppen om dit te doen. De exacte bewoording van het ontwerpwetsvoorstel is als volgt:

Een aanbieder van een platform onder deze verordening, met direct dan wel indirect commercieel belang, is het niet geoorloofd om:

(1) een zakelijk gebruiker te beperken of te belemmeren in de mogelijkheid om toegang te verwerven tot of samenwerking aan te gaan met functionaliteiten van het platform, besturingssysteem, hardware of software, die beschikbaar zijn voor de producten, diensten of bedrijven van de beheerder van het platform onder deze verordening;

Het document van Apple is best goed te lezen en de argumenten zijn overtuigend geformuleerd, maar het is 26 pagina’s lang. Daarom volgt hier een samenvatting:

• Door sideloading zullen gebruikers misleid worden om kwaadaardige apps te downloaden, waardoor ransomware, snuffelsoftware en andere ongewenste apps geïnstalleerd worden.
• De privacy-regels van Apple kunnen niet aan gesideloade apps opgelegd worden, waardoor gebruikers kwetsbaar worden voor het delen van persoonlijke informatie en privé-gegevens. Sommige van dit soort apps kunnen zelfs komen van legitime bedrijven die zich aan de letter van de wet houden.
• App-winkels van derden zullen belangrijke doelwitten worden van kwaadaardige actoren. Die winkels kunnen de beste bedoelingen hebben maar zullen niet aan de middelen van Apple kunnen tippen.
• Kinderen zouden het ouderlijk toezicht kunnen omzeilen door apps te installeren die het toezicht ontwijken.
• Ouders zouden onbedoeld apps voor kinderen kunnen downloaden die kinderen in staat stellen eindeloos en ongecontroleerd aankopen te doen.
• Zelfs als je nooit de intentie zou hebben om een app te sideloaden, kan het zijn dat een werkgever of een school die jij of je kind bezoekt, vereist dat je een app van een winkel van derden installeert, waardoor je blootgesteld wordt aan clandestiene of kwaadaardige apps. Zelfs apps die door het bedrijf of de school gekozen zijn, kunnen actief zijn in afluisterpraktijken die Apple nooit zou toestaan, of ze nu wel of geen open kaart spelen.
• Gebruikers kunnen per ongeluk illegaal-gekopieerde apps van app-winkels van derden kopen.
• Ontwikkelaars zouden hun apps in illegaal-gekopieerde vorm tegen kunnen komen in app-winkels, zonder dat ze er iets tegen kunnen doen.

Het document legt vervolgens uit hoe het beoordelingsproces van apps verloopt. Ingediende apps worden door mensen en door geautomatiseerde systemen onderzocht om te zien of ze werkelijk doen wat ze beloven, niet kwaadwillend zijn en niet misleiden. In dit hoofdstuk vertelt Apple dat een aantal van de privacy- en aankoopfuncties door "side-loaded" apps genegeerd of tenietgedaan zouden kunnen worden, ook de beperkingen die belangrijk zijn voor privacy, voor bescherming van kinderen tegen ongewenst aankopen doen, en voor het beheer van abonnementen. Dit betekent dat kinderen ongewenst blootgesteld zouden kunnen worden aan kwetsende inhoud, dat herhaalde aankopen zouden kunnen plaatsvinden en dat aankopen ongewenst door kinderen gedaan zouden kunnen worden. "Onze controles zouden niet meer volledig gelden voor side-loaded apps." (En let op de lijdzame toon!)

Dit is in theorie allemaal best redelijk. Maar er rijzen nu twee nieuwe vragen: waarom gelden deze problemen kenneljk niet op macOS? En ten tweede: in hoeverre is de beschreven situatie anders dan de huidige? Laten we beginnen met de Mac-situatie.

Hoezo is dit op de Mac heel anders?

Gelden, in het hier en nu, voor de Mac niet precies dezelfde zorgen over side-loading? In macOS bestaan op dit moment drie beveiligingsgradaties waarbinnen je apps op de Mac kunt installeren. De hoogte beveiliging staat alleen installatie van apps uit de Mac App Store toe. Het tweede beveiligingsniveau staat toe dat je Mac Store-apps installeert plus apps die een test op aanwezige kwetsbaarheden en malware (het zogenaamde "notarisatie"-proces) hebben doorstaan, en daarmee een versleutelingshandtekening van Apple kregen. Als het niet lukt, in dit tweede niveau van beveiliging, om een door jou vertrouwde app te installeren, dan kan je een serie acties in Finder toepassen om een niet-ondertekende, niet-genotariseerde app toch te installeren. En voor de komst van de Mac App Store naar de Mac, bestond natuurlijk alleen het laagste niveau van beveiliging.

Het tweede en derde beveiligingsniveau hierboven worden nu - met terugwerkende kracht - "side-loading" genoemd, en het is nog steeds de meestgebruikte manier voor gebruikers om apps op de Mac te installeren. Soms omdat de ontwikkelaar geen zin heeft om zijn software via de Mac App Store te verkopen; soms omdat de desbetreffende app (denk bijvoorbeeld aan Keyboard Maestro) niet aan de technische en sandbox-vereisten van de Mac App Store kan voldoen, zonder al zijn handige functies te verliezen.

Het antwoord dat Apple gebruikt op de vraag naar de vergelijking met de Mac, bestaat eruit om het belang van de Mac te bagatelliseren. Het bedrijf stelt dat meer dan een miljard mensen dagelijks gebruik maken van hun iPhone (geen woord over iPad en iPod touch hier), en dat betekent het volgende:

Dit enorme aantal gebruikers maakt iOS een aantrekkelijke en lucratieve prooi voor cybercriminelen en oplichters. Side-loading zal een tsunami van nieuwe investeringen opwekken, allemaal gericht op het aanvallen van de iPhone, en op een schaal die niet vergelijkbaar is, met aanvallen op andere platforms, zoals de Mac.

Dit is zeker geen onlogisch argument. macOS en iOS leven werkelijk in verschillende universums, zowel qua gebruik in de dagelijkse praktijk, als qua risico dat ze lopen om aangevallen te worden. Op dit moment is iOS als prooi bijna uitsluitend interessant voor staats-criminaliteit, omdat het systeem zo gesloten is dat iedere gevonden kwetsbaarheid meteen heel erg interessant is voor overheden die mensen willen observeren of hun activiteiten willen verstoren - of het nu gaat om criminelen, politieke activisten, of leden van de oppositie. (En bepaalde regeringen bestempelen politieke activisten en oppositieleden ook als criminelen). Er zijn in de afgelopen jaren genoeg iOS-kwetsbaarheden gerepareerd. Daarvan is er misschien niet één op grote schaal uitgebuit maar een aantal is wel degelijk op kleinere schaal ingezet tegen individuen of kleine groepen van doelwitten - zoals in een aantal landen tegen journalisten.

Hackers of cyber-onderzoekers die een effectief bruikbare kwetsbaarheid in iOS ontdekken, moeten vervolgens kiezen hoe ze hierop willen reageren. Het probleem kan gerapporteerd worden bij Apple, waarmee je soms een beloning kan claimen. Je kunt het - om persoonlijke of professionele redenen - publiekelijk bekend maken, zowel voor als nadat Apple en oplossing uitgebracht heeft. En tenslotte kan je de kwetsbaarheid verkopen, bijvoorbeeld aan een bedrijf dat beveiligingslekken verzamelt en verpakt voor overheden, of direct aan een geïnteresseerde regering.

Veiligheidslekken in Windows en Android zijn financieel extra aantrekkelijk voor wie het ontdekt. Daar levert het soms extra winst en minder risico op. Je kunt een kwetsbaarheid in malware verpakken, en daarmee gokken op geld uit ransomware, je kunt financiële informatie oogsten, de koers van cryptomunten kapen of software verhuren aan criminele zakenpartners.

Kwetsbaarheden in iOS zijn zeldzamer. Daarmee krijg je er meer geld voor (en onderzoekers krijgen hoger aanzien) maar zo'n lek is vaak minder breed toepasbaar. En ze zijn minder makkelijk uit te buiten doordat slachtoffers er niet vaak blind in zullen trappen. (Zo blijven jailbreaks vrij gangbaar, maar de eigenaar van het toestel moet eerst een groot aantal riskante stappen nemen voordat het werkt). Je verdient niet snel geld met zo'n lek (of combinatie van lekken). Van Windows en Android bestaan heel veel verschillende versies en daarbij is de betrokken software op heel veel toestellen ook nog niet gerepareerd - of is het zelfs niet mogelijk om de nog een "patch" te maken. Er zijn ladingen door piraten aangepaste Windows-systemen en hele gecorrumpeerde takken van Android-versies. Om al deze redenen is het eenvoudig om een grote hoeveelheid bruikbare doelwitten voor jouw aanval te kiezen.

Van de Mac zijn überhaupt veel minder computers in gebruik vergeleken met Windows-PC's, Android-telefoons en iPhones. En langzamerhand kan je stellen dat de beveiliging van Windows 10 even goed of zelfs beter is dan die van macOS 11 Big Sur. Maar los van deze cijfers: "the proof is in the hacking". Er is al eeuwen geen effectieve, breed ingezette ransomware of andere malware voor macOS ontdekt. Het kan zijn dat de slechterikken de Mac links laten liggen omdat de doelgroep gewoon te klein is. Mogelijk is het ook net te moeilijk om er genoeg geld mee te verdienen.

Kan Apple een hybride oplossing bieden die voldoet aan de vraag naar sideloading zonder de privacy in gevaar te brengen? De autoriserings- en ondertekeningsmodule van de Mac App Store biedt dat misschien maar het vereist nog steeds een betaald abonnement op het Developer Program van Apple en het naleven van de voorwaarden van Apple, inclusief een controle door zijn geautomatiseerde verificatieprocessen.

Kan Apple zich uit Sideloading onderhandelen?

Onbelemmerd sideloaden zonder medewerking van Apple zou een vreselijk idee zijn. Het is precies de reden waarom Apple gebruikers door hoepels laat springen om een niet-ondertekende en niet-geautoriseerde app in macOS te openen. Als Apple iOS zou openstellen voor sideloading zonder enige bescherming, zou het lijken op de scène uit Ghostbusters (1984) waarin een overheidsfunctionaris erin slaagt de ectoplasmatische insluitingseenheid uit te schakelen. Elk jaar verschijnen er tientallen miljoenen nieuwe malwarevariaties, ontwikkeld en ingezet door legioenen van individuele en georganiseerde misdaad en door de overheid gesteunde hackers die al hun dagen en nachten doorbrengen met het zoeken van gaten in iOS.

Ofschoon onbeperkt sideloaden misschien niet het beste is voor gebruikers, gebruikt Apple een klassieke mottekasteeltactiek om terug te slaan: in plaats van te pleiten voor een standpunt dat onpopulair is bij zijn critici en dat Apple wel bevalt (de muur), benadrukt het bedrijf in plaats daarvan een verwant maar veel beter verdedigbaar standpunt (de motte of heuvel). Het doel van Apple is totale controle over zijn platform en een royaal deel van alle inkomsten die daar doorheen gaan. Dat is de vestingmuur in dit geval - wat Apple wil maar moeilijk zou kunnen verdedigen als het openlijk zou worden gezegd. De motte, Apples gemakkelijk te beargumenteren positie, is dat smartphonegebruikers veilig en beveiligd willen zijn. De logische denkfout is Apples suggestie dat als het enige controle zou loslaten, iOS als Rome ten prooi zou vallen aan de barbaren, terwijl er in feite al tegenvoorbeelden zijn binnen het Apple ecosysteem.

Apple biedt zowel het macOS-model als zijn enterprise-ondersteuning al voor niet-App Store-installaties. Michael Tsai merkte dit op in een blog-artikel met een samenvatting van reacties op de whitepaper: "Bedrijven kunnen werknemers al dwingen om bepaalde apps te installeren en deze apps kunnen App Review al omzeilen via Apples enterprise programma." (Scholen kunnen dit niet gebruiken om apps naar leerlingen te pushen, alleen werknemers.)

Als Mac-eigenaars kunnen worden vertrouwd met "ondertekende en geautoriseerde programma's" met een niet voor de hand liggende uitzondering voor niet-ondertekende en niet-geautoriseerde programma's, en bedrijven kunnen worden vertrouwd met het maken van programma's en deze vrijgeven aan miljoenen werknemers, waarom kunnen individuele gebruikers dan niet ook enige controle krijgen? Apple heeft ook zijn verborgen XProtect en MRT (Malware Removal Tool), die alle apps kan controleren, zelfs de apps die zijn geïnstalleerd via het hierboven genoemde derde niveau van autorisatie en ondertekening.

Is Apple zo paternalistisch dat de samenvatting van deze whitepaper zou kunnen luiden: "Wij weten wat het beste voor u is. Vertrouw ons. Wij beschermen u."? Dit klinkt als de opening van elke dystopische superheldenfilm en tv-reeks, waaronder recent The Tick (seizoen 2), Invincible, en The Boys. (Vreemd genoeg zijn deze drie programma's allemaal gemaakt door Amazon. Probeert Jeff Bezos ons iets te vertellen?) Zou overbescherming kunnen bestaan om ons binnen grenzen te houden waar anderen baat bij hebben in plaats van voor ons eigen welzijn? Het is ook heel goed mogelijk dat Apple zijn paternalistische toon rechtvaardigt omdat het terecht van mening is dat een strenge hand noodzakelijk is, gezien de grote aantallen bedreigingen van zowel marketeers met slechte bedoelingen als de georganiseerde misdaad.

Een betere aanpak zou kunnen zijn dat Apple met ontwikkelaars, klanten, het Congres en de regering Biden (en ook met de EU en andere landen) onderhandelt over een soort middenweg, waarbij het een deel van zijn financiële invloed opgeeft in ruil voor een breder gematigd alternatief voor installatie uit de App Store alleen.

Hier zijn een paar geschilpunten waar Apple terrein zou kunnen prijsgeven:

• Verlaag de commissies van 15% en 30% naar 10% en 15%: Zowel ontwikkelaars als gebruikers zijn al gefrustreerd dat Apple zichzelf in het midden plaatst en probeert te beweren dat het niet puur uit is op geld verdienen - dat het waarde toevoegt aan het systeem ter waarde van 15% of 30% van de prijs van apps, abonnementen en digitale transacties. De commissie wordt al lang als te hoog beschouwd. Vorig jaar gaf Apple toe dat 30% te hoog was door een systeem aan te bieden voor kleine en middelgrote ontwikkelaars om dat te verlagen naar 15%, met enkele voorwaarden (zie "Apple verlaagt App Store-provisie voor kleine ontwikkelaars naar 15%", 18 november 2020). In 2016 veranderde Apple ook abonnementsverlengingen naar 15% en hebben ze naar verluidt privédeals voor minder dan 30% gesloten met sommige bedrijven. Als Apple verder zou gaan en de vergoedingen zou verlagen naar 10% voor kleine ontwikkelaars en 15% voor grotere, zouden veel negatieve gevoelens bij ontwikkelaars verdwijnen.
• Sta andere betaalwijzen dan die van Apple toe voor digitale zaken: Dwing ontwikkelaars niet langer om Apples in-app aankoopsysteem te gebruiken, maar sta digitale aankopen toe via kanalen waar Apple geen commissie van ontvangt. Op die manier wordt Apple gedwongen tot concurrentie om de gunst van ontwikkelaars, op basis van eenvoud en kostenplaatje.
• Sta koppelingen vanuit apps naar de website van de ontwikkelaar toe: Apple zou moeten toestaan dat apps koppelingen bevatten naar de website van de betreffende ontwikkelaar, ook voor abonnementen buite de app om. Apple heeft al overeenkomsten met hele grote bedrijven die iets dergelijks toestaan - waaom niet ook voor ontwikkelaars die slechts een paar duizend dollar per jaar omzetten? (En Apple moet ook eens ophouden met klagen bij uitgevers over hyperlinks in e-boeken in de Apple bookstore die naar Amazon en andere concurrenten verwijzen.)
• Stop met 'Sherlocking' van apps: Apple heeft uiteraard het recht om zelf apps te maken die functies bieden waar gebruikers om vragen. Maar je kunt het onmogelijk 'innovatie' noemen als je bestaande apps vrijwel volledig dupliceert en vervolgens de controle over de App Store gebruikt om de eigen app te promoten en gevonden te laten worden. Je zult een evenwicht moeten vinden die recht doet aan onafhankelijke ontwikkelaars.
• Verbeter je klantbescherming: Apples uitspraken over het waarborgen van een veilige App Store via bewaking met harde hand klinkt toch enigszins als holle frase als je beseft hoe eenvoudig het is om apps te vinden die misleidende namen gebruiken om ze op populaire apps van andere ontwikkelaars te laten lijken. (In 2018 onderzocht David Barnard de combinatie van misleidende apps en abonnementfraude uitgebreid.) Verder zijn er genoeg verhalen over apps met exorbitante prijzen of misleidende, dure abonnementen.
• Verbeter de bescherming van ontwikkelaars: Ontwikkelaars lopen omzet mis als gevolg van apps die klanten lokken met misleidende namen, advertenties die misbruik maken van de bekendheid van andere apps, en talloze nep-besprekingen. Het rapport stelt dat "Apple 244 miljoen accounts van klanten heeft verwijderd als gevolg van herhaalde fraude en misbruik.” Dat mag waar zijn, en het is zeker stof tot nadenken, maar Apple doet op dit vlak nog steeds niet genoeg.

Zal Apples rapport voldoende zijn om de overheid van de VS en de FTC af te houden van hun wens om consumenten meer keus te geven en aan minder restricties bloot te stellen? Op zichzelf lijkt dat onwaarschijnlijk. (Maar onderschat niet de invloed van andere krachten, zoals draagkrachtige lobbies.) Ik ben ervan overtuigd dat Apple een zekere mate van controle zal moeten opgeven in ruil voor een nog steeds belangrijke rol in het beschermen van gebruikers, zonder daarbij de enige poortwachter en tol-heffer te zijn.

Apple zou met de overheid compromissen kunnen sluiten die minder ver gaan dan wat ik hierboven voorstel maar Apples argumenten in het rapport overtuigen alleen op bepaalde punten. Bovendien hebben tech-reuzen in de VS op dit moment onder alle politici de wind tegen, ongeacht van welke partij ze zijn. Liberalen, conservatieven en andere stromingen zijn het vandaag de dag zelden ergens over eens, behalve in hun geklaag over de controle door 'Big Tech', het gebrek aan eigen keuze voor en bescherming van consumenten, en slecht gedrag tegenover verkopers. Degenen die het daar niet mee eens zijn vind je ook bij alle politieke stromingen, maar zijn duidelijk in de minderheid.

Naspel

Dan nog twee losse opmerkingen tot besluit. Allereerst merkt Apple enigszins merkwaardig op dat “In een studie werd gevonden dat apparaten die onder Android draaien 15 keer vaker werden geïnfecteerd met kwaadaardige software dan iPhone.” De voetnoot referert aan het Threat Intelligence Report 2020 van Nokia. De referentie is correct, maar de statistiek is tamelijk bizar. Het rapport stelt dat gemiddeld 0.23% van alle mobiele apparaten per maand geïnfecteerd worden. Gezien het feit dat er wereldwijd een paar miljard Android- en iOS/iPadOS-smartphones en -tablets gebruikt worden, zou dat betekenen dat er op elk willekeurig moment zo'n 5 miljoen apparaten besmet zijn, en dat 300.000 daarvan iPhones zijn. Dat aantal lijkt ons erg hoog, gezien wat we weten over de beveiliging van iOS.

Daarnaast opent het rapport met een citaat uit 2007 uit een soort blogbericht/open brief van Steve Jobs, oorspronkelijk geplaatst apple.com:

We trachten om tegelijkertijd twee volstrekt tegengestelde dingen te doen: een geavanceerd open platform bieden aan ontwikkelaars en tegelijkertijd onze iPhone-gebruikers te beschermen tegen virussen, kwaadaardige software, inbreuken op privacy, etc. Da's geen eenvoudige opgave.

Als je de voetnoot volgt zul je zien dat Apple nooit een permanente koppeling heeft gecreëerd voor deze uitspraak. Vanwege deze fout 14 jaar geleden moest Apple verwijzen naar een betrouwbare externe bron. Een die al 31 jaar het vertrouwen geniet van Apple-gebruikers en die zich al tientallen jaren inspant om er voor te zorgen dat ook stokoude URLs naar artikelen te allen tijde blijven werken, zelfs door drie verschillende web-publicatiesystemen.

Inderdaad, naar ons. Adam Engsts moeder was jarenlang Hoofdarchivaris voor Cornell University, en ik hoop dat ze trots is op haar zoon en schoondochter.

Als schrijver leef ik in mijn tekstverwerker. Welke app we voor TidBITS precies gebruiken is door de jaren heen veranderd. Eerst was er Nisus Writer Classic, daarna BBEdit en nu Google Docs. Toen we Nisus Writer Classic gebruikten, waren we afhankelijk van een server die AppleShare over IP draaide om samen te werken middels het klassieke IN (beschikbaar voor bewerken) en OUT (uitgecheckt door gebruiker) systeem voor mappen/versiebeheer/hernoemen. In de jaren waarin we BBEdit gebruikten, schakelden we het samenwerken over op het versiesysteembeheer van Subversion, zodat we de tekst eigenlijk als programmacode benaderden. (Zie “Gezocht: een beter samenwerkingssysteem voor documenten”, 3 april 2006.) Toen we naar ons huidige WordPress-contentbeheersysteem verhuisden (zie “TidBITS-infrastructuur wordt vernieuwd”, 20 november 2017), gingen we over op het schrijven en redigeren van alle artikelen in Google Docs, dat in samenwerkingsmogelijkheden topkwaliteit levert.

Uiteraard zou Google Docs, omdat het een webapp is, zich automatisch tussen alle andere tabbladen in een webbrowser nestelen. Ik kan daar niets mee, omdat ik vaak meerdere bestanden open heb en ook te veel tabbladen van pagina’s die ik moet lezen, waar ik naar moet verwijzen of waar ik op moet reageren. (“Hoi, mijn naam is Adam, ik ben verslaafd aan tabbladen.”) Wat tot gevolg heeft gehad dat ik Google Docs altijd in een site-specifieke browser (SSB) heb gedraaid, een hulpprogramma waarmee je een website of een aantal websites naar een alleenstaande app kunt ombouwen, met zijn eigen identiteit in de Dock, de appkiezer en dergelijke. Daar komt nog bij dat ik altijd met een druk op F1 naar mijn primaire tekstverwerker schakel, in welke app ik dan ook ben. Nu heb ik daar een Keyboard Maestro-macro voor, maar ik deed dit al lang voordat Keyboard Maestro bestond.

Naast mijn diepgewortelde verlangen om Google Docs in een afzonderlijke app te gebruiken, heb ik nog een aantal andere eisen:

• Ondersteuning voor vensters en tabbladen: ik werk aan veel bestanden, onder meer als ik jongleer met TidBITS-artikelen, maar meer nog in mijn rol als president van de Finger Lakes Runners Club. Dat laatste leunt zwaar op Google Docs en Google Sheets voor de administratie, samenwerking en het bijhouden van gegevens. Ik heb altijd een venster open voor TidBITS-bestanden en een ander voor FLRC-bestanden. In elk van deze vensters heb ik op elk willekeurig moment tussen de 3 en de 20 tabbladen open.
• Ondersteuning voor meerdere websites: Google Docs is in beide vensters altijd mijn eerste open tabblad, en met een dubbelklik open ik bestanden in een nieuw tabblad in Google Drive, Dus de SSB moet in dezelfde app zowel drive.google.com als docs.google.com kunnen plaatsen.
• Inkomende Google Docs-koppelingen ontvangen: wanneer ik een docs.google.com-URL aanklik, in Slack of Trello voor TidBITS of in Mimestream of Discourse voor FLRC, dan wil ik hiermee een nieuwe tab openen in mijn Google Docs-app. (Het kan ook in het verkeerde venster worden geopend, maar dat is een gering ongemak.) SSB's kunnen uiteraard de doel-URL niet regelen, maar er zijn Mac-hulpprogramma's die dit wel kunnen. Ik heb zelf BrowserFairy en Choosy getest en zal aan het eind van dit verhaal mijn bevindingen vertellen.
• Externe koppelingen naar de standaard ingestelde browser sturen: ik klik regelmatig op een koppeling in een artikel om iets te lezen of om te controleren of hij naar de juiste plaats gaat. Ik wil om twee redenen dat deze koppeling in mijn standaard browser (op dit moment Brave) opent. Ten eerste is dat wat ik verwacht, alle geopende documenten behalve die naar docs.google.com moeten openen in Brave. Ten tweede kan ik ze, als ze open zijn in Brave, op mijn linker scherm zien, terwijl ik op het rechter scherm aan het schrijven ben.
• Grammarly-ondersteuning: met tegenzin ben ik een grote liefhebber geworden van de schrijfondersteuning van Grammarly. Typefouten, dubbele woorden en andere fouten die er bij iedereen insluipen worden door Grammarly opgevangen. Ik moet wel zeggen dat ik niet veel van Grammarly's schrijfsuggesties gebruik, maar het programma is onmisbaar om fouten op te sporen waar je snel overheen kijkt. Grammarly heeft extensies voor Chrome, Firefox en Safari. Niet alle SSB's ondersteunen browser-extensies.

Sinds een aantal jaren maak ik gebruik van het gratis programma Epichrome, een op Chrome of Brave gebaseerde SSB die gecreëerd is door Github-gebruiker dmarmor. (Zie “Website-specifieke browsers maken met Google Chrome”, 6 maart 2015.) Epichrome voldoet aan alle criteria die ik boven heb genoemd met behulp van BrowserFairy of Choosy. Sinds een recente belangrijke update van Epichrome worden externe koppeling in Google Docs zowel intern als in mijn hoofd-webbrowser geopend, een vervelende duplicatie. Ik heb de fout gerapporteerd, maar helaas kwam snel daarna het bericht dat dmarmor de ontwikkeling van Epichrome aan het einde van 2021 stopzet.

Vanwege deze onzekere toekomst van Epichrome heb ik besloten dat het tijd werd om naar iets anders te zoeken. Hieronder staat wat ik heb gevonden. Als je bekend bent met een andere SSB voor de Mac die aan mijn criteria voldoet, laat het dan weten in de reacties.

Coherence X

Coherence X van BZG maakt het voor veel verschillende webapps makkelijk om met één klik een SSB te creëren, maar je kunt ook de applicatienaam en opstart-URL instellen. Je kunt natuurlijk ook voor elke andere website die je wilt een SSB creëren.

De geavanceerde instellingen van Coherence X zijn essentieel. Met de toets ‘Get App Icon' kun je een illustratie inladen vanaf het internet of je Mac. (Zoek in Google Afbeeldingen  naar “Programmanaam icoon” en je zult veel afbeeldingen vinden.) Met de toets ‘Browser Engine' kun je kiezen tussen Chrome, Brave en Edge. Alle drie zijn gebaseerd op Chromium-technologie, maar je voorkeur kan uitgaan naar de veelzijdigheid van Chrome, de privacy van Brave wat dan ook van Edge. (Heb je een van deze browsers geïnstalleerd, dan heb je ook Google Chrome Canary en Opera als opties.) Tot slot: de kleine toets aan de rechterzijde van de drie blauwe toetsen geeft toegang tot meer instellingen. Een aantal van deze instellingen heb je nodig:

• Use application as browser: wanneer dit is geselecteerd zal Coherence X de SSB als webbrowser registreren. Dit is nodig als je gebruik wilt maken van programma's zoals BrowserFairy of Choosy om er een URL naartoe te sturen.
• Use “Incognito” Mode: persoonlijk heb ik geen gebruik voor deze instelling, maar ik kan me situaties voorstellen waarbij je niet wilt dat je SSB de browsergeschiedenis, cookies, website-informatie of formulier-informatie bewaart. (Ter herinnering: privé browsen verbergt je activiteiten niet voor websites of de internetprovider.)
• Application whitelisting: met deze optie stel je in hoe de SSB klikken op koppelingen binnen de SSB afhandelt. Wanneer hij geselecteerd is, zorgt deze optie ervoor dat koppelingen in hetzelfde domein als de SSB ook binnen de SSB worden weergegeven. Je kunt later met de extensie Coherence Helper kiezen welke regels van toepassing zijn voor koppelingen buiten het SSB-domein. Mijn voorkeur is om de standaard webbrowser te openen.
• Create as tabbed app: bij de selectie van deze optie zal de SSB tabs ondersteunen, net als je internetbrowser. Dit is wat ik wil met Google Docs. Wil je geen tabs en een enkel venster hebben, selecteer deze optie dan niet.
• Icon style: selecteer je voorkeur.

Coherence X werkt goed samen met BrowserFairy en Choosy. Omdat het een Chromium-browser is, kun je er alle Chrome-extensies bij installeren, inclusief Grammarly. (BZG beweert dat je extensies en profielen uit je browser kan importeren en in gemaakte SSB's kan gebruiken, maar ik ben die functie niet tegengekomen. Voor mij is het niet belangrijk. Grammarly installeren is gemakkelijk genoeg als je Coherence Helper zo instelt dat je tijdelijk naar elke URL kan surfen.) Als zodanig voldoet hij aan al mijn bovenstaande eisen en is hij momenteel mijn eerste keuze om Epichrome te vervangen.

Ik heb wel een probleempje. Als ik op een koppeling in Google Docs klik, probeert de Coherence X-SSB die in een nieuw tabblad te openen voordat de Coherence Helper-extensie zich realiseert dat hij in plaats daarvan naar Brave moet gaan. Dat resulteert in een flits als een nieuw leeg tabblad wordt geopend en onmiddellijk weer wordt gesloten. Cosmetisch irritant, maar veel minder dan de manier waarop Epichrome alle koppelingen opende in zowel nieuwe tabbladen als Brave.

Coherence X4 heeft een proefversie waarmee je gratis drie SSB's kan maken. Als je meer nodig hebt, heb je een licentie van $ 29,99 nodig, of een Setapp-abonnement van $ 9,99 per maand.

Chromeless

Zoals de naam doet vermoeden, kan Chromeless SSB's maken van elke op Chromium gebaseerde webbrowser, zelfs meer dan Coherence X, en je kun er, net als met veel andere vergelijkbare programma's, apps met een eigen venster (standaard) en in een tab mee maken.

Met Chromeless kun je echter ook "standaard" op WebKit gebaseerde apps maken die in wezen Safari inkapselen en de maker claimt zelfs experimentele ondersteuning voor het maken van apps met tabbladen met de Firefox-engine. Dergelijke flexibiliteit kan belangrijk voor sommigen zijn, maar ik wil gewoon iets waarmee ik Grammarly kan gebruiken en Chromeless doet dat prima met de Brave-engine.

Hoewel je met Chromeless de basis-URL voor elke SSB kan bewerken, en zoals elke goede webbrowser bij het opstarten de geopende tabbladen heeft onthouden, leek er bij het opstarten altijd een nieuw Google Drive-tabblad voor mijn SSB te worden geopend, ook al was er al een geopend. Een kleine ergernis, die nog wordt versterkt door het feit dat je de naam of het pictogram van de SSB niet kan bewerken.

Omdat het zijn SSB's registreert als webbrowsers, kunnen zowel BrowserFairy als Choosy inkomende docs.google.com-URL's doorsturen naar de SSB. Dat was aanvankelijk een beetje lastig in te stellen, omdat Chromeless zijn apps standaard in ~/Applications/Chromeless in plaats van in de standaard map Programma's maakt. Dat blijkt voor Chromium-browsers standaard te zijn, maar ik was toch verrast. Het is ook een voorkeur, je kunt apps op elke locatie van je voorkeur laten installeren.

Chromeless installeert weliswaar de extensie Chromeless Helper, vermoedelijk om klikken op URL's af te handelen, maar die heeft geen instellingen en ik kon geen manier ontdekken om koppelingen in mijn standaard webbrowser te laten openen. Elke koppeling die ik in Chromeless aanklikte werd in Chromeless zelf geopend. Dat is een grote tegenslag.

Een pluspunt is dat Chromeless gratis en open source is, en dat hij ook beschikbaar is voor Windows en Linux voor wie SSB nodig op die platforms heeft. Het is ontwikkeld door het bedrijf dat ook achter het hieronder besproken programma WebCatalog zit.

Flotato

”You say Flotāto, I say Flotăto”
“Let's call the whole thing off”.

Hoe leuk ik de naam ook vind, Flotato is voor mij in bijna alle opzichten niet goed. Bij het opstarten toont het een venster vol icoontjes voor SSB's die je kan maken door op een knop “Get” te klikken. Zodra je de app hebt gemaakt, verschijnt hij in je map Programma's zoals elke andere app, en je kan ook op Openen klikken om hem vanuit Flotato te starten. Je kunt ook van elke URL een SSB maken.

Dat is allemaal prima, natuurlijk, maar de apps die Flotato maakt zijn werken met vensters in plaats van tabs. Hoewel ik een Google Docs-app kan maken en hem zelfs met mijn Google Drive-URL kan laten beginnen, neemt elk document dat je opent het hele venster in beslag. De enige manier om een ander document te openen is door “App > New Window” te kiezen en opnieuw door Google Drive te gaan. Flotato onthoudt ook niet de grootte van vensters, dus je moet van elk nieuw venster dat je maakt de grootte aanpassen.

Ik weet niet wat Flotato onder de motorkap gebruikt om zijn SSB's te creëren, maar ik vermoed dat het WebKit is, omdat er nergens ondersteuning voor Chrome-extensies wordt vermeld. Je kunt Flotato vragen de mobiele versie van een web-app te tonen, wat handig kan zijn voor lichtgewicht web-apps met een minimale interface en goed ontworpen mobiele versies, maar het is onzinnig voor Google Docs, dat juist grote vensters moet hebben.

Bovendien registreert Flotato de SSB's niet als webbrowser, dus BrowserFairy en Choosy kunnen geen docs.google.com-URL's naar een Flotato-SSB sturen. Standaard opent het klikken op een koppeling in een Google Doc binnen Flotato deze in een nieuw Flotato-venster maar je kunt erop shift-klikken om hem te openen in je standaard browser. Ten minste in theorie. Ongeveer de helft van de koppelingen die ik shift-klikte resulteerde in een foutmelding dat het programma niet kon worden geopend.

Je kunt gratis één Flotato-app tegelijk gebruiken. Je moet dan de ene afsluiten voordat je de andere opstart. Om net zoveel Flotato-apps tegelijk te gebruiken als je wilt, moet je $ 19 betalen voor Flotato Pro.

Fluid

Fluid bestaat al erg lang voor de Mac maar werkte bij mij nooit zo goed. Het instellen van een nieuwe SSB vereist een URL en een app-naam. Je kunt ook voor de nieuwe app een locatie op je Mac kiezen en dan de favicon van de site of een andere afbeelding gebruiken.

Maar daarna ging er van alles mis. Om te beginnen wilde Fluid het lettertype Proxima Nova dat we in Google Docs gebruiken niet weergeven en verving hij dit door een of ander geschreefd lettertype, wat gewoon raar is. Je kunt een gereedschapsbalk laten weergeven (waarmee je bovenin een adresbalk en knoppen krijgt) met een bladwijzer-balk en een tab-balk eronder. Misschien ligt het eraan dat Fluid niet is bijgewerkt voor het uiterlijk van Big Sur, maar ik vond de op elkaar liggende grijze balken bovenaan lelijk.

Problematischer was dat Fluid niet in staat was om Google Sheets te openen. Als ik dit probeerde, kreeg ik een Google Sheets-foutmelding over het vrijmaken van geheugen voor het programma, gevolgd door een Mac-foutmelding over JavaScript. Ik heb hier geen oplossing voor gevonden.

Fluid registreert zijn SSB's als browsers dus er was geen probleem in gebruik met BrowserFairy of Choosy met het doorverwijzen van docs.google.com-URL's naar mijn Fluid-SSB. Maar hoewel Fluid een Whitelist-instelling bevat waarmee je in theorie koppelingen waar je op klikt kunt laten openen in je standaard browser, was dit bij mij volkomen willekeurig. Zelfs dezelfde koppeling tweemaal snel achter elkaar aanklikken resulteerde erin dat de eerste klik de koppeling in Brave opende en de tweede klik in de SSB van Fluid. Fluid heeft wel een fijne functie: webbrowser-panelen links en rechts die ieder hun eigen webpagina's kunnen bevatten. Maar dan moet je de betreffende URL's wel in de whitelist zetten, natuurlijk.

Omdat Fluid WebKit gebruikt, werkt het net als Safari. Maar het ondersteunt voor zover ik weet geen Safari-extensies. Of Chrome-extensies, natuurlijk. Dit houdt in dat ik Grammarly er niet mee kan gebruiken. Over het algemeen is Fluid niet echt handig voor het gebruik met Google Docs.

Fluid is gratis en je kunt zoveel SSB's gebruiken als je wilt, maar voor $ 5 kan je Fluid-apps aan de macOS-menubalk vastmaken, Userscripts of Userstyles in je apps gebruiken (ik weet ook niet wat dat betekent) en volledige beeldweergave gebruiken.

Unite

Unite is gemaakt door BZG, dat ook achter Coherence X zit, en biedt een andere kijk op het SSB-concept. Het grote verschil tussen Coherence en Unite is dat Coherence X iedere Chromium-browser als engine kan gebruiken terwijl Unite WebKit 2 gebruikt, dezelfde engine als in Safari.

Het feit dat Unite WebKit gebruikt maakt het passender als Mac-programma, zorgt dat de apps veel kleiner kunnen zijn en maakt het mogelijk dat je web-apps in andere vormen van app-verpakkingen kunt stoppen. Het kan statusbalk-apps aanmaken die je in de menubalk kunt stoppen, apps verkleinen die proberen een telefoon-achtige ervaring of apps in tabs te genereren. Geen van deze speciale vormen van apps waren voor mij interessant, omdat ik ze vooral voor Google Docs gebruik waar ik gewoon SSB's in tabs wil zien.

Wat betreft binnenkomende koppelingen werkt Unite prima met BrowserFairy en Choosy. Bij uitgaande koppelingen lijdt het aan hetzelfde euvel als Coherence X: er flitst iets doordat een tab opent en sluit terwijl de koppeling geladen wordt in mijn standaard browser.

Helaas, Unite heeft voor mijn doeleinden twee grote nadelen. Ten eerste kan het programma, net als Fluid, geen Google Spreadsheet-documenten openen. Telkens wanneer ik het probeer, krijg ik een Google Spreadsheet-bericht dat er iets mis is gegaan, en een foutmelding dat het bestand niet kon worden geladen.

Ten tweede: het nadeel van het vertrouwen op WebKit is dat web-extensies zoals Grammarly niet ondersteund worden. Kortom, zelfs als Unite met Google Spreadsheets zou werken, zou ik het negatief beoordelen, omdat er geen ondersteuning voor Grammarly is.

De proefversie van Unite is gratis voor drie apps, en je kunt het kopen voor $ 24,99 of met een Setapp-abonnement van $ 9,99 per maand.

Wavebox

De meeste andere site-specifieke browseroplossingen die ik heb getest zijn vrij eenvoudig, waardoor je zelfstandige apps voor specifieke websites kunt maken. Wavebox is niet eenvoudig. Wavebox wil je één samenhangende werkruimte bieden voor al je internet-apps. Misschien vind je dit, net zoals ik, overweldigend.

Om te beginnen moet je een account aanmaken. Ik weet niet zeker waarom dit nodig is, misschien voor synchronisatie van werkruimten op verschillende apparaten. Vervolgens vraagt het programma naar je e-mailadres(sen), waarna Wavebox een werkruimte voor je maakt met de sites die overeenkomen met je e-maildomeinen.

Wavebox is gebaseerd op Chromium en ondersteunt dus Chrome-extensies. Het programma gaat zelfs zo ver dat het je tijdens de installatie helpt bij het installeren van enkele populaire extensies, waaronder Grammarly. Zodra je de configuratie-assistent hebt voltooit, beland je in een browserachtige omgeving met een navigatiekolom voor je apps. Je kunt ook extra apps of websites aan de navigatiekolom toevoegen.

Aanvankelijk leek het erop dat Wavebox ging werken zoals ik wilde. Mijn Google-werkruimte had een vast tabblad voor Google Drive, en dubbelklikken daarin op een Google-document opende het in een nieuw tabblad in hetzelfde venster. Als ik echter op een docs.google.com-koppeling in Slack klikte en op BrowserFairy of Choosy vertrouwde om deze in Wavebox te openen, werd deze altijd geopend in een nieuw Wavebox-venster. Daaropvolgende klikken op soortgelijke externe koppelingen werden ook als nieuwe tabbladen in dat venster geopend. Als gevolg hiervan kreeg ik altijd twee vensters, één met tabbladen voor documenten die zijn geopend vanuit Google Drive en een andere met tabbladen voor documenten die zijn geopend vanuit andere apps. Het was, net als al het andere in Wavebox, verwarrend. Ik heb geprobeerd Google Docs toe te voegen als app in de Google-werkruimte en als eigen werkruimte, maar dat maakte het alleen maar erger.

Ook omgaan met uitgaande koppelingen was teleurstellend. Wavebox biedt talloze opties om ze te verwerken, inclusief specifieke opties voor wat te doen als verschillende modificatietoetsen ingedrukt zijn. Ik slaagde er niet om het basisgedrag te krijgen dat ik wilde, namelijk dat alle koppelingen in mijn standaard internetbrowser zouden worden geopend. Wavebox erkent de complexiteit van deze situatie met een algemeen kennisbank-artikel en een andere lijst waarschuwingen over koppelingen die worden geopend in de standaard-browser.

Uiteindelijk heb ik Wavebox gefrustreerd opgegeven. Het probeert duidelijk een probleem op te lossen veel complexer is dan mijn simpele wens om Google Docs in te kapselen in een sitespecifieke browser. Het pakt dat probleem misschien wel goed aan, maar het deed niet wat ik wilde.

Zelfs het bedrijfsmodel van Wavebox is verwarrend. Er zijn prominente downloadknoppen op de thuispagina, maar geen informatie over prijzen in de bovenste navigatiebalk, wat suggereert dat het gratis is. In de onderste navigatiebalk is er echter een koppeling Pricing die onthult dat Wavebox Pro $ 12,95 per maand kost, dat je op elk moment kunt annuleren, $ 8,32 per maand indien jaarlijks gefactureerd, of $ 9,99 per maand gedurende zes maanden, zonder indicatie van hoe dat wordt gefactureerd (het bedrijf verduidelijkte de interface na publicatie). En ja, de opties worden in die verwarrende volgorde gepresenteerd. Of je kunt gewoon gratis Wavebox Basic (de eerste keer dat ik die term tegenkom) gebruiken. Ik kon geen overzicht vinden welke functies in Wavebox Basic zitten en welke exclusief zijn voor Wavebox Pro.

WebCatalog

WebCatalog is het bedrijf achter zowel Chromeless als de SSB-oplossing WebCatalog. Je zou daarom verwachten dat WebCatalog een verbeterde versie van Chromeless is, en op conceptueel niveau is dat waar. Aan dezelfde set internet-apps in de Discover-weergave voegt WebCatalog het idee van Spaces toe waarmee je gerelateerde internet-apps kunt samenbrengen, zoals de vele apps die Google biedt. Je kunt ook aangepaste ruimtes maken en met sneltoetsen schakelen tussen de interne apps. Spaces ondersteunen zelfs meerdere accounts, dus je kunt bijvoorbeeld een ruimte hebben die is aangemeld op verschillende Google-accounts.

Afgezien van enkele overeenkomsten in de gebruikersinterface, zijn Chromeless en WebCatalog echter behoorlijk verschillend. WebCatalog laat je geen internetbrowser kiezen en maakt in plaats daarvan zijn apps binnen een Electron-shell. Electron is een open-source framework van GitHub dat veel bedrijven gebruiken om desktopversies te maken van web-apps. Slack is bijvoorbeeld een Electron-app. Hoewel Electron leunt op de browser Chrome, kun je geen bladwijzers maken, tabbladen gebruiken of Chrome-extensies installeren.

Daarom werkt WebCatalog gewoon niet voor mij. Ik kon geen manier bedenken om Google Docs in een venster met tabbladen te laten werken, en dubbelklikken op documenten van Google Drive opende ze in afzonderlijke vensters. Ik zag ook geen manier om de extensie Grammarly te installeren. Positief is dat WebCatalog uitgaande URL's beter verwerkt, zodat je kunt specificeren welke in de SSB moeten worden geopend en welke naar de standaard internetbrowser moeten worden verzonden.

Je kunt WebCatalog gratis gebruiken, maar je bent beperkt tot tien geïnstalleerde apps en ruimtes, en je kunt slechts twee accounts per app of ruimte hebben. Na een eenmalige betaling van $ 40 onder de noemer Lifetime worden deze beperkingen opgeheven en wordt advertentie-blokkering toegevoegd, alsmede de mogelijkheid om apps te vergrendelen met wachtwoorden of Touch ID.

Elke oude webbrowser

Op een gegeven moment, terwijl ik schreef over hoeveel internet-browsers Chromeless ondersteunde, kwam ik op een idee. "Waarom niet gewoon een hele browser aan Google Docs wijden?" Ik hoef Microsoft Edge of Opera niet voor iets anders te gebruiken. Dit zou perfect zijn, met één knelpunt: klikken op uitgaande koppelingen moeten naar mijn standaard webbrowser leiden.

Zowel met BrowserFairy als met Choosy kan je regels maken die bepalen waarmee de koppelingen die je aanklikt worden geopend. In een snelle test met Slack werkte dit allemaal goed. Maar dat geldt niet voor koppelingen in webbrowsers. Alleen een extensie helpt uiteindelijk om een koppeling in de ene browser te laten openen in een andere browser.

Eigenlijk bieden BrowserFairy en Choosy vrijwel precies dezelfde browser-extensies. En beide bieden slechts twee functies: een knop in de menubalk waarmee je de huidige pagina opent in BrowserFairy resp. Choosy, en een optie BrowserFairy resp. Choosy in het contextuele menu als je op een koppeling control-klikt. Geen van beide opent standaard alle koppelingen.

Mogelijk is er nog een andere manier om wel te bepalen dat klikken op iedere koppeling (ook vanuit een webbrowser) steeds doorgestuurd worden naar een andere browser (zonder nog andere acties te hoeven uitvoeren.) Omdat Coherence X naar mijn smaak al alles doet wat ik wil, zie ik de noodzaak niet om nog verder te zoeken of verplicht te werken met een compromis op dit punt. Aan de andere kant: ik ben wel benieuwd of een van de lezers een oplossing vindt. Laat het mij dan vooral weten.

(Ontwikkelaar Jeff Johnson schreef op Twitter dat zijn extensie genaamd Stop the Madness ($&bnsp;9,99) wel koppelingen kan doorsturen, maar alleen in Safari).

@adamengst "Mogelijk is er nog een andere manier om wel te bepalen dat klikken op iedere koppeling (ook vanuit een webbrowser) steeds doorgestuurd worden naar een andere browser."

StopTheMadness!https://t.co/zdWQGE36tX

En ook Link Unshortener kan ingesteld worden als standaard webbrowser, en volgt daarbij STM-regels:https://t.co/XbPaGf6oc4

— Jeff Johnson (@lapcatsoftware) June 18, 2021

Vergelijking tussen BrowserFairy en Choosy

Ik heb al deze SSB's getest met zowel BrowserFairy als Choosy. Ik ging er daarbij van uit dat er een verschil tussen deze twee zou zijn, maar je zult gemerkt hebben dat ze volkomen vergelijkbaar werken. Alles dat werkte in de ene, deed dat ook in de andere.

Dat is nog geen garantie op succes. Ik ben ook bezig geweest met Bumpr, een aantrekkelijke app die koppelingen doorstuurt. Hij is geschreven door Scott Ostler en deels ontworpen door onze TidBITS-vriend Khoi Vinh. Over het geheel ben ik een grote fan van Bumpr ben, maar de app ondersteunt nog geen site-specifieke browsers. Een snelle zoektocht in de Mac App Store leverde nog een paar nieuwe programmaatjes op dit terrein op. Bijvoorbeeld, onder andere, Browser Ninja, OLW: Open Link With, OpenIn, en Redirector. Van deze kandidaten weet ik niet, of zij wel SSB's ondersteunen.

Met BrowserFairy moet je er wel expliciet voor zorgen dat het de standaard webbrowser is. Dat kun je eenvoudig doen als je het programma start, of in het voorkeurenpaneel General. Daarna moet je een regel toevoegen die zoekt naar docs.google.com in het adres van de koppeling en koppelingen die onder die regel vallen openen in je SSB. Het kost maar een paar minuten om een en ander in te stellen, zoals ik laat zien in de onderstaande schermafbeelding.

Choosy is iets ingewikkelder, maar wel flexibeler. Het eerste dat je hier moet doen is je webbrowsers toevoegen en sorteren in het Browsers-scherm, waarbij je je favoriete browser bovenaan zet.

Daarna dubbelklik je in het scherm Rules op de regel Default Behavior die gebruikt wordt als geen specifieke regel van toepassing is. Je kunt kiezen tussen je favoriete browser, de best werkende browser, een specifieke browser, of zelfs een groep van browsers (helemaal goed als je een webontwikkelaar bent die pagina's in verschillende browsers moet testen). Of je kunt Choosy je laten vragen welke browser geopend moet worden uit een voorgedefinieerde set, uit alle open browsers, of uit alle beschikbare browsers.

En dan heb je ook nog een regel nodig die docs.google.com-koppelingen afvangt en ze naar je SSB doorstuurt. Ook dat is eenvoudig: volg gewoon de schermafbeelding hieronder.

Beide opties werken naar behoren, daarom hier mijn advies:

• Als je niet meer dan drie regels nodig hebt, gebruik dan BrowserFairy. De gratis versie is dan meer dan voldoende. Als je meer dan drie regels nodig hebt, ben je bij BrowserFairy gebonden aan een abonnement van $ 0,99 per maand of $ 8,99 per jaar.
• Als je meer dan drie regels nodig hebt ben je echter beter af door Choosy te kopen, dat kost je eenmaal tien dollar via PayPal. Verder biedt Choosy een API waarmee je de software vanuit andere programma's kunt aanroepen, mocht je daar behoefte aan hebben.

Kies de Coherente weg

Alles overwegende ga ik voor een combinatie van Coherence X en BrowserFairy. Alleen Coherence X vervult al mijn eisen, en het cosmetische probleem bij het openen en sluiten van tabs tijdens het verwerken van uitgaande koppelingen is weliswaar storend, maar niet onoverkomelijk. Niet ieders eisen zijn echter gelijk, en als jij andere criteria wilt hanteren hoop ik dat het bovenstaande overzicht je voldoende inzicht geeft om de beste SSB voor jouw situatie te kiezen.