Countless smartphones seized in arrests and searches by police forces across the United States are being auctioned online without first having the data on them erased, a practice that can lead to crime victims being re-victimized, a new study found. In response, the largest online marketplace for items seized in U.S. law enforcement investigations says it now ensures that all phones sold through its platform will be data-wiped prior to auction.

Researchers at the University of Maryland last year purchased 228 smartphones sold “as-is” from PropertyRoom.com, which bills itself as the largest auction house for police departments in the United States. Of phones they won at auction (at an average of $18 per phone), the researchers found 49 had no PIN or passcode; they were able to guess an additional 11 of the PINs by using the top-40 most popular PIN or swipe patterns.

Phones may end up in police custody for any number of reasons — such as its owner was involved in identity theft — and in these cases the phone itself was used as a tool to commit the crime.

“We initially expected that police would never auction these phones, as they would enable the buyer to recommit the same crimes as the previous owner,” the researchers explained in a paper released this month. “Unfortunately, that expectation has proven false in practice.”

The researchers said while they could have employed more aggressive technological measures to work out more of the PINs for the remaining phones they bought, they concluded based on the sample that a great many of the devices they won at auction had probably not been data-wiped and were protected only by a PIN.

Beyond what you would expect from unwiped second hand phones — every text message, picture, email, browser history, location history, etc. — the 61 phones they were able to access also contained significant amounts of data pertaining to crime — including victims’ data — the researchers found.

Some readers may be wondering at this point, “Why should we care about what happens to a criminal’s phone?” First off, it’s not entirely clear how these phones ended up for sale on PropertyRoom.

“Some folks are like, ‘Yeah, whatever, these are criminal phones,’ but are they?” said Dave Levin, an assistant professor of computer science at University of Maryland.

“We started looking at state laws around what they’re supposed to do with lost or stolen property, and we found that most of it ends up going the same route as civil asset forfeiture,” Levin continued. “Meaning, if they can’t find out who owns something, it eventually becomes the property of the state and gets shipped out to these resellers.”

Also, the researchers found that many of the phones clearly had personal information on them regarding previous or intended targets of crime: A dozen of the phones had photographs of government-issued IDs. Three of those were on phones that apparently belonged to sex workers; their phones contained communications with clients.

An overview of the phone functionality and data accessibility for phones purchased by the researchers.

One phone had full credit files for eight different people on it. On another device they found a screenshot including 11 stolen credit cards that were apparently purchased from an online carding shop. On yet another, the former owner had apparently been active in a Telegram group chat that sold tutorials on how to run identity theft scams.

The most interesting phone from the batches they bought at auction was one with a sticky note attached that included the device’s PIN and the notation “Gry Keyed,” no doubt a reference to the Graykey software that is often used by law enforcement agencies to brute-force a mobile device PIN.

“That one had the PIN on the back,” Levin said. “The message chain on that phone had 24 Experian and TransUnion credit histories”.

The University of Maryland team said they took care in their research not to further the victimization of people whose information was on the devices they purchased from PropertyRoom.com. That involved ensuring that none of the devices could connect to the Internet when powered on, and scanning all images on the devices against known hashes for child sexual abuse material.

It is common to find phones and other electronics for sale on auction platforms like eBay that have not been wiped of sensitive data, but in those cases eBay doesn’t possess the items being sold. In contrast, platforms like PropertyRoom obtain devices and resell them at auction directly.

PropertyRoom did not respond to multiple requests for comment. But the researchers said sometime in the past few months PropertyRoom began posting a notice stating that all mobile devices would be wiped of their data before being sold at auction.

“We informed them of our research in October 2022, and they responded that they would review our findings internally,” Levin said. “They stopped selling them for a while, but then it slowly came back, and then we made sure we won every auction. And all of the ones we got from that were indeed wiped, except there were four devices that had external SD [storage] cards in them that weren’t wiped.”

A copy of the University of Maryland study is here (PDF).

This is the first post in Italian on this blog in over ten years, mostly because it only really applies to readers who would be understanding Italian in the first place. Please see the summary on Mastodon, if you’re curious.

Sono praticamente cresciuto con La Settimana Enigmistica. Non riesco ad immaginare nessuno, in Italia, che non conosca almeno di nome questa rivista, che viene pubblicata da quasi un secolo, ininterrottamente. Quand’ero bambino, mia madre compilava le parole crociate ogni settimana, lasciandomi i giochi più semplici, come La Pista Cifrata, Che Cosa Apparirà? e Aguzzate La Vista — e man mano che sono cresciuto, mi ha insegnato a risolvere le parole crociate, semplici, crittografate e senza schema.

