The Internet is full of commercial activity and it should come at no surprise that even illegal commercial activity is widespread as well. In this article we would like to describe
the current developments – from where we came, where we are now, and where it might be going – when it comes to technologies used for digital black market activity.
…
The other major change is the use of “dead drops” instead of the postal system which has proven vulnerable to tracking and interception. Now, goods are hidden in publicly accessible
places like parks and the location is given to the customer on purchase. The customer then goes to the location and picks up the goods. This means that delivery becomes asynchronous
for the merchant, he can hide a lot of product in different locations for future, not yet known, purchases. For the client the time to delivery is significantly shorter than waiting
for a letter or parcel shipped by traditional means – he has the product in his hands in a matter of hours instead of days. Furthermore this method does not require for the customer
to give any personally identifiable information to the merchant, which in turn doesn’t have to safeguard it anymore. Less data means less risk for everyone.
The use of dead drops also significantly reduces the risk of the merchant to be discovered by tracking within the postal system. He does not have to visit any easily to surveil post
office or letter box, instead the whole public space becomes his hiding territory.
…
From when I first learned about the existence of The Silk Road and its successors – places on the dark web where it’s possible to pseudo-anonymously make illicit purchases of e.g.
drugs, weapons, fake ID and the like in exchange for cryptocurrencies like Bitcoin – it always seemed to me that the weak point was that the “buyer” had to provide their postal address
to the “seller”. While there have, as this article describes, been a number of arrested made following postal inspections (especially as packages cross administrative boundaries), the
bigger risk I’d assume that this poses to the buyer is that they must trust the seller (who is, naturally, a bigger and more-interesting target) to appropriately secure and
securely-destroy that address information. In the event of a raid on a seller – or, indeed, law enforcement posing as a seller in a sting operation – the buyer is at
significant risk.
That risk may not be huge for Johnny Pothead who wants to buy an ounce of weed, but it rapidly scales up for “middleman” distributors who buy drugs in bulk, repackage, and resell either
on darknet markets or via conventional channels: these are obvious targets for law enforcement because their arrest disrupts the distribution chain and convictions are usually
relatively easy (“intent to supply” can be demonstrated in many jurisdictions by the volume of the product in which they’re found to be in possession). A solution to this problem, for
drug markets at least, with the fringe benefit of potentially faster-deliveries is pre-established dead drops (the downside, of course, is a more-limited geographical coverage and the
risk of discovery by a non-purchaser, but the latter of these can at least be mitigated), and it’s unsurprising to hear that this is the direction in which the ecosystem is moving. And
once you, Jenny Drugdealer, are putting that kind of infrastructure in place anyway, you might as well extend it to your regular clients too. So yeah: not surprising to see
things moving in this direction.
I recall that some years ago, a friend whom I’m introduced to geocaching accidentally ran across a dead drop (or a stash) while hunting for a ‘cache that was hidden in the same general
area. The stash was of clearly-stolen credit cards, and of course she turned it in to the police, but I think it’s interesting that these imaginative digital-era drug dealers, in trying
to improve upon a technique popularised by Cold War era spies by adding the capacity for long-time concealment of dead drops, are effectively re-inventing what the geocaching community
has been doing for ages.
This comic from the fabulous Oh Joy Sex Toy folks gives a pretty good explanation of vasectomy that mirrors my experience (part one,
part two)… except for the fact that I didn’t have this dude’s anxiety issue and was instead (according to the surgeon) “creepily interested”
in the nitty-gritty of what he was up to!
The choice of this encoding has made ASCII-compatible standards the language that computers use to communicate to this day.
Even casual internet users have probably encountered a URL with “%20” in it where there logically ought to be a space character. If we look at this RFC we see this:
Column/Row Symbol Name
2/0 SP Space (Normally Non-Printing)
Hey would you look at that! Column 2, row 0 (2,0; 20!) is what stands for “space”. When you see that “%20”, it’s because of this RFC, which exists because of some bureaucratic
decisions made in the 1950s and 1960s.
…
Darius Kazemi is reading a single RFC every day throughout 2019 and writing up his understanding as to the content and importance of each. It’s good reading if you’re “into” RFCs and it’s probably pretty interesting if you’re just a casual Internet historian.
In a blog post, cryptographer Matthew Green summarized the technical problems
with this GCHQ proposal. Basically, making this backdoor work requires not only changing the cloud computers that oversee communications, but it also means changing the client program
on everyone’s phone and computer. And that change makes all of those systems less secure. Levy and Robinson make a big deal of the fact that their backdoor would only be targeted
against specific individuals and their communications, but it’s still a general backdoor that could be
used against anybody.
The basic problem is that a backdoor is a technical capability — a vulnerability — that is available to anyone who knows about it and has access to it. Surrounding that vulnerability
is a procedural system that tries to limit access to that capability. Computers, especially internet-connected computers, are inherently hackable, limiting the effectiveness of any
procedures. The best defense is to not have the vulnerability at all.
…
Lest we ever forget why security backdoors, however weasely well-worded, are a terrible idea, we’ve got Schneier calling them out. Spooks in democratic nations the
world over keep coming up with “innovative” suggestions like this one from GCHQ but they keep solving the same problem, the technical problem of key distribution or
key weakening or whatever it is that they want to achieve this week, without solving the actual underlying problem which is that any weakness introduced to a secure
system, even a weakness that was created outwardly for the benefit of the “good guys”, can and eventually will be used by the “bad guys” too.
Furthermore: any known weakness introduced into a system for the purpose of helping the “good guys” will result in the distrust of that system by the people they’re trying to
catch. It’s pretty trivial for criminals, foreign agents and terrorists to switch from networks that their enemies have rooted to networks that they (presumably) haven’t, which tends to
mean a drift towards open-source security systems. Ultimately, any backdoor that gets used in a country with transparent judicial processes becomes effectively public
knowledge, and ceases to be useful for the “good guys” any more. Only the non-criminals suffer, in the long run.
With each tap, a small electrical current passes from the screen to her hand. Because electricity flows easily through human bodies, sensors on the phone register a change in voltage
wherever her thumb presses against the screen. But the world is messy, and the phone senses random fluctuations in voltage across the rest of the screen, too, so an algorithm
determines the biggest, thumbiest-looking voltage fluctuations and assumes that’s where she intended to press.
Figure 0. Capacitive touch.
So she starts tap-tap-tapping on the keyboard, one letter at a time.
I-spacebar-l-o-v-e-spacebar-y-o-u.
…
I’ve long been a fan of “full story” examinations of how technology works. This one looks and the sending and receipt of an SMS text message from concept through touchscreen, encoding
and transmission, decoding and display. It’s good to be reminded that whatever technology you build, even a “basic” Arduino project, a “simple” website or a “throwaway” mobile app,
you’re standing on the shoulders of giants. Your work sits atop decades or more of infrastructure, standards, electronics and research.
Sometimes it feels pretty fragile. But mostly it feels like magic.
If you’re reading this post via my blog and using a desktop computer, try opening your browser’s debug console (don’t worry; I’ll wait). If you don’t know how, here’s instructions for Firefox and instructions for Chrome. Other browsers may vary. You ought to see something like this in your
debugger:
The debug console is designed to be used by web developers so that they can write Javascript code right in their browser as well as to investigate any problems with the code run by a
web page. The web page itself can also output to the console, which is usually used for what I call “hello-based debugging”: printing out messages throughout a process so that the flow
and progress can be monitored by the developer without having to do “proper” debugging. And it gets used by some web pages to deliver secret messages to any of the site users who open
their debugger.
Facebook writes to the console a “stop” message, advising against using the console unless you know what you’re doing in an attempt to stop people making themselves victims of
console-based social engineering attacks.
Principally, though, the console is designed for textual content and nothing else. That said, both Firefox and Chrome’s consoles permit the use of CSS to style blocks of debug output by using the %c escape sequence. For example, I could style some of a message with italic text:
>> console.log('I have some %citalic %ctext', 'font-style:
italic;', ''); I have someitalictext
Using CSS directives like background, then, it’s easy
to see how one could embed an image into the console, and that’s been done before. Instead, though, I wanted to use
the lessons I’d learned developing PicInHTML 8¾ years ago to use text and CSS
(only) to render a colour picture to the console. First, I created my template image – a hackergotchi of me and an accompanying
speech bubble, shrunk to a tiny size and posterised to reduce the number of colours used and saved as a PNG.
The image appears “squashed” to compensate for console monospace letters not being “square”.
Next, I wrote a quick Ruby program, consolepic.rb, to do the hard work. It analyses each pixel of the image
and for each distinct colour assigns to a variable the CSS code used to set the background colour to that colour. It looks for
“strings” of like pixels and combines them into one, and then outputs the Javascript necessary to write out all of the above. Finally, I made a few hand-tweaks to insert the text into
the speech bubble.
The resulting output weighs in at 31.6kB – about a quarter of the size of the custom Javascript on the frontend of my
site and so quite a bit larger than I’d have liked and significantly less-efficient than the image itself, even base64-encoded for embedding directly into the code, but that
really wasn’t the point of the exercise, was it? (I’m pretty sure there’s significant room for improvement from a performance perspective…)
What it achieved was an interesting experiment into what can be achieved with Javascript, CSS, the browser console, and a little
imagination. An experiment that can live here on my site, for anybody who looks in the direction of their debugger, for the foreseeable future (or until I get bored of it). Anybody with
any more-exotic/silly ideas about what this technique could be used for is welcome to let me know!
Update: 17 April 2019 – fun though this was, it wasn’t worth continuing to deliver an additional 25% Javascript payload to every
visitor just for this, so I’ve stopped it for now. You can still read the source code (and even manually run it in the
console) if you like. And I have other ideas for fun things to do with the console, so keep an eye out for that…
An open source checklist of resources designed to improve your online privacy and security. Check things off to keep track as you go.
…
I’m pretty impressed with this resource. It’s a little US-centric and I would have put the suggestions into a different order, but many of the ideas on it are very good and are
presented in a way that makes them accessible to a wide audience.
During that time I’ve repeatedly tried to contact CO both through this site and through Go Active Oxfordshire (to report this as probably-missing and to volunteer to help with its
future maintenance if they want to bring it back to life), but never received a response.
I strongly suspect that this cache is abandoned by the organisation that set it up. I’m reaching out to them today, one last time, but if they don’t respond then I suggest that this be
considered for archiving by an administrator.
Came past here the other day while some work was being done on the island. The entire area around the GZ has been torn-up and it seems likely that the cache has been muggled and that
the area might no-longer be suitable for a cache. :-(
Summary: if an idealised weight slides into another, bouncing it off a wall then back into itself, how many times will the two collide? If the two weights are the same then the answer
is 3: the first collision imparts all of the force of the first into the second, the second collision is the second bouncing off the wall, and the third imparts the force from the
second back into the first. If the second weight weighs ten times as much as the first, the answer turns out to be 31. One hundred times as much, and there are 314 bounces. One thousand
times, and there are 3,141. Ten thousand times, and there are 31,415… spot the pattern? The number of bounces are the digits of pi.
Why? This is mindblowing. And this video doesn’t answer the question (completely): it only poses it. But I’ll be looking forward to the next episode’s explanation…
Brian and Nick are back for the first time in, like, forever. Do you remember what happened before this? It was The Faux
Pas, two years ago. And before that? And before that? And before that? The short of it is that it’s been a long time since your mom’s butthole was just fine.
It’s my birthday on YYYY-01-08 (Birthday geohash achievement, here I
come!), and even though I have to go into work (boo!), I note that my graticule’s geohashpoint falls only about a kilometre and a half of a diversion from my usual cycle route to work.
The A4260 and A34 are basically a deathtrap for cyclists, so depending on conditions and traffic I’ll probably divert via the Oxford Canal towpath from Kidlington to Peartree, park up
near Peartree Services, and then finish on foot. And then go to work, I guess.
Expedition
Success! A relatively easy (but sometimes scary: the traffic’s a bit nuts on some of the major roads that provided the shortest route) journey to the hashpoint area, followed by a
slightly-scary crossing of the road to the hashpoint, which turned out to be right by the crash barriers at the central reservation. The crash barriers provided a great place to tie a
“The Internet Was Here” sign.
On my way away from the hashpoint, at 09:19, I hid a geocache: (“2019-01-08 51 -1, 09:19”, OK049E, GC827X6). The geocache is of the “puzzle” variety – the person looking for it is likely to discover geohashing (if they haven’t already) as part of their research into
the secret location of the cache.
