I am not sure about the real use cases. For learning development will be useful since you don't need to do a more complex interaction between the browser and your server.
I do wonder how qemu compiled via emscripten would compare though...
its a waste of time trying to figure out what his superior mind could be thinking :)
I am not a vim user, but I guess this gets close:
See this: http://haldean.org/docstore/?vim-problems .
$ gcc hello.c -o hello
I've learned that attention is more important than appreciation. When you introduce a project, it's better to get people thinking about it, nitpicking and even questioning the point of your project, than to get a few replies of "Nice!" and be ignored in the long term.
I've noticed another thing: most things of which I'm initially slightly dismissive fail to reach any success, but the things I'm very dismissive succeed. I've seen products get very harsh feedback and, a few months later, the products were successful, had better user experiences, and their users loved them.
But the visceral reaction to his project may have to do with the kind of expectations we have from web use vs. installed software.
I know some people install anything they happen by, and will try all one-line command line installs and random .pkgs they find, but most people who care about security are wary of installing closed source software from a not-very-known third party, or run arbitrary code in a virtual machine.
HN can be very negative sometimes, and seeing angry or snide comments makes me sad too. You can give concrete, actionable advice and feedback without being an asshole, and no, that's not pretending to be nice, it's simply not going out of your way to be rude. But if you take everything into account, it's better to get discouraging comments from HN and filter them for real information than to be ignored.
I think one of the main reasons why projects like Arc or NaCl started is that the web is that the web is not a very good platform. It was created as a platform for documents, not for apps. I wish there was a platform having advantages of both web and native platforms (Windows, Linux, Android, etc.).
In this culture you never quite know what people really think. Hacker News is the opposite. You will get (mostly) constructive feedback from (mostly) smart people for free, that you could not get elsewhere if you were to pay money for it. Don't come here to stroke you ego. That said, if you get positive feedback you know it is for real and not just out of politeness.
Sometimes however, people could package their criticism a little bit better or self-censor if it's not constructive.
 I don't claim to understand Thai culture. In some cases I may be the extreme opposite. Where sometimes people say things to each other that would be considered outright insulting in the West to strangers.
