Aetheric Research, Ltd.

Judging from the search terms I’ve seen coming in, the information that people want is:

1.  How do I make it happen if it’s not connecting to the authentication server properly?

Attach to a wireless access point and go to https://quickaccess.verizonwireless.com (or to the string found in your modem status).  Make sure that your 3g connection is enabled, as the scripts there require certain things from the modem that they can only pull when it’s enabled.

2. Modem status?  Wat?

Hit ctrl-alt-t to get a terminal.  Type: modem status

This will get you a bunch of information, most of which is irrelevant unless you’re troubleshooting a specific problem.  The lines you’ll be interested in are the MEID (if you’re trying to activate over the phone) and your payment_url (which is going to be the quickaccess one mentioned above, with some additional information after it–use that if generic quickaccess doesn’t work)

Enjoy!

A tool as powerful as the Native Client promises to be will have equally powerful misuses.  As discussed yesterday, NaCl is an extension of the functionality of Chrome, allowing it to act as something closer to a general hypervisor than ‘just’ a browser.  To understand the security implications of running generalized code in such a manner, it may be instructive to look at the Java VM.

The Java language was invented originally as a means of providing additional functionality to cellphones–before smartphones existed.  It spent much of the late ’90s being pushed as a ‘platform independent’ programming language–any platform that could run the Java Virtual Machine could run any Java program without issues.  This independence was at a much lower cost to speed than that of competitor interpreted languages; Java had a hybrid approach that rendered human-readable program instructions into an intermediate state between the human-readable instructions and the machine-readable code that compiled programs end up in–something called ‘bytecode’.

These bytecodes execute inside a sandbox environment set up by the JVM; much like the NaCl, the JVM seeks to isolate running code from touching parts of the machine other than what it is authorized to access–though unlike the JVM, the NaCl leverages the thread isolation offered by the Chrome environment to prevent inter-thread communications to (if I analyze this correctly) a greater extent than the JVM does.  

This sandboxing model is fairly safe as-is, though like all systems it is exploitable.  In the case of the JVM, exploits appear to focus on memory corruption, attempting to cause the virtual machine to execute instructions that will cause information to be written outside the authorized memory stack, and thence to execute instructions that have not been approved for execution by the trusted environment.

The exploit can be handled in various ways; one paper gives the possibility of loading a specially crafted program and waiting for a memory-corruption event to allow for the code execution to happen.  Existing vulnerabilities (that have been patched in the past) include corrupted image files and overflowing calendar modules.

The same vectors of attack are likely to happen inside NaCl, with similar effectiveness–that is, fairly ineffective unless some fault in the vetting of the code to be executed can be found.  With open-sourced projects, such faults are unlikely to persist, given the number of eyes (especially those with a vested interest in ensuring the project’s success) examining the code, as well as the well-publicized monetary rewards posted as bounties for bug reporting by Google.  Still, it would be a mistake to assume safety–as always, the basic rules will still apply, and a new vulnerability in the process could be found at any time.  

The ChromeOS (and by extension the chromium browser) is to include the NaCl–the Native Client.  Condiment puns abound, given that NaCl is also the chemical formula for table salt.  NaCl is an implementation of a means to run machine code inside the framework of the browser, granting webapps a significant performance boost.

The Chrome paradigm is one of multithreaded sandboxing: each thread (more or less synonymous with “browser tab”) has its own area of memory and its own slice of processor time to work with.  In this model, the browser tabs are like very limited virtual machines, and the parent browser process much like a hypervisor–individual meltdowns of machines are (at least in theory) irrelevant to the operation of the other threads, and can be cleaned up and removed by the parent process should it become necessary.

NaCl takes this a little bit closer to a real VM setup, in that it offers a way to run code on the ‘bare metal’–that is, using the native hardware of the user’s machine, rather than working via a javascript implementation like current HTML5 apps.  

