mozilla

Mozilla Nederland LogoDe Nederlandse
Mozilla gemeenschap

Abonneren op feed Mozilla planet
Planet Mozilla - http://planet.mozilla.org/
Bijgewerkt: 8 uur 2 min geleden

Doug Belshaw: Playtesting for MozFest

wo, 08/10/2014 - 18:02

Today I was down at Bishop Grosseteste University, giving a guest lecture and facilitating a workshop. The module was on digital literacies as part of a course for Early Years students. These are students who may go on to teacher training. Some of the work relating to my thesis and the work I’ve done with Mozilla is on their reading list.

Web

From my point of view it was a useful opportunity to playtest some sessions I’ve got planned for the Mozilla Festival at the end of the month. I’ve travelled a lot less in the year since I moved to the Webmaker team, and so I welcomed this opportunity to refine some of my thinking. It’s also good to get input from as many places as possible about Web Literacy Map v2.0.

I made the lecture as participatory as the logic of the lecture theatre allowed. You can find my slides here. We had a backchannel in the form of a Google Doc which surfaced some interesting questions. On a meta level my aim was to highlight the importance of attention. I’m coming round to Howard Rheingold’s view that it’s key to everything we do, both online and offline. Interestingly, one of the questions was whether a single Web Literacy Map can be relevant to everyone.

For the workshop, I split the students into two groups and swapped over halfway. After an introduction to both workshops, half stayed with the course leaders, and the other half came with me. Those who came with me read a chapter of my book The Essential Elements of Digital Literacies followed by a discussion. Those who stayed behind completed a Web Literacy Map activity on their iPads.

Three things stand out in particular from the discussion I had with students:

  1. Confidence. One student had the insight about the reason she’s always shied away from using technology. She explained that she wasn’t exposed to it at a young age in the same way others had been. As a result, she’s always felt under-confident around anything digital and never wants to do more than she has to with it.

  2. Filtering. As I point out in my book, I’m against filtered internet connections. This presupposes the ability to have a rational conversation instead of just filtering. In Early Years (ages 3-5) this isn’t necessarily the case.

  3. Unintended consequences. We know that people devise workarounds to problems they have. Students talked about the ways in which school filters had prevented them accessing Facebook. As a result, they resorted to ‘dodgy’ websites that had evaded filters. These often featured inappropriate advertising and malware, but promised access to Facebook. User accounts were often hacked. By filtering, the school had driven students towards those things they were trying to prevent them doing or seeing.

I’m still waiting to see all the results of the Web Literacy Map activity I set, but the couple of examples I saw were promising. Students added, renamed and re-arranged the competencies of the Web Literacy Map v1.1. This led to some curious groupings. I wouldn’t necessarily thought of putting together ‘Credibility’ with ‘Security’ and ‘Privacy’, for example. It was also interesting that it wasn’t immediately obvious to them what ‘Infrastructure’ means.

For MozFest, I’m going to:

  • Refine the Web Literacy Map activity based on the results of the survey we’re launching this week.
  • Think about where skills and competencies related to ‘e-safety’ should sit.
  • Revisit Beetham & Sharpe’s (2009) taxonomy of access, skills, practices, and attributes.

All in all, it was definitely a worthwhile trip down to Lincoln for me. I hope it was for the students and course leaders, too! Many thanks to Ben Samuels for the invitation, and to Chris Bonfield, Mary-Louise Maynes and team for their warm welcome!

Categorieën: Mozilla-nl planet

Jen Fong-Adwent: End of a year, start of a new year

wo, 08/10/2014 - 17:00
A year ago I publicly announced Meatspace as an experiment in realtime chat with animated GIFs
Categorieën: Mozilla-nl planet

Gervase Markham: Rebel Alliance Ideas

wo, 08/10/2014 - 13:34

Chris Beard has been encouraging us to think like the rebels; what can we do that other people won’t do? How can we make an impact?

