LWN.net Weekly Edition for March 24, 2016

Firefox and cookie micromanagement

For most of its existence, Firefox has provided users with the ability to manage how cookies are stored with a rather high degree of granularity: users can block specific cookies, create site-wide exceptions to the accept/block policy, and configure behavior for third-party cookies. Up until Firefox 44, there was an additional option as well, one that allowed users to choose the expiration point (that is, expiring them at the end of the session or letting them persist) for every cookie they encounter. That option was removed in the Firefox 44 release, which has made some users rather unhappy.

The option in question was found in the Privacy preferences screen, labeled "Ask me every time" on the "Keep until:" selector. When enabled, the option raised a dialog box asking the user to accept or reject each cookie encountered, with a "accept for this session only" choice provided. Removing the option was proposed in 2010, although the patch to perform the removal did not land until 2015. It was released in Firefox 44 in January 2016.

A few days after Firefox 44 was released, users began to complain, starting with comments on the bug report. The primary concern was that of user privacy. A significant number of Firefox users, it seems, prefer to see each new cookie they encounter and make a decision whether to allow or reject it. As commenter Wayne Woods put it, the remaining options (such as the exceptions list) do not offer the convenience of the pop-up dialog:

In response to the complaints, Mozilla's Marco Bonardo replied with a rationale for the change. The functionality was "unmaintained, bogus and not really nice to use on today's Web", he said. Furthermore, attempting to manage cookies for privacy protection through "a dialog that pops up every other second and can easily break website functionality" is not realistic, he said. Firefox's Tracking Protection feature takes better care of the user's privacy, and further fine-grained control over cookie management would be better implemented in a browser add-on.

On February 4, Hugues de Lassus Saint-Geniès raised the issue on the Firefox development mailing list, summarizing the points made in the bug-report comments. He, too, pointed out the loss of control, and noted that the granular cookie-management feature had been a differentiating factor between Firefox and other browsers. In addition, he said, the "ask me every time" option "was instructive as it would show which cookies were set by which domain".

In the ensuing discussion, the issue of end-user control took center stage. While essentially everyone agreed that providing the user with the means to manage cookies was good, the practical question was whether or not the pop-up dialog truly met that goal. Gijs Kruitbosch contended that users are unlikely to guess successfully which cookies they should accept and which to reject:

Coupled with the fact that every user seemed to raise a different use case (e.g., treating cookies from subdomains differently than higher-level domains, or handling "hub" sites that embed content from other sources), the user-interface question makes it difficult to devise a cookie-management interface that works for everyone.

And, despite the removal of the "ask me every time" feature, options do remain, as Mozilla employees pointed out. Mike Hoye pointed readers to the Self Destructing Cookies add-on, which deletes all cookies that do not come from a currently open tab. Francois Marier noted that there is a network.cookie.thirdparty.sessionOnly preference available in about:config that will discard all third-party cookies at the end of each browsing session, while retaining cookies originating from the site.

In past debates about Firefox functionality, referring users to add-ons has been interpreted, at least by some, as a dodge on Mozilla's part. Bonardo took issue with that, saying "add-ons are not an enemy nor an evil thing, we should stop saying things like 'requiring a user to install 20 add-ons is wrong...'. Nothing wrong with that, it's customization."

Chris Peterson agreed, but added that trends in add-on popularity are "an indicator of what Firefox users want and do not get with the default". The Tracking Protection feature, he said, was implemented in response to the privacy concerns of users. Surely allowing users to customize what the Tracking-Protection blacklist blocks would satisfy many users. Panos Astithas replied that user-provided lists are on the Firefox roadmap.

In the end, the discussion quieted down, with most of the participants seeming to agree that, while installing add-ons may be less convenient, there are still ways for interested users to exercise fine-grained control over cookies. Kruitbosch noted, in his message linked-to above, that the issue at hand is not really "cookie management" anyway:

That answer may not please everyone but, for the time being, it appears to have quelled the concern over this one removed Firefox feature.

Comments (20 posted)

Fighting DRM in HTML, again

In 2013, the World Wide Web Consortium (W3C) raised the ire of many in the free-software community (and elsewhere) by adopting an API that adds support for DRM modules within web content. Now, the working group that produced the API in question has come up for renewal, and a number of high-profile parties—including the Electronic Frontier Foundation (EFF) and Free Software Foundation (FSF)—are using the occasion to push back against the DRM camp, in hopes of regaining some of what was lost.

To recap, the W3C accepted the Encrypted Media Extensions (EME) framework as a W3C "Working Draft" specification in 2013. EME added hooks to the HTML <audio> and <video> elements designed to pass control to a Content Decryption Module (CDM) that would then enable or disable playback based on some authentication system chosen by the site owner. Although the specification included a simple, plain-text key system as the only mandatory authentication scheme, the intent was widely recognized: online media vendors like Netflix would implement DRM authentication schemes via proprietary, binary CDMs that users would have to install as some form of browser plugin (albeit with limited functionality).

Strictly speaking, the "Working Draft" status of EME is not the final step in the W3C standards-publication process. But it is part of that process, and critics loudly objected to the W3C taking any part in drafting a specification the purpose of which is to restrict access to content.

