If those answers are the truth, what's wrong with them? They don't say anything particularly bad about the workplace, just that the previous employee had other ideas about what they wanted to do.

I was thinking the exact same things. Identifying the hardware is fundamentally different from identifying the person currently using it, and being able to state unequivocally that they are authorising whatever action is taking place. Plus, as you said, hardware gets upgraded. Even worse, though, is that hardware also fails; particularly high-end GPUs nearing the end of a life spent being slightly too hot. Unexpected hardware failure could leave users with no overlap in the usable life of old & new components, meaning they cannot log in to existing accounts in order to register the fingerprint of the new hardware. Also, unless there's a hidden cache of documents I'm missing somewhere, I can't find any details of what these "unclonable functions" actually are, just that they exist. Are they robust against simple replay attacks?

This all smells like a bad idea to me; something cooked up by a bunch of theorists with very little grounding in practicality. Not sure what part of this could be a "good thing", to be honest.

I thought I'd take a gamble on this one, and actually read TFA - even before reading the comments. I thought there would be a nice picture or two, maybe a few links to pages about the device itself. But you know what I got instead?

France.

No pictures, no related links at the end, and only one word in the entire article itself turned into a link - the word "France."

Tooltip? "Full coverage of France."

FFFFFFFUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU

Yes there are other methods, but generally speaking, once you've got a device with a touchscreen, only so many of those methods are actually practical and sensible - it's a flat, touch-sensitive screen, so they're all going to revolve around pressing it, dragging your finger across it, or some combination of the two.

Where's the patent for "double press to unlock"? Oh, wait, there isn't one, because patenting the concept probably didn't even cross the minds of the people who came up with it!

When it doesn't validate, you reject it. Or, in the case of a replacement for an "extensible" protocol, you do something more subtle - such as, accept something which is well-formed XML but contains unrecognised tags, by skipping over the unrecognised tags. Much as is done in HTML itself.

Once you've written a few programs which accept data from the public internet, you come to greatly appreciate the value of protocols whose syntax is easy to parse, and whose semantics are simple to understand. The simpler the parsing code, the less likely it is to contain exploitable bugs; the simpler the semantics, the easier it is to write standards-compliant logic, and have a wide range of client & server implementations which interoperate happily. HTTP in its modern form - i.e. augmented over the years with such features as persistent connections, pipe-lining, chunked encoding, multi-part bodies, compression, cookies & caching - is neither easy to parse, nor easy to understand once parsed. It needs to be taken out and shot, along with this whole laissez-faire attitude to standards compliance & well-formed-ness which permeates web standards.

It's caught my attention too. You're not alone. I regularly cringe - or even groan out loud - when reading pieces published online in various places; Slashdot submissions being a frequent source of offence.

What *I* want to know is what the poor horse did wrong in all this. Why are they helping Uncle Jack to off the poor beast?

Burma-Shave

But the business decision has its roots in technical issues, to a certain extent. An unstable app isn't going to get good reviews, and an app with bad reviews isn't going to sell well. We haven't seen the code, but it's entirely possible that different development practices could have lead to Android issues taking up less than 20% of their time. They use a pre-exising cross-platform framework (Unity), but still have issues with shaders and texture formats? Sounds like their shaders aren't as well written as they perhaps thought, or they're doing something fruity in their content production pipeline. Having looked at screenshots, I'm not even sure what they're using shaders or exotic texture formats *for* - perhaps they should really be targetting OpenGL ES 1.0/1.1, not 2.0. Perhaps Unity as a framework just isn't very stable on Android, in which case they need to either ditch the framework or make use of their support entitlement (assuming you get some when you purchase a license).

Given that they only support two platforms to start with, spending 20% of their time on one of them doesn't sound too unreasonable. You can't expect your product to do well on a given platform if you don't treat it as a first-class target. Of course they're painting the end result as a pure business decision, but when other developers continue to profit from Android apps, you have to wonder why they were only making 5% of their money from one of a grand total of two supported platforms.

