Gå til innhold

Se når du kan kaste ut Java fra nettbanken


Anbefalte innlegg

Videoannonse
Annonse

Ett steg frem og to tilbake? Java Runtime Environment erstattes med JavaScript?

Det blir da som å velge mellom pest og kolera. Det er et stort mysterium hvorfor de har klart å bruke så mange tusen konsulenttimer på å bytte ut et front end som kunne vært klart på 10 minutter. Alt som trengs er tross alt noen få ulike HTML-skjema, uten noe makkverk av JavaScript som bare introduserer potensielle sikkerhetshull og brukerproblemer. Så hvorfor trenger de da JavaScript? Er det for å lage noen fancy effekter, eller er det for å implementere "sikkerhet"? Hvis det er sistnevnte er det spesielt urovekkende.

 

 

På den positive siden er det nå ingen grunn til at folk flest skal ha JRE installert på PCene sine lenger, så får de fjernet en av verdens dårligste og beryktede programvarepakker.

Endret av efikkan
Lenke til kommentar

Tja må være ganske lite folk som ringer til banken da om 20% av kundeservice tiden går til forklaring på oppdatering/installasjon av java, eller så må de ha noen sære kunder siden selv folk i 60 åra klarer å installere java sammens med den herlige mcafee jævelen.

  • Liker 4
Lenke til kommentar

Ett steg frem og to tilbake? Java Runtime Environment erstattes med JavaScript?

Det blir da som å velge mellom pest og kolera. Det er et stort mysterium hvorfor de har klart å bruke så mange tusen konsulenttimer på å bytte ut et front end som kunne vært klart på 10 minutter. Alt som trengs er tross alt noen få ulike HTML-skjema, uten noe makkverk av JavaScript som bare introduserer potensielle sikkerhetshull og brukerproblemer. Så hvorfor trenger de da JavaScript? Er det for å lage noen fancy effekter, eller er det for å implementere "sikkerhet"? Hvis det er sistnevnte er det spesielt urovekkende.

 

 

På den positive siden er det nå ingen grunn til at folk flest skal ha JRE installert på PCene sine lenger, så får de fjernet en av verdens dårligste og beryktede programvarepakker.

 

Ikke at jeg er noe ekspert på javascript, men de bruker dette mer får funksjonaliteten? Rent design messig?

Lenke til kommentar

Tja må være ganske lite folk som ringer til banken da om 20% av kundeservice tiden går til forklaring på oppdatering/installasjon av java, eller så må de ha noen sære kunder siden selv folk i 60 åra klarer å installere java sammens med den herlige mcafee jævelen.

 

 

Her overvurderer du folk flest til tusen, som en som jobber i serviceyrket selv så kan jeg garantere deg at vedlikehold av Java og Flash Player er et gigantisk problem.. Enda verre blir det jo når du kjører Google Chrome som blokkerer eldre utgaver av Java automatisk (noe som i seg selv er bra, men forverrer jo problematikken ytterligere).

 

Flash Player har jo løst dette greit med automatiske oppdateringer som går helt av seg selv, og Google Chrome har jo innebygget PepperFlash som oppdateres med Chrome, som igjen har auto-installasjon av oppdateringer osv.. Men mange kjører fremdeles eldgamle versjoner av Flash Player som de først må oppdatere for i det hele tatt å få denne funksjonaliteten... Og det skjer jo ikke av seg selv.

 

 

Java er en verre suppe, for Java har ingen auto-installasjon av oppdateringer, den vil bare mase høl i hue på deg konstant nederst i høyrehjørnet i Windows, noe 99% av folket bare krysser bort uansett. Og det at det pøses ut ny versjon av Java hver 14. dag hjelper ikke på hva angår å få folk flest til å holde Java oppdatert og klar på sine systemer. Mange kjører jo nå også 64-bit utgaver av nettlesere og har ikke nødvendigvis 64-bit utgaven av Java installert overhode på sine systemer.

  • Liker 3
Lenke til kommentar
Gjest Slettet+6132

Ett steg frem og to tilbake? Java Runtime Environment erstattes med JavaScript?

Hvor har du det fra? (står da ingenting om hvordan Bankid 2.0 er implementert)

 

Er forøvrig fint lite av websider som "kun" har HTML(5) og ikke noe JScript eller JQuery.

Hvordan har du tenkt at kommunikasjon mot backend skal løses uten bruk av script?

Kun via native kode og bruk av Web API's på mobil platform? (HTTPS-kall)

 

Når du skriver som du gjør (og i andre tråder) må jeg jo anta at du har mer enn normalt utviklerkompetanse på emnet?

Lenke til kommentar

 

Ett steg frem og to tilbake? Java Runtime Environment erstattes med JavaScript?

