mozilla

Mozilla Nederland LogoDe Nederlandse
Mozilla gemeenschap

Doug Belshaw: Survey: 5 proposals for Web Literacy Map 2.0

Mozilla planet - do, 09/10/2014 - 11:13

We’re currently working on a v2.0 of Mozilla’s Web Literacy Map. From the 38 interviews with stakeholders and community members I’ve identified 21 emerging themes for Web Literacy Map 2.0 as well as some ideas for Webmaker. The canonical home for everything relating to this update can now be found on the Mozilla wiki.

Cat with tail

While there are some decisions that need to be made by paid contributors / staff (e.g. design, combining competencies, wording of skills) there are some that should be made by the wider community. I’ve come up with five proposals in this survey:

http://goo.gl/forms/LKNSNrXCnu

The five proposals are:

  1. I believe the Web Literacy Map should explicitly reference the Mozilla manifesto.
  2. I believe the three strands should be renamed ‘Reading’, ‘Writing’ and ‘Participating’.
  3. I believe the Web Literacy Map should look more like a ‘map’.
  4. I believe that concepts such as ‘Mobile’, ‘Identity’, and ‘Protecting’ should be represented as cross-cutting themes in the Web Literacy Map.
  5. I believe a ‘remix’ button should allow me to remix the Web Literacy Map for my community and context.

Please do take the time to fill in the survey. Any meta feedback should go to @dajbelshaw / doug@mozillafoundation.org.

Categorieën: Mozilla-nl planet

Daniel Stenberg: Coverity scan defect density: 0.00

Mozilla planet - do, 09/10/2014 - 09:14

A couple of days ago I decided to stop slacking and grab this long dangling item in my TODO list: run the coverity scan on a recent curl build again.

Among the static analyzers, coverity does in fact stand out as the very best one I can use. We run clang-analyzer against curl every night and it hasn’t report any problems at all in a while. This time I got almost 50 new issues reported by Coverity.

To put it shortly, a little less than half of them were issues done on purpose: for example we got several reports on ignored return codes we really don’t care about and there were several reports on dead code for code that are conditionally built on other platforms than the one I used to do this with.

But there were a whole range of legitimate issues. Nothing really major popped up but a range of tiny flaws that were good to polish away and smooth out. Clearly this is an exercise worth repeating every now and then.

End result

21 new curl commits that mention Coverity. Coverity now says “defect density: 0.00” for curl and libcurl since it doesn’t report any more flaws. (That’s the number of flaws found per thousand lines of source code.)

Want to see?

I can’t seem to make all the issues publicly accessible, but if you do want to check them out in person just click over to the curl project page at coverity and “request more access” and I’ll grant you view access, no questions asked.

Categorieën: Mozilla-nl planet

Firefox OS Shows Continued Global Growth

Mozilla Blog - do, 09/10/2014 - 09:10
Firefox OS is now available on three continents with 12 smartphones offered by 13 operators in 24 countries. As the only truly open mobile operating system, Firefox OS demonstrates the versatility of the Web as a platform, free of the … Continue reading
Categorieën: Mozilla-nl planet

Eitan Isaacson

Mozilla planet - do, 09/10/2014 - 01:13

An understated feature in desktop Firefox is the option to suppress the text and background colors that content authors choose for us, and instead go with the plain old black on white with a smattering of blue and purple links. In other words, 1994.

Why is this feature great? Because it hands control back to the user and allows people with visual impairments to tweak things just enough to make the web readable.

Somebody once asked on the #accessibility IRC channel why they can’t turn off content colors in Firefox for Android. So it seemed like a good idea to re-introduce that option in the form of an extension. There are a few color related addons in AMO, but I just submitted another one, and you could get it here. This is what the toggle option looks like:

Remove colors option in tools menu

Remove colors option in tools menu

Since the color attribute was introduced, the web has evolved a lot. We really can’t go back to the, naive, monochrome days of the 90s. Many sites use background images and colors in novel ways, and use backgrounds to portray important information. Sometimes disabling page colors will really break things. So once you remove colors from AMO, you get:

AMO with colors removed

Okayish, eh?

As you can see, it isn’t perfect, but it does make the text more readable to some. Having a menu item that doesn’t take too much digging to find will hopfully help folks go back and forth between the two modes and gt the best out of both worlds.


Categorieën: Mozilla-nl planet

