Smedsrud Skrevet 26. september 2014 Del Skrevet 26. september 2014 Java-fri nettbank er lansert, men enkelte banker holder igjen lenger enn de andre.Se når du kan kaste ut Java fra nettbanken Lenke til kommentar
efikkan Skrevet 26. september 2014 Del Skrevet 26. september 2014 (endret) 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 26. september 2014 av efikkan Lenke til kommentar
Xprez Skrevet 26. september 2014 Del Skrevet 26. september 2014 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. 4 Lenke til kommentar
Populært innlegg ignoreme Skrevet 26. september 2014 Populært innlegg Del Skrevet 26. september 2014 Skulle likt å se deg utvikle bankId 2.0 på 10 minutter... 10 Lenke til kommentar
realbunny Skrevet 26. september 2014 Del Skrevet 26. september 2014 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
sevs Skrevet 26. september 2014 Del Skrevet 26. september 2014 Jeg har kastet ut java fra nettbanken. Har faktisk kastet ut hele nettbanken. Går fysisk i banken hver gang jeg vil noe. Lenke til kommentar
RamGuy Skrevet 26. september 2014 Del Skrevet 26. september 2014 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. 3 Lenke til kommentar
Fush. Skrevet 26. september 2014 Del Skrevet 26. september 2014 De av oss uten katastroferæva bank har aldri behøvet Java for innlogging. Leve Skandiabanken! 2 Lenke til kommentar
mongojarle Skrevet 26. september 2014 Del Skrevet 26. september 2014 Hva med Gjensidige? Lenke til kommentar
Gjest Slettet+6132 Skrevet 26. september 2014 Del Skrevet 26. september 2014 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
efikkan Skrevet 26. september 2014 Del Skrevet 26. september 2014 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 Skrevet 26. september 2014 Del Skrevet 26. september 2014 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
*F* Skrevet 26. september 2014 Del Skrevet 26. september 2014 De av oss uten katastroferæva bank har aldri behøvet Java for innlogging. Leve Skandiabanken! +1 Skandiabanken er en drøm å logge inn på. Så slipper man til med en bankbrikke 5 Lenke til kommentar
tHz Skrevet 26. september 2014 Del Skrevet 26. september 2014 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. 1 Lenke til kommentar
tHz Skrevet 26. september 2014 Del Skrevet 26. september 2014 (endret) 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 26. september 2014 av tHz 1 Lenke til kommentar
Toppitus Skrevet 26. september 2014 Del Skrevet 26. september 2014 Avinstallerte pisset for måneder siden. Sålangt har jeg overlevd. 1 Lenke til kommentar
efikkan Skrevet 26. september 2014 Del Skrevet 26. september 2014 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
Toppitus Skrevet 26. september 2014 Del Skrevet 26. september 2014 (endret) 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 26. september 2014 av Toppitus Lenke til kommentar
efikkan Skrevet 26. september 2014 Del Skrevet 26. september 2014 Pass på, noen nummer for kundeservice koster en formue! Lenke til kommentar
tHz Skrevet 26. september 2014 Del Skrevet 26. september 2014 (endret) 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 26. september 2014 av tHz Lenke til kommentar
Anbefalte innlegg
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 kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå