Xuzz

Previous submission (still on the front page right now, at least): http://news.ycombinator.com/item?id=4518588

That's more likely because Google won't let them add it, not because Amazon wants to block it. Google Play is a proprietary service and they like to use it a a threat to force OEMs to cooperate. I don't see Google allowing it on a heavily customized OS that's barely "Android" at all.

There is no public API on the iPhone to access the IMEI, so at least it is pretty conclusively not using that there.

Unless, of course, you're Nintendo: http://wiibrew.org/wiki/Signing_bug

No they can't: part of a process cannot create executable memory while another part cannot. They'd have to move WebKit completely out of process: a huge task as it already does most text drawing.

Profiles are still web-based, unlike the news feed.

It's still there, just less obviously accessible: Settings app -> Facebook -> About.

Apple's app stores, on both iOS and Mac, both host games and allow unlimited free updates to them.

This has been supported with Colloquy on iOS for years — even using ZNC as the bouncer with the Colloquy plugin. I'm glad there's now a solution for Android that looks like it might be approaching the same awesomeness level!

More info: http://colloquy.info/project/wiki/PushNotifications

I actually wish it was that obvious: I used Palm OS, RIM, and Windows Mobile devices before the iPhone and the unlock mechanisms (on the touchscreens!) ranged from "press the tiny * key, then the unlock soft button" (which was awful) to "press the center button once" (somewhat less awful). Slide to unlock was a huge deal for me: I no longer dreaded the crazy key commands needed to unlock a smartphone.

Palm Treo: http://blog.treonauts.com/picKeyGuard01.jpg

Palm Windows Mobile: http://www.hpc.ru/lib/arts/2364/palm-treo-750v-keylock.gif

Windows Mobile: http://cdn.pocketnow.com/wp-content/uploads/2009/08/DeviceLo...

They're distributed as .zip files (renamed .ipa), so a corrupted file or bad download wouldn't extract anyway. The real issue here is in their DRM: they have to re-encrypt the binary for each user, and the encryption seems to be incorrect in some cases. That's also consistent with the FairPlay log error in Marco's post.

If you're technical enough to be buying old computers to work around it, I bet you could figure out how to disable it when the option is right there. :)

The FSF, not the EFF. The EFF is generally much more reasonable (moderate?) about things like this; the FSF is generally more in line with Stallman's views (radical or crazy, depending if you agree with him).

The part about "Facebook sneaking through contacts and adding friends' numbers" isn't correct: the Facebook app has always had a pretty clear description about what would happen if contact sync (an optional feature) is enabled.

For example, on iOS, it looked like this almost two years back: http://www.neowin.net/images/uploaded/iPhoneNumber.png (as seen on this page from October 2010: http://www.marismith.com/facebook-phonebook-how-safe-your-ce...) I don't have any old screenshots of the Android version, but the current app is similar to the iOS screenshots above.

UIWebView runs in-process. There's no way for "part of" a process to be able to map executable pages without other parts able to, so either they let any app run whatever code it wants, disable Nitro, or rewrite large chunks of the UI to move WebKit out-of-process.

Just Googled for "square chrome icon" and copied a link to the first relevant image I found, hah.

So far, there have been two userland exploits of the iOS browser (Safari) since Apple implemented code signing in 2008, at JailbreakMe.com. Both of those required tons of extra work compared to what they would have required otherwise.

It's not a "weak argument", it's the reason why iOS is one of the most secure platforms out there, and way more secure than Android, Windows, (most) desktop Linux, and OS X. Other preventative technologies (e.g. ASLR, DEP/w^x, etc) are on those platforms, but none of them have the same kind of pervasive code signing that you see on iOS (and often video game consoles).

Sparrow tried to position it like that, but that was not the real story: it was not Apple "blocking" them, it was that they did not want to put in the effort to setup a real push service, and instead wanted to run all the time on the device (using battery) to maintain an open connection. Which, of course, not having every app doing that is exactly the problem that push notifications, as implemented by Apple, were designed to solve.

Something like this might have worked and fit inside the iOS frame: http://fc06.deviantart.net/fs70/i/2011/132/3/1/chrome_11_flu...

iOS code signs all code that runs on the system. Compared to most other operating systems, this is a huge security win: without another exploit in that system, even a standard remote code execution vulnerability is useless. Nitro generates code at runtime, so it (by definition) needs to run unsigned code. With Safari, Apple can audit all the code necessary, but with third party apps, it would be easy for a developer to have their app exploited or even use the unsigned code ability to download new, possibly malicious code after the App Store review process.

Same link, discussion from earlier today: http://news.ycombinator.com/item?id=4167721

In Facebook for iPhone, there is a way to report an issue: you can go to Help Center -> Something's Broken -> Report an Issue -> "please let us know", which then shows a page to file a report. It could be made even easier to find, but there is a way.

Good question. The one I posted above was an accident; I don't know how I did it.

The real article you want is (as linked): http://atnan.com/blog/2011/11/17/enabling-remote-debugging-v...

This post is essentially just a compiler warning fix for the (much more interesting) one linked.

The important part is using it, not specs. My Lumia 900 scrolls faster than my Galaxy Nexus, and I don't even really care why. But, it's still a better experience for scrolling through a list of items, even if the specs on paper are technically less powerful.

The legal route would to be to provide an installer that downloads e iOS frameworks from Apple, so you aren't redistributing anything. However, it would still be quite a bit of work: iOS has a not-insignificant layer of drivers in the not-yet-recreated IOKit kernel framework (although some are open source), and likely many other low-level layers that would need to be recreated.

However, it's certainly possible, but as 'mparlane says, it would be a lot of (difficult) work.

Dropbox is just a folder — the reverse engineering was to inject themselves into the Finder for their custom icons and context menus.

Yep, that's how the binaries for it are currently built: with the iPhone SDK. However, higher-level stuff hasn't been developed (e.g. graphics), and the native iOS libraries would need emulation of additional lower-level services (like IOKit for hardware interaction) to run.

How is "mute by default" different from "no autoplay" except that when users actually hit play, it would just start somewhere in the middle? (That sounds like an even worse user experience.)