JavaScript has come a long way since I knew it as the “D” in DHTML. For any­one like me, who’s been re­luc­tant to use the lat­est syn­tax that could re­quire poly­fills or a tran­spiler, I’ve writ­ten this cheat­sheet to get you caught up on all the good­ness that’s widely sup­ported in mod­ern browsers.

I’ve made this page con­cise, with runnable ex­am­ples and links to fur­ther doc­u­men­ta­tion. If you have any ques­tions or spot any er­rata, please con­tact me.

Check out all these new built-in ar­ray func­tions! No more need for un­der­score or lo­dash!

These new key­words de­clare vari­ables in block scope (as op­posed to global or func­tion scope). Using const im­plies that the value will not change as the ref­er­ence is im­mutable. Use let if the value will change.

The ?? op­er­a­tor checks if the value is null or un­de­fined. No more need to use the !! check.

The ?. op­er­a­tor checks if the value is truthy be­fore call­ing the next prop­erty or func­tion. Extremely use­ful when deal­ing with op­tional props.

The async/​await key­words are here to save you from call­back hell. Use await to make an asyn­chro­nous call re­sem­ble a syn­chro­nous call, i.e. run­ning await fetchUser­Name() will not pro­ceed to the next line un­til fetchUser­Name() is com­plete. Note, in or­der to use await, you have to be ex­e­cut­ing a func­tion de­clared as async, i.e.

async func­tion fn(){ await fetchUser­Name() }.

These are func­tions that are bound to the cur­rent con­text. There are three main forms you’ll see in the wild:

sin­gle ar­gu­ment, sin­gle line, multi-line.

The sin­gle ar­gu­ment form does not re­quire paren­the­sis, and the sin­gle line form does not re­quire a re­turn state­ment; the re­turn is im­plicit.

The multi-line form re­quires a re­turn state­ment if the func­tion in­tends to re­turns some­thing. Multiple ar­gu­ments re­quire paren­the­sis.

Used for loop­ing over an it­er­a­tor. Similar to for…in ex­cept you don’t have to check for ha­sOwn­Prop­erty. You can­not use this loop­ing syn­tax on an Object di­rectly be­cause the Object does­n’t have an it­er­a­tor. Instead use Object.entries({}) to re­trieve an it­er­able.

Asynchronous it­er­a­tion was in­tro­duced In 2018. Much like Promise.all, it can be used to syn­chro­nize many asyn­chro­nous tasks. The ex­am­ple be­low shows 3 tasks hap­pen­ing asyn­chro­nously. The loop processes one re­sult at a time, in or­der; in this case, the quick­est tasks to com­plete are only ev­i­dent at the end of the it­er­a­tion.

for await…of docs

In 2015, ES6 brought classes to Javascript 🎉. Javascript classes are sim­i­lar to the classes you know and love from other lan­guages. Inheritance, class meth­ods, get­ters and set­ters, prop­er­ties, etc.

Get and set are func­tions that are called like prop­er­ties, i.e. per­son.age = 16; per­son.age > 18. These are very con­ve­nient when you need a dy­namic or com­puted prop­erty. And they can be used with both classes and reg­u­lar ob­jects.

Yay! You can now spec­ify de­fault pa­ra­me­ters in your func­tion de­f­i­n­i­tion. Works as you would ex­pect.

With a bit of ob­ject de­struc­tu­ing magic, func­tions can now have named pa­ra­me­ters.

The re­set pa­ra­me­ter al­lows a func­tion to ac­cept an ar­bi­trary num­ber of ar­gu­mentsas an ar­ray. It’s rec­om­mended to use this over ar­gu­ments.

Object.assign(target, source) merges two or more ob­jects into one. It mod­i­fies the tar­get ob­ject in-place, so if you’d pre­fer a new ob­ject be cre­ated, pass an empty ob­ject lit­eral as the first ar­gu­ment.

Alternatively, you can use the spread op­er­a­tor … to merge mul­ti­ple ob­jects to­gether: {…obj1, …obj2}, though bear in mind, spread will not call set­ters on the ob­ject, so to be the most portable, con­sider Object.assign. The spread op­er­a­tor can also be used on ar­rays as shown in the last code sam­ple.

Destructuring al­lows you to ex­tract val­ues from ob­jects and ar­rays through pat­terns. It is a com­plex topic with many ap­pli­ca­tions…far too many for me to enu­mer­ate, but I’ve shown some of the most com­mon uses I can think of.

