Having difficulty getting closer than 18m away (according to my devices): looks like it’s in someone’s garden! Gonna assume that the coordinates are off (or the satellites hate me
today) and just start searching in a wide area…
Nope, no luck this morning. Thought I’d be in with a chance of an FTF for sure, but I can’t find the cache.
Both my GPSr and my phone seem to think that the posted coordinates are about 18m directly onto what’s clearly private property (and Google Maps agrees too, not that it’s always as
accurate as a real life observation at GZ). Either the GPS gods aren’t smiling on me this morning, or the posted coordinates are off. :-(
McDonalds had to know what they were doing. The New Zealand branch of the franchise launched its “Create Your Taste” campaign with a special promotion: Design your own burger
and get free fries and a soft drink for your trouble. Not a bad idea in theory, but then there’s the part where they let everyone share their hideous creations. There
was no way that someone somewhere at the company didn’t speak up at one point and say “Hey uh, you know that the internet is just going to create the most offensive and terrible
burgers possible, right?”
If you’re a tourist on one of “Jump Man” of Footprints Tours’ tours, I’m sure that the obligatory “jump for a photograph” moment at the end is a fun novelty. However, the novelty
quickly wears off when you work in one of the library offices right next to their usual spot, and the call of “3… 2… 1… JUMP!” is the loudest thing you hear all day, each day,
throughout the summer season.
At a little over 590 thousand words and spanning 1,349 pages, Vikram Seth’s A Suitable Boy is almost-certainly among
the top ten longest single-volume English-language novels. It’s pretty fucking huge.
I’ll stick with the Kindle edition: I fear that merely holding the paperback would be exhausting.
I only discovered A Suitable Boy this week (and haven’t read it – although there are some good reviews that give me an inclination to) when, on a whim, I decided to try to get
a scale of how much I’d ever written on this blog and then decided I needed something tangible to use as a comparison. Because – give or take – that’s how much I’ve written here, too:
At 593,457 words, this blog wouldn’t fit into that book unless we printed it on the covers as well.
Of course, there’s some caveats that might make you feel that the total count should be lower:
It might include a few pieces of non-content code, here and there. I tried to strip them out for the calculation, but I wasn’t entirely successful.
It included some things which might be considered metadata, like image alt-text (on the other hand, sometimes I like to hide fun messages in my image alt-text, so perhaps they
should be considered content).
On the other hand, there are a few reasons that it perhaps ought to be higher:
Post titles (which sometimes contain part of the content) and pages outside of blog posts are not included in the word count.
I’ve removed all pictures for the purpose of the word count. Tempting though it was to make each worth a thousand words, that’d amount to about another one and a half million words,
which seemed a little excessive.
Another reason for not counting images was that it was harder than you’d think to detect repeat use of images that I’ve used too many times. Like this one.
Of course, my blog doesn’t really have a plot like A Suitable Boy (might compare well to the even wordier Atlas Shrugged, though…): it’s a mixture of mostly
autobiographical wittering interspersed with musings on technology and geekery and board games and magic and VR and stuff. I’m pretty sure that if I knew where my life would be now, 18
years ago (which is approximately when I first started blogging), I’d have, y’know, tried to tie it all together with an overarching theme and some character development or something.
Or perhaps throw in the odd plot twist or surprise: something with some drama to keep the reader occupied, rather than just using the web as a stream-of-conciousness diary of whatever
it is I’m thinking about that week. I could mention, for example, that there’ll be another addition to our house later this year. You heard it here first (unless you already heard it
from somewhere else first, in which case you heard it there first.)
Brought up in a world of tiny, bright, UHD colour touchscreens, Annabel seemed slightly underwhelmed by the magic of a sonograph picture of her future baby brother.
Still: by the end of this post I’ll have hit a nice, easy-to-remember 594,000 words.
A cross-site scripting vulnerability (shortened to XSS, because
CSS already means other things) occurs when a website can be tricked into showing a visitor unsafe content that came from another site
visitor. Typically when we talk about an XSS attack, we’re talking about tricking a website into sending Javascript code to the user: that Javascript code can then be used to steal
cookies and credentials, vandalise content, and more.
Good web developers know to sanitise input – making anything given to their pages by a user safe before ever displaying it on a page – but even the best can forget quite how many things
really are “user input”.
This page outputs a variety of your inputs right back at you.
Recently, I reported a vulnerability in a the University of Oxford’s IT Services‘ web pages that’s a great example of this. The page (which
isn’t accessible from the public Internet, and now fixed) is designed to help network users diagnose problems. When you connect to it, it tells you a lot of information about your
connection: what browser you’re using, your reverse DNS lookup and IP address, etc.. The developer clearly understood that XSS was a risk, because if you pass a query string to the
page, it’s escaped before it’s returned back to you. But unfortunately, the developer didn’t consider the fact that virtually anything given to you by the browser can’t be
trusted.
To demonstrate this vulnerability, I had the option of writing Perl or Javascript. For some reason, I chose Perl.
In this case, I noticed that the page would output any cookies that you had from the .ox.ac.uk domain, without escaping them. .ox.ac.uk cookies can be manipulated by anybody
who has access to write pages on the domain, which – thanks to the users.ox.ac.uk webspace – means any staff or students at the University (or, in
an escalation attack, anybody’s who’s already compromised the account of any staff member or student). The attacker can then set up a web page that sets up such a “poisoned” cookie and
then redirects the user to the affected page and from there, do whatever they want. In my case, I experimented with showing a fake single sign-on login page, almost indistinguishable
from the real thing (it even has a legitimate-looking .ox.ac.uk domain name served over a HTTPS connection, padlock and all). At this stage, a real attacker could use a spear phishing scam to trick users into clicking a link to their page and start stealing credentials.
The padlock, the HTTPS url, and the convincing form make this page look legitimate. But it’s actually spoofed.
I’m sure that I didn’t need to explain why XSS vulnerabilities are dangerous. But I wanted to remind you all that truly anything that comes from the user’s web browser, even if
you think that you probably put it there yourself, can’t be trusted. When you’re defending against XSS attacks, your aim isn’t just to sanitise obvious user input like GET and POST
parameters but also anything that comes from a browser header including cookies and referer headers, especially if your domain name carries websites managed by many different people. In
an ideal world, Content Security Policy would mitigate all these kinds of attacks: but in our real world – sanitise
those inputs!
Sometimes I feel developers think that performance is a dark art. It is not. In my experience, well performing systems come down to this: fewer and faster. If you are
doing something a lot, do it fewer times. If you are doing something that is slow, make it faster. It really is that simple. The more things you make your system do and the slower
those things are, the worse your performance will be…
A nice easy find while on my way to a meeting at the Naval College. Not too many muggles about at this time on a weekday morning, so only had to wait a few minutes for a window of
opportunity to stealthily get to the cache. TFTC.
Here is an example scenario… You receive an email requesting a payment. It could be for rent, it could be fees for a course or any other legitimate reason. Typically, the payment is a
significant sum. The email contains the banking details you need to make the payment. Then shortly after the 1st email arrives…