What? This includes my kids’ Honor-branded phones, and as far as I know, a significant portion of the kids in their middle school, as Honor has been proposing phones with a great value for a few years, and they are popular in that population who are usually not getting the top-of-the-line models.

I could also have titled this blog more provocatively as “Google denies basic security to their customers,” “Donald Trump throws millions of kids in hackers’ hands,” or “Evil Americans exercise extra-territorial power over people around the world.” There are plenty of opportunities here to be angry, but the problem is elsewhere.

There is here a trust and liability issue. When I buy an Android phone, I expect some service from the vendor, but I also expect some services from Google. In my professional life, I am battling for improving IoT security, making updates mandatory and secure, among other things. Until now, this was a battle against slackers and profiteers, but today, politics is getting in the way. If hackers benefit from this, who can be held liable? Is this just Huawei? Doesn’t Google share some responsibility for stopping their support? My kids have done nothing, for sure.

Most comments seem to emphasize that Google dealt a big blow to Huawei, but Google has also dealt a big blow to themselves: Huawei didn’t cut my kids’ updates, Google did. This really has some consequences on the Android model: When you buy a phone with Android, you introduce a dependency between you and both the device vendor and Google, and you will be a collateral victim if their relationship turns sour. This almost sounds like Apple; when you get an iPhone, you belong to Apple, but at least, only to Apple.

It makes me rethink seriously my dependency on Google, so it’s time to take some strong decisions. I will switch my family streaming subscription from Google Play Music to Spotify, just to make sure that my kids still enjoy music on their unsupported phones. And if this madness continues, I will move them to Huawei’s app store as well…

In this early 2019, the Road to Bandol can be quite dangerous, as exemplified by the video below:

Yep, that’s the Bandol toll barrier burning during a gilets jaunes demonstration. I am not sure to be fully sympathetic to these gilets jaunes, but they represent the French way to signal major unease in the population: rioting.

What they want is not clear, but what they express is very clear: it was better before. And I have to admit that the latest serious books that I have read kinda make me feel somewhat like this:

• Bruce Schneier’s Click Here to Kill Everybody: Security and Survival in a Hyper-Connected World promises us an IoT apocalypse that sounds just plausible to me.
• Yuval Harari’s Homo Deus: A Brief History of Tomorrow promises us another dystopian future, where AI is the scary thing, and gives a good background to the gilets jaunes by his description of the current failure of the capitalist religion.
• Research book Agnotology: The Making and Unmaking of Ignorance provides chilling insights into how fake news is just one of the ways to build ignorance of the masses willfully for the benefit of a few.

I guess that the year 2019 is going to be interesting, but it takes me a lot of positive energy to be optimistic about the near future. But then, who knows, because

The times, they are a changing…

So let’s go for a good change.

• The device performs its tasks normally, but the attacker also runs other software on it, for instance to make it participate to DDoS attacks.
• The device apparently works normally, but its behavior is somehow altered, for instance by providing wrong information.
• The device doesn’t work or obviously dysfunctions, for instance a car that won’t start.

A second factor to analyze the consequence of an attack is the duration of the attack, or the delay until recovery. Here, we can consider four situations:

• Until next reboot. I am confident that the firmware hasn’t been modified, so a reboot will remove the attack vector from RAM and address the problem.
• Until next hard reset. I am confident that the device will not boot on modified firmware, so a hard reset will restore a « good Â» copy of the last known correct firmware.
• Until next update. I am not sure about the full firmware, but I know that a firmware update will remain possible and will address the issue.
• Until replacement. The firmware update mechanism is corrupted as well (or the device is permanently damaged), so the only solution is to replace the device.

We could go further, but let’s stop here for now. The impact looks essential, but the differences between the three scenarios aren’t that great. An obvious dysfunction is bad, but a device whose behavior has been altered by an attacker can be just as bad, and a device that is controlled by a hacker can easily become dysfunctional. In all three situations, it is obvious that some fix is required.

That’s where duration and recovery are important. The two first options (reboot and hard reset) are only temporary fixes. Even if the attack is transient and can be removed, the vulnerabilities that made the attack possible are still present, and the attack can be reproduced easily. Ideally, a reboot or reset/restore must be accompanied with some operational restrictions (like a “safe mode”) until an update is performed.

