Pest Solutions Oxfordshire, Swinford Park, Eynsham OX29 4BY, United Kingdom.
Rating: ⭐⭐⭐⭐⭐
Same-day service… when I called on a Saturday lunchtime! Explained everything over the phone, charged fairly, and offered to come back for free if the problematic wasps nest wasn’t
completely eradicated the first time. Can’t do better than that!
Came by to check up on this cache following the previous log entry. Everything is fine here; tucked the paracord away a little more-tidily and did a little litter picking, and my
preschooler took a pink flower with which to decorate a nearby fairy door.
(With owner’s permission) moved cache container about 30cm closer to the road in order to put it under better cover, as the bush that used to provide for its concealment has been
severely cut back. Cache still intact and happy (but thanks to wynner71 for the shout).
Previous Page
Dark Science #85 is almost finished, but in the meantime enjoy this interlude comic with indispensable cyborg knowledge! Enjoy Dresden Codak? Become a Patreon subscriber today!
http://dresdencodak.com/wp-content/plugins/patron-button-and-widgets-by-codebard/images/patreo…
Dresden Codak is one of the most fabulous (but strange) webcomic series, and it’s great to see this quirky “aside” piece.
It's a psychological quirk that when something becomes rarer, people may spot it in more places than ever. What is the 'concept creep' that lets context change how we categorize the
world around us?
Why do many problems in life seem to stubbornly stick around, no matter how hard people work to fix them? It turns out that a quirk in the way human brains process information means
that when something becomes rare, we sometimes see it in more places than ever.
Think of a “neighborhood watch” made up of volunteers who call the police when they see anything suspicious. Imagine a new volunteer who joins the watch to help lower crime in the
area. When they first start volunteering, they raise the alarm when they see signs of serious crimes, like assault or burglary.
Let’s assume these efforts help and, over time, assaults and burglaries become rarer in the neighborhood. What would the volunteer do next? One possibility is that they would relax
and stop calling the police. After all, the serious crimes they used to worry about are a thing of the past.
But you may share the intuition my research group had – that many volunteers in this situation wouldn’t relax just because crime went down. Instead, they’d start calling things
“suspicious” that they would never have cared about back when crime was high, like jaywalking or loitering at night.
You can probably think of many similar situations in which problems never seem to go away, because people keep changing how they define them. This is sometimes called “concept creep,” or “moving the goalposts,” and it can be a frustrating experience. How can you know if you’re making progress
solving a problem, when you keep redefining what it means to solve it? My colleagues and I wanted to understand when this kind
of behavior happens, why, and if it can be prevented.
After violent crime starts going down, loiterers and jaywalkers may start to seem more threatening.Marc Bruxelle/Shutterstock.com
Looking for trouble
To study how concepts change when they become less common, we brought volunteers into our laboratory and gave them a
simple task – to look at a series of computer-generated faces and decide which ones seem “threatening.” The faces had been carefully
designed by researchers to range from very intimidating to very harmless.
As we showed people fewer and fewer threatening faces over time, we found that they expanded their definition of “threatening” to include a wider range of faces. In other words,
when they ran out of threatening faces to find, they started calling faces threatening that they used to call harmless. Rather than being a consistent category, what people
considered “threats” depended on how many threats they had seen lately.
This kind of inconsistency isn’t limited to judgments about threat. In another experiment, we asked people to make an even simpler decision: whether colored dots on a screen were
blue or purple.
As the context changes, so do the boundaries of your categories.David Levari, CC BY-ND
As blue dots became rare, people started calling slightly purple dots blue. They even did this when we told them blue dots were going to become rare, or offered them cash prizes to
stay consistent over time. These results suggest that this behavior isn’t entirely under conscious control – otherwise, people would have been able to be consistent to earn a cash
prize.
Expanding what counts as immoral
After looking at the results of our experiments on facial threat and color judgments, our research group wondered if maybe this
was just a funny property of the visual system. Would this kind of concept change also happen with non-visual judgments?
To test this, we ran a final experiment in which we asked volunteers to read about different scientific studies, and decide which were ethical and which were unethical. We were
skeptical that we would find the same inconsistencies in these kind of judgments that we did with colors and threat.
Why? Because moral judgments, we suspected, would be more consistent across time than other kinds of judgments. After all, if you think violence is wrong today, you should still
think it is wrong tomorrow, regardless of how much or how little violence you see that day.
But surprisingly, we found the same pattern. As we showed people fewer and fewer unethical studies over time, they started calling a wider range of studies unethical. In other
words, just because they were reading about fewer unethical studies, they became harsher judges of what counted as ethical.
The brain likes to make comparisons
Why can’t people help but expand what they call threatening when threats become rare? Research from cognitive psychology and neuroscience suggests that this kind of behavior is a
consequence of the basic way that our brains process information – we are constantly comparing what is front of us to its recent
context.
Instead of carefully deciding how threatening a face is compared to all other faces, the brain can just store how threatening it is compared to other faces it has seen recently, or compare it to some average
of recently seen faces, or the most and least threatening faces it has seen. This kind of comparison could lead directly to the
pattern my research group saw in our experiments, because when threatening faces are rare, new faces would be judged relative to mostly harmless faces. In a sea of mild faces, even
slightly threatening faces might seem scary.
It turns out that for your brain, relative comparisons often use less energy than absolute measurements. To get a sense
for why this is, just think about how it’s easier to remember which of your cousins is the tallest than exactly how tall each cousin is. Human brains have likely evolved to use relative comparisons in many situations, because these comparisons often provide enough information to safely navigate our
environments and make decisions, all while expending as little effort as possible.
Being consistent when it counts
Sometimes, relative judgments work just fine. If you are looking for a fancy restaurant, what you count as “fancy” in Paris, Texas, should be different than in Paris, France.
But a neighborhood watcher who makes relative judgments will keep expanding their concept of “crime” to include milder and milder transgressions, long after serious crimes have
become rare. As a result, they may never fully appreciate their success in helping to reduce the problem they are worried about. From medical diagnoses to financial investments,
modern humans have to make many complicated judgments where being consistent matters.
How can people make more consistent decisions when necessary? My research group is currently doing follow-up research in the lab to develop more effective interventions to help
counter the strange consequences of relative judgment.
One potential strategy: When you’re making decisions where consistency is important, define your categories as clearly as you can. So if you do join a neighborhood watch, think
about writing down a list of what kinds of transgressions to worry about when you start. Otherwise, before you know it, you may find yourself calling the cops on dogs being walked
without leashes.
I remember when this advertisement did its original run and I loved it. I was delighted to accidentally stumble across it on the Web recently; if you haven’t seen it before (and even if
you have) you should give it a watch…
The unprecedented spell of hot, dry weather across Wales has provided perfect conditions for archaeological aerial photography. As the drought has persisted across Wales, scores of
long-buried archaeological sites have been revealed once again as ‘cropmarks’, or patterns of growth in ripening crops and parched grasslands. The Royal Commission’s aerial
investigator Dr Toby Driver has been busy in the skies across mid and south Wales over the last week documenting known sites in the dry conditions, but also discovering hitherto lost
monuments. With the drought expected to last at least another two weeks Toby will be surveying right across north and south Wales in a light aircraft to permanently record these
discoveries for the National Monuments Record of Wales, before thunderstorms and rain wash away the markings
until the next dry summer.
There comes a time when people at a technical conference like this need something more relaxing. A change of pace. A shift of style. To put aside all that work stuff and think of
something refreshingly different.
So let’s talk about coding theory. There are perhaps some of you here tonight who are not experts in coding theory, but rather have been dragged here kicking and screaming. So I
thought it would be a good idea if I gave you a sort of instant, five minute graduate course in coding theory.
Coding theorists are concerned with two things. Firstly and most importantly they are concerned with the private lives of two people called Alice and Bob. In theory papers, whenever a
coding theorist wants to describe a transaction between two parties he doesn’t call then A and B. No. For some longstanding traditional reason he calls them Alice and Bob.
Now there are hundreds of papers written about Alice and Bob. Over the years Alice and Bob have tried to defraud insurance companies, they’ve played poker for high stakes by mail, and
they’ve exchanged secret messages over tapped telephones.
If we put together all the little details from here and there, snippets from lots of papers, we get a fascinating picture of their lives. This may be the first time a definitive
biography of Alice and Bob has been given.
In papers written by American authors Bob is frequently selling stock to speculators. From the number of stock market deals Bob is involved in we infer that he is probably a
stockbroker. However from his concern about eavesdropping he is probably active in some subversive enterprise as well. And from the number of times Alice tries to buy stock from him
we infer she is probably a speculator. Alice is also concerned that her financial dealings with Bob are not brought to the attention of her husband. So Bob is a subversive stockbroker
and Alice is a two-timing speculator.
But Alice has a number of serious problems. She and Bob only get to talk by telephone or by electronic mail. In the country where they live the telephone service is very expensive.
And Alice and Bob are cheapskates. So the first thing Alice must do is MINIMIZE THE COST OF THE PHONE CALL.
The telephone is also very noisy. Often the interference is so bad that Alice and Bob can hardly hear each other. On top of that Alice and Bob have very powerful enemies. One of their
enemies is the Tax Authority. Another is the Secret Police. This is a pity, since their favorite topics of discussion are tax frauds and overthrowing the government.
These enemies have almost unlimited resources. They always listen in to telephone conversations between Alice and Bob. And these enemies are very sneaky. One of their favorite tricks
is to telephone Alice and pretend to be Bob.
Well, you think, so all Alice has to do is listen very carefully to be sure she recognizes Bob’s voice. But no. You see Alice has never met Bob. She has no idea what his voice sounds
like.
So you see Alice has a whole bunch of problems to face. Oh yes, and there is one more thing I forgot so say – Alice doesn’t trust Bob. We don’t know why she doesn’t trust him, but at
some time in the past there has been an incident.
Now most people in Alice’s position would give up. Not Alice. She has courage which can only be described as awesome. Against all odds, over a noisy telephone line, tapped by the tax
authorities and the secret police, Alice will happily attempt, with someone she doesn’t trust, whom she cannot hear clearly, and who is probably someone else, to fiddle her tax
returns and to organize a coup d’etat, while at the same time minimizing the cost of the phone call.
A coding theorist is someone who doesn’t think Alice is crazy.
…
I’ve always been a fan of the “expanded universe” of cyptography placeholders Alice & Bob, and this humorous speech –
partially-reproduced here – is a great example of Alice & Bob headcanon at its best.
Fabulous explanation of the Strong Equivalence Principle coupled with a nice bit of recent research to prove that it holds true even in extreme gravitational fields (and therefore
disproving a few interesting fringe theories). It’s hard science made to enjoy like pop science: yay! Plus a Hitch-Hiker’s Guide to the Galaxy reference, to boot. Under 10,000
views; go show them some love.
The day that Mitchell Hurwitz starts making shallow humor is the day that we rip the mask off of Mitchell Hurwitz and find the real Mitchell Hurwitz bound in his own cellar.
Throughout the first three seasons of Arrested Development, we were treated to some ridiculous attention to details, hidden clues, foreshadowing, Easter eggs, and in-jokes. For instance, ever wonder what
was with the obsession with seals in the first few seasons? They were actually a metaphor for Lucille Bluth, the matriarch of the family, who kept poor baby Buster Bluth, a
juice-loving man child, terrified of ever leaving the nest (or entering the ocean). As an act of defiance, Buster enters the ocean and gets his hand bitten off by a “loose seal.”
Loose. Seal. “Lucille.” Do I need to add a “GET IT?!” there?
But that’s not even the crazy part. As we’ve talked about before, the hand being bitten off was foreshadowed throughout the entire season. In one episode in season three,
the U.S. Securities and Exchange Commission attempts to persuade Tobias Funke, a struggling actor, into
cooperating with them and becoming a mole in the Bluth family. He misunderstands the entire situation and inadvertently becomes a mole (in all senses of the word — by which I mean he
fucking dresses like a mole.) But the real mole in the family was right under our noses all along since season one …
Look at his shirt.
However, all of this is just a teaser for the grandest mystery in Arrested Development: that of “Nichael Bluth.”
I recently discovered a minor security vulnerability in mobile webcomic reading app Comic Chameleon, and I thought that it was interesting
(and tame) enough to share as a learning example of (a) how to find security vulnerabilities in an app like this, and (b) more importantly, how to write an app like this
without this kind of security vulnerability.
The nature of the vulnerability is that, for webcomics pushed directly into the platform by their authors, it’s possible to read comics (long) before they’re published. By way
of proof, here’s a copy of the top-right 200 × 120 pixels of episode 54 of the (excellent) Forward
Comic, which Imgur will confirm was uploaded on 2 July 2018: over three months ahead of its planned publication date.
I’m not going to spoil this comic for you, but if you follow it then when October comes I think you’ll be pleased.
How to hack a web-backed app
Just to be clear, I didn’t set out to hack this app, but once I stumbled upon the vulnerability I wanted to make sure that I was able to collect enough information that I’d be
able to explain to its author what was wrong and how to fix it. You’d be amazed how many systems I find security holes in almost-completely by accident. In fact, I’d just noticed that
the application supported some webcomics that I follow but for which I hadn’t been able to find RSS feeds (and so I was selfdogfooding my own tool, RSSey, to “produce” RSS feeds for my reader by screen-scraping: not the most-elegant solution). But if this app could produce a list of issues of the comic, it
must have some way of doing what I was trying to do, and I wanted to know what it was.
Comic Chameleon brings a lot of comics into a single slick Android/iOS app. Some of them you’ll even have heard of!
The app, I figured, must “phone home” to some website – probably the app’s official website itself – to get the list of comics that it supports and details of where to get their feeds
from, so I grabbed a copy of the app and started investigating. Because I figured I was probably looking for a URL, the first thing I
did was to download the raw APK file (your favourite search engine can tell you how to do this), decompressed it (APK files are just ZIP files, really) and ran strings on it to search for
likely-looking URLs:
As predicted, there are several hard-coded addresses. And all over unencrypted HTTP, eww!
I tried visiting a few of the addresses but many of them seemed to be API endpoints that were expecting additional parameters. Probably, I figured, the strings I’d extracted were
prefixes to which those parameters were attached. Rather than fuzz for the right parameters, I decided to watch what the app did: I spun up a simulated Android device using the official
emulator (I could have used my own on a wireless network that I control, of course, but this was lazier) and ran my favourite packet sniffer to
see what the application was requesting.
The web addresses are even clearer, here, and include all of the parameters I need.
Now I had full web addresses with parameters. Comparing the parameters that appeared when I clicked different comics revealed that each comic in the “full list” was assigned a numeric
ID which was used when requesting issues of that comic (along with an intermediate stage where the year of publication is requested).
Each comic is assigned an ID number, probably sequentially.
Interestingly, a number of comics were listed with the attribute s="no-show" and did not appear in the app: it looked like comics that weren’t yet being made available via
the app were already being indexed and collected by its web component, and for some reason were being exposed via the XML
API: presumably the developer had never considered that anybody but their app would look at the XML itself, but the thing about the Web is that if you put it on the Web, anybody can see it.
Still: at this point I assumed that I was about to find what I was looking for – some kind of machine-readable source (an RSS feed
or something like one) for a webcomic or two. But when I looked at the XML API for one of those webcomics I discovered quite a bit more than I’d bargained on finding:
Hey, what’s this? This feed includes titles for webcomics that haven’t been published yet, marked as ‘no-show’…
The first webcomic I looked at included the “official” web addresses and titles of each published comic… but also several not yet published ones. The unpublished ones were
marked with s="no-show" to indicate to the app that they weren’t to be shown, but I could now see them. The “official” web addresses didn’t work for me, as I’d expected,
but when I tried Comic Chameleon’s versions of the addresses, I found that I could see entire episodes of comics, up to three and a half months ahead of their expected
publication date.
Whoops.
Naturally, I compiled all of my findings into an email and contacted the app developer with all of the details they’d need to fix it – in hacker terms, I’m one of the “good guys”! – but
I wanted to share this particular example with you because (a) it’s not a very dangerous leak of data (a few webcomics a few weeks early and/or a way to evade a few ads isn’t
going to kill anybody) and (b) it’s very illustrative of the kinds of mistakes that app developers are making a lot, these days, and it’s important to understand why
so that you’re not among them. On to that in a moment.
Responsible disclosure
Because (I’d like to think) I’m one of the “good guys” in the security world, the first thing I did after the research above was to contact the author of the software. They didn’t seem
to have a security.txt file, a disclosure policy, nor a profile on any of the major disclosure management sites, so I sent an email. Were the
security issue more-severe, I’d have sent a preliminary email suggesting (and agreeing on a mechanism for) encrypted email, but given the low impact of this particular issue, I just
explained the entire issue in the initial email: basically what you’ve read above, plus some tips on fixing the issue and an offer to help out.
This is what stock photo sites think “hacking” is. Well… this, pages full of green code, or hoodies.
I subscribe to the doctrine of responsible disclosure, which – in the event of more-significant vulnerabilities –
means that after first contacting the developer of an insecure system and giving them time to fix it, it’s acceptable (in fact: in significant cases, it’s
socially-responsible) to publish the details of the vulnerability. In this case, though, I think the whole experience makes an interesting learning example about ways in which
you might begin to “black box” test an app for data leaks like this and – below – how to think about software development
in a way that limits the risk of such vulnerabilities appearing in the first place.
The author of this software hasn’t given any answer to any of the emails I’ve sent over the last couple of weeks, so I’m assuming that they just plan to leave this particular leak in
place. I reached out and contacted the author of Forward Comic, though, which turns out (coincidentally) to be probably the most-severely affected publication on the platform, so that
he had the option of taking action before I published this blog post.
Lessons to learn
When developing an “app” (whether for the web or a desktop or mobile platform) that connects to an Internet service to collect data, here are the important things you really, really
ought to do:
Don’t publish any data that you don’t want the user to see.
If the data isn’t for everybody, remember to authenticate the user.
And for heaven’s sake use SSL, it’s not the 1990s any more.
It’s a good job that nobody on the Web would ever try to view something easily-available but which they shouldn’t, right? That’s why screens like this have always worked so well.
That first lesson’s the big one of course: if you don’t want something to be on the public Internet, don’t put it on the public Internet! The feeds I found simply
shouldn’t have contained the “secret” information that they did, and the unpublished comics shouldn’t have been online at real web addresses. But aside from (or in addition to)
not including these unpublished items in the data feeds, what else might our app developer have considered?
Encryption. There’s no excuse for not using HTTPS these days. This alone wouldn’t have prevented a deliberate effort
to read the secret data, but it would help prevent it from happening accidentally (which is a risk right now), e.g. on a proxy server or while debugging something else on the same
network link. It also protects the user from exposing their browsing habits (do you want everybody at that coffee shop to know what weird comics you read?) and from having
content ‘injected’ (do you want the person at the next table of the coffee shop to be able to choose what you see when you ask for a comic?
Authentication (app). The app could work harder to prove that it’s genuinely the app when it contacts the website. No mechanism for doing this can ever be perfect,
because the user hasa access to the app and can theoretically reverse-engineer it to fish the entire authentication strategy out of it, but some approaches are better than others.
Sending a password (e.g. over Basic Authentication) is barely better than just using a complex web address, but
using a client-side certiciate or an OTP algorithm would (in conjunction
with encryption) foil many attackers.
Authentication (user). It’s a very-different model to the one currently used by the app, but requiring users to “sign up” to the service would reduce the risks and
provide better mechanisms for tracking/blocking misusers, though the relative anonymity of the Internet doesn’t give this much strength and introduces various additional burdens both
technical and legal upon the developer.
Fundamentally, of course, there’s nothing that an app developer can do to perfectly protect the data that is published to that app, because the app runs on a device that the user
controls! That’s why the first lesson is the most important: if it shouldn’t be on the public Internet (yet), don’t put it on the public Internet.
Hopefully there’s a lesson for you somewhere too: about how to think about app security so that you don’t make a similar mistake, or about some of the ways in which you might test the
security of an application (for example, as part of an internal audit), or, if nothing else, that you should go and read Forward, because it’s
pretty cool.