Purtroppo, perché la vita va come viene a volte, mentre da bambino sia La Settimana che Topolino erano dei punti di riferimento settimanali, col tempo sono diventati molto meno regolari. Con l’eccezione dei mesi passati in ospedale, dove almeno avevo a disposizione un’edicola e tanto tempo da perdere. Ma è stato solo quando me ne sono andato dall’Italia che mi sono reso conto quanto mi mancasse La Settimana.

Non è un caso che non abbia più scritto praticamente nulla in italiano da quando me ne sono andato — per quanto fossi sempre stato un bravo studente di grammatica, non sono mai stato portato nello scrivere temi in classe, o in generale nella scrittura creative italiana. Ma in aggiunta a tutto questo, scrivere in italiano è difficile da quando passo praticamente tutto il tempo a pensare e scrivere in inglese. Per dare un esempio, solo dopo aver scritto quasi tutto questo paragrafo mi sono reso conto di andare a togliere la maiuscola da italiano e inglese — vanno maiuscoli in inglese.

La Settimana Enigmistica, e in particolare, ma non solamente, le Parole Crociate, sono un’ottima ginnastica mentale per mantenere almeno un minimo di connessione con la lingua, e con il Paese. Per fare un esempio, ho scoperto che 3 Italia e Wind si fossero fuse… in una delle domende dell’Edipeo enciclopedico!

Ma come ho fatto a leggere la Settimana da Dublino (prima) e Londra (poi)? O per i molti mesi che sono stato in viaggio negli Stati Uniti, Cina, o altrove? Beh, nove anni fa, fu lanciata La Settimana Enigmistica Digitale — una versione completa della Settimana Enigmistica disponibile su tablet, sia iOS che Android. Ovviamente mi ci sono fiondato subito — eventualmente comprando un tablet Samsung con S-pen principalmente per questo motivo!

Negli scorsi nove anni, ho comprato (tra abbonamenti e numeri sfusi) 224 numeri della Settimana digitale. Non li ho sfogliati o risolti tutti, principalmente per motivi di tempo. Ma quando ho avuto tempo, modo, ed energie, sono stati un’ancora verso le mie origini, la mia “coperta di Linus” se vogliamo dirla così. L’applicazione non ha sempre funzionato molto bene a vederla bene, e non ha mai sfruttato le capacità moderne di dispositivi con il supporto per penne EMR per disattivare il touchscreen quando si usa la penna, ma almeno dal mio punto di vista non è stata una pessima scelta.

Purtroppo la rivista ha deciso di abbandonare questa applicazione in favore ad una nuova:

Caro lettore,martedì 9 maggio verrà rilasciata una nuova applicazione, in sostituzione di quella attuale. La nuova App sarà scaricabile dagli store e sarà supportata da dispositivi tablet con sistema operativo iOS 14 e Android 7 o versioni successive.

A causa di questo cambio di piattaforma, per facilitare il passaggio alla nuova App, a partire dal 03/05/2023 verrà inibita la possibilità di sottoscrivere abbonamenti nella vecchia versione.

Al rilascio della nuova applicazione, gli abbonamenti attivi già sottoscritti verranno trasferiti in modo da continuare la fruizione del servizio sulla nuova App. Le riviste verranno pubblicate anche sull’applicazione attuale fino al numero del 8/06/2023 e saranno giocabili fino al 10/07/2023, data in cui essa verrà dismessa definitivamente.

La Settimana Enigmistica — 26 Aprile 2023

Con poco più di una settimana di anticipo dal lancio della nuova versione, La Settimana Enigmistica ha deciso di dare una grossa scrollata di spalle ai lettori di lunga data. Giusto per essere chiari, ho chiesto conferma se fosse previsto che la nuova applicazione avesse a disposizione i precedenti numeri:

Buongiorno,

nella nuova applicazione i possessori di un abbonamento attivo avranno accesso anche ai numeri vecchi compresi nel loro abbonamento.
Saranno però presenti solo i numeri pubblicati negli ultimi 12 mesi, per cui i numeri precedenti al maggio 2022 non saranno sicuramente disponibili.

Ci scusiamo per il disagio, purtroppo l’avanzamento tecnologico ci ha imposto un aggiornamento della piattaforma.

La Settimana Enigmistica — 28 Aprile 2023

Ora, l’ultimo numero che ho acquistato nell’applicazione precedente risale a Febbraio 2022 (non ho comprato numeri recentemente perché onestamente ho accumulato tantissimi numeri che non ho completato) in che significa che, dopo luglio, la vecchia applicazione sarà rimossa e non avrò più modo di completare questi numeri. Ho continuato la conversazione con il supporto, chiedendo se avessero l’intenzione di permettere a chi ha comprato i numeri in precedenza di accedere ai PDF usati dall’app, ma ho ricevuto una risposta negativa, e nessuna offerta per risolvere la questione.