Here are some of my thoughts:

  • The internet, in global average, is getting less reliable, slower and more laggy. Finish Janus and persuade our mobile partners to deploy it and default to it. Your Firefox OS phone now accesses the net faster than an Android phone.
  • Make Firefox OS connect by default to openwireless.org access points, and encourage Firefox OS users to run them. There’s a virtuous circle here. More net in more places; a global movement of being generous with net access.
  • Finish Daala faster, by finding people other than the core team to do everything except design the codec and write the algorithms (e.g., testing, speed optimizations, fuzzing, writing Windows Media plugins). We need to get the word out that this project is critical.
  • Show the core free software community, who have great influence over tech choices and who should be our natural allies, that we care about them. Be the first organization ever to make a free-from-bottom-to-top mobile phone (running Firefox OS) and give some help to the Replicant team to port to it as well, just to prove we mean it and it’s real.
  • Make it possible to search for specifically open source software in the Marketplace, and show we believe it “promotes the development of the Internet as a public resource” by promoting apps which are open source.
  • Ship Collusion (which has been in the works for years), even if there’s not a perfect mapping between what it shows you and what’s actually bad. Make sites feel they have to justify all their 3rd party links.

What are your ideas?

Categorieën: Mozilla-nl planet

Lucas Rocha: Probing with Gradle

wo, 08/10/2014 - 01:12

Up until now, Probe relied on dynamic view proxies generated at runtime to intercept View calls. Although very convenient, this approach greatly affects the time to inflate your layouts—which limits the number of use cases for the library, especially in more complex apps.

This is all changing now with Probe’s brand new Gradle plugin which seamlessly generates build-time proxies for your app. This means virtually no overhead at runtime!

Using Probe’s Gradle plugin is very simple. First, add the Gradle plugin as a dependency in your build script.

buildscript { ... dependencies { ... classpath 'org.lucasr.probe:gradle-plugin:0.1.3' } }

Then apply the plugin to your app’s build.gradle.

apply plugin: 'org.lucasr.probe'

Probe’s proxy generation is disabled by default and needs to be explicitly enabled on specific build variants (build type + product flavour). For example, this is how you enable Probe proxies in debug builds.

probe { buildVariants { debug { enabled = true } } }

And that’s all! You should now be able to deploy interceptors on any part of your UI. Here’s how you could deploy an OvermeasureInterceptor in an activity.

public final class MainActivity extends Activity { @Override protected void onCreate(Bundle savedInstanceState) { Probe.deploy(this, new OvermeasureInterceptor()); super.onCreate(savedInstanceState); setContentView(R.id.main_activity); } }

While working on this feature, I have changed DexMaker to be an optional dependency i.e. you have to explicitly add DexMaker as a build dependency in your app in order to use it.

This is my first Gradle plugin. There’s definitely a lot of room for improvement here. These features are available in the 0.1.3 release in Maven Central.

As usual, feedback, bug reports, and fixes are very welcome. Enjoy!

Categorieën: Mozilla-nl planet

Will Kahn-Greene: Input: 2014q3 post-mortem

di, 07/10/2014 - 20:00

This is the 2014q3 Input post-mortem. It was a better quarter than 2014q2--that one kind of sucked. Instead 2014q2 started out well and then got kind of busy and then I was pretty overwhelmed by the end.

Things to know:

  • Input is Mozilla's product feedback site.
  • Fjord is the code that runs Input.
  • I unilaterally decided to extend 2014q3 to October 6th.
  • I am Will Kahn-Greene and I'm the primary developer on Input.
Bug and git stats Bugzilla ======== Bugs created: 58 Bugs fixed: 54 git === Total commits: 168 Will Kahn-Greene : 144 (+195460, -188019, files 658) Ian Kronquist : 12 (+402, -106, files 21) L. Guruprasad : 6 (+16, -36, files 6) Adam Okoye : 4 (+34, -34, files 34) Ruben Vereecken : 2 (+69, -29, files 12) Total lines added: 195981 Total lines deleted: 188224 Total files changed: 731

We added a bunch of code this quarter:

  • October 7th. 2014: 23466 total, 11614 Python

Compare to previous quarters:

  • 2014q1: April 1st, 2014: 15195 total, 6953 Python
  • 2014q2: July 1st, 2014: 20456 total, 9247 Python

Nothing wildly interesting there other than noting that the codebase for Input continues to grow.

Contributor stats

Ian Kronquist was the Input intern for Summer 2014. He contributed several fixes to Input. Yay!

