Mozilla Nederland LogoDe Nederlandse
Mozilla gemeenschap

Jeff Walden: Heien v. North Carolina: Is ignorance of the law an excuse for cops who need reasonable suspicion to stop you?

Mozilla planet - di, 07/10/2014 - 01:03

It’s that time again: time to visit Washington, D.C. for more Supreme Court bobbleheads and oral arguments! I’m not going to try assembling the bobbleheads til I get home, so no pictures of them yet. Just (the first) oral argument for now.

An early-morning Supreme Court building on the first day of the October 2014 term OT2014 opening day at the Court Opening day!

Today’s argument was the first of the October 2014 term. This timing was of particular interest to me: I’ve been to arguments at other times of the year, but I figured opening day might be a little different. It was, although not significantly.

The public line outside included a few people who come every year to opening day arguments — with one person who’d been doing it for twenty-five years. (SCOTUS groupies! :-D ) If I ever make it back for an opening day it’ll be interesting to see him again. Unlike past years I didn’t do much case-reading while waiting in line; too much interesting discussion and general camaraderie.

Early morning camera crews in front of the Court building Early morning camera crews outside the Court

Inside the Court the difference was limited to Chief Justice Roberts announcing the close of the October 2013 session and the opening of the October 2014 session — essentially none, just another day at the office.

Now, a brief-ish recap of the case.

The facts of Heien v. North Carolina

One morning in 2009, two men, one of them Nicholas Heien, were driving through North Carolina. Sergeant Darisse noticed them as they passed by and found their behavior suspicious, so he started following them. Eventually Sergeant Darisse observed a reason to pull them over for violating a traffic law. (As a practical matter it’s impossible to drive for any length of time in perfect compliance with traffic law. But under Whren v. United States it’s perfectly acceptable to make “pretextual” stops, where the stop is really being made for some reason other than the immediate violation noticed.) The reason here was that Heien’s car had a malfunctioning stop lamp — that is, when the brakes were applied, only one stop lamp went on (and the other did not).

Sergeant Darisse and another officer asked the two men in the car a few questions, and they became more suspicious when the answers diverged. Sergeant Darisse asked if he could search the car. The driver said he’d have to ask Heien (as owner of the car); Heien said yes.

Looking back on the line, from the Supreme Court plaza Pictures in pictures, from the front of the line; note the scaffolding on the Capitol in the distance A brief interlude

Before we proceed further, I would like to emphasize something.

When an officer asks you if you consent to a search, you say NO.

If the officer is asking you, (at that moment) he needs your permission to do it. You do not have to grant permission. You will gain nothing if you grant consent. You’re not going to be on your way any faster; searching properly takes longer than not searching. And you never know what he might turn up. If it’s your vehicle, perhaps you had a passenger recently who left something in your car, that wouldn’t look good: drugs, drug paraphernalia, or a Justin Bieber CD. Practically, you can’t know what he’ll find. And even if you do: you’re not qualified to say what might be considered evidence of a crime, or even something that might be used against you in court for some other reason.

What if the cop promises it might get you moving faster, or tries to suggest you have nothing to hide, or whatever? Don’t believe him. Cops can legally lie to you. His verbal promise is worth the paper it’s printed on. Don’t talk to cops. My understanding is consent can’t be coerced or tricked. But good luck arguing you were tricked into it, given weasel words like “might” and it usually being your word against theirs.

Back to the facts: the result of the search

Of course (because otherwise we wouldn’t be hearing this case), the search found drugs. So now a traffic stop’s turned into a charge for trafficking cocaine. See what consenting to a search does? (Why would Heien have consented to a search, despite presumably knowing there were drugs in the car? Probably because he was legally intimidated or guilted into it. Again: Do Not Consent To Searches.)

In lower North Carolina courts

Heien challenged the stop on a number of grounds, only one relevant here: that the initial reason for the stop wasn’t valid. North Carolina law requires a working “stop lamp” (singular; emphasis added). Heien’s car had a working stop lamp. If the law is properly read that way, there was no valid reason for the initial seizure, and so by fruit of the poisonous tree the result of the search here can’t be admitted in court. (Glossing over a few details, but I’ll circle back to them.)

