web design software portable
colt mcanlis: hello, everybody. welcome to another episodeof "google developers live." my name is colt mcanlis,and today, we're talking about a fantastictechnology inside of chrome known as the nativeclient project. now this technologydoes something that a lot of web developersnever thought possible. you see, it allows youto develop, distribute, and execute native coderight in your web browser.
but here's the catch. it's just as secureas javascript. now here to talk about thisfantastic technology today are some of thebrains of the project. i'd like to introduceour panel for today. hello, everyone. sitting next to me,we have erik kay, who's an engineeringdirector for chrome, as well as mollymackinlay, who's
a product manageron native client. and also at the end is davidsehr, technical lead for nacl and also one of theinventors of the project. hey, listen, thankyou guys for being here today on "googledevelopers live." molly mackinlay: absolutely. colt mcanlis: we have lightsand all sorts of microphones. hopefully, it'snot too big a deal. anyhow, so erik, tell us aboutthe native client project.
what is it? what's its goals? erik kay: well,as you said, it's about bringing nativecode to the web. so the question is, why? and why should youcare about that? well, it turns out thatthere's a lot of native code that's been written outthere, a lot of c, c++ code. and there's a lot ofexpertise, a lot of people
who that's theirbread and butter. they are developersin c and c++. there's a lot ofdevelopers, also, who need to use thosetechnologies because they target a variety of differentplatforms, some that require native code in orderto get on them. if you're targeting for theiphone, maybe you have a c, c++, objective-c app. if you want to getthat to the web,
you need technology like nativeclient to bring it there. colt mcanlis: andthat's going to help us sort of get performance. it's going to help us withsecurity and everything else, right? erik kay: right. portability,security, performance. colt mcanlis: interesting. now david, you'reone of the creators.
you were therefrom the beginning. so tell us a bitabout native client. what is it doingunder the hood that allows it to accomplishall these things? david sehr: putsimply, native client is about secure execution ofnative code in the web browser. so we do this by actuallychanging the compiler that you would use to producethe native code in such a way that it produces machinecode that can only
do things that are secure. the code that it generatesactually sets up something that we call a sandbox. and inside the sandbox, theapplication can run in a way that it can't gain access toexecution outside the sandbox, except through verycontrolled apis, and it can't have access toother parts of the browser that might otherwisecompromise security. colt mcanlis: so it'ssounds like there's
sort of a componenton the compiler side of the technology, as wellas a lot of machinery running inside of the browser, whichis kind of a complex pipeline. how much of this is actuallyvisible to the user? molly mackinlay: so froma user's perspective, when they navigate to aweb application that's using a nativeclient module, it's really a transparent process. they get all the benefitof the performance
we get with a nativeclient application, but they don't have to gothrough the classic plug-in install gesture that we'vecome to know and maybe not love quite as much about the web. so it's really much moreof a transparent process. they're not having to interactdirectly with a module. it just kind ofhelps them be more performant in theapplication itself. colt mcanlis: now i think youmentioned something interesting
there, the sort ofplug-in dialogue. this has sort of been the uneasysurface of the web community for about the past 20 years now. when you see that"please install," you're never reallysure if you're getting something awesomeor something malicious. but nacl attacks this, right? so david, how is nacl actuallyensuring this code is secure? david sehr: so we knewfrom the beginning
that we were going to be runningcode that came from the web. so this can be kindof a scary place, and the whole plug-inexperience sort of taught us that relying on the userto decide what was safe or what was not safe might notbe the best approach to this. so the approach thatwe took was-- actually, i talked a little bitbefore about this-- was we modify the compiler toproduce these sequences that are secure.
when the application and whenthe page actually starts up, we check, through somethingwe call the validator, part of the chrome browser,that this set of safety rules that the compiler producesare actually followed. if the application does notfollow those safety rules, the browser simply refusesto start the application. if those safetyrules are started, then while theapplication is executing, we're stillmonitoring and making
sure that accesses tothe operating system or to other browserfunctionality are carefullymonitored and secured. any time any of those, again,are violated, any those rules for access to operating systemor browser functionality, we will, again, terminatethe application. and all of this runs in additionto the existing chrome sandbox, which is used to securejavascript execution as well as native client.
colt mcanlis: so it's likethere's sandboxes in sandboxes. david sehr: that's right. colt mcanlis: it's justsandboxes all the way down is kind of what i'm hearing. defense in depth. colt mcanlis: so nowsome of these rules, most developers could hearthat and say, my program has to adhere to rules. that's super spooky.
what does that actuallymean for the developer? what kind oflimitations do they have in the developmentof their application? david sehr: so we looked atnative client in the beginning. and as erik talkedabout, we really wanted to bring native code,in general, to the web. we wanted to put as fewlimitations as possible on this system. so because of some of therules that we require,
if your application actuallyhas inline assembly code, or if you're using .s files,you may have to modify those to follow the safety rulesthat the validator enforces. if you're using a justin time compiler as part of your application,you're probably going to have tomodify that also to properly executeunder the environment. but otherwise, we'vetried very hard not to put any additionallimitations
on what developers can do. colt mcanlis: so when chromegets this package of bytecode, it has to kind ofcheck through it. what's interesting aboutthat for me, though, is that it sounds like maybeyou're not just limited to c++ to generate that code? david sehr: so we here at googlehave built the initial tool chains. we've built a c/c++ toolchain and have focused most
of our efforts on that. but the intent isthat developers can go broad and do otherplatforms, other languages. some of our developer communityhave already picked up on this. and in fact, we'vealready had ports of lua and python and ruby. there are peopleactively working on go and other languages outin the developer community. you can pick up someof this on "naclports"
or follow on ourdiscussion list. but c and c++, you have fullaccess to the pepper apis today. some of these otherones, we're working on developing and adding accessto the other pepper apis. but otherwise,language independence is a goal from the start, andwe're well along that path. colt mcanlis: andsee, this is the thing that i've loved about the nativeclient project from the start,
really. so i'm a badjavascript programmer. i like having controlover my memory access and understanding theperformance characteristics. and so this is somethingi like because i can bring this code andthese other languages. but to be honest, this is a bitof bucking a trend for the web development community. i mean typically,since its inception,
we've kind of been drilledinto this one mindset of single language,single setup. but what this isreally proposing is opening the doorsto just all sorts of new experiencesand new technologies. so erik, obviously this is big. what do you feel thatthe impact of this is going to be on the web overthe next five or so years? erik kay: well, i thinkyour example highlighted
one of the main changesthat this is going to bring, which is that thereare many developers who aren't great javascriptweb developers. they're c/c++. they use the languageof their choice. and this suddenlyallows them to bring their tools and theirtechnology and their knowledge and expertise to the web. so it's going to open up theweb to even more developers
with a lot ofexisting software that hasn't been brought to the web. think about this. there's a ton ofnative code that's been out there being developedover the last 40, 50 years. the effort to port that tojavascript is not trivial. these things havebeen vetted over time. so you think of crypto. you think of image filters.
you think of whatever. you don't want to gohave to reinvent that. so another interesting bit is tothink about the opposite user, the user who is aweb developer first and knows nothingabout native code. so how are they going togo take that native code and port it over tojavascript themselves? one of the interestingthings about native client is they might be able to justtake an existing built module
that somebody elsebuilt, somebody that had that expertise, andintegrate into their web. you want to add a gaussianblur to your image editor? great, grab this nacl modulethat does that for you. you don't necessarily have toknow anything about c and c++ to do that. you just grab the nacl moduleand integrate it with your app. colt mcanlis:that's really cool. i like the point you makeabout the vetted code, too,
because that makes methink that one day, i'm going to be able tojust included the mars rover navigation controller fromnasa right into my web page and use it for some crazy thing. now again, this kindof a big vision. how have developersbeen responding? is anyone really-- how hasthe uptake been with this? molly mackinlay: we've actuallyhad a huge developer response. we've had over 300 applicationsin the chrome web store.
these aren't justyour mom's web app. these are applicationsthat are really using the full processingpower of the computer, coming from reallyhigh powered platforms, things like "tomb raider"and "tank riders," coming from xbox 360 and ps3. we have "bastion," whichcomes from the steam platform. and not just games, thoughgame developers really use the cutting edge ofwhat a platform can do.
we've also seen goodadoption for things like cad modeling andsurgical simulations, where you're cuttingopen cadavers and teaching medical studentsall the different entrails that-- lots of crazystuff going on. but these are high poweredapplications that are really pushing forward what wecan do, which is wonderful. things like imageand video editing that really are taking advantageof everything native client
can offer. colt mcanlis: nowa couple weeks ago, i know that it was announcedon the chromium blog post sort of a new, i guess,flavor, if that's the right version of it,called portable native client or pnacl. molly mackinlay: "pinnacle." colt mcanlis: "pinnacle." tell me a little bitmore about pnacl.
molly mackinlay: so pnacl isanother flavor, as you say, of native client project. and what this does is introducesan intermediate representation between the language, the cand c++ the developer codes, and how a user runs thatnatively on their computer. and through thisintermediate representation, we can make surethat in the future, as new hardware is developed,we can continue to target all the different users' computers.
with the originalnative client project, you had to compile once forevery type of user computer you wanted to support. with portable native client,we don't have that problem. we translate on the fly, giventhe user's hardware type. this means that we're portable,as we say in the title. we're portable across all ofthese different architectures. previously, becausenative client was this architecture-specificbinary, we had to kind of gate
how we let that out. we needed to makesure that we were future compatible in the web. and so therefore, we putnative client modules in the chrome web store. with portable native client,you don't have that problem, you don't have that gate. colt mcanlis: so ilike what you say there about sort of future proofing.
i mean everyone--let's be clear here. the buzz in the tech worldright now is less on software and more on hardware. we've got new devices comingout in much different areas-- i mean, google glass and tonsof different android things. i'm personally looking forwardto google shoe, which is nice because that meanspnacl will support whatever silicone-basedpump ups. i remember the nike pump ups.
those to me were thepinnacle of shoe. like, when i cancontrol-- that was it. anyhow. so it sounds like there'skind of a big move here, from the static,architecture-specific compilation to this sort oftranslation that then gets turned into whatever theunderlying architecture is. so this sounds like a prettybig shoveling of code. david, how did thatgo with the engineers?
was this like a monumentaleffort, or was it pretty easy? david sehr: it's beena pretty big effort. so we started withthe gcc tool chain, targeting, as mollysaid, basically one executable platform at atime, so x86, 32, or 64. and with pnacl, wewanted that to be one platform-independent binary,what we're calling a pexe. so we started witha tool called clang, from the llvm tool suite.
and it produces bitcode. this bitcode, we madesome modifications to, to make it moresuitable to the web, to being hosted overtime in a website. and then once wehad done that, we had to look attranslators for all these platforms in addition. the translators themselvesto each one of the platforms are based, again, onthe llvm tool chain,
on the back endcompiler for that. and so we had tobuild one of those for all the supported platforms. and we've worked withsome people externally to add some more supportedplatforms over time as well. so it's been a lot ofwork in doing this. and also, the securitystandard that we set with nacl was an important part of this. so securing both the translationprocess and the executable code
is done through nativeclient as it was before. so it's been a longdevelopment effort, and the engineers, ithink, are very relieved. we're all really happyto be at this point now, and i think really coolthings are to come. colt mcanlis: and see,i remember actually reading some of theoriginal publications you guys did on this. and even back then, itwas really weird to me.
like, wait, this soundslike a huge amount of work. but it sounds like theteam has done fantastic. but then with the uptakethat has already been there, i mean, that's amazing. so now that you're moved onto pnacl-- or not moved on to, but now that thisthing has rolled out-- what's different for the user? if someone's developing anacl app versus a pnacl app, how does the user experiencethe two differently?
molly mackinlay:so for the user, when they're navigating to apage that contains a pnacl app, they still have that sametransparent experience using all of the featureset, the performance that we enablethrough native client. but now, pnacl applicationscan be embedded in a web page. you navigate to a tab. you use the benefits of pnacl. you get tired of it.
you're busy. you want to go and edit yourvideo in a different tab. you navigate away. and so now you have thiskind of seamless interaction, where you're getting pages thatare powered by portable native client, but they don't have togo through the same chrome web store installprocess that you had with the nativeclient executables. so it's similar, very much,from the user perspective,
but just more free-flowingin the web at large. colt mcanlis:that's interesting. and so some of theexamples you gave, though, they talkabout basically access to native resources. you've got high powered compute. you've got access to tcp,udp, and stuff like that. so i guess this iskind of the question that the community brings upa lot is, so, if i can just
browse to a random webpage, and they have access to some of these apis,erik, is this something i should be worried about? is someone going to turn onmy webcam when i don't know? erik kay: absolutely not. as david pointed outbefore, the security model for native client basically isexactly the same as javascript. so native client reallycan't do any more than what we allow normalweb pages to do before.
the main thing is just thecode that the developer uses to write thatand the performance that they're able toget as a result of it. native client is sandboxedfrom the underlying operating system. it can't directly access things. so it only accessesthese capabilities through apis likepepper that we've developed, whichbasically mirror
what's in the web platform. in fact, because of that, we'vebeen able to take pepper apis and create javascript wrappersfor them called pepper.js and expose thatto and script it. so people can even target pepperas a cross-browser solution for their applications. colt mcanlis: now see,that's really interesting. so you're telling methat-- because one of the big vocal points aboutthe native client technology
is that, sort of,it's chrome only. but you're telling methat targeting the pepper apis and then thispepper.js project sort of allows you to take yourapplication that you've targeted for nativeclient and actually get it into other browsers throughthe javascript route. erik kay: that's right. and it won't bequite as performant as if you targetednative client.
you might not be able totake advantage of things like threading, thingsthat aren't in javascript. but yes, you'll be ableto get the portability of cross-browser. colt mcanlis: andthat's really cool. it's a complex web,so i'm glad that this is sort of added to the project. so talk about thisa little bit more. when we talk aboutaccessing native resources,
one of the big waysthat developers have been approachingthis problem for a while has been withnpapi-based plug-ins. and recently, it wasannounced that we're going to depreciate those. so can you talk a littlebit more about that decision and whether-- is nacl a viablesolution for these developers? erik kay: absolutely. so as i mentionedbefore, nacl is
sandboxed from theunderlying operating system. npapi is sort of the opposite. npapi was intentionally designedto give web developers access to the underlyingoperating system. now what that means,unfortunately, is it means there's nosecurity guarantees of it. and so that means that ifthe plug-in has any security vulnerabilities, any web pagecan take advantage of those, can exploit those.
and as a result, it turns outthat plug-ins have historically been the number one source ofweb browser vulnerabilities. by closing up, bydeprecating npapi in chrome, we're getting rid of thatone last big security hole that has been sitting there. colt mcanlis: and so that wasalways the scary part, right? erik kay: that wasalways the goal. and it's why wedeveloped pepper. it's why we have built-in flashusing pepper and a pdf reader
using pepper. those are built into chrome sothat we sandboxed those first. and now this is justclosing down the others. and so if you're annpapi developer today, nacl can be usedas a replacement, as long as you're not trying toaccess un-sandboxed resources in the operating system. so if what you'redoing is using this as a way to bringnative code to the web,
then nacl is what you want. if what you wanted wasdirect, un-sandboxed access to the operating system,unfortunately, we're closing that up now. colt mcanlis: i thinkthis is the right thing. the web should be aboutgetting information and about trading ideas andfinding what you need. you shouldn't have to walkinto that area of being afraid to click on a link.
that's not the web you want. you want freeinformation exchange. so listen, this isfantastic stuff. we're talking aboutbig vision stuff here, changing securitymodels on the web and the way languages and the waydevelopers look at things. so molly, give us the vision. what's next for thenative client project? what's the six month,eight month ramp?
what can developersbe excited about? molly mackinlay:absolutely, colt. so we have some cool newstuff right out the door. we want to get things like c++exception handling in there. it's something that, talkingto our developer community, was something that they lovedabout the native client project and they want in portablenative client as well. and so we're working on,right out of the gate, adding that asquickly as we can.
a big thing that we're thinkingabout as we move forward is performance. we want the load time, whenyou load a native client and portable native clientapplication in a page, that translation time to beas small as we can get it. and so we're working ondecreasing that as we speak. another thing is the size of aportable native client module. we want to decreasethat, optimize every little lastmegabyte that we can
and make sure that that'sas small as we can get it. and finally, moving forward,one of the big things we want to work on is thedebugging experience, making sure that we're reallyreceptive to our developers, hear their pain points,and try and optimize for their developmentsuite and how they go about making anative client application, so that's as smooth andhiccup-free as we can get. colt mcanlis: that'sgood, that's good.
so it sounds like lots of goodthings have already been done. amazing technology,really trying to change the face of the web. and so we've gota couple questions that i want to getto here in a minute. but before i give the massestheir shot at you guys, i got a question,because this is really one of the things i want. when is nacl coming to mobile?
that seems like the perfectmelding of these two worlds. can you talk aboutthat, anybody? erik kay: so we've beenfocused on desktop. so it's a little early totalk about anything there. but stay tuned. colt mcanlis: ok. i like that. i'll take that. all right.
now the masses can gettheir shot at you guys. so let's take a lookat our questions that we opened upearlier in the week. so first one, arethere any plans to have portable nativeclient communicate to the browser via javascriptapis, like asm.js does, as opposed to thepepper plug-in apis? molly mackinlay: all right, soi can jump on this at first, and you guys can hopin with your pieces.
we don't currently have anyplans to have a native client application talkdirectly to javascript. i think erik talked a littlebit about pepper.js earlier on and how that ties up withthe javascript libraries. but for a nativeclient application, when you have native codethat wants to communicate, we really do want to routeit through a secure api that we can make sure it's notgoing to do anything malicious, and we can contain that access.
and so really, whatthe pepper apis do is connect up with thesame sort of back end fundamentals of thejavascript apis. and so as we add functionalityto the pepper apis, that sort of coverageof the apis available is going to increase. so we don't haveany plans of letting javascript-- directjavascript api access. david sehr: to build onthat just a little bit, one
of the design goalsof the pepper apis was actually to providea securable and smooth interacting with the browserexperience for plug-ins. actually, one of thethings that plug-ins-- erik didn't talk about thiswith npapi, et cetera. one of the constantcomplaints was, gee, when the plug-indoes something that ties up thejavascript and makes for an awkward experiencein the browser.
in the foreground, thejavascript is not responding. you get that nastylittle pop-up that says javascriptunresponsive or whatever. so ppapi was designedwith that sort of jank-free experience in mind. and also, having a separateprocess that actually you're running the nativecode in is yet another layer ofsecuring the application. we really like the factthat it's a separate process
and that if thatprocess crashes, it doesn't takedown the renderer. it doesn't cause some ofthe awkward experiences that people have cometo see with plug-ins. colt mcanlis: now answerthis really quick as sort of a follow-up to that. so the question was like, asm.jsinteracting with the browser. that's standardjavascript, right? it's not reallyaccessing anything
that javascript's not exposing. it's not doing magic, right? or am i mis-- david sehr: no, that's right. it's just a subsetof javascript. and currently, nacl actuallycan communicate back to javascriptthrough postmessage. so there is somecommunication there, right? colt mcanlis: interesting, ok.
good. so number two, are there anyperformance considerations that developers shouldtake into account when using pnacl versus the old,static compiled tool chains? david sehr: there are a coupleof performance considerations. some of them are longerterm, and a couple of them we will be phasingout as concerns over the next few releases. so first of all,portable native client
is intended to be portable. so if you've used assemblycode, if you've got .s files in your build, or you'vegot inline assembly code, these are things that areinherently non-portable. so if you hand-codedassembly code, you're going to needto find ways to do that otherwise or not pick portalnative client as the approach. a second and something we'reworking to phase out is, for instance, some of the thingspeople were doing with inline
assembly or with .s files wasaccess to simd instructions, vector instructions todo all kinds of things, appear in every successivegeneration of most hardware vendors' products. we're going to be addingsimd instruction support to the existingset of performance features of portablenative client over time. but at this point,if you're expecting to be able to usesimd instructions,
you'll probably need to wait. colt mcanlis: and soi've got to tell you, i'm glad that simd's coming,because that's really the thing that took my hair awayback in the games industry was trying to optimize theright simd instructions for the architecture and getthe right thing like that. so great. it's good that my bloodpressure can go back up again. my doctor's going toreally appreciate that.
next question. so how much effortwould take to port an app built using native clientto portable native client? david sehr: ithink the good news there is if you've alreadydone the work to port to ppapi, unless you're using just in timecompilation or inline assembly, the port should be verysimple, should be almost as simple as justswitching the compiler flag for yourmakefiles, or whatever
build environment you use. if you're using someof those features, then you will have to dosome work to get around that. colt mcanlis: and so mostof the nacl tool chain, does it insulate you from this? is it two separatetool chains, or how would a developergo through that? erik kay: well, in thesdk-- we have the nacl sdk is the set of tools youdownload to build native client
applications. and the sdk does its bestto insulate you from this. so it's just aconfig file change when you build to targetpnacl versus to target nacl. colt mcanlis: good. so it's pretty seamless, right? i mean, obviously, thedevil's in the details, but that's forprogrammers to deal with. so is there a publictimeline for allowing
native client acrossall web pages, not just apps distributedthrough the chrome web store? i think we've kind of tackledthis pretty well, right? erik kay: that isportable native client. colt mcanlis:that's shipping now. go play with itimmediately at this moment. that's good. i love seeing a question,and it's like, no, yeah, we're good there.
no curveballs there. here's another one. when will vector data typesand simd be supported in pnacl? david sehr: we're activelyworking on that at the moment. in fact, we'll publish somedata here fairly shortly of what we're proposingas the first set of things that will be supported. we don't have thedates exactly set yet, but we're workingon it as we speak.
colt mcanlis: add the"lower colt's blood pressure intrinsic." i'd appreciate that. final question that we'regoing to have for today because i think we'rerunning out of time. will the tcp socket apibe available to portable native client applicationsbeing served via a website? erik kay: so no, and there'sa good reason for that. as we mentioned before,the whole point of this
is to have the samecapabilities as web pages. so if we come up with asecurity model for the web that would allow us to havetcp exposed to javascript, then we would expose itto portable native client. but since we don't, sincethe security model of the web doesn't allow thattoday, we're not exposing any additional featureslike that to portable native client. colt mcanlis: nowdo they have access
to some of thesefeatures-- because i've read the documentation--in standard native client, right, distributed throughthe chrome web store? erik kay: well, ifyou use packaged apps, you can use portable nativeclient or native client. and then, yes, youcan use the packaged apps apis to donetworking there. but since the questionerasked about on a website, as opposed to--
colt mcanlis: ona website, yeah. erik kay: in a website, no. in a packaged app, yes. colt mcanlis: awesome. well, hey, listen,thank you guys so much for taking the timeto talk about portable native client today. it's an exciting product. i'm really glad to havebeen associated for so long.
so hey, if you'rewatching the stream, and you want to know moreabout portable native client, make sure you visit gonacl.com. that's going tobe the place where you get all of yourinformation, stay up to date with announcements,news, demos, everything. hit that. my name is colt mcanlis. thank you for staying tunedfor another great episode
of "google developers live." thanks.
Tidak ada komentar:
Posting Komentar