* I don't think total honesty is always the best amount of honesty, in some situations it's better to twist the truth slightly. I see it as a tradoff between honesty and politeness.
* You can be honest in many different ways. I agree that some of the comments here could be rewritten to be less depressing for the author while staying honest.
A 3-minute video demo (with no editing) is all Arthur needs to get the point across that this is the next big thing. Show the public what I've seen.
I like HN for its news, but am not so sure about its moderation policies, muchless the sometimes-hypercritical attitudes.
I hope the author continues working on the project.
I don't trust Virtualbox to be especially resilient to attacks from malicious VMs. Chrome's sandbox is well-audited and (overall) is sound. A virtual machine host has a much larger attack surface, and generally doesn't assume malicious guests.
1) Is Chrome only.
2) Can't spawn processes or subprocesses.
3) Can't open raw UDP or TCP sockets.
4) Requires apps be ported.
Argument #1 only makes sense if you support a lot of platforms. Right now you only support Mac OS X (according to another comment).
The number of people who use Chrome globally is larger than the number of people who use Mac OS X. Ergo, if you used Native Client and chrome, you'd be more ubiquitous.
Regarding sockets: chrome supports UDP and TCP:
If there's one platform to build on that is going to cover a large number of people and give close to native performance, it's Chrome+PNaCl. I wouldn't tell everybody to drop what they're doing and adopt that target (it's not ready yet). VMs in the browser are pretty nascent, too.
Virtualbox in specific might be a vulnerability compared to other virtualization systems, though.
>Chrome's sandbox is well-audited and (overall) is sound.
So why does it fail during the annual Pwn2Own competition? You and I have different definitions of 'sound'.
Also coming back to NaCL.. NaCl's code verifier has never undergone large scale deployment/testing/real world use from millions of users/apps.
It's completely backwards from my personal usage of the Internet; I get away with browsing online using a Penryn-era Pentium, a ARM-based Chromebook, and/or my Galaxy Nexus precisely because the majority of processing costs are offloaded on "traditional" websites rather than on the browser doing the rendering.
But if this means that application developers won't have to recompile every application under the sun (like, say, ffmpeg or Audacity) to run under asm.js or PNaCl, then I think it could mean that we could skip a decade or two of having to reinvent the wheel.
On the other hand, this feels suspiciously reminiscent of ActiveX, so I suspect you're going to have a hard time convincing people to adopt it if the security diehards warn you of running arbitrary code on your machine (even if it is in a sandbox).
I have not found this to be the case. I find that most websites take a LOT of processing power to display - loaded with flash, scripts, video, etc.
A lot of sites are not really guilty as it is the ad network content inline with the site that pulls all of that computing power, but other sites (boingboing, for instance) generate a lot of CPU use just on their own.
And it gets worse all the time. I suspect that whatever gains we make with efficiency of HTML5, etc., will be immediately consumed by things like the OP is building.
I have a 5 year old macbook air that absolutely does not need to be replaced. Except that I can't have more than 10-12 browser windows open before it's pinwheel city...
Granted, I find myself enabling Adblock by default on most sites because most ads nowadays are annoying Flash pop-overs. Back in the day, the Linux implementation of Flash didn't support making the Flash embed transparent, so I had to go into Firebug/Web Inspector and delete the embed/object tags entirely just to read the page. While I think that particular bug has been fixed, even today, most of the Chrome tab crashes I run into are still caused by Flash crashing.
It really bothers me how much stuff depends on Flash still, whether it's putting something in the clipboard from the browser, or just Google Hangouts or Facebook deciding to play a "ping!" when a notification goes off.
I've also noticed that the Chromebook and Chrome for Android will deallocate tabs that I haven't used recently and reload them when I switch to them, which lets me have dozens of tabs "open" on devices which are otherwise only capable of handling three or four tabs at once. Of course, this is only reasonable because of "high speed internet"; I remember being on dial-up in the late 90s running Internet Explorer 4 and opening ten windows in the background so that the pages would pre-load in the background while I read the current page.
I try to keep my network secure, but e.g. Cisco/Linksys E3000 hasn't received a firmware update in a long time, and it has known exploitable bugs - right now, the fact that it is only accessible from inside the NAT, and that webpages can't do arbitrary accesses is what keeps all those E3000s from being exploited.
(My E3000 has been running dd-wrt, so it's not vulnerable to those problems; but I had to manually upgrade the dropbear ssh because of vulnerabilities - latest official dd-wrt for it is still vulnerable)
I don't see a lot of difference - for good or for bad.
Is it 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16? I guess that would cover 99% of local networks.
I wasn't aware virtualbox has firewalling at the virtual NIC level - my 4.1 doesn't; It's either host-only, bridged, or nat - of which bridged is unlimited, host-only is useless, and nat cannot (as far as I can tell) be firewalled at the virtual NIC level. So how do you do it?
A VM can be put on its own VLAN with a traffic routed through a secure firewall. I don't think Arc is as doomed to be insecure as many are claiming.
It isn't doomed to be insecure, but its security, portability and convenience/usability have a nontrivial tradeoff which is ignored by the original description. If it's portable and convenient, it is likely going to be lacking on the security front.
The original Cisco firmware for the E3000 also has vulnerabilities, which were never fixed.
I had an idea like this, but instead of a VM, using a client-hosted server. The big concern I couldn't solve was security. If you have, say, Peggo.. What is to prevent other websites from being malicious and connecting to your locally-installed Peggo VM and trashing it or otherwise exploiting it?
If Arc is installed, you're good to go. Everything just works. If Arc isn't
1) arc.js transparently falls back to the cloud and runs the Arc app on a
server. The user doesn't know the difference.
2) Upsell the user to install Arc.
> What is to prevent other websites from being malicious and connecting to your
> locally-installed Peggo VM and trashing it or otherwise exploiting it?
The web server running in the Arc app can check the Referer header to verify the
request came from a permissible domain.
As usual this goes back to one of the standard rules of server security: Don't trust anything that comes from the client.
Taking a look at it from a different angle, even in the case of the legal framework for names - trademark - having Arc the language and Arc the VM thing would be fine.
The truth is, if you don't want people to collide with your name, picking a 3 letter common word probably isn't the way to do it.
Names are hard. :/
I just found out about this language thanks to the link.
More importantly, according to the TIOBE index, Arc programming language apparently isn't one of the 50 most popular languages.
I'm pretty sure the heat death of the universe will occur before all names are used.
Arc passes the highway test with flying colors. Imagine driving down the highway when an 18-wheeler thunders past. If you remember the name stamped on the side of the corrugated shipping crate, it's a good name. 'Arc' in a Neo-grotesque typeface next to an iconic logo on such a shipping crate is as good as burning Arc into your retina with a megawatt laser.
Edit: just realized that was Ark with a K. My bad.
It seems like full blown x86 PC hardware emulation is overkill for what you're doing. As others mentioned, NaCL isn't really the right abstraction layer either.
Perhaps a stripped-down version of VirtualBox could be turned into a "standard" browser plug-in and paired with something like Docker, so you're just running a minimal container image.
That story reminds me of the last time I tried to compile a blackberry app on my mac a few years ago :
Java VM running my code within a blackberry simulator running inside of a windows XP VM on top on my mac OS.
Where will it end ?
Seriously though, I was more excited when I thought it was about running Linux inside the browser. Personally, I have no interest in installing an extra VM on my system just to make your development easier.
More than just any language - any Linux software.
I don't have a Mac, so I haven't tried out your demo yet, but ideally you should make this work like genymotion, using the existing VirualBox install in headless mode. This would also make a much quicker install option for existing vbox users. Hopefully you can avoid the mistake YouWave made of interfering with an existing vbox installs.
It will only work with OS X 10.7+ though.
should also be great for downloading torrents in a sandboxed environment.
Documentation for Arc and arc.js will be available shortly.
> Is this going to be open source?
Arc will not be.
Perhaps Peggo once Arc has cooled.
>Arc will not be
The project is certainly interesting and I respect your right to license it as you will, maybe for commercial reasons, but a closed source black box with relatively low-level access (like Java) makes me uncomfortable.
I may be alone in my aversion to browser plugins, but most of what Arc could be good for would be better solved with actual native software. See Peggo: A GUI app for OSX with just an input box for the YouTube URL and a choice of where to download the MP3 file would be a better solution for that problem. On the devices where Peggo would be useful (mobile phones, for instance), Arc can't be used.
Some things just shouldn't be web apps—I say this as someone who's never made a native app.
> Arc will not be.
Are you using a commercial license for VirtualBox then (and not the default GPL)?
vim, emacs, anything that runs on Linux.
It's too bad that "Virtual Machine" means so many things. Maybe someone has more info on this, but I understand that it was Java who first called their language runtime a "Virtual Machine". Partly motivated because they wanted to create an actual physical machine that ran Java (kind of like Lisp machines). Nowadays with type 1, type 2 hypervisors, and jails/containers/zones, and every programming language on the planet calling their runtime a VM, I'm not surprised that people are getting confused.
Also this sounds good for just 1 App, but what happens when you try to run more VMs than you have physical cores? And/Or memory, this would directly affect the host.
The VMs are just processes of the host OS. They're multiplexed over available cores, same as ordinary processes.
There is a lot of awesome stuff you can do with "local, short-lived VMs". I've thought about how to do this securely (using hardware) -- an awesome end state would be letting a data owner with local data, and a code author in the cloud, both mutually distrustful, allow data owner's data to be processed by code owner in a safe way mutually agreed by each. You could do this with trustworthy computing, or a dedicated trusted third party environment on the net, or maybe with MPC someday.
Not sure if Linux or x86 vm is the right level of abstraction; maybe the "peggo" level where you have a higher level might be better for users. Maybe even something like Docker (but on the client)?
People who need solutions like peggo needed can use the Java applet a portion of their users already have, or they could use asm.js and convert their binaries into JS that runs in the browser. Months ago, I saw a post here where I ran a Qt desktop GUI in my browser that was nothing but JS.
I don't see any real projects / sites that would use Arc, because it would be a lot of friction / poor UX for their users, and it is simply unnecessary because there are already usable solutions to client-side computing.
Arc uses a desktop virtualisation tool to run arbitrary code on your system. The manifest provides a set of packages to download and install and a series of commands to execute inside the downloaded Arc VM image. A malicious server could use this to run an app that attacks your network, the host, acts as a bot, anything.
I'm assuming that in order to run native code like this, there's no sandboxing. I've seen no mention of it. There's a reason you can't run native code in the browser without restrictions, and this bypasses all of that.
1) Escape the virtual machine sandbox.
2) Denial of service of host resources.
3) Attack network services.
For 2), virtual machines also provide strong protection from the denial of service of host resources. Virtual machines can be restricted in memory, CPU, and device use while running. This occurs routinely with virtual machines provisioned on servers.
Network services, 3), are the largest attack vector not protected by encapsulation within a virtual machine. One weapon virtual machines do posses, however, is complete control over the virtual NIC. Every packet sent or received can be inspected, modified, or discarded.
Arc's network policy is not carved in stone. There is nothing preventing Arc from adopting a same-origin policy, like browsers. Perhaps it will.
That's not true. You've identified 3 avenues of attack, there are far more. That's what threat modelling is for. It does not appear that this project has properly considered the threats associated with the attach surface area, but lets look at these three.
> For 1), virtual machines provide strong, hardware supported isolation of the host. They can't access the filesystem, resources, or hardware of the host, only their own.
Not true. The isolation isn't as strong as you think. Most virtualization software provides avenues to share information between guest and host. Code is still executed on the same hardware. Virtualization isolation is extremely hard to do correctly, and even the pros, have got it wrong in the past. Even Java's had sandbox issues, as has Google Chrome most recently. It's believed that VirtualBox may have been affected by this bug, which is in Intel's 64-bit CPU architecture, not the product. I say may because it's really hard to confirm without sitting down and writing an actual exploit for the bug.
> For 2), virtual machines also provide strong protection from the denial of service of host resources.
That's not true. Yesterday I was testing a simple windows fork-bomb type attack (putting %0|%0 in a bat file to be precise) and the VMs were all suffering, as was the host. You can limit available resources in a VM, but that's neither here nor there - what happens if you open multiple VMs? How will the virtualisation react?
> Network services, 3), are the largest attack vector not protected by encapsulation within a virtual machine.
They're not the largest attack vector by a long way (arbitrary code execution by virtualisation escape is the most significant attack vector), but lets talk about netowrk services. Just because packets could be inspected, modified or discarded doesn't mean they are. If I deploy a malicious VM to your computer and you start it, that means I'm executing the code of my choice in a virtualised environment on your computer on your network. Nothing will change that. You can sandbox parts of it to reduce what can be done to other components and it'll be down to the integrity of the isolation and sandboxing, but unless you start removing instructions, arbitrary code is exactly what my VM executes on your system.
Architecturally, it's a bad idea. If you were meant to execute native code on a system from a browser, it'd be supported across multiple browsers and OSes as part of a spec. Even Native Client (NaCl) has it's detractors and has made mistakes (possibly addressed in Pepper), yet seems to most likely do enough to support what this project proposes to do.
 - http://www.cupfighter.net/index.php/2009/07/blackhat-cloudbu...
 - http://seclists.org/fulldisclosure/2010/Jan/341
 - http://www.kb.cert.org/vuls/id/MAPG-8TVPQL
 - https://en.wikipedia.org/wiki/Google_Native_Client
