coldnebo

I'm not sure I understand this. Apple seems to be limiting all discussion to in-situ mechanisms of cracking, but no one is talking about external means. For example ICE-level debuggers require sophisticated hardware that is not easily available to everyone. Likewise, the XBOX encryption was very difficult to crack without Ghz hardware.

Just put the critical path in the prom and then bypass the prom with your own hardware-level circuit. The device itself can be keyed so that only Apple hardware bypass is allowed to connect in this way. Now you have a physical bypass that is difficult if not impossible to get around, but enables warranted access by agencies that own the limited hardware. This also has the advantage of human cost. You can't easily apply this method to millions of phones without a huge cost in time and effort. Even if the device is stolen, it limits exposure to phones in the physical possession of the hardware bypass which is surely better than compromising millions of phones. And so what that the critical path patch exists out in the open? Knock yourself out and make an emulator that will unlock hw emulated phones (which is a difficult task, not even the IOS emulator is a true hw emulator), but it won't work on the actual hardware unless the prom is swapped which is hardly trivial.

The key signing argument has little weight by the way. DVD manufacturers had the same stance and the root key was leaked to the public. How can Apple guarantee the same won't happen with their keys?

It seems both Apple and the FBI are withholding something, but on face value the technical requirements should allow warranted access. The fact that they don't is a flaw in the technology design.

Case law surely has precedents in this area? Can safe manufacturers be required to make bypass mechanisms for bank vaults? What about non-criminal property law? Say a family member dies and the legal estate needs access?

If you learn web development and apply for a job as computer scientist, there's a bit of a mismatch.

I think the author is assuming that "data scientist" means scientist more than developer.

But I agree, there's more than enough applications coming out of this for developers.

I'll bite.

Regarding your assertion:

I'm not sure that follows. TCP/IP's primary design point was avoiding centralized network failure in a nuclear war, so you can't strongly claim that it is responsible for heirarchies (i.e. Star) we see in modern topology -- that's likely due to other forces like cost optimization (eg branching structure is a common feature of such optimizations).

Now this isn't to say that TCP/IP is efficient for all decentralized networks. And I think there are quite a few points that make mesh networks challenging... But you could also argue that for the interplanetary network protocols as well, so I think it's not so much the concept of decentralization, it's more the specific constraints of mesh or interplanetary that are unsuitable for TCP/IP.

Regarding the quote:

This argument seems to be partly based on economies of scale and how they are currently applied. But internet economies can be platforms as well as products.

Platforms have a strong tendency towards monopolies (i.e., Apple App Store, Uber, VISA). But even in platforms, they may centralize wealth by treating customers as resources, or they may distribute wealth by treating them as partners.

As we race towards the so-called "gig" economy, I think a key differentiator in platform providers will be the extent to which they grant power to their users as partners in creating value.

This changes the classical idea of monopoly quite a bit as the old concept merely controlled a market for maximum exploitation of its consumers. If consumers are given back some power in terms of profit sharing, content creation, value creation, the Internet could be an extremely vitalizing force.

You see this in spates: Etsy, Steam, Heroku.

Maybe greater collaboration will be necessary to drive increasing efficiencies. The key point might be "central management" vs "empowerment" rather than platform, product, monopoly etc.

I think you have to be careful because there are two things that need to be separated:

1) the human digestive tract is adaptable -- this measures the amount of adaptation the individual is capable of.

2) evolutionary pressure selects individuals who are highly adapted to their environment (I.e. The others simply die off!) -- this measures the adaptations of a population towards diet.

Ex: Swedish ability to digest lactose in adults. Asian insulin response to high carb/rice diets.

It seems that if we really want to crack this nut, we should be looking at DNA data as well. I.e. This population gets this response with this diet, while that population has a completely different response.

And yes, unfortunately adding DNA populations makes all of this research even more complex than it already was.

Easier said than done. For a trivial combination, it's easy. For most real world requirements it becomes a combinatorial explosion of various strategies that are mutually exclusive in many parts.

Unless you have some new machine learning approach to work out all the platform quirks and arrive at pure fallback nirvana?

And how many commercial marketing clients from Fortune 500 are in your portfolio?

Doing GAs right can be very hard. Like, I've seen cases where GAs hooked up to a certain type of physical simulation learn to exploit the ODE in play and find optima that are based on ODE artifacts, not reality. Eg wind turbine design and CFD modeling.

I remember one specifically learned in Quake to always strafe run because the dx+dy gave sqrt(2) max speed instead of just max speed.

What most people don't understand about GAs is that asking the question correctly and unambiguously can be harder than solving the problem. GAs can have a steep price, it's not magic.

