I've been at the OpenStreetMap hack weekend. [Photo]. One of the things I wanted to explore was getting offline maps working on my Firefox OS phone.

Firefox OS is not like iPhone or Android - every app has to be written in pure HTML and JavaScript, which means that for full-featured phone apps / web apps we need to use the fancy extra tools that Mozilla and others are providing to beef up things beyond the usual web features. One of these is IndexedDB which allows a HTML page to store objects longish-term. So let's use that for cacheing map tiles:

• A simple demo with four tiles in a HTML page
• A Leaflet slippy map, tweaked to use IndexedDB cacheing
• Get the code on Github

The demos are just online maps, so they key thing is testing them with internet access on, and then trying again with internet access off.

I had to make a small tweak to the Leaflet slippy-map code in order to patch it to grab map tiles from my cache-or-live service. I don't know if there's a more "sustainable" way to do this...

Is this any different from standard browser cacheing? Well yes and no. It lets us have tighter control over what we, as "an app", do or do not remember. We get to say that we want to remember map tiles but we don't necessarily need to remember logo images, for example.

The UK Government's Department of Business Innovation and Skills recently published a review of Open Access research publication. It made a number of really good recommendations, including de-emphasising the "gold" (pay-to-publish) route, and stepping back from the over-extended embargo periods that the publishers seem to have got RCUK to agree to.

The Government has published its response to this review. What is their response? basically, "Nah, no thanks."

• The review said "RCUK should build on its original world leading policy by reinstating and strengthening the immediate deposit mandate in its original policy". The Government said "... timely OA ... through mutually acceptable embargo period". There's nothing "mutual" about the choice of embargo period, given that many academics have been asking for the position that the government has just explicitly rejected.
• The review said "We recommend that the Government and RCUK revise their policies to place an upper limit of 6 month embargoes on STEM subject research and up to 12 month embargoes for HASS subject research, in line with RCUK’s original policy published in July 2012". The Government said "A re-engineering of the research publications market entails a journey not an event" or in other words "No". Note the vacuousness of their statement. It could easily have been "an event", and the committee wasn't even recommending the total removal of embargoes.
• The review said "We recommend that the Government and RCUK reconsider their preference for Gold open access during the five year transition period, and give due regard to the evidence of the vital role that Green open access and repositories have to play as the UK moves towards full open access." The government said "Government and RCUK policy with an expressed preference for Gold OA [sets the direction of travel]". This is fair enough as a sentiment, but unfortunately the government response also included the publisher's favourite "open access flowchart" which clearly tells researchers that gold open access must be chosen if available. Note that this is not a consensus or objective reading of current RCUK rules, let alone the future. The government is showing no signs of backing away from this weird new competitive problem they're creating right now, where researchers in universities have to compete with their own colleagues (studying completely different disciplines) for the tiny and certainly insufficient institutional pay-to-publish funding pots.
• The review in fact agrees with the position I just stated: "RCUK’s current guidance provides that the choice of Green or Gold open access lies with the author and the author’s institution, even if the Gold option is available from the publisher. This is incompatible with the Publishers Association decision tree, and RCUK should therefore withdraw its endorsement of the decision tree as soon as possible, to avoid further confusion within the academic and publishing communities." The government says "As discussed above the UK OA Decision Tree sets out clearly the direction of travel." Arrrrrrrrrrrrrrrgh, are you not even listening?

I could go on. Suffice to say that I was so encouraged by the sane voice of the BIS review; yet the government's response appears to be a solid and completely shameless "not for turning".

This weekend I was at the Symposium on Acoustic Ecology. Interesting event, but here I just want to note one specific thing from Barry Truax, who gave a keynote as well as a new composition.

Truax has a pretty nice way of talking about acoustic structure at different scales. As a composer he's been an important proponent of granular synthesis, and as a teacher his way of talking about sound meshes rather neatly with the granular approach.