The trial court disagreed with Heien, but on appeal a North Carolina court of appeals agreed. The law required only one working stop lamp. And a law requiring vehicles “shall have all originally equipped rear lamps or the equivalent in good working order” didn’t apply, because stop lamps were not “rear lamps”. (“Surprising”, as the dissenters at the North Carolina Supreme Court later noted — but also fairly justified by careful reading of the statutory text.)

The court of appeals then concluded that Heien’s seizure was not permissible under the Fourth Amendment, which prohibits “unreasonable” seizures — and a seizure based on a misunderstanding of law is inherently not reasonable.

At the North Carolina Supreme Court

North Carolina didn’t contest the validity of the traffic law interpretation. Until North Carolina rewrites its laws (which, to be fair, weren’t originally buggy — back in the day only a single stop light wasn’t unusual, it’s just the law hasn’t been updated since 1955), at least in some parts of North Carolina you can legally drive with a broken stop lamp, if you have another that works. Instead North Carolina argued that the stop was a “reasonable” Fourth Amendment seizure: the officer made an “objectively reasonable” mistake of law, that had a “foothold” in the text (whatever that that precisely means), which should be enough for the seizure to be reasonable.

Another interlude: good faith

Now an interesting quirk arises. Per United States v. Leon and subsequent precedents, the exclusionary rule that prevents admitting evidence obtained through a Fourth Amendment violation is riddled with holescontains a good faith exception for various cases where a violation occurs, but it’s deemed society’s interest in not ignoring the usually-obvious truth trumps the exclusionary rule’s benefits to individuals. So for Heien to get off, he has to argue that the Fourth Amendment was violated and that he’s entitled to the remedy of suppression and that no good faith exception applies.

Except that’s not the rule in North Carolina. North Carolina’s Supreme Court has interpreted some combination of the Fourth Amendment and its own constitution (I’m not 100% sure on the details) to contain no good faith exception. If the police violate the Fourth Amendment and you’re prosecuted under North Carolina law, evidence from that violation must be suppressed. (But see two paragraphs down.)

So Heien’s job is much easier. He needs a Fourth Amendment violation, but he doesn’t also need courts to feel “sorry enough” for him to suppress the evidence: North Carolina’s already done it for him.

Back to the North Carolina Supreme Court

North Carolina’s argument that the seizure, as an “objectively reasonable” mistake of law, was a valid Fourth Amendment seizure succeeded at the North Carolina Supreme Court by a 4-3 vote. (North Carolina’s not the first court to consider this question. Nine circuit courts have considered this question. Only one has adopted the North Carolina Supreme Court’s position.) Note carefully how the North Carolina Supreme Court in effect created an alternative version of the good faith exception, just without calling it one. (The dissenters specifically called them on this.) There’s increasing pushback in North Carolina against the lack of exception, culminating in 2011 in a statutory good faith exception and a legislative call for their court to reconsider the constitutional lack of such an exception. (I don’t know the extent to which that statute and the constitutional interpretation cause conflicts North Carolina courts will have to sort out. In any event the statutory exemption can’t apply retroactively to Heien.)

At the United States Supreme Court

The (United States) Supreme Court agreed to take the case to decide whether a cop misunderstanding the law, is enough to justify a search. It didn’t decide to take on the applicability of a good faith exception to such a mistake: only whether it was a Fourth Amendment violation.

Legal analysis

Both sides here actually have pretty good arguments from precedent for their positions. The Court has previously held that cops don’t have to predict that a law might later be held unconstitutional: they can enforce laws as they’re written, without worrying whether the laws are valid or not (“with the possible exception of a law so grossly and flagrantly unconstitutional that any person of reasonable prudence would be bound to see its flaws”). That case has various logic in it that cuts strongly in favor of North Carolina, but also a few parts that arguably exclude mistakes of law from consideration. Another, more recent case, Ornelas v. United States cuts the other way. And various other cases lend support to each side.

