Verborgen functies in Efteling app, is dit wenselijk?

[min6]

Vraagje hè.
Ik zag dit op Reddit: https://www.reddit.com/r/...ents/1kgswqc/app_pincode/

In de Efteling app kom je, door een paar keer op het versienummer te drukken, bij een veld waar je een pincode in kunt vullen. Ongetwijfeld om developers extra rechten/ functies te geven.

Vraagje: hoe gebruikelijk/ wenselijk is het om dit op deze manier in te bouwen?

[Standeman]

Tja, ligt er maar net aan welke (extra) informatie wordt ontsloten wanneer je de juiste pin invoert. Daar valt nu weinig over te zeggen. Meest waarschijnlijk debug info.

Ik vind het als developer dat je het er uit moet slopen voordat je de app naar de playstore pushed. Extra code in je app geeft alleen maar de mogelijkheid tot extra bugs. Dat wil je niet.

[pistole]

Als het functionaliteit is die ook door een Efteling-medewerker gebruikt kan worden (bij voorbeeld in geval van een dispuut) dan lijkt het mij prima, maar je hoeft het niet weg te stoppen.

Ander voorbeeld: in mijn auto is er ook een bepaalde sequentie van handelingen die een 'verborgen menu' te voorschijn tovert. Kan gebruikt worden in de garage. Lijkt mij verder ook niets mis mee.

[Jazzy]

min6 schreef op donderdag 8 mei 2025 @ 13:13:
Vraagje: hoe gebruikelijk/ wenselijk is het om dit op deze manier in te bouwen?

Kun je wat specifieker zijn wat je punt van zorg is?

[-LA-]

Zelfs bij Android zelf kom je op deze manier bij extra debug settings, is niet heel bijzonder lijkt mij

[_eLMo_]

min6 schreef op donderdag 8 mei 2025 @ 13:13:
Vraagje hè.
Ik zag dit op Reddit: https://www.reddit.com/r/...ents/1kgswqc/app_pincode/

In de Efteling app kom je, door een paar keer op het versienummer te drukken, bij een veld waar je een pincode in kunt vullen. Ongetwijfeld om developers extra rechten/ functies te geven.

Vraagje: hoe gebruikelijk/ wenselijk is het om dit op deze manier in te bouwen?

Heel gebruikelijk en prima wenselijk. Bij een vorige app waar ik aan gewerkt had hebben we het concreter gemaakt door een menu beta-features toe te voegen, waar je een sleutel kon invoeren die je kreeg van support om bepaalde dingen te enablen. En developers hadden al die sleutels natuurlijk.

[kodak]

_eLMo_ schreef op donderdag 8 mei 2025 @ 13:27:
[...]
Heel gebruikelijk en prima wenselijk. Bij een vorige app waar ik aan gewerkt had hebben we het concreter gemaakt door een menu beta-features toe te voegen, waar je een sleutel kon invoeren die je kreeg van support om bepaalde dingen te enablen.

Het is duidelijk niet zomaar wenselijk. Want het is dan wel bij de ontwikkelaars en een aparte groep gebruikers bekend wat het doet, maar voor de andere gebruikers die dit wel of nirt tegen komen is volkomen onduidelijk waarom ontwikkelaars dit 'stiekem' in de app op hun smartphone of tablet bouwen, het legt ze ook niets uit en het stelt juist niet zomaar gerust (in tegendeel).

Security by obscurity en geheimzinnig doen zijn daarbij meestal geen behoorlijke keuzes als je dat op andermans systeem doet. Je kan er namelijk op rekenen dat gebruikers dit bij toeval ontdekken en er niet zomaar tevreden of gerust bij zijn, hoe eigenwijs sommige ontwikkelaars ook voor gebruikers willen invullen dat dit niet zal gebeuren en ze maar niets uitgelegd hoeft te worden.

Daarbij is het ook nogal krom om niet transparant naar je gebruikers te zijn dat je betafuncties in de app levert. Meestal is dat namelijk niet zomaar acceptabel, ook al zit het achter een 'veilige' pincode. Je gaat als ontwikkelaars dan voor gebruikers beslissen onder welke omstandigheden een app beta features mag hebben en dat een pincode maar veilig genoeg is, terwijl die beslissing juist ook aan de gebruikers hoort te zijn voor een app die op hun systeem is geïnstalleerd.