One issue he brought out in his keynote is how, over the past 100 years, our ways of listening have changed, and our sophistication as listeners. He's not just talking about professional or arty listeners, but all of us. In the past, our "acoustic environment" was pretty much synonymous with our immediate environment more generally. This (Truax argues) is one of the reasons that people in the 1910s seemed to be fooled by the sound of an opera singer on a phonograph record, a sound which to us comes across as a feeble imitation. But recording technologies have allowed us to abstract the acoustic environment from our immediate environment: we now have a felicity with embedded acoustic environments that is so sophisticated as to be casual. We know how to relate to the person sitting next to us on the tube listening to headphones; we understand the voices in the radio, why they have different reverb from the room we're sitting in, and why they can't hear us; we understand what is being hinted at when the narrator in a radio play doesn't seem to be in the same room as the characters.

Later that night, at the concert, there was a great example of embedded acoustic environments. We were listening to a multi-channel electronic concert, in a huge ex-ship-building shed ("No. 3 slip") in a dockyard. This hangar allowed plenty of sound in from outdoors, and so as the music played, it was... ahem... "augmented" by various other sounds: the dockyard's big clock chiming the hours; the firework-like sounds of artillery fire in a naval training ground; and also a heavily-echoed "Call Me" by Blondie!

I don't believe any of this was deliberate ;) but it's a great example of an embedded acoustic environment - and furthermore, the challenge that it presents to electronic composers. Composers need to be aware that the environment they're constructing will be usually played back over some speakers which don't form the entirety of the acoustic environment, but a sub-system of it, for the listeners. (Is this challenge equivalent to a demand to always be site-specific? Not quite, but related.) Some of the composers last night I think did not rise to this challenge, and it showed. But some of them did. Barry Truax was premiering a new piece called "Earth and Steel", written specifically for this place, and it worked great, it was very affecting.

The "Faculti" website did a video interview with me about automatic birdsong tracking. A little tongue-tied occasionally but here it is (5:36):

The research papers related to this are:

• Segregating Event Streams and Noise with a Markov Renewal Process Model in the Journal of Machine Learning Research
• Improved multiple birdsong tracking with distribution derivative method and Markov renewal process clustering presented at the International Conference on Acoustics, Speech, and Signal Processing.

Leftover haggis is great for salads. This time I put it with apple - a bit less jazzy than my haggis and orange salad but still a great easy lunch. Serves 1 to 2:

• 1/4 of a cooked haggis (cold)
• 1 apple
• Handful of pasta
• Handful of rocket
• 1-2 tsp white wine vinegar
• 2 tsp olive oil

Cook the pasta, then drain it, refresh it in cold water, and leave it to one side for a bit to cool down.

Peel the apple and slice it into matchsticks.

In a bowl, break up the haggis with a spoon or a fork. Mix the apple into it. Then add everything else and mix it together.

On OpenStreetMap, I find the /browse/ pages really useful for getting a quick summary of an "object" in the map. It shows when it was edited, shows all the tags, etc.

However, I have two issues with it:

• The use of space isn't ideal. There's plenty of unused space which I don't think is entirely deliberate (of course whitespace is good sometimes) - and the interesting information often gets pushed down below the fold as a result.
• The browse pages have enough information that they should be generally useful, not just as a diagnostic tool for mappers, but maybe for people who want to share the details of the pub they're going to, or whatever. The main impediment to this is that the initial impact of the page is fairly unfriendly and technical.

I believe the layout can be rearranged in a way which doesn't remove any of the information that mappers need, but which makes the browse pages more accessible and friendly and hopefully generally useful. This would encourage more casual users to see the tags we have, and... fix them :)

So the main objectives are:

• Make the main heading a bit more approachable, making the "name" (where available) a bit more primary than it currently is.
• Make the "Tags" section a little bit more visually primary (more approachable to newcomers than changeset).
• Make the "last edited" info more compact - it doesn't need to be a four-row tabulation, but can be as a sentence "Last edited [date] by [user] (version [v] in changeset [c])". It makes sense to put the "View history" link at the end of this too. Also, it's more approachable to have the last-edited-date converted to something like "2 months ago", and for full info it'd be good to have the full date tooltippy.
• Try not to do anything that prevents experienced mappers from getting a visual overview of the more technical info, such as history, XML link, edit links etc.

Work so far is in my github branch called "browsepage". Here are some screenshots, in each case with "before" on the left and my version on the right:

A relation:

A way:

A node:

I really think the "Last edited N decades ago by Thor" is much more approachable than the current table of metadata. The other stuff I've done is less dramatic, but I like the way it gives a bit more priority to the tags and makes room for plenty of them in a screenful.

Update: someone asked if I could post how the pages look on small screens (i.e. phones) - here are screenshots, taken by resizing my Firefox window small enough that the small stylesheet kicks in:

Post-Snowden, we all need to understand privacy and cryptography a little bit better than we did before. If you use something like Dropbox to synchronise files between computers, or to collaborate with people, you may wonder about the security of it. Well, you should wonder about the security of it: the way Dropbox works is that it sends your files up into "the cloud" which is really a big filestore run by Amazon. That's handy because if you trash your computer, your files can be recovered from Amazon's servers. But it's not so handy in that all your files are stored on some third-party server, maybe in the EU, maybe in the USA. In general we shouldn't have to trust such third parties, so it'd be better if the data were encrypted so that Dropbox/Amazon couldn't inspect it. (Note: technically the data is "encrypted" on their server but not in a way that prevents them from looking at it.) Even worse, we know (post-Snowden) that it's highly likely the US security services have some kind of "relationship" with Dropbox/Amazon through which they can scan for interesting content etc, under rather looser terms than maybe we thought. So Dropbox provides a personal service but not a private one.

Luckily (?) the makers of Bittorrent have come along with an alternative called BitTorrent Sync, which does the same kind of job but in a peer-to-peer fashion.

The way it works is described in the btsync tech summary and it's rather neat. Transferring files between computers is basically done Bittorrent-style, but it transmits the data directly between your computers over an encrypted connection.