Ora, è verissimo che, da sviluppatore di Software Libero incluso VLC, comprendo benissimo il problema che “l’acqusito” di contenuti digitali provvisti di DRM non sia mai al sicuro, ma non ho mai visto nessun fornitore di servizi digitali suggerire ai propri lettori, con poco più di qualche mese a disposizione, di buttar via fino a nove anni di contenuti. Non stiamo parlando di un film o due o di qualche videogioco — chi si è abbonato al lancio e ha continuato a ricevere numeri finora, andrà a perdere oltre €600 in contenuti!

In tutto questo, temo che la Settimana Enigmistica abbia fatto un errore di fondo, però. Il DRM non è mai uno strumento assoluto, e poiché invece di inventare un nuovo formato per distribuire la rivista digitale, la vecchia applicazione sfruttava dei PDF perfettamente standard, l’unica difficoltà nel poterli utilizzare è la necessità di trovare la password che ognuno di questi possiede — e visto che mi hanno infranto il cuore, mi sono impegnato (neanche tanto) e ho trovato il modo di recuperare tali passwords.

Non pubblicherò il codice per ritrovare le password fino a Luglio! Inizialmente avrei voluto pubblicarlo oggi, ma ho un certo timore per il fatto che, sia in UK dove abito che in Italia dove La Settimana ha sede, la circonvenzione dei DRM anche per copia privata è illegale. In Italia, tecnicamente, è possibile farne una copia analogica, ma non credo sia di nessun interesse andare a stampare La Settimana digitale.

La mia speranza è che La Settimana veda quanto disruttiva sia la loro idea, e decida di caricare tutti i numeri precedenti sulla nuova applicazione — nel qual caso non avrò motivo di pubblicare il codice necessario. Tecnicamente, sono andato a violare le condizioni generali d’uso della vecchia applicazione. Allo stesso tempo, nulla nelle condizioni di vendita fornite da La Settimana Enigmistica Digitale suggerisce la loro capacità di distruggere i miei acquisti senza fornire un rimborso.

Nel frattempo se avete comprato numeri sulla vecchia applicazione vi consiglio di scaricarli tutti, e di fare una copia dei dati presenti. In particolare, su Android, vi servirà l’intera cartella Android/data/com.atono.lasedigitale/files/lase_digitale/Issues (tecnicamente escludendo le anteprime, ma vi consiglio di prendere l’intera cartella). Non so se o come sia possibile fare altrettanto su iOS — e non so se i PDF usati su iOS siano gli stessi usati su Android.

Come, tecnicamente, ci sono riuscito

Anche se aspetterò di pubblicare il codice nel momento in cui l’applicazione smetterà di funzionare (sempre che La Settimana Enigmistica non senta ragioni per cambiare idea), posso almeno fornire una breve descrizione.

L’applicazione Android (e immagino pure la versione iOS) scarica dei semplici file PDF per ogni numero acquistato, in aggiunta ad un file chiamato issue.json (che non è, a prima vista, un file JSON) e ad una quantità di anteprime a bassa risoluzione. Purtroppo tali PDF sono protetti da password quindi non sono direttamente apribili da un lettore PDF qualsiasi — al contrario delle restrizioni su duplicazione e stampa, che sono implementate “a parola d’onore”, i file PDF protetti da password sono cifrati.

Prima ancora di avere un modo di recuperare la password, ho scaricato tutti i numeri che ho comprato negli anni e fatto una copia dell’intera cartella Issues dal mio tablet — nel dubbio, in qualche modo le password potrebbero essere spuntate fuori. Come primo tentativo, ho lasciato il mio PC provare a trovare la password di forza bruta per una notte, senza risultati — come farò vedere fra poco, questa missione sarebbe stata completamente impossibile.

Il giorno dopo, in preda a… non disperazione, ma sicuramente noia, mi sono lamentato su Mastodon della situazione, e il mio amico ed ex-collega Pierre mi ha ricordato di fare una copia dell’applicazione stessa, nel caso in cui fosse più semplice riversare l’implementazione.

Presa la copia dell’applicazione, che non pare essere stata aggiornata dal 2011, c’ho dato un’occhiata veloce — pur sapendo che Android non è il mio forte, e non avendo mai provato a fare reverse engineering di Java in vita mia. Ma appena ho estratto il file APK (è solo un file ZIP con una struttura specifica), mi sono accorto di una cosa abbastanza banale: l’applicazione usa MuPDF.

MuPDF è un’applicazione, e una libreria, al momento sviluppata da Artifex (gli stessi di GhostScript) che permette di includere PDF direttamente in un’applicazione. In particolare, la vecchia applicazione della Settimana Digitale, usa un’estensione JNI per chiamare MuPDF dal codice Java dell’applicazione Android. Questo significa che anziché avere un’implementazione oscura (od oscurata) per decifrare i PDF, l’applicazione deve semplicemente chiamare la funzione authenticatePassword. Anche senza il minimo di esperienza in Java, trovare dove il codice chiama questa funzione dovrebbe essere banale.