What we are analyzing here with recovery methods is resilience, or according to Random House, “the power or ability to return to the original form, after being [attacked]”. It is a valuable property for systems that are submitted to high levels of stress. Resilience is about recovery, in opposition to resistance, which is about protection.

Resilience and resistance are complementary. Resilience is often considered easier to achieve than resistance, but maybe more importantly, resilience may still happen when resistance has failed. Even if an attack on a system has been successful, its recovery is possible is the system is resilient to that attack.

We can here use an analogy with resilience against natural disasters. Although a hurricane can cause massive destruction to coastal areas, (resistance is limited), most U.S. coastal areas are resilient against hurricanes because hurricane evacuation routes have been defined, and shelters are ready to host evacuated people. Such resilience measures rarely fail, and we are shocked when this occurs, like in New Orleans after Katrina.

For an embedded device, resilience is mostly about:

• Secure boot, to restart from a clean sheet upon reboot, and detect a potentially persistent attack.
• Firmware update, to load a new version that is not vulnerable to the attack.

More generally, resilience can be achieved through simple infrastructure means like roads and shelters. In the case of connected devices, resilience can be achieved through low-level features, within or below the operating system, and highly independent of the use case.

However, although resilience mechanisms are simple, they also need to be very robust. A hurricane shelter must be built on high ground with strong material like reinforced concrete that offer strong guarantees of resistance against a hurricane. Similarly, the secure boot and firmware updates of a connected device must be designed and implemented to resist attacks. In both cases, this resistance is easier to build because it is applied on a smaller scale, and it is mutualized:

• Smaller scale. A shelter is a single building, typically used for other purposes (like a stadium) that is relatively easy to reinforce. Similarly, a secure boot is a small mechanism, so is the security-critical subset of a firmware update mechanism. These mechanisms offer a small attack surface, and are therefore easier to protect than an entire software stack.
• Mutualized. A shelter is shared by all members of a community, who will use it together in case of emergency. Similarly, secure boot and firmware update are independent of the device’s role and application. The development and reinforcement efforts can therefore be mutualized, reducing the cost for every device.

Resilience must be proactive

Resilience is the capacity to recover from an attack, and as such, appears to be a highly reactive technology, that comes after the fact. It is of course true that resilience mechanisms are triggered after the fact, but in order to succeed, they need to be proactively prepared.

Just like evacuation routes and shelters need to be planned in advance and designed to resist a hurricane, resilience measures in IoT devices similarly need to be prepared beforehand. A firmware update mechanism is crucial, and it needs to be prepared with great care proactively. In particular, this mechanism must be designed to be highly resistant against attacks.

In the world of connected devices, we know that resistance to attacks will be difficult to achieve, because it requires a very large investment from vendors to fix all vulnerabilities and make their systems resistant to attacks. Resilience, on the other hand, can be achieved on a wide scale with a limited budget, and has the ability to provide a strong basis on which IoT security can gradually be built.

Looking at this from a Java Card point of view, the main question is to understand the limits of Java Card. Should it be just a smart card framework, or a more generic security framework? Are there good reasons to use or not use Java Card on a particular kind of security framework? That’s what we explore in this last installment of my farewell to Java Card.

What makes Java Card good?

Or in other terms, “what’s the value of Java Card”? Java Card is a security middleware framework, which presents a portable interface to security functions typically provided by smart card hardware, and it is valuable because:

• It allows the development of reference frameworks (such as the SIM toolkit framework), and of reference applications (like Visa’s payment application), which can then be made available on all Java Card-compliant devices.
• It provides to developers a security framework that is relatively easy to use, where all the key functions (cryptography, authentication) are already implemented and available with predictible qualities on many commercial platforms.
• It includes a full ecosystem, including laboratories and certification authorities that are specific to the security community.

That may not sound like much, but when it comes to programming security environments, this combination is quite unique.

What can Java Card run on?

That may first sound as a strange question, unless we reformulate it as “Beyond smart cards, what can Java Card run on”?