Yes, but in this case compliance is quite difficult. Why would the compliance department go out of its way to develop a new mobile testing infrastructure when that isn't the industry standard? So it seems very plausible in this case that compliance might not have found the issue. It required a novel method of testing to discover the cheat.

I have to be honest, when I first heard about this, I suspected a genetic algorithm as the culprit. It's exactly the kind of result you'd expect when giving an impossible optimization without sufficient boundary constraint. AIs can and have been known to cheat, and because the fitness driver would have been compliance (V&V) the GA could plausibly have settled on methods that were undetectable (i.e. Not part of the fitness function).

Often the output of GA code is not understood formally by engineers, or reverse-engineered into a traditional algorithm, so it's plausible that it could have remained hidden in plain sight.

BUT, if that had truly been the case, the engineers at VW would have quickly suspected and publicized it. So the fact that VW blinked showed that in fact they lied and didn't have an honest technical explanation.

However, I think the GA scenario is good to keep aware of as we increasingly rely on machines to optimize solutions based on testing.

This is fantastic news. The marketers have given us an excellent key by which to block ads and distinguish ads from content! Nice!

“We learnt that we were building the same thing over and over, and realised that the more interesting thing to do was to cut out the wasted effort and cost, and work out how to automate 90 per cent of writing code.”

I view that as a failure of abstraction and composition, not as a failure of automation. If it's tedious to hook up window controls to underlying data, or to handle properly a form validation loop in a controller for the millionth time, we should be asking why the abstraction layer we are using requires that tedium instead of being more succinct?

Often the abstraction is complex because of the degrees of freedom it has. Automation on the other hand reduces the degrees of freedom. This is great if you are the one who is reducing and making the choices, but if you are letting someone else make all the choices about what is possible... It's like the difference between driving and being chauffeured.

Even if this system were like the mathematician: "show me all possible worlds satisfying X" it would require either a huge search space to pick the desired answer or present only a handful of preselected choices. Search refinement is more interesting, sounds like a great deal of complexity to avoid (less?) complexity of actually doing the work-- especially in meanial cases-- i.e. I don't want to sift through 1000 variations of form validation to "find" the magic one that completely meets my business needs.

I think that's precisely why this testing insight isn't more commonly used. In reality, it's not about unit vs functional, it seems to be about scope. E.g. If you have behavior that can't be tested without doing a full manual integration test, then that's where you need to start. Automate it and start to push back the layers until you get to functional, until you get to unit.

I've been experimenting with applying code coverage to integration test since it gives testers insight into whether they are testing the code at hand vs internals of other integrated systems (this difficulty is likely what keeps many from trying such testing).

But yes, these methods take a lot of time that we don't have.

The other approach I've been leaning towards is static code-flow analysis, which can also be difficult (esp. in distributed web applications).

I totally agree with this!! I've been learning this the hard way and came to similar conslusions about the need to wrap code with functional testing first and then refactor. It solves the chicken/egg problem with unit test/refactor. But it's not very popular -- maybe because of a percieved two-pass testing. Lots of work.

Page crashes chrome and safari on ipad. Fyi

The rule of composition is an important counterpoint to the rule of diversity. Unix's most important feature is treating everything as a file. That interface allows a lot of freedom in composition, but every process has to conform to exactly the same interface. Perhaps not surprisingly, TCP's stream-based interface has also allowed a great deal of freedom in composition in networks.

"The people entering the workforce today value flexibility and autonomy; they choose location over career and job rotation over promotions."

This is so much bs. What chance of career? What chance of promotion? It's not that they value these things more than older workers (we do too dammit!) it's just that they have little choice.

With real wages stagnating, the only way to move up is to switch jobs. The entering workers have no choice in the matter, but they also are embracing the alternatives to extract new value out of the employer-employee relationship.

Or, more simply: by the time you've 'looked' and understood what you are looking at, billions of other particles have already interacted with the experiment output, collapsing the wave function... so no, by the time you actually look at anything, it's classical, not QM.

Sure. But either term is usually passive in classical contexts and always destructive in QM contexts. You can't uncollapse a wave function!

Consider a twist on Schrödinger's cat experiment: there are two scientists, A and B. The box can only be opened by one scientist at a time... the other scientist must wait outside the room. Scientist A looks in the box and collapses the wave function and sees that the cat is dead.

What is the probability that scientist B will see a dead cat when she opens the box afterwards? 50%? 100%?

I know this article is a bad source, but why do scientists and the press continue to use the provocative explanation of QM: "things don't exist unless you look at them at the quantum level."

