Apple schrapt Sign In with Apple-verplichting en komt met nieuwe voorwaarden

Apple laat ontwikkelaars voortaan zelf kiezen of ze Sign in with Apple willen toevoegen aan hun apps, of niet. Deze inlogwijze werd tot voor kort opgelegd zodra ontwikkelaars gebruikmaakten van inlogopties van derden. Het Amerikaanse bedrijf stelt in ruil wel enkele voorwaarden.

Uit de vernieuwde richtlijnen blijkt dat ontwikkelaars die inlogopties van derde partijen of socialemediabedrijven gebruiken in hun app, vanaf nu een inlogoptie moeten aanbieden waarbij er aan minimale dataverzameling wordt gedaan. Deze optie moet de gebruikers ook de mogelijkheid bieden om hun e-mailadres af te schermen en ze mogen ook niet getrackt worden tijdens het gebruik van de app.

De nieuwe voorwaarden zijn niet altijd van toepassing. Ze vervallen bij apps van bedrijven die hun eigen manier van inloggen gebruiken en bij apps van educatieve en professionele organisaties die enkel educatieve en professionele accounts gebruiken. De voorwaarden zijn ook niet van toepassing bij apps met een identificatiesysteem dat ontwikkeld en geverifieerd is door een overheid of door bedrijven.

De inlogwijze Sign in with Apple is 2019 geïntroduceerd. De functionaliteit maakte onderdeel uit van iOS 13. Apple claimt dat er aan minimale dataverzameling wordt gedaan en dat gebruikers van Sign in with Apple niet getrackt worden bij het gebruik van de app.

Sign in with Apple

Reacties (75)

[gday]

Voor ontwikkelaars zal het wel een last zijn om deze optie toe te voegen maar ik heb er tot nu toe als gebruiker graag gebruik van gemaakt. Hopelijk zal het niet stilaan verdwijnen want hoe gaat gecontroleerd worden of er inderdaad minimaal aan dataverzameling gedaan wordt?

[Werelds]

Voor ontwikkelaars zal het wel een last zijn om deze optie toe te voegen

Vanuit de Apple ecosysteem kant niet echt, kost niet meer of minder moeite dan de overige opties.

Vanuit alle andere kanten? Ja. Hun JS SDK is troep en ze hebben uiteraard 0,0 SDK's voor de server-side implementaties. De manier waarop ze willen dat je ondertekent werkte toen ook niet met de meeste bestaande libraries voor JWT's, want het is Apple en die kijken niet naar wat de industrie al 10 jaar doet. En iedereen die hun documentatie ooit heeft moeten gebruiken kan je zeggen dat je daar niet zo 1-2-3 de benodigde informatie in kunt vinden, alles zit meerdere clicks diep. Toen ze het uitrolden was er dus veel werk aan de winkel en ze hadden het duidelijk nooit getest met enige ontwikkelaars buiten Apple vóór de uitrol.

Het hele Sign-In With Apple verhaal voelt, als ontwikkelaar, als iets waar iemand een prototype voor maakte en dat prototype is gewoon uitgerold. Het is ontzettend onbetrouwbaar en heeft allerlei haken en ogen. En er is op 5 jaar tijd niets aan veranderd.

Als gebruiker heerlijk en ik maak er zelf regelmatig gebruik van, maar als ontwikkelaar kan ik niet anders dan wederom vloeken, zoals zo vaak met Apple's ontwikkelaars-dingen

[JoannisO]

Dit is absoluut niet mijn ervaring, de implementatie is op het backend altijd straightforward geweest voor mij. Er is wel één caveat met SIWA, namelijk dat als gebruikers hun naam en/of email delen, krijg je deze maar een enkele keer.

[Werelds]

Maar wanneer heb je het voor het eerst geïmplementeerd?

Als dat pas 6+ maanden of nog later na juni 2019 is geweest, heb jij het voordeel dat anderen al libraries hebben gemaakt die jij waarschijnlijk gebruikt. Tot oktober van dat jaar waren ze ook niet OpenID-compliant, dus een standaard OpenID handler moest je al aanpassen. De meeste programmeertalen en libraries maken ook gebruik van OpenSSL, wat niet werkt zonder wat aanpassingen (OpenSSL produceert DER ASN.1 signatures).

