Zelf rabobankieren app maken

[Keiichi]

Ik zat laatst te denken, de nieuwe app van de rabobank is best wel langzaam en ongebruiksvriendelijk. Maar het is wel iets wat tegen een server aanpraat.
Omdat we uiteraard zelf ook gewoon apps voor andriod/iphone kunnen maken, zat ik te denken: "Waarom maak ik m'n eigen rabobank app niet?"

Ik zal vast niet de eerste met het idee zijn. Zou het mogelijk zijn om dit te doen, zij het met reverse engineering hoe de huidige app naar de buitenwereld praat?

Omdat de beveiliging meestal wel goed in elkaar zit, zou het zomaar kunnen dat het links en rechtsom moeilijk en/of onmogelijk gemaakt wordt.

Zou het in de eerste plaats uitvoerbaar zijn?

_{Ik kan me voorstellen dat dit als fraudegevoelig beschouwd wordt, lijkt me vrij terecht. Maar het is ook wel een technische uitdaging opzich. Ik denk als je met de nieuw app gewerkt heb, dat je wel het gevoel kan delen iets voor jezelf te maken}

[stfn345]

Zowel de client als server valideren elkaar: de client chcked of hij met een echte server praat en de server valideert of het een valide client is. Dit wordt allemaal,goed afgedekt middls cryptografie.
Nee, het is dus niet mogelijk

[Verwijderd]

als je de random reader wil gebruiken voor het inloggen en het overboeken dan is eea wel te maken.

[johnkeates]

Ik denk dat je heel snel een boze brief van de bank krijgt, en als je niet stopt een advocaat aan de deur...

Een bank app is natuurlijk zo gebouwd dat je het verkeer niet kan tappen, debuggers gedetecteerd worden en bij modificatie niet start.

Op z'n best zou je de webinterface van de Rabobank website kunnen scripten/automatiseren, en de content en I/O scrapen en simuleren, maar of dat snel is moet nog maar blijken.

[Hydra]

Ik werk zelf op dit moment als back-end dev bij een grote bank aan een mobiele app: dit kun je wel vergeten. De client en server praten via een custom encrypted protocol en het implementeren daarvan gaat je niet lukken aangezien de bank je die informatie niet gaat geven. Mocht het je lukken dan gaat je implementatie bij iedere grote update breken en gaat het je weer net zo veel tijd kosten uit te vogelen wat er gewijzigd is.

[Keiichi]

Is er een rede voor een custom encrypted protocol? Er zijn enkele industriestandaarden die volgens mij ook 'niet kraakbaar' zijn. Als je met een protocol komt dat alleen binnen je eigen organisatie gebruikt wordt, dan is de kans dat er toch een vulnerability gevonden wordt, maar dan juist door overwegend kwaadwillende, groter? (Ik bedoel dit in de zin dat encryptie standaarden die iedereen in kan zien, kan valideren, beproeven en op voorhand als advisories geven waar gebreken liggen)

[Osiris]

Hydra schreef op dinsdag 17 november 2015 @ 08:55:
Ik werk zelf op dit moment als back-end dev bij een grote bank aan een mobiele app: dit kun je wel vergeten. De client en server praten via een custom encrypted protocol en het implementeren daarvan gaat je niet lukken aangezien de bank je die informatie niet gaat geven.

Oej, ik mag toch hopen van niet..

999 van de 1000 keer betekent "custom" namelijk "zo lek als een mandje, zolang je maar goed genoeg zoekt". Een vorm van security by obscurity, maar dan door incompetentie danwel het wiel nogmaals proberen uit te vinden (maar dan verkeerd) i.p.v. je aan gevalideerde standaarden te houden

[Cloud]

Mogelijk bedoelt hij een 'custom protocol' dat tevens encrypted is, wat inderdaad wat logischer klinkt dan custom encryptie

[Osiris]

Ah, dat zou fijn zijn idd

[DexterDee]

Het kan natuurlijk ook "custom" zijn in de zin dat ze standaard TLS gebruiken, maar met libraries die (met opzet) nét iets andere headers sturen waardoor "normale" libraries geen verbinding kunnen maken.

Het zelf maken van een cryptografie protocol is inderdaad in zo goed als alle gevallen geen goed plan. Ik kan me ook niet indenken dat een grote bank in zo'n valkuil trapt.

[NovapaX]

In het geval van de nieuwe rabo-app lijkt het meer op een veredelde webbrowser, dus het gros zal wel https zijn. Die rabo-app praat dan, zo lijkt het, met een server uit 1997 waarvan de harde schijf het aan het begeven is....