Tra l’inizio del mio thread su Mastodon e avere il PDF aperto su Microsoft Edge (conoscendone quindi la password) mi ci sono volute circa cinque ore — di queste ne ho buttate un paio per tentare di far funzionare Flatpak su WSL/Ubuntu (non ha funzionato), ed eventualmente per installare Fedora Workstation su una macchina virtuale (dove Flatpak ha funzionato e Jadx mi ha permesso di aprire il codice molto semplicemente), e un’altra ora persa per via di un refuso che continuava a darmi la risposta sbagliata.

Quando pubblicherò il codice sarà abbastanza ovvio, ma per il momento vi basti sapere che non avrei mai potuto recuperare la password per forza bruta: si tratta di una password con lettere (minuscole e maiuscole), numeri, e simboli, per un totale di 28 caratteri! Secondo Hive Systems, servirebbero oltre ventiseimila miliardi di anni per ritrovare la password!

In realtà, già dal codice è possibile restringere lo spazio di ricerca: la parte centrale della password è fomata da 12 caratteri costanti che includono simboli — mentre i restanti 16 sono presi dall’alfabeto base64 (che, con l’eccezione dell’ultimo carattere, comprende 63 simboli.) Questo significa che, anche conoscendo la parte costante, ogni numero è richiederebbe selezionare la password corretta tra 225787570473400320: C^R(63, 15)×64.

Un quarto di milioni di bilioni. Volendo generare una lista di queste possibili password, assumendo 29 bytes per password, avremmo bisogno di oltre 5.6EiB (Exibibyte). Come confronto, i primi 100 trilioni di cifre di π occupano “solamente” 82 Terabyte.

Una volta conosciuta la password, qpdf permette di decifrare i file preservando tutti gli attributi e contenuti.

Cosa si fa ora?

Prima di tutto effettuate una copia di backup dei numeri che avete acquistato! Come ho detto, assicuratevi di copiare l’intera cartella Issues (che in questo caso, se non masticate l’inglese, significa numeri, della rivista, non problemi).

Poi vi consiglierei di mandare una mail alla Settimana, per chiedergli spiegazioni, e per fargli comprendere quanto non sia una bella cosa distruggere gli acquisti di nove anni dei propri lettori. Sarebbe molto più semplice se gli sviluppatori e l’editore cambiassero idea e preservassero gli acquisti nella nuova applicazione.

Io nel frattempo ripulirò per bene il codice per il programma che recupera queste password così che non sia utilizzabile solo da me. Se nulla sarà cambiato, nel momento in cui la vecchia applicazione sarà rimossa o smetterà di funzionare, lo pubblicherò, cosi tutti gli altri lettori potranno recuperare gli acquisti perduti.

E ovviamente, tornerò a risolvere le Parole Crociate dei numeri che già possiedo e non ho completato — eccetto lo farò sul mio ReMarkable 2, anziché con la loro app. È anche più realistico!

...and why this is different than blockchain/cryptocurrency/web3.

Unlike the earlier crazes, AI is obviously useful to the layperson. ChatGPT finished what tools like Midjourney started, and made the average person in front of a browser go, "oh, I get it now." That is something Blockchain, Crypto currencies, and Web3 never managed. The older fads were cool to tech nerds and finance people, but not the average 20 year old trying to make ends meet through three gig-economy jobs (except as a get-rich-quick scheme).

Disclaimer: This post is all about the emotional journey of AI-tech, and isn't diving into the ethics. We are in late stage capitalism, ethics is imposed on a technology well after it has been on the market. For a more technical take-down of generative AI, read my post from April titled "Cognitive biases and LLM/AI". ChatGPT-like technologies are exploiting human cognitive biases baked into our very genome.

For those who have avoided it, the art of marketing is all about emotional manipulation. What emotions do your brand colors evoke? What keywords inspire feelings of trust and confidence? The answers to these questions are why every 'security' page on a SaaS product's site has the phrase "bank-like security" on it; because banks evoke feelings of safe stewardship and security. This is relevant to the AI gold rush because before Midjourney and ChatGPT, AI was perceived as "fancy recommendation algorithms" such as those found on Amazon and the old Twitter "for you" timeline; after Midjourney and ChatGPT AI became "the thing that can turn my broken English into fluent English" and was much more interesting.

The perception change caused by Midjourney and ChatGPT is why you see every tech company everywhere trying to slather AI on their offerings. People see AI as useful now, and all these tech companies want to be seen as selling the best useful on the market. If you don't have AI, you're not useful, and companies who are not useful won't grow, and tech companies that aren't growing are bad tech companies. QED, late stage capitalism strikes again.

It's just a fad