Nonaggression

The EME specification is being drafted by the HTML Media Extensions Working Group, and the group's original charter expires on March 31, 2016. When the group came up for official rechartering (a step that will be required to move EME further through the standardization process), the EFF took that event as an opportunity to push back again at EME. In January, it proposed tying the recharter to a DRM "nonaggression covenant."

Akin to the W3C's existing patent policy, the DRM covenant is meant to put a halt to several of the nastier effects of DRM, such as copyright holders' ability under the Digital Millennium Copyright Act (DMCA) to sue anyone who discusses circumvention methods. Since publishing security vulnerabilities can be regarded as "discussing circumvention methods," the EFF notes, this DMCA provision has a strong chilling effect on work that has no illegal purpose. The EFF's proposed covenant describes this problem as "paracopyright", noting that the expansive effect it has in stopping speech and development that is not copyright infringement is a separate issue from whether the W3C should endorse DRM in the first place. Adopting the covenant would be moving to middle ground.

The proposed covenant requires that all participants in the W3C DRM specification process agree not to sue anyone who makes software that complies with the specification or who reports bugs in a specification-compliant implementation. That would free implementers and security researchers from the threat of DMCA lawsuits for otherwise legal work.

Protestations

In the lead-up to the W3C's March 20 meeting in Cambridge, Massachusetts, several other organizations registered their support for the EFF proposal or, more generally, their opposition to EME. The Open Source Initiative (OSI) published a position statement supporting the proposed nonaggression covenant, saying:

The FSF, on the other hand, organized protests objecting fundamentally to the inclusion of DRM itself in web standards; first starting a "selfie campaign" in which supporters sent photos of themselves holding anti-DRM signs or messages, then planning an in-person picket line outside the W3C meeting. The FSF also pointed interested parties to its online petition, started in 2013, and currently signed by 26 organizations and more than 33,000 individuals.

In the end, protesters gathered not just outside the W3C meeting, but at several other W3C offices around the globe. The gatherings were picked up by several tech-news outlets.

W3C responses

The various public positions and protests certainly did not go unnoticed by the W3C. On March 11, it published an "invitation to the free-software community for real dialog" on its blog, inviting members of the free-software community to contact W3C staff directly to discuss concerns about DRM, rather than "just snapping a selfie next to a W3C sign."

The tone of the post might be considered dismissive by some, as it equates participating in protests with "let[ting] someone else make you try to shoehorn yourself into any narrative they want to construct about fearless activists doing battle against some faceless uncaring entity." Nevertheless, the W3C did agree to consider the EFF's nonaggression-covenant proposal during the March meeting.

On March 20, the W3C also published an EME fact sheet page, which it says "clarifies definitions and current activities" and "corrects misconceptions" about EME. The page notes that the W3C welcomes participation from all stakeholders, regardless of interest or industry, and highlights the initial EME proposal's ability to automatically handle the plugin-management tasks that users had previously needed to perform by hand. Ultimately, it said, the web should be "universal" so that it can "contain anything", and EME supports that goal by remaining neutral about DRM and supporting CDMs generically—a far better approach for the health of the web than the alternative: external software like Flash and Silverlight.

Up next

The position put forward in the EME fact sheet is essentially the same one offered by the W3C in 2013; it is not likely to change any minds. To an extent, the pro- and anti-EME sides are arguing past each other (publicly) over the nuances of wording. Paraphrasing for the sake of brevity, the W3C claims that protesters are objecting to "DRM in HTML" but contends that EME is not DRM. Opponents of EME, in turn, would reply that such a description is merely a technicality, since EME is designed to deliver DRM. Unfortunately, as long as the debate remains fixated on such linguistic puzzles, there is not likely to be any significant movement on either side, and the camps may well continue to talk past each other.

Ideally, that impasse is what makes the EFF's nonaggression covenant a potentially useful play: it makes an incremental and beneficial change, rather than attempting to take a direct run at the logjam. At present, the outcome of the W3C meeting's consideration of the DRM nonaggression covenant remains unknown. How that proposal was received is the unanswered question; so far neither the EFF nor any W3C representatives have commented.

EME was a contentious issue even within the ranks of the W3C in 2013, and it continues to be so today as well. W3C employee Harry Halpin moderated a DRM panel discussion at LibrePlanet 2016; afterward he announced that he would resign if the W3C approves EME as a Recommendation, the final status for W3C standards. However this week's discussions turn out, it seems likely that there will be many more battles yet to come.

Comments (19 posted)

Bringing Signal to the desktop

The non-profit Open Whisper Systems (OWS) organization is best known for its smartphone apps: first TextSecure and, more recently, Signal. Lately, however, the project started branching out by developing a desktop front-end for Signal, thus allowing users to take advantage of verifiable, end-to-end encryption for instant messages and group chats from the comfort of a full-size keyboard. The desktop version remains linked to the smartphone edition, although opinions certainly may vary as to whether that constitutes a plus or a minus.