[Hydra]

Osiris schreef op dinsdag 17 november 2015 @ 09:01:
Oej, ik mag toch hopen van niet..

999 van de 1000 keer betekent "custom" namelijk "zo lek als een mandje, zolang je maar goed genoeg zoekt". Een vorm van security by obscurity, maar dan door incompetentie danwel het wiel nogmaals proberen uit te vinden (maar dan verkeerd) i.p.v. je aan gevalideerde standaarden te houden

Je begrijpt me verkeerd. De encryptie is gewoon industry-standard. Er zijn alleen meerdere lagen actief die je allemaal moet begrijpen EN waarvan je de keys moet hebben om er kaas van te maken.

P.s. ik vind het bijzonder on-chique dat een mod me aan de hand van mijn e-mailadres dat niet getoond wordt in mijn profiel opgezocht heeft op LinkedIn.

NovapaX schreef op dinsdag 17 november 2015 @ 09:21:
In het geval van de nieuwe rabo-app lijkt het meer op een veredelde webbrowser, dus het gros zal wel https zijn. Die rabo-app praat dan, zo lijkt het, met een server uit 1997 waarvan de harde schijf het aan het begeven is....

Je onderschat de complexiteit van een mobiele bank back-end.

[ Voor 20% gewijzigd door Hydra op 17-11-2015 09:22 ]

[RayNbow]

De Rabobank gebruikt gewoon een niet-gedocumenteerde API over https voor de mobiele app. Zo lang je maar niets verdacht doet kun je zelf deze aanroepen uitvoeren.

(Als je wel verdachte transacties doet, dan krijg je een belletje van de bank en wordt je rekening geblokkeerd.)

[Osiris]

Hydra schreef op dinsdag 17 november 2015 @ 09:21:
[...]

Je begrijpt me verkeerd. De encryptie is gewoon industry-standard. Er zijn alleen meerdere lagen actief die je allemaal moet begrijpen EN waarvan je de keys moet hebben om er kaas van te maken.

Ah ja, precies wat Cloud dus al zei. Niet zoals ik interpreteerde Snap 'em!

[NovapaX]

Hydra schreef op dinsdag 17 november 2015 @ 09:21:
[...]


Je begrijpt me verkeerd. De encryptie is gewoon industry-standard. Er zijn alleen meerdere lagen actief die je allemaal moet begrijpen EN waarvan je de keys moet hebben om er kaas van te maken.

P.s. ik vind het bijzonder on-chique dat een mod me aan de hand van mijn e-mailadres dat niet getoond wordt in mijn profiel opgezocht heeft op LinkedIn.


[...]


Je onderschat de complexiteit van een mobiele bank back-end.

Dat is niet helemaal waar. Ik begrijp dat de back-end complex is. Ik heb alleen problemen met de gekozen oplossingen. Er worden zware HTML pagina's en veel te veel content van de server gehaald.
De oude app was snel, en werkte veel beter, maar zag er niet zo mooi uit.
De nieuwe app is wel mooi, maar teveel server-side. Zelfs het toegangscode toetsenbord is volgens mij html van de server af. Als ik te snel de code invoer dan worden de toetsen geselecteerd (als in tekst-selectie om te kopiëren)

Natuurlijk is het geen server uit de prehistorie, maar zo voelt het wel.

[ThinkPad]

Ik denk dat je binnen de kortste keren een dreigbrief van je bank krijgt als je app publiekelijk beschikbaar komt. Kijk hier maar naar: nieuws: Rechter dwingt huishoudboekje te stoppen met importeren ING-transacties

[slaay]

Los van de techniek, staat de Rabobank het toe om te 'bankieren' buiten hun eigen website en app?
Dus wat zeggen de algemene voorwaarden hier over? Als dat al niet mag, dan weet je voldoende..

[SinergyX]

johnkeates schreef op maandag 16 november 2015 @ 20:34:
Ik denk dat je heel snel een boze brief van de bank krijgt, en als je niet stopt een advocaat aan de deur...

Een bank app is natuurlijk zo gebouwd dat je het verkeer niet kan tappen, debuggers gedetecteerd worden en bij modificatie niet start.

Op z'n best zou je de webinterface van de Rabobank website kunnen scripten/automatiseren, en de content en I/O scrapen en simuleren, maar of dat snel is moet nog maar blijken.

Een bank app is ook zo gebouwd dat het gebruiksvriendelijk en handig is voor de gebruiker, dat is gezien de reviews ook geen succes van de Rabo. Het mag natuurlijk niet van de Rabobank, maar gezien de huidige staat van de app, staan er tientallen app-bouwers te springen om iets zelf te mogen maken.