Wij moesten er rap bij zijn (om allerlei redenen waar ik verder niet al te veel over mag zeggen ), dus ik had nogal wat hoofdpijn hiervan.

[Pwain]

Eventjes wel een rechtzetting hier. Want als ontwikkelaar heb ik hier geen enkele problemen mee net zoals @JoannisO hier ook vermeld.

Toen in juni 2019 Apple ‘Sign in with Apple’ demonstreerde was deze gebaseerd op openID Connect maar met een paar zaken toch wat anders zodat deze niet 100% conform de openID richtlijnen was.

MAAR toen iOS 13 gelanceerd werd voor het grote publiek had Apple al de nodige aanpassingen gerealiseerd zodat deze nu wel 100% conform is. Weet je nog die open letter brief van openID?

Neen…je kan niet zomaar kritiek leveren op producten die nog in beta zijn. Sign in with Apple is voor elke ontwikkelaar eenvoudig te implementeren.

[Reactie gewijzigd door Pwain op 22 juli 2024 18:55]

[Werelds]

Toen in juni 2019 Apple ‘Sign in with Apple’ demonstreerde was deze gebaseerd op openID Connect maar met een paar zaken toch wat anders zodat deze niet 100% conform de openID richtlijnen was.

MAAR toen iOS 13 gelanceerd werd voor het grote publiek had Apple al de nodige aanpassingen gerealiseerd zodat deze nu wel 100% conform is. Weet je nog die open letter brief van openID?

Dat zei ik ook, maar de aanpassingen met betrekking tot OIDC compliance kwamen pas twee weken ná de release van iOS 13

Neen…je kan niet zomaar kritiek leveren op producten die nog in beta zijn. Sign in with Apple is voor elke ontwikkelaar eenvoudig te implementeren.

Dat was het toen dus helemaal niet, want je had 0,0 voorbeeld code of libraries om op terug te vallen. En kritiek leveren op beta producten mag wel, dat is juist het punt van een beta. Het probleem was echter dat Apple het al meteen verplicht stelde, zonder dat er ook maar enige ondersteuning werd geleverd. Er zijn nog steeds geen officiële SDK's buiten de client-side JS SDK, of überhaupt iets van voorbeeldcode. Een waarschuwing over het feit dat OpenSSL in dit geval niet zonder meer gebruikt kan worden is nog steeds op z'n plaats.

Daarnaast is Apple nog steeds de enige OIDC provider waarbij je je eigen JWS (client secret) moet genereren (waarbij ze dan ook nog eens één van de weinigen zijn waar dat relatief snel verloopt), waar de gemiddelde ontwikkelaar tegen OpenSSL's DER "probleem" aan zal lopen als ze geen bestaande libraries gebruiken die dit af handelen. Je vind de oplossing nu heel snel via Google, maar toen uiteraard niet, want maar heel weinig mensen hoefden zélf ES256 te genereren

Dus nee, ik ben het niet met je eens dat SIWA even makkelijk is als andere OIDC providers. Bij alle anderen is het een kwestie van client ID (krijg je), secret (krijg je) en authorization code (krijg je, na redirect) naar een URL sturen en klaar. Wil je dan ook nog signatures verifiëren, haal je de JWK set op en doe je dat; wat gewoon met RS256 kan (verplicht in de OIDC spec) en dus ook via alle stdlib's kan. Zelf een JWS genereren doet 95% van de ontwikkelaars niet.

Edit: de JS SDK is overigens ook problematisch, omdat je óf een POST redirect af moet handelen (in plaats van GET zoals alle anderen), óf het via postMessage moet. En iets testen op localhost of een IP adres mag ook niet. Nogmaals: Apple maakte het gewoon niet makkelijk.

[Reactie gewijzigd door Werelds op 22 juli 2024 18:55]

[aikebah]

[...]

Dat zei ik ook, maar de aanpassingen met betrekking tot OIDC compliance kwamen pas twee weken ná de release van iOS 13


[...]

Daarnaast is Apple nog steeds de enige OIDC provider waarbij je je eigen JWS (client secret) moet genereren

...

en makkelijk is als andere OIDC providers. Bij alle anderen is het een kwestie van ..., secret (krijg je) en