According to QM, things don't exist until they are measured which is quite different (unless you are tied to an anthropomorphic interpretation of 'observer').

Since there is no formal definition of observer that in any way limits such to humans, an observer/measurer can in essence be any interacting particle in physics-- measurement is an interaction.

This specialist notion is so far removed from the lay-person's interpretation of an anthropomorphic observer creating reality wherever they look as to be nonsense. Especially since the intuition is likely to be applied at the non-quantum scale.

Systems of interacting particles are the norm, not the exception as our careful laboratory experiments are crafted to be.

It seems more like Scala syntax, which is much cleaner than C++ IMHO. But with Java becoming dynamic (and C++ techniques for same), is the future a smear of shared language features, like Bladerunner's cityspeak, or are these just intermediate forms as a new protolanguage capable of unifying these features comes into existence?

Does this use the rust ast? Ala llvm?

I keep hoping for a new age where editors can simply use the language itself to define structure.

So I agree that TBL himself did a great job designing HTML for exactly what he concieved: distributed documentation. It was not however a system designed for web applications. Almost immediately after it gained popularity, people wanted to represent shopping carts. Even the places where Roy Fielding's thesis on REST are well understood and applied, it is very difficult to turn documents into applications without implicit client server state.

Just because TBL is brilliant doesnt mean his work can be misapplied. Of course, i also blame the people who thought of scaling thousands of existing client server applications for a fraction of the cost: things like shopping carts and online banking. True, it drove the web to what it is today, but at great cost.

Here is another thought: if the web is so great, why are so many companies creating their own tablet/mobile app experience instead? It cant be because it requires less dev knowledge and effort?

Regarding Postscript vs web: I'm only talking about device independence. Specifically in the case of pixel perfect layouts. I am not talking about the layout constraint problem, which is extremely challenging no matter the technology. But layout constraints depend on a solid notion of coordinate system, which the web lacks. Device independence gives you that in postscript and SVG.

Besides, windows faces a similar problem of multiple resolutions and devices. How do they v&v? They set the resolutions the same for certain tests! Even if you do this for browsers, they cant pass the test. Yes, it would be nice if we could have device independent layout constraints as well, but even the simplest most constrained test not involving layouts fails. At least now, its close. Before ACID it wasn't even close.

If webdevs can't even rely on their browser coordinate system in the most heavily constrained case, how can they hope to trust it when they try to solve challenging problems of dynamic layouts across multiple resolutions?

Good points. We might be focusing on different evidence for good design. Certainly a system has to be tested -- the theory is not enough. But areas of TCP that were designed up front were things like being able to carry arbitrary payloads, including itself! This is what makes ssh and vpns possible. By contrast, many web protocols break when tunneling: soap within soap.

Also, for those unfamiliar with the actual process of protocol development back in those days, it was a wire protocol, which meant formal modeling and testing. Sure, it doesnt catch everything, but the web is far less formal. For example, the w3c originally said it wasn't going to provide an XML parser reference implementation because any graduate student should be able to code it up in two weeks. WTH?! While I don't doubt that is true, in practice it has meant that dozens of slightly different parsers were written, leading to hundreds of slightly different incompatibilities. Anyone who has had to integrate two different XML stacks will know.

I use Ruby, which was inspired by smalltalk; modern Java is also becoming much more functional.

In some ways, it has taken the larger community 20 years to understand Kay's vision. Also, he always said that the systems he worked on were prototypes -- he's commented before that he fully expected real-world systems to have surpased his long ago.

But now we have Ruby, Node and Rust. Even Java and Spring.io have dramatically reshaped things towards a "smalltalkish" future. So I still put a lot of weight behind some of Kay's observations of the industry.

no, it doesn't. Having multiple independent implementations is a PITA, but that's why you have testing & validation labs along with standards. Take windows graphics driver labs... They test for pixel perfect compliance of output across hundreds of vendor implementations. Contrast that to the web where it took a separate group outside the w3c to embarrass browsers with the ACID2&3 tests. Now separate browsers look a lot closer in output.

Devs are trying to fix these ecosystems: why does react use a virtual dom? Why do we need css resets? Why do we need js shims and polyfills? Because its the only way to come close to normalizing the platform.

But have you ever wondered why you expect no two browsers display the same image? Postscript met that bar and is just as old as the web. Why didn't the w3c base the web on device independent coordinates instead of this confusing and unpredicatble layering of partial scalars and "angle subtended by a pixel on a 96dpi surface at a nominal arms length from the surface" crap? No one could have made a reference implementation off those requirements, much less a consistent verification & validation suite.