[Hydra]

NovapaX schreef op dinsdag 17 november 2015 @ 09:29:
Dat is niet helemaal waar. Ik begrijp dat de back-end complex is. Ik heb alleen problemen met de gekozen oplossingen. Er worden zware HTML pagina's en veel te veel content van de server gehaald.
De oude app was snel, en werkte veel beter, maar zag er niet zo mooi uit.
De nieuwe app is wel mooi, maar teveel server-side. Zelfs het toegangscode toetsenbord is volgens mij html van de server af. Als ik te snel de code invoer dan worden de toetsen geselecteerd (als in tekst-selectie om te kopiëren)

Natuurlijk is het geen server uit de prehistorie, maar zo voelt het wel.

De rabobank app wordt hier ook beschouwd als een goed voorbeeld van waarom je gewoon native apps wil maken. De rabo loopt gewoon achter.

[NovapaX]

Eens!
Hoewel ik wel geloof in een bepaalde vorm van hybride apps, maar dan moet je daarin wel de juiste keuzes maken, en zorgen dat de backend super-responsive is. (<100ms round-trip.... heat up those caches! Maar dat gaat op mobiel al snel niet lukken, alleen met een goede 4G verbinding nog wel.)

[ Voor 17% gewijzigd door NovapaX op 17-11-2015 10:03 ]

[Tom Paris]

Hydra schreef op dinsdag 17 november 2015 @ 09:21:
[...]
P.s. ik vind het bijzonder on-chique dat een mod me aan de hand van mijn e-mailadres dat niet getoond wordt in mijn profiel opgezocht heeft op LinkedIn.
[...]

Dit is off-topic voor deze discussie, maar dit is inderdaad erg onprofessioneel. Ik raad je aan een topic te openen in Lieve Adjes.

[Hydra]

NovapaX schreef op dinsdag 17 november 2015 @ 10:01:
Eens!
Hoewel ik wel geloof in een bepaalde vorm van hybride apps, maar dan moet je daarin wel de juiste keuzes maken, en zorgen dat de backend super-responsive is. (<100ms round-trip.... heat up those caches! Maar dat gaat op mobiel al snel niet lukken, alleen met een goede 4G verbinding nog wel.)

Nogmaals: je onderschat de complexiteit van een back-end. Over het algemeen is het serveren van statische content het probleem niet: het zijn vaak de (complexe en antieke) achterlanden die lang op zich laten wachten. Er zitten vaak nog gewoon COBOL systemen achter die gewoon traag zijn.

Tom Paris schreef op dinsdag 17 november 2015 @ 10:04:
Dit is off-topic voor deze discussie, maar dit is inderdaad erg onprofessioneel. Ik raad je aan een topic te openen in Lieve Adjes.

Men is op de hoogte.

[ Voor 16% gewijzigd door Hydra op 17-11-2015 10:10 ]

[DexterDee]

Hydra schreef op dinsdag 17 november 2015 @ 09:58:
De rabobank app wordt hier ook beschouwd als een goed voorbeeld van waarom je gewoon native apps wil maken. De rabo loopt gewoon achter.

Dat is ook een (deels) achterhaalde mening. Ja, hele lappen HTML ophalen van een remote server en renderen in je app is not done. Maar diezelfde HTML kan ook lokaal in je app staan en dan is het snel genoeg. Apps gemaakt in http://ionicframework.com/ bijvoorbeeld benaderen wel enigszins het native gevoel.

Blijf je wel met het probleem zitten dat HTML container apps wat makkelijker te reverse engineeren zijn. Maar dat heeft niet zoveel met de usability discussie van de Rabobank app te maken.

[Keiichi]

Hydra schreef op dinsdag 17 november 2015 @ 10:09:
[...]


Nogmaals: je onderschat de complexiteit van een back-end. Over het algemeen is het serveren van statische content het probleem niet: het zijn vaak de (complexe en antieke) achterlanden die lang op zich laten wachten. Er zitten vaak nog gewoon COBOL systemen achter die gewoon traag zijn.

De vorige rabobankieren app was wel gewoon goed, ik denk niet dat het aan de backend ligt.

Even terug naar het technische aspect, het zal wel mogelijk zijn, maar dan zou het flink wat kennis en kunde en moeite kosten om eigenlijk de huidige 'app' te reverse engineeren en eigen app zich goed voor te laten doen all 'originele' app.
En daarbij het risico tijdens ontwikkeling dat de bank het als verdachte activiteit beschouwd en dat je met blokkades (firewalls) en advocaten te maken krijgt of een keer van je bed gelicht wordt.