As with so many things in the world of computing, it's a trade-off. If the OS wants to maintain an application's EGL context when the user switches applications, it either needs its own state management so it can recreate that context behind the scenes without any specific application support (I imagine this would be quite complex, if it's even possible in the general case), or it has to take RAM hit of leaving the context intact, meaning decreased performance and/or fewer concurrent applications before things start being forcibly terminated. The EGL spec has a section on power management for a reason.

I've never developed for iOS, so I don't know exactly what it does, but I can understand why Android works the way it does - developer unfriendliness aside. Applications don't terminate the moment the user switches away from them, so they don't have to be launched from scratch if the user switches back; however, if something else wants to perform accelerated rendering whilst your app doesn't have focus, your app loses its grasp on the GPU. Personally I don't think this is unreasonable. AFAIK, if your app doesn't use OpenGL, loss of focus (distinct from termination) doesn't imply anything special.

Just hook into the right events, re-upload your textures & set desired GPU state before trying to render the next frame, and you're good to go.

64-bit builds of libcurl are flaky? That's news to me. I use it at home on Gentoo and at work on Fedora, both 64-bit native, and don't have any issues. Maybe there's something "interesting" (read: not set up correctly) in the Windows parts of its build system, but I doubt it's anything inherent in the code. As for 64-bit QuickTime, does that even exist on Windows? I'm willing to accept that in your case, the lack of 64-bit builds may not be your fault, but the GP's comments still apply - just in a slightly different way. There *should* be stable, 64-bit versions of your app's dependencies by now.

Really though... QuickTime? Do people still use that on Windows?

Have you looked at the specs of modern smartphones? Dual core CPUs are increasingly commonplace, with quad core on the way - in fact, already here in some of the high-end tablets. We're talking about Android devices here, not sub-£50 "feature phones". Comparing the tricks needed on this sort of hardware with what was required to squeeze performance out of DOOM-era PCs is an insult to the ingenuity of the programmers behind the early ground-breaking titles. OpenGL ES 1.0 has been available since API level 4 (Android 1.6), and 2.0 available since API level 8 (Android 2.2).

The primary language for Android development is Java. You *can't* go "pretty deep into the guts" from so high up; that's the very reason you can run the same bytecode on x86 and ARM devices. Yes, there's always the NDK if you really want to use C/C++, but if you stray outside the realm of the supported libraries then you deserve everything you get.

MASSIVE DISCLAIMER: I'm only just getting started with Android development myself. Still, I have to wonder how many of the problems lie with the platform, and how many lie with developers not really understanding what they're working with, assuming that the size and nature of the audience automatically turns mobile game development into some sort of free lunch.
        * We all know that GPUs have driver issues, but don't rule out the possibility that issues are really to do with your own code: in my limited experience with OpenGL on the desktop, it's easy to write something that only works on certain hardware because you have unintentionally violated the spec, for example by setting something outside its officially specified range of values, or assuming some default piece of state which the standards don't mandate. Unless you're writing the next Unreal, this is more likely than uncovering driver issues with your 2.5D platformer or simplistic first-person engine. Keep your rendering pipeline as simple as it can be.
        * Apps published on the marketplace had (until very recently) a size limit of 50mb. Anything above that had to be installed via a follow-up download within the app itself, which adds complexity, and increases the chances of failure. This limit has now been raised to 4GB, but before that, any developer blowing the limit ought to have thought long and hard about whether they really needed to before going down that route. Even if you get it right, there will still be scores of complaints from users who just don't understand that trying to download several hundred megabytes (non-resumable) over a patchy GPRS connection is just not going to end well, no matter how much care you take to warn them up front.
        * I could be missing something here, but it appears to me that Android doesn't hand-hold your application through state management, especially if you're using OpenGL. This isn't just about saving basic state such as high scores, but the much lower-level business of simply writing something which is robust in the face of how Android handles multi-tasking. Read up on what events can and cannot cause an app's EGL context to get trashed, and what exactly you need to do when that happens. Remember the bad old days not so long ago, when alt-tabbing was a good way to crash full-screen games on Windows? Well, those days are still with us, just not on the same platform.
        * Another good thing to understand is how to use the manifest. Declare what screen sizes and orientations you support, what texture format support you expect from the hardware, and so on. I have no evidence of this, but it wouldn't surprise me if some devices claim support for texture formats which they can't actually handle (those pesky GPU vendors), but hey, sometimes issues are out of the developer's hands - that's what trial versions are for, right?

I'm not saying it's easy. I don't fully understand how to navigate my way around most of the above issues myself, but rather than let it put me off, I'm trying to learn how to deal with them, so I can learn the best practices, push the specifics into a framework where possible, then use that as common ground for multiple apps.

Development is hard, especially game development; cross-platform game development more than doubly so. But the issue is not one of underpowered hardware.

By choosing TLS as the underlying transport, inspecting traffic for debugging or monitoring purposes becomes nigh on impossible. It will only be possible to capture traffic at the application level, after decryption and decapsulation (which, depending on the nature of any given bug, may be too late), or if it originates from servers you own (i.e. the server's private key is available to you). SPDY proxies will become dumb pipes, unable to perform any sort of content caching, unless users are willing to accept that the proxy may perform MITM on their traffic. For such MITM to be feasible, users need to trust a CA certificate associated with the proxy, and rely on the proxy performing upstream certificate checks on their behalf, because the browser no longer has a single end-to-end TLS session with the origin server. In corporate and other "managed" environments, people often find this acceptable in moderation*, but I would be worried if this became the norm - it creates a mind-set whereby it's acceptable to breach users' privacy, and the more proxy vendors have incentive to implement the necessary (proprietary) code, the more scope there is for them to get it wrong, completely undermining security.

Not to mention that introducing a mux/demux layer in between the network traffic and the individual requests/responses greatly increases the complexity needed to implement a proxy compared to plain-old HTTP.

Losing the functionality of caching proxies would seem counter to Google's goal of speeding up the Web. Losing the ability to monitor and filter network traffic will greatly diminish the ability of schools, employers, public hotspot providers etc. to enforce acceptable usage policies, to the extent that some - especially employers - may simply resort to blocking web access outright.

IMHO, the behaviour of SPDY proxies needs to be tightly specified, if they are going to exist. Standardise MITM behaviour, so that users and admins are aware of the pros and cons. Make it mandatory that end users are warned when MITM is taking place. Perhaps introduce new extensions, such as the ability for the proxy to establish TLS with the browser using its own certificate, but transmit a copy of any origin server certificates corresponding to proxied requests, so that the browser isn't entirely at the proxy's mercy WRT certificate verification. Perhaps introduce the ability to multiplex requests to different domains on the same connection, something a browser can't do when talking directly to distinct origin servers.

Note that similar concerns apply to reverse proxies, used by website providers themselves to speed up their own infrastructure. It may seem desirable for both front-end caching and back-end servers to use SPDY, but establishing TLS sessions between two halves of the same infrastructure, over the LAN, will be detrimental to resource usage.

* Bear in mind that currently, MITM is only necessary for HTTPS sites, which means that there are vast swathes of in-the-clear HTTP traffic for which caching doesn't introduce any inherent security concerns. By making *everything* use TLS, MITM becomes a consideration if you want to perform *any* caching/filtering at all, not just caching/filtering of secure sites. If there is no longer any distinction between secure and insecure sites, how does even a responsible admin know where to draw the line?

Yeah... the first version is never going to work through a proxy. If the proxy supports HTTP 1.1 and is well coded, it may either strip the upgrade header (in which case the server will drop down to the fall-back method), or respond with something like an error 501 (unimplemented), in which case the client could drop down to the fall-back method itself (i.e. re-send the request without the upgrade header). If the proxy only supports HTTP 1.0, it will probably send the upgrade header on to the server blindly without understanding it, in which case it will come down to how well behaved the server is: if it notices the request version is only 1.0, it should technically drop to the fall-back method, since the upgrade mechanism wasn't defined in 1.0; however it may not do so, in which case things will go wrong, most likely in the form of the server's response being truncated.

The second version is slightly less bad. Polling might not be great for resource usage, but at least it remains within the realms of valid HTTP. The fact that the server's response bodies are actually queries, and the client sends the answers as POST request bodies, is neither here nor there from the proxy's point of view. It's still a hack, but there's no reason a well-behaved proxy shouldn't handle the data.

The particular proxy I work on purposefully downgrades requests to HTTP 1.0, to get away from a variety of HTTP 1.1 "features" where support is assumed rather than negotiated, such as chunked transfer coding. This still doesn't stop the occasional broken webserver from sending a response branded as HTTP 1.0 but using features which only exist in 1.1. One thing I can say for the "protocol" you linked to is that at least it's correctly negotiated.

I think part of the problem stems from a common assumption amongst developers that "uses HTTP" equates to "works through firewalls", which is just plain wrong. I can kind of understand why HTTP abuse happens in the context of JavaScript, but when the client isn't even a browser - as is the case with the SHOUTcast/Icecast abomination, where data travels over port 80 and kinda looks like HTTP but isn't (responses begin with "ICY", for starters) - just make a new protocol, FFS!

Unfortunately, I don't have a good answer for you. However, I would like to point out that in my opinion, your question typifies what is wrong with trying to use HTML, HTTP and JavaScript as a general purpose development platform. The reason this isn't easy is because long polling is a hack, as are all "push" technologies. HTTP was only designed as a simple, one-way request/response protocol; clients make requests, and the server responds.

I'm not entirely convinced that running arbitrary code directly from the browser is a good idea, regardless of whether or not it works across many platforms; but if people really want to take application development in that direction, can we please design technologies which are up to the task, and stop abusing ones which were never intended to be used that way?

Disclaimer: at $DAYJOB I develop a web proxy; HTTP abuse makes me cry.