(When I say "directly"... it's still transmitted indirectly in the sense that internet traffic passes through many machines - but I mean that your data is not addressed first to some third-party machine [neither peer nor server] before it gets re-addressed and hops onward to your machine.)

If you have two computers, attached to the internet, you sync files between them by telling them the secret random code that it generates for you. You don't need any central server (in principle), because btsync is able to use a DHT which lets it ask the p2p network, "which IP addresses correspond to machines which know my secret code?"

I think this architecture is really rather nice. There are a handful of extra tweaks you need to be aware of - for example, it does in fact use centralised servers (not just DHT) to help bootstrap awareness of peers, and also to help get round firewalls - but the basic idea is neat, and cuts out the middleman compared against Dropbox. In principle, this appears much better privacy-wise.

There is a major security/privacy issue, but before that here's a minor one. The DHT stores data in the form of "SHA1(Secret):ip:port", which means that although your secret isn't directly stored, if some naughty person was spying on you and detected that your computer had sent out a message saying "who knows about SHA1(Secret)?", then the naughty person could ask the same question and discover the IP addresses of the nodes in your little sharing network. So, that doesn't give away your secret or your data, but it does give away some of your web of connectivity. For example, maybe it lets someone confidently associate your work computer and your home computer. These narrower kinds of information leak are hard to stop, but I believe there are tools that can even avoid them (RetroShare privately hops data from friend-to-friend so that an outside observer could probably work out who your friends are, but not which bit of data is destined for which destination).

The major issue is that Bittorrent sync is not open-source. Many, many security experts can tell you that open-source software is much easier to rely on for security, because the actual software code is out in the open (and ideally, the development process too) and can be inspected for any issues. In the past this was just a vague idea, but now post-Snowden we know that government agencies do force software vendors to compromise the security of their software, and then to deny it to us. So it's very difficult to trust a company (especially, right now, a US-based company) when they say their software is private and secure.

(Of course just because something is open-source doesn't guarantee it is secure. The NSA has been documented tweaking public open-source code, influencing on-the-record standards meetings, etc.)

But if it's closed source, it's like buying a boat and not being able to check all round it to see if it's seaworthy. "Is the hull watertight?" "Well, I've checked the left side, and there are no holes in that side." "Let's go!"

So, it's no wonder that the Free Software Foundation considers it a high priority to make a free-software equivalent to btsync. The design is neat, and in principle it's privacy-preserving. In practice... who knows?

Disclaimer: I'm a citizen not a cryptographer. Post-Snowden we all need to understand privacy and cryptography a little bit better than we did before. You should probably read something by Bruce Schneier or Jacob Appelbaum.

The big annual meetup of OpenStreetMap folks was last week and it was full of interesting talks. The diversity of people seemed pretty good relative to a lot of the meetups I end up at (open-source software, experimental music, computer science, you know, that kind of thing), but still, the OSM community needs to work towards being more representative of people in general.

In her keynote on diversity, Alyssa Wright gave a telling example, of how a proposal for a "childcare" tag had been voted down, primarily because the people who voted felt unconvinced that it wasn't already covered by the "kindergarten" tag. Alyssa contrasted this with the slightly bizarre plurality of tags for things that traditionally have male associations (e.g. pub, bar, nightclub, stripclub, brothel, each of which have separate amenity tags).

Now, this is a fairly anecdotal contrast, and Alyssa said so herself. (In other slides she showed some statistics which make the point more numerically.) But it illustrates some of the ways in which diversity issues come into play in open wiki-like projects. Maybe the existence of both "pub" and "bar" tags is a weird historical glitch which no-one particularly agrees with (I certainly don't see the point!). That doesn't detract from the fact that there's always going to be some sort of bias built in to OSM's norms, and people who absorb themselves into OSM will absorb and reproduce the norms, and this can be a self-reinforcing problem unless we pay attention to fixing it.

In this post I'm not going to summarise everything that everyone said about diversity. I'm just going to list some of the take-home messages that I got from this strand of talks:

• "Diversity" relates to many things of course - gender, age, nationality, etc etc etc. Alyssa acknowledged this but said that fixing gender diversity in a community is the fastest and clearest route to fixing diversity in general in a community. This has a definite ring of truth to me. It'd help to focus efforts.

• Yuwei Lin recommended that project-based mapping was a good idea - from her research it would be a mode of engagement that would work well for women. She suggested examples: the humanitarian OSM team projects, as well as mapping parties to do specific purposeful things such as zoo mapping, mapping of National Trust sites, etc - all sounds good to me.

• "Measure excellence by teaching" (said Alyssa). This sounds like good advice, especially in the context of a kind-of-techy community like this one, where discussions about GIS systems or web servers can lead to a tendency to measure excellence by fairly techy measures. Teaching is flipping critical to a project like OpenStreetMap, whose success or failure must lie in how well its dedicated "in-group" helps people from outside to engage.

• "Bikeshedding is normal" said Frederick Ramm, summarising one tendency in OpenStreetMap's mailing lists. I know bikeshedding is pretty much an inevitable fact of organised discussion, but I do fear that it can put off potential (or existing) community members, and I wonder how to arrange things so that unnecessary bikeshedding is truncated...

• "Stop talking, start mediating" said Alyssa, in her closing recommendations. Sounds like general good advice. (Relates to bikeshedding? Maybe, dunno.)

• Yuwei recommended diversity-friendly social events. For example the OSM London meetings are always brief mapping parties followed by pub drinking in the mid-to-late evening. Nothing wrong with it in itself, but it could easily be offputting for people who don't drink (e.g. for religious reasons), or have childcare commitments, etc - probably wise to vary the events a bit? A Saturday afternoon in a tea-room would be nice (I know a good one or two).

• I did notice in one talk, there was a little bit of a tendency to equate female mappers with newbie mappers. Let's not make that mistake! I don't think anyone was stuck on that point, just thought I'd mention it since I noticed it.

• Frederick talked about the different OSM mailing lists, and he mentioned all the different country-specific mailing lists, each of which uses their national language. He gave an interesting example in which three different communities each came upon a particular topic, but independently and at different times. This made me wonder if this setup, with a "cluster" of semi-independent communities rather than one big community lumped together on a single universal mailing list, was in fact a good way to promote diversity and reduce the impact of self-reinforcing social loops. I wonder, should we de-emphasise the idea of a "main" mailing list or IRC or whatever? A half-formed thought to finish the list with.

I didn't actually end up chatting to most of the people I've mentioned just above, so I haven't really talked any of this stuff through with them. Lucky that there are good people on the case already, so it seems. OpenStreetMap has a diversity-talk mailing list if you'd like to get involved.