[NovapaX]

Hydra schreef op dinsdag 17 november 2015 @ 10:09:
[...]


Nogmaals: je onderschat de complexiteit van een back-end. Over het algemeen is het serveren van statische content het probleem niet: het zijn vaak de (complexe en antieke) achterlanden die lang op zich laten wachten. Er zitten vaak nog gewoon COBOL systemen achter die gewoon traag zijn.


[...]


Men is op de hoogte.

Nogmaals, die onderschat ik niet. Daarom heb ik het ook over caches. Je kunt voor bepaalde zaken prima een laag voor je antieke backend zetten die delen van de informatie cached bijvoorbeeld. Uiteraard wil je echter up-to-date (bijv. saldo-informatie) informatie gewoon wel uit die back-end halen en zul je daar voor de gebruiker een fatsoenlijke 'laad-ervaring' voor moeten maken. Maar veel andere zaken kun je prima binnen enkele milliseconden weer op de lijn hebben richting de gebruiker (de hele lay-out, inlogschermen, dynamische menustructuren etcetera)

[incaz]

Hydra schreef op dinsdag 17 november 2015 @ 10:09:
Nogmaals: je onderschat de complexiteit van een back-end.

Als de backend complex is, krijg je dat met een native app natuurlijk niet rechtgetrokken. Uiteindelijk heeft de native app exact dezelfde actuele data nodig van die backend.

Ook ik zie niet waarom de problemen van de rabo-app vooral geschoven worden op het webapp-vs-native, terwijl het volgens mij gewoon gaat om slecht ontworpen vs goed ontworpen.

(Het enige wat volgens mij lastig is, is dat je bij webapps geen volledige controle hebt over wat er gecachet wordt, omdat er ook weer zut uitgegooid wordt als de cache te groot wordt. Terwijl je de resources bij native apps gewoon meecompilet, en ze dus gegarandeerd blijven staan. Brengt me bij nog een punt: de cache wil nog wel eens corrupted raken en tot bijzondere gevolgen leiden. Ik weet niet in hoeverre webapps eea anders afhandelen dan de browser bij gewone sites.)

[Hydra]

NovapaX schreef op dinsdag 17 november 2015 @ 10:17:
Nogmaals, die onderschat ik niet. Daarom heb ik het ook over caches. Je kunt voor bepaalde zaken prima een laag voor je antieke backend zetten die delen van de informatie cached bijvoorbeeld. Uiteraard wil je echter up-to-date (bijv. saldo-informatie) informatie gewoon wel uit die back-end halen

En laat dat nu dus net het probleem zijn. Saldo informatie komt niet uit 1 systeem.

Keiichi schreef op dinsdag 17 november 2015 @ 10:16:
De vorige rabobankieren app was wel gewoon goed, ik denk niet dat het aan de backend ligt.

Het is een combinatie van factoren vermoed ik. Het is een nieuwe app met veel kinderziekten waar ook in de UX een aantal flinke fouten gemaakt zijn. Koppel dat met een problematische back-end waar de nieuwe app nog niet handig mee om gaat (de oude app cachte waarschijnlijk meer aan de client kant) en je zit met de problemen waar ze nu mee zitten.

Waar het mij vooral om gaat is dat mensen hier vaak dingen roepen zonder die systemen te kennen. Ik ken het Rabo systeem zelf niet (ik kan het een collega eens vragen) maar ik weet wel hoe complex die imgevingen zijn en vaak is het een combinatie van factoren en niet simpelweg een kwestie van "even" en cache toevoegen.

[ Voor 47% gewijzigd door Hydra op 17-11-2015 10:30 ]

[NovapaX]

Dat geeft toch niet, maar zorg dan dat de rest van je hybride app wel responsieve is en geef aan de gebruiker een hint dat de saldo-informatie zo op het scherm zal verschijnen. Dat bedoel ik dus, als je iets niet op tijd kan weergeven, zorg dan voor een goede 'laad-ervaring'

Overigens, de saldo-informatie komt niet uit 1 systeem, maar wordt blijkbaar wel door 1 systeem samengevoegd tot de juiste informatie, anders kan de bankieren app dat niet weergeven. Volgens mij moet het prima mogelijk zijn dat systeem een bepaalde vorm van caching te laten verrichten.

Maar in het geval van de rabo-app gaat het niet eens om de saldo informatie, maar alle bloat eromheen.

[ Voor 8% gewijzigd door NovapaX op 17-11-2015 10:34 ]