I have stated for quite a while that Java Card is suitable for any dedicated security subsystem. Such subsystems obviously include all kinds of smart cards and secure elements. Now, what about other security subsystems:

• In preparation for the deployment of eUICC, mobile chip vendors are getting ready to integrate a security element within the main mobile chipset (as they do with all new promising technologies). Here, the idea is to include secure hardware, similar to a secure element’s, and to use some kind of TEE to protect its access. This kind of security subsystem is quite obviously a Java Card target, at least because it will most likely need to support the SIM Toolkit Java Card framework.
• Going a step further, Java Card could run on any Trusted Execution Environment. Some experiments have been made, showing that Java Card could be successful in that area. The debate is here whether this extension of Java Card’s realm represents a risk (for the smart card/secure element industry) or an opportunity (for the security subsystem industry).
• Going even a bit further, Java Card can run on any system that offers virtualization and the ability to have a dedicated security VM. This could be very useful in particular for low-cost devices, where it doesn’t make financial sense to include a secure element or even a full-fledged TEE. Note that such a dedicated VM could still achieve a good security level, by leveraging hardware mechanisms like TrustZone (now available even on Cortex M cores), or software mechanisms like formally proven software stacks.

Note that such extensions could require an evolution of the Java Card platform, at least because the memory model of these chips is different from the model used in secure elements. In addition, some additional features may be required.

What uses for Java Card?

The final step is to combine the value of Java Card with these opportunities: How can Java Card bring significant added value in these areas? We can take a look at a few use cases:

• On mobile devices, eUICC is likely to be a game changer. The combination of secure element technology and TrustZone in a mobile processor allows the implementation of UICC-like functionality, and the flexibility required to manage the environments provided by several network operators can be easily addressed with Java Card, since most operators already use the technology and have applications ported to the platform. In addition, this secure environment could be leveraged in other ways: (1) the TEE is not clearly established today, so it could be replaced by this environment, which offers similar or higher security features; and (2) this secure environment could be leveraged to host the applications that run today in the mobile device’s embedded secure element, if implementers are able to prove that they can reach the required security level.
• In the IoT market, the opportunity is to address the security of endpoints (the things). This market remains wide open, with no established standard. Most actors also have limited security know-how, and development cycles are very short. The Java Card ecosystem can here prove to be an essential competitive advantage, as it is relatively easy to develop Java Card applications and evaluate their security. Yet, in this market, we are missing a category of actors that would build the basic security services and a framework to deploy them easily on top of the existing Java Card and GlobalPlatform frameworks.

I am sure that there is more, but these two markets represent the major opportunities available today.

Long live Java Card!

Java Card technology has dominated the smart card industry for a while, and it now faces the same challenges as this industry, which may also be a great opportunity. Security is becoming a priority in areas like mobile phones and IoT, but secure elements are being challenged by new technologies for the implementations of security subsystems.

Java Card has the ability to be one of the technologies that will bridge the “old” smart card world with this new world, and I will close this series by wishing the best to the Oracle, the Java Card Forum and the entire Java Card community, hoping that they will be able to seize this opportunity and keep Java Card great for many more years.

These 20 years have been quite an interesting ride. Java Card is an amazing technology, just as successful as it is understated. Java Card has been deployed on over 15 billion devices since the first deployments in 2000, its deployment numbers have been growing steadily for 15 years. With the current movements in the SIM industry, it is hard to guarantee that this growth will be sustained over the next years, but Java Card is at least guaranteed to have a very fat and very long tail before it disappears.

I will publish a few entries on Java Card, starting here with a few comments on how improbable this success has been over the years.

An immature technology for an immature industry

Initial work on Java Card started in 1996 at Schlumberger’s research team (now part of Gemalto), as all card vendors were looking for solutions to run scripts on smart cards, mostly for supporting the SIM Toolkit framework. At the time, every major vendor had developed a proprietary solution, usually based on an existing programming framework.