Hvor har du det fra? (står da ingenting om hvordan Bankid 2.0 er implementert)

 

Er forøvrig fint lite av websider som "kun" har HTML(5) og ikke noe JScript eller JQuery.

Hvordan har du tenkt at kommunikasjon mot backend skal løses uten bruk av script?

Kun via native kode og bruk av Web API's på mobil platform? (HTTPS-kall)

 

Når du skriver som du gjør (og i andre tråder) må jeg jo anta at du har mer enn normalt utviklerkompetanse på emnet?

 

BankID har flere steder på siden sin nevnt at JavaScript er brukt uten at det er spesifisert til hva, men det er naturlig at det foregår på klientsiden. Kommunikasjon bør foregå via HTML-skjema over SSL. Det store spørsmålet blir hva de bruker JavaScript til? For å finne ut det må jeg inspisere den nye løsningen. Det kan f.eks. være interaktivitet i nettsidene det er brukt til, eller det kan være som f.eks. MEGA hvor hele kryptografien er implementert i JavaScript. Sistnevnte er en svært dårlig idé siden det finnes ørten versjoner av nettlesere som gjør potensialet enormt for feil i krypteringen. De som har styrt en del med JavaScript vet at det er et mareritt å få det til å kjøre plettfritt på alle nettlesere, der er alltid små variasjoner. Derfor bør JavaScript unngås til helt kritiske ting som kryptering. Det er mye enklere å verifisere at kryptering i nettlesere fungerer.
Lenke til kommentar
Gjest Slettet+6132

 

 

Ett steg frem og to tilbake? Java Runtime Environment erstattes med JavaScript?

Hvor har du det fra? (står da ingenting om hvordan Bankid 2.0 er implementert)

 

Er forøvrig fint lite av websider som "kun" har HTML(5) og ikke noe JScript eller JQuery.

Hvordan har du tenkt at kommunikasjon mot backend skal løses uten bruk av script?

Kun via native kode og bruk av Web API's på mobil platform? (HTTPS-kall)

 

Når du skriver som du gjør (og i andre tråder) må jeg jo anta at du har mer enn normalt utviklerkompetanse på emnet?

 

BankID har flere steder på siden sin nevnt at JavaScript er brukt uten at det er spesifisert til hva, men det er naturlig at det foregår på klientsiden. Kommunikasjon bør foregå via HTML-skjema over SSL. Det store spørsmålet blir hva de bruker JavaScript til? For å finne ut det må jeg inspisere den nye løsningen. Det kan f.eks. være interaktivitet i nettsidene det er brukt til, eller det kan være som f.eks. MEGA hvor hele kryptografien er implementert i JavaScript. Sistnevnte er en svært dårlig idé siden det finnes ørten versjoner av nettlesere som gjør potensialet enormt for feil i krypteringen. De som har styrt en del med JavaScript vet at det er et mareritt å få det til å kjøre plettfritt på alle nettlesere, der er alltid små variasjoner. Derfor bør JavaScript unngås til helt kritiske ting som kryptering. Det er mye enklere å verifisere at kryptering i nettlesere fungerer.

 

OK. :)

Jeg deler din bekymring om bruk av JS(Client side scripting), men vi får håpe dette er gjort på en trygg måte dersom det er tilfellet (JavaScript).

Lenke til kommentar

Ett steg frem og to tilbake? Java Runtime Environment erstattes med JavaScript?

Det blir da som å velge mellom pest og kolera. Det er et stort mysterium hvorfor de har klart å bruke så mange tusen konsulenttimer på å bytte ut et front end som kunne vært klart på 10 minutter. Alt som trengs er tross alt noen få ulike HTML-skjema, uten noe makkverk av JavaScript som bare introduserer potensielle sikkerhetshull og brukerproblemer. Så hvorfor trenger de da JavaScript? Er det for å lage noen fancy effekter, eller er det for å implementere "sikkerhet"? Hvis det er sistnevnte er det spesielt urovekkende.

 

 

På den positive siden er det nå ingen grunn til at folk flest skal ha JRE installert på PCene sine lenger, så får de fjernet en av verdens dårligste og beryktede programvarepakker.

 

Husk at Javascript har ingenting med Java å gjøre, om man ser bort fra navnet..

I dag er Javascript de facto standard for all webutvikling. Om du skal gjøre noe som hjelst på klientsiden så gjøres det med javascript.

Mange har negative fordommer mot javascript, men det er ikke så ille i praktisk bruk (lengre). Det brukte å være helt forferdelig på sent 90-tall.

Når det gjelder sikkerhet så kjøres som nevnt javascript på klientsiden, og kan dermed ikke utføre noe spesielt i retning av sikkerhetsfunksjoner.