[Hydra]

NovapaX schreef op dinsdag 17 november 2015 @ 10:32:
Overigens, de saldo-informatie komt niet uit 1 systeem, maar wordt blijkbaar wel door 1 systeem samengevoegd tot de juiste informatie, anders kan de bankieren app dat niet weergeven. Volgens mij moet het prima mogelijk zijn dat systeem een bepaalde vorm van caching te laten verrichten.

En wat schiet je daar mee op? Een klant haalt over het algemeen maar 1 keer z'n saldo informatie op bijvoorbeeld. Caching heeft alleen zin als je vaak dezelfde informatie ophaalt. Dat soort zaken worden over het algemeen al gecached. Het probleem is vaak dat je bepaalde zaken gewoon niet kunt cachen. Als jij saldo informatie op wil halen moet eerst gecheckt worden of een bepaalde rekening uberhaupt van jou is: deze call kan en mag niet gecached worden. En zo zijn er nog vaak een hele zwik aan dergelijke checks die allemaal andere systemen raken.

[Helixes]

Dit is al eens gedaan, in 2011. Blauwe Leenw was een iPhone app die aan de achterkant inlogde in en informatie haalde uit Mijn ING. Dat was voordat ING kwam met haar huidige generatie app - voornamelijk omdat de vorige generatie bij ING bepaald niet om over naar huis te schrijven was.

ING had dat vrij snel in de smiezen en heeft een rechter gevraagd daar een stokje voor te steken...

[NovapaX]

Hydra schreef op dinsdag 17 november 2015 @ 10:40:
[...]


En wat schiet je daar mee op? Een klant haalt over het algemeen maar 1 keer z'n saldo informatie op bijvoorbeeld. Caching heeft alleen zin als je vaak dezelfde informatie ophaalt. Dat soort zaken worden over het algemeen al gecached. Het probleem is vaak dat je bepaalde zaken gewoon niet kunt cachen. Als jij saldo informatie op wil halen moet eerst gecheckt worden of een bepaalde rekening uberhaupt van jou is: deze call kan en mag niet gecached worden. En zo zijn er nog vaak een hele zwik aan dergelijke checks die allemaal andere systemen raken.

Je hebt gelijk, maar zoals ik al zei, in het geval van de rabo-app gaat het niet eens zozeer om de saldo-informatie, maar om alle bloat eromheen die gewoon enorm traag is en slecht geïmplementeerd.

[Keiichi]

Caching zou volgens mij toch niet zo'n issue moeten zijn. Ik weet dat de oude app dit wel deed, als ik een transactie deed, dan waren m'n saldo's niet gelijk aangepast. (nieuwe app wel overigens).

Bij het inloggen of zelfs voor het inloggen zou er al een snapshot gemaakt kunnen worden hoe alle rekeningen er nu uit zien. Op voorhand alle data ophalen die je in eerste instantie zou willen inzien. (saldo, laatste x-transacties op alle rekeningen)

Maar de UX lijkt ook best wel een probleem. Als ik een overboeking wil maken dan vul in een bedrag in en ik zie letterlijk pas een seconde of meer later het ook verschijnen op het scherm. Zoiets moet je met Microsoft Word proberen.

[Hydra]

Keiichi schreef op dinsdag 17 november 2015 @ 11:12:
Caching zou volgens mij toch niet zo'n issue moeten zijn. Ik weet dat de oude app dit wel deed, als ik een transactie deed, dan waren m'n saldo's niet gelijk aangepast. (nieuwe app wel overigens).

Dat heeft niet zoveel met caching te maken. Boekingen worden batch-gewijs verwerkt. Hierin werken 2 parallelle systemen. Een "snel" systeem (dat een boeking in een paar minuten verwerkt zou moeten hebben) en een "traag" system daar in de nacht de definitieve betalingen verwerkt. Een app kan die informatie sowieso niet client-side cachen; een dergelijke betaling kan om heel veel redenen mislopen.

[elhopo]

Als ik het goed heb begrepen is de nieuwe applicatie een HTML5 applicatie, daar valt niet zoveel omheen te schrijven, het wordt aangeboden zoals het is, en de app is slechts een dun schilletje om wat beveiligde webpagina's heen.
De oudere app zal hebben gewerkt met wat beveiligde webservices, daar kan je dan wel een eigen app omheen schrijven, maar hoe kom je aan de adressen van de services, en hoe weet je wat je moet sturen en hoe je de response moet interpreteren? Daarnaast zal het wel over de een of andere SSL verbinding worden ge-encrypt, dus daar kan je ook niet zomaar in meekijken om het een en ander af te tappen. Mocht het je lukken dan denk ik dat je ook nog wel een certificaat nodig hebt om dit te kunnen en / decrypten en ook dat certificaat geven ze je niet zomaar.
Ook een applicatie decompileren en de broncode bekijken zal je niet lukken, ook dat is allemaal ge-encrypt en bovendien illegaal.
Het korte antwoord is dat het met aan zekerheid grenzende waarschijnlijkheid onmogelijk is.