Peter Bengtsson: Premailer on Python 3

Mozilla planet - wo, 08/10/2014 - 23:00

Premailer is probably my most successful open source project in recent years. I base that on the fact that 25 different people have committed to it.

Today I merged a monster PR by Michael Jason Smith of OnlineGroups.net.

What it does is basically that it makes premailer work in Python 3, PyPy and Python 2.6. Check out the tox.ini file. Test coverage is still 100%.

If you look at the patch the core of the change is actually surprisingly little. The majority of the "secret sauce" is basically a bunch of import statements which are split by if sys.version_info >= (3, ): and some various minor changes around encoding UTF-8. The rest of the changes are basically test sit-ups.

A really interesting thing that hit us was that the code had assumptions about the order of things. Basically the tests assumed the the order of certain things in the resulting output was predictable even though it was done using a dict. dicts are famously unreliable in terms of the order you get things out and it's meant to be like that and it's a design choice. The reason it worked till now is not only luck but quite amazing.

Anyway, check it out. Now that we have a tox.ini file it should become much easier to run tests which I hope means patches will be better checked as they come in.

Categorieën: Mozilla-nl planet

Mozilla Open Policy & Advocacy Blog: Launching the Ford-Mozilla Open Web Fellows Program, a Global Initiative to Recruit the Heroes of the Open Internet

Mozilla planet - wo, 08/10/2014 - 19:21

{Re-posting from the Mozilla Blog on Sep 30, 2014}

By Mark Surman, Executive Director, Mozilla Foundation; and Darren Walker, President, Ford Foundation

We are at a critical point in the evolution of the Internet. Despite its emergence as an integral part of modern life, the Internet remains a contested space. Far too often, we see its core ethos – a medium where anyone can make anything and share it with anyone – undermined by forces that wish to make it less free and open. In a world in which the future health of the Internet is vital to democratic discourse and a free flow of ideas, we need a band of dedicated Mozilla Advocacyindividuals standing ready to protect it.

That’s why we are joining together today to launch the Ford-Mozilla Open Web Fellows program, a landmark initiative to create a worldwide community of leaders who will advance and protect the free and open Web.

Working in the Open on Core Issues with the World’s Most Innovative Organizations

Ford-Mozilla Fellows will be immersed in projects that create a better understanding of Internet policy issues among civil society, policy makers, and the broader public. Fellows will be technologists, hackers, and makers who work on a range of Internet policy issues, from privacy and security to surveillance and net neutrality. They will create an affirmative agenda and improve coordination across the sector, boosting the overall number of people throughout society (in nonprofit, government, philanthropy, academic and corporate sectors) that protect the Internet. At present, a whole new architecture is emerging at NGOs and in government where a technology lens is vital to achieving results, just as a focus on law and communications were important in building previous capacity. Fellows will be encouraged to work in the open so that they can share their experiences and learnings with others. Around the world, civil society organizations are working under difficult situations to advance social justice and create a thriving digital society where all voices have an opportunity to be heard.

Fellows will serve as technology advisors, mentors and ambassadors to host organizations, helping to better inform the policy discussion. We are thrilled to name the first cohort organizations that will host a Fellow in the first year of the program. They include:

A Call for Fellowship Applicants

Today also marks the official opening of the application window. Beginning immediately, people can apply to be a Ford-Mozilla Open Web Fellow by visiting www.mozilla.org/advocacy. The application deadline is December 31, 2014.

We are looking for emerging leaders who have a passion for influencing and informing the public policies that impact the Internet. Selected Fellows will have a track record of making and contributing to projects and an interest in working with Mozilla, the Ford Foundation, and our host organizations on specific initiatives to advance and protect the free and open Web.

Protecting the Internet

The Internet has the potential to be the greatest global resource in the history of the world, accessible to and shaped by all people. It has the promise to be the first medium in which anyone can make anything, and share it with anyone. In many ways, it already has helped bend the arc of history towards enlightenment and justice.

But continuing in that direction isn’t guaranteed without help. For all the good that can come from the Internet, in some areas it is already being used to weaken society and concentrate power in the hands of the few, and to shut down democratic discourse. The fight over preserving net neutrality in the U.S.; the debate over governments undermining the Internet to further surveillance efforts; the curtailing of speech and access to the Internet by authoritarian regimes — these are all threats to the Internet and to civil rights.