Probably not. This phase of the hype cycle is a fad, but we've reached the point where if you have a content database 10% the size of the internet you can algorithmically generate human-seeming text (or audio, or video) without paying a human to do it; this isn't going to change when the hype fades, the tech is here already and will continue to improve so long as it isn't regulated into the grave. This tech is an existential threat to the content-creation business, which includes such fun people as:

• People who write news articles
• People who write editorials
• People who write fiction
• People who answer questions for others on the internet
• People who write HOW TO articles
• People who write blog posts (hello there)
• People who do voice-over work
• People who create bed-track music for podcasts
• People who create image libraries (think Getty Images)
• People who create cover art for books
• People who create fan art for commission

The list goes on. The impact here will be similar to how streaming services affected musician and actor income streams: profound.

AI is going to fundamentally change the game for a number of industries. It may be a fad, but for people working in the affected industries this fad is changing the nature of work. I still say AI itself isn't the fad, the fad is all the starry-eyed possibilities people dream of using AI for.

It's a bullshit generator, it's not real

Doesn't matter. AI is right often enough to fit squarely into human cognitive biases of trustworthy. Not all engines are the same, Google Bard and Microsoft Bing have some famous failures here, but this will change over the next two years. AI answers are right often enough, and helpful often enough, that such answers are worth looking into. Again, I refer you to my post from April titled "Cognitive biases and LLM/AI".

Today (May 1, 2023) ChatGPT is the Apple iPhone to Microsoft and Google's feature-phones. Everyone knows what happened when Apple created the smartphone market, and the money doesn't want to be on the not Apple side of that event. You're going to see extreme innovation in this space to try and knock ChatGPT off its perch (first mover is not a guarantee to be the best mover) and the success metric is going to be "doesn't smell like bullshit."

Note: "Doesn't smell like bullshit," not, "is not bullshit". Key, key difference.

Generative AI is based on theft

This sentiment is based on the training sets used for these learning models, and also on a liberal interpretation of copyright fair use. Content creators are beginning to create content under new licenses that specifically exclude use in training-sets. To my knowledge, these licenses have yet to be tested in court.

That said, this complaint about theft is the biggest threat to the AI gold rush. People don't like thieves, and if AI gets a consensus definition of thievery, trust will drop. Companies following an AI at all costs playbook to try and not get left behind will have to pay close attention to user perceptions of thievery. Companies with vast troves of user-generated data that already have a reputation for remixing, such as Facebook and Google, will have an easier time of this because users already expect such behavior from them (even if they disapprove of it). Companies that have high trust for being safe guardians of user created data will have a much harder time unless they're clear from the outset about the role of user created data in training models.

The perception of thievery is the thing most likely to halt the fad-period of AI, not being a bullshit generator.

Any company that ships AI features is losing my business

The fad phase of AI means just about everyone will be doing it, so you're going to have some hard choices to make. The people who can stick to this are the kind of people that are already self-hosting a bunch of things, and are fine with adding a few more. For the rest of us we have harm reduction techniques like using zero-knowledge encryption for whatever service we use for file-sync and email. That said, even the hold-out companies may reach for AI if it looks to have real legs in the marketplace.

Yeah. Like it or not, AI development is going to dominate the next few years of big-tech innovation.

I wrote this because I keep having this conversation with people, and this makes a handy place to point folk at.

I have built quite the reputation as an IPv6 contrarian over the years, particularly as I yearly criticize FOSDEM for describing their dual-stack network as a “legacy” network. As I keep reminding people, I’m also a relatively early adopter of IPv6 at home (with related annoyances), and I have eagerly tested and debugged issues with services having (partial) IPv6 support, such as OVH back in the days. So if I’m denying that IPv6 “has won” and is the “current” protocol versus IPv4’s legacy, this is coming from the point of view of someone who would love to see more adoption of IPv6.

Last year, we crossed 10 years since the World IPv6 Launch, the organized “flag day” when many websites started offering their services over IPv6 without having to jump through many particular hoops — for many that meant starting to publish AAAA records for their hostnames, for others it meant stopping filtering those records when resolving hostnames. But in general, that was the day that we “all” roughly decided IPv6 was no longer an experiment.

Since that day, the amount of traffic received over IPv6 continued to increase steadily — which is definitely great news… or is it? This post is actually my way of suggesting that we may be measuring the wrong thing, when we keep talking about IPv6 in terms of relative traffic on the Internet — and that if we do want to realistically think of IPv4 as a legacy technology, there’s still quite a long way to go.

The reason why I’m still insisting that IPv4 is not a legacy technology, but rather the current technology is very simple: if you are on a dual-stack network that suddenly lost IPv6 connectivity, an average user may notice something odd (I say average because us IPv6 geeks would obviously notice — I wouldn’t be able to access my own home network service!), but most likely it would be a matter of latency, rather than completely unusable network. On the other hand, if the same network loses IPv4 connectivity, that will become very clear very quickly, as any service that depends on IPv4 would suddenly just stop working!