[ Voor 16% gewijzigd door elhopo op 17-11-2015 13:11 ]

[incaz]

Maar zelfs daarvan vraag ik me af: hoe lang kan het duren om een html van een regel of 10 heen en weer te sturen? (Ok, en nog wat headers.) We hebben het hier toch om hele simpele schermen? En is ajax dan helemaal niet mogelijk in webapps?

[Verwijderd]

Hydra schreef op dinsdag 17 november 2015 @ 09:21:
P.s. ik vind het bijzonder on-chique dat een mod me aan de hand van mijn e-mailadres dat niet getoond wordt in mijn profiel opgezocht heeft op LinkedIn.

Ik vraag me af of het wel verstandig is om je zo uit te wijden op tweakers.net over de IMO vertrouwelijke werkzaamheden die je doet.

Je geeft bijvoorbeeld zelf aan dat je op Linkedin te vinden bent.

Je bent voor de criminele wereld zeker niet minder interressant geworden.

[Hydra]

Verwijderd schreef op dinsdag 17 november 2015 @ 13:21:
Ik vraag me af of het wel verstandig is om je zo uit te wijden op tweakers.net over de IMO vertrouwelijke werkzaamheden die je doet.

Ik heb geen vertrouwelijke informatie gegeven?

Je bent voor de criminele wereld zeker niet minder interressant geworden.

En wat denk je dat een crimineel aan mij heeft?

[elhopo]

incaz schreef op dinsdag 17 november 2015 @ 13:16:
Maar zelfs daarvan vraag ik me af: hoe lang kan het duren om een html van een regel of 10 heen en weer te sturen? (Ok, en nog wat headers.) We hebben het hier toch om hele simpele schermen? En is ajax dan helemaal niet mogelijk in webapps?

Dat is maar net afhankelijk van hoe het geïmplementeerd is. Buiten die regel of 10 kan het zijn dat er iedere keer een bak javascript wordt overgepompt, plaatjes worden meegenomen en dat de backend er misschien wel 500 ms over doet om die respons te berekenen, omdat dat uit verschillende systemen kan komen (waarvan er misschien wel een paar asynchroon zijn, voor backend systemen moet je soms andere keuzes maken dan voor frontend systemen).
Dit alles over 4G (of 3G) met de latency van het hele netwerk maakt het ook niet beter.

Aangezien je gewoon een mini browser in een webapplicatie hebt is Ajax gewoon wel mogelijk.

Overigens hebben ze bij Facebook ooit aangegeven dat het 1 van hun grootste fouten is geweest om hun mobiele app als HTML5 uit te voeren. Ik kan dan ook niet begrijpen dat iemand bij de Rabobank dacht: Hee, dat is een goed idee! Laten we het zo gaan maken.

Ik zou het nog kunnen begrijpen als je helemaal niets zou hebben. Een HTML5 variant is dan redelijk vlot te maken en dan kan je later altijd nog een native applicatie maken. Met de ervaring die er intussen is op het web is dit echt een onbegrijpelijke stap, maargoed ik zit niet in het bestuur van de Rabobank, wellicht zijn er andere beweegredenen geweest...

[ Voor 12% gewijzigd door elhopo op 17-11-2015 13:30 ]

[Verwijderd]

Hydra schreef op dinsdag 17 november 2015 @ 13:27:
[...]


Ik heb geen vertrouwelijke informatie gegeven?

Je geeft aan een applicatie van een grote bank werkt. Tevens publiceer je wat, beperkte, informatie over werking.

Ik ken je Linkedin profiel niet mogelijk kan iemand daar ook herleiden voor welke bank je deze opdracht uitvoert.

[...]


En wat denk je dat een crimineel aan mij heeft?

Mogelijke backdoor , informatie over de applicatie zodat ze deze misbruiken kunnen etc
Het hangt er ook van af hoe chantabel je bent.

[Hydra]

Verwijderd schreef op dinsdag 17 november 2015 @ 13:36:
Mogelijke backdoor , informatie over de applicatie zodat ze deze misbruiken kunnen etc
Het hangt er ook van af hoe chantabel je bent.