There’s enough evidence in case law to support each side that it’s hard for me to fault a judge for coming down on either side here, on the basis of case law. I think that says something about the case law, to be honest.

Rather, what seems stronger to me ultimately is the common law presumption that “ignorance of the law is no excuse”. If you violate the law, you’re still guilty even if you didn’t know the law. Heien beats on this point pretty hard: that it’s unfair to punish someone for a law he didn’t know about, but it’s okay for a cop to stop someone for an offense that doesn’t actually exist because of what, ultimately, is ignorance of the law. North Carolina and the United States try to distinguish this by saying that a cop who breaks a law he doesn’t know about is held to it as much as a normal person. But this on-the-job, off-the-job wax-on, wax-off argument is way too cute for me.

Another landscape shot of the Court building The Court building, again; it appears from lack of netting that they’ve finished renovating the sculpture work just under the roof
Oral argument

Going into oral argument I didn’t have much sense how things might turn out. The common law rule seemed like it might speak to some at the Court. But the shining ideal of the exclusionary rule we’re all familiar with, has been steadily chipped away at for several decades. That chipping continues with the current Court. That general trend didn’t bode well for Heien.

I counted a few votes that looked fairly likely for Heien — Sotomayor pretty strongly, Ginsburg and Kagan to lesser extents. Roberts pushed about equally hard on each side in questioning. The rest seemed somewhat more in opposition to Heien than to North Carolina. Heien’s side got more pushback in oral argument than either North Carolina or the United States, all things considered. But the most striking part of argument was how it took multiple turns for the bizarre.

Justice Scalia asked why Heien wasn’t pushing for mistake of law triggering no good faith exception, in addition to it being a Fourth Amendment violation. This despite the presence of North Carolina’s non-recognition making the point irrelevant. He seemed to think the two questions were inseparable and had to be answered together. Which is a fair question — when deciding whether to review the case. But the Court took the case to answer only the one question, whether there was a Fourth Amendment violation, leaving the question of the remedy for such violation to another day. And the Court can’t really decide the question of remedy here, because it’s irrelevant to Heien and thus is not a “case or controversy” that the Court is empowered to decide here. I claim no knowledge of precedents, but it seems really unlikely to me (and Heien’s counsel had ready examples) that the Court hasn’t half-decided an issue like this before.

Meanwhile, Justice Alito wondered why North Carolina could get away without having a good faith exception: why weren’t they held to the federal rule? Which is an interesting question. But first, that question wasn’t accepted for argument, or argued below. And second, I thought Pruneyard Shopping Center v. Robins allowed states to interpret their constitutions (as North Carolina has done) to more strongly protect rights than federal courts would. (We might suppose from this that Justice Alito is rather a fan of the good faith exception [he said, understatedly, because Justice Alito is generally known to defend the police much more often than not].)

Finally, a few justices (Ginsburg, Alito, Kennedy) asked questions along the lines of, “If there was consent to search, given after the traffic stop had ended as a Fourth Amendment seizure, doesn’t that make the evidence admissible?” To which the clear answer, fruit of the poisonous tree (there is no chance to ask for consent to search, if there is no mistake-of-law stop), seemed so obvious to me as a decently-read non-lawyer (and to a couple other knowledgeable lawyers I talked to after argument), that clearly those justices were missing something really obvious. Or that law is less settled than I thought. (Which is entirely possible. But see the lawyers’ reactions.) But in any case it wasn’t the question presented, and wasn’t an argument North Carolina made in lower courts.


Given the thoroughly strange turns in argument, I’m really unsure what’ll happen. The Court could dismiss the case as “improvidently granted”, because it’s not worth answering the Fourth Amendment question without also answering whether a good faith exception also applies, and they flat-out screwed up accepting the case. In which case, everyone wasted their time. :-) The Court could answer the original question as saying there is a Fourth Amendment violation, then “somehow” also manage to answer the good faith question that was never seriously argued before — despite it not being relevant because of North Carolina jurisprudence. Or they could vote for North Carolina. But there was enough random confusion that it’s hard to guess much about who might win.