We spent a bunch of time making our docs and Vagrant provisioning script less buggy so as to reduce the problems new contributors have when working on Input. I talked with several people about things they're interested in working on. Plus several people did some really great work on Input.

Generally, I think Input is at a point where it's not too hard to get up and running, we've got several lists of bugs that are good ones to start with and the documentation is good-ish. I think the thing that's hampering us right now is that I'm not spending enough time and energy answering questions, managing the work and keeping things going.

Anyhow, welcome L. Guruprasad, Adam Okoye and Ruben Vereecken! Additionally, many special thanks to L. Guruprasad who fixed a lot of issues with the Vagrant provisioning scripts. That work is long and tedious, but it helps everyone.

Accomplishments

Dashboards for everyone: We wrote an API and some compelling examples of dashboards you can build using the API. It's being used in a few places now. We'll grow it going forward as needs arise. I'm pretty psyched about this since it makes it possible for people with needs to help themselves and not have to wait for me to get around to their work. Dashboards for everyone project plan.

Vagrant: We took the work I did last quarter and improved upon it, rewrote the docs and have a decent Vagrant setup now. Reduce contributor pain project plan.

Abuse detection: Ian spent his internship working on an abuse classifier so that we can more proactively detect and prevent abusive feedback from littering Input. We gathered some interesting data and the next step is probably to change the approach we used and apply some more complex ML things to the problem. The key here is that we want to detect abuse with confidence and not accidentally catch swaths of non-abuse. Input feedback has some peculiar properties that make this difficult. Reduce the abuse project plan.

Loop support: Loop is now using Input for user sentiment feedback.

Heartbeat support: User Advocacy is working on a project to give us a better baseline for user sentiment. This project was titled Heartbeat, but I'm not sure whether that'll change or not. Regardless, we added support for the initial prototype. Heartbeat project plan.

Data retention policy: We've been talking about a data retention policy for some time. We decided on one, finalized it and codified it in code.

Shed the last vestiges of Playdoh and funfactory: We shed the last bits of Playdoh and funfactory. Input uses the same protections and security decisions those two projects enforced, but without being tied to some of the infrastructure decisions. This made it easier to switch to peep-based requirements management.

Switched to FactoryBoy and overhauled tests: Tests run pretty fast in Fjord now. We switched to FactoryBoy, so writing model-based tests is a lot easier than the stuff we had before.

Summary

Better than 2014q2 and we fixed some more technical debt further making it easier to develop for and maintain Input. Still, there's lots of work to do.

Categorieën: Mozilla-nl planet

Roberto A. Vitillo: Using ML to correlate add-ons to performance bottlenecks

di, 07/10/2014 - 16:50

I started looking into exploiting our Telemetry data to determine which add-ons are causing performance issues with Firefox. So far there are three metrics that I plan to correlate with add-ons:

  • startup time,
  • shutdown time,
  • background hangs.

In this post I am going over my findings for the first scenario, i.e. the relation between startup time and installed add-ons.

In an ideal world, all add-ons would have an uniform way to initialize themselves which could be instrumented. Unfortunately that’s not possible, many add-ons use asynchronous facilities and or rely on observer notifications for initialization. In other words, there is no good way to easily measure the initialization time for all add-ons without possibly touching their codebases individually.

This is the sort of problem that screams for a multi-way ANOVA but, after some thought and data exploration, it turns out that the interaction terms can be dropped between add-ons, i.e. the relation between add-ons and the startup time can be modeled as a pure additive one. Since a multi-way ANOVA is equivalent to a linear regression between a set of predictors and their interactions, the problem can be modeled with a generalized linear model where for each Telemetry submission the add-on map is represented as a boolean vector of dummy variables that can assume a value of 0 or 1 corresponding to “add-on installed” and “add-on not installed”, respectively.

Startup time depends on many other factors that are not taken into account in the model, like current system load and hard drive parameters. This means that it would be very surprising, to say the least, if one could predict the startup time without those variables. That doesn’t mean that we can’t explain part of the variance! In fact, after training the model on the data collected during the past month, it yielded a R^2 score of about 0.15, which in other words means that we can explain about 15% of the variance. Again, as we are not trying to predict the startup time accurately this is not necessarily a bad result. The F ratio, which relates the variance between add-ons to the variance within add-ons, is significant which remarks that having or not certain add-ons installed does influence the startup time.