Als je een eigen app op je eigen systemen installeert om gebruikers er gebruik van te maken dan kan het nog redelijk zijn. Op je eigen systeem bepaal je immers je eigen regels over wat gebruikers wel of niet mogen doen. Maar als je een app aan een gebruiker aflevert door installatie op andermans systeem dan hoor je nmm gewoon heel duidelijk te zijn wat je wel en niet levert zodat de gebruikers zelf kunnen beslissen of dat wel of niet acceptabel is. Want het feit dat je als ontwikkelaars maar van mening bent wat er op andermans systeem een acceptabel risico moet zijn wil niet zeggen dat gebruikers het daarmee een (kunnen) zijn.

[ Voor 24% gewijzigd door kodak op 10-05-2025 21:59 ]

[Jazzy]

kodak schreef op zaterdag 10 mei 2025 @ 21:38:
Security by obscurity is daarbij meestal geen behoorlijke keuze. Je kan er namelijk op rekenen dat gebruikers dit bij toeval ontdekken, hoe eigenwijs sommige ontwikkelaars ook voor gebruikers willen denken dat dit niet zal gebeuren.

Zowel in het geval van de topicstarter als die waar je op reageert zijn de functies niet "verstopt" maar afgeschermd en is er een code of sleutel nodig om ze beschikbaar te maken. Daar is toch niets mis mee?

[jadjong]

Zolang de code niet 5171 is zal het wel goed komen.

[Leeghoofd21]

Het veld geeft geen goed of fout bij de verkeerde input in ieder geval. Dus het kan variëren tussen de 1 en de 1e99 karakters. Meestal zal hier ook wat development opties achter zitten maar ik zou zo niet kunnen bedenken wat die zijn in deze app.

[kodak]

Jazzy schreef op zaterdag 10 mei 2025 @ 21:45:
[...]
Zowel in het geval van de topicstarter als die waar je op reageert zijn de functies niet "verstopt" maar afgeschermd.

De TS geeft aan dat er een verborgen toegang in de app zit. Dat is security by obscurity. De reactie waar ik op reageer stelt dat dit prima wenselijk zou zijn.

Ik stel dat het om verschillende redenen niet zomaar wenselijk is. En hoewel iemand het daar niet mee eens kan zijn, het probleem is dat beta features al niet zomaar acceptabel zijn. Omdat ze lang niet alleen een te groot risico vormen als gebruikers er via een gui bij kunnen.

[Jazzy]

kodak schreef op zaterdag 10 mei 2025 @ 22:16:
[...]

De TS geeft aan dat er een verborgen toegang in de app zit. Dat is security by obscurity. De reactie waar ik op reageer stelt dat dit prima wenselijk zou zijn.

Ik stel dat het om verschillende redenen niet zomaar wenselijk is. En hoewel iemand het daar niet mee eens kan zijn, het probleem is dat beta features al niet zomaar acceptabel zijn. Omdat ze lang niet alleen een te groot risico vormen als gebruikers er via een gui bij kunnen.

Ze kunnen er helemaal niet bij via een GUI. Het enige wat 'verstopt' is is een functie waarin je een code moet ingeven om de features beschikbaar te maken. Je logica dat developers niet zouden mogen beslissen wie van hun gebruikers die features mogen gebruiken volg ik ook niet. Als het niet aan de developer is, aan wie wel?

[Onbekend]

kodak schreef op zaterdag 10 mei 2025 @ 22:16:
[...]

De TS geeft aan dat er een verborgen toegang in de app zit. Dat is security by obscurity. De reactie waar ik op reageer stelt dat dit prima wenselijk zou zijn.

Ik stel dat het om verschillende redenen niet zomaar wenselijk is. En hoewel iemand het daar niet mee eens kan zijn, het probleem is dat beta features al niet zomaar acceptabel zijn. Omdat ze lang niet alleen een te groot risico vormen als gebruikers er via een gui bij kunnen.

Als er wel een zichtbaar invoerveld had gestaan (i.p.v. verborgen) dan was het wel prima?
Het invullen van een pincode vergelijk ik gewoon met het invullen van een gebruikersnaam/wachtwoord die wat meer rechten geeft. Zolang er niet oneindig lang geprobeerd kan worden en de pincode niet uit maar 4 cijfers bestaat is er niets aan de hand.

[_eLMo_]

kodak schreef op zaterdag 10 mei 2025 @ 21:38:
[...]