So in the end…yeah, I dunno. I don’t see any reason why the Court can’t decide for Heien or for North Carolina, and maybe in conference the justices can collectively learn enough to see why that’s so. Some of them clearly weren’t there yet, at the start of the day. Where they go from there, also unclear. I’m guessing the odds are still against Heien, but I could easily be wrong.

Other random observations

I arrived in line early enough (about 05:20) to receive card #11, solidly within the first fifty people in the public line to get a seat. (I think there were only actually eight people in front of me, and a few numbers got skipped.) This was a much better showing than the last Fourth Amendment case I attended, where I arrived at something like 02:00 and wasn’t joined by anyone else til 06:15. Just ahead of me was the man who’s attended the last twenty-five opening days, and a couple friends of his.

 11 Eleventh (actually ninth, but that early it doesn’t matter)

In front of them was a rather unusual delegation: several people from the North Carolina police department that had seized Heien, including Sergeant Darisse himself! (North Carolina apparently only received six seats at oral argument, which presumably all went to the attorney general’s office. That’s surprisingly stingier than I’d have expected.) I imagine watching a case from that vantage point would be…kind of mind-boggling, actually. I asked about a picture, but occasional undercover work precluded it. :-( No idea whether Heien himself was at the Court — apparently he finished serving his sentence, or at least is out now, so he might have been there. Of course, as actual party (as opposed to merely the agent of a party) he presumably would have no trouble attending.

In other associated mild celebrity meetings, I got to meet Orin Kerr of the Volokh Conspiracy, and very briefly (I didn’t introduce myself, just was present as he and Orin briefly talked after leaving the Court) Jeffrey Fisher of Stanford, most recently known for having successfully argued Riley v. California, the cell phone search case from last term.


In the end it seems almost commonsense to me that when you’re breaking no law, and there’s no confusion that you might possibly have been breaking the law in its actual meaning, you should be safe against searches and seizures. (Note that a mistaken understanding of facts, in contrast to a mistaken understanding of the law, doesn’t invalidate a search or seizure. For example, suppose someone liked having “fun” playing a recording of a woman’s screams in his back yard. It should be totally justified for a cop to investigate that, even if the facts are that no domestic violence or other crime is being committed.) Ignorance of the law should apply equally to everyone, and not differently to a cop acting to enforce what turns out not to be the law.

But it’s a long line of cases that have lent support to the notion that searches and seizures not consistent with the law, as ultimately interpreted by the courts, can still produce fruits for investigations and prosecutions. And so eventually we reach the point where someone can be detained for not violating the law identified as the reason for the seizure, and it’s a legitimate question whether the seizure is reasonable or not.

I don’t agree with the retired Justice Stevens on a number of issues. But in this case, judging by his dissent in United States v. Leon, I wish he were still voting on the Court.

(And, as always — and particularly here, because Fourth Amendment law is very clearly not a thing quickly or easily understood, and I am still only scratching the surface in my knowledge of it — please point out any mistakes I’ve made in my discussion here. :-) )

Categorieën: Mozilla-nl planet

Bugzilla 0-day can reveal 0-day bugs in OSS giants like Mozilla, Red Hat - Ars Technica

Nieuws verzameld via Google - ma, 06/10/2014 - 23:31

Ars Technica

Bugzilla 0-day can reveal 0-day bugs in OSS giants like Mozilla, Red Hat
Ars Technica
Security firm Check Point Software Technologies used a flaw it discovered in the Perl programming language to hack into the popular Bugzilla bug-tracking system and add four users to the administrator group, giving them power to see the details of ...
Bugzilla Vulnerability Puts Bug Collections in Harm's WayThreatpost
Critical Bugzilla vulnerability could give hackers access to undisclosed ...CSO Online

alle 24 nieuwsartikelen »Google Nieuws
Categorieën: Mozilla-nl planet

64 bit Mozilla Firefox browser official - Load The Game

Nieuws verzameld via Google - ma, 06/10/2014 - 21:18

Load The Game