I can understand the dream and the goal but it doesn't stack up. It's dangerous stuff. Stop it.
I think I missed that. Can you point me to the bit in the source code where the sandboxing is so I can have a look and assuming it's good retract any claims about a lack of sandboxing I may have made?
Did you try the existing solutions for running those languages in the browser? (pyjamas, emscripten, etc.)
Were there specific limitations that prevented you from using them?
From the link:
> This was painful, expensive, and inefficient. Clients are more than capable of transcoding video; the problem is browsers aren't.
> Browsers can't run Linux software like ffmpeg, can't run Python, can't reach native performance, and can't make cross-domain requests.
Depending on exactly what ffmpeg is being used for, the legality of distributing codecs is going to be an issue. Virtualbox VM overhead is non-zero compared to "native performance" anyway so I'd like to see numbers on this versus running in a browser. Cross-domain requests can be an issue, but CORS headers can work (unless he does not control the site in question, or they don't want people making these sorts of requests).
From the post it sounds like this was a YouTube scraper, which basically means that there's no way he could legally be distributing ffmpeg + codecs needed in any case, and also this is against YouTube's ToS of course.
It is on the client, I believe. Literally runs VirtualBox on the client side.
ffmpeg definitely can be run in browsers, as can python. How close to native performance needs to be measured in each case, of course. I'm curious if they compared the performance and found it lacking, or just didn't try the browser options at all.
Right, sorry I meant the situation that Arc was intended to remedy (from the site):
> I want to build apps in Python and C and ship them in the browser. I can't.
> I ran full steam into this problem when I built Dirpy, a web app that records MP3s from YouTube. I could have built a native app in Python and C, but to test, distribute, and maintain builds for every OS is a total nightmare. So I built Dirpy as a web app, did all the work on servers, and paid $25,000 every month in hosting costs.
>> Browsers can't run Linux software like ffmpeg, can't run Python, can't reach native performance, and can't make cross-domain requests.
>> ffmpeg definitely can be run in browsers, as can python. How close to native performance needs to be measured in each case, of course. I'm curious if they compared the performance and found it lacking, or just didn't try the browser options at all.
Totally agreed (I was quoting the site there, to be clear) - I am a huge fan of emscripten's approach, and I think it would work really well for this use case. VirtualBox is overkill here, and getting people to install something like this is a huge barrier.
However I still think that it would not be legal to distribute the codecs one would need to do this, and it'd also be against YouTube's terms of service.
Of course it is as secure as the virtualbox Sanbox is, but some variation of this statement would also be true for Flash, for Java and a host of other technologies that despite whatever flaws they had did allow a lot of interesting things to be built.
I am here musing, trying to come up with something nice I could build once the Linux-packaged version is made available...
There was a very interesting tech scene that many don't know about around MMO cheating, especially Runescape.
The Installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance.
Qemu would seem to be the better choice.
I didn't click ok
Maybe 40MBs is ok… :D
"Arc is only packaged for OS X right now. It will be packaged and available for Ubuntu and Windows soon."