In 1997, smart card issuers were starting to ask for interoperability between vendors. The Java Card Forum was founded in the spring as an answer, although few of its members were convinced that it was the way to go forward. Sun Microsystems was invited as owner of the Java technology, smart card vendors became Java Card licensees, and Sun Microsystems took the responsibility of managing the specification and related technologies (reference implementation and compliance kit). Sun didn’t have any experience about smart cards, and in the first meetings, their representatives clearly showed it. Sun then hired Integrity Arts (a Gemplus spin-off) as consultant, and rapidly acquired them, getting expertise in-house.

Java was not well suited to the smart cards available then. The language was easy to learn, but the virtual machine brought an overhead in both size and performance. At the time, it would have been possible to design a more suitable standard for programming smart cards, but the industry has not been able to organize in order to define such a standard.

Java Card became an API specification rapidly with version 2.0, but this version was short-lived, and quickly replaced by version 2.1, which also included a virtual machine specification, and allowed binary Interoperability between products. At about that time, the mobile operators became really interested, a SIM toolkit API was defined, and the deployment began around 2000.

15 years later, this adoption of a poorly adapted technology by an immature industry has become an asset. Because Java Card was a bit too ambitious at the time, and thanks to the continuing success of the Java language, Java Card has now become a mainstream technology, which in 2015, fits the needs of the smart card market, and is present on most open smart cards, and roughly half of the microprocessor cards sold worldwide. In the end, it pays to be inadapted.

Mostly an ecosystem

In the late 1990’s, the first marketing sentences for Java Card were directly taken from Java, like “Millions of developers”, or “Write once, run anywhere”. The one specific marketing argument was about “Running multiple applications on your card”. Fifteen years later, here is a factual status:

• Hundreds of developers (tens of expert developers), mostly working for smart card vendors or for a few specialized consulting firms.
• Most applications written for a single card, or at least for a single issuer.
• Most applications written by a card vendor, and running only on a single vendor’s cards.
• Most cards running a single application.

The next question is: why is Java Card still around if it is not used? Well, in fact, it is being used, just not in the ways that people initially planned. In fact, an essential factor in the success of Java Card has been the certification of cards. In many cases, once a card is deployed, there is no (efficient) procedure to update the card to fix a bug or a vulnerability. Therefore, cards are heavily tested before to be deployed, and most vendors require several levels of certification, including a functional certification and a security certification.

These certification processes are costly, both in developer resources and in laboratory fees. Over the years, efficient certification has become an essential aspect of card development, and Java Card facilitated this in several ways:

• A reference for core functionality. The Java Card specification defines a set of core functions which can then be used to develop applications (cryptography, I/O, storage, appication isolation and sharing). It then becomes possible to test separately these core functions (by evaluating a Java Card platform) and the application using them (by evaluating a Java Card applet). This can lead to economies of scale.
• Reference applications. Some issuers and actors, notably Visa, have written reference versions of their applications, which have been thoroughly tested on compliant Java Card implementations. Vendors who use these reference implementations can simplify the certification process.
• Building experience beyond developers. Laboratories, certification authorities, security consultants all have worked with many Java Card platforms and applications over the years, and now feel confident about their ability to use, test and certify such cards in different configurations. This is the ecosystem part.

In the past few years, the strength of this ecosystem has been a key asset for Java Card, together with the fact that it remains today the dominant platform for defining APIs for smart cards, regardless of the target vertical (once again an ecosystem aspect).

Not dead, not frozen, just slow and conservative

Another striking feature of Java Card is its lack of evolution. The core features of the platform have remained vastly unchanged since release 2.1. Several attempts to make the platform evolve have failed over the years:

• Java Card RMI was introduced with Java Card 2.2, with the objective of making it easier to design new smart card applications, but it was never adopted by the community. Support of Java Card RMI has been optional in the latest releases, and it was close from being deprecated a few times.
• Java Card 3.0 Connected was a bolder attempt at reaching new markets, this time arounod Smart Card Web Servers. This specification is very nice, and it defines a Web application model that can be implemented in half a megabyte, all included (OS, VM, Web container, content management, and a few apps). Yet, smart card web servers never caught, and this specification has never been implemented in a real product since its 2009 release.
• An annotation framework for security interoperability was added recently, but the industry hasn’t been able to agree on a semantics for these annotations, and it has not been adopted.

