Kjører x86-kode i nettleseren

[kilogram]

Google har lansert et prosjekt som skal la utviklere skrive vanlig x86-kode som kan leveres over nettet.

 

Les mer

[Toa]

Syns det lukter som en Google-versjon av ActiveX... Noe jeg har misforstått?

[Sokkalf™]

What could possibly go wrong..

 

Spennende tanke, men dette har som sagt i artikkelen store sikkerhetsmessige utfordringer. Stusser også litt på hvordan dette skal foregå i praksisk. x86-kode i sin "reneste" form (assembly) er ikke akkurat raskt og lettvindt å programmere i. Skal man ha et slags "nettleser-API" som i praksis gjør nettleseren til et operativsystem?

[A-Jay]

Nå skal jo Google Code kjøres på en sandkasse, noe som forhåpentligvis vil hindre det fra å få tilgang til ting på PC-en det ikke burde ha tilgang på.

 

Men så finnes det jo alltids sikkerhetshull og annet man kan utnytte til å få tilgang på ting utenfor sandkassen. Så jeg er litt skeptisk til denne ideen likevel.

 

Stusser også litt på hvordan dette skal foregå i praksisk. x86-kode i sin "reneste" form (assembly) er ikke akkurat raskt og lettvindt å programmere i. Skal man ha et slags "nettleser-API" som i praksis gjør nettleseren til et operativsystem?

Man kan selvsagt skrive det i C eller annet programmeringsspråk for så å kompilere det.

[Sokkalf™]

Man kan selvsagt skrive det i C eller annet programmeringsspråk for så å kompilere det.

 

Selvsagt kan man det, men er det da gitt et slags API, "systemkall" osv for å relativt enkelt kunne kalle funksjoner i nettleseren, eller er dette en ren virtuell maskin?

 

Når du kompilerer et C-program av en viss kompleksitet på Windows, Linux etc, så bruker du jo i praksis en hel haug med biblioteker som ikke vil være tilgjengelige i en slik "sandkasse". Derfor vil nettleseren måtte ha sine egne bibliotekfunksjoner som kan tas ibruk av x86-koden som kjøres i den.

[Smif]

What could possibly go wrong..

Haha! Akkurat det tenkte jeg også. La oss like gjerne gi google root tilgang med en gang...

 

Og der sluttet internett å være plattform/arkitektur uavhengig?

[A-Jay]

Man kan selvsagt skrive det i C eller annet programmeringsspråk for så å kompilere det.

 

Selvsagt kan man det, men er det da gitt et slags API, "systemkall" osv for å relativt enkelt kunne kalle funksjoner i nettleseren, eller er dette en ren virtuell maskin?

 

Når du kompilerer et C-program av en viss kompleksitet på Windows, Linux etc, så bruker du jo i praksis en hel haug med biblioteker som ikke vil være tilgjengelige i en slik "sandkasse". Derfor vil nettleseren måtte ha sine egne bibliotekfunksjoner som kan tas ibruk av x86-koden som kjøres i den.

Jeg tror nok det vil være et slikt bibliotek ja. Vi snakker tross alt om et program som skal kjøre som en del av en HTML-side i nettleseren.

[idos]

Spørsmålet her er vel hva koden skal gjøre....

Er det som en erstatning for applets flash osv, eller er det som en erstatning av javascript. eller kanskje begge deler. ... må sjekke ut..

[krigun]

Så dette er akkurat samme mulighet som Java har hatt i alle år, men nå kommer altså Python også. Hva er egentlig nytt her?

 

Se f.eks: https://jogl-demos.dev.java.net/applettest.html

[Smif]

Det er her snakk om kompilerte språk, ikke script... Java er en liten mellomting

[Sokkalf™]

Java er jo også et kompilert språk. x86-kode som kan kjøres native vil jo ha en ytelsesfordel på x86-prosessorer, men på andre arkitekturer vil denne falle bort, og man kunne like gjerne brukt java (som sikkert er mye bedre optimalisert for slike scenarier uansett). Med framgangen til mobile enheter på nettet, som gjerne ikke bruker x86-arkitekturen i det hele tatt, kan man jo lure på om dette egentlig har noe for seg..

[krigun]

Jeg mente at du kan integrere native kode MED Java (JNI). OpenGL appleten linket til ovenfor gjør akkurat dette. Så Google har laget en plugin som bruker Python til dette istedenfor. Flott.

[Simen1]