The sandboxing requirement is still maintained, in that the Native Client only (theoretically) allows code to run that will respect the limits of the sandboxing system–this is important, given that running code directly allows for a great deal more leeway and leveraging of resources than execution inside a javascript interpreter.  The NaCl executables are, for all intents and purposes, the same kind of machine code that you would run directly on your computer, and have all the associated advantages (speed, especially) and disadvantages (ability to cause harm) that this entails.

One intended use for the NaCl framework is for cloud apps to export a portion of the processing load to the client systems, to enable a better user experience.  Games, especially, will benefit from the Native Client, given that the graphical rendering calculations are rather more intensive than those required for standard web apps.  Statistical and rendering applications may also see a benefit from the increased performance available under this model.

Another is for webapps to extend parts of their functionality to the client machine in order to limit the amount of data required to be sent and received–an important consideration for people who may be on slow or capped internet connections.  In this model, the NaCl app could be downloaded once, and thereafter traffic to and from the hosting server would be limited to user provided or requested data–all the processing and rendering of the information could happen locally.

One usage that has not appeared in the official documentation, at least as far as I’ve seen, but seems as though it would be appropriate would be an implementation of the BOINC client–being able to run folding@home, seti@home or any of the other distributed computing projects inside a browser tab could result in significantly increased uptake.  Given that the format of the NaCl executables is fairly close to that of an existing BOINC implementation, a comparatively limited amount of development would be required to adapt it to this platform.

NaCl offers significant opportunities to developers; much can be done with native machine code that cannot be effectively done with javascript or other interpreted languages.  It also offers significant dangers–of which the developers appear very much aware.  On the whole, though, NaCl appears likely to be able to provide a much improved user experience, with the potential for significant improvements for developers–with NaCl, much like Java before it, they’ll be able to write one program and run it on any platform, rather than having to target a specific OS.  Unlike Java, which handled sandboxing by implementing a sort of virtual machine and compiling code into a special format to run on top of it, NaCl allows the execution to be handled directly by the processor–this should allow NaCl applications to run much faster than the equivalent Java apps.  

Native Client is still very much experimental, but can be enabled for users of the Chromium browser by going to the about:flags page, clicking the ‘Enable’ button under the Native Client option, and restarting your browser.  You can test out some of the functionality with the examples found in the Gallery page.

Running software development projects ‘in the cloud’ has several barriers that traditional development projects do not face.  First, regardless of the project, you’ll need someplace to keep the files when you’re not working on them; most “cloud storage” currently is biased towards either backups or towards documents; obtaining a URI to work with a project from one cloud on a service hosted in another cloud is rather like pulling teeth.  This barrier can be overcome with some careful work (or a solution that I’m currently developing), but in the meantime, ShiftEdit has some useful features.

ShiftEdit is a PHP editor with the typical syntactical highlighting, automatic indenting, and paren-completion that developers have come to expect from traditional IDEs.  It has a clean interface and works well enough on the CR-48 to be worth using.  Most critically, beyond the FTP retrieval of object files that other competitor products provide, ShiftEdit allows for SFTP and SVN.  

The SFTP access can be leveraged to obtain files from any server that you have SSH access to; read/write may be a little slow (depending on the server) but it works well enough.  The SVN access does not yet support SVN+SSH, but the developer assures me that this capability is in the works.

ShiftEdit is still very much in active development; the developer takes the time to respond to queries about the status of the project and to trace down any errors that may occur.  

Things I like: clean, useful interface; built-in versioning; under active development

Things I dislike: not enough documentation

Things I would change: adding SSH+SVN, perhaps adding a little storage on the server for small projects

Edit:  Ok, make that VERY active development.  It looks like SSH+SVN was added while I wasn’t looking.  Even more recommended now. :-)

It is perhaps a testament to the orderly and efficient working of the adblock extension that I only just noticed that I had not yet reviewed it.  Sitting quietly in a button up in the corner, Chrome Adblock filters out advertisements across the web quietly and efficiently.

The Adblock extension comes with a fairly useful set of configuration tools.  You can whitelist domains that you wish to support on the third tab of the settings page; you can select your preferred block lists on the second page; and on the first page you have the option to show google text ads–to be encouraged, given that they’re unobtrusive and not annoying–and to block ads within youtube videos.