Oftewel: bij alle andere is het client secret vanaf de start al gecompromitteerd en enkel Apple doet het veilig

[Werelds]

Huh? SIWA is even veilig of onveilig als de rest. De client secrets zijn doorgaans slechts één keer te bekijken, net als de key die je van Apple krijgt. In beide gevallen ben je de pineut als je die lekt, maakt echt geen donder uit. Dat je bij SIWA je key ID en team ID in de payload stopt maakt verder niet uit, want dat zijn geen beschermde gegevens. Team ID is gewoon uit een app te halen.

[Reactie gewijzigd door Werelds op 22 juli 2024 18:55]

[aikebah]

Het gaat erom dat een client-secret alleen een private secret is als je het zelf terplekke maakt. Ieder 'secret' dat gecommuniceert wordt is niet meer 'slechts bij één partij bekend', aangezien de verzender er ook kennis van heeft kunnen nemen.

Vervolgens moet je er maar op vertrouwen dat die zender-kant voldoende veilig geprogrammeerd is om het niet per ongeluk ergens toch nog even vast te houden en/of onbedoeld een bad apple in de organisatie heeft die key-material nog even elders vastlegt.

Zodra een ander je een sleutel geeft moet je het beschouwen als een shared secret ipv een private secret.

[Werelds]

Ja, en? Apple doet precies hetzelfde, maar maakt het omslachtiger in het gebruik. Op z'n best security through obscurity, omdat er een extra stap nodig is. Ze geven je een key die je moet gebruiken voor de JWS. Zij hebben die gegenereerd en je moet er net als bij alle anderen maar op vertrouwen dat dat veilig gebeurd is en niet opgeslagen is. De payload bestaat verder uit informatie die gewoon publiek mag zijn, team en key ID zijn geen van beide geheim.

Toegegeven, die extra stap vereist wat kennis van de JWT spec en hoe OpenSSL werkt, maar als je daar van op de hoogte bent is dit niet veiliger dan een vooraf gegenereerd secret dat eenmalig te downloaden is.

Die key kan overigens ook voor een onbeperkt aantal apps gebruikt worden

[aikebah]

Ik heb de details niet bekeken, maar reageerde op

waarbij je je eigen JWS (client secret) moet genereren

jij beweert nu effectief dat dat statement dus niet klopt?

ofwel je moet zelf iets genereren en als client-secret gebruiken (private deel van een pki sleutelpaar, en dan mag de server er dus niets van weten), ofwel een server voorziet je van een identificatie die je zo goed mogelijk geheim moet houden (shared secret)

[Werelds]

Ik heb de details niet bekeken, maar reageerde op
[...]
jij beweert nu effectief dat dat statement dus niet klopt?

Waar ik het over client secret heb, gaat dat over de context van OAuth2, waarbij dat dus enkel server-side gebruikt dient te worden maar niet onder jouw controle valt. Mijn excuses, ik dacht dat je het specifiek over OAuth2 had met je eerste comment, maar je doelde op de cryptografische kant.

Met OAuth2 heb je een client ID en een client "secret"; beide krijg je (doorgaans) van de provider. Het client ID is publieke data: dat is hoe je een verzoek tot authorisatie indient. Je stuurt de gebruiker dus naar https://site.com/oauth/authorize?client_id=123

Apple stuurt de gebruiker vervolgens terug naar je site waarbij jij een authorisatie code krijgt. Die code wissel je vervolgens uit in een request naar https://site.com/oauth/token, met als payload (onder andere) je client ID en je client "secret"; dit moet aan jouw kant uiteraard server-side gebeuren zodat je je secret niet lekt, maar je server is tegelijkertijd ook de client van de provider. Pas na dit uitwisselen krijg je iets van gebruikers gegevens, inclusief een token voor toekomstige communicatie met de provider uit naam van die gebruiker. Wat je daarmee kunt hangt helemaal af van de authorisatie; bij Apple is er nagenoeg niets te krijgen na de eerste request, bij bijvoorbeeld FB kun je om specifieke scopes vragen en behoudt je die toegang.