64 bit Mozilla Firefox browser official
Load The Game
Mozilla has been thinking about developing a 64 bit Firefox browser for quite some time now, and with the imminent launch of Windows 10, the company seems to have decided to speed things up. Mozilla has announced that the 64 bit Firefox browser it has ...
Mozilla's 64-bit Firefox browser will touch down in Spring 2015TechRadar UK
Mozilla And KDDI Unveil New Mini PC Running Firefox OSGeeky gadgets
Mozilla is making plans for 64-bit Firefox browserPhys.Org
Liliputing -REM -ITProPortal
alle 27 nieuwsartikelen »Google Nieuws
Categorieën: Mozilla-nl planet

Gervase Markham: New Class of Vulnerability in Perl Web Applications

Mozilla planet - ma, 06/10/2014 - 21:13

We did a Bugzilla security release today, to fix some holes responsibly disclosed to us by Check Point Vulnerability Research, to whom we are very grateful. The most serious of them would allow someone to create and control an account for an arbitrary email address they don’t own. If your Bugzilla gives group permissions based on someone’s email domain, as some do, this could be a privilege escalation.

These bugs are actually quite interesting, because they seem to represent a new Perl-specific security problem. (At least, as far as I’m aware it’s new, but perhaps we are about to find that everyone knows about it but us.) This is how it works. I’m using the most serious bug as my example. The somewhat less serious bugs caused by this pattern were XSS holes. (Check Point are going to be presenting on this vulnerability at the 31st Chaos Communications Congress in December in Hamburg, so check their analysis out too.)

Here’s the vulnerable code:

my $otheruser = Bugzilla::User->create({ login_name => $login_name, realname => $cgi->param('realname'), cryptpassword => $password});

This code creates a new Bugzilla user in the database when someone signs up. $cgi is an object representing the HTTP request made to the page.

The issue is a combination of two things. Firstly, the $cgi->param() call is context-sensitive – it can return a scalar or an array, depending on the context in which you call it – i.e. the type of the variable you assign the return value to. The ability for functions to do this is a Perl “do what I mean” feature.

Let’s say you called a page as follows, with 3 instances of the same parameter:


If you call param() in an array context (the @ sigil represents a variable which is an array), you get an array of values:

@values = $cgi->param('foo'); --> ['bar', 'baz', 'quux']

If you call it in a scalar context (the $ sigil represents a variable which is a scalar), you get a single value, probably the first one:

$value = $cgi->param('foo'); --> 'bar'

So what context is it being called in, in the code under suspicion? Well, that’s exactly the problem. It turns out that functions called during hash value assignment are evaluated in a list context. However, when the result comes back, that value or those values are assigned to be part of uthe hash as if they were a set of individual, comma-separated scalars. I suspect this behaviour exists because of the close relationship of lists and hashes; it allows you to do stuff like:

my @array = ("foo", 3, "bar", 6); my %hash = @array; --> { "foo" => 3, "bar" => 6 }

Therefore, when assigning the result of a function call as a hash value, if the return value is a single scalar, all goes as you would expect, but if it’s an array, the second and subsequent values end up being added as key/value pairs in the hash as well. This allows an attacker to override values already in the hash (specified earlier), which may have already been validated, with values controlled by them. In our case, real_name can be any string, so doesn’t need validation, but login_name most definitely does, and it already has been by the time this code is called.

So, in the case of the problematic code above, something like:


would end up overriding the already-validated login_name variable, giving the attacker control of the value used in the call to Bugzilla::User->create(). Oops.

We found 15 instances of this pattern in our code, four of which were exploitable to some degree. If you maintain a Perl web application, you may want to audit it for this pattern. Clearly, param() calls are the first thing to look for, but it’s possible that this pattern could occur with other modules which use the same context-sensitive return feature. The generic fix is to require the function call to be evaluated in scalar context:

my $otheruser = Bugzilla::User->create({ login_name => $login_name, realname => scalar $cgi->param('realname'), cryptpassword => $password});

I’d say it might be wise to not ever allow hash values to be assigned directly from functions without a call to scalar.

Categorieën: Mozilla-nl planet

Bugzilla Vulnerability Puts Bug Collections in Harm's Way - Threatpost