This last is not fully functional-yet-but as the extension is under active development, that should move out of ‘beta’ status within a few versions.

Whitelisting is easy to accomplish; there’s the option to put in the filter by hand, using the same format as the popular firefox adblocker, as well as a ‘wizard’ interface to automatically generate the rules for individual domains or subdomains.  

Blacklist lists, on the second tab, are easily managed as well; a series of checkboxes allows them to be selected individually, and a button is provided to select all of them at once.  

The only other feature of note is an optional context menu entry, allowing specific blocking of an ad, of all ads on a site, or whitelisting of a site.  

All in all, this extension works quietly and effectively, and is nearly invisible to the user after some small initial setup.  It provides the option to enable ads for sites you wish to support quickly and easily while blocking most of the known annoyances, “weird old tip” or otherwise.  

Things I like:  It works, it’s unobtrusive, and it’s easy to set up and ignore.

Things I dislike:  It does not yet make toast.

Things I would change:  Frankly…nothing.  It does exactly what I asked for.  Send this guy a donation; he’s doing it right.

An extension to leverage the use of URL shorteners, ViewThru allows the user the functionality of finding out where a short URL is pointing before following it.

URL shorteners have become popular more or less concurrent with the rise in popularity of Twitter:  the character limit that twitter imposes makes it a challenge to both tweet a meaningful URL and to provide some form of commentary upon it.  As such, services such as bit.ly have become popular, taking a short domain name and a bit of redirect scripting to develop a means of linking to content in as short a form as possible.

Unfortunately, this shortening obfuscates the destination URL, allowing for ‘Rickroll’ hijacking or potentially direction to other undesired–and potentially malicious–content.

ViewThru uses the API provided by most of the major URL shorteners, and provides an expanded view of where the URL is pointing.  It does this by, when the user hovers their mouse over the URL in question, showing a tooltip with the relevant information.  Conveniently, this not only works on websites but within other chrome apps–like, for instance, TweetDeck.

It’s a very simple functionality, but a very convenient one–not only does it enhance safety, but it saves the user from having to go through the redirect themselves to decide whether or not the URL is worth following.

Things I like:  Invisible operation except when needed; universal functionality within the browser

Things I don’t like: the hover window stays just a little shorter than I’d like

Things I’d like to change:  Longer hover window duration, slight delay before the window appears so I can mouse past a link without getting the popup

Yesterday’s post noted that the 100MB free quota appeared to be automatic with rollover to the new month; not so with the paid coverage–somewhat obviously; the paid coverage is intended to be month-to-month.

A query to Verizon Wireless returned an answer that, no, there was no way to reactivate the paid coverage while still within the purview of the free coverage, so the hassle of activation began again.

An important note: while the customer service number provided by the page appears to connect somewhere where there are clueful people–the lady with whom I spoke is only the second technical-support-type representative with whom I’ve ever been able to work effectively on the consumer side of things–they cannot activate the device there at this time; apparently they do not have the access level required to do so.  

When calling, if you do not have a security code set–I did not; if there was some means of setting it previously, I missed it–they’ll want your MEID in addition to your phone number.  To find that, hit the Wrench and call up the settings menu; select the Internet tab, and find the ‘Options’ button next to the Verizon connection.  The MEID can be found under the ‘Device’ tab.

There is a workaround for being unable to grab a connection (two, actually; sometimes you can get past the timeout window if you reload quickly, though that may just be having the luck to catch the server in a usable state):  when on a wifi (802.11) connection, connect to https://quickaccess.verizonwireless.com.  While you canot get usage information when on wifi, the activation page will still work well enough to stick in your credit-card info and get your 3g connection running again.

I’ve filed a couple of bug reports with Google for this issue already; activation is far too much of a chore, and so long as it takes more than a couple minutes to activate a month, the OS won’t be ready for primetime–users aren’t going to want to call up a call center unless they have to, and I have no doubt that when the OS goes live, the quality of the support staff will decline sharply.

