cscotta

It is good to see some analysis turning up on the exploit front. I was (and still am) surprised that the coverage of this jailbreak has been focused almost exclusively on the jailbreak itself rather than the attack vector and its implications.

The fact that a zero-day remote code execution exploit can be triggered so reliably in every iOS 4 and iPad 3.x device that the creators could drop a cute "Slide to Jailbreak" widget on a web page is alarming. With nothing more than a single rogue link and a bit of Objective C, this exploit could easily be used to produce a worm spread by e-mail or SMS to every contact with a link to the same rogue code, hopping from device to device as users tap an innocent link from a friend. In fact, the action of clicking a link could be bypassed entirely by script injection -- resulting in infection should the user merely browse to a page serving the rouge JS. Considering that the exploit is PDF-based, it's likely that it could also be triggered by viewing a document in Mail.

The prospect of iOS worms is very real, and unless Apple begins to take security more seriously (note that this is the second remote code execution exploit accessible from within MobileSafari, and they've yet to even make a peep about this one), I would not be surprised if we begin to see malware on the platform.

[ See the original exploit teardown here: http://digdog.tumblr.com/post/894317027/jailbreak-with-pdf-f... ]

Really cool post, Greg - thanks. That's a neat application of Twilio.

I'm almost more intrigued by this write-up as a study of advanced planning for multiple triaged failure modes and remote correction. It can be difficult to break out of the "ship code, find a bug, ship a patch" cycle long enough to realize the power of a few well-placed remote management hooks that can keep an app on course with minimal intervention.

(Also, as one who's been to my share of swim meets, this sounds invaluable for such a large competition. I'm sure folks appreciated it!)

Strong second.

You would have a very difficult time establishing a proper merchant account as the fraud risks are incredibly high. While many might be willing to discuss it, it is unlikely that the account would be approved by the processor's sponsoring bank in the underwriting phase.

Amazon's FPS service, while far from ideal in that it requires all parties have Amazon accounts, and requires the transaction occur off-site in Amazon's payflow, is very well-suited to this use case. It's the only quick, affordable, easy to integrate service I can think of that allows for a merchant to broker transactions between two parties (while skimming a percentage).

If you push forward with this, I'd definitely recommend launching with FPS rather than plunking down a large personal guarantee with Authorize.net or Braintree.

Good luck!

What surprises me here is the Apple spokewoman's suggestion that "users whose accounts had been misused dispute the charges with their card companies" rather than initiating action against Mr. Nguyen and issuing refunds at his expense.

Apple's developer agreement requires that developers refund the total price of the app, despite the fact that Apple only pays out 70% in the first place (details: http://news.cnet.com/apple-refund-clause-bad-for-developers). The company makes it painfully clear that application developers are entirely liable in the event of customer complaints.

It strikes me as unusual that the company would urge customers to request a chargeback, which would be filed against Apple at significant cost, as all billing runs through iTunes. Can anyone offer an explanation for this?

The speeds we're starting to see on next-gen mobile devices + networks are pretty impressive - more than can be used effectively without draining the battery in a hot second, at least. Now that we've got bandwidth figured out, it's time to tackle latency.

A coworker ran a speed test on his AT&T iPhone 4 in NE Portland at lunch and got about 1.4mbps down with a 150ms ping. I get about 3.9 - 4.3mbps down with an 80ms ping with my Nexus One (T-Mobile): http://j.mp/94sfpF

Both of these speeds are fantastic. The bandwidth question is highly network-dependent, and almost entirely moot once you're beyond the 800k mark -- especially with a low-latency ping, which is likely the biggest bottleneck when browsing the web.

We need device manufacturers and carriers to work closely, striving to reduce latency in mobile connections. For developers, it's critical to drive home the point of minimizing the number of HTTP requests. If you've got a minimum 200ms round-trip for each call and 98 items to load (NYT.com, tested a moment ago), it adds up quickly.

At 140 bytes even, it looks a lot like an SSH RSA public key to me (RSA 1024 bit).

Around page 28-29, you'll find the Court's opinion on Sarbanes-Oxley and its future. In short, it appears they strike down a provision that allows the executive branch to remove a member from the board of directors, leaving the rest of the law intact. Apologies in advance, and please correct me - I'm neither a lawyer or an expert on Sarbox. [Edit: See comment below by kgrin]

This seems to be the most relevant portion of the decision (viewable in full here: http://www.scribd.com/doc/33661051/Supreme-Court-Ruling-on-S...). From pages 28-29, with citations removed for readability:

---

"We reject such a broad holding. Instead, we agree with the Government that the unconstitutional tenure provisions are severable from the remain­ der of the statute. “Generally speaking, when confronting a constitutional flaw in a statute, we try to limit the solution to the problem,” severing any “problematic portions while leaving the remainder intact.”

"Because “[t]he unconstitutionality of a part of an Act does not necessarily defeat or affect the validity of its remaining provisions,” ... the “normal rule” is “that partial, rather than facial, invalidation is the required course”.

Under the traditional default rule, removal is incident to the power of appointment. Concluding that the removal restrictions are invalid leaves the Board removable by the Commission at will, and leaves the President separated from Board members by only a single level of good-cause tenure. The Commission is then fully responsible for the Board’s actions, which are no less subject than the Commission’s own functions to Presidential oversight.

The Sarbanes-Oxley Act remains “‘fully operative as a law’” with these tenure restrictions excised. We therefore must sustain its remaining provisions “[u]nless it is evident that the Legislature would not have enacted those provisions inde­pendently of that which is [invalid].” Ibid.

---

Not entirely related, but if you look closely at 0:50, you'll see that Apple's Mac OS X "Clownfish" desktop image appears prominently in the photo gallery.

That said, the OS looks much nicer than the previous release - at least, on par or a bit above the native Froyo components. I have a hard time getting past the hardware, though. There are tons of diehard BlackBerry users, but I'd have trouble bringing myself to use any of their devices in their current form. Even so, it's great to see that people have choice and that the UI/UX bar is rising on each of the most popular mobile platforms.

[edit: topical content added]

Completely agree - Mozilla's scaled-back implementation, which appears to be closer in line with the standards track - is much safer and marks a better approach anyway (several at MS have been openly recommending against using dynamic attributes for some time now).

It's moves like this among vendors that force us to think about that line between "experimentation and innovation" vs. implementing "proprietary features."

As NathanKP mentioned below, we'd all do well to push vendors to come back together toward standard implementations across all popular browsers. Here's hoping.

I've been testing pre-release builds of AIR 2.0 since January and am pleasantly surprised by the improvements over 1.5.x.

Their inclusion of the WebKit release that ships with Safari 4.x is enough to grin about (which introduced SquirrelFish Extreme and a native JSON object, so clients do not have to implement JSON parsing in AS3 or pass eval'd objects back through the security sandbox).

Beyond that, support for CSS transitions, animations, and canvas are welcome as well. I've not had a need to play with multitouch or the native process API, but they're great to have baked in.

I'm particularly looking forward to the Android SDK. It's a shame the AIR packager for iPhone is no longer maintained, but that's water under the bridge. It'll be nice to have a framework like this which allows for much easier UI skinning and definition than the stock SDK. PhoneGap et al are great - don't get me wrong - but it's nice to have a choice of platforms.

AIR is far from perfect, but it's a solid runtime to work in if you're building an app that has to be cross-platform, is media or network-intensive, and should behave more like a native app than something wrapped in a browser. Kudos to the AIR team on a good release.

Of course, the humor here lies in the fact that IE has had dynamic CSS calculations since IE 5, but is now in the process of removing them – just as they are being standardized in other browsers.

For example [1]: <div style="left:expression(document.body.clientWidth/2-oDiv.offsetWidth/2);">Content</div>

These expressions (or "dynamic properties") essentially evaluated JScript embedded inside a stylesheet and provided some handy hacks to get around otherwise-painful bugs. This included simple math calculations as described in the Mozilla post, but also more complex transformations such as varying the style of an element based on the current day (or other JS-retrievable information).

Funny to see Mozilla phasing this in just as Microsoft phases something similar out [2].

[1] http://blogs.msdn.com/b/ie/archive/2008/10/16/ending-express...

[2] http://msdn.microsoft.com/en-us/library/ms537634(VS.85).aspx...

The current "app" frenzy leaves me uneasy in that most "apps" (in the iPhone/Android/WebOS sense) are roughly feature-par with what a superset of we'd traditionally call "widgets".

That's not to say that a tremendous amount of UX + graphic design, development, and testing are involved - they are, which I celebrate.

But I'd like to suggest that the end product of "HTML 5" app development (assuming any HTML 5 is involved at all) more closely resembles mobile development than desktop application development. I'm uncomfortable with the notion that browser + Javascript-based applications should be considered on-par, feature-for-feature, experience-for-experience replacements for desktop applications written in native code for specific operating systems.

Please don't get me wrong - I'm not attempting to channel a neo-luddism, or pining for the days of Swing and QT. There are tremendous advancements being made in the browser. But browser-based applications are constrained to running inside a browser. Development for browsers is painful and wildly inconsistent, unless papered over by frameworks we all love like jQuery and Prototype. We're heading closer to native implementations of animation and media-related functions, but are still years from any sort of standardization. Even companies heralding the era of HTML5 + JS + standards...well, fragrantly undermine their points by releasing single-browser demos and calling it "universal" (see Apple and the recent HTML5 demo flap).

I look forward to the day when web and browser-based development are a breeze. But until then, I'd feel much more comfortable referring to such endeavors as "web apps" and "web sites" than "applications" in the desktop sense.

It's an interesting idea, but honestly, I find any boilerplate claim to ownership of content posted on a site or imposition of a license, well, frustrating.

The magazine is fantastic and I completely support it, but I do think this should be an opt-in. Perhaps it would be easier for commenters who wouldn't mind their work being published elsewhere to just drop a note like "All comments licensed CC/NC/SA" in their profile?

(I've dropped this in mine).

Before anyone gets riled up, be sure to see the resolution: a rep working on her day off to resolve the issue, a $100 credit and 2,500 frequent flier miles.

Not the best experience, but this one worked out.

You just described several conflicting areas and examples of user confusion. If you stick with this name, tread very carefully.

Indiana University uses Sakai (http://oncourse.iu.edu/). At the time I used it ('04-'08), it was...better than Blackboard, but still generally a pain. The design was poor, the UX was awkward - just a deeply unsexy experience overall.

It might be better now, but I have a feeling that most LMS software is doomed to being, well, LMS software.

I've looked around for something like this quite a bit. The best I found were via eNom, InternetBS, and GoDaddy - but they were all pretty terrible and / or felt skeezy.

If you find something good, let us know!

This is really cool to see. IPv6 is the internet's "peak oil" problem, or a "long emergency" - most seem to think of the transition as a "maybe someday" nice to have, without realizing how few blocks remain in the IPv4 address space.

It's refreshing to see a major ISP take the initiative to prepare their networks, but also release software to help others route between IPv4 and IPv6 networks. Speaking of which, you can download it here: https://www.isc.org/software/aftr

That said...I'd prefer that most of the source weren't a 13,217-line file with rare, cryptic comments called "aftr.c" ;-).

PDF'd manpages: http://u.phoreo.com/rh.pdf

A-ha! Somehow, this link seems to fix the problem: http://twitter.com/c99koder/status/14529776311

I'm having the same problem (server error, but on a Mac) - it's good to know we're not the only ones.

My phone is registered using a custom domain, but I switched the account to a GMail address and ensured I was signed in using a standard Google account when installing the extension. Perhaps it's an issue with phones tied to GAFYD accounts. Is yours?

Pardon me, but I'd like to disagree.

The murder of Theo van Gogh and subsequent threats against other artists, authors, etc. are terrible acts. No one should be killed for such expression.

But I have to say - I find any "juvenile attempt to troll a religious group," well, juvenile and trollish. It is uncivil and rude. It promotes division and distrust, and actively destroys the work many have put into creating safe atmospheres of expression and mutual respect by ridiculing a religious community.

I am not a Muslim. The closest affiliation I'd claim might be with some liberal emerging christianities. But I believe in respecting others enough not to make fun of deeply-held beliefs, which I myself do not hold and which do not impact my life but are absolutely central to the worldviews and spirituality of a very signification portion of the world's citizens.

I'd suggest that "valuing free speech and reason" needn't involve encouraging socially destructive behavior intent on marginalizing a people group, self-selected or not.

In terms of both raw talent and writing ability, Jason's blog is one of my favorites. You can depend on him for solid analysis, clear thinking, and good writing. This article is worth reading.

While I only have a surface-level understanding of video encoding and compression techniques, there are some very good criticisms here. That said, I've been reading through the libvpx source for the past 20 minutes or so. Jason repeatedly slams the quality of the source. The code is much cleaner than he suggests and rather well-commented.

Better than H.264/main or not, I'm excited to see where VP8 goes. With implementations in Chrome, Firefox, Opera, and Flash, it's off to a good start from day one. We'll see where it heads from there.

I'd love to sign up, but apparently students and employees of eight companies can register.

Would the creator consider opening this up? Those of us who work for smaller companies and businesses would love to have the opportunity to connect without being on the same level as Googlers.

There is a great collection of Vim screencasts at: http://vimcasts.org/

Peeepcode has a "Meet Emacs" screencast available for about $9 as well here: https://peepcode.com/products/meet-emacs

It's not quite the site you describe, but I've learned quite a bit watching Vimcasts.

These posts make me sad. If you are in a position to choose the language you're working in, choose the one that makes you and your team happy (in a gestalt sense, of course).

I don't mean to be overly reductionist. But the languages that I'm currently happiest with are statically-typed, compiled, and run on the JVM.

When I'm in a position to choose, I opt for the one in which myself and my coworkers are most productive that meets project requirements. There's not much to say beyond that.

Alpha software is alpha-quality. It takes time to get things right.

My pre-release stuff is full of bugs...which is why it's pre-release. Seems like it's a bit early to judge the quality of their product.

As I understand it, the focus up 'til now has been correctness and compatibility rather than performance / efficiency. It seems a bit early to jump on them for that (though the speed hit you mention is surprising). That said, I'd expect things to pick up speed once the next-generation compiler Laurent mentions in the blog post is ready (and when the RubySpec needle moves closer to 100).

Regardless, the team has made a ton of progress since the last release. Here's looking forward to the next.

I'm surprised by the outrage in this post. This is a very common - indeed, necessary - practice in retail.

A friend of mine manages a high-end retail store in the area. He tells me that there are a number of people who match this buying profile. The products either show up on Craigslist, eBay, or are moved out of state to be sold elsewhere, often in markets the retailer is unwilling or unable to enter for a variety of reasons. Like it or not, in pretty much any retail environment, this practice is unacceptable.

He also tells me that these small groups of people will often approach customers in the parking lot as they exit their vehicle, offering them cash to enter the store, buy the goods with a few crisp hundred-dollar bills, and to keep the change. This gray market is very real.

Beyond that, the guy admits he knew of the policy and was willingly violating it. There's really not much room for outrage here.

This post is pretty heavy on rant and mudslinging against a variety of unrelated platforms.

The author forgets that GCC / the GNU toolchain alone is not sufficient to package, sign, and distribute a .ipa - instead, the developer is bound to Xcode, signing certificates, and the whims of the App Store approval process.

By declaring ActionScript, C#, and Java (all of which have open compilers and virtual machines) "vendor lock-in", the author glosses over the fact that the iPhone OS toolchain is not an open one, in fact, arguably more restricted than all of the above. Make no mistake - I'm not arguing that any of the above are "open" platforms, or that open platforms necessarily make for a better product ecosystem. But I would like to offer a correction to the article's imbalance.

Anyway, I wasn't getting my hopes up. The dream of "write once, deploy anywhere" software is generally one that disappoints.

Sure - it was awhile back and water under the bridge by now, but the original ticket was here: https://rails.lighthouseapp.com/projects/8994/tickets/2628-r...

The bug was a Ruby 1.9-specific issue that another user had stumbled on which I hit as well. Unicode support in the 1.9x series is great, but brought some trouble along with it.

The problem in this case was that ETag generation in ActionController tested the response data using a method that threw an exception if it hit a string with an encoding issue. As such, the request would die after being processed, but before being returned to the user. Because it occurs after calling render in ActionController::Response, the exception was unrescuable. (Ed: No 500 error page, no rescue_action_in_public, or any indication of an exception - just an HTTP response with an empty body). It was a sticky situation. Read my longer comment if you're interested in a full explanation.

Anyway, I don't mean to re-open the discussion now. I eventually resolved the issue by applying this patch locally, then moving to a new encoding-aware MySQL adapter. Life's good.