En dat is waar Apple verschilt van de rest. Waar Facebook, Google en dergelijke je gewoon meteen een secret geven dat je rechtstreeks in de payloads van jouw server naar hun server stop, krijg je bij Apple een key van hen, waarmee je vervolgens een JWS voor een zelf-gegenereerd JWT moet maken. Die JWT is wat je als client secret gebruikt in de oauth/token request. Maar als puntje bij paaltje komt maakt het niet uit dat Apple het omslachtiger maakt met een key voor een JWS/JWT paar, als die key lekt ben je even hard de pineut als met het platte secret dat FB en Google genereren. En die secrets kun je ook maar eenmalig downloaden, net als die key van Apple.

Het zijn dus inderdaad shared secrets, maar binnen OAuth2 context heten ze client secrets

[Reactie gewijzigd door Werelds op 22 juli 2024 18:55]

[Guru Evi]

Sign-in met Apple is gewoon OAuth2, natuurlijk ga je server-side geen JWT van Apple krijgen om het profiel in te kijken, het hele authenticatie gedeelte gebeurt tussen Apple en de cliënt, daarna krijg je enkel een token met de informatie die de gebruiker wilt delen (en bij Apple is een groot deel van die informatie geanonymizeerd), dat is juist de bedoeling van OAuth2.

Als je geen OAuth2 libraries kan integreren, of je haalt profielen op server-side (wat mogelijk is bij vb Facebook), heb je een groter probleem met privacy. OAuth was gebouwd met de bedoeling om anoniem (of tenminste pseudoniem) in te loggen en in principe zou je zelfs geen afspraken nodig hebben om vb. Sign-in met Google te doen, in principe kan het gewoon op basis van login domein naar de juiste server verstuurd worden (alhoewel dit op zichzelf ook problemen met zich meebrengt).

[Reactie gewijzigd door Guru Evi op 22 juli 2024 18:55]

[Werelds]

Waar had ik het in vredesnaam over gebruikersnaam en wachtwoord? Apple's implementatie was in eerste instantie niet OIDC compliant en OAuth libraries waren toentertijd geen van allen in staat het secret te genereren. En zelfs nu doen veel van die libraries dat niet, omdat het niet hun verantwoordelijkheid is; ze moeten secrets kunnen gebruiken, niet genereren.

[Guru Evi]

Je had het over JWT als authenticatie mechanisme, niet over OIDC.

OIDC is een extensie van OAuth2 en bepaalde libraries waren (en sommige applicaties nog steeds) niet compleet, dat wil niet zeggen dat het niet op de standaarden gebaseerd was, enkel dat de OAuth2 implementaties van andere providers dit niet hadden en daarvoor developers het niet nodig achten om dit toch te ontwikkelen. Maar als je vb. Keycloak opzet kun je dit wel ondersteunen.

De secret etc waar jij over spreekt is wel degelijk de verantwoordelijkheid van jouw applicatie indien de cliënt dit wilt gebruiken. Inderdaad, Facebook etc, genereren alles aan hun kant en geven jouw applicatie dan de mogelijkheid om direct te communiceren met het profiel zonder dat de gebruiker daar toestemming voor blijft geven, met Apple is dit expliciet opgezet om niet te kunnen.

Maar vb. OAuth2 met AzureAD (Entra) kan ook opgezet worden om dit zo te doen, vooral als je wettelijk niet kunt toelaten dat een applicatie gegevens van je werknemers zomaar bijhoudt/ophaalt (zowat iedereen in Europa valt hieronder) alhoewel, zoals je zelf zegt, bepaalde applicaties niet kunnen werken en veel administrators weten het verschil niet en zetten de boel maar aan omdat dingen zoals app integratie niet zouden werken (je geeft vb Zoom toelating in te loggen als een gebruiker om kalender status op te halen, wat je enkel zou mogen doen als je een overeenkomst met Zoom hebt)

[Reactie gewijzigd door Guru Evi op 22 juli 2024 18:55]

[Werelds]

OIDC is een extensie van OAuth2 en bepaalde libraries waren (en sommige applicaties nog steeds) niet compleet, dat wil niet zeggen dat het niet op de standaarden gebaseerd was

Ze noemden het OIDC compliant, maar was dat niet, juist omdat ze de standaarden niet goed gevolgd hadden. Dat hebben ze na release hersteld. Dat heeft verder niets met de JWT's zelf te maken.