We need to take up the challenge to prevent this from happening. We must support the heroes – the developers, advocates and people who are fighting to protect and advance the free and open Internet. We must train the next generation of leaders in the promise and pitfalls of technology. We need to build alliances and infrastructure to bridge technology policy and social policy.

The Ford-Mozilla Open Web Fellows program is an effort to find and support the emerging leaders in the fight to protect the free and open Internet. Apply to become a Ford-Mozilla Fellow and tell us how you would stand up to protect and advance the Web to continue the effort to bend the arc toward justice.

Categorieën: Mozilla-nl planet

Jeff Walden: Holt v. Hobbs: Is a prisoner’s 1/2″ beard so dangerous that he can’t have it even if his religion requires it?

Mozilla planet - wo, 08/10/2014 - 18:17

Now the second, final argument this trip. (There are other arguments this week, some interesting enough to attend. But I ran out of time to prepare for them or attend them.) Holt v. Hobbs is much simpler than Heien v. North Carolina, because one side’s arguments are “almost preposterous”. So this post is (slightly) breezier.

This line was a bit different from the Heien line: more people attending for (this) argument, fewer people present simply for opening day. The line was possibly less talkative (and I still had briefs to read, although I never intended to read all twenty-one [!] of them), but there were still good discussions with local law students, the author of one of the amicus briefs (which I naturally read standing in line), and others. Good fun again.

49 for Holt v. Hobbs Another day, another line Gregory Holt and his would-be beard

Gregory Holt is a Muslim inmate in the Arkansas prison system. (He actually goes by Abdul Maalik Muhammad now; Gregory Holt is his birth [legal?] name. News stories and legal discussion refer to him as Holt, and in some sense I want this in that corpus, so I use Holt here.) Holt interprets Islamic law to require he have a beard.

Allah’s Messenger said, “Cut the moustaches short and leave the beard (as it is).”

The Translation of the Meanings of Sahih Al-Bukhari ¶ 5893 (Muhammad Muhsin Khan trans., Darussalam Pubs. 1997)

A small request. Reasonable? Quoting the ever-colorful Justice Scalia in oral argument, “Religious beliefs aren’t reasonable. I mean, religious beliefs are categorical. You know, it’s God tells you. It’s not a matter of being reasonable.” Reasonable or not, a beard isn’t an obviously dangerous request like, “My religion requires I carry a broadsword.” And as a conciliatory gesture Holt moderated his request to a half-inch beard.

Sunrise over the Court, with a camera crew and reporter in the foreground No matter how many arguments I go to (this makes ten), the sunrise over the Court will never get old Arkansas: no beards

Arkansas doesn’t permit prisoners to grow beards (except to the natural extent between twice-weekly shaves). There’s an exception for prisoners with medical conditions (typically burn victims), shaving only to 1/4″. But no religious exceptions.

Arkansas’s justifications are three. A beard could hide contraband. A bearded prisoner can shave to disguise himself, hindering rapid identification and perhaps aiding an escape (see The Fugitive). And it’s a hassle measuring half-inch beards on everyone.

The law’s requirements

Twenty-odd years ago, Holt would likely have been out of luck. Turner v. Safley permitted regulations “reasonably related to legitimate penological objectives”. And Justice Scalia’s Employment Division v. Smith says that as a constitutional matter, generally-applicable laws may burden religious exercise, with objectors having no recourse. It’d be an uphill slog getting past the no-beard rule.

But in the mid-1990s to 2000, Congress near-unanimously statutorily protected some exercises of religion, even against generally-applicable laws. (Lest it be thought this was protection specifically, or only, of Christian beliefs: the original motivating case was a Native American group that used a hallucinogen for sacramental purposes.) In particular Congress enacted the Religious Land Use and Institutionalized Persons Act (RLUIPA, usually “ruh-loo-pah”), stating:

No government shall impose a substantial burden on the religious exercise of [a prisoner], even if the burden results from a rule of general applicability, unless the government demonstrates that imposition of the burden on that person—

  1. is in furtherance of a compelling governmental interest; and
  2. is the least restrictive means of furthering that compelling governmental interest
42 U.S.C. § 2000cc-1(a)

And “religious exercise” is later defined as:

The term “religious exercise” includes any exercise of religion, whether or not compelled by, or central to, a system of religious belief.

42 U.S.C. § 2000cc-5(7)(A)