10 minutter? på å produsere noe i bankverden? som har med penger å gjøre? nei.

Utvikling i slike miljøer krever tid.

  • Liker 1
Lenke til kommentar

Skulle likt å se deg utvikle bankId 2.0 på 10 minutter...

 

Enig :)

En slik instilling er desverre helt vanlig, spesielt til oppgaver man ikke aner noe om (eller aner en liten brøkdel av). Jeg har selv gjort samme feilen flere ganger, men begynner å lære.

Stort sett så er ting litt mer komplisert enn man umiddelbart forstår.

Endret av tHz
  • Liker 1
Lenke til kommentar

Husk at Javascript har ingenting med Java å gjøre, om man ser bort fra navnet..

I dag er Javascript de facto standard for all webutvikling. Om du skal gjøre noe som hjelst på klientsiden så gjøres det med javascript.

Mange har negative fordommer mot javascript, men det er ikke så ille i praktisk bruk (lengre). Det brukte å være helt forferdelig på sent 90-tall.

Når det gjelder sikkerhet så kjøres som nevnt javascript på klientsiden, og kan dermed ikke utføre noe spesielt i retning av sikkerhetsfunksjoner.

10 minutter? på å produsere noe i bankverden? som har med penger å gjøre? nei.

Utvikling i slike miljøer krever tid.

Jeg har aldri påstått at språket Java har noe som helst med språket JavaScript.

 

Alt som trengs for BankID på klientsiden er et skjema som sendes over SSL, og da kan du løse det på enklest og sikrest mulig måte, og derfor kan front end designes på få minutter, fordi all validering skal skje i back end. Å bruke JavaScript her introduserer bare mulige feil i oppførsel, samt risiko for potensiell injection av script hvis dette integreres dårlig med nettbutikker. Jeg har ingenting i mot bruk av JavaScript til interaksjon utenfor kritiske operasjoner, men det er hull i hodet å implementere noe unødvendig i JavaScript når det finnes en tryggere måte. Som jeg har nevnt over er det ennå værre om de har implementert kryptering i JavaScript, noe så komplisert er vanskelig å få til sikkert på tvers av maskiner (ref. MEGA).

Lenke til kommentar

Hmm. Lurer på om jeg skal ringe inn en siste (forøvrig første også) gang til en av bankene som fremdeles bruker Java og be dem hjelpe meg å installere det, bare for å være et helsike.

EDIT: ... og jeg bruker ikke engang banken. x)

Endret av Toppitus
Lenke til kommentar

 

Husk at Javascript har ingenting med Java å gjøre, om man ser bort fra navnet..

I dag er Javascript de facto standard for all webutvikling. Om du skal gjøre noe som hjelst på klientsiden så gjøres det med javascript.

Mange har negative fordommer mot javascript, men det er ikke så ille i praktisk bruk (lengre). Det brukte å være helt forferdelig på sent 90-tall.

Når det gjelder sikkerhet så kjøres som nevnt javascript på klientsiden, og kan dermed ikke utføre noe spesielt i retning av sikkerhetsfunksjoner.

10 minutter? på å produsere noe i bankverden? som har med penger å gjøre? nei.

Utvikling i slike miljøer krever tid.

Jeg har aldri påstått at språket Java har noe som helst med språket JavaScript.

 

Alt som trengs for BankID på klientsiden er et skjema som sendes over SSL, og da kan du løse det på enklest og sikrest mulig måte, og derfor kan front end designes på få minutter, fordi all validering skal skje i back end. Å bruke JavaScript her introduserer bare mulige feil i oppførsel, samt risiko for potensiell injection av script hvis dette integreres dårlig med nettbutikker. Jeg har ingenting i mot bruk av JavaScript til interaksjon utenfor kritiske operasjoner, men det er hull i hodet å implementere noe unødvendig i JavaScript når det finnes en tryggere måte. Som jeg har nevnt over er det ennå værre om de har implementert kryptering i JavaScript, noe så komplisert er vanskelig å få til sikkert på tvers av maskiner (ref. MEGA).

 

 

Bare et skjema over SSL... du har virkelig ikke peiling.

 

Over til sikkerhet. Du mener Javascript på klientsiden introduserer risiko for injection? Hvorfor det? Du kan ta fint kjøre javascript injection selv om sia ikke har javascript fra før? Tror du folk kjører uten javascript for tia?

Selvfølgelig har de ikke implementert kryptering i Javascript. Hvorfor skulle noen gjøre det? hva i all verden er det slags utviklermiljø du er i?

Javascript brukes til å behandle svar man får fra back-end og tilpasse flyt for bruker.

Endret av tHz
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...