Many of the p-values of the predictor’s coefficients are highly significant (<< 0.001); it’s just a matter of sorting the significant results by their effect size to determine the add-ons that cause a notable slowdown of Firefox during startup:

Rplot06The horizontal axis measures the startup time overhead with respect to the average startup time of Firefox. For instance, Yandex Elements seems to be slowing down startup by about 8 seconds on average. The error-bars represent the standard errors of the sampling distributions of the coefficients.

Note that the model is based on a very small fraction of our user-base, i.e. the subset that has Telemetry enabled, so there clearly is some implicit bias. The picture might be different for a truly random sample of our users, nevertheless it is an indication of where to start digging deeper.

The next step is to “dashboardify” the whole thing and contact the developers of the various add-ons. We are also considering notifying users, in a yet to be determined way, when the browser detects add-ons that are known to cause performance issues.

References: map-reduce job and model


Categorieën: Mozilla-nl planet

Adam Lofting: Mozilla Contributor Analysis Project (Joint MoCo & MoFo)

di, 07/10/2014 - 16:27

I’m  back at the screen after a week of paternity leave, and I’ll be working part-time for next two weeks while we settle in to the new family routine at home.

In the meantime, I wanted to mention a Mozilla contributor analysis project in case people would like to get involved.

We have a wiki page now, which means it’s a real thing. And here are some words my sleep-deprived brain prepared for you earlier today:

The goal and scope of the work:

Explore existing contribution datasets to look for possible insights and metrics that would be useful to monitor on an ongoing basis, before the co-incident workweek in Portland at the beginning of December.

We will:

  • Stress-test our current capacity to use existing contribution data
  • Look for actionable insights to support Mozilla-wide community building efforts
  • Run ad-hoc analysis before building any ‘tools’
  • If useful, prototype tools that can be re-used for ongoing insights into community health
  • Build processes so that contributors can get involved in this metrics work
  • Document gaps in our existing data / knowledge
  • Document ideas for future analysis and exploration

Find out more about the project here.

I’m very excited that three members of the community have already offered to support the project and we’ve barely even started.

In the end, these numbers we’re looking at are about the community, and for the benefit of the community, so the more community involvement there is in this process, the better.

If you’re interested in data analysis, or know someone who is, send them the link.

This project is one of my priorities over the following 4-8 weeks. On that note, this looks quite appealing right now.

So I’m going make more tea and eat more biscuits.

Categorieën: Mozilla-nl planet

Patrick Cloke: How I Got Involved in Mozilla

di, 07/10/2014 - 15:31

This is discussed very briefly on my about page, but I figured it could use a bit of a longer discussion. I generally consider myself to have joined the Mozilla community in ~2006. I know that I was using Mozilla Firefox, Mozilla Thunderbird, and Mozilla Sunbird way before that (probably since ~2004, which is when I built my own computer). But I was just an enthusiast then, running beta builds, then alpha and eventually nightly builds. (This was way back when we things were more dangerous to run: Minefield and Shredder.)

Anyway, back to 2006…I initially got involved in a more technical fashion by writing extensions (or maybe it was GreaseMonkey scripts). I don’t really have anyway to prove this though — I don’t seem to have any of that code. (This was before widespread distributed version control.) Anyway, let’s just assume this 2006 date is correct.

My first patch was in 2008 to move a function from the Provider for Google Calendar to the calendar core so that I could use it in Thundershows: a calendar provider for TV shows [1] [2]. (As far as I know, I’m one of a handful of people to actually implement a calendar provider.) I found the calendar project much easier to get involved in than other aspects of Mozilla since it was so much smaller. (I also toyed with adding an entire new protocol to Thunderbird, which R Kent James has now done successfully! [3] [4])

I then came across Instantbird in ~2008 (sometime in the Instantbird 0.1 era). I thought this was great — Mozilla was finally making an instant messaging client! Well, I was kind of right…Instantbird is not an official Mozilla project, but it was exactly what I wanted! The guys (mostly Florian Quèze) in the #instantbird IRC channel were awesome: kind, patient, helpful, and welcoming. They were the ones that really introduced me into the Mozilla way of doing things. I fixed my first bug for Instantbird in 2010 and haven’t stopped since! I’ve since added IRC support and am now one of the lead developers. I’ve mentored Google Summer of Code students twice (2013 and 2014), contribute to Thunderbird and am a peer of the chat code shared between Instantbird and Thunderbird. (I do also occassionally contribute to other projects. [5])

