Neural Network in JavaScript

I’ve seen just about everything else implemented in the lightweight, scripting language of the web, so why not a neural network? I saw this via Hacker News and it doesn’t strike me as too far different from libraries for doing heavy graphic processing in JavaScript. I could also see some distributed applications potentially using this. Think about it, modern browsers increasingly provide excellent client side storage, useful for hanging onto locally produced results, and means for sending and receiving data much more smartly, just what you would need to distribute tasks and collect results. I think a folding@home style project that works completely in the browser makes a great deal of sense.

The code is licensed under an MIT license and is available on github. Both would make it pretty simple to grab it and experiment quickly, whether pursuing my idea of distributed neural networks or any application that could make use of the capabilities of such a tool in a lightweight execution environment.

feeds | grep links > DoJ Fails to Report Wiretap Orders (Again), Ads with Cloud Printing, Ajax Library Targets Mobile Developers, and More

  • DoJ fails to report wiretaping activities to Congress, again
    Mike Masnick at Techdirt links through to some findings by Julian Sanchez that the Attorney General has failed for a period of some years to provide a report on the number of surveillance orders applied for by law enforcers. This report is meant to allow Congress to exercise proper oversight which has essentially just not happened for large swaths of the past decade. As Masnick goes on to explain, the DoJ has done this twice before, lapsing then dumping multiple years of data onto Congress effectively creating years of operation at a stretch where oversight was impossible.
  • HP experimenting with ad delivering on its cloud based printers
    Via Cory at Boing Boing, this Computerworld article has me very concerned. Automatically printing ads along with print jobs your submit over the net is very different from purely digital ads on web pages and email. A user of one of these printers is paying for consumables, most notably ridiculously over-priced ink. I don’t care if HP says their first test subjects didn’t mind, I have to imagine a majority of folks will be surprised, not sanguine, if not outright angry at the presumption.
  • ExtJS tries to harness developer outrage to fuel its new framework
    The Register has an announcement from the ExtJS folks, a dual license AJAX library, that they are launching a new project to compete with mobile apps by combining their library with a couple of others targeted at programming touch interfaces and vector graphics presumably including animation. I’ve worked with ExtJS in a professional capacity and I am not entirely impressed by this attention getting move. I won’t say the library is bad, it packs a lot of capabilities. However, I will say I don’t think it is any easier to program than the iOS or Android SDKs. If you want to target pure web applications using HTML5 at mobile devices, I am positive there are better options.
  • Inside Australia’s data retention proposal
  • Employee monitoring, when and why IT is expected to spy
    Via Slashdot.
  • More on issues, activism around filming police
  • VPNs not adequate to anonymize BitTorrent users

Stanford JavaScript Crypto Library

I found a link to SJCL on Hacker News.  This project looks impressive, offering SHA256 for digesting and AES for encryption with a handful of bit lengths.  It boasts any number of other impressive features.

SJCL is secure. It uses the industry-standard AES algorithm at 128, 192 or 256 bits; the SHA256 hash function; the HMAC authentication code; the PBKDF2 password strengthener; and the CCM and OCB authenticated-encryption modes. Just as importantly, the default parameters are sensible: SJCL strengthens your passwords by a factor of 1000 and salts them to protect against rainbow tables, and it authenticates every message it sends to prevent it from being modified. We believe that SJCL provides the best security which is practically available in Javascript. (Unforunately, this is not as great as in desktop applications because it is not feasible to completely protect against code injection, malicious servers and side-channel attacks.)

It is also tiny, at 6.4KB minified, and promises significant performance.  The project page promises some benchmarks to back up the latter claim.  The library is written by Emily Stark, Mike Hamburg and Dan Boneh at Stanford University.

With increasing support for ever more sophisticated client-side APIs like IndexedDB I think using SJCL makes a great deal of sense.  I can easily see dropping it into an application that intends to store sensitive data on the client side.  The library should be cross browser compatible though it is early days and that still requires more testing.  It is also open source, released under either the BSD license or the GPL v2 or later.  No reason not to grab it and give it a whirl.

There is a promise of asymmetric public key support at some point in the future.  I wonder if that means it would be possible to use it in a bookmarklet to bring GPG-like functionality directly into web mail clients?

Yet Another JavaScript Based Flash Interpreter

Haven’t we been here before? I didn’t think using HTML5 and JavaScript for interpreting Flash was anything all that new. I guess The Register’s story on Smokescreen differs from Gordon because it is a proprietary development much more specifically aimed at Apple’s mobile platform.

The article mentions the company will eventually open source the interpreter at which point it will be interesting to see if anyone combines it or parts of it with Gordon to advance the state of Flash replacements. As far as I can tell after just a few minutes playing with demos for both, they seem pretty comparable. I am skeptical having both available openly will improve either one.

Doing a bit more digging into the Smokescreen site, I think I found the difference, which The Register buried a little in their story. The company behind Smokescreen is specifically looking to bring interactive ads to the iPhone and iPad with its interpreter. Not developing a general drop in replacement for Flash. In that instance, I suspect The Register’s view on the slow performance and limitations of Smokescreen, a trait Gordon shares, as being less of a handicap is apt. Their point about Apple’s forthcoming network for interactive ads is also well made–if Smokescreen is serious, they need more than a technology demo.

Mozilla Shares Its Take on a Rich Browser Database