OIDC is overigens geen extensie van OAuth2, maar meer een wrapper er omheen. OAuth2 draait om authorisatie, OIDC om authenticatie. Het authorisatie gedeelte van OIDC ís OAuth2

enkel dat de OAuth2 implementaties van andere providers dit niet hadden en daarvoor developers het niet nodig achten om dit toch te ontwikkelen. Maar als je vb. Keycloak opzet kun je dit wel ondersteunen.

Ik denk dat je niet begrijpt waar ik op doelde. Het probleem was (en is nog steeds) dat Apple geen enkele regel code bood om hun afwijkend gebruik van client secrets uit te leggen of te demonstreren. De manier waarop zij dat doen maakt dat je als consumer ineens iets moet doen dat normaal gesproken juist aan de provider kant van OAuth2 zit, namelijk een JWS genereren.

Dat ze geen zin hebben om SDK's voor allerlei programmeertalen te onderhouden is niet gek, maar ze hadden wel op z'n minst één referentie implementatie moeten bieden en die is er niet.

De standaarden van OAuth2 en OIDC hebben daar verder niets mee te maken, want hoe een client secret tot stand komt is daarbij niet vast gelegd. Maar het betekent wel dat er geen enkele OAuth2 client library was die dit kon doen; en de meeste doen dit nog steeds niet, omdat het simpelweg niet tot de verantwoordelijkheid van een client behoort.

De secret etc waar jij over spreekt is wel degelijk de verantwoordelijkheid van jouw applicatie indien de cliënt dit wilt gebruiken. Inderdaad, Facebook etc, genereren alles aan hun kant en geven jouw applicatie dan de mogelijkheid om direct te communiceren met het profiel zonder dat de gebruiker daar toestemming voor blijft geven, met Apple is dit expliciet opgezet om niet te kunnen.

Uh, dit is dus absoluut niet het geval

Het client secret is bedoeld om jouw verzoek tot gebruikers gegevens te verifiëren, maar daarvoor heb je wel de authorisatie van de gebruiker al nodig. Dat ligt niet anders. Wel is het inderdaad zo dat het token dat je van Apple krijgt daarna vrij nutteloos is, terwijl je bij andere providers meerdere malen gegevens op kunt vragen - maar dat staat los van het secret.

Sterker nog, ik heb een aantal OIDC implementaties in één van m'n backends zitten waar je net zoals bij Apple niets kunt met het token, behalve dan controleren of het nog geldig is.

[Reactie gewijzigd door Werelds op 22 juli 2024 18:55]

[bantoo]

Bij een oauth achtig login prompt kun je volgens mij exact zien wel permissies er gevraagd worden. Het lijkt mij dat een app daar op gekeurd gaat worden.

[pinqeh]

Ben sindskort overgestapt naar Android maar in de 5+ jaar dat ik iOS had gebruikt maakte ik ook volledig gebruik van de login feauture. Specifiek vanwege het verbergen van je emailadres voor apps waar ik eigenlijk nieteens een account voor wil hebben.

[Get!em]

Alternatief cross platform werkt via Firefox relay.

[Skywalker27]

Ontwikkelaars moeten niet zo miepen het enige is wat ze willen is afleveren en zo snel mogelijk Security en alles wat er bij komt kijken willen ze niet doen grrrrrr.

[Verwijderd]

Apple had als enige de optie om je email adres te verbergen. Ik vind dit altijd de beste optie.

[logix147]

Dat klopt niet helemaal, Apple maakt dan een relay/alias aan voor je e-mail en forward die dan netjes. Check je wachtwoorden en accounts instellingen maar. Anders kan je ook geen wachtwoord reset krijgen.

Ik gebruik gewoon per dienst een alias op mijn eigen domein.

[Donstil]

Dat klopt niet helemaal, Apple maakt dan een relay/alias aan voor je e-mail en forward die dan netjes. Check je wachtwoorden en accounts instellingen maar. Anders kan je ook geen wachtwoord reset krijgen.

Dat is toch precies wat het woord verbergen betekend?

[logix147]

Dat Apple de enige is die dat aanbiedt is niet zo. Je kan het zelf namelijk ook, met als bijkomend voordeel dat je ook vanuit dat e-mail adres kan reageren.

[Donstil]

