Infodisiac

Usually this blog is about Wikimedia statistics. Today I need to digress. My favorite cross-platform archival system is the hugely popular Evernote. I use Evernote for all kinds of data and images, and love the product. So much that I stored all kinds of (mildly) personal data. No longer.

As a paying subscriber I get a few goodies, like setting a pin code. In fact apart from the higher upload limit there are just a few of these goodies so this pin code thing is prominently featured on their sign up page, especially on iPad.

In July I stumbled over a security flaw, and reported it first to the help desk (after all as a paid subscriber I get ‘top priority support’). They confirmed the bug quickly and said they reported it to the engineers. A lively debate on their support site followed, with an Evernote employee participating. 3.5 months, several small updates and one major new release later the bug still stands.

So what is it about? On iOS devices one can circumvent the pin code simple and fast. All that is needed is to remove the app and download it again. Takes less than a minute. Since iOS6 no Apple password is needed for updates. Remember Everything Evernote helpfully suggests to reuse existing account but forgets there was a pin code set. Oops!

Evernote employee responds as follows (paraphrasing, see exact response here): it’s Apple’s fault: they changed their system, and the iOS device has its own pin code which one needs to bypass first, also Evernote supports encryption, that makes this less of an issue.

Evernote, if you rely on the general iOS login code why did you offer an extra pincode in the first place, and brag about it? Maybe some users prefer a short device login code to keep their daily news and amusement within easy reach, but treat Evernote as their trusted vault and use a more solid pin code there. Also encryption support is minimal, only for plain text, not for scans, pdf’s etc.

As much as I love your product, shouldn’t you care for your client’s security before adding new goodies? How difficult can it be to either disable import of stored account data, or remember the pin code as well?!

Wikistats editor counts are too low for some languages, for all reported months. The issue has made it into the German Wikipedia’s “Kurier” newsletter (18.1) , and is discussed at this page.

First, there has not been a definition change or re-evaluation of editor counts. Current counts are wrong. Let me explain why all months display lower counts: on every monthly run of wikistats nearly all data are regenerated from the dumps. This is on purpose. This way new functionality and (rare) bug fixes apply to all months since the creation of the wiki. The other side is that when stats scripts or dumps are broken reports will show wrong data for all months, which is what happened now (a hybrid situation with data retention and update runs would complicate processing further and easily be a source of errors itself). I put up a notice on the stats pages.

I am investigating. So far test runs have been inconclusive. My first priority is to find out whether this is caused by a change in the dumps, or the scripts, or a config change on the server. The latter is most likely. In the past month Wikistats data and script were moved to a new server, with a number of modifications to overall configuration and shell scripts.

I will keep you posted on any new findings. My apologies for the inconvenience and confusion caused by this mishap.

Update June 17

The problem has been analyzed and fixed. A few weeks ago, during substantial overhaul on stats scripts (to add new metrics) an error had creeped in, which was not recognized during tests: as a result far too many articles were flagged as redirects, resulting in far too low counts for articles and editors: redirect pages are not counted as articles, and for consistency, not taken into accounts for edits and editors (*).

Now it still will take about 7-10 days to reprocess all dumps. Slightly delayed further by scheduled maintenance on the stats server, which is still ongoing.

Thanks so much for your patience.

*: This is of itself a point that could be debated, but this is how it works or is supposed to work. For one it prevents skewing of edits per article metric.

Update June 26

All 800+ wikis have been updated now.

The following breakdowns of non-mobile and mobile traffic are based on our squid logs.

Note how share of mobile usage peaks every year around Christmas.
Note how mobile here is to be taken as ‘traffic from mobile devices’ not as ‘traffic to our mobile site’.

See also the Wikipedia article on usage share by browser.