Of course, it’s technically possible to do what FOSDEM does, and provide an IPv6-only network with NAT64 on the way out to provide access to the rest of the Internet — except the fact that no (typical) ISP is willing to do that to their customers: too much hardware just won’t work on such a network, so even for those soho-class routers that support IPv6, there’s no way to treat IPv4 as legacy. Which in turns means that basically every single piece of equipment you would buy has likely only been tested with IPv4 present, and IPv6 present maybe out of luck — this is actually a great reason why opt-in IPv6-only network are actually a great thing to have, and indeed Google used to provide one like that for testing their consumer devices. I’ll get back to devices later, first I want to go back on why I believe that the traffic ratio is a good measure.

Five years ago I already described the world of IPv6 only (home) networks as Fantasyland — the main point I made for that most of the websites for services people use for banking, household management, shopping, and so on so forth, are not IPv6 compatible. Both that analysis and my more detailed (if a bit abandoned) IPv6 in Real Life website point two trends out to me: a number of websites will not get IPv6 support until their cloud providers will get IPv6 support (I’m told AWS finally has that available, compared to then), and on the other hand websites behind CDNs such as CloudFlare, Akamai, or Fastly are all happy to serve IPv6 traffic. Neither of these are surprising if you’re used to the complexity of cloud architectures or distributed services: your dependencies mandate what you can or cannot do to begin with.

The way the world is going, I can see that more and more websites are turning to CDNs to serve at least their public-facing websites, to the point that it sometimes feels like it would be really unwise not to use a CDN for a new corporate website in the first place. The reason for this are likely worth of academic research, but at the very least feel like a combination of increased audience (more people are online), a push from Google (primarily) for websites to improve their performance (or be down-listed in their results), a scary increase in ease to run DDoS (particularly after it having been used in protest), and generally a loss on the war on bots — I wanted to link to some of Troy Hunt’s reports about how CloudFlare protected his bank account by caching the content that would have served from Azure, but the only reference I found was on Twitter, and I don’t think it’s wise to count on it.

With more websites being served over CDNs, that increases the ratio of traffic going to the very same CDNs, which in turn (since they all pretty much do support IPv6) increases the traffic ratio of IPv6 — so why do I insist it’s the wrong measure? Well, at the same time as CDNs increased their ratio of traffic, the average user traffic patterns have changed — Google, Netflix, and Meta (full disclosure, I’m currently a Meta employee and a former Google employee) are big adopters of IPv6, and all of the traffic to their product is certainly part of the IPv6 traffic! An increase in IPv6 traffic (at a home network, or ISP level) could very well mean an increase in the amount of traffic caused by streaming YouTube, Netflix, or Instagram Reels rather than any change in adoption of IPv6.

To be fair, though, measuring the proportion of traffic that those services receive over IPv6 – which both Meta and Google do and report on – has value: it provides us with information about the availability of IPv6 networking — and it tells us that currently less than 40% of networks provide IPv6. And that’s considering that (as many would remind me) a number of Mobile Internet providers have been providing IPv6-only network for 4G/5G for years.

Another measurement that I have been hearing a lot about is the amount of websites in the Alexa Top 100 (or other similar rankings) that publish IPv6 records for their hosts. I find this is definitely more interesting, but it needs some interpretation — and as you can guess by the fact I set up a separate website tracking it, I don’t believe that the right answer for this is to track a top-100 list of domains.

The first problem here is the weighing — because most of these lists are global list of most visited websites, they skew hard for websites that target a global, or large country audience. Amazon sunset the Alexa list last year, and I honestly haven’t searched for what the current replacement for this is, but searching for the last snapshot of it, in the top-10 domains, you get four Chinese services and five “Big Tech” domains — the only odd one out there is Wikipedia.

What this means in practices is that even though there are countries with very good IPv6 infrastructure (Czechia being a clear winner on my site), they are unlikely to be recorded on these results — while the moment China could have a full deployment of IPv6 (according to my employer’s data, it seems to have jumped last year in August, but still not stable — although obviously with the Great Firewall existing, this is not going to be an easy measurement) it would cover a large number of most domain leaderboards.

But if the weighting could be solved by using per-country leaderboards, there is something else that cannot be solved as easily: the fact that nowadays a website is rarely a single hostname. I’m not talking about separated asset delivery hosts (which allow you to leverage CDNs even when implementing an in-house complex web app that cannot be fully outsourced), or worse yet the analytics hosts. I’m talking about the fact that (for very good reasons, in my opinion!) most companies would not let the their marketing copy and user-access account web apps sit on the same host, or even with the same authentication system!

This may sound odd, but it’s actually quite standard practice. I’ll take banks as example because this is something that everyone has to use, one way or another, but the same is true for most srvices out there. In both the UK and Italy,banks appear to have a confusing, unmemorable hostname for their online banking, versus the site with all of the commercial information. Somehow Chase US is once again the surprise outlier here. This separation is not just useful for security (a marketing person account being compromises won’t cause user account information to be easily compromised) but it also makes for a much easier integration with CDNs, as the “marketing” site does not need user customization.