Ik denk dat je hard overschat hoeveel toegang je hebt als dev en hoe deze systemen werken. Het is niet een database waar je ff een saldo op +1000000 zet.

[azerty]

Hydra schreef op dinsdag 17 november 2015 @ 13:48:
[...]


Ik denk dat je hard overschat hoeveel toegang je hebt als dev en hoe deze systemen werken. Het is niet een database waar je ff een saldo op +1000000 zet.

Daar gaat mijn plan om je uit te nodigen, dronken te voeren en dat dan subtiel te vragen

[Hydra]

azerty schreef op dinsdag 17 november 2015 @ 13:59:
Daar gaat mijn plan om je uit te nodigen, dronken te voeren en dat dan subtiel te vragen

Aww

[Guillome]

Daar gaat je avond met gratis drank

[incaz]

elhopo schreef op dinsdag 17 november 2015 @ 13:30:

Overigens hebben ze bij Facebook ooit aangegeven dat het 1 van hun grootste fouten is geweest om hun mobiele app als HTML5 uit te voeren. Ik kan dan ook niet begrijpen dat iemand bij de Rabobank dacht: Hee, dat is een goed idee! Laten we het zo gaan maken.

Ik heb gezocht naar de context van die quote, maar behalve het algemene 'unresponsive' is het me helemaal niet duidelijk waarom de business case van Facebook (VEEEEL data en user interaction) vergelijkbaar is met die van de Rabobank. Bij facebook heb je te maken met video, notifications, langere teksten, veel foto's, vaak kijken, veel scrollen etc (en zelfs spelletjes? geen idee hoe dat werkt.)

Bij bankapps gaat het voornamelijk om een paar getalletjes. Weinig data, weinig beweging.

DAT lijkt me veel meer de fout die de rabobank heeft gemaakt: het idee dat een bankapp net zo 'leuk' moet zijn als andere apps. Maar facebook verdient geld met het verleiden van mensen zoveel mogelijk op hun site rond te hangen, + reclame? + gegevensverkoop over bekijkgedrag, etc. Dat geldt voor bankapps allemaal niet.

Ik vind de algemene lijn van de kritiek op de rabo-app met 'ze hadden van facebook moeten leren' dan ook wat te simpel, en ben veel geinteresseerder in waarom de webapp zo slecht presteert, zelfs als het naar mijn mening niet nodig is om een webapp die zulke simpele taken uitvoert als een bankierenapp zo traag te laten zijn.

Dus niet 'het is slecht omdat facebook zegt dat het slecht is', maar vooral: wat gebeurt er nou waardoor het zo traag is, en is het echt fundamenteel onmogelijk om dat binnen een webapp op te lossen?

[Tim2121]

Voor wat spielerij heb je hier misschien wat aan:
https://honeybee.3scale.net/docs

https://github.com/honeyb...ion/blob/master/README.md

[Keiichi]

Is het misschien ook bekend wat evt de URL van de nieuwe app van rabobank zou zijn? Ben benieuwd hoe deze in mijn gewone browser zou werken

[elhopo]

incaz schreef op dinsdag 17 november 2015 @ 14:29:
[...]

Bij bankapps gaat het voornamelijk om een paar getalletjes. Weinig data, weinig beweging.

Dat is jouw aanname, zolang ik de code van een applicatie niet heb gezien kan ik er niets van zeggen. Overigens is de traagheid niet de enige storende factor, ik irriteer me suf aan het plaatje van een medewerker wat zit mee te kijken en het feit dat ik maar 3 rekeningen kan zien in het overzicht (ik heb er 5: betaalrekening, spaarrekening en 3 spaarrekeningen van de kinderen). Je kan in de app een berichtje / feedback sturen maar ik vermoed dat dat verdwijnt in /dev/null...

[incaz]

elhopo schreef op dinsdag 17 november 2015 @ 16:42:
[...]
Dat is jouw aanname, zolang ik de code van een applicatie niet heb gezien kan ik er niets van zeggen.

Dat is niet zozeer een aanname als wel een analyse: de kern van de functionaliteit van een bankapp is heel simpel. Een paar lijstjes, een paar getalletjes, enkele hele simpele formuliertjes met maar een paar velden en opties... meer dan dat is het gewoon eigenlijk niet. Geen ingewikkelde wereldmaps, geen gaming AI, geen physics die de bewegingen van je sprites hoeven te berekenen, niets van dat al.

Zo suf als maar zijn kan. Vrijwel al het werk gebeurt serverside. De api die hierboven genoemd werd geeft wel ongeveer aan welke functies er zoal zijn... en dat zijn er gewoon niet zo veel.

