- Extracting demand curves across 240 categories by age
- Largest quantum computation ever
- More instances in which sheer human ingenuity surpasses Moore’s law
- Google’s replacement value: a thousand man-years.
- On the hardships of data analysis to prove reverse engineering: chess edition.
Holding a contrarian view could carry out great benefits: there has always been a need for a procedure to protect any innovative software from reverse engineering that at the same time allows for its appropriation and exclusionary use, as well as it precludes any imitation of its functionality, implementation details aside. This procedure really exists, it’s the proverbial patent: a negative right, temporal and exclusionary, to protect any novel intellectual property in exchange of publishing enough information to replicate it. In some sense, it’s the only open window for the ordinary citizen to introduce its own personal legislation, a strong general purpose tool, however double-edged it may be.
The frontal and so popular opposition to software patents transcends the software world: indeed it can be found in past centuries and for other technologies; for example, the most cited case, and therefore so full of hyperbole, is the decades-long delayed adoption of the vapour machine due to the machiavellic use of the rights conferred by one of its patents.
Regarding current practices, a detailed study of the descriptive statistics of the use of software patents shows that they have been the fastest growing category for decades, though software companies have not been granted many of them because the biggest appliers are other industries similarly intensive in their use of IT capital but also with a strong record of filing for strategic patents. Note also that in the absence of strong patents rights, custom and common sense have required the use of copyright protection (which also does not need to give up any source code) even if it’s a far weaker protection: in fact, both of them are complimentary, but their actual use is substitutive, because whenever one of them is weakened, the other gets used much more.
From a purely economic point of view, studies show a statistically significant increase of the stock value of the software patent-owning companies and they happen to be a mandatory prerequisite to enter markets in which the incumbents already own strongly interdependent patent portfolios. And contrary to general opinion and practice, their use in software start-ups is, overall, positive: they increase the number of rounds and their amount, as well as survival and valuation in case of acquisition. From a strategic point of view, software patents raise barriers to entry acting as a deterrent mechanism to the kind of competition that just follow profits without investing in any kind of sunk costs in the search of technological advances: in short, an increase of 10% in the number of patents entails a reduction in competition between 3 and 8 per cent. And even if their valuation is a very complex matter, the intrinsic value of software patents is higher than that of the rest of patents.
In practice, the biggest burden in their granting and defence is the search of prior art: that is, even under the assumption that the inventor is operating under the principles of good will and full coöperation, he can’t get access to the full prior art because most software is developed internally for companies and never sees the public light. This gives rise to a great number of non-innovative and trivial patents, and others that ignore the prior art on purpose, a matter which sometimes can be difficult to settle (vg. Apple Multi-touch, Amazon 1-click). Fortunately, malicious uses don’t fare well in the Courts of Justice: the strategies of the so-called patent trolls aren’t successfully long-term, that is, those who are operating within the letter of the law but against its spirit, and are using the patent system to extract rents from others that are using them for productive purposes, a problem that carries a very high economic cost. Only their fair use brings a true premium to business valuations, that is, building a good patent portfolio that does not enter into practices of dubious ethics like filing for patents that only pursue the cross licensing with competitors to avoid paying them for their intellectual property.
The fastest way to begin to learn how to write software patents is to start with this set of documents. And since real learning only happens from the best sources, there are lots of noteworthy software patents, examples to follow for their high degree of inventiveness and the business volume that they backed and helped generate:
- The first practical algorithm to solve linear programming problems.
- DSL, the technology that allowed for the cheap diffusion of broadband connectivity.
- Pagerank, the famous patent that laid out the foundations of Google; it also takes into account the method to quickly compute the rankings of indexed pages.
- Lempel-Ziv-Welch, the well-known algorithm for lossless data compression.
- In the cryptography field, the RSA and ECC algorithms, at the core of public key cryptography.
- The beginnings of digital sound would not have been possible without the DPCM method or FM sound synthesis, and the patents of MP3 compression are dispersed across many companies.
- In the storage field, it’s curious how RAID was invented a decade before its definition as a standard.
- Regarding hardware, we shall not forget the patents awarded to the transistor (Shockley and Bardeen) and modern magnetic storage enabled thanks to the GMR phenomenon.
- Efficient Secure Two-Party Protocols. Good introduction to the paradigm and the techniques of secure computation, with an emphasis on the proving methodology. Although it doesn’t cover all the relaxations and variations generally used in the literate to get significant speed-ups, the authors really do care about the efficiency part to the point of providing empirical results to prove the feasibility of two-party secure in current computers
- Composition of Secure Multi-Party Protocols. Written by the top contributor of the field, it’s a good survey that covers up the subject in sufficient detail for a quick introduction. A bit old, although the theoretical treatment of the subject has survived the passing of time, but it lacks the newer results on the limits and impossibilities on concurrent general composition and information-theoretically secure protocols.
- Algorithmic Cryptanalysis. Forget all the previous books on cryptanalysis, with too much focus in the classical ciphers. This is the most technical and advanced book on cryptanalysis, reviewing all the techniques with lots of references to modern and more detailed papers. The coverage of lattice-based cryptanalysis and algorithms deserves special mention. IMHO, much more C source code will be preferred in the next editions.
I’ve been updating the list of presentations on smartphone security with 25 new links. A few noteworthy mentions are the newer exploit writing techniques, new OSes and their vulnerabilities (Windows Phone) and the emphasis on researching the distinct mobile network protocols (femtocells, satellite, GPRS and GSM, …).
- The R Inferno: a programming manual in a very literary style
- Category Theory for the Java Programmer
- Voyager 2, debugging across planetary systems
- A Graphical Notation for the Lambda Calculus with Animated Reduction
“You can see the computer age everywhere but in the productivity statistics.” Robert Solow (1987 Nobel Prize in Economics) summed up with this harsh remark his celebrated “productivity paradox”, which itself started a research frenzy to find counterexamples to refute it. It took more than a decade, because there is a strong inter-relationship between information technologies and the human capital that they are at the same time complementing and substituting for, but at the end these affirmations could be discredited. Furthermore, another profound change with much more evidences against the paradox occurred parallel to the wide expansion of computer technology, which was also easier to measure and prove: the global spread of the digital mobile phone. To get a better understanding of its true economic impact, nothing better than to sum up the relevant literature regarding this topic.
From a purely microeconomic perspective, Jensen was able to prove that the introduction of mobile phones incremented the profits of North Kerala’ fishers to a whopping 8%, reducing at the same time the final consumer price by 4%: better communications enabled the access to wider markets, expanding the dealing possibilities of those offered by the previous local fish market, enhancing overall market efficiency via an stronger the law of one price. From a macroeconomic point of view, Waverman used statistical and econometric techniques to isolate cause from effect, to find that an increase of 10 devices per 100 in a developing country did add 0.6 points to GDP growth per capita and 0.5 to GDP growth: these results bring out the transformative power of technology to the the global economic activity.
And to gain a better understanding of how technological innovations are transmitted into the economy, I’ve put together a stylized model in an Excel workbook offering a mechanistic explanation of how a successful general purpose technology is able to impact economic growth in such a significant way: in the first sheet, a general Bass model is used to quantify the transition to digital mobile technology from 1996 to 2011 (taking care of network effects in a gross manner, better modelled using Becktrom’s law); in the second sheet, and by using the previously calculated penetration level of the digital mobile phone technology as one of the inputs, a neoclassical economic growth model (Solow-Swan) is utilised to explain its economic impact: note this particular model was the first used to introduce technological progress as a fundamental variable to explain economic growth, making it look like a component that increments the productivity of the labour factor and that also complements capital accumulation at the same time, itself divided in different periods of decreasing value to account for the technological depreciation process. The only negative aspect of this model is that technological progress is supposed to be constant over the full period of analysis, leaving aside the possibilities of a growing innovation rate, or a much more realistic decreasing innovation rate. In addition, other variables that are taken into account by the model are: capital depreciation, savings rate, population growth and the relationship between capital and labour in the resulting economic production. Besides, other technological changes could be analysed with the same Excel workbook, because they feature similar diffusion processes and economic impacts: the adoption of the car, substituting for horses; the diffusion of electricity; or the diffusion of computer, replacing the typewriter.
Later economic models supplement the previous one introducing the accumulation of human capital next to technological change, giving birth to endogenous economic growth theories that better explain the relationship between computer technology and economic growth: even if information technologies are mostly deployed for the purpose of substituting the labour factor, their true nature is incredibly complementary to human capital, but this is more difficult to prove econometrically. Last but not least, the entertainment potential of computer technology makes it to negatively redound in productivity growth statistics: for example, the 5 million hours that Angry Birds is played every day should also be counterbalanced in other ways.
Sure, it’s always feasible to write secure C code: for example, using the ternary operator (cond ? : x : y;) it’s possible to write statements so that errors are thrown whenever type mismatches are found at compile time, but it also would be very easy to accidentally bypass these software constructs. However, and for serious undertakings, it’s always better to rely on the existing tools that automate the many mind-numbing tasks that comprise a software audit.
Static code analysis features a long history (with the first lint tool dating back to 1977), but only the profusion of programmers from the last decade instructed in the paradigm of strongly-typed languages generated the expectation to get the same level of pre-execution bug detection for the weakly-typed languages. So strong is the impetus for static analysis in the C arena, that the whole Clang compiler suite is replacing gcc just because is almost impossible to develop static analysis tools for it. Nowadays, in the hall of fame for static analysis code auditing software tools, Deputy gets the top prize for the open source/free program, and Coverity for the commercial one, with Veracode being a strong-contender.
Coverity is a commercial spin-off of the academic work of Dawson Engler, whose papers are a must to not only understand how their tools work, but also other cutting-edge research subjects like symbolic execution. Coverity Static Analysis generates a higher number of false positives than Veracode’s, especially given that they charge so much, but neither of the two surpass the huge number that gets generated by the venerable PC-Lint. But this last one, and others like PVS-Studio and Parasoft C/C++ are still a must if you prefer on-premise software rather than giving away to the cloud your precious source code. Or if no external tools are available, at least consider the code analysis tool in Visual Studio.
On a different category, Deputy is an innovative software project that tries to introduce rigorous type safety based on annotations that are included within the code. I agree that it’s always a great idea to start introducing annotations whenever the codebase is in a nascent state, but it’s much more cumbersome whenever software projects are in an advanced state because it is akin to the tedious maintenance of code written by others. It also features runtime checks to detect those faults that couldn’t be detected at compile time. Or if having limited time available, you may consider just using splint instead of annotating everything.
At the end, I like to think that the most critical parts of the code should be minimized and subjected to formal verification efforts (see L4.verified) but always noting the implicit circular paradox of having to write a specification for the formal verification process, which is a just a program in itself. Because, who verifies the verifier?
- Crypto-coding like a Charm, in Python!
- Encyclopaedia of Windows Privilege Escalation
- Forward Secrecy for HTTPS
- Things you can learn while data-mining Facebook: the world is closer than we though, at 4.74 degrees of separation, and FB followers correlate with stock prices, but its userbase valuation fundamentals are still in question.
- Clayton Christensen on Disruption
- The Private and Social Costs of Patent Trolls
Every time an email is sent, it’s expected to be handled to its recipient, no matter what their service provider is. But in the first days, it wasn’t so simple: early commercial email services (CompuServe, Prodigy, Delphi, …) featured proprietary email services with no concept of an universal e-mail address, which in turn created technical barriers that originated the commercial practice of settling charges for email delivery between service providers. In other words, there were interconnection agreements which detailed the delivery charges between providers, bounding the two parties to periodically settle their accounting differences, much like in the other telecommunication networks (telex, fax, teletex, SMS and phone termination fees).
But the number of said required agreements grew exponentially as the number of service providers expanded, and so did the technical difficulties to integrate their different email services. X.400 was born to solve these issues, implicitly providing support to keep settlement scores between carriers and their multi-interface delivery technology (vg. the preferredDeliveryMethod attribute). In the end, X.400 didn’t really take off and was substituted in 1990 by the much simpler X.500 protocol: but not due to its tremendous complexity, but rather due to the decisive move of service providers to stop settling accounts between them so they could just use X.500 to interconnect their directory services.
As usual, it’s almost never about technology, which can be better thought as the child of necessity and will. The hassle of reaching agreements was getting so high with the growing number of service providers that their diminishing return stopped justifying the related bargaining costs, which in turn were precluding the emergence of the essential network effects from the growing number of email users (as per Metcalfe-Beckstrom-Reed’s Laws): that is, they were the real limiting factor blocking the growth of the early Internet. Nowadays, the only trace of these agreements survives in transit traffic agreements, in turn solved by peering agreements.
To sum up, notice the circular paradox that the history of email established, a curious tale of unintended consequences: free email begot spam, and spam beget the obvious solution to start charging for email to put an end on it. Whether the trade-off was correctly solved depends on whom you talk to.
Blogroll
- @altgate
- Alan Quayle Blog
- Analysis Mason's Insight
- Asymco
- Banda Ancha
- Barking up the wrong tree
- Chris Dixon's blog
- Cloud Four
- CMT Blog
- Collin R. Mulliner
- Consultant Value Added
- El sueño de Jardiel
- Feld Thoughts
- Financial Times Tech Hub
- Harald Welte's blog
- Lessons Learned
- Marc Andreessen
- Marginal Revolution
- Mark Russinovich's Blog
- Mobile Opportunity
- Mobile Phone Development
- Musing on Markets
- Renesys Blog
- root labs rdist
- Start-Up: the book
- Steve Blank
- TecnoEstrategias
- Telco 2.0
- TEXTOS
- The Catalyst Code
- The Economist
- Unenumerated
- VisionMobile Forum
- WSJ All Things Digital