In the latest 3.0.5 release, we have attempted to add a few simple things, hoping that they will be adopted, but this will only happen in a while, because of another interesting specificity of Java Card. It takes around a year to develop a new platform after the release of a specification, at least another year to get a full certification (functional and security), and another year to sell, produce and deploy it. That’s about 3 years between the specification and the actual availability of products.

This development rate partly explains the slow evolution of Java Card. The smart card ecosystem globally evolves very slowly, and to observers who are used to Web-like evolution, it may look life completely frozen. However, it keeps evolving at its specific and very slow rate. Since 2009, Java Card has become much better adapted to contactless cards, it has adopted a number of cryptographic technologies, and a few other features have evolved to follow the evolution of smart card hardware. Such changes are invisible to the non-specialist, but they keep the Java Card framework in synch with smart card technology, and this is what really counts.

With iPay, Apple just proved to many people that mobile security can have a favorable economics. By embedding a biometric sensor and putting their critical credentials on an embedded secure element, they have been able to negotiate a lower transaction fees on their payments and save millions in the future. Mobile security brings millions instead of just boring geek stuff? Now, that’s innovation.

Of course, the security of the iPhone 6 must live up to these high expectations. As much as the latest announcements bring a boost to mobile security, the announcement of a hack allowing a guy to steal a phone and use it “illegally” has the power to bring us back to the dark ages.

A few weeks ago, a friend sent me a link to the Cardis program, with the message “A bug in the verifier?”. Looking at the program, I saw a paper entitled Manipulating frame information with an Underflow attack undetected by the Off-Card Verifier, by Thales Communications and Security. This sounded like bad news, so I got a copy of the paper and read it.

The good news is that there is no bug. Nevertheless, reading the paper made me unhappy. As a consequence, the first version of this blog post was a flame, in which I qualified the paper of “dishonest, not innovative, and misleading”.

Publishing the flame triggered some discussions, with people at Thalès and with other people, in particular with Jean-Louis Lanet of XLIM. They provided me their views on the topic, and I have decided to revise my original flame into a more mundane and constructive post.

Dishonest, or just a bad title.

As mentioned above, the paper’s title is”Manipulating frame information with an Underflow attack undetected by the Off-Card Verifier”. However, section 3.2 of the paper surprisingly starts with the sentence: “The standard Oracle bytecode verifier detects the underflow attack”. There is no other reference to a verifier that would not detect that attack, and that makes the title sound really dishonest, at least the “undetected” part of it.

More specifically, it seems that the objective of the paper is not to point to an issue in the off-card verifier, as the title seems to, but rather to point to the fact that there exist ways to bypass the verification. A revision of the title in the proceedings would do just fine.

Not innovative, or not published.

The paper describes an attack that uses the dup_x instruction to perform a stack underflow. This stack underflow allows the authors to access the content of a stack frame, including the current context, and to change it. The question is: is this a new attack? As a virtual machine implementer and evaluator, I would say no immediately. This attack very easily comes to mind as soon as you know the content of a stack frame (as an implementer does). This attack has therefore been in my “bag of tricks” when I was an evaluator, and was even quite a practical one.

Now, the smart card industry is secretive, and evaluators are even more secretive. Very few actual attacks have been described in scientific papers. It seems that the attack to mention stack underflow is the EMAN2 attack described by Bouffard et al. at Cardis in 2011. However, they only abuse the return address, labeling the current context “unknown value”. In that context, it seems that this paper describes something that has not been published before. For this one, my apologies, as I forgot the secrecy of the industry, and kudos for actually publishing this rather than keeping it secret.

So now, the community knows that, unverified bytecode can lead on some cards to allowing an attacker to run attacker-provided code in a chosen context. This is about as bad as it gets, and now, additional attacks will fall in my “tricks” category, in which an attacker/evaluator uses a new illegal bytecode combination because the previously known ones don’t work on a card. I hope that we won’t see more scientific papers about such tricks (see Jean-Louis Lanet’s second comment about this).

Misleading, or missing its target.

Of course, since the off-card verifier catches all of these logical attacks, they are not supposed to occur in real life, where bytecode verifiers are systematically used.

