Linguists will know John Benjamins as one of the nicer academic publishing houses, not quite so terrible as Elsevier or other profiteering behemoths, and one with really good typography to boot. Iconicity afficionados will probably know the Iconicity in Language and Literature series published by Benjamins. One of my first articles on ideophones and iconicity appeared in this series and though since then much of my work has appeared in journals, I’ve just written a contribution for another volume in the series (this one edited by Kimi Akita and Prashant Pardeshi). I’ll share that paper on another occasion; here I just want to share a CSL style I created to make my life easier. If you’re just after the style, download it here (and see instructions for use here). If you want some background, feel free to keep reading.
One of the key tasks scientists need to master is how to manage bibliographic information: collecting relevant literature, building a digital library, and handling citations and bibliographies during writing.
This tutorial (last updated March 2018) introduces Zotero (www.zotero.org), an easy to use reference management tool made by scholars for scholars. The tutorial covers the basics of using Zotero for collecting, organizing, citing and sharing research. Zotero automates the tasks of managing bibliographic data, storing and renaming PDFs, and formatting references. It also integrates with widely used text processors, and can synchronize your library across devices. There is no more need to search through disorganized file folders full of inscrutably named PDF files, to copy and paste references across documents, or to manually deal with pointless differences in citation styles. Ultimately, the point of using a reference manager is to free more time for real research.
Note: these are slides made for a hands-on workshop. They may not work well outside the context of a live Zotero demonstration. I share them because they may still contain some useful information.
A while back some low quality citations started showing up on Google Scholar. They had titles like “CHAPTER 2 draft — email firstname.lastname@example.org” and it was hard find actual bibliographic metadata. Google Scholar seemed to have scraped random PDFs uploaded on Academia.edu and decided it was worth counting the citations in them even in the absence of proper metadata. I shared this on Twitter and promptly forgot about it.
Then I got an email from someone asking me to say a bit more about my concerns with poor metadata. I decided to write it up in a blog post. I’m afraid it turned into a a bit of rant about how Academia.edu seems built not so much for sharing scientific information as for playing to our vanity. Sorry about that. Let’s start with the poor metadata issue, which turns out to be rather pervasive. Continue reading
Today, Nature published a news feature by Cat Ferguson, Adam Marcus and Ivan Oransky (Retraction Watch) in which I am quoted about some problems with Editorial Manager (EM). This post provides the background to what I say there. Disclaimer: I am not a security expert, though the basic problems should be obvious to anyone caring about security and privacy on the web.
Editorial Manager (EM), the submission and reviewing software used by thousands of academic journals, routinely throws around passwords in plaintext. If you publish with any of the journals using EM, you’ll get emails with your password in plain text, even if you didn’t ask for it. Some configurations of EM even display the password in plain view on the user account page. This means that Editorial Manager does not safely encrypt passwords, which presents a massive security risk. Aries Systems, the firm behind Editorial Manager, defends itself by saying that (1) journal editors want these options and (2) they don’t collect financial information anyway. Those replies skirt the real issue: Editorial Manager, trusted by millions of academic authors and reviewers, fails to implement some of the most basic rules for the secure and responsible handling of passwords and user accounts.
Every academic will run into Editorial Manager and its kin sooner or later. This is a piece of web-based software that helps the editors of academic journals to manage the submission and review procedure. Literally thousands of journals across all disciplines use it, from well-known interdisciplinary ones like PLOS ONE to niche journals like Policy and Society and Frontiers in Neuroendocrinology. Elsevier has its own branded version (EES) of what is essentially the same software.
EM requires authors, reviewers and editors to register an account. With such an account, users can submit and review manuscripts. The registration procedure asks for the usual username / email / password combination — nothing very special so far. Until you start using the system a bit more and you discover that it handles your password in, shall we say, a very casual way.
Take PLOS ONE (though note that any other journal using EM is vulnerable in the same ways). Say you submit a paper, or get a request to review one. You’ll get an email notification — with your password. You didn’t ask for this. In fact, even if you did, it shouldn’t be able to give it to you; at most it should offer you to set or reset it. Many of us haven’t seen plaintext password since the early 2000s; in the last decade, better and safer methods have been introduced everywhere, except at Editorial Manager.1
Packet sniffing and password reuse
I shouldn’t really have to explain why this is seriously problematic in multiple ways. Indeed why this is so is written all over the internet (1 2 3 4 5). The fact that some system sends you your password by email means that your password could be intercepted by any old packet sniffer on a network that you’re using (think free wifi). It also means, obviously, that your password can be retrieved by anyone who manages to get access to your email — either by looking over your shoulder, by rummaging in your inbox while you’re away from your computer, or by more sophisticated means.
Worse, the fact that the system can send out passwords means that passwords are stored in plaintext form, or using easily reversible encryption (which, experts say, comes down to the same). As plaintextoffenders puts it, the password is there on the server, waiting for someone to come and take it. And not only your password is there. It’s the passwords of the millions of users of the thousands of academic journals using this centrally hosted service. That, coupled with the knowledge that about 60% of users reuse passwords across different web services, means a security risk of massive proportions. Check out this XKCD comic for the basics on password reuse.
So EM freely shares passwords in emails. It also displays passwords on profile pages, offering further proof of the lack of encryption (or the use of reversible encryption). Thousands of academic journals crucially depend on this same system, making their hundreds of thousands of peer reviewers and authors sign up for it. You would think that with “periodic third party security and infrastructure audits” (according to Aries’ hosting checklist), Aries Systems would at least have ensured that the most basic lessons in user account security are taken care of. Apparently not.
Aries Systems: ‘It’s optional, so don’t worry’
While preparing a report on this matter in May 2013, I communicated my findings to the Editorial Manager team, because I thought it would be reasonable to give them the chance to respond to the issue. After a first email went unanswered, a reminder email led to an email exchange with Jennifer Fleet, Director of Client Services at Aries Systems, the company behind EM. Here are the most crucial excerpts from what she wrote to me (she gracefully gave me permission to cite this):
Our software (Editorial Manager) has a variety of configuration options that are made available to our publishing customers. The inclusion of credentials in emails is an optional configuration choice. The configuration option to include log-in credentials in emails is desired by some publishers because of the high convenience factor it provides to end users who infrequently access the system. However, inclusion of credentials in emails can also be entirely suppressed and many publishers in fact do not include credentials in emails. We have a wide variety of publishing customers and each is empowered by the administrative capabilities in the system to make their own choices concerning this type of policy.
While honest, this reply suggests that Aries Systems doesn’t realise how important it is to handle user information in a responsible way. The defense is basically: our clients want it, so we do it. But clients should never dictate security design. As a common principle in web development states, your responsibility goes beyond your application.
Modern, safe, and user-friendly ways of handling user account security (involving hashed+salted storage of passwords with tokenised ways of resetting (but never retrieving!) them) have been available for at least five years now. People have thought long and hard about this problem. Repeated breaches have shown how dangerous it is to use anything less than secure encryption and robust ways of resetting passwords. It is remarkable to see such a blatant disregard of industry-standard security measures.
Aries Systems continues by saying, “We do encrypt all passwords.” Here is a simple technical fact: any system that offers the possibility to switch on bizarre options like sending out or displaying plaintext passwords has to store its passwords in such a way that they can be easily fetched and decrypted. No matter how creatively you define “encryption”, you can’t get around that as long as you offer this ‘service’ to your customers.2
Aries Systems: ‘We don’t collect financial information’
Aries Systems: “Also, Editorial Manager does not collect or store any financial information.
I would be happy to discuss this with you further by telephone or email, and I hope you will understand the dynamics and trade-offs under consideration.”
The final defense is that Editorial Manager doesn’t store financial information. This sounds like, “You haven’t given us your creditcard, so we’ll just handle your user accounts in an irresponsible way.” This disregards the fundamental principle, mentioned above, that your responsibility goes beyond your application. Additionally, it is of course only apparently a mitigating circumstance. It is widely known that about 60% of users reuse passwords across websites.
If malicious hackers were to get access to an EM server, how many of the emails and passwords would match with accounts on other services that do allow financial transactions? The userbase of EM consists of highly educated people in academia. They have creditcards, Amazon accounts, Paypal wallets, iTunes IDs, et cetera. A significant chunk of them may use the same password for some of those services. Put these things together and suddenly Editorial Manager becomes a very interesting hacking target. (I would not say this out loud here if I had not communicated all this to Aries Systems well over a year ago.)
It’s not just about financial information
The problem is not just about credit cards and such, but about the security of the very process of scholarly publishing. Editorial Manager is easily one of the weakest links in the chain of peer review. What if you could easily get access to someone’s account — pass yourself off as a peer reviewer, say, or get access to an editor’s account to invite your own friends (or yourself) to peer review your own papers?
This is not mere conjecture. It’s happened already, as documented by RetractionWatch: Elsevier’s editorial system (a branded version of EM) was hacked, leading to a peer review scandal and ultimately to a couple of retractions. The details of the case aren’t known, but with a link in the chain that is as weak as EM’s lighthearted handling of password security, I wouldn’t be surprised if some form of password hacking played a role; with the lax security of Editorial Manager, getting access to passwords is child’s play.
Let me end on a positive note. The journal Language recently transitioned to the open source Open Journal Systems, which, as far as I’ve been able to ascertain, handles passwords and account information in a much more secure and modern way. Such is the power of open source. Of course, this doesn’t really help us end users: we are unlikely to choose a publication venue on the basis of the manuscript management software they force us to use. But it does show that there are good models out there. Let’s hope that the dust kicked up by the Nature news story will bring some change for the better. Meanwhile, if you’re forced to use Editorial Manager, use disposable passwords and write to the editor to tell them of the risks of the system.
Max Planck Institute for Psycholinguistics, Nijmegen
- To be clear, this is not about sending the user a password upon first registration. Although even this is frowned upon by security experts, some websites do this while still storing the password in a secure way. Editorial Manager, however, sends users their password in plaintext when they’re already registered, without them asking for it — and it does so routinely, for instance when sending out notifications of submissions awaiting approval. [↩]
- In a follow-up email exchange, Fleet refused to answer my more detailed questions about their security design, “due to the potential exposure to which that may lead”. Even without that information it is already clear that passwords are not being hashed and salted. If they were, the system wouldn’t be able to give me my password. [↩]
One of the most common word-processing related task for academics is to generate PDF versions of documents — for sharing with colleagues, for submission to a journal, for uploading to a publication page, et cetera. In LaTex, creating PDFs is a question of one simple command (plus a bit of fiddling with settings). In recent versions of Word, it is also pretty simple: just Save as… and select PDF. But that option is buried in the ribbon interface and involves quite a number of clicks. I generate PDFs practically everyday, so I wanted something easier. Enter Word macros. Continue reading
Duplicate detection is one of the things any serious reference manager should offer. Zotero users have been clamouring for it since the early days. There are basically two ways to implement it: as a preflight check, warning the user when they are about to add a potential duplicate; and as an after the fact scan, which enables users to weed duplicate items from their library.
The most recent version of Zotero takes the second route: a posthoc duplicate detection mechanism. Though definitely better than nothing, and with an elegant merging solution, the interface is still far from perfect and yields a lot of false positives, making it somewhat difficult to use. Besides, it is slow, because it tries to compare everything with everything, which amounts to a huge amount of operations even in moderately sized libraries. Although it is good to have at least something, what seems to me have been overlooked is that prevention is better than cure, and that a quick check before adding new items to the library would help users a lot. Continue reading
This long overdue instalment of Ideophones around the web features ideophones in the names of snappy new mobile apps from an Indian software startup. Continue reading
Here’s a quick tip for Zotero users who like to do their browsing in Chrome or Safari: you can install “Zotero Connectors” that will make Zotero recognize references in Chrome and Safari just like in Firefox. The Zotero developers are working on a standalone version, but these connectors can already talk to your Zotero library in Firefox. So if you, say, find yourself going to Chrome for its speed and nice interface, you can simply connect it with Zotero and use Firefox to host your local Zotero library until Zotero Standalone comes along. Continue reading
A new version of ELAN, the widely used tool for time-aligned annotation of linguistic data, was released today by the developers, Han Sloetjes and Aarthy Somasundaram. One of its major features is a whole new user interface for high-speed transcription. This interface is the outcome of a process of user consultation and usability testing at the MPI for Psycholinguistics led by Mark Dingemanse, Jeremy Hammond, and Simeon Floyd in close collaboration with the ELAN developers Han Sloetjes and Aarthy Somasundaram. In this post we outline the most important features of Transcription mode. Continue reading