Nieuws verzameld via Google - ma, 06/10/2014 - 20:33


Bugzilla Vulnerability Puts Bug Collections in Harm's Way
Hundreds of open source software projects that make use of Bugzilla, Mozilla's bug-tracking software, anxiously await a patch for a vulnerability that exposes private bugs collected by the system. Mozilla is today expected to make available a patch for ...
Critical Bugzilla vulnerability could give hackers access to undisclosed ...CSO Online

alle 24 nieuwsartikelen »Google Nieuws
Categorieën: Mozilla-nl planet

Frédéric Harper: DevFest Nantes 2014 aura sa présentation sur Firefox OS

Mozilla planet - ma, 06/10/2014 - 16:38


DevFest Nantes, organisé par le Google Developer Group local, en est à sa troisième édition. Je suis bien heureux d’avoir été invité à présenter sur Firefox OS par les organisateurs, car ceci démontre une ouverture d’esprit de la part de l’organisation pour sortir un peu des sujets strictement lié au géant de la recherche sur le web. Pour ma première visite à Nantes, voici la présentation que je ferais le 7 novembre prochain sur le thème de HTML pour le web mobile, Firefox OS:

HTML5 est un pas de géant dans la bonne direction: il apporte plusieurs fonctionnalités dont les développeurs avaient besoin pour créer plus facilement de meilleures expériences web. Il a aussi fait naitre un débat sans fin: applications natives ou applications web! Lors de cette présentation, Frédéric Harper vous montrera comment le web ouvert peut vous aider à créer des applications mobiles de qualités. Vous en apprendrez plus sur des technologies telles que les WebAPIs, ainsi que les outils qui vous permettront de viser un nouveau marché avec Firefox OS et le web d’aujourd’hui.

J’aime bien aller présenter en France, car même si notre accent diffère, cela me permet de partager ma passion des technologies dans ma langue natale, même si je m’aperçois que j’ai de plus en plus de misère à trouver mes mots, présentant toujours dans ma langue seconde, l’anglais. Ça s’annonce une belle journée avec quatre sessions consécutives et les billets sont toujours en vente, donc faite vite. Au plaisir de discuter web avec les développeurs nantais.

DevFest Nantes 2014 aura sa présentation sur Firefox OS is a post on Out of Comfort Zone from Frédéric Harper

Related posts:

  1. HTML5 sur les stéroïdes à HTML5mtl C’est avec un immense plaisir que je présenterais pour la...
  2. Entrevue Firefox OS de Savoir Faire Linux à Pycon 2014 Je ne suis pas un développeur Python, mais j’ai tout...
  3. Firefox OS à HTML5mtl Mardi soir avait lieu la rencontre mensuelle d’HTML5mtl et j’ai...
Categorieën: Mozilla-nl planet

Curtis Koenig: Curtis Report 2014-10-03

Mozilla planet - ma, 06/10/2014 - 15:58

I spent a good deal of this week doing RTB activities that are mostly non-noteable other than they have to get done. I likely should have taken a PTO day to recover from DerbyCon (lesson for next time) I jumped right back into things.

On Thu I attended the Louisville Metro InfoSec conference put on by the Kentuckiana chapter of the Information Systems Security Association (ISSA). This is a  yearly gathering of InfoSec professionals from Louisville, Southern Indiana, Lexington and Cincinatti, and a few from furhter out. This event also allows infosec students from local schools to attend for free and a large number of them did attend.

I spent most of the day promoting OWASP and Mozilla via a booth the organizers were kind enough to give for free. I was supposed to have help so I could attend some talks but my 2 other co-leaders had to leave town suddenly (will have to watch IronGeek recordings).

While I did not have any items to give away we did get lots of traffic at the booth, mostly due to my FirefoxOS device. While it is an older geeks phone I did have the latest nighly installed on it. The student attendees were most excited about it, some even taking pictures of different screens. They seemed quite interested in the developer tools in Firefox (WebIDE) along with the FirefoxOS simulator. this lead to natural conversations about getting involved, mentored bugs and mentorship projects at Mozilla.

