Google snart klar med Native Client til udviklerne: Kør C-kode i browseren

Google-projektet Native Client er ved at være klar. Det skal bygge bro mellem den lokale maskinkraft og web-applikationer.

Besøg en webside og kør et krævende spil eller en tung applikation via browservinduet, med samme hastighed som var den installeret lokalt.

Sådan lyder den vision, Google har forfulgt i flere år nu med projektet Native Client, og nu er der ved at være hul igennem, skriver firmaet i et blogindlæg.

Selvom der stadig er lang vej til et færdigt og stabilt produkt, er udviklerne hos Google nu stolte af at have knækket de hårdeste nødder på vejen.

For eksempel er der blevet arbejdet meget med sikkerheden, eksempelvis med ekstra sandboxing, da en webside med uhindret adgang til klient-maskinen ville være enhver hackers våde drøm.

Nu fejrer Google udgivelsen af det første udviklerkit til Native Client, som understøtter det nye browser-API Pepper. Det er en vigtig milepæl i arbejdet for at gøre Native Client lige så sikkert og portabelt som Javascript, skriver firmaet.

Med Native Client kan man skrive kode i maskinnære sprog som C eller C++, der så via browseren kan køre på klienten med næsten samme hastighed som rent lokale applikationer.

Lykkes Googles plan, kan det betyde en ny omvæltning, hvor der til sidst ikke er mange grunde til at bruge tid på at installere software lokalt.

I de kommende måneder vil Google frigive API'er for blandt andet 3D-grafik, lokal filadgang, Websockets og peer-to-peer-netværk. Der bliver også arbejdet på Dynamic Shared Objects, som med tiden vil føre til et Application Binary Interface, som gør hele konceptet mere stabilt.

Indtil det er sket, vil Native Client være slået fra som standard, men de eventyrlystne kan hente en beta-version af Chrome 10 og slå Native Client til.

Det er langt overvejende Google, som står bag arbejdet med Native Client, men hele projektet er open source og laves til alle gængse platforme, inklusive en version til ARM-processorer.

Native Client vil kunne køre i Chrome, Firefox og Opera, men ikke Microsofts Internet Explorer, som bruger ActiveX-teknologi til udvidelserne.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (7)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Palle Simonsen

Spændende om Google lykkes med at sandbox'e godt nok til at manglende sikkerhed ikke bliver en barrierer.

En hurtig inspektion af sourcen til 'Helloworld' giver indtryk af et nogenlunde pænt C++ api og et lidt mere rodet C api (samt en reference til 'hitchhikers guide' ;))

http://code.google.com/p/nativeclient-sdk/source/browse/trunk/src/exampl...

http://code.google.com/p/nativeclient-sdk/source/browse/trunk/src/exampl...

  • 0
  • 0
#2 Michael Nielsen

Det er næsten allerede umuligt at holde malware væk fra sin computer, det her kan virkeligt gøre det svært...

håber de kan få en funktionel sandbox - som vores browsere behøver allerede nu, med almindelig plugins.

  • 0
  • 0
#3 Flemming Frandsen

Native Client er virkeligt meget gennemtænkt mht. sikkerhed, f.eks. må koden slet ikke lave kald til OS'et på egen hånd.

Maskinkoden er underlagt nogle strenge krav som tillader at sandbox'en kan validere at koden ikke gør noget den ikke må, inden den startes, så med mindre der er fejl i NativeClient så bør det være sikkert at køre.

NC forhindrer koden i at lave kald til OS'et, i stedet skal alle kald gå via NCs API, det gør også at det er umuligt at lave NC kode der er bundet til et enkelt OS.

... i modsætning til ActiveX som er 100% Windows kode og ultra-usikkert og inkompatibelt med alt andet end Windows.

  • 0
  • 0
#4 Robert Larsen

Hvorfor dog ikke bruge JavaScript?

Browseren kan jo JIT compile JavaScript til noget, som er optimeret til den maskine, det kører på...eller compile det til JVM kode og lade JVM'en tage det sidste skridt til native kode.

  • 0
  • 0
#5 Michael Nielsen

Det har potentiale til at virkeligt blive usikkert, fordi du åbner for code injection, og mange andre ting på stack niveau.

Jeg er bange for at det bare bliver lige så usikkeret som activeX.

Hvis man kørte det i noget lign. en chroot, kunne der være noget om det, i det, selv hvis du bryder containeren du sidder i, så har operativ systemet begrænset din skade til et meget begrænset område, men mig bekendt er det kun unix verdenen der har dette koncept.

Jeg tror simplehen ikke på at browserne kan implementere noget der kan begrænse det nok, for at sikre dit system. Da så snart du har aktiveret det binære kode, bliver det meget svært at stoppe dynamic loading af system biblioteker, selvom du har begrænset systemet til at det ikke må gøre det.

Jeg er bange for vi ender med den situation at vi skal havde et utal af ekstra sikkerhedsprogrammer kørende for at kunne håndtere sandboxing.

Grunden til jeg har den holding er at der er et utal af plugins til divs browsere du er tvunget til at havde installeret, hvis du vil ind på forskellige sider, disse plugins er fri til at angribe og misbruge dit system helt frit. Browser leverandørene ville havde, hvis de kunne begrænset adgangen til brugere systemet, men dette har de ikke kunnet.

Så ville jeg heller at man standardisered java, således det blev en standard element af browseren, og man fixede de tåbelige bugs, relateret til signeret applets, hvor man simplehen tager appletten ud af sandboxen, når den er signeret.

Jeg så hellere man fixede java (og javascript) sandboxen, således jeg som brugere fik fuld kontrol over hvad jeg tillader applets at gøre til mit system (hvis jeg ønsker det), og den per automatik kun fik adgang til et eneste katalog i mit filsystem, således jeg ved hvad den kan gøre..

Det midste vil være at man fik en varsel, og mulighed for at blokere ved - adgang til fil system, eller program start (der er mange måder hvor dette ikke sker).

  • 0
  • 0
#7 Bjarke Walling

Det har potentiale til at virkeligt blive usikkert, fordi du åbner for code injection, og mange andre ting på stack niveau.

Sådan er det ikke nødvendigvis. Hvordan vil du f.eks. loade kode, hvis der ikke er en dlopen tilgængelig og den kørbare hukommelse ikke er skrivbar? Hvis der var en dlopen, så ville de selv have skrevet koden, som tjekker hvad du indlæser. Stakken og anden hukommelse er også markeret ikke-kørbar med et systemkald. Det lader til at være rimelig gennemtænkt.

De bruger to niveauer af sikkerhed: 1) Kode-validering (= begrænset instruktionssæt, som den patchede compiler tager højde for). Det gør i sig selv at du ikke kan kalde andre funktioner end dem de tilbyder. 2) OS'ets egen sikkerhed, f.eks. giver de den kørende applikation de laveste privilegier muligt. Niveau 2 er der, hvis det skulle ske at der var en bug i niveau 1. Læs deres research papers: http://code.google.com/p/nativeclient/wiki/Papers

Jeg synes det er en super idé, der giver næsten native performance (±5%), høj sikkerhed og nemmere deployment af dine applikationer. Selvfølgelig vil jeg altid vælge JavaScript og HTML5-API'er, hvis jeg starter på en ny ikke-performance-kritisk webapplikation.

Ultimativt, som jeg ser det, kunne Java appletviewer, Flash, Silverlight, osv. portes til NaCl og have gavn af den højere sikkerhed og nemmere installation. I den henseende forestiller jeg mig NaCl som en slags meta-plugin.

  • 0
  • 0
Log ind eller Opret konto for at kommentere