Het is duidelijk niet zomaar wenselijk. Want het is dan wel bij de ontwikkelaars en een aparte groep gebruikers bekend wat het doet, maar voor de andere gebruikers die dit wel of nirt tegen komen is volkomen onduidelijk waarom ontwikkelaars dit 'stiekem' in de app op hun smartphone of tablet bouwen, het legt ze ook niets uit en het stelt juist niet zomaar gerust (in tegendeel).

Security by obscurity en geheimzinnig doen zijn daarbij meestal geen behoorlijke keuzes als je dat op andermans systeem doet. Je kan er namelijk op rekenen dat gebruikers dit bij toeval ontdekken en er niet zomaar tevreden of gerust bij zijn, hoe eigenwijs sommige ontwikkelaars ook voor gebruikers willen invullen dat dit niet zal gebeuren en ze maar niets uitgelegd hoeft te worden.

Daarbij is het ook nogal krom om niet transparant naar je gebruikers te zijn dat je betafuncties in de app levert. Meestal is dat namelijk niet zomaar acceptabel, ook al zit het achter een 'veilige' pincode. Je gaat als ontwikkelaars dan voor gebruikers beslissen onder welke omstandigheden een app beta features mag hebben en dat een pincode maar veilig genoeg is, terwijl die beslissing juist ook aan de gebruikers hoort te zijn voor een app die op hun systeem is geïnstalleerd.

Als je een eigen app op je eigen systemen installeert om gebruikers er gebruik van te maken dan kan het nog redelijk zijn. Op je eigen systeem bepaal je immers je eigen regels over wat gebruikers wel of niet mogen doen. Maar als je een app aan een gebruiker aflevert door installatie op andermans systeem dan hoor je nmm gewoon heel duidelijk te zijn wat je wel en niet levert zodat de gebruikers zelf kunnen beslissen of dat wel of niet acceptabel is. Want het feit dat je als ontwikkelaars maar van mening bent wat er op andermans systeem een acceptabel risico moet zijn wil niet zeggen dat gebruikers het daarmee een (kunnen) zijn.

Je trekt dit voor mijn gevoel te ver door. Een app ontwikkelaar bepaald sowieso wat er op jouw systeem geïnstalleerd word. Niemand leest changelogs die automatische updates.
Daarnaast introduceren deze beta features of developer insights helemaal geen extra attack surface, gezien deze op de backend zit.

Overigens is het in de app waar ik het over had duidelijk uitgelegd, met link naar help artikel.

Bij de app van de TS kan het duidelijker uitgelegd kunnen worden, maar er hebben altijd easter eggs en dergelijke in applicaties. Leuk!

[kodak]

_eLMo_ schreef op zondag 11 mei 2025 @ 08:54:
[...]
Een app ontwikkelaar bepaald sowieso wat er op jouw systeem geïnstalleerd word. Niemand leest changelogs die automatische updates.

De eigenaar van een systeem is verantwoordelijk voor wat daarop wel en niet acceptabel is. Daarom is er transparantie nodig en steeds meer vereist. Zonder transparantie vooraf valt er namelijk nauwelijks verantwoordelijkheid te nemen.

Dat niet iedere eigenaar alle transparantie aan teksten leest is hun verantwoordelijkheid. Het is geen argument om dus maar helemaal niet over belangrijke kenmerken te informeren. En al helemaal niet om dus maar belangrijke kenmerken opzettelijk te verbergen in de hoop dat de eigenaar ze niet zal vinden. Omdat het opzettelijk voorkomen dat een eigenaar goed geinformeerd keuzes kan maken niet snel redelijk is. Als ontwikkelaars ga je er namelijk niet over in welke gevallen de eigenaar keuzes wil of moet maken wat er op hun systeem staat. Anders hoor je namelijk duidelijk naar de eigenaar te zijn dat je daarover volledige eigen verantwoordelijkheid neemt. Maar dat lees is dit soort ontwikkelaars die opzettelijk belangrijke kenmerken van apps verbergen ook niet doen.

Daarnaast introduceren deze beta features of developer insights helemaal geen extra attack surface

Dat gaat hooguit op voor apps waar je zelf controle over de kwaliteit hebt. Maar die kwaliteit is er niet zomaar wanneer ontwikkelaars beta features inbouwen. En al helemaal niet als die ontwikkelaars opzettelijk doen alsof er alleen maar hoogwaardige code en features in de app geleverd worden.