[1]This was my first project to really have other users, I had people filing bugs, asking for new features, etc. It was great! I even had someone (years later) tell me in #instantbird that they had loved Thundershows! [2]My second bug dealt with the same set of code and had tests committed (by me) over 5 years after the initial patch. Oops! [3]My work was based off of some experiments Joshua Cranmer did to add support for web forums to Thunderbird. After all this time, I still want that extension. [4]Oh, also rkent did EXACTLY what I wanted years later: which is add Twitter to Thunderbird. [5]But not Firefox. After seven years (and over 1800 commits), I’ve never fixed a bug in Firefox; although I have had code committed to mozilla-central.
Categorieën: Mozilla-nl planet

Ben Hearsum: Redo 1.3 is released – now with more natural syntax!

di, 07/10/2014 - 14:48

We’ve been using the functions packaged in Redo for a few years now at Mozilla. One of the things we’ve been striving for with it is the ability to write the most natural code possible. In it’s simplest form, retry, a callable that may raise, the exceptions to retry on, and the callable to run to cleanup before another attempt – are all passed in as arguments. As a result, we have a number of code blocks like this, which don’t feel very Pythonic:

retry(self.session.request, sleeptime=5, max_sleeptime=15, retry_exceptions=(requests.HTTPError, requests.ConnectionError), attempts=self.retries, kwargs=dict(method=method, url=url, data=data, config=self.config, timeout=self.timeout, auth=self.auth, params=params) )

It’s particularly unfortunate that you’re forced to let retry do your exception handling and cleanup – I find that it makes the code a lot less readable. It’s also not possible to do anything in a finally block, unless you wrap the retry in one.

Recently, Chris AtLee discovered a new method of doing retries that results in much cleaner and more readable code. With it, the above block can be rewritten as:

for attempt in retrier(attempts=self.retries): try: self.session.request(method=method, url=url, data=data, config=self.config, timeout=self.timeout, auth=self.auth, params=params) break except (requests.HTTPError, requests.ConnectionError), e: pass

retrier simply handles the the mechanics of tracking attempts and sleeping, leaving your code to do all of its own exception handling and cleanup – just as if you weren’t retrying at all. It’s important to note that the break at the end of the try block is important, otherwise self.session.request would run even if it succeeded.

I released Redo 1.3 with this new functionality this morning – enjoy!

Categorieën: Mozilla-nl planet

Alex Vincent: Competing with pen & paper

di, 07/10/2014 - 07:37

In tonight’s linear algebra class, I made the mistake of leaving my paper notebook home. Ok, I thought, I’ll just use Amaya and see how that goes.

Not so well, it turns out.

Twenty minutes of lecture equals a frantic “where is that thing?”, and nothing learned…
  • The template for a MathML subscript is in a different panel from the template for a MathML summation (“sigma”), and you have to switch between panels constantly.
  • If you want two subscripts (and in linear algebra, two subscripts for an element is common), you get a modal dialog.  (Really? How many subscripts does an element need?)
  • Where’s the special “M” symbol for matrix spaces? (I’d post it, but WordPress eats everything after that U+1D544 character!)  We can get the real number set with &#x211d;..
  • The UI for Amaya is hard-coded, so I can’t change it at all.
  • Amaya’s copy & paste support is terrible.
  • It takes about 2 seconds to write [Ai]1j with pen & paper. In Amaya that takes somewhere around ten seconds, plus the dialog I mentioned earlier.
  • Oh, and the instructor’s going on, keeping a pace for students using pen & paper… there’s no chance of me keeping up with him.

After twenty minutes of trying to quickly jot down what he’s saying, without comprehension, I end up with some symbolic gobbledygook that’s probably about 80% of a match to what the instructor is actually saying.  But what I was able to write down was complete nonsense.

I ended up switching to scratch paper and pen, where I was not only able to keep up, but ask some insightful questions.