In my implementation, I have explicitly tried to track the additional hostnames involved in making use of a service, not just being able to load its marketing page. So taking Medicinos Bankas in Lithuania: its marketing page is served by Cloudflare, but their online banking login page isn’t and it’s served by their own network. It’s reasonable, I’m not sure if I’d be comfortable if Cloudflare could theoretically see my banking information and possibly leak it.

Funnily enough I can totally see the opposite situation happening, as well — that is, marketing websites with no IPv6 while the actual service supports it. It’s not unreasonable to use WordPress to maintain a marketing copy website, but Automattic still to this day does not support IPv6. While other hosting provides exist, and you could host your own WordPress, it is not an unreasonable expectation to outsource a lower-sensitiveness website.

My methodology is obviously not perfect, it does not cover a lot of important cases, such as payment flows — very few online shops implement their own payment acquisition integration, as that would be a significant cost, with high requirements, that would distract from the core business of a shop or service provider. Whether it is PayPal, Stripe, Shopify (none of which appear to publish AAAA records for their main website!), or more local alternatives, these providers need to support IPv6 well before their customers, as demonstrated by the OVH case above. If payments were to fail, and customers couldn’t be acquired, that would be a significant cost to the business, making IPv6 a risk.

This is where the attitude of what I can only hope is a vocal minority of network engineers get in the way of their goal of IPv6 adoption: you cannot just say “our network is IPv6 ready, we’ll turn it on!” — you need to be able to at least talk with the folks working at “application level” and be able to test and verify that everything fits together. Otherwise you end up with Telegram-style screwups where the application is completely ignoring the real peer IP and logging (in the best case) a fake address. Sometimes, you may actually go further up than the application developers! Do you know whether all the dependent services your web application uses support IPv6? Do the users send requests to them directly, or do you proxy those requests? Are you sending the requestor’s IP address over, for the sake of rate limiting and user protection? If so, has that flow been tested with IPv6 requests?

I promise I would come back to hardware — but I don’t want to dig again in why I will insist that IoT customers are not stupid, so please read the previous blog post if that’s what you want to argue here.

As I said above, I have a dual-stack network at home, and while I have not tried to figure out the current ratio of traffic between the two stacks on my network, I found myself cursing IPv4 and DHCP some weeks ago. You see, I’m using UniFi network with a controller that I migrated between different systems over the past five years, and between various virtual machines, test SBCs, and various other devices, I ended up getting to the point where the subnet “autoscaling” triggered – or at least tried to because on the USG it doesn’t work right – since it would have started reusing addresses in the /24 IPv4 network it used to have.

On IPv6 things would have worked fine, as I have a full /56 delegated from Hyperoptic, which means I’m distributing “standard” /64 addresses within the network… except of course most of the devices need to be in the dual-stack world at best, and most of them need to stay in the “legacy” IPv4 world probably forever, because I doubt that hardware out there would care to update their stack. Even ESPHome, which is used by the majority of the devices I have at home, only works with IPv6 in very limited circumstances — despite the fact that it would gladly stay entirely local and would be a perfect application for IPv6 with stable EUI64 addressing in the first place!

The last thing hardware manufacturers would want to deal with is requiring features from a network that are not universally present — even Multicast DNS is at best a shortcut right now, and not the sole way to access most services, due to the way WiFi routers sometimes manage to mess it up entirely. How do you expect these devices to be developed with the ability to run on a network that has no IPv4 in the first place?

And let’s not even talk about Android and its reliability (or lack thereof) to obtain IPv6 over WiFi — with the well known stubborn engineer being discussed and deconstructed for years for his complete refusal to reach feature parity with basically every other operating system out there in the form of DHCPv6. While, yes, of course it would be lovely if this could be used as a forcing function for every network operator to ditch user-hostile practices, the reality is that this turns most into a question of how hard it is to even provide IPv6 support on WiFi networks that are not directly in control of their users, such as most public WiFi — it has to just work, for them, as they wouldn’t be able to debug every customer having a different problem!

Generally, my opinion has not changed (much) over the year. While IPv6 is a great technology in theory, from the point of view of businesses that need to deploy it, it is a risk — a risk that, for most small to medium businesses, has very little upsides, as I do not believe there is any one single “killer feature” in IPv6 that (non-geek) customers have been clamoring for. HTTPS was different, and even that is not fully deployed. While I believe an investment on the deployment of IPv6 before it becomes an effective requirement is a great idea, it is the type of R&D project that network people need to learn to “sell” to their management — while accepting that it might not be something a struggling business would be interested in. Legacy, but always reachable, is better than modern while risking to lose customers.