TextSecure was released as open-source software in 2011, followed by an encrypted voice-calling app named RedPhone in 2012. OWS then merged the functionality into a single iOS app called Signal in March 2015; the Android version was released in November of the same year. Signal Desktop was announced in December, via a beta program for which potential users had to sign up and wait to receive an invitation. As with all of OWS's projects, of course, the source code for Signal Desktop is available on GitHub.

The desktop client is implemented as a packaged web app for Google Chrome/Chromium. It is distributed through the Chrome Web Store but, as a "pre-release" app, it does not turn up in search results. One must get the link by joining the beta program.

The beta program has its share of peculiarities; when one signs up, the sign-up page reports how many applicants are ahead in the waitlist. I signed up in December (with many thousands of ahead of me in the queue) and only received the sign-up invitation in March. So patience may be advisable. Then there was the invite itself. The accompanying message reported that an OWS employee needed to add me to a private Google Group list before I could participate; the step requires altering one's privacy settings to allow strangers to automatically sign you up for discussion lists, which did not sound appealing from a privacy standpoint.

Evidently others have had that reaction in the past, though. After an inquiry, an OWS spokesperson provided an alternate means of signing up for the list, and all was soon well. As it turns out, the list's sole purpose is to publish the Chrome Web Store link to the Signal Desktop app. A bit convoluted, perhaps, but that process seems to be part of working with the Chrome Web Store ecosystem, rather than being a facet of Signal itself.

Like a lot of packaged web apps, Signal Desktop runs in a small window without any desktop integration (i.e., there are no native menus or buttons apart from the generic window-manager buttons on the title bar). All interaction takes place inside the rendered web view, although Signal Desktop can be configured to pop up transient notifications when a new message arrives (with several privacy levels to choose from, allowing the user to show full messages, just the sender's name, or nothing but a generic new-message notice).

Once installed, it is clear from the start that Signal Desktop is intended to be an extension of the mobile app, and not meant to serve as a stand-alone application. First, the desktop app cannot be set up independently; it can only be activated as a second "device" through a previously configured smartphone Signal account. Second, one can only start conversations with a new person by typing in their phone number (as opposed to the mobile app, where you can type in a contact's name). The other party will continue to be labeled by phone number in the app's recent-conversations list until you use the smartphone app to associate the number to a name.

The smartphone app has access to the device's contacts database, so it may be possible that some future version of the desktop app will support looking up contacts by name as well. Given the need to support iOS and Android (possibly with multiple devices for any single user), though, navigating the contact-data-privacy restrictions of multiple platforms while presenting a single UI might be a tricky task for OWS. In any case, there is no escaping the fact that, in Signal, a "user" is ultimately a phone number.

At present, the desktop app supports only text conversations; sending media attachments was mentioned in the initial announcement and there is an open issue for such a feature. A request for voice-call support, however, was locked and taken private, making it rather unclear what the future of that feature is.

The interface is simple. A list of recent conversations, sorted by date, sits on the left-hand side of the window. Clicking on a contact's name opens up the conversation history on the right. At the top of the conversation pane, the drop-down menus allow the user to delete messages, verify the other user's identity, or reset the conversation (that is, re-perform the Axolotl session-key exchange). The identity verification process is akin to the one used in Zfone and many subsequent ephemeral-Diffie-Hellman–based systems: a hexadecimal key fingerprint is displayed for both users; through some out-of-band means of communication, the users can read the reported keys to each other, thus ensuring that no man-in-the-middle attack is in progress. Group chats are supported, although any groups must (currently) be created in the mobile client.

Conversations, groups, and contacts are all synchronized between the desktop client and all associated smartphone clients. This synchronization takes place immediately for mobile clients, but if one shuts down the desktop client and all other running Chrome/Chromium processes, the data will re-sync at the start of the next session.

Signal Desktop is not a general-purpose desktop chat application; it exists to add convenience for existing users of the smartphone Signal clients. For some people, that may be seen as a drawback. One needs a mobile device to even get started, even apart from the concern that Signal for Android will not run on Android derivatives (such as Replicant) without Google's proprietary Cloud Messaging library.

On the other hand, a "mobile first" approach may attract far more users than a desktop tool ever would. Even if one does not buy the oft-repeated adage that the desktop is dead, smartphone platforms rapidly attract big user bases, and instant messaging is persistently among the most popular app categories. Secure desktop clients like Tor Messenger may be excellent, but that alone will not persuade millions to put down their phones and pull up to a desktop machine to talk to their friends.

As to the security of the system itself, it checks all the right boxes (literally, on the Electronic Frontier Foundation's secure messaging scorecard): encryption is end-to-end with forward secrecy, the source code is available, and the TextSecure protocol has been audited. It is also nice to see such a potentially important end-user tool released under the GPLv3, thus protecting against proprietary forks. The only real hangups to consider are the portions of the system that run through Google services, if one is concerned about that company's wide-scale ability to track user activity.

But the desktop client, once released to the public, will not require using Google Groups, and it may even be ported to work in other browsers. Better yet, if it takes off, then perhaps it will gain additional functionality—at some point, maybe even offering a messaging solution to those users not comfortable or interested in the mobile options. Given the ease of use that OWS has achieved in its products so far, that would be a win for free software indeed.

Comments (7 posted)