(Incidentally, I glanced at LibreOffice tonight as well.  I saw immediately that I’d have fundamentally the same problems:  unfamiliar UI and lots of context switching.  Too much to really listen to what the instructor’s saying.)

How does a computer compete with pen & paper?

Later tonight, I realized, if it only takes five quick, essentially subconscious penstrokes to draw Ai, and a fair bit of training to teach someone the equivalent keystrokes in an editor… then maybe a keyboard and mouse are the wrong tools to give a student.  Maybe something closer to pen & paper is best for quickly jotting down something, and then translating it to markup later… which sounds like character recognition.

Hmm, isn’t that something digital tablets and styluses are somewhat good at?  Maybe not perfect, but easier for a human to work with than a memorized set of keystrokes.

Now, I am starting to understand why computer manufacturers (and Firefox OS developers) are putting so much effort into supporting touchscreens:  because they’re useful for taking notes, at least.  Once again, I’ve somewhat missed the boat.

How does this impact my editor project?

The good news is this is way too complicated for me to even attempt in my proof-of-concept editor that I’m trying to build.  (The proof of concept is about making each XML language an add-on to the core editor.)

The bad news is if I ever want students to regularly use computers in a mathematics classroom (which is the raison d’être I even started working with computers as a child), I’m going to need to support tablet computers and styluses.  That’s a whole can of worms I’m not even remotely prepared to look at.  This raises the bar extremely high.  I’m writing this blog post mainly for myself as a future reference, but it means I’ve just discovered a Very Hard Problem is really a Much, Much Harder Problem than I ever imagined.

Categorieën: Mozilla-nl planet

Paul Rouget: Firefox OS: Upgrading ZTE Open C

di, 07/10/2014 - 02:00
How to upgrade a ZTE Open C (French/Europe/US versions)

I use Windows for part 1 (required), and Linux or Mac for part 2. I never tried part 2 with Windows.

Before anything: Install ADB and fastboot on your computer.

1. Root the phone (Windows required)

Where did you buy your phone:

With Open_C_upgrade_Tool, flash the ROM. Common issue if it fails:

  • make sure your phone is charged (at least 10%)
  • remove SIM card and sdcard
  • make sure to select the right ROM directory

Normally, now your phone is unlocked. To check, type: "adb shell id". If it says "root", good. If it says "shell", it didn't work. If "adb" doesn't work on Linux, you need to add a udev rule (google: "udev adb").

2. flash the version of Gecko and Gaia you want

The Open C is compatible with Mozilla's reference phone: The Flame. So you just need to download and flash Flame's builds: http://ftp.mozilla.org/pub/mozilla.org/b2g/ (no need to build B2G or Gaia yourself).

At the moment, I recommend Firefox OS 2.1: http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-mozilla-aurora-flame/

Download b2g-34.0a2.en-US.android-arm.tar.gz (gecko) and gaia.zip (gaia).

Download the flash script: https://github.com/Mozilla-TWQA/B2G-flash-tool/blob/master/shallow_flash.sh

On Mac and Cygwin: ./shallow_flash.sh -g gaia.zip -G b2g-XX.XX.en-US.android-arm.tar.gz

On Linux: ./shallow_flash.sh -ggaia.zip -Gb2g-XX.XX.en-US.android-arm.tar.gz

If you want to save your profile, use this tool: https://github.com/Mozilla-TWQA/B2G-flash-tool/blob/master/backup_restore_profile.sh

Categorieën: Mozilla-nl planet

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

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.

Predictions

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.

Conclusion

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

Gervase Markham: New Class of Vulnerability in Perl Web Applications

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:

index.cgi?foo=bar&foo=baz&foo=quux

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:

index.cgi?realname=JRandomUser&realname=login_name&realname=admin@mozilla.com

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, CGI.pm 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

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

ma, 06/10/2014 - 16:38

devfestnantes

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

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
Tue
  • secautomation
  • Update on Firefox OS Release Cadence
  • Cloud Services Security Team Meeting
Wed
  • MWoS team meeting
  • Cloud Services All Hands
Fri
  • 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

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.

Bengali_Screenshots

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

ma, 06/10/2014 - 14:00
Summary

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 bl.ocks.org:

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?

Thanks

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

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

Pagina's