Dat kun je dan naar believen nog opfleuren met wat leuke invulhulpjes en een likje verf in de vorm van mooie css, (en wellicht nog lokale encryptie om niet alleen op ssl te vertrouwen?) en daar pas je dan een goede cache- en loadstrategie op toe, en dan zou het allemaal heel compact moeten kunnen.

Als het veel meer dan dat is, is dat meer de fout dan web-vs-native lijkt me. Iets wat helemaal van toepassing is op wat je beschrijft: zo'n foto van een medewerker die je de hele tijd aan zit te kijken terwijl dat helemaal geen core functionaliteit is. Maar als ze dat native hadden geimplementeerd zou het daar niks beter op worden. En dat ze de boel zo vervelend hebben gelayout dat er maar 3 rekeningen op het overzicht passen heeft ook 0 te maken met bv beperkingen van css. Dat is een designkeuze, en geen technische.

[agoNITE]

Mocht je nog inspiratie zoeken voor de met betrekking tot de UI voor Android/iOS:
Behance - Rabobankieren Android & iOS concept

[fsfikke]

Verwijderd schreef op dinsdag 17 november 2015 @ 13:36:
[...]


Je geeft aan een applicatie van een grote bank werkt. Tevens publiceer je wat, beperkte, informatie over werking.

Ik ken je Linkedin profiel niet mogelijk kan iemand daar ook herleiden voor welke bank je deze opdracht uitvoert.
[...]

Dat bepaalde informatie bij jou (of een random ander iemand) niet bekend is, betekend nog lang niet dat die informatie vertrouwelijk is

[raptorix]

Keiichi schreef op dinsdag 17 november 2015 @ 15:43:
Is het misschien ook bekend wat evt de URL van de nieuwe app van rabobank zou zijn? Ben benieuwd hoe deze in mijn gewone browser zou werken

https://m.rabobank.nl/

[BlueZero]

Er wordt wel veel gezegd over de complexiteit van de backend van deze applicaties, en ik denk dat je daar een punt heb. Echter er zijn in mijn ervaring (moet soms koppelingen bouwen met een bank) toch wel wat andere punten die meespelen soms.

Onwil/-kunde bij sommige bedrijfsonderdelen, van hogeraf wordt er besloten dat er een nieuwe functionaliteit moet worden opgezet, hiervoor wordt een team aangewezen (intern/extern) echter bepaalde afdelingen die verantwoordelijk zijn voor de back-end systemen die de info dienen aan te leveren hebben er eigenlijk niet zo veel zin in ala "de huidige oplossing werkt toch ook goed".

Het ligt dus dan niet perse aan de ontwikkelaars van de app echter hun wensen worden niet altijd even goed ingevuld door de mensen die er aan mee moeten werken.

Dat het niet mogelijk is om een snelle app te bouwen is flauwekul naar mijn mening. De huidige online bankieren omgevingen van een bank hebben vaak prima response-tijden (in acht nemende dat hier vaak nog meer/gedetailleerdere data wordt geladen ook).

Als die data centraal samengevoegd is gaat de API die hem versleuteld/uitspuugt niet meer de vertragende factor zijn natuurlijk.

En "last but not least" het argument richting een klant sorry onze app is niet zo rap want we hebben complexe en verouderde backend systemen is natuurlijk wel erg treurig.

[Cartman!]

agoNITE schreef op dinsdag 17 november 2015 @ 17:25:
Mocht je nog inspiratie zoeken voor de met betrekking tot de UI voor Android/iOS:
Behance - Rabobankieren Android & iOS concept

Deze is natuurlijk prachtig en precies wat ik als gebruiker wil. Jammer dat Rabobank zo achter lijkt te lopen qua internet terwijl ze ~15 jaar geleden er juist in voorop liepen.

[Firefly III]

-

[ Voor 100% gewijzigd door Firefly III op 23-10-2016 15:06 . Reden: Leeg vanwege privacy. ]

[expor]

Er wordt wel gezegd dat de bank apps relatief snel zijn, maar die van Rabobank springt er toch wel uit. Ik gebruik er zelf 3, namelijk ING, ABN en Rabobank. ING heeft vanaf begin heerlijk snel gewerkt, ABN wisselde maar inmiddels net zo snel (ik vind de flow van de app niet altijd even handig), maar sinds de nieuwe Rabobank app is het echt tergend langzaam. Elke keer als je een rekening opnieuw opent lijkt hij de hele historie opnieuw te downloaden voordat hij iets laat zien bijvoorbeeld.