The large topic of discussion with the more coporate types centered around our Cloud Services efforts. I fielded lots of questions about Sync (how they could do their own), Firefox Accounts, Location services and Marketplace. There is good deal of angst with the corporate types over the tension to use cloud for cost but concerns over data ownership, privacy and security of such services. They were quite pleased with our efforts and also liked that they could do hybrid cloud (public-private) mixes with Mozilla offerings.

What I did this week
  • [vendor redacted] ground work for internal pen testing
  • DerbyCon trip report
  • TRIBE Prep
  • Safari books for MWoS team
Meetings Attended Mon
  • Mozilla Project Meeting
  • secautomation
  • Update on Firefox OS Release Cadence
  • Cloud Services Security Team Meeting
  • MWoS team meeting
  • Cloud Services All Hands
  • Security/Privay/Vendor Reviews Discussion w/ Marshall
  • last day virtual beer for coworker

Categorieën: Mozilla-nl planet

Yunier José Sosa Vázquez: Firefox OS fue presentado en Bangladesh

Mozilla planet - ma, 06/10/2014 - 14:00

Desde el lanzamiento de Firefox el año pasado hay sido muchos los países donde se ha presentado la nueva alternativa propuesta por Mozilla hasta sumar más de 20. Con el apoyo de las operadoras y los fabricantes, Mozilla planea abrir el ecosistema móvil convirtiendo la web en la plataforma para estos dispositivos.

A finales de septiembre pasado se presentó en Bangladesh y operado por el operador local Grameenphone perteneciente a Telenor Group, el teléfono GoFox F15 (producido por Symphony). Este anuncio es el segundo que ocurre en Asia pues con anterioridad se habían presentado los modelos Intex Cloud FX y el Spice Fire One MI FX1 en la India. Ahora, muchas más personas podrán contar con un teléfono inteligente barato capaz de dar a los usuarios una agradable experiencia.


Captura de Firefox OS en Bengali (pantalla de inicio, búsqueda y música)

El Symphony GoFox F15 tiene instalado Firefox OS 1.4, está siendo vendido a unos 60 USD e incluye las siguientes características:

  • Procesador Spreadtrum a 1 GHz de un solo núcleo
  • Pantalla de 3.5 pulgadas (320×480)
  • 512 Mb de almacenamiento
  • 512 Gb de RAM
  • Cámara frontal de 0,3 Mp, y trasera de 3.2 Mp
  • Wi-Fi, Bluetooth
  • Batería de 1450 mAh
  • Dual SIM

Esperamos que muy pronto Firefox OS sea presentado en más latitudes y que nuevos fabricantes apoyen la iniciativa de Mozilla.

Categorieën: Mozilla-nl planet

Will Kahn-Greene: Input: Dashboards for Everyone v1

Mozilla planet - ma, 06/10/2014 - 14:00

In 2014q3, I created the Dashboards for Everyone project. This blog post covers what the project is, what's out there now, some examples of usage and the future.

Input collects sentiment data on Mozilla products. Currently, this data can be seen on the front page dashboard. This dashboard sucks for a variety of reasons amongst which is that it's a slog of data that isn't particularly informative.

Further, it's pretty clear that the greater Mozillaverse has different informational needs. Some people are interested in issues with products in specific locales. Some people are interested in today's hot topic. Some people are interested in comparing the first week after release of one version of a product with another. Etc.

Given that, we have two paths:

  1. Create dashboards that live on Input catering to all these needs.
  2. Create an API that allows people to create their own dashboards and host them wherever.

These two paths aren't mutually exclusive. However, I want to put effort into the second one first for the following reasons:

  1. It enables people to individually and collectively solve their own informational problems.
  2. It enables people to solve informational problems as problems crop up rather than wait for Input developers to have time to write up a dashboard.
  3. As people are solving their informational problems, we'll learn a lot more about what informational problems exist which will guide how we build dashboards that live on Input.

The Dashboards for Everyone project aims to create the infrastructure for enabling people to write their own dashboards using Input data.

Version 1