Dat Apple de enige is die dat aanbiedt is niet zo. Je kan het zelf namelijk ook, met als bijkomend voordeel dat je ook vanuit dat e-mail adres kan reageren.

Uiteraard maar dat kwam pas later en vereist veel meer stappen.

De poster bedoelde gewoon dat hij via deze manier zijn e-mail adres verbergt bij het maken van een login en dat is inderdaad precies wat de functie doet.

[logix147]

Een alias bestaat al jaren en langer dan Apple en diensten zoals SimpleLogin maken het alleen makkelijker.

[Donstil]

Een alias bestaat al jaren en langer dan Apple en diensten zoals SimpleLogin maken het alleen makkelijker.

We hebben het hier over de Apple context uiteraard. Daarin bestond “sign in with Apple” (2019) eerder dan “hide my e-mail” (2021).

[Reactie gewijzigd door Donstil op 22 juli 2024 18:55]

[laptopleon]

Ik doe dit zelf al 20 jaar, maar het is naar mijn bescheiden mening wel degelijk iets anders – vooral een stuk omslachtiger – om het zelf te doen dan wanneer Apple of wie dan ook dit als geautomatiseerde dienst aanbiedt. Ik heb niet honderden mailboxen of aliassen aangemaakt maar gebruik gewoon een catch-all mailadres. Je moet uiteraard ook zelf bijhouden wie je welk adres geeft. Bij terugmailen ontstaat nog wel eens verwarring omdat ik niet bij elk mailtje het afzender-mail op maat instel.

Overigens moet ik zeggen dat al jaren de overgrote meerderheid van de bedrijven zich netjes aan de regels houdt qua spam. Het is maar een klein percentage mailadressen, meeste al van 10+ jaar geleden, waar de meeste spam op binnen komt. Tja en dat is dan heel eenvoudig /dev0 te sturen.

[Janbraam]

[...]Dat is toch precies wat het woord verbergen betekend?

Nee. https://www.reddit.com/r/...il_vs_icloud_email_alias/

Voor méér info: https://www.google.com/se...s+and+hide+e-mail+address

[Donstil]

[...]


Nee. https://www.reddit.com/r/...il_vs_icloud_email_alias/

Voor méér info: https://www.google.com/se...s+and+hide+e-mail+address

Ja ik ken de systemen maar dat was het punt toch niet?

[logix147]

HideMyEmail kan soms als je contact hebt met de dienst waarvoor je Apple login gebruikt schijnbaar per ongeluk je achterliggende e-mail meesturen. Dan is je e-mail niet meer “verborgen” - dat is het punt wat in die thread staat.

[Donstil]

HideMyEmail kan soms als je contact hebt met de dienst waarvoor je Apple login gebruikt schijnbaar per ongeluk je achterliggende e-mail meesturen. Dan is je e-mail niet meer “verborgen” - dat is het punt wat in die thread staat.

Aah oké dat wist ik niet, dat had een mooie aanvulling aan je originele post kunnen zijn.

[Janbraam]

leg eens uit...

[Donstil]

leg eens uit...

De poster bedoelde gewoon dat hij via deze manier zijn e-mail adres verbergt bij het maken van een login en dat is inderdaad precies wat de functie doet.

[iAR]

De Reddit post gaat over het zelf aanmaken van aliassen vs. hide my email.

De laatste zijn random adressen per dienst/site die je echte e-mail (of een eigen gemaakt alias) verbergen.

[Llopigat]

Nou het is nog beter als die app gewoon helemaal geen naam of email krijgt natuurlijk.

Als ze alleen een random identifier krijgen, weten ze wel dat hij het bent maar niet wie je bent, zelfs je naam niet.

[Verwijderd]

Ja dat snap ik, maar deze relay kan je dan ook weer uitschakelen zonder problemen, wat dus je email adres 100% verbergt

[logix147]

Een alias gooi je ook weg zonder probleem. Nadeel van de Apple manier is dat je geen contact met de dienst kan opnemen via dat mailadres. Dat kan soms voor issues zorgen met bepaalde diensten. Vanuit een eigen beheerd domein kan dat wel. Het is beter voor je privacy dan Apples methode. Die is makkelijk toegankelijk maar dat is ook alles. Protonmail en SimpleLogin bestaan niet voor niets.

