Dubsar has few issues related to user privacy, but it takes those seriously.
Users have no identity to Dubsar beyond an IP address. Nothing considered to be personally identifiable information is ever collected. Dubsar never requests an e-mail address. Users do not log in. The content of the application is entirely public and read-only and mostly static.
While no personally identifiable information is collected by Dubsar, IP addresses can still be correlated with identities, and the search history of otherwise anonymous users of Dubsar is available to the server in different ways at different times. The Dubsar Dictionary Project prefers to err on the side of caution and treat this as sensitive data, though it is generally not considered personally identifiable. This is, at any rate, the worst vulnerability Dubsar users have when it comes to privacy.
This is potentially the most secure, private Dubsar implementation if used in offline mode.
In offline mode, the application on an iPhone, iPod touch or iPad only communicates with the server to request the FAQ web page, to update the database or to synchronize the word of the day if it has expired. The application maintains a local copy of the database downloaded from the server. When a user views Dubsar content in the iOS application in offline mode, all searching and data retrieval are local, using a read-only SQLite database file. User queries and browsing history are not recorded or transmitted anywhere. The release build of the application logs nothing to the device console during normal operation. Without a hidden keystroke or screen capture program, it would be extraordinarily difficult to discover the search and browsing history of a user of the Dubsar iOS application.
In online mode, the app communicates with the server normally, like a browser, obtaining its data from a RESTful API. All requests to the server use TLSv1.2 with forward secrecy.
Version 2.0 of the iOS app introduces bookmarks, which constitute an equally significant privacy concern. The bookmark feature does not involve data queries, so it is unaffected by the offline setting. Bookmarks are stored and backed up in the user defaults. Bookmarks are not protected by encryption, out of concern over export laws. That feature could be added later. For now, be aware that your bookmarks are not secure. You can protect your backups by backing up locally and encrypting your backups. See http://support.apple.com/kb/HT4946
All users of Dubsar other than those using the iOS application get their information from the Dubsar server. All requests are served by an Nginx web server.
Dubsar redirects all HTTP traffic to the same HTTPS URL (e.g., http://dubsar.info is redirected to https://dubsar.info ). HTTPS is a secure, private transport that encrypts all communications between the client and server using SSL or TLS. There are many ins and outs to SSL and TLS. Qualys has a tool for evaluating the security of any HTTPS site; it gives Dubsar a high score.
Note that Dubsar supports forward secrecy, which makes it resistant to mass surveillance when used with modern browsers. This also applies to the Android client on Android 3.0 and later with version 1.1.0 or later of the Dubsar for Android app.
It's not possible to operate a server without logs. In order to troubleshoot many problems, it is necessary to have a record of traffic to the server. This means each request that the server receives is stored in a disk file with the IP address of origin and the URL requested, which is precisely the request and browsing history of each user by IP adddress. These log files, however, are protected by system security. The data stored in them is retained for a limited time for purposes of troubleshooting and then completely discarded. All reasonable steps are taken to protect the server logs.
Starting with the 1.1.0 release of Dubsar for Android in 2013, the app uses HTTPS for all communications with the server. It also logs almost nothing about a user's activity to the Android logcat.
Tor and anonymity
The only real privacy issue at stake is the search history for each IP address that connects to Dubsar. Any user who is very concerned about protecting that information is welcome to use the Tor network to connect to Dubsar. The Dubsar server will not refuse connections or service by IP address. Getting a response through Tor takes a little longer, but it makes the request quite anonymous and private.
The 1.1.0 release of the Android application also supports an HTTP proxy setting, making it easy to use with the Guardian Project's Orbot application. Even without rooting a device, you can install Orbot from Google Play and connect Dubsar to it by setting the application's HTTP proxy to localhost:8118. This is also a good idea even if Orbot is configured for transparent proxying of data, since it prevents accidentally connecting to Dubsar and revealing your true IP address if Orbot is not running.
Note that when you first install the application, the first time you launch it, it is not possible to avoid requesting the current word of the day before you have an opportunity to set the HTTP proxy for the application. If this is a grave concern for you, take the network down on the device before the first time you launch Dubsar, or make sure you're running Orbot with transparent proxying enabled.
Also note that the HTTP proxy setting only applies to requests made by the application, which includes all user dictionary requests, any traffic related to the word of the day and the FAQ web page from the server. It does not apply to the buttons on the About activity that take the user to Google Play, the Amazon App Store or the Dubsar website. If you are careful to use the Orweb browser or have transparent proxying enabled, those browser requests can also be routed through Tor.
The Dubsar Dictionary Project has been entirely open source from its initial launch in 2010. All the source code for the Rails, iOS and Android apps is publicly available on GitHub:
The less technical user may still require a strong degree of trust. Those with proper knowledge and tools may see how the apps accomplish their tasks, run and test the code themselves to verify its behavior. It is, for example, possible using Xcode 6 to build and deploy Dubsar for iOS on a device from the repository above. Everything except push notifications will work normally. Ultimately, the fact that the source code is public provides more solid grounds for any user to trust the application.