Now, don’t mistake my skepticism at the “Mission Accomplished” feeling with accepting failure. IPv6 has come a long way since 15 years ago, and the fact that I can indeed watch all kind of movies while my DHCP server decided to give up its soul (but, crucially, not receive email!) makes me fairly happy. More importantly, I can have a monitoring setup that can reach out from my hosting provider to my flat’s infrastructure without needing a VPN (not that Tailscale didn’t make that almost as easy), while not requiring to expose it to the wider Internet.

Indeed, for backend usage IPv6 is an absolute fantastic choice. I ran the Tinderbox with Linux Containers with their own (publicly routed) IPv6 with nearly no issue, and I could very easily jump into any of them by SSH without using jumphosts or static configurations — and this was over 10 years ago! Nowadays, if you do not serve the public, it is a great choice to have an IPv6 only server, and indeed most of the cloud providers nowadays charge you extra if you need a v4. (If I didn’t need to serve the redirector, I would probably have done away with IPv4 for my monitoring server!)

I do not know what’s going to tip the scale for consumer-facing services — I personally have a feeling that IPv4 will stick around for my lifetime, unless something big happens. Maybe it’s going to be regulation, maybe it’s going to be a black swan, or maybe it’s going to be the perfect router that becomes so ubiquitous that it is unreasonable for consumers to complain if something works there and not on their setup.

Does this mean that developers have excuses to ignore IPv6? I don’t think so! IPv6 support in software is most definitely needed — as noted above, IPv6-only servers are a thing nowadays, since they are cheaper. And unless you’re working for a consumer-facing service, the whole “legacy and safe” discussion doesn’t apply — for instance, I’m significantly miffed that Automattic does not support IPv6 at all, it means I cannot run my own WordPress instance on a v6 only server, while serving it to the public via a CDN (since to active Jetpack you need their servers to reach yours.) If I was a startup looking to be paid, I would also probably be annoyed at Stripe for not supporting IPv6, though that’s a bit more understandable anyway.

More importantly, we should be paying more attention to tutorials, because right now there’s too much content that just assumes “192.168.0.x” left and right — and without some IPv6-focused updates, it’s unlikely that newcomers would be able to avoid hardcoding these expectations by mistakes. I have ranted publicly about the terrible state of looking for documentation on using Docker with IPv6 — hopefully soon I’ll be able to get myself to document this in the official places, because it turned out to be a lot simpler, once I stopped reading old, out of date tutorials.

So, to close it off, let me repeat myself: I’m not a hater of IPv6 — I’m a realist, expecting IPv4 and dual-stack solutions to stay around for a very long time. I’m also skeptical of yelling “Mission Accomplished”, or saying that it is someone else’s problem if IPv6 adoption is not complete yet. I also am a bit… concerned about the amount of people who appear to have made IPv6 so much part of their persona that they refuse to hear any of the criticism related to its deployment or implementation. I wish them good luck.

If you are interested in keep track of IPv6 in real life, I welcome contributions to either the list of websites to check or to the methodology over GitHub (assuming you have IPv4 connectivity, since that is also still not publishing AAAA records) — I’m not wed to any of the current details of the implementation, and it would really be nicer to use an actual headless Chrome to see if the page renders at all with just v6, even though that would be a lot more complex and resource-hungry to generate.

Got back our taxes from the accountant today. This year’s taxes are, to put it charitably, a tangle: not only my usual hodgepodge of royalty and option statements, but also matters attending to the church and its renovation, our rental property, interest and investments, and a bunch of other stuff that, were I trying to handle it all myself, I would have set myself on fire and run screaming into the night. But our accountant was all, like, “oh, all this? No problem at all” and just dealt with it. And got our taxes to us well in advance of their final filing date.

This is yet another reason why I am grateful for the people who do things for me I can’t or don’t want to do, and will do it happily, and cheerfully, and all I have to do to get them to do it is throw money at them. Yes, a privilege, certainly! But if you have the privilege, what a wonderful thing. My accountant is one of my very favorite people, professionally speaking. I assure you I do not take the financial skills she wields for granted. She’s friggin’ magic, I tell you. Julie Boring of Boring and Associates, if you’re reading this, just know: I appreciate you. Like, a lot.

If you have a tax profile that is in any way complicated, and you can afford it, I strongly encourage you to get an accountant as well. They’re tax deductible! And will make your life so much easier, at least in the month of April.

— JS

The vast majority of Irish Airbnbs are illegal. Two law students are going after them



A former Labour Party TD wants you to think that “Airbnb recognises the historic housing challenges facing Ireland” and that the company wants “to be part of the solution”.

Tags:

via Pocket <a href="https://www.ontheditch.com/illegal-airbnbs/" rel="nofollow">https://www.ontheditch.com/illegal-airbnbs/</a>

April 07, 2023 at 01:05PM