[Verwijderd]

Dat weet je van te voren al, dan gebruik je op sites waar je wel email contact wilt een ander adres dan je belangrijke adres

[iAR]

Dit is dus precies wat verbergen betekend. Er wordt een alias aangemaakt, specifiek voor die site. De site krijgt alleen het alias en je e-mail is dus verborgen voor die site.
Krijg je spam? Dan sluit je dat alias af, en dan kan die site niet meer communiceren (ook niet met een met een wachtwoord reset, maar dat is ook niet nodig met sign in with Apple).

[jpfx]

Dit soort regels vindt ik vaak lastig te lezen. Minimaal in de zin van zo weinig mogelijk, of minimaal in de zin van tenminste. En wat ziet Apple als minimaal. Want zelf verzamelen ze uiteraard ook (minimaal in de zin van?).

[kftnl]

Biedt Apple de mogelijkheid om een Apple account te maken en hun apps zoals xcode, itunes, Apple TV en hun marktplaats te gebruiken zonder je email adres aan Apple te geven? Als ze dat niet doen is dit wel echt een heel cynische manier van laten zien dat ze vinden dat hun gebruikers hun bezit zijn.

[klonic]

Dat kan, maar dan krijg je wel gratis een [e-mail] address.

[kftnl]

Ha ok fair enough, ze bieden ook een eigen email service. Maar dat kan ook als je op 'login with Google' klikt dus ik ga er vanuit dat ze die dan accepteren als dat je enige mogelijkheid is.

[supersnathan94]

Ja. Je kunt een appleID aanmaken met niet gekoppelde gegevens. Zo heb ik een pseudoniem account gemaakt wat volledig niet te koppelen is met mijzelf.

[kftnl]

Dus zonder email adres?

[supersnathan94]

Ja. Gewoon icloud adres gekregen en daar log ik mee in. Net als dat je een gmail of hotmail adres aanmaakt zeg maar.

[kftnl]

Ok dus dan zijn Google en Microsoft ook goede inlogmethodes want daar kun je ook gewoon met paar kliks een email adres aanmaken? Als we zeggen alle partijen waarbij je een email adres kunt aanmaken zijn ok dan denk ik dat niemand hierover gaat klagen.

[supersnathan94]

Nou nee. Want sowieso google tracked alles wat je met dat account doet en dat is dus precies wat ze hier aangeven niet te willen promoten.

[kftnl]

Maar wat betreft die regel over email adressen is het wat jou betreft dan wel in orde dus? Dat je bij google gewoon een nieuw email adres kunt maken met een paar kliks?

[supersnathan94]

Ja, maar het punt is dus dat er een trackingvrije optie moet zijn en dat is "log in met Google" per definitie niet.

[Verwijderd]

Jammer, want nu kan ik gewoon sign in met apple doen ipv allemaal losse inlog gegevens die rond slingeren ookal heb je een wachtwoorden manager

[JoannisO]

Laat staan voor mensen zonder wachtwoord manager..

[rene_fb]

Waarom zou je überhaupt 'inlogopties van derde partijen of socialemediabedrijven' als gebruiker willen gebruiken?
Ja, op dat moment ist het makkelijk. Maar als je overstapt naar een Android mobiel, of je je Facebook-account de deur uit doet, werken al je logins niet meer.
Of begrijp ik het principe gewoon niet (goed)?

[Werelds]

Je hoeft geen wachtwoord voor elke site te onthouden; de Facebook login optie heb ik zelf ook nooit echt begrepen, maar de Google optie wel, daar velen een GMail account hebben die ze nooit weg zullen doen.

[Verwijderd]

Als je je account verwijderd moet je inderdaad zorgen dat je van alle websites ook een wachtwoord hebt om in te loggen.

Qua overstappen, het is natuurlijk niet zo dat als je overstapt op Android je Apple account opeens weg is, net zoals andersom. Je kunt dus nog wel inloggen, maar het is natuurlijk wel een mooie manier om je in het ecosysteem te houden.

[klonic]

Omdat elke keer dat ik mijn e-mail adres achter laat bij een bedrijf, ik de kans loop dat dit address gejat of doorverkocht wordt. Apple biedt de optie om een bullshitaddress op te geven en de mail door te sturen.