Speaking of usage information, I may have found out how it’s accessed; I’ll have to see about writing an extension to display a meter of some sort.

An update regarding the ChromeOS revision that dropped last week–

Taking a look ’round the OS, outside of the features mentioned last time, there have been several other bugs that have been fixed.  Video seems to have smoothed out a bit, though I’m not sure if that’s actual or just perception–going to need to investigate that one further before I declare it ‘squashed’.  The filesystem has been made functional; both the USB port and the SD card reader can be made to read data–a big plus, especially if I’m going to be migrating legacy data to “The Cloud.”  Additionally, the issues that I’d noticed making SSL/TLS (the ones marked “https” for the nontechnical amongst you) connections last for longer than a couple minutes appear to have been resolved; GChat and GMail remain connected when on the wifi for at least a couple hours; this functionality was tested on both open and protected access points, including behind a NAT–I’m read to call that one fixed, as well.

Interestingly, the free 100MB automagically re-upped when the paid chunk ran out, which is handy; I’d read before that I’d have to re-up it every month by hand, which seemed rather antagonistic–if the functionality’s being offered free, then what’s the point in rubbing my nose in it every month?  I’m glad to see that VZW opted to allow automatic refresh here; it makes for a much better customer experience.  I’m still dreading the inevitable purchase page that’ll come up when I run through this 100MB, though–and I’m a little irked that my careful hoarding of my purchased GB had ~100MB left over from it at the end of the month; “rollover bytes” would be kinda nice to have.

There’ve been a couple of new bugs that have cropped up, of course–every once in a while, flash seems to go kaput; I’ve not managed to figure out anything consistent regarding that one.  The ‘home screen’–the tab that pops up with your app selections–seems to have corrupted text on the captions for the large icons….sometimes.  It’s not very consistent like that.

Also, the ‘known issues’ page doesn’t really have any change; there’s no real indication of versioning or progress reports on any of the ‘known issue’ bugs. 

On the whole, though, the user experience has improved; if this pace continues, then there should be a pretty reasonable OS for commercial distribution inside of six months–meaning that if they plan to release this in the spring, they’d better get a move on lest they end up looking like Microsoft or something.

When you live in the cloud, it’s helpful to have a portion of cloud to stash your stuff.  Ge.tt will fill that niche, at least temporarily.  

Ge.tt provides a dropbox service where users can stick files for sharing to other users.  Much like other noted dropbox services (rapidshare, etc.) there is no official search engine nor any external search engine capability provided; the only way to find a file is when someone tells you it’s there.  The interface is clean and simple; the sharing function is usable, and there’s really not much more to be said about basic functionality.

Much like some pastebins, inactive files (those that aren’t accessed on a regular basis) will be removed and inaccessible after a certain period of inactivity.  Registering for an account–which is free–will lengthen this time.  

One of the features mentioned is the ability to count how popular your file has been by counting visits and downloads–which is as advertised: it counts visits and downloads, cumulatively, since the datestamp marking when you first uploaded it.  They also advertise being able to begin sharing the file before it has finished uploading; I was unable to coordinate both a large upload and some observers to verify how that works.

It’s a fairly simple way to temporarily store files; like everything else on the “web 2.0″ it’s prominently marked “Beta”, so the absence of any overt monetizing method should not be too terribly alarming.

Things I like:  free (as yet), clean interface, no overt filesize limit

Things I dislike: not much; there’s one function here and it’s being addressed

Things I would change: it’d be nice to see a little more breakdown of the stats–perhaps an option to view a raw list of access times or something?

It’s beginning to look fairly viable.  Transloading may be possible for reasonable rates.  At this point, it’s just a question of gathering up the typical services and doing some writing.

There was one service some years back that offered transloading, but that was not the focus of their service (which was geared mostly towards one-to-many uploads) and said service went under a while back–no traces of it on the ‘web since a couple years ago.

Sounds like there may be a viable use for the ‘tubesworks.com’ domain yet!