Mozilla Nederland LogoDe Nederlandse

Abonneren op feed Mozilla planet
Planet Mozilla -
Bijgewerkt: 1 uur 42 min geleden

The Mozilla Blog: Mozilla, Caribou Digital Release Report Exploring the Global App Economy

ma, 01/02/2016 - 15:48

Mozilla is a proud supporter of research carried out by Caribou Digital, the UK-based think tank dedicated to building sustainable digital economies in emerging markets. Today, Caribou has released a report exploring the impact of the global app economy and international trade flows in app stores. You can find it here.

The findings highlight the app economy’s unbalanced nature. While smartphones are helping connect billions more to the Web, the effects of the global app economy are not yet well understood. Key findings from our report include:

  • Most developers are located in high-income countries. The geography of where app developers are located is heavily skewed toward the economic powerhouses, with 81% of developers in high-income countries — which are also the most lucrative markets. The United States remains the dominant producer, but East Asia, fueled by China, is growing past Europe.
  • Apps stores are winner-take-all. The nature of the app stores leads to winner-take-all markets, which skews value capture even more heavily toward the U.S. and other top producers. Conversely, even for those lower-income countries that do have a high number of developers — e.g., India — the amount of value capture is disproportionately small to the number of developers participating.
  • The emerging markets are the 1% — meaning, they earn 1% of total app economy revenue. 95% of the estimated value in the app economy is captured by just 10 countries, and 69% of the value is captured by just the top three countries. Excluding China, the 19 countries considered low- or lower-income accounted for only 1% of total worldwide value.
  • Developers in low-income countries struggle to export to the global stage. About one-third of developers in the sample appeared only in their domestic market. But this inability to export to other markets was much more pronounced for developers in low-income countries, where 70% of developers were not able to export, compared to high-income countries, where only 29% of developers were not able to export. For comparison, only 3% of U.S. developers did not export.
  • U.S. developers dominate almost all markets. On average, U.S. apps have 30% of the market across the 37 markets studied, and the U.S. is the dominant producer in every market except for China, Japan, South Korea, and Taiwan.

Mozilla is proud to support Caribou Digital’s research, and the goal of working toward a more inclusive Internet, rich with opportunity for all users. Understanding the effects of the global app economy, and helping to build a more inclusive mobile Web, are key. We invite readers to read the full report here, and Caribou Digital’s blog post here.

Categorieën: Mozilla-nl planet


ma, 01/02/2016 - 15:10

Several members of the QA team attended FOSDEM this year, and gave presentations on a variety of subjects – both the BuddyUp Pilot Project and FxOS Automation were presented. All of the FOSDEM presentations were recorded and will eventually be available online. Mozilla also had a booth, and we had a group of community volunteers who volunteered to sit at the booth and answer questions. There was a VR display as well as some FxOS devices on display.

You can read more about the event here.

Pictures of the event are here.

Categorieën: Mozilla-nl planet

Andrew Sutherland: An email conversation summary visualization

ma, 01/02/2016 - 12:29

We’ve been overhauling the Firefox OS Gaia Email app and its back-end to understand email conversations.  I also created a react.js-based desktop-ish development UI, glodastrophe, that consumes the same back-end.

My first attempt at summaries for glodastrophe was the following:

old summaries; 3 message tidbits

The back-end derives a conversation summary object from all of the messages that make up the conversation whenever any message in the conversation changes.  While there are some things that are always computed (the number of messages in the conversation, whether there are any unread messages, any starred/flagged messages, etc.), the back-end also provides hooks for the front-end to provide application logic to do its own processing to meet its UI needs.

In the case of this conversation summary, the application logic finds the first 3 unread messages in the conversation and stashes their date, author, and extracted snippet (if any) in a list of “tidbits”.  This also is used to determine the height of the conversation summary in the conversation list.  (The virtual list is aware of a quantized coordinate space where each conversation summary object is between 1 and 4 units high in this case.)

While this is interesting because it’s something Thunderbird’s thread pane could not do, it’s not clear that the tidbits are an efficient use of screen real-estate.  At least not when the number of unread messages in the conversation exceeds the 3 we cap the tidbits at.

time-based thread summary visualization

But our app logic can actually do anything it wants.  It could, say, establish the threading relationship of the messages in the conversation to enable us to make a highly dubious visualization of the thread structure in the conversation as well as show the activity in the conversation over time.  Much like the visualization you already saw before you read this sentence.  We can see the rhythm of the conversation.  We can know whether this is a highly active conversation that’s still ongoing, or just that someone has brought back to life.

Here’s the same visualization where we still use the d3 cluster layout but don’t clobber the x-position with our manual-quasi-logarithmic time-based scale:

the visualization without time-based x-positioning

Disclaimer: This visualization is ridiculously impractical in cases where a conversation has only a small number of messages.  But a neat thing is that the application logic could decide to use textual tidbits for small numbers of unread and a cool graph for larger numbers.  The graph’s vertical height could even vary based on the number of messages in the conversation.  Or the visualization could use thread-arcs if you like visualizations but want them based on actual research.

If you’re interested in the moving pieces in the implementation, they’re here:

Categorieën: Mozilla-nl planet

QMO: David Weir: friendly with belief in team work and contribution

ma, 01/02/2016 - 09:00

David Weir has been involved with Mozilla since 2009. He is from Glasgow, Scotland where he has recently graduated from Glasgow Kelvin College with skills in digital media. In his spare time, he volunteers at local organisations that aim to promote the quality of life in Glasgow’s East End community.

David is from Scotland in Europe.

David is from Scotland in Europe.

Hi David! How did you discover the Web?

I used to write letters the old-fashioned way with ink and paper till I got an email address and discovered the Internet. I started going online for stuff like applying for jobs. That’s how I discovered the Web.

How did you hear about Mozilla?

I used Internet Explorer before I found out about Firefox from an advertisement on Facebook.

How and why did you start contributing to Mozilla?