Over the course of the quarter we put enough of the bits in place that building your own dashboard is a viable thing now.

First, we wrote and honed an API for getting feedback data.

Then we wrote a bunch of proof-of-concept dashboards that use this data.

I threw together these two dashboards which are defined in Github gists and "hosted" on

Ian Kronquist (Input intern for summer 2014) wrote this one:

Those are examples of fetching and manipulating the data into a chart. They're not very informative. We used them to help flesh out the API and their current purpose is as examples for using the API to do things.

However, we've built some real things that use the data and are "in production" now:

  • I use the Input API for the Response Breakdown graphs on the Input Health Dashboard. That helps me figure out whether we've just pushed out bugs preventing people from leaving feedback. That uses a d3-based charting library I've been toying with to help me flesh out possible data transform needs. It also uses a library that lets me defined the charts in HTML attributes and they get "auto-charted" without me having to write JavaScript.
  • Cheng used the Input API to build the Hello dashboard for tracking Hello feedback.
  • I then reused most of his ideas and some of his code to produce a Firefox for Android trends dashboard. That's still got some issues namely that the tokenizing isn't very good and thus there's enough noise in the words lists that it doesn't bring real trending issues into starker relief.

That's where we're at. Now I need to tell people about it so that you know these possibilities exist.

Do you have informational needs for the data on Input?

Can the API help you solve your specific needs?

Are there important things missing that you need to have implemented in order to solve your needs?

If you use the Input API to build your own dashboards and you run into problems, write up a bug.

Version 2 and future

Bugs, conversations and seeing other peoples' dashboards will inform us as to how we need to grow the API going forward. That will set the priorities for the next version.

Also, I have a few ideas I've been mulling over:

  1. Build an index of charts: If there are a sufficient number of interesting charts out there, then we should build an index of them on Input.

  2. Build tokenizing into the Input API: If you look at the JavaScript code for my Firefox for Android Trends chart, a good portion of it deals with tokenizing. If tokenizing is a common thing people are doing to build charts, then we should pull that tokenizing in-house.

  3. Build an auto-charter or chart widget library: Right now you have to do all the charting by hand. It'd be really nice to be able to throw dashboards together using chart "widgets" and possibly define the dashboard entirely in HTML. I've been toying with this with the Input Health Dashboard. I'm curious to find out if there's a need for throwing dashboards together quickly to follow certain issues (e.g. e10s, Hello, ...).

    The Metrics team produces some really great looking dashboards that use MetricsGraphics.js. Maybe we could build a shim on top of that letting people more easily use that library with Input data?


I really want to thank Matt Grimes for coordinating d3 training, Cheng Wang for giving me some compelling code to reuse and Mike Cooper for helping me debug code whose mystery was only exceeded by its brokenness.

Thoughts, comments, etc

I'm using the fruits of this labor now, so at a bare minimum, it solved some of my problems.

Can it help you solve yours?

Categorieën: Mozilla-nl planet

Mozilla Reps Community: Rep of the Month: September 2014 – Alexandre Ben Mahmoud

Mozilla planet - ma, 06/10/2014 - 13:17

rednaksSkander (aka Alex) is an inspiring, passionate and a gifted Tunisian mozillian when it’s about free technologies. His involvement in Mozilla is about a strong belief in our mission and our values.

These last months, Alex has been doing a wonderful work to encourage Tunisians techies to contribute in Mozilla.

Starting by making all Mozilla Tunisia’s projects available to all on github to writing documentation and tutorials on the community’s Wiki and publishing articles on the website to encourage people and facilitate there integration. Without forgetting his availability on IRC to reply to all the contributors questions and assist them.

As a community technical manager, he managed brilliantly this month the MozTn Slides project.
He also was also very helpful to prepare the Grow Mozilla Tunisia and had a wonderful reaction to encourage the team and push them to continue when the event was canceled.

This apart, Alex always contributed to many bugs and developed many patch for Firefox and Firefox OS.

Congratulations Alex, well deserved :)

Congratulate Alex yourself on Discourse!

Categorieën: Mozilla-nl planet