Now, prisons may regulate in pursuit of normal prison aims. But regulations can’t “substantial[ly] burden” a prisoner’s “religious exercise”, regardless how important the exercise is(n’t) in the prisoner’s belief system, even if the regulation is general and doesn’t target religion — unless the government demonstrates the regulation satisfies a “compelling interest” that can’t be addressed less restrictively. This phrasing comes from strict scrutiny: the strongest form of review American courts apply to laws. Unlike the Turner/Smith regime, these requirements have teeth.

19 Almost go-time to advance onto the plaza to receive line numbers Evaluating Arkansas’s no-beard rule applied to Holt

As a threshold matter, Holt must wish to engage in “religious exercise” that is “substantial[ly] burden[ed]“. Once Holt claims the belief, courts won’t second-guess it. They will consider whether the belief is sincere: no opportunistic exception requests for unwarranted benefits. But no one contests the sincerity of Holt’s beliefs. If Holt refuses to be shaved, he’ll suffer various disciplinary actions and bad consequences: “loss of privileges, punitive segregation, punitive work assignments, and loss of good-time credits”. Certainly a substantial burden.

Now Arkansas must demonstrate — with evidence, persuasively — both a compelling interest, and least restrictive means. Put another way, does Arkansas’s regulation pass strict scrutiny?

Arkansas’s claimed interests are “prison safety and security”. But a no-beards rule only marginally advances these goals, and “the government does not have a compelling interest in each marginal percentage point by which its goals are advanced.” Arkansas’s interest must be more specific: an interest specifically in no beards.

It’s hard to say Arkansas has a compelling interest when the rules in forty-odd prison systems nationwide, and various penal code recommendations, either impose no restrictions on beards among prisoners, or would allow Holt his 1/2″ beard. Arkansas is an outlier. And Arkansas’s medical exemption undermines the argument that no beards must apply universally (compelling interests often brook no exceptions). Similarly, Arkansas can’t use the least restrictive means when forty jurisdictions use even less restrictive means.

Arkansas might justify their policy through unique local experience. But Arkansas concedes “no example” of anyone hiding contraband in a beard. (With the “caveat” that “Just because we haven’t found the example doesn’t mean they aren’t there.” A strong argument!) Disguise arguments could be addressed by taking multiple pictures (as other systems do). And measuring the few inmates requesting religious exemptions wouldn’t be much harder than measuring medical-exception beards.

Arkansas could “demonstrate” strict scrutiny is satisfied by providing evidence of evaluation and reasoned rejection of other states’ policies. But Arkansas previously admitted it considered no other systems (eliciting an acerbic suggestion to try “the common practice of picking up the phone to call other prisons”).

Arkansas could argue that Arkansas’s system, that houses many prisoners in barracks and not separate cells, justifies no beards. But such systems exist elsewhere, and no beards applies in Arkansas’s non-barracks prisons.

In short, Arkansas has demonstrated neither a compelling interest, nor least restrictive means, and it has done so presenting no evidence. Ouch.

In lower courts

An obvious question: why must Holt fight this in court if he’s so obviously right? Basically, a few lower courts are giving far too much deference (a word found in legislative history but not in the statute) to the mere assertions of prison officials, without requiring them to “demonstrate” much of anything. The magistrate judge described officials’ claim that Holt might hide something in his half-inch beard as “almost preposterous” — just before deferring to those claims. Courts below the Supreme Court similarly gave too much deference to prison officials’ bare assertions unsupported by any data.

At the Supreme Court

One indicator of lopsidedness here is the brief count, and authors, on each side. Holt has seventeen other briefs on his side, representing a wide variety of interests: Jewish, Christian, Islamic, Hindu, Sikh, American Indian and Hawaiian, former prison wardens, former corrections officials, Americans United for Separation of Church and State (whose brief, incidentally, is interesting but quite surpassed by later events), sociologists, and the United States government (and others). The authors include a who’s-who of religious freedom organizations. Arkansas has one brief on its side: from eighteen states, who don’t defend Arkansas’s policy as much as try to preserve deference as an element to consider (presumably so those states’ prison systems can be run with a freer hand).