I was a newbie Firefox user and I liked it. As I got to understand it better, I decided to help out other users on live chat. I became a part of SUMO. To date, I’ve answered 39 questions, written 27 documents and earned 3 badges on SUMO.

Have you contributed to any other Mozilla projects in any other way?

I am a community contributor to the QA team. I actively participate in discussions during team meetings, email threads, and IRC. I’ve recently arranged testdays for Windows 10, Windows Nightly 64-bit, Firefox for Android and Firefox for Desktop.

I contribute code to SuMoBot, an IRC bot in Mozilla’s #SuMo IRC channel.

I’m part of Firefox Friends, a team of social-sharers and word-spreaders to promote Firefox. I help run the Mozilla contributor group on Facebook, and I keep an eye out for Mozilla-related news spreading around social channels.

I am a Mozilla Rep and actively recruit Mozillians.

What’s the contribution you’re the most proud of?

I have some disability in the form of visual impairment and autism; my hand-eye co-ordination is not perfect. I help to make the web more accessible for people with disability. I look at Mozilla websites and if I find things like the text is too dark to read, I notify the developers to make fixes for better accessibility. See bugs 721518, 746251, 770248 and 775318.

You belong to the Mozilla UK community. Please tell us more about your community. Is there anything you find particularly interesting or special about it?

The Mozilla UK community consists of a small number of employees and volunteers scattered around the United Kingdom. There is a Community Space in London. Every year in November, community members help to host the Mozilla Festival. Since only a few employees work in the London office, most meetings happen online. You can find us on the #uk IRC channel. Community discussion happens on Discourse.

A recent landmark achievement for the UK community was the rollout of the en-GB locale for Mozilla’s web properties like,,,, and the main Mozilla website, I personally contributed to the (en-GB) localization of See bugs 1190535 and 1188470.

There is a Scottish community within the larger UK community that can download Mozilla products localized in Gaelic language and discuss support issues on the Gaelic language discussion forum Fòram na Gàidhlig.

What advice would you give to someone who is new and interested in contributing to Mozilla?

Mozilla is one of the most friendly communities I have ever volunteered with. The whole staff is behind you.

If you had one word or sentence to describe Mozilla, what would it be?

Lots of stuff happening – get involved!

What exciting things do you envision for you and Mozilla in the future?

A Scottish community space would be nice.

The Mozilla QA and SUMO teams would like to thank David Weir for his contributions over the past 7 years.

David has contributed to the Mozilla project for a few years now. I’ve frequently had the opportunity to interact with him through IRC. We would also get to say “hi!” to him face-to-ace every so often, because he would attend our weekly team meetings throughteleconferencing. I remember he initially started out attending “testdays” where he would help us test new features in Firefox. Later, his collaboration evolved into organizing his own testdays to address issues he identified as problematic. He’s been a very enthusiastic contributor, and he’s never been shy about pointing out when and where we could be doing better for example, in terms of sharing documentation, or any other information that could be helpful to other contributors. He has made a memorable impression on me and enriched my Mozilla experience, and I hope he keeps participating in the project. – Juan Carlos Becerra

Every team at Mozilla would be lucky to have a contributor like David (IRC nick satdav). He’s committed, the first to know about anything new going on in our social contributor community, and always open with ideas for how we can improve our programs. – Elizabeth Hull

Over the last few years satdav has stayed on top of many support and QA issues, often bringing new bugs that affect the user community to developer attention. That’s so helpful! He shows up to a wide range of Firefox meetings and irc channels, and has a good idea of who to ask to get more information on a bug. Because he has a broad and general interest and is not afraid to ask questions, he also sometimes works as a cross team communicator letting people know what’s going on in other meetings or discussions. I think of him as one of those people who in a science fiction future, would be in a spaceship mission control center with 20 monitors, listening on many channels at once. It has been cool to see his enthusiasm on Mozilla projects and to see his knowledge deepen! – Liz Henry

Categorieën: Mozilla-nl planet

Karl Dubost: Testing Google Search On Gecko With Different UA Strings

ma, 01/02/2016 - 08:40

Google is serving very different versions of its services to individual browsers and devices. A bit more than one year ago, I had listed some of the bugs (btw, I need to go through this list again), Firefox was facing when accessing Google properties. Sometimes, we were not served the tier 1 experience that Chrome was receiving. Sometimes it was just completely broken.

We have an open channel of discussions with Google. Google is also not a monolithic organization. Some services have different philosophy with regards to fixing bugs or Web compatibility issues. The good news is that it is improving.

Three Small Important Things About Google Today
  1. mike was looking for usage of -webkit-mask-* CSS property on the Web. I was about to reply "Google search!" which was sending it to Chrome browser but decided to look at the bug again. They were using -webkit-mask-image. To my big surprise, they switched to an SVG icon. Wonderful!
  2. So it was time for me to testing one more time Google Search on Gecko with Firefox Android UA and Chrome UA. See below.
  3. Tantek started some discussion in the CSS Working Group about Web compatibility issues, including one about getting the members of the CSS Working Group to fix their Web properties.
Testing Google Search on Gecko and Blink

For each test, the first two screenshots are on the mobile device itself (Chrome, then Firefox). The third screenshot shows the same site with a Chrome user agent string but as displayed on Gecko on Desktop. Basically, this 3rd one is testing if Google was sending the same version to Firefox on Android that they serve to Chrome, would it work?

Home page

We reached the home page of Google.

home page

Home page - search term results

We typed the word "Japan".

home page with search term

Home page - scrolling down

We scrolled down a bit.

scrolling down the page

Home page - bottom

We reached the bottom of the page.

Bottom of the page

Google Images with the search term

We go back to the top of the page and tap on Images menu.

Accessing Google image

Google Images when image has been tapped

We tap on the first image.

focus on the image