Zodra je onzin mail krijgt gaat dat address uit de lucht en gebruik je voor die specifieke dienst gewoon een nieuwe. Daarnaast weet je ook welk bedrijf onvoorzichtig is met je gegevens.

Als je dat allemaal zelf moet doen heb je een enorme administratie ervoor nodig.

[Blokker_1999]

En als je Apple's alternatief gebruikt heb je hetzelfde probleem de dag dat je uit Apple's ecosysteem stapt. Ik zie dus niet echt wat het verschil is.

[svenk91]

Belangrijke accounts manage ik zelf, maar er zijn genoeg accounts waarbij het weinig uitmaakt als ik die verlies. Van die accounts om een keertje een bestelling te doen of dat je dan een bepaald aantal gratis artikelen mag lezen.

[Frame164]

Dat inderdaad. Voor incidentele bestellingen gebruik ik eigenlijk altijs PayPal. Dan hoef je verder niets in te vullen.

[panterarosso]

Je zou juist zeggen dat als een app 3party gebruikt voor zowel Android als iOS de overstap veel makkelijker is. Nu moet je voor elke iOS app bij overstappen maar zien

[xFeverr]

Ik zit nu op een project en daar willen we best Sign In with Apple aanbieden voor de verschillende webapps zodat gebruikers daarmee kunnen inloggen als ze dat graag willen. Maar ook dat vereist dus een developer account a 99 piek per jaar. Terwijl dat voor de andere inlogmiddelen niet hoeft. Dat werpt wederom een drempel op als je niet van plan bent om een app in de app store uit te brengen.

Sign in with Apple kan dus veel groter worden dan het nu al is, want we zijn niet de enige die daar tegenaan lopen.

[SRI]

Ja als je geen geld verdient aan data collectie moet je ergens anders geld aan verdienen hè. Die 99 euro is misschien stom naar het weerhoudt partijen met slechte intenties vaak al van pogingen tot misbruik.

[Sjakelien]

Ik lees dit artikel als:
Apple creëert dusdanig lastige voorwaarden, dat Sign In with Apple eigenlijk als enige optie overblijft.
Iedereen blij: de gebruikers (zie de andere commentaren), de wetgever (want Apple luistert), en Apple, omdat ze eigenlijk niet echt iets hoeven te doen, behalve dan af en toe met de vinger te zwaaien bij het app-acceptatieproces.

[JoannisO]

De eisen zijn zeker hoog voor 3rd party systemen, maar dit is dan ook van toepassing indien het niet een authenticatie systeem van jouw eigen bedrijf is. Ik vind de eis best redelijk, want het pushed de industrie naar betere standaarden (iig voor Apple's gebruikers). Public-key cryptography is hetgene wat hier het beste aan voldoet, en naar mijn idee is dat toch geen recente hippe technologie meer

[ArremeR]

Dat is wat ze met het repair programma doen en nu ook met het zogenaamd toelaten van alternatieve app-stores. Kortom anti-consumer en malicious compliance.

[supersnathan94]

Van wat ik nu kan zien zijn de eisen die ze stellen juist heel erg pro consument. Geen tracking dmv login en eisen mbt registratie/auditing van 3rd party implementaties. Iets als DigID komt daar met gemak doorheen (want Logius is onderdeel van overheid)

Valt ook prima in het tracking opt-in straatje van de GDPR in europa.

[ShadLink]

Nou nee, je moet of het "Sign in with Apple" gebruiken of een systeem wat vergelijkbare bescherming biedt. Maw. extra bescherming voor de gebruiker. Ik kan dat alleen maar aanmoedigen!

[Jan Onderwater]

Ik vraag me af, of apple het voor elkaar kan krijgen dat, op verzoek van een App ontwikkelaar, alleen Apps die in de officiële Webshop worden verkocht ook daadwerkelijk lopen. Dus dat Apps die een roofkopie zijn uit een Chinese of Russische shop niet lopen op een Mac of iPhone.
Ik voorzie namelijk een enorme toename in roofkopijen als gevolg van deze EU verplichting.

[DigitalExorcist]

Mag hopen dat de functie wel veel toegevoegd blijft worden door ontwikkelaars. Het is ideaal wat mij betreft.