Oioi, høres skummelt ut. Jeg ser for meg en flodbølge av diverse alvorlige angrep dersom det skulle dukke opp sikkerhetshull. Og sikkerhetshull er jo noe som dukker opp i all programvare. Får håpe dette blir testet og sikret grundig i mange omganger før det slippes på markedet.

 

En annen ting: Hvordan vil dette fungere når man bruker nettlesere på andre arkitekturer enn x86? F.eks på mobiltelefonen, ARM, Power, Cell, etc? Vil den emulere x86 eller blir det bare full stopp?

[efikkan]

Tviler sterkt på at det er snakk om assembler her, selv om det er det som er x86-kode.

 

At vi skal kjøre programmer i steden for script er en veldig interessant tanke, spesielt pga. ytelse men også sikkerhet om systemet virker. Jeg har lenge vært skeptiske til all denne dårlige skriptingen rundt om kring, men ulemper er at ting blir låst mot plattformer.

[Tormeh]

Dette ser spennende ut, om enn noe risikabelt. Hvis de nå klarer å få det samme til for andre instruksjonssett enn x86 og integrere det på en god måte, blir dette virkelig spennende. Da kan weblications basert på dette kjøre native på mange instruksjonssett, men samtidig få det til å framstå for brukeren som om det er samme weblication som kjøres uavhengig av instruksjonssett.

 

Kanskje andre instruksjonssett enn x86 endelig kan brukes av vanlige sluttbrukere? AMD/Intel-duopolet kunne fått seg en knekk da. (Ja, jeg vet at VIA har x86 de også, men markedsandelen er veldig liten)

 

Men tror nok at sjansen for at dette skjer er veldig lav, når alt kommer til alt

[Thorsen]

Konseptet virker usikkert spør du meg.

 

Det vil bli oppdaget hull, og det vil bli et kappløp om å alltid ha "mest" oppdatert versjon.

 

Personlig er jeg også litt imot denne ideologien om at ALT skal kjøres i nettleseren, uansett hvordan det løses blir det et ekstra kompliserende lag.

[DarkSlayer]

Jeg er av den oppfatning at javascript i browser trenger en real erstatning - språket og motorene er jo rævva egentlig. Men jada, man får jo lagt mye rart. Men så lenge man ikke kan lage programmer ala gta4, 3dstudio, fullblods office etc - så er det rævva.

 

Fordelen med javascript vs x86 er jo at javascript teoretisk kan kompileres og kjøres på alskens prosessorer. Mens x86 er begrenset til .... x86 prosessorer.

Det idiotiske her er jo at man kan lage en javascript-til-google-sandbox kompilator, og så er man tilbake til start...

 

Men jeg syns det er på høy tid at man ser på alternativer, og muligheter for å kunne kjøre et bredere utvalg av språk/rammeverk i browser - for det må man om man skal kunne støtte ulike miljøer og behov. Det finnes ikke 1-size-fits-all språk. Du lager ikke windows apps i php selv om det går an. C++ er ikke det første du tyr til for å lage webapps.

[Kahuna]

Dette høres ikke så dumt ut hvis man vil ha opp ytelsen på web-applikasjoner. Derimot har de en aldri så liten jobb foran seg hva angår sikkerhet og integrering mot OS og hardware.

 

Jeg bruker sandboxie hjemme, den kjører x86-kode native, uten ytelsestap. Den er så vidt jeg vet vanskelig å bryte ut av men den har de sikkerhetsmessige ulempene at den ikke skjuler sin egen eksistens for kjørte programmer og gir read-only tilgang til mesteparten av systemet... Tror google kjøpte opp en konkurrent til sandboxie for noen år siden, kan hende den teknoligien ligger i bunn her?

 

Litt mer usikker på hvordan de skal løse OS-integrering? Kanskje med et Qt-liknende rammeverk som automatisk kompilerer opp versjoner for et utvalg OS og gir brukeren den versjonen som passer maskinen hans?

[Vipera]

Den er så vidt jeg vet vanskelig å bryte ut av men den har de sikkerhetsmessige ulempene at den ikke skjuler sin egen eksistens for kjørte programmer

 

Hva mener du? Programer har jo ikke peiling på om de blir kjørt i en sandbox eller ikke, det er jo poenget.

 

og gir read-only tilgang til mesteparten av systemet...

 

som også er hele poenget. Programmer kan skrive så mye de vil, men det er begrenset til inne i sandboxen.

[Rabbid]

Saalenge det kan brukes av alle ser jeg ikke noe galt i dette, men höres naa ganske taapelig ut.