In a post on Mozilla’s hacks blog, Arun Rangatharan and Shawn Wilsher give a clear and compelling walkthrough of IndexedDB, a feature coming in Firefox 4. IndexedDB is their answer to the need for more powerful client-side data storage. Many browsers already support localStorage but that is just a persistent map. It only stores name-value pairs and doesn’t provide any kind of index support for faster look up over larger data sets. Mozilla has decided to eschew another effort in this arena, the WebDatabase API. That API is currently implemented by other browsers and is based on and a subset of the popular SQLite file database.

I don’t even have to read the post they link to explaining the reasons, looking over the code samples they provide for comparison has convinced me that IndexedDB is appealing. The choice between the two mirrors very strongly the calculus around selecting server side database these days, too. There may well be some kinds of data for which a small relational database makes sense but the ease of programming speaks well of the more JSON-like IndexedDB. I doubt any of the advantages of SQLite will make much of a difference on the scale at which these APIs will be used.

My only concern is cross browser support. IndexedDB was a draft spec before Mozilla started implementing it for the forthcoming version of their browser. In that post on reasons for supporting it, they do note their is support from Microsoft and some implementation of the structured storage system for Chrome. Here is hoping we can avoid having to have abstraction layers or wrappers as crappy compromises for it not making it into all the modern browsers.

Proof of Concept for Ajax without JavaScript

Slashdot links to what is really little more than a code sketch for driving some of Ajax’s features without using any client side scripting. The proof of concept is trivial and a bit clunky in and of itself but may have potential for helping highly dynamic applications degrade more gracefully when JavaScript is disabled. I say clumsy because it relies on a meta-refresh, a script-less way to get a page refresh itself. That refresh, unlike just about any JavaScript based technique, is pretty crude as it simply keeps refreshing the page, potentially interfering with your attempts to navigate and use its content.

However it is increasingly common to see visitors disable JavaScript despite its widespread acceptance and inclusion in all modern browsers. I for one use NoScript as an added security measure because it disables all client side scripts on first load. It gives me a more secure default when following a link to a site that is unknown to me. For convenience, I can grant a site temporary permissions that evaporate when I close the browser. Once I have determined a site can be trusted, I can mark it as such which will there after allow its scripts to load. (The sites in question are actually the source sites for various scripts. A give page may load scripts from other domains alongside its own for analytics, ads, etc. NoScript works with those fine grained distinctions, I am simplifying for the sake of making a point.)

There is a cost in having such a default. If a site doesn’t work quite right when I first visit, I have to spend a little bit of time figuring out from where it is loading scripts or just grant temporary permissions all at once. More often than not, I take the latter approach. NoScript even has a button to grant all sources on a page temporary permissions. I’d be a lot happier if more sites explored even clumsy ways to get their core functionality working without scripts. This would allow paranoiacs like me to safely preview a site before even conferring temporary trust.

Mozilla Shoring Up Performance for JavaScript beyond TraceMonkey

The Register has some good news from our favorite open source lizard. I was unaware of the limitations of Mozilla’s last major improvement to their JavaScript interpreter, TraceMonkey. As The Register explains it, though, it makes sense that there would be some segments of script where the cost to fully trace the code and convert to assembly would be prohibitive.

The part that caught me be surprise is when the interpreter finds such code, it drops through to code that is two or three years old. This new effort, JaegerMonkey, looks to fix that, shoring up this performance drag on more complex scripts. It will marry the approach, compiling entire functions to assembly, proven out by the other modern browsers with TraceMonkey on the promise that a hybrid approach will yield the benefits of both.

There is plenty of more detail at the article, including some possible concerns arising from too much parasitizing of approaches between the competitive browsers. While there is no projected date for when JaegerMonkey could be included in a generally available build, the developers look to be doing the key integration work necessary for that this week.

14 Day Event for Latest jQuery

Although I don’t get much of a chance to use it, I very much enjoy jQuery when I have to program any non-trivial client-side behavior in JavaScript. Jon Resig tweeted about what sounds like a clever launch event for the latest version. Already, the day one post reveals a big win for documentation, a deal with a publisher of one of the better jQuery books. As a hacker using jQuery, docs are critical to figuring out how to apply it best, so this is splendid news.

Jon is on my list of people to interview in the coming year. If I schedule that soon enough, we can discuss 1.4 and this clever way of helping drive adoption.

ECMAScript 5 Approved

According to Slashdot, the biggest point of contention in the approval of the new standard was over possible inclusion of some floating point representation in the language. The linked article, at the H, notes that namespaces are still out. Apparently that effort completely died out when it was rejected from ECMAScript 4.

I still hold out hope that we may get something perhaps even better if browsers and AJAX libraries adopt CommonJS modules regardless of ECMAScript’s now entrenched refusal to afford any way to manage scripts of non-trivial size, from potentially widely varied sources.

TCLP 2009-12-06 News

This is news cast 199, an episode of The Command Line Podcast.

This week’s security alerts are malware may start affecting non-jailbroken iPhones and testing whether Google’s new DNS resolver is secure. I wrote about Google’s new offering earlier in the week.

In this week’s news latest ACTA leak seems to confirm the worst exceeding EU and Canadian copyright policy and makes better sense of KEI Director James Love’s encounter with USTR chief Ron Kirk, standalone JavaScript, historical antecedents to the current broadband regulation debate, and a new privacy reporting tool from the CDT which is part of a larger trend to try to improve awareness around online privacy.

Following up this week one British politician pushed back on the Digital Economy Bill and evaluating the censorship risk of the current version of the Google Books settlement.

[display_podcast]

Grab the detailed show notes with time offsets and additional links either as PDF or OPML. You can also grab the flac encoded audio from the Internet Archive.

Creative Commons License

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.