And no offense to TBL, but HTTP didn't even survive first contact with netscape's vision of shopping carts. Cookies? An elegant solution? Or simple a new hell of tunneling client/server state over a supposedly stateless protocol. HTTPS everywhere requires long lived sessions as the basis?!? No wonder people are heading towards web sockets, etc. webapps are client/server apps -- HTTP was always grossly misapplied to them.

Webdev is hard, not because I'm building beatiful bridges in the sky that are "good enough" poetic balances of constraints while coming in on time and on budget... Webdev is hard because of all the underlying assumptions I constantly have to check and recheck because I can't rely on them as an ME would (or hell, even as a backend J2EE engineer would). This is why some of us lament that people don't know the stack all the way down, because we have to in order to solve real problems. Every abstraction leaks, but hell, web abstractions are flipping sieves!

No, the thing that "works incredibly well" is not the web, but whats under it that lets us make so very many mistakes and yet keep on trucking.

Again, sounds nice, but an ME wouldnt be so cocky if he had to smelt his own materials and quality grade them before even starting to build the bridge. ME's get the benefit of a older, more mature industry that surrounds them and enables them to make rational decisions. See how quickly that goes to hell when getting substandard parts from a sketchy supplier. Then you can see the schedules and the budgets go to hell.

Multiply this times 100 and you are just about in the same situation as web developers. Maybe in 100 years, an ecosystem will grow around to support us? I can only hope. For now, i cant even rely on xml to be marshalled the same unless i control both client and server.

This sounds like Engineering, but be aware that in mechanical engineering the requirements are well-defined for materials and load. Consider the famous bridge resonance problem and you will see why wind resonance is now a required subject for structural engineering.

ME has an advantage over CSE in this regard because in CS the requirements are usually very poorly stated. About the best and most rigorous requirements you get are from mathematicans, but most devs and managers now certainly view that as wasting resources.

To make not to fine a point of this, I always like to turn to Alan Kay's comparison: TCP/IP vs the web. When was the last time any human technology like TCP/IP scaled so well and so invisibly, it's like air we breathe without even thinking about it. The web in contrast was the work of rank amateurs.

Alas, mathematics is really the "good enough" standard we in CS should strive for just like physics is the "good enough" standard behind ME and EE. Unfortunately as CS opened to the mainstream, I think a deep fear of mathematics led us to view this as "over engineering" even when it wasn't. The results are that the majority of the web is woefully underengineered, requiring far more money and time for inferior products.

We know they are inferior, because even the simplest gui application has more consistency than a web variation of it. And that's what marketing constantly compares things too when they can't understand why the web sucks as much as it does.

"Good Enough"? Please! For the last 20 years we haven't even come close!

Cool! I'm curious about the traffic patterns -- for example I see them slow down towards areas of complexity and speed up on straights.

Is this just an emergent property of the number of control points on your traffic curves, or was it intentional?

It would be cool if some kind of max-flow algorithm were applied to generate realistic traffic flow speeds; a kind of baseline throughout measurement for the road system geometry without further detail.

Morning people tend to get slower later in the day. Night people actually tend to get faster.

(There is some research that backs this up: http://www.personal.psu.edu/afr3/blogs/siowfa12/2012/09/earl...)

Know yourself and work during your peak time, not someone else's.

Also this!

One of the things that makes me fast is something that was a premise that was very slow to start with: "every error means something, no error is random, once you understand the error completely, you usually also understand the problem."

Almost every time I have ignored an error without understanding it, it has come back to bite me a hundred ways until I finally get it. It seems faster to ignore the details and plow on, but those hundred missteps add up vs one sure step, so practice reading those errors and understanding exactly what they mean. When you know that you can choose to ignore them, but it's likely it will be faster to simply fix the problem.

I would also add: get to know your debugging tools really well. I'm constantly surprised how many developers still use print logging to debug issues with data structures. Sometimes it's hard to visualize what's going on in your mind or with the code, why not let the computer "play computer" and actually see what it's doing step by step.

We may not have the real time integration that Bret Victor demos, but a call stack, watch list and breakpoints are a beautiful thing when you know how to use them.

A REPL like Ruby's pry is also invaluable for exploring return data and playing with data access syntax right in the console without long tedious trial by error sessions. (I know this annoys the purists who think you should know the data structures beforehand -- they are right; if you know what you are doing, of course you'll be fast -- but sometimes even the smartest of us don't know a service api changed without popping the hood.

Use all the tools you can to understand what your code is really doing, not just what you think it's doing.