Destructuring docs and MDN docs­func­tion f() {

re­turn [1, 2];

let [a, b] = f()

print(“a=“+a + ” b=” + b)

const obj = {state: {id: 1, is_ver­i­fied: false}}

const {id, is_ver­i­fied: ver­i­fied} = obj.state

print(“id = ” + id)

print(“ver­i­fied = ” + ver­i­fied)

for (const [key, value] of Object.entries({a: 1, b: 2, c: 3})) {

print(key + ” is ” + value);

Functions de­clared on ob­jects can use a new short­hand style that omits the func­tion key­word.

The two func­tions (fn1, fn2) are equiv­a­lent in the sam­ple be­low.

I’ve mostly skipped over promises be­cause async/​await is pre­ferred, but some­times you need to syn­chro­nize mul­ti­ple asyn­chro­nous calls, and Promise.all is the eas­i­est way to do it.

Also known as tem­plate strings, this new syn­tax pro­vides easy string in­ter­po­la­tion and multi-line strings.

A Proxy al­lows you to in­ter­cept get/​set calls on an­other ob­ject. This could be use­ful for watch­ing a prop­erty for changes, then up­dat­ing the DOM, or mak­ing in­no­v­a­tive APIs like the www proxy be­low.

Proxy doc­slet _nums = [1,2,3]

let nums = new Proxy(_nums, {

set(tar­get, key, value) {

tar­get[key] = value

print(“set called with ” + key + “=” + value)

print(“up­date DOM”)

re­turn true

nums.push(4)

print(“nums: ” + nums)

print(“_nums: ” + _nums)

Modules al­low you to name­space your code and break down func­tion­al­ity into smaller files. In the ex­am­ple be­low, we have a mod­ule named greet.js that gets in­cluded in in­dex.html. Note, mod­ule load­ing is al­ways de­ferred, so it won’t block the HTML from ren­der­ing. There are many ways to im­port/​ex­port func­tion­al­ity from js files, read more in the ex­port docs.

Okay, so I did­n’t cover every­thing that’s changed over the last decade, just the items I find most use­ful. Check out these other top­ics.

Elon Musk’s Neuralink has been mak­ing waves on the tech­nol­ogy side of neural im­plants, but it has­n’t yet shown how we might ac­tu­ally use im­plants. For now, demon­strat­ing the promise of im­plants re­mains in the hands of the aca­d­e­mic com­mu­nity.

This week, the aca­d­e­mic com­mu­nity pro­vided a rather im­pres­sive ex­am­ple of the promise of neural im­plants. Using an im­plant, a par­a­lyzed in­di­vid­ual man­aged to type out roughly 90 char­ac­ters per minute sim­ply by imag­in­ing that he was writ­ing those char­ac­ters out by hand.

Previous at­tempts at pro­vid­ing typ­ing ca­pa­bil­i­ties to par­a­lyzed peo­ple via im­plants have in­volved giv­ing sub­jects a vir­tual key­board and let­ting them ma­neu­ver a cur­sor with their mind. The process is ef­fec­tive but slow, and it re­quires the user’s full at­ten­tion, as the sub­ject has to track the progress of the cur­sor and de­ter­mine when to per­form the equiv­a­lent of a key press. It also re­quires the user to spend the time to learn how to con­trol the sys­tem.

But there are other pos­si­ble routes to get­ting char­ac­ters out of the brain and onto the page. Somewhere in our writ­ing thought process, we form the in­ten­tion of us­ing a spe­cific char­ac­ter, and us­ing an im­plant to track this in­ten­tion could po­ten­tially work. Unfortunately, the process is not es­pe­cially well un­der­stood.

Downstream of that in­ten­tion, a de­ci­sion is trans­mit­ted to the mo­tor cor­tex, where it’s trans­lated into ac­tions. Again, there’s an in­tent stage, where the mo­tor cor­tex de­ter­mines it will form the let­ter (by typ­ing or writ­ing, for ex­am­ple), which is then trans­lated into the spe­cific mus­cle mo­tions re­quired to per­form the ac­tion. These processes are much bet­ter un­der­stood, and they’re what the re­search team tar­geted for their new work.

Specifically, the re­searchers placed two im­plants in the pre­mo­tor cor­tex of a par­a­lyzed per­son. This area is thought to be in­volved in form­ing the in­ten­tions to per­form move­ments. Catching these in­ten­tions is much more likely to pro­duce a clear sig­nal than catch­ing the move­ments them­selves, which are likely to be com­plex (any move­ment in­volves mul­ti­ple mus­cles) and de­pend on con­text (where your hand is rel­a­tive to the page you’re writ­ing on, etc.).

With the im­plants in the right place, the re­searchers asked the par­tic­i­pant to imag­ine writ­ing let­ters on a page and recorded the neural ac­tiv­ity as he did so.

Altogether, there were roughly 200 elec­trodes in the par­tic­i­pan­t’s pre­mo­tor cor­tex. Not all of them were in­for­ma­tive for let­ter-writ­ing. But for those that were, the au­thors per­formed a prin­ci­pal com­po­nent analy­sis, which iden­ti­fied the fea­tures of the neural record­ings that dif­fered the most when var­i­ous let­ters were imag­ined. Converting these record­ings into a two-di­men­sional plot, it was ob­vi­ous that the ac­tiv­ity seen when writ­ing a sin­gle char­ac­ter al­ways clus­tered to­gether. And phys­i­cally sim­i­lar char­ac­ters—p and b, for ex­am­ple, or h, n, and r—formed clus­ters near each other.

Overall, the re­searchers found they could de­ci­pher the ap­pro­pri­ate char­ac­ter with an ac­cu­racy of a bit over 94 per­cent, but the sys­tem re­quired a rel­a­tively slow analy­sis af­ter the neural data was recorded. To get things work­ing in real time, the re­searchers trained a re­cur­rent neural net­work to es­ti­mate the prob­a­bil­ity of a sig­nal cor­re­spond­ing to each let­ter.

Despite work­ing with a rel­a­tively small amount of data (only 242 sen­tences’ worth of char­ac­ters), the sys­tem worked re­mark­ably well. The lag be­tween the thought and a char­ac­ter ap­pear­ing on screen was only about half a sec­ond, and the par­tic­i­pant was able to pro­duce about 90 char­ac­ters per minute, eas­ily top­ping the pre­vi­ous record for im­plant-dri­ven typ­ing, which was about 25 char­ac­ters per minute. The raw er­ror rate was only about 5 per­cent, and ap­ply­ing a sys­tem like a typ­ing au­to­cor­rect could drop the er­ror rate down to only 1 per­cent.

The tests were all done with pre­pared sen­tences. Once the sys­tem was val­i­dated, how­ever, the re­searchers asked the par­tic­i­pant to type out free-form an­swers to ques­tions. Here, the speed went down a bit (to 75 char­ac­ters a minute) and er­rors went up to 2 per­cent af­ter au­to­cor­rec­tion, but the sys­tem still worked.

As the re­searchers them­selves put it, this “is not yet a com­plete, clin­i­cally vi­able sys­tem.” To be­gin with, it has only been used in a sin­gle in­di­vid­ual, so we have no idea how well it might work for oth­ers. The sim­pli­fied al­pha­bet used here does­n’t con­tain any dig­its, cap­i­tal let­ters, or most forms of punc­tu­a­tion. And the be­hav­ior of the im­plants changes over time, per­haps be­cause of mi­nor shifts rel­a­tive to the neu­rons they read or the build-up of scar tis­sue, so the sys­tem had to be re­cal­i­brated reg­u­larly—at least once per week to main­tain a tol­er­a­ble er­ror rate.

That said, the sys­tem shows a very sig­nif­i­cant speed boost com­pared to pre­vi­ous im­plant-dri­ven sys­tems, and the ac­cu­racy is quite good. The sys­tem also has the po­ten­tial to be sim­i­lar to touch-typ­ing, in that a user does­n’t have to ac­tu­ally vi­su­ally fo­cus on let­ter pro­duc­tion, al­low­ing more nor­mal in­ter­ac­tions with the user’s sur­round­ings. The let­ter is­sue might be solved in part by us­ing an al­ter­nate al­pha­bet de­signed by the re­searchers, in which all the let­ters are de­fined by dis­sim­i­lar pat­terns of strokes. There’s a lot of po­ten­tial here.

The ex­per­i­ments also pro­vide a re­minder of the po­ten­tial of these im­plants more gen­er­ally and why com­pa­nies might start find­ing the tech­nol­ogy worth com­mer­cial­iz­ing.

One of my fa­vorite books is 2013 “High Performance Browser Networking” by Ilya Grigorik. Besides a wealth of ac­tion­able ad­vice, the book is il­lus­trated with cap­ti­vat­ing real life sto­ries.

46% of Battery Consumption to Transfer 0.2% of Total Bytes

Whenever a Pandora user plays a song, the en­tire mu­sic file is streamed by the ap­pli­ca­tion from the net­work in one shot, which is the cor­rect be­hav­ior: burst as much data

as you can, then turn off the ra­dio for as long as pos­si­ble.

However, fol­low­ing the mu­sic

trans­fer, the ap­pli­ca­tion would con­duct pe­ri­odic au­di­ence mea­sure­ments by send­ing

in­ter­mit­tent an­a­lyt­ics pings every 60 sec­onds. The net ef­fect? The an­a­lyt­ics bea­cons

ac­counted for 0.2% of the to­tal trans­ferred bytes and 46% of the to­tal power con­sump­tion of the ap­pli­ca­tion!

Ilya takes the time to go deep to make his points across. To en­lighten read­ers on the topic of cell­phone bat­tery life, he ded­i­cates a whole chap­ter to de­tail the GSM, UMTS, and LTE ra­dio mo­dem. It is fas­ci­nat­ing to re­al­ize that prob­lems at one level can find their roots sev­eral lay­ers be­low.

By ex­plor­ing the whole stack, High Performance Browser Networking does more than pro­vid­ing facts. It ad­vo­cates a phi­los­o­phy.

Good de­vel­op­ers know how things work.

Great de­vel­op­ers know why things work.

An old idea is new again

Back when I read it, in 2013, I thought it would have been cool to do my own ex­plo­ration and vi­su­al­ize how the ra­dio jumped from one cell to an­other while the phone trav­eled.

The idea was not doable with my 2013 iOS phone since it did not ex­pose the data I needed but my cur­rent Pixel does not have this is­sue. LocationManager can pro­vide a GPS lo­ca­tion (lat,long) every sec­ond. Meanwhile, TelephonyManager gives the cel­lID=(mmc,mcc,lac,cid) the ra­dio is cur­rently camp­ing on.

A cel­lID data­base[1], al­lows to know the (lat,long) of each CellID. What is left is to draw the itin­er­ary (in red) and, for each sec­ond, a cel­lID-color-coded con­nec­tion to the cell.

A drive from Sunnyvale to down­town Mountain View.

The re­sult above shows a 7 min­utes drive cov­er­ing 2.3 miles (3.7 km) with an LTE ca­pa­ble phone (a.k.a UE for User Equipment). Along the way, five tow­ers and nine cells (a.k.a eNB for Evolved NodeB) were en­coun­tered.

Combining the map, Google StreetView, and Wikipedia al­lowed to un­der­stand a lot of things.

- Several cel­lIDs map to the same eNB lat/​long co­or­di­nates. That’s be­cause the an­ten­nas mounted on an eNB don’t have 360° cov­er­age. The an­gle and range of each an­tenna carves the space into pizza slice shaped cells.

- Antennas are po­si­tioned and ori­ented strate­gi­cally. In the map on the right, tow­ers are posted along high­way 85 and an­ten­nas pointed par­al­lel to it. Some an­ten­nas seem to have ex­cep­tion­ally nar­row and long range. Possibly to ac­com­mo­date the high den­sity dur­ing traf­fic jams.

- eNBs have a much higher den­sity than I thought. Googling about “cellphone tower range” re­turned a 45 miles fig­ure. That may be true in rural ar­eas but in a city, pop­u­la­tion den­sity and eNB den­sity are cor­re­lated. That means there were tow­ers every mile in Sunnyvale.

- Sites are not nec­es­sar­ily shared among op­er­a­tors. The ac­cu­racy of the CellID data­base (CellMapper) is so high that I was able to go on Google StreetView and see the ac­tual tow­ers. I ex­pected to see huge mono­liths with large ar­rays of an­tenna for each op­er­a­tors but most of the time it looked like a sin­gle one was there.

- eNB an­ten­nas can be found on many things be­sides masts[2]. Some of the lo­ca­tions in­clude churches[3], elec­tric py­lons[4], and even com­mer­cial build­ings.

- Once you are in the habit of look­ing for them, these once in­vis­i­ble cell tow­ers be­come im­pos­si­ble to ig­nore.

- The UE’s LTE ra­dio is able to jump from cells back and forth. Several times within a minute seems to be a com­mon oc­cur­rence within a city to pal­li­ate to build­ing ob­struc­tion.

- Tower pair­ing (a.k.a camp­ing) looks de­ter­min­is­tic. In the two pre­vi­ous maps, the tower us­age looks sim­i­lar in the shared por­tion of the trip. The se­lec­tion hap­pens ac­cord­ing to a state-ma­chine con­fig­ured by each cell via broad­cast SIB mes­sages. The state tran­si­tion hap­pens based on mul­ti­ple fac­tors such a pre­vi­ous cell sig­nal strength thresh­old or next cell sig­nal strength thresh­old.

- On a “long” (10 miles) dri­ving ses­sion I saw that the LAC (Location Area Code) part of the CellID re­mained the same. According to the LTE specs, cell-tow­ers don’t have to per­form UE hand-overs like in GSM/UMTS. The phone starts camp­ing on the next tower while re­main­ing in RCC_IDLE mode with­out emit­ting data. Not only does this save bat­tery, it also means op­er­a­tors don’t re­ally know where the phone is as long as it re­mains in the same LAC. If data must be sent, all tow­ers in the same LAC must ping the phone. I may mean LTE of­fers greater pri­vacy al­though this topic seem to have been de­bated ever since GSM[5].

- Each tower seems to use three 120° an­ten­nas. It is pretty ob­vi­ous when cir­cling around one.

Traveling around a tower re­veals the 120° ra­dius of each cells.

Further down the rab­bit hole

Drawing maps was fun. It made me want to learn more about the field. I found it to not only be deep but also quite broad. Even draw­ing a min­i­mal table to sum­ma­rize it re­quired a sub­stan­tial amount of acronym re­search.

Starting in 1998 with 2G (GSM), all tech-stacks were stan­dard­ized and doc­u­mented by 3GPP. These specs span over hun­dreds of doc­u­ments. Understanding them seems like a life­time achieve­ment.

There are no open source LTE stack to learn from and even if there was, emit­ting on cell­phone bands is highly reg­u­lated in or­der to make sure fre­quen­cies are not pol­luted with buggy modems.

The few books in the fields are very ex­pen­sive. My “genuine win­dow of in­ter­est” was fu­eled by these three.

An in­tro­duc­tion to LTE by Christopher Cox.

Finally, there are apps that al­low to peek un­der the hood to show the mo­dem state and mes­sages. I elected not to use them since not only they are ex­pen­sive, they also re­quire to root the phone.

A few years back there was an ex­hi­bi­tion in a London gallery by the Royal Geographic Society, and the cu­ra­tor asked the edge.org group to con­tribute “unusual maps”. Thinking it would be for a few hun­dred peo­ple at most, I put to­gether a lit­tle map that I had made pre­vi­ously in the mid 80s be­fore, then as an ex­am­ple of sci­en­tific vi­su­al­iza­tion graph­ics soft­ware (which I spent a decade on, ac­tu­ally).

It was a very sim­ple premise that I had seen done a num­ber of times be­fore - never claimed it to be a novel in­ven­tion - but had a slightly new twist in mind: Africa is so mind-numb­ingly im­mense, that it ex­ceeds the com­mon as­sump­tions by just about any­one I ever met: it con­tains the en­tirety of the USA, all of China, India, as well as Japan and pretty much all of Europe as well - all com­bined !

And the idea was to roughly put all of them as puz­zle pieces some­how fit­ting in­side the out­line shape of Africa, which is of course just a sym­bolic im­age - it may as well have been just blobs to tell the story, but it ac­tu­ally worked pretty well with the real pieces, at least enough to get the idea across in a vi­sual and vis­ceral way:

Just for ref­er­ence:

Surface of the Moon

During the mak­ing of it, I sent it to a few friends for some feed­back, but then next thing I knew Stephen Fry had tweeted it and within lit­er­ally days there were tens of thou­sands of re­blogs all over the place, a lit­tle vi­ral meme…

Searching for that ex­act phrase got over half a mil­lion re­sponses in 2010:

On the right here you can see each of the main 5 swal­lowed up in­side the land­mass of Africa, one at a time to make it clearer…

And be­low that you can see an ex­act list of an­other set of coun­tries by area, adding up to less than Africa as well…

The whole point be­ing made was that we all have been taught ge­og­ra­phy mainly based on the Mercator pro­jec­tion - as the back­ground in daily tele­vi­sion news, the cover of my school at­las, in gen­eral the ubiq­ui­tous de­pic­tion of the planet.

But the ba­sic fact is that a three-di­men­sional sphere be­ing shown as a sin­gle two-di­men­sional flat im­age will al­ways be sub­ject to a con­ver­sion loss: some­thing has to give…

The rea­son why Mercator was such an im­por­tant ad­vance is sim­ple: on it one can draw straight lines to ac­count for travel routes - in the days of the gi­gan­tic mer­chant fleets and naval bat­tles an im­mensely valu­able at­tribute.

But that abil­ity to use lines in­stead of curves came at a cost: ar­eas near the poles would be greatly ex­ag­ger­ated. Greenland looks de­ceiv­ingly as if it were the size of all of South America for in­stance…

In other words: if things are nor­mal near the equa­tor, every­thing fur­ther north and south is fa­mil­iar to us in a stretched and en­larged ver­sion, veer­ing fur­ther and fur­ther away from the proper size. And con­versely: if we kept the shapes as we in­tu­itively know them now, Africa ought to be stretched mas­sively larger to keep it in true pro­por­tion.

Hence the fact that in every­day think­ing, Africa is just about al­ways hugely un­der­es­ti­mated - even by col­lege grads, off by fac­tor of 2 or 3.

The table at right shows the US in­clud­ing Alaska and Hawaii, btw. And while not list­ing Eastern Europe (dark blue in the map) it adds many oth­ers un­used in the map: Mexico, Peru, New Guinea, New Zealand, Nepal and Bangladesh!

All of that be­came the fod­der for the old cliché:

“Are you com­ing to bed, honey?”

“No not yet -there is some­one wrong on the in­ter­net!”

A ver­i­ta­ble shit­storm of re­sponses latched onto the tini­est of tiny de­tails. People com­plained “you missed Ibiza”, “how could you make Belgium the same color as the Netherlands” “and on and on and on…

Some oth­ers were dead cer­tain to have spot­ted the big flaw “the UK is not the same size as Madagascar - this dude is SOOO wrong!”… and well DUH… that is PRECISELY the point I was mak­ing, in ac­tion: Madagascar is much larger!

Had I stretched things to truly prop­erly show that though, then the whole shape of Africa would have looked very awk­wardly elon­gated. I chose to tell the ba­sic puz­zle piece fit­ting story by us­ing the fa­mil­iar shapes.

Both to­gether can­not be done - but one could prob­a­bly do a much nicer job of an ex­act list of the in­gre­di­ents and then a nearly ex­act fit of the pieces - or maybe “pouring the pix­els” highly ac­cu­rately in pro­por­tion into the out­line shape of Africa as the ves­sel to con­tain them all - but af­ter­wards each coun­try is just a layer of color - I pre­ferred the out­lines, even if rather rough and sym­bolic.

Hopefully some­one will im­prove on it - as mine was by far not the first and should also not be the last at­tempt to tell the story :)

But many to­tally missed the sin­gle big point: NO - this was not at all an at­tempt to cre­ate “an ac­cu­rate map”, it was merely a sim­ple graph­i­cal de­pic­tion of the state­ment: Africa is just im­mense - much, much larger than you or I thought. Just look at it, re­al­ize that, and smile - be­cause you will never for­get it again :)

And: here is to Africa achiev­ing the stature that it de­serves to have…

He takes the first one on the list and looks it up on the Companies House web­site. Everything is meant to be trans­par­ent - the web­site con­tains the de­tails of every com­pany in the UK. It’s thought to be a key anti-cor­rup­tion tool. “We are very proud of this in this coun­try,” he says. “The prob­lem is that when you cre­ate this com­pany, no-one checks any of the in­for­ma­tion pro­vided.” He clicks to see the com­pa­ny’s fil­ing his­tory, but where you should see com­pany ac­counts, there is noth­ing. “This is clas­sic,” he ex­claims. “Look, noth­ing has hap­pened. They have filed no fi­nan­cial in­for­ma­tion at all.” Then he tries check­ing the com­pa­ny’s own­ers. The UK be­gan to in­sist re­cently that com­pa­nies must en­ter the name of the per­son with “significant con­trol” - the real owner.

This blog post is based off of a talk I gave on May 12, 2021 at the Stanford Computer Science Department’s weekly lunch talk se­ries on com­puter se­cu­rity top­ics. Full dis­clo­sure: I’ve done some con­sult­ing work for Signal, al­beit not on any­thing like this is­sue. (I kinda doubt they’ll hire me again if they read this, though.)

You may have seen a story in the news re­cently about vul­ner­a­bil­i­ties dis­cov­ered in the dig­i­tal foren­sics tool made by Israeli firm Cellebrite. Cellebrite’s soft­ware ex­tracts data from mo­bile de­vices and gen­er­ates a re­port about the ex­trac­tion. It’s pop­u­lar with law en­force­ment agen­cies as a tool for gath­er­ing dig­i­tal ev­i­dence from smart­phones in their cus­tody.

In April, the team be­hind the pop­u­lar end-to-end en­crypted (E2EE) chat app Signal pub­lished a blog post de­tail­ing how they had ob­tained a Cellebrite de­vice, an­a­lyzed the soft­ware, and found vul­ner­a­bil­i­ties that would al­low for ar­bi­trary code ex­e­cu­tion by a de­vice that’s be­ing scanned with a Cellebrite tool.

As cov­er­age of the blog post pointed out, the vul­ner­a­bil­ity draws into ques­tion whether Cellebrite’s tools are re­li­able in crim­i­nal pros­e­cu­tions af­ter all. While Cellebrite has since taken steps to mit­i­gate the vul­ner­a­bil­ity, there’s al­ready been a mo­tion for a new trial filed in at least one crim­i­nal case on the ba­sis of Signal’s blog post.

Is that mo­tion likely to suc­ceed? What will be the likely ram­i­fi­ca­tions of Signal’s dis­cov­ery in court cases? I think the im­pact on ex­ist­ing cases will be neg­li­gi­ble, but that Signal has made an im­por­tant point that may help push the mo­bile de­vice foren­sics in­dus­try to­wards greater ac­count­abil­ity for their of­ten sloppy prod­uct se­cu­rity. Nevertheless, I have a raised eye­brow for Signal here too.

Cellebrite is an Israeli com­pany that, per Signal’s blog post, “makes soft­ware to au­to­mate phys­i­cally ex­tract­ing and in­dex­ing data from mo­bile de­vices.” A com­mon use case here in the U. S. is to be used by law en­force­ment in crim­i­nal in­ves­ti­ga­tions, typ­i­cally with a war­rant un­der the Fourth Amendment that al­lows them to search some­one’s phone and seize data from it.

Cellebrite’s prod­ucts are part of the in­dus­try of “mobile de­vice foren­sics” tools. “The mo­bile foren­sics process aims to re­cover dig­i­tal ev­i­dence or rel­e­vant data from a mo­bile de­vice in a way that will pre­serve the ev­i­dence in a foren­si­cally sound con­di­tion,” us­ing ac­cepted meth­ods, so that it can later be pre­sented in court.

Who are their cus­tomers?

Between Cellebrite and the other ven­dors in the in­dus­try of mo­bile de­vice foren­sics tools, there are over two thou­sand law en­force­ment agen­cies across the coun­try that have such tools — in­clud­ing 49 of the 50 biggest cities in the U. S. Plus, ICE has con­tracts with Cellebrite worth tens of mil­lions of dol­lars.

But Cellebrite has lots of cus­tomers be­sides U. S. law en­force­ment agen­cies. And some of them aren’t so nice. As Signal’s blog post notes, “Their cus­tomer list has in­cluded au­thor­i­tar­ian regimes in Belarus, Russia, Venezuela, and China; death squads in Bangladesh; mil­i­tary jun­tas in Myanmar; and those seek­ing to abuse and op­press in Turkey, UAE, and else­where.”

The ven­dors of these kinds of tools love to get up on their high horse and talk about how they’re the “good guys,” they help keep the world safe from crim­i­nals and ter­ror­ists. Yes, sure, fine. But a lot of ven­dors in this in­dus­try, the in­dus­try of sell­ing sur­veil­lance tech­nolo­gies to gov­ern­ments, sell not only to the U. S. and other coun­tries that re­spect the rule of law, but also to re­pres­sive gov­ern­ments that per­se­cute their own peo­ple, where the de­f­i­n­i­tion of “criminal” might just mean be­ing gay or crit­i­ciz­ing the gov­ern­ment. The will­ing­ness of com­pa­nies like Cellebrite to sell to un­sa­vory gov­ern­ments is why there have been calls from hu­man rights lead­ers and groups for a global mora­to­rium on sell­ing these sorts of sur­veil­lance tools to gov­ern­ments.

What do Cellebrite’s prod­ucts do?

Cellebrite has a few dif­fer­ent prod­ucts, but as rel­e­vant here, there’s a two-part sys­tem in play: the first part, called UFED (which stands for Universal Forensic Extraction Device), ex­tracts the data from a mo­bile de­vice and backs it up to a Windows PC, and the sec­ond part, called Physical Analyzer, parses and in­dexes the data so it’s search­able. So, take the raw data out, then turn it into some­thing use­ful for the user, all in a foren­si­cally sound man­ner.

As Signal’s blog post ex­plains, this two-part sys­tem re­quires phys­i­cal ac­cess to the phone; these aren’t tools for re­motely ac­cess­ing some­one’s phone. And the kind of ex­trac­tion (a “logical ex­trac­tion”) at is­sue here re­quires the de­vice to be un­locked and open. (A log­i­cal ex­trac­tion is quicker and eas­ier, but also more lim­ited, than the deeper but more chal­leng­ing type of ex­trac­tion, a “physical ex­trac­tion,” which can work on locked de­vices, though not with 100% re­li­a­bil­ity. Plus, log­i­cal ex­trac­tions won’t re­cover deleted or hid­den files, un­like phys­i­cal ex­trac­tions.) As the blog post says, think of it this way: “if some­one is phys­i­cally hold­ing your un­locked de­vice in their hands, they could open what­ever apps they would like and take screen­shots of every­thing in them to save and go over later. Cellebrite es­sen­tially au­to­mates that process for some­one hold­ing your de­vice in their hands.”

Plus, un­like some cop tak­ing screen­shots, a log­i­cal data ex­trac­tion pre­serves the re­cov­ered data “in its orig­i­nal state with foren­si­cally-sound in­tegrity ad­mis­si­ble in a court of law.” Why show that the data were ex­tracted and pre­served with­out al­ter­ing any­thing? Because that’s what is nec­es­sary to sat­isfy the rules for ad­mit­ting ev­i­dence in court. U. S. courts have rules in place to en­sure that the ev­i­dence that is pre­sented is re­li­able — you don’t want to con­vict or ac­quit some­body on the ba­sis of, say, a file whose con­tents or meta­data got cor­rupted. Cellebrite holds it­self out as meet­ing the stan­dards that U.S. courts re­quire for dig­i­tal foren­sics.

But what Signal showed is that Cellebrite tools ac­tu­ally have re­ally shoddy se­cu­rity that could, un­less the prob­lem is fixed, al­low al­ter­ation of data in the re­ports the soft­ware gen­er­ates when it an­a­lyzes phones. Demonstrating flaws in the Cellebrite sys­tem calls into ques­tion the in­tegrity and re­li­a­bil­ity of the data ex­tracted and of the re­ports gen­er­ated about the ex­trac­tion.

That un­der­mines the en­tire rea­son for these tools’ ex­is­tence: com­pil­ing dig­i­tal ev­i­dence that is sound enough to be ad­mit­ted and re­lied upon in court cases.

What was the hack?

As back­ground: Late last year, Cellebrite an­nounced that one of their tools (the Physical Analyzer tool) could be used to ex­tract Signal data from un­locked Android phones. Signal was­n’t pleased.

Apparently in re­tal­i­a­tion, Signal struck back. As last mon­th’s blog post de­tails, Signal cre­ator Moxie Marlinspike and his team ob­tained a Cellebrite kit (they’re coy about how they got it), an­a­lyzed the soft­ware, and found vul­ner­a­bil­i­ties that would al­low for ar­bi­trary code ex­e­cu­tion by a de­vice that’s be­ing scanned with a Cellebrite tool. According to the blog post:

Looking at both UFED and Physical Analyzer, … we were sur­prised to find that very lit­tle care seems to have been given to Cellebrite’s own soft­ware se­cu­rity. Industry-standard ex­ploit mit­i­ga­tion de­fenses are miss­ing, and many op­por­tu­ni­ties for ex­ploita­tion are pre­sent. …

“[W]e found that it’s pos­si­ble to ex­e­cute ar­bi­trary code on a Cellebrite ma­chine sim­ply by in­clud­ing a spe­cially for­mat­ted but oth­er­wise in­nocu­ous file in any app on a de­vice that is sub­se­quently plugged into Cellebrite and scanned. There are vir­tu­ally no lim­its on the code that can be ex­e­cuted.

“For ex­am­ple, by in­clud­ing a spe­cially for­mat­ted but oth­er­wise in­nocu­ous file in an app on a de­vice that is then scanned by Cellebrite, it’s pos­si­ble to ex­e­cute code that mod­i­fies not just the Cellebrite re­port be­ing cre­ated in that scan, but also from all pre­vi­ously scanned de­vices and all fu­ture scanned de­vices in any ar­bi­trary way (inserting or re­mov­ing text, email, pho­tos, con­tacts, files, or any other data), with no de­tectable time­stamp changes or check­sum fail­ures. This could even be done at ran­dom, and would se­ri­ously call the data in­tegrity of Cellebrite’s re­ports into ques­tion.

Signal also cre­ated a video demo to show their proof of con­cept (PoC), which you can watch in the blog post or their tweet about it. They sum­ma­rized what’s de­picted in the video:

[This] is a sam­ple video of an ex­ploit for UFED (similar ex­ploits ex­ist for Physical Analyzer). In the video, UFED hits a file that ex­e­cutes ar­bi­trary code on the Cellebrite ma­chine. This ex­ploit pay­load uses the MessageBox Windows API to dis­play a di­a­log with a mes­sage in it. This is for demon­stra­tion pur­poses; it’s pos­si­ble to ex­e­cute any code, and a real ex­ploit pay­load would likely seek to un­de­tectably al­ter pre­vi­ous re­ports, com­pro­mise the in­tegrity of fu­ture re­ports (perhaps at ran­dom!), or ex­fil­trate data from the Cellebrite ma­chine.

What did Signal say they’re go­ing to do about this?

The blog post an­nounced that go­ing for­ward, in the fu­ture, the Signal app will add “aesthetically pleas­ing” files, pe­ri­od­i­cally and at ran­dom, to Signal’s app data caches on Signal users’ phones. Here’s the last para­graph of the blog post:

In com­pletely un­re­lated news, up­com­ing ver­sions of Signal will be pe­ri­od­i­cally fetch­ing files to place in app stor­age. These files are never used for any­thing in­side Signal and never in­ter­act with Signal soft­ware or data, but they look nice, and aes­thet­ics are im­por­tant in soft­ware. Files will only be re­turned for ac­counts that have been ac­tive in­stalls for some time al­ready, and only prob­a­bilis­ti­cally in low per­cent­ages based on phone num­ber shard­ing. We have a few dif­fer­ent ver­sions of files that we think are aes­thet­i­cally pleas­ing, and will it­er­ate through those slowly over time. There is no other sig­nif­i­cance to these files.

What ex­actly does that mean? Only Moxie and his team know. The rest of us are left to guess. I lit­er­ally had a re­porter tell me that they could­n’t tell if this part of the blog post was a joke or not.

One in­ter­pre­ta­tion is that “aesthetically pleas­ing” means they’re im­age files — like, pic­tures of cats or some­thing — that the Signal user never ac­tu­ally sees and did not ac­tively put in app stor­age them­selves. Another in­ter­pre­ta­tion, if we as­sume those “aesthetically pleas­ing” files do what a “real ex­ploit pay­load” could do, then (absent a mit­i­ga­tion by Cellebrite) these files could af­fect a Cellebrite ma­chine if that phone got an­a­lyzed with a Cellebrite tool while those files were in app stor­age.

If noth­ing else, it means that if they fol­low through on what they say they’ll do, then Signal will add noise to the, uh, sig­nal in the Signal ap­p’s lo­cal stor­age on some users’ phones. But only some users, and Signal won’t know which users, and the files will change pe­ri­od­i­cally, if they’re there at all. It won’t be the case that all users of Signal will have the same files added by Signal into lo­cal stor­age at all times go­ing for­ward.

What did Signal sug­gest Cellebrite should do about this po­ten­tial ex­ploit?

Here’s what Signal sug­gested Cellebrite should do:

Any app could con­tain such a file [i.e. a booby-trapped file], and un­til Cellebrite is able to ac­cu­rately re­pair all vul­ner­a­bil­i­ties in its soft­ware with ex­tremely high con­fi­dence, the only rem­edy a Cellebrite user has is to not scan de­vices. Cellebrite could re­duce the risk to their users by up­dat­ing their soft­ware to stop scan­ning apps it con­sid­ers high risk for these types of data in­tegrity prob­lems, but even that is no guar­an­tee.

Basically, what they’re say­ing is: “We’re go­ing to screw with you for adding sup­port to Cellebrite for Signal data. If you want to be sure of your own data in­tegrity, your users (the cops) should stop scan­ning phones that have Signal in­stalled. But even then, you can’t re­ally be sure, be­cause the apps that you or law en­force­ment deem high-risk might not be the ones poi­son­ing your ma­chines. The only way to be sure is for your users (the cops) to stop do­ing the one thing that your tools are made to do, which ul­ti­mately could put you out of busi­ness.”

Signal went on, “We are of course will­ing to re­spon­si­bly dis­close the spe­cific vul­ner­a­bil­i­ties we know about to Cellebrite if they do the same for all the vul­ner­a­bil­i­ties they use in their phys­i­cal ex­trac­tion and other ser­vices to their re­spec­tive ven­dors, now and in the fu­ture.”

Basically, “I’ll show you mine if you show me yours.” That is not gen­er­ally how vul­ner­a­bil­ity dis­clo­sure works, and AFAIK, Cellebrite has not taken them up on the of­fer so far.

By the way, this is­n’t the first time Cellebrite’s been outed for hav­ing shoddy se­cu­rity. In 2017, a hacker hacked Cellebrite’s servers and “obtained 900 GB of data re­lated to Cellebrite,” in­clud­ing (1) Cellebrite cus­tomers’ user­names and pass­words for log­ging into its web­sites; (2) “a vast amount of tech­ni­cal data re­gard­ing Cellebrite’s prod­ucts”; and even (3) “what ap­pear[ed] to be ev­i­dence files from seized mo­bile phones, and logs from Cellebrite de­vices.”

What was Cellebrite’s ac­tual re­sponse to the hack?

According to Vice, a few days af­ter the blog post, “Cellebrite pushed an up­date to its cus­tomers … limit[ing] what prod­ucts can per­form a log­i­cal iOS ex­trac­tion.” The com­pany did­n’t ad­mit whether the vuln was the one Signal de­scribed. (But ba­si­cally every­body as­sumes that’s the case.) Cellebrite did say, “Based on our re­views, we have not found any in­stance of this vul­ner­a­bil­ity be­ing ex­ploited in the real-life us­age of our so­lu­tions.” A Cellebrite cus­tomer who com­mented to Vice said, “It ap­pears to be an at­tempt to min­i­mize the at­tack sur­face[,] not a ‘fix[.]’”

From the news re­ports, it sounds like Cellebrite has tem­porar­ily turned off iPhone sup­port for the Physical Analyzer tool. (Note Cellebrite only turned off sup­port for Physical Analyzer, even though the Signal blog post’s demo was about the UFED soft­ware and they said sim­i­lar ex­ploits ex­ist for Physical Analyzer.) You’ll re­call that Physical Analyzer is the sec­ond part of the two-part sys­tem. UFED cre­ates the backup, Physical Analyzer parses the files.

But even though UFED has vulns too, Cellebrite cus­tomers can still use UFED to dump the data from iPhones onto a lo­cal backup. You can back up the data but you can’t do any­thing with it for now. That’s still kinda weird, be­cause if vulns in UFED could also al­ter data, why keep sup­port for UFED on? Isn’t there a risk that those data dumps could be al­tered? My guess: Cellebrite’s go­ing half­sies be­cause it would be even more dis­as­trous for their busi­ness to yank sup­port for both prod­ucts, and they’re con­fi­dent enough that there aren’t any real-world ex­ploits for UFED that they left it work­ing for iPhones, since they fig­ure cus­tomers will want to keep pre­serv­ing ev­i­dence with those data dumps (which is surely eas­ier than keep­ing the phone pow­ered on, charged, and in an un­locked state in­def­i­nitely), but they deemed the Physical Analyzer vulns more dan­ger­ous, so that’s the part they de­cided to pause for now. But that’s just my guess. In any event, this is just a Band-Aid so­lu­tion: Cellebrite will have to re­store iOS sup­port for Physical Analyzer sooner or later.

It’s like there’s a bull that’s in the yard out­side a china shop, and it’s been locked in the yard in­side the fence. So it’s be­ing con­tained there. That’s not a long-term so­lu­tion, and the bull might still do dam­age to the yard, but the own­ers of the china shop think the bull will prob­a­bly be chill, and any dam­age won’t be as bad as it would be if the bull were to get in­side the china shop. And to keep the bull from go­ing in­side the china shop, for now, they boarded over the door to the china shop. But in­side, the shop is still full of frag­ile, break­able china. It won’t be safe to turn the Physical Analyzer back on un­til they’ve con­verted the china to adaman­tium or some­thing. (Yeah, sorry, it’s not the best metaphor.)

So what does Signal’s stunt mean for law en­force­ment use of Cellebrite?

The jour­nal­ist Thomas Fox-Brewster sum­ma­rized the the­o­ret­i­cal fall­out suc­cinctly in Forbes:

“This could be a se­vere is­sue for the many po­lice agen­cies us­ing Cellebrite across the world. If a crim­i­nal can hack a Cellebrite de­vice by run­ning a ma­li­cious file like the one de­scribed by Marlinspike, they could spoil ev­i­dence.”

No, in­ten­tion­ally spoil­ing ev­i­dence — or “spoliating,” to use the le­gal term — is def­i­nitely not le­gal.

Neither is hack­ing some­body’s com­puter, which is what Signal’s blog post is say­ing a “real ex­ploit pay­load” could do. It said, “a real ex­ploit pay­load would likely seek to un­de­tectably al­ter pre­vi­ous re­ports, com­pro­mise the in­tegrity of fu­ture re­ports (perhaps at ran­dom!), or ex­fil­trate data from the Cellebrite ma­chine.” All of those things are a vi­o­la­tion of the fed­eral anti-hack­ing law known as the Computer Fraud and Abuse Act, or CFAA, and prob­a­bly also of many state-law ver­sions of the CFAA. (If the com­puter be­longs to a fed­eral law en­force­ment agency, it’s def­i­nitely a CFAA vi­o­la­tion. If it’s a state, lo­cal, or tribal gov­ern­ment law en­force­ment agency, then, be­cause of how the CFAA de­fines “protected com­put­ers” cov­ered by the Act, it might de­pend on whether the Windows ma­chine that’s used for Cellebrite ex­trac­tions is con­nected to the in­ter­net or not. That ma­chine should be seg­mented apart from the rest of the po­lice de­part­men­t’s net­work, but if it has an in­ter­net con­nec­tion, the CFAA ap­plies. And even if it does­n’t, I bet there are other ways of eas­ily sat­is­fy­ing the “protected com­puter” de­f­i­n­i­tion.)

So is, uh, is Signal go­ing to up­date its app to make it hack po­lice com­put­ers? Recall what Signal said about how “upcoming ver­sions of Signal will be pe­ri­od­i­cally fetch­ing files to place in app stor­age…”. It’s very cutesy, coy, eva­sive lan­guage and it does­n’t say ex­actly what the hell they mean by that. They’re wink­ing and smil­ing and nudg­ing the reader in­stead of be­ing clear.

They seem to be im­ply­ing — or at least they seem to in­tend for the reader, and more im­por­tantly Cellebrite and its cus­tomers, to in­fer — that Signal will add “innocuous” code to their app that might, maybe, al­ter the data on a Cellebrite ma­chine if the phone gets plugged into it. If they’re say­ing what they’re hint­ing they’re say­ing, Signal ba­si­cally an­nounced that they plan to up­date their app to hack law en­force­ment com­put­ers and also tam­per with and spo­li­ate ev­i­dence in crim­i­nal cases.

When you put it that way, it be­comes clear why they were us­ing such coy lan­guage and why I bet they’re bluff­ing: Those things are il­le­gal. It’s a stunt that could get their own users in trou­ble (if the user gets blamed for what her phone does to a Cellebrite ma­chine, she will be plunged into a world of pain, ir­re­spec­tive of whether she would ul­ti­mately be held cul­pa­ble for the de­sign of an app she had in­stalled on her phone), and could get them in hot wa­ter (because they in­ten­tion­ally de­signed and put those booby-trapped files on the user’s phone).

Plus, ad­mit­tedly I haven’t ac­tu­ally looked into this at all, but it seems like it could get Signal kicked out of the Apple and Google app stores, if the com­pa­nies in­ter­pret this as a vi­o­la­tion of their app store rules against mal­ware. (It would­n’t ac­tu­ally help pro­tect pri­vacy or free ex­pres­sion or hu­man rights, as Signal prides it­self on do­ing, if peo­ple can’t in­stall and up­date the app, or if they side­load ma­li­cious fake ver­sions of Signal that some cy­ber­crime gang or evil gov­ern­ment puts out there.)

So my guess is that they’re play­ing this nudge-wink, plau­si­ble de­ni­a­bil­ity, vague lan­guage game, where maybe you might in­fer that they’re go­ing to make their app hack Cellebrite ma­chines and spoil ev­i­dence, but in ac­tu­al­ity they never had any in­ten­tion of ac­tu­ally do­ing that. It was just to mess with Cellebrite and make a point. At most, maybe they stick some files in app stor­age that don’t do any­thing ma­li­cious at all. And maybe Cellebrite’s prompt re­sponse con­ve­niently gave Signal an out from hav­ing to fol­low through, on top of the plau­si­ble de­ni­a­bil­ity of their cutesy eva­sive lan­guage.

Still, it’s a weird choice to make, for the pub­lic-fac­ing of­fi­cial com­mu­ni­ca­tions of an or­ga­ni­za­tion that makes an app with mil­lions of users around the world, to kinda-sorta vaguely an­nounce that you maybe just might re­design your app to break the law and screw with law en­force­ment.

Will this mean a bunch of de­fen­dants’ crim­i­nal cases get thrown out?

This is just a PoC. Yes, re­search showed there’s this flaw, but Signal’s demo is just a demo. It does­n’t mean the vuln they found was ever ac­tu­ally ex­ploited in the wild. Cellebrite told their cus­tomers they don’t be­lieve it was, though they did­n’t say how they reached that con­clu­sion. (And, well, there are ob­vi­ous rea­sons to be skep­ti­cal of the qual­ity of their in­ci­dent re­sponse.)

But crim­i­nal de­fense at­tor­neys are still go­ing to try to make use of this — as they should; they should hold the pros­e­cu­tion ac­count­able for the re­li­a­bil­ity of the ev­i­dence used against their clients. There’s a case in state court in West Virginia where the case al­ready went to trial, Cellebrite ev­i­dence was in­tro­duced, the de­fen­dant was con­victed, and based on this blog post, the at­tor­ney moved for a new trial and to ex­am­ine the Cellebrite ma­chine. I sus­pect there’ll be other at­tor­neys fil­ing sim­i­lar mo­tions.

My guess is that these de­fense lawyers are un­likely to get their clients a new trial in many, if any, of the cases where a ver­dict has al­ready been re­turned; but that in any on­go­ing open cases, those lawyers have bet­ter odds of get­ting the court to grant them the chance to ex­am­ine the Cellebrite ma­chine if they did­n’t do so be­fore (or maybe to ex­am­ine it again if they did).

The thing to un­der­stand is that the mere spec­u­la­tive pos­si­bil­ity that data in a Cellebrite re­port might have been al­tered is­n’t go­ing to sway any judges. If you’re a de­fense at­tor­ney, just show­ing the court this blog post say­ing “oh, Cellebrite soft­ware has a lot of vulns, and there was this vuln in par­tic­u­lar, here’s a sam­ple ex­ploit for it, and oh by the way maybe Signal will do some­thing to ex­ploit it in fu­ture ver­sions of the Signal app”: that’s not go­ing to be enough.

Another rea­son that le­gal chal­lenges prob­a­bly won’t go very far is that it should be pretty straight­for­ward for law en­force­ment to dis­prove an ac­cu­sa­tion about the Cellebrite ma­chine. In a re­cent le­gal we­bi­nar about mo­bile de­vice foren­sics tools, the dis­cus­sion touched upon Signal’s Cellebrite hack. One of the pan­elists pointed out that Cellebrite’s not the only game in town when it comes to these ex­trac­tion tools. It’s a whole in­dus­try, it’s not just this one com­pany, al­though Cellebrite is prob­a­bly the best-known ac­tor in that in­dus­try. Therefore, as the pan­elist pointed out, if you’re law en­force­ment, you can just per­form the same ex­trac­tion through a dif­fer­ent pro­gram, and there won’t be a prob­lem be­cause this flaw is unique to Cellebrite. Sure, prob­a­bly those other com­pa­nies’ tools have bugs too (and they should get their act to­gether too), but there’s been no show­ing that every other tool out there has an iden­ti­cal flaw that could be ex­ploited in an iden­ti­cal way. So Signal’s hack does­n’t draw into doubt all mo­bile de­vice foren­sics tools.

Thus, if there’s a chal­lenge to the in­tegrity of Cellebrite data in a par­tic­u­lar crim­i­nal case, the pros­e­cu­tion should be able to read­ily prove there’s no cor­rup­tion by just run­ning the ex­trac­tion through more than one foren­sic pro­gram be­sides Cellebrite. Then they could com­pare the out­puts of the two tools and see if there are dif­fer­ences. Or, they could just not use Cellebrite at all and just use the other tool. (Of course, in­duc­ing the cops to stop us­ing Cellebrite would be some sweet re­venge for Signal.)

In some cases, the pros­e­cu­tion could also po­ten­tially use wit­ness tes­ti­mony by a law en­force­ment of­fi­cer to cor­rob­o­rate what’s in the Cellebrite re­port and show that the re­port is ac­cu­rate. Remember, this Cellebrite two-part sys­tem works on al­ready un­locked phones. And crim­i­nal sus­pects will of­ten con­sent to un­lock their phones when the po­lice ask them to. (You don’t have to, you can say no, but peo­ple of­ten say yes.) If that hap­pened in a case where the Cellebrite data was chal­lenged, the state could call the cop to tes­tify and the cop might be able to say, “The de­fen­dant un­locked his phone for me and I flipped through it and saw these in­crim­i­nat­ing texts in Signal with the time­stamp on them from such-and-such a date, and that was be­fore we took the phone back to the po­lice sta­tion and plugged the phone into the Cellebrite ma­chine. And look­ing at this Cellebrite re­port, yep, what’s in the re­port matches up with my mem­ory: same text mes­sages, same time­stamp as I re­mem­ber see­ing when I was do­ing my man­ual in­spec­tion of the con­tents of his phone.”

The point be­ing, as I wrote on Twitter at the time, these chal­lenges will go nowhere un­less the de­fense can come up with some plau­si­ble ac­tual ev­i­dence of cor­rup­tion of the Cellebrite ma­chine or the data ex­tracted. There has to be some­thing to show that the Cellebrite data ex­trac­tion us­ing that Cellebrite tool on this phone is not re­li­able. No judge will throw out ev­i­dence from a Cellebrite analy­sis just be­cause Signal did a PoC.

So I hope lawyers are ad­vis­ing their clients that mov­ing for a new trial, or mov­ing to (re)examine the Cellebrite de­vice as part of an on­go­ing pros­e­cu­tion, solely on the ba­sis of Signal’s blog post, is a Hail Mary move that will prob­a­bly go nowhere. Lawyers ab­solutely should do this, in or­der to zeal­ously rep­re­sent their clients (and put the pros­e­cu­tion through its paces), but it prob­a­bly won’t change the re­sult.

What if it turns out the Cellebrite data was cor­rupted?

Even in the un­likely event that it turns out this ex­ploit was used in the wild, or if a Cellebrite ma­chine oth­er­wise turns out af­ter test­ing to be un­re­li­able, that’s not a guar­an­tee that every crim­i­nal case out there that in­volved a Cellebrite (which is prob­a­bly a lot of cases) de­serves to get the con­vic­tion thrown out. It may hap­pen in some cases, but not in all.

That’s be­cause of a doc­trine in the law that, while it’s com­pli­cated in prac­tice, es­sen­tially boils down to say­ing, “OK, so the un­re­li­able data should­n’t have been al­lowed into ev­i­dence. Let’s pre­tend that it had­n’t been ad­mit­ted: would that have had a big ef­fect on the ju­ry’s ver­dict, or would it prob­a­bly have been the same as it was when the un­re­li­able ev­i­dence was let in?” If the jury prob­a­bly would’ve con­victed any­way even with­out the Cellebrite ev­i­dence, then the guilty con­vic­tion will stand.

My guess is that it’s pretty rare that the Cellebrite ev­i­dence is the dis­pos­i­tive crux of a case, mean­ing, but for ev­i­dence pulled from a phone us­ing a Cellebrite de­vice, the jury would not have voted to con­vict. Surely it hap­pens some­times, but not in every case. Plus, the courts have an un­for­tu­nate ten­dency to say “yeah, the jury would’ve con­victed any­way.” This doc­trine does­n’t ac­tu­ally come out su­per fa­vor­ably to the de­fense when ap­plied in real cases. Like many things about the American jus­tice sys­tem, it’s not fair but it’s the re­al­ity.

Plus, there’s a rea­son why ju­ries would likely con­vict any­way in many cases. In a typ­i­cal case, the Cellebrite data will be just one part of the ev­i­dence pre­sented by the pros­e­cu­tion. In many cases the pros­e­cu­tion will have a lot of ev­i­dence that they can ob­tain from on­line ser­vice providers rather than just re­ly­ing on the lo­cal client-side copy that was ex­tracted us­ing Cellebrite. That might in­clude, for ex­am­ple, iCloud back­ups; phone records from the phone com­pany show­ing whom you called or texted and who called or texted you; cell-site lo­ca­tion in­for­ma­tion, GPS data, or other lo­ca­tion in­for­ma­tion show­ing where you were when; emails from Gmail; posts and DMs from so­cial me­dia; and so on. Much of the data about us is in the cloud, or oth­er­wise held by third par­ties and read­ily avail­able to the gov­ern­ment with the right le­gal process.

Signal is an out­lier in that it keeps al­most zero data about its users. All they can pro­vide in re­sponse to a sub­poena or other le­gal process is “Unix time­stamps for when each ac­count was cre­ated and the date that each ac­count last con­nected to the Signal ser­vice. That’s it.” So you can see why law en­force­ment would re­ally want Cellebrite to work for Signal data in par­tic­u­lar: a user’s phone is the only place to get Signal mes­sages. (Of course, by de­f­i­n­i­tion there are mul­ti­ple par­tic­i­pants in any con­ver­sa­tion. QED.) Still, Signal data is of­ten go­ing to be one piece of ev­i­dence among many.

What’s more, dig­i­tal ev­i­dence is­n’t the only ev­i­dence. A typ­i­cal case may also in­volve tes­ti­mony by mul­ti­ple wit­nesses (perhaps in­clud­ing a po­lice of­fi­cer who saw in­crim­i­nat­ing files on the phone while go­ing through it man­u­ally, as noted above), a con­fes­sion by the de­fen­dant, tes­ti­mony by a co-con­spir­a­tor who turns state’s ev­i­dence and points the fin­ger at the de­fen­dant, hard-copy doc­u­ments and other items seized with a search war­rant, and so on.

Why does this mat­ter, then, if Cellebrite mit­i­gated the flaw and no­body’s case gets thrown out?

It mat­ters be­cause peo­ple have a con­sti­tu­tional right to a fair trial, and to con­front the ev­i­dence against them, thanks to the Sixth Amendment. We also have a con­sti­tu­tional right to pro­ce­dural due process un­der the Fifth Amendment, mean­ing that if you are haled into court, there are rules; it’s not just a Kafka-esque show trial in a kan­ga­roo court where any­thing goes. Signal’s hack demon­strated an im­por­tant point: if you’re go­ing to con­vict some­body of a crime, put them be­hind bars, and take away their free­dom, based in part on the re­ports from a com­puter sys­tem, then at least that sys­tem should have ad­e­quate se­cu­rity.

Moxie’s hack might af­fect past cases, though I doubt it’ll change the out­come in many, if any. And, this par­tic­u­lar find­ing won’t af­fect fu­ture cases. That’s be­cause Cellebrite ap­par­ently has al­ready is­sued a mit­i­ga­tion (a stop-gap mea­sure to stanch the bleed­ing). (Which, if you’re law en­force­ment, you’re fum­ing mad at Cellebrite: what the hell did you pay them all this money for? As said, Cellebrite will have to get Physical Analyzer work­ing on iPhones again be­fore too long.)

Going for­ward, Signal’s hack may in­duce more de­fense at­tor­neys to de­mand to ex­am­ine Cellebrite de­vices more of­ten — not just be­cause of this bug, but be­cause if this ex­ploitable bug was in there, surely there are oth­ers, too. The blog post makes it sound like Cellebrite’s se­cu­rity is so bad that there’s plenty of low-hang­ing fruit in there.

Giving de­fense at­tor­neys more ammo to push back harder against the use of Cellebrite de­vices against their clients is Good and Right and Just. The gen­eral point that Moxie made —  Cellebrite’s tools are buggy A. F. and can be ex­ploited in ways that un­der­mine the re­li­a­bil­ity of their re­ports and ex­trac­tions as ev­i­dence, which is the en­tire point of their ex­is­tence — is ac­tu­ally more im­por­tant than the specifics of this ex­ploit or of Signal’s an­nounced app up­date (because Cellebrite’s al­ready kinda-sorta mit­i­gated against this ex­ploit).

The big­ger point is that Cellebrite, like other law en­force­ment tech ven­dors, plays fast and loose with the tech­nol­ogy that they’re sell­ing. Law en­force­ment and pros­e­cu­tors then rely upon these tools, de­spite their half-assed se­cu­rity, to jus­tify tak­ing peo­ple’s free­dom away. So Signal turned the ta­bles on them, and they showed that the em­peror has no clothes. Signal did a pub­lic ser­vice by desta­bi­liz­ing the per­cep­tion of re­li­a­bil­ity in Cellebrite.

Even if Signal’s blog post does­n’t get any­body a new trial, it proves the point that courts should­n’t rely so read­ily on Cellebrite or other such law en­force­ment tech­nol­ogy. Megan Graham, who su­per­vises a tech­nol­ogy law & pub­lic pol­icy clinic at Berkeley Law, dis­cussed the likely ram­i­fi­ca­tions of Signal’s hack in a thread on Twitter and com­ments to the press. Drawing on her deep ex­pe­ri­ence work­ing on these is­sues, she noted that law en­force­ment tech ven­dors’ ap­proach to se­cu­rity is usu­ally ba­si­cally “YOLO.” She was­n’t sur­prised at how bad Cellebrite’s se­cu­rity is.

As Graham said, hope­fully the take­away for judges is to dig more in the fu­ture into how re­li­able these law en­force­ment tech­nolo­gies ac­tu­ally are be­fore al­low­ing in ev­i­dence that was ob­tained us­ing these tools. This could be a wake-up call for courts — but it’s gonna be an up­hill bat­tle.

There are big ob­sta­cles be­tween the world as it is and the world as it should be. The courts — es­pe­cially the state courts, like the one in West Virginia where that one lawyer al­ready asked for a new trial — are very busy and very short on re­sources. (Graham and I both know that first­hand, as we both used to be the clerks to fed­eral mag­is­trate judges.) Judges don’t have a lot of time; they have re­ally heavy case­loads so there’s just too much to do. They prob­a­bly lack the back­ground to un­der­stand these new tech­nolo­gies on their own. They don’t nec­es­sar­ily have the in-house re­sources and per­son­nel to do it for them, be­cause court bud­gets are al­ways strapped. That said, judges can and do at­tend train­ings on cur­rent top­ics and new tech­nolo­gies like this… if some­body’s of­fer­ing them. (And who’s of­fer­ing them may be pros­e­cu­tors and the ven­dors of these tools.)

And any­way, judges don’t run the par­ties’ cases for them. Judges can de­cide “sua sponte” (on their own) to chal­lenge some­thing that one of the par­ties says or does, they can de­cide on their own to tell one of the par­ties to do some­thing in par­tic­u­lar, but for the most part, ob­ject­ing to some­thing one of the par­ties says or does is the lawyers’ job, not the judge’s. So it’s usu­ally go­ing to be up to the de­fense lawyer in these cases to bring a chal­lenge to a par­tic­u­lar foren­sic tool or process, or chal­lenge an ex­pert wit­ness’s qual­i­fi­ca­tions.

That costs time and money and re­sources, and those just won’t al­ways be avail­able to every de­fen­dant, who, let’s face it, is play­ing on an un­level play­ing field in the American crim­i­nal jus­tice sys­tem — by de­sign. In our sys­tem, the cards are stacked in fa­vor of the pros­e­cu­tion. And that’s why com­pa­nies like Cellebrite get away with sloppy work.

So Signal’s stunt should be a wake-up call to the courts that these tools aren’t as re­li­able as they’re held out to be, and they re­ally ought to be a lot more se­cure, and the courts should re­ally dig in there more. But the process for ac­tu­ally hold­ing these law en­force­ment tech­nol­ogy ven­dors to ac­count and forc­ing them to do bet­ter is very slow. We’re not go­ing to see a mas­sive sea change overnight just from this blog post. The po­lice de­part­ments that use Cellebrite, and the mo­bile de­vice foren­sics in­dus­try in gen­eral, are on no­tice that they need to get their act to­gether. But un­less and un­til judges and crim­i­nal de­fense at­tor­neys force them to — or, per­haps more re­al­is­ti­cally, un­less and un­til their law en­force­ment cus­tomers force them to by re­fus­ing to give them any more money un­til they step their game up — com­pa­nies like Cellebrite will con­tinue to skate by. And that’s the value of this hack. It’s one step to­wards forc­ing more ac­count­abil­ity.

Plus, the prob­lem is not just mo­bile de­vice foren­sics tools

Another rea­son that this topic is im­por­tant is that Cellebrite is not the only ex­am­ple of a tech­nol­ogy that gets sold by pri­vate-sec­tor ven­dors to some unit of gov­ern­ment — law en­force­ment, a state ad­min­is­tra­tive agency, or the courts, for ex­am­ple — which then gets used to help con­vict crim­i­nal de­fen­dants or oth­er­wise af­fect peo­ple’s rights and lives and liveli­hoods. There’s a ton of ven­dors out there that sell their tools to some part or an­other of the coun­try’s state, lo­cal, tribal, and fed­eral gov­ern­ments.

But their tools are of­ten a black box. It’s not clear how they work, or whether they ac­tu­ally work the way the ven­dors say they do. The ven­dors aren’t above mak­ing the gov­ern­ment cus­tomers that buy their tools sign a non-dis­clo­sure agree­ment say­ing they won’t dis­close any­thing about the tool they’re pay­ing for — de­spite the fact that the use of these tools can im­pli­cate peo­ple’s con­sti­tu­tional rights, which is not some­thing you can just wipe away with a con­tract.

Other ex­am­ples of tech­nolo­gies that have been paid for with your tax dol­lars in­clude:

(1) TrueAllele, a soft­ware pro­gram for help­ing law en­force­ment an­a­lyze DNA sam­ples by us­ing what’s called “probabilistic geno­typ­ing, which uses com­plex math­e­mat­i­cal for­mu­las to ex­am­ine the sta­tis­ti­cal like­li­hood that a cer­tain geno­type comes from one in­di­vid­ual over an­other,” which costs $60,000 to li­cense, and whose ven­dor has fought tooth and nail to keep its source code from be­ing ex­am­ined by crim­i­nal de­fense coun­sel, cit­ing trade se­crecy (but, in at least one re­cent case, los­ing);

(2) Stingray de­vices, aka IMSI catch­ers — de­vices used by law en­force­ment which mimic cell phone tow­ers and force the phones of every­body in the area to con­nect to them, whose ven­dor made law en­force­ment agen­cies sign NDAs that led the agen­cies to out­right lie to courts in mul­ti­ple cases about the very ex­is­tence and use of Stingray de­vices in crim­i­nal cases; and

(3) al­go­rithms that are used by the state to make de­ci­sions about such cru­cial choices as:

- whether ar­restees who are in jail should or should­n’t be let out on bail

- whether em­ploy­ees should be given or de­nied a

should get ben­e­fits such as Medicaid, Medicare, un­em­ploy­ment, and Social Security Disability Insurance.

Understandably, the peo­ple who are on the re­ceiv­ing end of these tech­nolo­gies want to know how the tools work. So their lawyers push for ac­cess to peek in­side the black box and ex­am­ine the hard­ware and/​or soft­ware and even the source code, to see how it works and try to fig­ure out if it’s flawed. And of­ten the re­sponse, as with TrueAllele and Stingrays, is that ei­ther the state, or the pri­vate-sec­tor ven­dor that makes the tool, or both, will try to keep what’s un­der the hood a se­cret. They try to keep the black box closed. These black-box chal­lenges have been a long, hard slog for ad­vo­cates fight­ing for more trans­parency and fair­ness, and the win rate is far less than 100%.

Signal ba­si­cally short-cir­cuited that whole process by just get­ting their hands on this piece of law en­force­ment tech­nol­ogy, tear­ing it apart, and pub­lish­ing some of what they found. That set the stage for ad­di­tional or re­newed chal­lenges by de­fense coun­sel to de­mand to ex­am­ine the tools.

This is why white-hat se­cu­rity re­search (and up­dat­ing the law to pro­tect it) is so im­por­tant. Private-sector ven­dors like Cellebrite that sell their tech­nol­ogy to the pub­lic sec­tor have a good thing go­ing: they get that sweet sweet tax­payer money on those con­tracts, they have lit­tle in­cen­tive to dot their i’s and cross their t’s in terms of prod­uct qual­ity so long as the cus­tomer is sat­is­fied (because the peo­ple who are sub­jected to their tools are not the cus­tomer), and they can some­times get away with keep­ing their tools’ in­ner work­ings a se­cret. But white-hat se­cu­rity re­search does­n’t nec­es­sar­ily color in­side the lines that the ven­dor dic­tates, and it can be an im­por­tant way to get cru­cial in­for­ma­tion about these gov-tech tools that the ven­dor would not share will­ingly.

In sum, Signal’s hack was a stunt that has al­ready been mit­i­gated and prob­a­bly won’t set any­body free from prison. But that does­n’t mean this was all in vain. The sil­ver lin­ing is that hope­fully white-hat se­cu­rity re­search like this will push crim­i­nal de­fense lawyers, courts, and law en­force­ment agen­cies to make ven­dors like Cellebrite do a bet­ter job… ide­ally be­fore the black hats take ad­van­tage of their slop­pi­ness.

Yes, Signal did a cool hack. Overall it was a proso­cial move. But it was also a stunt, and Signal’s blog post was vague and con­fus­ing and seemed to sug­gest, in a cutesy, plau­si­bly de­ni­able way, that the Signal app is go­ing to be up­dated so as to hack po­lice com­put­ers.

So while com­puter se­cu­rity folks were gig­gling at Signal’s cute, clever blog post, lawyers like me were sigh­ing. Why? Because of an im­por­tant life les­son that en­gi­neers typ­i­cally don’t un­der­stand: Judges hate cute and clever.

In gen­eral, if you do some­thing very clever and you show it off in a cute pre­sen­ta­tion, it won’t go over well with a judge. They have no pa­tience for stunts and show­boat­ing. The court­room is not the stage at DEF CON. And judges do not like mealy-mouthed vague state­ments that are de­signed for plau­si­ble de­ni­a­bil­ity.

Sign in

Use Git or check­out with SVN us­ing the web URL.

Work fast with our of­fi­cial CLI. Learn more.

If noth­ing hap­pens, down­load GitHub Desktop and try again.

If noth­ing hap­pens, down­load GitHub Desktop and try again.

If noth­ing hap­pens, down­load Xcode and try again.

If noth­ing hap­pens, down­load the GitHub ex­ten­sion for Visual Studio and try again.

Permalink

Sqliteviz is a sin­gle-page of­fline-first PWA for fully client-side vi­su­al­i­sa­tion of SQLite data­bases or CSV files.

With sqlite­viz you can:

run SQL queries against a SQLite data­base and cre­ate Plotly charts based on the re­sult sets

man­age queries and chart set­tings and run them against dif­fer­ent data­bases

use it of­fline from your OS ap­pli­ca­tion menu like any other desk­top app

The lat­est re­lease of sqlite­viz is de­ployed on GitHub Pages at lana-k.github.io/​sqlite­viz.

It’s a kind of mid­dle­ground be­tween Plotly Falcon and Redash.

It is built on top of re­act-chart-ed­i­tor, sql.js and Vue-Codemirror in Vue.js. CSV pars­ing is per­formed with Papa Parse.

You can’t per­form that ac­tion at this time.

You signed in with an­other tab or win­dow. Reload to re­fresh your ses­sion.

You signed out in an­other tab or win­dow. Reload to re­fresh your ses­sion.

Bibliogram is a web­site that takes data from Instagram’s pub­lic pro­file views and puts it into a friend­lier page that loads faster, gives down­load­able im­ages, elim­i­nates ads, gen­er­ates RSS feeds, and does­n’t urge you to sign up. See an ex­am­ple.

Bibliogram does not al­low you to anony­mously post, like, com­ment, fol­low, or view pri­vate pro­files. It does not pre­serve deleted posts.