Let’s make a parallel between two typical components, RSA and a virtual machine. RSA is a crypto algorithm, a function RSA(K,M) that takes as input a key K and a message M, and produces a result. Similarly, a virtual machine is a function VM(P,I), where P is a program (in bytecode) and I some input data, and produces a result. The RSA and VM functions share something important: the key K and the program P need to obey some properties. If the don’t, the algorithms don’t work.

If the RSA prime factors are not prime numbers, or if the program provided to the VM is not valid, their results may not be satisfactory: although they are functionally correct, they will not have the expected security properties. In order to avoid bad keys and bad programs, we use appropriate algorithms to perform primality checks, and to verify bytecode. Just as it is important to ensure that an attacker cannot tamper with the key generation scheme, it is important to ensure that bytecode is verified before to be executed. But is it sufficient?

Well, that may be sufficient if you run your VM or your RSA on a device that is physically protected from attackers. But on a smart card, it isn’t sufficient, at least for RSA. There have been many attacks published on smart card implementations of RSA, using fault induction, power analysis, and more. The VM is just as sensitive to these attacks; in particular, combined attacks can be used to dynamically create illegal code on a card, as mentioned in the paper.

If we continue the analogy, RSA is still used on cards, even though attacks exist. During security evaluations, the robustness of the implementation is verified by a lab, which ensures that well-known attacks don’t work. Naturally, the same thing must be done with the VM: a high-security implementation must include significant countermeasures against attacks on VM, such as combined attacks. The implementers have the choice of the countermeasures; they can include additional checks in the virtual machine, attempt to detect the faults, or both, or anything else, as long as it works.

According to my discussion with Thales, this is more or less the point that the paper tries to make, in particular in its last part. However, the paper insists on the malicious application rather than on the attacks, especially in its last sentence:

Finally, this paper shows that during open platform evaluations, it is necessary to take into account malicious applications, and make detailed analysis of each requirement included in the platform guidance.

I definitely agree on the platform guidance aspect. Requiring bytecode verification is not sufficient, as the management of the verification context is also important to avoid logical attacks. However, during evaluations, malicious applications are not the real issue, attacks on the virtual machine are. In that context, malicious applications are for now tied to combined attacks, where a fault triggers the logical attack. What the community often fails to understand is that, on a smart card, a virtual machine is a component like any other: it can be subject to physical attacks. And that’s the reason why specific countermeasures are required.

So what?

In Cardis, the proceedings are collected after the conference, so authors have an opportunity to revise their paper before publication. After our exchanges, I hope that some revisions will be made before publication, in particular on the title and on the last part (making a stronger point about evaluation requirements). And so, I replaced my flame with this.

So, there is an age limit to have a gmail account. Uh oh. The bad thing for me is that Ethel gets punished for doing what I told her to for years: don’t lie about your age. She has been waiting to get a Facebook account, and she will get it in 40 days, when she turns 13. Sadly, her gmail account will have been deleted 10 days earlier, with all her data, and without any way to get her e-mail address back.

Being bugged by these no-backup and 29-day clauses, I tried to get in contact with Google. Well, this sure isn’t simple. Basically, you have to use the forum or fill a form. In both cases, you get a robot answer reminding you the rules and ignoring your question. Just the worst service you can imagine. I am not optimistic about saving Ethel’s e-mail.

Of course, I set up her account two years ago. At the time, there was no age question, and I didn’t think for a second that there was an age issue to get e-mail. Apparently, the age thing was in the conditions, but not even explicitly; according to some internet posts, the wording was like “you must be old enough according to laws blah blah”. Once again, I didn’t think that there was a law against e-mail for children. Well, there isn’t, but your gmail account also gives you access to other Google services, including Google+. And there, there is a law (American, not French). So now, as soon as Google realizes that you are underage, they cut you off. Period.

Now, a few more questions and, in some cases, answers:

• The school invited a 12-year old to Google+? Well, yes, school fail. I will be on their case, to figure out how this could happen. Most likely, this is just one person making the mistake, and the others not realizing what all this implies.
• What do you do with your Android phone if you are under 13? Well, without an account, many apps won’t work well. So I guess that the best thing to do is to lie about your age. Thank you, Google, for this nice educational help.
• Can’t parents get a contract on behalf of their children? In many cases, it is possible, but not with Google (or Facebook). The reason is Google+ and the COPPA law, which protects children on Internet. Since Google+ doesn’t comply to COPPA, it cannot be accessed by children under 13, even with an authorization. And because Google stupidly links Google+ and gmail, youlose.

Now, what is this thing about liking to pay? A few weeks ago, I signed up to Amazon Cloud and had some issues with the music player. I sent a support request, and somebody from Amazon called me the next day on my mobile. I was baffled, since I only expected an e-mail answer. The guy couldn’t help me, because the feature wasn’t working. He noted it, and told me that he would let me know when the issue is resolved. And you now what? He did.

This is just good service. i don’t expect anything close to it from Google. I’ll let you know what I get. I didn’t pay for Amazon Cloud (or at least, not yet); however, I am a faithful Amazon customer, spending a lot of money on their site year after year. And I believe that Amazon wants to keep customers, which motivates them to have decent support. For Google, Ethel is not a customer, she is just a piece of data that can be sold to customers. And that just isn’t a good enough information to pay for.

So, in the end, I become every day more of a fan of paying for services I use, instead of relying on ulltra-complex business models. Would it be possible to have companies that don’t use random advertising but don’t make me pay for it? Once again, simple customer-vendor relationships sound good.

Google fail.

This article led me to make the link with the hack that was recently publicized. Beyond hacking, dying is definitely a good way to lose your digital assets. In my personal case, my wife and kids don’t know my passwords, and they are even aware of all the accounts that I have in many places (actually, I am not fully aware of that). This means that, most likely, nobody will inherit my data, unless I do a digital will.

A rapid Google search has shown that other people are thinking about it, including companies offering “advance funeral plans”.

Of course, there are a few startups in the area. I like the deathswitch idea: they will regularly send you e-mails; if you don’t answer them for 30 days, they will send an e-mail to other people, including personalized messages that you have provided, to let them know what to do after your death. This is a service you better not forget, but it gives you an opportunity to tell them that all your passwords are stored in file “passwords.txt”, with password “1234”.

The legacylocker offer is much more complete, as it allows you to store all kinds of important information, who will then be disclosed to your legal heirs after your death. And in that case, they will need to provide a certified death certificate to access the information. This one looks good, but I am not sure that they provide a worldwide guarantee. Anyway, they would be nicely complemented by a death switch reminding your heirs of the existence of this digital locker.

Not sure that I will move ahead with such services. I have a personal preference for a NFC-enabled smart card stored in a safe, just because physical objects are a good bootstrap to digital objects (and maybe a little bit because I like smart cards).

Well, that may change. researchers for the University of Pittsburgh’s RFID Center for Excellence have invented a on/off switch for cards, that simply requires you to put your finger on a specific spot on a contactless card to allow it to work (see a picture here).

Comment on the various articles around the topic are quite typical, ranging from the “This is very dumb because it is unpractical” to the “You have to give up some practicality for security”, and all variants in the middle. I would have liked to see the inventors’ arguments, but I haven’t found a reference to a paper/report.

From previous experience, user experience often wins, in particular when, like with contactless cards, practicality is a selling point of a technology.Also, since the idea is to protect your cards in your wallet, I would think that it is easier for security-conscious to use wallets that include some kind of wire mesh or other wave-blocking technology. Since the on/off switch requires you to actually get the card out of your wallet, it is more or less equivalent, and it only annoys security-conscious people. The other guys will still be able totap their wallet (until, of course, they start having several contactless cards in there, in which case this optimization may not work any more).

This invention does not look flexible enough. The threat of someone performing transactions without you knowing is not significant enough to justify this kind of generalized measure for payment cards. On the other hand, it sounds much better as privacy-protecting technology on ID cards, since an ID card. Ensuring that the data about your identity will not leak from your wallet is interesting, and since an ID card is typically pulled out of the wallet before to be used, the technology is not an annoyance any more. But of course, in research like in politics, the fears associated to credit card theft remain more powerful than those associated to privacy protection (although identity theft is gaining traction).