The Court accepted this case in unusual circumstances. Holt filed a hand-written petition requesting Supreme Court review, through a special system not requiring him to pay filing fees from non-existent income. Such petitions are almost never accepted. (Holt basically won the lottery. That said, when I read his brief after the case was accepted, the form was unusual, but the discussion and presentation seemed orthodox.) It’s pretty clear the Court accepted this case to lopsidedly, probably unanimously, overturn the Eighth Circuit. The Supreme Court doesn’t take cases to correct errors, but that’s what they’ll do here.

The #12 admission card Number 12 today: slipping back slightly, but as far as I’m concerned this means I had perfect timing Oral argument

The argument questions roughly ran in largely three veins: pondering deference, drawing a line, and almost mocking Arkansas’s arguments. Holt’s counsel faced difficult questions, but not skeptical questions.

Deference

First, what does deference (if it even matters — the term appears only in legislative history, not in the law as enacted) look like in the context of strict scrutiny? These are somewhat contradictions in terms. Yet the Court somehow must make sense of this.

Line-drawing

Second, while beards are easy to decide, other issues (Sikh turbans that actually can conceal things, for example) will require different considerations. How can the Court provide general guidelines to address these situations? The Court doesn’t want to be in the business of reviewing every prison official’s (better-“demonstrated”) decisions. (Scalia bluntly put it this way: “Bear in mind I would not have enacted this statute, but there it is.” Recall he wrote Employment Division v. Smith, shutting off constitutional religious exemptions from generally-applicable laws. Something to remember any time Scalia’s stereotyped as reflexively pro-religion.) But Congress opened up that box, so courts have to live with it.

Almost mocking questions

Arkansas’s position is not easily defended. Not surprisingly, then, questions and comments almost made fun of Arkansas’s position. To the assertion that “Just because we haven’t found the example doesn’t mean they aren’t there”, Justice Breyer replied, “There are a lot of things we’ve never found that might be there and I’ll refrain from mentioning them. You see them on television, a lot of weird programs from time to time.” (Presumably referring to things like Sasquatch, the Loch Ness Monster, Ghost Hunters, and similar.) And later, Justice Alito proposed an alternative means of detecting beard contraband: “Why can’t the prison just…say comb your beard, and if there’s anything in there, if there’s a SIM card in there, or a revolver, or anything else you think ­­can be hidden in a half-inch beard…” (emphases added). Both lines made the audience erupt in laughter.

Post-Holt crowds on the Supreme Court plaza The post-argument crowds, framed by visitor lines Why Arkansas fights

It’s unclear to me why Arkansas is still arguing. They won in lower courts. But once the Court agreed to review the in forma pauperis petition, Arkansas should have folded. The law is too clearly against them, and this Court won’t give them a pass. Arkansans should be outraged that their state is wasting taxpayer money to defend this system. (And on the policy’s merits, outraged at the petty bureaucratic nonsense at best, and bigotry at worst, it represents.)

One plausible, potentially upsetting, explanation is provided by former prison wardens: “Political Considerations May Underlie Prison Officials’ Resistance to Accommodations of Religious Practices.” These wardens had been sued (and lost) in various cases cited in briefing, and they candidly admitted that their positions were partly attributable to “political realities”.

Conclusion

Arkansas will lose. The only remaining question is how. (And as before, if I’ve made any mistakes in this discussion, please point them out.)

Categorieën: Mozilla-nl planet

Doug Belshaw: Playtesting for MozFest

Mozilla planet - 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

Mozilla planet - 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

Mozilla planet - 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

Mozilla planet - 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

Mozilla planet - 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

Mozilla planet - 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)

Mozilla planet - 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

Mozilla planet - 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!

Mozilla planet - 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

Mozilla planet - 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

Bugzilla code critters blab your security sinners, warns Mozilla - Register

Nieuws verzameld via Google - di, 07/10/2014 - 02:14

Ars Technica

Bugzilla code critters blab your security sinners, warns Mozilla
Register
The Mozilla Foundation has warned of a number of recently discovered vulnerabilities in its Bugzilla bug-tracking tool that could give attackers access to sensitive information about software projects. One particularly serious flaw allows attackers to ...
Bugzilla 0-day can reveal 0-day bugs in OSS giants like Mozilla, Red HatArs Technica
Bugzilla Vulnerability Puts Bug Collections in Harm's WayThreatpost
Bugzilla Zero-Day Exposes Zero-Day BugsKrebs on Security

alle 6 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Paul Rouget: Firefox OS: Upgrading ZTE Open C

Mozilla planet - 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?

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.

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

Pagina's