We are not there yet the issue is complex, because of the big number of versions which are served to different browsers/devices, but definitely there is progress. At first sight, the version sent to Chrome is compatible with Firefox. We would need to test with being logged too and all the corner cases of the tools and menus. But it's a lot, lot, better that what it was used to be in the past. We have never been that close from an acceptable user experience.

Categorieën: Mozilla-nl planet

Daniel Stenberg: My HTTP/2 slide updates

ma, 01/02/2016 - 08:39

My first HTTP/2 talk of the year I did for OWASP Stockholm on January 27th, and I subsequently updated my public slide set:

On slideshare here: Http2 I then did a shorter talk at FOSDEM 2016 on January 30th that I called “an HTTP/2 update”. In 25 rushed minutes I presented these slides:

HTTP/2 Update – FOSDEM 2016
Categorieën: Mozilla-nl planet

This Week In Rust: This Week in Rust 116

ma, 01/02/2016 - 06:00

Hello and welcome to another issue of This Week in Rust! Rust is a systems language pursuing the trifecta: safety, concurrency, and speed. This is a weekly summary of its progress and community. Want something mentioned? Tweet us at @ThisWeekInRust or send us an email! Want to get involved? We love contributions.

This Week in Rust is openly developed on GitHub. If you find any errors in this week's issue, please submit a PR.

This week's edition was edited by: nasa42, brson, and llogiq.

Updates from Rust Community News & Blog Posts Notable New Crates & Project Updates Updates from Rust Core

114 pull requests were merged in the last week.

See the triage digest and subteam reports for more details.

Notable changes New Contributors
  • Ali Clark
  • Daan Sprenkels
  • ggomez
  • tgor
  • Thomas Wickham
  • Tomasz Miąsko
  • Vincent Esche
Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

Final Comment Period

Every week the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now. This week's FCPs are:

New RFCs Upcoming Events

If you are running a Rust event please add it to the calendar to get it mentioned here. Email Erick Tryzelaar or Brian Anderson for access.

fn work(on: RustProject) -> Money

Tweet us at @ThisWeekInRust to get your job offers listed here!

Crate of the Week

This week's Crate of the Week is herbie-lint, a miraculous compiler plugin to check the numerical stability of floating-point operations in the code. Another reason to have a nightly Rust handy.

Thanks to redditor protestor for the suggestion.

Submit your suggestions for next week!

Quote of the Week

imo: the opinionated version of mio

durka42 on #rust

Thanks to Steve Klabnik for the suggestion.

Submit your quotes for next week!

Categorieën: Mozilla-nl planet

Daniel Stenberg:, HTTPS and h2

ma, 01/02/2016 - 00:03