Nmm zijn features die je als ontwikkelaars opzettelijk gaat verbergen en dan ook nog de gebruiker niet over gaat informeren kennelijk belangrijk. Als een app geen duidelijke game is waar je verborgen features moet zoeken dan informeer je de gebruikers over het bestaan van die features, of je neemt duidelijk volledige verantwoordelijkheid over alle risico's die de app geeft zolang het op iemands systeem staat. Iedere andere keuze lijkt namelijk alleen maar tot doel te hebben wel te willen dicteren wat een ander maar moet accepteren maar er geen duidelijke verantwoording in te willen als het voor een ander onacceptabel is of zelfs toch mis gaat.

Het belang van de ontwikkelaars staat niet voorop als een app op andermans systeem staat. Het belang van de ontwikkelaars is niet zomaar vergelijkbaar met de belangen van een ander. En aangezien er al jaren te veel ontwikkelaars zijn die het niet zo nauw nemen met de risico's voor gebruikers om er vooral zelf beter van te worden is het niet transparant zijn dat je beta code, beta features of debug features meelevert en dan ook vooraf daarover geen duidelijke verantwoording af legt nmm onverantwoord naar de gebruikers.

[ Voor 10% gewijzigd door kodak op 11-05-2025 11:56 ]

[_eLMo_]

kodak schreef op zondag 11 mei 2025 @ 11:38:
[...]
De eigenaar van een systeem is verantwoordelijk voor wat daarop wel en niet acceptabel is. Daarom is er transparantie nodig en steeds meer vereist. Zonder transparantie vooraf valt er namelijk nauwelijks verantwoordelijkheid te nemen.

Dat niet iedere eigenaar alle transparantie aan teksten leest is hun verantwoordelijkheid. Het is geen argument om dus maar helemaal niet over belangrijke kenmerken te informeren. En al helemaal niet om dus maar belangrijke kenmerken opzettelijk te verbergen in de hoop dat de eigenaar ze niet zal vinden. Omdat het opzettelijk voorkomen dat een eigenaar goed geinformeerd keuzes kan maken niet snel redelijk is. Als ontwikkelaars ga je er namelijk niet over in welke gevallen de eigenaar keuzes wil of moet maken wat er op hun systeem staat. Anders hoor je namelijk duidelijk naar de eigenaar te zijn dat je daarover volledige eigen verantwoordelijkheid neemt. Maar dat lees is dit soort ontwikkelaars die opzettelijk belangrijke kenmerken van apps verbergen ook niet doen.


[...]
Dat gaat hooguit op voor apps waar je zelf controle over de kwaliteit hebt. Maar die kwaliteit is er niet zomaar wanneer ontwikkelaars beta features inbouwen. En al helemaal niet als die ontwikkelaars opzettelijk doen alsof er alleen maar hoogwaardige code en features in de app geleverd worden.

Nmm zijn features die je als ontwikkelaars opzettelijk gaat verbergen en dan ook nog de gebruiker niet over gaat informeren kennelijk belangrijk. Als een app geen duidelijke game is waar je verborgen features moet zoeken dan informeer je de gebruikers over het bestaan van die features, of je neemt duidelijk volledige verantwoordelijkheid over alle risico's die de app geeft zolang het op iemands systeem staat. Iedere andere keuze lijkt namelijk alleen maar tot doel te hebben wel te willen dicteren wat een ander maar moet accepteren maar er geen duidelijke verantwoording in te willen als het voor een ander onacceptabel is of zelfs toch mis gaat.

Het belang van de ontwikkelaars staat niet voorop als een app op andermans systeem staat. Het belang van de ontwikkelaars is niet zomaar vergelijkbaar met de belangen van een ander. En aangezien er al jaren te veel ontwikkelaars zijn die het niet zo nauw nemen met de risico's voor gebruikers om er vooral zelf beter van te worden is het niet transparant zijn dat je beta code, beta features of debug features meelevert en dan ook vooraf daarover geen duidelijke verantwoording af legt nmm onverantwoord naar de gebruikers.

Je hebt duidelijk weinig ervaring met apps developen. In jouw utopie: ja je hebt helemaal gelijk.

In de werkelijkheid:
- niemand gaat uren design en werk stoppen in developer features oppoetsen
- niemand gaat beta features ongestuurt releasen
- eindgebruikers caren er niet om

Jouw bank app zit ook vol met “beta” features voordat de feature flag aangezet wordt (zelf ervaring mee als developer). Je overtrekt de zaken enorm.