I previously mentioned my slow-moving plan to get all my sites and servers onto HTTPS and HTTP/2. As of now, I’ve started to activate HTTPS for sites that run on our server and that I admin. First out in the list of sites are this host ( and the curl web site ( There are plenty more to setup but the plan is to have the most important ones on HTTPS really soon.

If you experience problems with any of these, let me know. The long-term plan involves going HTTPS-only for all of them.

Categorieën: Mozilla-nl planet

Ludovic Hirlimann: Fosdem 2016 day 2

zo, 31/01/2016 - 23:22

Day 2 was a bit different than day 1, has I was less tired. It started by me visiting a few booths in order to decorate my bag and get a few more T-shirts, thanks to wiki-mania, Apache, Open Stack. I got the mini-port to VGA cable I had left in the conference room and then  headed for the conferences.

The first one was “Active supervision and monitoring with Salt, Graphite and Grafana“ was interesting because I knew nothing about any of these, except for graphite, but I knew so little that I learned a lot.

The second one titled “War Story: Puppet in a Traditional Enterprise” was someone implementing puppet at an enterprise scale in a big company. It reminded me all the big company I had consulted to a few years back - nothing surprising. It was quiet interesting anyway.

The Third talk I attend was about hardening and securing configuration management software. It was more about general principle than an howto. Quite interesting specially the link given at the end of the documentation and the idea to remove ssh if possible on all servers and enable it thru conf. management to investigate issues. I didn’t learn much but it was a good refresher.

I then attend a talk in a very small room that was packed packed packed , about mapping with your phone. As I’ve started contributing to OSM, it was nice to listen and discover all the other apps that I can run on my droid phone in order to add data to the maps. I’ll probably share that next month at the local OSM meeting that got announced this week-end.

Last but not least I attended the key signing party. According to my paperwork, I’ll have sot sign twice 98 keys (twice because I’m creating a new key).

I’ve of course added a few pictures to my Fosdem set.

Categorieën: Mozilla-nl planet

Kartikaya Gupta: Frameworks vs libraries (or: process shifts at Mozilla)

zo, 31/01/2016 - 19:26

At some point in the past, I learned about the difference between frameworks and libraries, and it struck me as a really important conceptual distinction that extends far beyond just software. It's really a distinction in process, and that applies everywhere.

The fundamental difference between frameworks and libraries is that when dealing with a framework, the framework provides the structure, and you have to fill in specific bits to make it apply to what you are doing. With a library, however, you are provided with a set of functionality, and you invoke the library to help you get the job done.

It may not seem like a very big distinction at first, but it has a huge impact on various properties of the final product. For example, a framework is easier to use if what you are trying to do lines up with the goal the framework is intended to accomplish. The only thing you need to do is provide (or override) specific things that you need to customize, and the framework takes care of the rest. It's like a builder building your house, and you picking which tile pattern you want for the backsplash. With libraries there's a lot more work - you have a Home Depot full of tools and supplies, but you have to figure out how to put them together to build a house yourself.

The flip side, of course, is that with libraries you get a lot more freedom and customizability than you do with frameworks. With the house analogy, a builder won't add an extra floor for your house if it doesn't fit with their pre-defined floorplans for the subdivision. If you're building it yourself, though, you can do whatever you want.

The library approach makes the final workflow a lot more adaptable when faced with new situations. Once you are in a workflow dictated by a framework, it's very hard to change the workflow because you have almost no control over it - you only have as much control as it was designed to let you have. With libraries you can drop a library here, pick up another one there, and evolve your workflow incrementally, because you can use them however you want.

In the context of building code, the *nix toolchain (a pile of command-line tools that do very specific things) is a great example of the library approach - it's very adaptable as you can swap out commands for other commands to do what you need. An IDE, on the other hand, is more of a framework. It's easier to get started because the heavy lifting is taken care of, all you have to do is "insert code here". But if you want to do some special processing of the code that the IDE doesn't allow, you're out of luck.

An interesting thing to note is that usually people start with frameworks and move towards libraries as their needs get more complex and they need to customize their workflow more. It's not often that people go the other way, because once you've already spent the effort to build a customized workflow it's hard to justify throwing the freedom away and locking yourself down. But that's what it feels like we are doing at Mozilla - sometimes on purpose, and sometimes unintentionally, without realizing we are putting on a straitjacket.

The shift from Bugzilla/Splinter to MozReview is one example of this. Going from a customizable, flexible tool (attachments with flags) to a unified review process (push to MozReview) is a shift from libraries to frameworks. It forces people to conform to the workflow which the framework assumes, and for people used to their own customized, library-assisted workflow, that's a very hard transition. Another example of a shift from libraries to frameworks is the bug triage process that was announced recently.

I think in both of these cases the end goal is desirable and worth working towards, but we should realize that it entails (by definition) making things less flexible and adaptable. In theory the only workflows that we eliminate are the "undesirable" ones, e.g. a triage process that drops bugs on the floor, or a review process that makes patch context hard to access. In practice, though, other workflows - both legitimate workflows currently being used and potential improved workflows get eliminated as well.

Of course, things aren't all as black-and-white as I might have made them seem. As always, the specific context/situation matters a lot, and it's always a tradeoff between different goals - in the end there's no one-size-fits-all and the decision is something that needs careful consideration.

Categorieën: Mozilla-nl planet

Marcia Knous: Firefox OS QA at FOSDEM 2016

zo, 31/01/2016 - 19:19
Despite the fact I have been around the Mozilla project for some time, I never did get the opportunity to attend the FOSDEM conference. This year I was fortunate enough to not only attend, but also to present along with Ioana Chiorean at FOSDEM in the Mozilla Developer Room. And I was in good company: Johan Lorenzo and Martijn Wargers of the QA team also presented a great Automation Session on Saturday.    Martijn Wargers and Johan Lorenzo presenting at FOSDEM 2016   There were several things
Categorieën: Mozilla-nl planet

Ludovic Hirlimann: Fosdem 2016 day 1

za, 30/01/2016 - 16:58

This year I’m attending fosdem, after skipping it last year. It’s good to be back even if I was very tired when I arrived yesterday night and managed to visit three of Brussels train station. I was up early and the indications in bus 71 where fucked up so it took me a short walk under some rain to get to the campus - but I made it early and was able to take interesting empty pictures.

The first talk I attended was about MIPS for the embedded world. It was interesting for some tidbids, but felt more like a marketing speech to use MIPS on future embedding project.

After that I wanders and found a bunch of ex-joosters and had very interesting conversation with all of them.

I delivered my talk in 10 minutes and then answered question for the next 20 minutes.

The http2 talk was interesting and the room was packed. But probably not deep enough for me. Still I think we should think about enabling http/2 on

I left to get some rest after talking to otto about block chain and bitcoins.

Categorieën: Mozilla-nl planet

Mike Hommey: Enabling TLS on this blog

za, 30/01/2016 - 07:22

Long overdue, I finally enabled TLS on this blog. It went almost like a breeze.

I used simp_le to get the certificate from Let’s Encrypt, along Mozilla’s Web Server Configuration generator. SSL Labs now reports a rating of A+.

I just had a few issues:

  • I had some hard-coded http:// links in my wordpress theme, that needed changes,
  • Since my wordpress instance is reverse-proxied and the real server not behind HTTPS, I had to adjust the wordpress configuration so that it doesn’t do an infinite redirect loop,
  • Nginx’s config for multiple virtualhosts needs SSL configuration to be repeated. Fortunately, one can use include statements,
  • Contrary to the suggested configuration, setting ssl_session_tickets off; makes browsers unhappy (at least, it made my Firefox unhappy, with a SSL_ERROR_RX_UNEXPECTED_NEW_SESSION_TICKET error message).

I’m glad that there are tools helping to get a proper configuration of SSL. It is sad, though, that the defaults are not better and that we still need to tweak at all. Setting where the certificate and the private key files are should, in 2016, be the only thing to do to have a secure web server.

Categorieën: Mozilla-nl planet

Chris Cooper: RelEng & RelOps Weekly Highlights - January 29, 2016

vr, 29/01/2016 - 23:10

Well, that was a quick month! Time flies when you’re having fun…or something.

Modernize infrastructure:

In an effort to be more agile in creating and/or migrating webapps, Releng has a new domain name and SSL wildcard! The new domain ( is setup for management under inventory and an ssl endpoint has been established in Heroku. See

Improve CI pipeline:

Coop (hey, that’s me!) re-enabled partner repacks as part of release automation this week, and was happy to see the partner repacks for the Firefox 44 release get generated and published without any manual intervention. Back in August, we moved the partner repack process and configuration into github from mercurial. This made it trivially easy for Mozilla partners to issue a pull request (PR) when a configuration change was needed. This did require some re-tooling on the automation side, and we took the opportunity to fix and update a lot of partner-related cruft, including moving the repack hosting to S3. I should note that the EME-free repacks are also generated automatically now as part of this process, so those of you who prefer less DRM with your Firefox can now also get your builds on a regular basis.


One of the main reasons why build promotion is so important for releng and Mozilla is that it removes the current disconnect between the nightly/aurora and beta/release build processes, the builds for which are created in different ways. This is one of the reasons why uplift cycles are so frequently “interesting” - build process changes on nightly and aurora don’t often have an existing analog in beta/release. And so it was this past Tuesday when releng started the beta1 process for Firefox 45. We quickly hit a blocker issue related to gtk3 support that prevented us from even running the initial source builder, a prerequisite for the rest of the release process. Nick, Rail, Callek, and Jordan put their heads together and quickly came up with an elegant solution that unblocked progress on all the affected branches, including ESR. In the end, the solution involved running tooltool from within a mock environment, rather than running it outside the mock environment and trying to copy relevant pieces in. Thanks for the quick thinking and extra effort to get this unblocked. Maybe the next beta1 cycle won’t suck quite as much! The patch that Nick prepared ( is now in production and being used to notify users on unsupported versions of GTK why they can’t update. In the past, they would’ve simply received no update with no information as to why.


Dustin made security improvements to TaskCluster, ensuring that expired credentials are not honored.

We had a brief Balrog outage this morning [Fri Jan 29]. Balrog is the server side component of the update system used by Firefox and other Mozilla products. Ben quickly tracked the problem down to a change in the caching code. Big thanks to mlankford, Usul, and w0ts0n from the MOC for their quick communication and help in getting things back to a good state quickly.


On Wednesday, Dustin spoke at Siena College, holding an information session on Google Summer of Code and speaking to a Software Engineering class about Mozilla, open source, and software engineering in the real world.

See you next week!

Categorieën: Mozilla-nl planet

Air Mozilla: Foundation Demos January 29 2016

vr, 29/01/2016 - 19:00

Foundation Demos January 29 2016 Mozilla Foundation Demos January 29 2016

Categorieën: Mozilla-nl planet

Yunier José Sosa Vázquez: Visualizando lo invisible

vr, 29/01/2016 - 14:46

Esta es una traducción del artículo original publicado en el blog The Mozilla Blog. Escrito por Jascha Kaykas-Wolff .

Hoy en día, la privacidad y las amenazas como el seguimiento invisible de terceros en la Web en línea parecen ser muy abstractas. Muchos de nosotros no somos conscientes de lo que está pasando con nuestros datos en línea o nos sentimos impotentes porque no sabemos qué hacer. Cada vez más, Internet se está convirtiendo en una casa de cristal gigante donde tu información personal está expuesta a terceros que la recogen y utilizan para sus propios fines.

Recientemente hemos lanzado Navegación privada con la protección de seguimiento en Firefox – una característica que se centra en proporcionar a cualquier persona que utilice Firefox una elección significativa frente a terceros en la Web que podrían recolectar sus datos sin su conocimiento o control. Esta es una característica que se ocupa de la necesidad de un mayor control sobre la privacidad en línea, pero también está conectada a un debate permanente e importante en torno a la preservación de un ecosistema Web sano, abierto y sostenible y los problemas y las posibles soluciones a la pregunta sobre los contenidos bloqueados.

La casa de cristal

A principios de este mes nos dedicamos a un evento de tres días sobre la privacidad en línea en Hamburgo, Alemania. Hoy en día, nos gustaría compartir algunas impresiones del evento y también un experimento que filmamos en la famosa calle Reeperbahn.

¿Nuestro experimento?

Nos dispusimos a ver si podíamos explicar algo que no es fácilmente visible, la privacidad en línea, de una manera muy tangible. Hemos construido un apartamento totalmente equipado con todo lo necesario para disfrutar de un corto viaje a la perla del norte de Alemania. Hicimos el apartamento a disposición de los diferentes viajeros que llegan a pasar la noche. Una vez que se conectaron a Wi-Fi de la vivienda, se eliminaron todas las paredes, dejando al descubierto los viajeros a los espectadores y la conmoción externa causados ​​cuando su información privada resultó ser pública.

Las respuestas de los viajeros ante lo que les sucede resultan impactantes.

En video: mira lo que sucede con nuestros datos

Dicho esto, nos ayudamos con algunos actores para realzar con más dramatismo una referencia no tan sutil de lo que le puede pasar a sus datos cuando usted no está prestando atención. ¡Bienvenido a la casa de cristal!

Desde Mozilla Hispano instamos a todos los lectores a que sepan que son usuarios que deben de informarse para poder reflexionar sobre lo que ocurre cuando ingresan a la Web. Tomar el control requiere de tener herramientas e información, y para lograr ésto los usuarios deben de volverse autogestivos, sujetos conscientes de la realidad que viven dentro del entorno que circundan para poder tomar cartas en el asunto.

Mientras que los resultados del experimento pretenden educar y generar conciencia, también capturamos pensamientos y sentimientos de los participantes después de la intervención. Estas son algunas de las reacciones más conmovedoras:

 Lars Reppesgaard (Autor, "El Imperio Google"), Svenja Teichmann (crowdmedia), Federico Richter (Presidente de la Fundación de Protección de Datos de Alemania) y Winston Bowden (Sr. Gerente de Marketing de Producto de Firefox)

De izquierda a derecha: Lars Reppesgaard (Autor, “El Imperio Google”), Svenja Teichmann (crowdmedia), Federico Richter (Presidente de la Fundación de Protección de Datos de Alemania) y Winston Bowden (Sr. Gerente de Marketing de Producto de Firefox)

Discutiendo el Estado de control de datos en la Web hoy

En los dos días que le siguieron a la intervención, en la misma casa de vidrio, expertos en privacidad y tecnología alemana, el grupo Digital Media Women de Hamburgo, la comunidad Mozilla y personas interesadas en el tema de la privacidad en línea se reunieron para discutir el “Estado de los datos y control en la Web”.

Empezamos con una mesa redonda. Moderada por Svenja Teichmann, fundador y director general de crowdmedia (actualmente Sequel) y expertos en protección de datos alemanes. La protección de la privacidad en línea y preguntas como “¿Qué es privado hoy en día?” fueron los temas que se debatieron mientras que los transeúntes podían mirar a través de las paredes de cristal.

Federico Richter señaló la incertidumbre del usuario: “En la web no nos damos cuenta de qué nos está viendo. Y muchas personas no pueden proteger su privacidad en línea, ya que no tienen características fáciles de usar”– Lars Reppesgaard no está completamente en contra del rastreo por Internet pero piensa que los usuarios deben tener una opción. “Si desea que la tecnología lo ayude, es necesario que la misma recoja algunos datos a veces. Pero para la mayoría de los usuarios no es obvio cuando y por quién se realiza éste seguimiento”. Sobre la nueva función de seguimiento de protección en la navegación privada en Firefox, Winston Bowden enfatizó:

“No somos un enemigo de la publicidad en línea. Es una fuente legítima de ingresos y garantiza el contenido altamente emocionante en la Web. Pero si el seguimiento de los usuarios es sin que ellos lo sepan o aún, cuando estén en contra, este tipo de rastreo no va a funcionar. La web abierta y libre es un activo valioso, que debemos proteger. Los usuarios tienen que tener el control de sus datos”.

Educación y Participación

Por último, los miembros de la comunidad Mozilla alemanes se unieron al evento para informar y educar a la gente sobre cómo Firefox puede ayudar a los usuarios a obtener el control sobre su experiencia en línea. Explicaron el fondo y la génesis de la Protección contra rastreo, pero también mostraron herramientas como Lightbeam y hablaron de Smart On Privacy y sobre Web Literacy, con la intención de ofrecer puntos de referencia para tener un mayor conocimiento de cómo funciona la Web.


Gracias a todos los que trabajaron detrás de las escenas y/o vinieron a Hamburgo e hicieron lo posible para que este evento funcionara. Apreciamos su ayuda en pos de educar y abogar para que la gente sepa acerca de su elección y control sobre la privacidad en línea.

Por último, si te interesa el tema puedes compartir este artículo en tus redes sociales para que todos estén al tanto de lo que pasa. Así podrás unirte al mes de la privacidad.

Fuente: Mozilla Hispano

Categorieën: Mozilla-nl planet

Daniel Glazman: Google, and blacklists

vr, 29/01/2016 - 09:36

Several painful things happened to yesterday... In chronological order:

  1. during my morning, two users reported that their browser did not let them reach the downloads section of without a security warning. I could not see it myself from here, whatever the browser or the platform.
  2. during the evening, I could see the warning using Chrome on OS X
  3. apparently, and if I believe the "Search Console", Google thought two files in my web repository of releases are infected. I launched a complete verification of the whole web site and ran all the software releases through three anti-virus systems (Sophos, Avast and AVG) and an anti-adware system. Nothing at all to report. No infection, no malware, no adware, nothing.
  4. since this was my only option, I deleted the two reported files from my server. Just for the record, the timestamps were unchanged, and I even verified the files were precisely the ones I uploaded in january and april 2012. Yes, 2012... Yesterday, without being touched/modified in any manner during the last four years, they were erroneously reported infected.
  5. this morning, Firefox also reports a security warning on most large sections of and its Downloads section. I guess Firefox is also using the Google blacklist. Just for the record, both Spamhaus and CBL have nothing to say about
  6. the Google Search Console now reports my site is ok but Firefox still reports it unsecure, ahem.

I need to draw a few conclusions here:

  • Google does not tell you how the reported files are unsecure, which is really lame. The online tool they provide to "analyze" a web site did not help at all.
  • Since all my antivir/antiadware declared all files in my repo clean, I had absolutely no option but to delete the files that are now missing from my repo
  • two reported files in and led to blacklisting of all of and that's hundreds of files... Hey guys, we are and you are programmers, right? Sure you can do better than that?
  • during more than one day, customers fled from because of these security warnings, security warnings I consider as fake reports. Since no public antimalware app could find anything to say about my files, I am suspecting a fake report of human origin. How such a report can reach the blacklist when files are reported safe by four up-to-date antimalware apps and w/o infection information reported to the webmaster is far beyond my understanding.
  • blacklists are a tool that can be harmful to businesses if they're not well managed.

Update: oh I and forgot one thing: during the evening, blacklisted one of the Mail Transport Agents of Dreamhost. Not, my email address, that whole SMTP gateway at Dreamhost... So all my emails to one of my customers bounced and I can't even let her know some crucial information. I suppose thousands at Dreamhost are impacted. I reported the issue to both Earthlink and DH, of course.

Categorieën: Mozilla-nl planet

Karl Dubost: [worklog] APZ bugs, Some webcompat bugs and HTTP Refresh

vr, 29/01/2016 - 09:15

Monday, January 25, 2016. It's morning in Japan. The office room temperature is around 3°C (37.4F). I just put on the Aladdin. The sleep was short or more exactly interrupted a couple of times. Let's go through emails after two weeks away.

My tune for WebCompat for this first quarter 2016 is Jurassic 5 - Quality Control.

MFA (Multi Factor Authentication)

Multi Factor Authentication in the computing industry is sold as something easier and more secure. I still have to be convinced about the easier part.

WebCompat Bugs
  • Bugzilla Activity
  • Github Activity
  • In Bug 1239922, Google Docs is sending HiRes icons only to WebKit devices because of a mediaqueries @media screen and (-webkit-min-device-pixel-ratio:2) {} in the CSS. One difference is that the images are set through content outside of the mediaquery on a pseudo-element, but inside directly on the element itself. It is currently a non-standard feature as explained by Daniel Holbert. We contacted them. A discussion has been started and the magical Daniel dived a bit more in the issue. Read it.
  • Google Search seems to have ditched the opensearch link in the HTML head. As a result, users have more difficult to add the search for specific locales. Contacted.
  • Google Custom Search is not sending the same search results links to Firefox Desktop and iOS9 on one side than Firefox Android. Firefox Android receives instead of This is unfortunate because is a 404.
  • DeKlab is sending some resources (a template for Dojo) with a bogus BOM. Firefox is stricter than Chrome on this and rejects the document, which in return breaks the application. Being stricter is cool and the site should be contacted, but at the same time, the pressure of it working in Chrome makes it harder to convince devs.
  • When creating a set of images for srcset, make absolutely sure that your images are actually on the server.
  • Some bugs are harder to test than others. is not accessible from Japan. Maybe it's working from USA. If someone can test for us.
  • When mixing em and px in a design you always risk that the fonts and rounding of values will not be exactly the same in all browsers.
  • There is an interesting bug with Font being truncated on twitter differently on linux and other platforms and this depending on the fonts. Boris Zbarsky suspect that twitter plays somehow with the font. I started to dig to extract more information.
  • Strange issue on a 360 video not playing in IceWeasel. This seems related specifically to the Debian version.
  • Some of the bugs we had with Japanese Web sites are being fixed, silently as usual. Once we reached out, not always the person will tell us back, hey we deployed a fix.
  • A developer is working on a Web site and he feels the need because of a performance, feature issue to create a script to block a specific user-agent string. Time passes. We analyze. Find the contact information given on the site. Try to contact and don't get any answers. We try to contact again this time on twitter. And the person replies that he is not working anymore there so can't fix the user agent sniffing. Apart of the frustration that it creates, you can see how user agent sniffing strategy is broken, it doesn't take evolution of implementations and human changes in consideration. User agent sniffing may work but it is a very high maintenance choice with consequences on a long term. It's not a zero cost.
APZ Bugs

There's a list of scrolling bugs which affects Firefox. The issue is documented on MDN.

These effects work well in browsers where the scrolling is done synchronously on the browser's main thread. However, most browsers now support some sort of asynchronous scrolling in order to provide a consistent 60 frames per second experience to the user. In the asynchronous scrolling model, the visual scroll position is updated in the compositor thread and is visible to the user before the scroll event is updated in the DOM and fired on the main thread. This means that the effects implemented will lag a little bit behind what the user sees the scroll position to be. This can cause the effect to be laggy, janky, or jittery — in short, something we want to avoid.

So if you know someone (or a friend of a friend) who is able to fix or put us in contact with one of these APZ bugs site owners, please tell us in the bugs comments or on IRC (#webcompat on I did a first pass at bugs triage for contacting the site.

Some of these bugs are not mature yet in terms of outreach status. With Addons/e10s and APZ, it might happen more often that the Web Compat team is contacted for reaching out the sites which have quirks, specific code hindering Firefox, etc. But to reach out a Web site requires first a couple of steps and understanding. I need to write something about this. Added to my TODO list.

Addons e10s

Difficult to make progress in some cases, because the developers have completely disappeared. I wonder in some cases if it would not just be better to complete remove it from the addons list. It would both give the chance to someone else to propose something if needed by users (nature doesn't like void) or/and the main developer to wake up and wonder why the addon is not downloadable anymore.

Webcompat Life

We had a We discuss about APZ, WebCompat wiki, Firefox OS Tier3 and WebkitCSS bugs status.

Pile of mails
  • Around 1000 emails after 2 weeks, this is not too bad. I dealt in priority with those where my email address is directly in the To: field (dynamic mailbox), then the ones where I'm in needinfo in Bugzilla, then finally the ones which are addressed to specific mailing-lists I have work to do. The rest, rapid scann of the topics (Good email topics are important. Remember!) and marking as read all the ones that I don't have any interests. I'm almost done in one day with all these emails.
  • explain what is necessary to consider a bug "ready for outreach".
  • check the webkitcss bugs we had in Bugzilla and
  • check if the bugs still open about Firefox OS are happening on Firefox Android
  • testing Google search properties and see if we can find a version which is working better on Firefox Android than the current default version sent by Google. Maybe testing with Chrome UA and Iphone UA.


Categorieën: Mozilla-nl planet

Andy McKay: Why I closed your bug

vr, 29/01/2016 - 09:00

Because I'm mean. Well not really, but I understand how it can feel that way.

Web sites at Mozilla have a unique advantage in that they are open source. That is great for development and contributions. Although the number of contributions tends to be lower than for Firefox and other projects [1].

Just like Firefox anyone can file a bug and anyone can send in a patch. Which is truly awesome and for the last 10+ years AMO has had some excellent contributors as well as paid staff help it out. Except for a few basic problems:

  • There are always new features, new edge cases, new problems to be solved.

  • Each new feature spawns new bugs.

  • Each new feature interacts with other features to become more and more complex.

  • The number of bugs on the site grows to overwhelming proportions given time.

  • The maintenance burden grows and grows until no new features can be added without getting more resources.

This is probably a familiar cycle to many. In open source projects you can fork and take your project off in a different direction. In the case of AMO though you really can't in that there's only one such site for Firefox.

And there in we get to the dilemma. At Mozilla we've gone through various phases of support for AMO from paid contributors: from lots of developers, to none, to one, to lots of developers.

The one continual theme in all of them, the number of features and bugs just keeps growing and to get more done we need more and more people.

So let's return to that bug you've filed asking for something on AMO. We'll think quite unsurprisingly of things like:

  • Will it add complexity or remove it?

  • What are the long term maintenance and security issues?

  • Will it be used?

...that shouldn't be too much of a surprise. But that might mean that we won't take that bug, or pull request, and then you'll think we are mean.

In the past I've seen bugs triaged to be "P5 Enhancement" (or maybe even "good first bug" or "patches welcome"), this is just a cop out. Basically we don't want to work on this so we are going to ignore it, we know that you don't really want to work on the feature either and it sits in limbo. I'd rather be up front and close it.

The only way we can make a site like AMO maintainable is by keeping the complexity and feature set down. After all, there's a lot of work to be done around add-ons, the more we can keep the complex things simple, the more we can do.

[1] Citation needed.

Categorieën: Mozilla-nl planet

Ehsan Akhgari: Building Firefox With clang-cl: A Status Update

vr, 29/01/2016 - 05:46

Last June, I wrote about enabling building Firefox with clang-cl.  We didn’t get these builds up on the infrastructure and things regressed on both the Mozilla and LLVM side, and we got to a state where clang-cl either wouldn’t compile Firefox any more, or the resulting build would be severely broken.  It took us months but earlier today we finally managed to finally get a full x86-64 Firefox build with clang-cl!  The build works for basic browsing (except that it crashes on for reasons we haven’t diagnosed yet) and just for extra fun, I ran all of our service worker tests (which I happen to run many times a day on other platforms) and they all passed.

This time, we got to an impressive milestone.  Previously, we were building Firefox with the help of clang-cl’s fallback mode (which falls back to MSVC when clang fails to build a file for whatever reason) but this time we have a build of Firefox that is fully produced with clang, without even using the MSVC compiler once.  And that includes all of our C++ tests too.  (Note that we still use the rest of the Microsoft toolchain, such as the linker, resource compiler, etc. to produce the ultimate binaries; I’m only focusing on C and C++ compilation in this post.)

We should now try to keep these builds working.  I believe that this is a big opportunity for Firefox to be able to leverage the modern toolchain that we have been enjoying on other platforms on Windows, where we have most of our users.  An open source compilation toolchain has long been needed on Windows, and clang-cl is the first open source replacement that is designed to be a drop-in replacement for MSVC, and that makes it an ideal target for Firefox.  Also, Microsoft’s recent integration of clang as a front-end for the MSVC code generator promises the prospects of switching to clang/C2 in the future as our default compiler on Windows (assuming that the performance of our clang-cl builds don’t end up being on par with the MSVC PGO compiler.)

My next priority for this project would be to stand up Windows static analysis builds on TreeHerder.  That requires getting our clang-plugin to work on Windows, fixing the issues that it may find (since that would be the first time we would be running our static analyses on Windows!), and trying to get them up and running on TaskCluster.  That way we would be able to leverage our static analysis on Windows as the first fruit of this effort, and also keep these builds working in the future.  Since clang-cl is still being heavily developed, we will be preparing periodic updates to the compiler, potentially fixing the issues that may have been uncovered in either Firefox or LLVM and therefore we will keep up with the development in both projects.

Some of the future things that I think we should look into, sorted by priority:

  • Get DXR to work on Windows.  Once we port our static analysis clang plugin to Windows, the next logical step would be to get the DXR indexer clang plugin to work on Windows, so that we can get a DXR that works for Windows specific code too.
  • Look into getting these builds to pass our test suites.  So far we are at a stage where clang-cl can understand all of our C and C++ code on Windows, but the generated code is still not completely correct.  Right now we’re at such an early stage that one can find crashes etc within minutes of browsing.  But we need to get all of our tests to pass in these builds in order to get a rock-solid browser built with clang-cl.  This will also help the clang-cl project, since we have been reporting clang-cl bugs that the Firefox code has continually uncovered, and on occasions also fixes to those bugs.  Although the rate of the LLVM side issues has decreased dramatically as the compiler has matured, I expect to find LLVM bugs occasionally, and hope to continue to work with the LLVM project to resolve them.
  • Get the clang-based sanitizers to work on Windows, to extend their coverage to Windows.  This includes things such as AddressSanitizer, ThreadSanitizer, LeakSanitizer, etc.  The security team has been asking for AddressSanitizer for a long time.  We could definitely benefit from the Windows specific coverage of all of these tools.  Obviously the first step is to get a solid build that works.  We have previously attempted to use AddressSanitizer on Windows but we have run into a lot of AddressSanitizer specific issues that we had to fix on both sides.  These efforts have been halted for a while since we have been focusing on getting the basic compilation to work again.
  • Start to do hybrid builds, where we randomly pick either clang-cl or MSVC o build each individual file.  This is required to improve clang-cl’s ABI compatibility.  The reason that is important is that compiler bugs in a lot of cases represent themselves as hard to explain artifacts in the functionality, anything from a random crash somewhere where everything should be working fine, to parts of the rendering going black for unclear reasons.  A cost effective way to diagnose such issues is getting us to a point where we can mix and match object files produced by either compilers to get a correct build, and then bisect between the compilers to find the translation unit that is being miscompiled, and then keep bisecting to find the function (and sometimes the exact part of the code) that is being miscompiled.  This is basically impractical without a good story for ABI compatibility in clang-cl.  We have recently hit a few of these issues.
  • Improving support for debug information generation in LLVM to a point that we can use Breakpad to generate crash stacks for crash-stats.  This should enable us to advertise these builds to a small community of dogfooders.
  • Start to look at a performance comparison between clang-cl and MSVC builds.  This plus the bisection infrastructure I touched on above should generate a wealth of information on performance issues in clang-cl, and then we can fix them with the help of the LLVM community.  Also, in case the numbers aren’t too far apart, maybe even ship one Firefox Nightly for Windows built with clang-cl, as a milestone!  :-)

Longer term, we can look into issues such as helping to add support for full debug information support, with the goal of making it possible to use Visual Studio on Windows with these builds.  Right now, we basically debug at the assembly level.  Although facilitating this will probably help speed up development too, so perhaps we should start on it earlier.   There is also LLDB on Windows which should in theory be able to consume the DWRAF debug information that clang-cl can generate similar to how it does on Linux, so that is worth looking into as well. I’m sure there are other things that I’m not currently thinking of that we can do as well.

Last but not least, this has been a collaboration between quite a few people, on the Mozilla side, Jeff Muizelaar, David Major, Nathan Froyd, Mike Hommey, Raymond Forbes and myself, and on the LLVM side many members of the Google compiler and Chromium teams: Reid Kleckner, David Majnemer, Hans Wennborg, Richard Smith, Nico Weber, Timur Iskhodzhanov, and the rest of the LLVM community who made clang-cl possible.  I’m sure I’m forgetting some important names.  I would like to appreciate all of these people’s help and effort.

Categorieën: Mozilla-nl planet