Outreachy/Round/14

From MozillaWiki
Jump to: navigation, search

Round 14 was from May 30 - Aug 30, 2017.

Projects

Page Shot / Firefox Screenshots

Note: Page Shot has been renamed Firefox Screenshots

Mentor: Ian Bicking
IRC: ianbicking (usually online 8am-3pm Pacific time)
IRC channel: #screenshots Status: it seems like we have quite a few potential applicants, you might want to consider looking at other projects

Project Description: Firefox Screenshots, a screenshot tool for Firefox, will be shipping with Firefox mid-June. Our small team's focus during the time of the internship will be running A/B tests on the product and refining the experience based on what we learn.

There's several areas that can be impactful to the project:

  • We are collecting behavioral data on how people use the tool, and plan to make changes through the summer based on what we learn. Someone with skills and interest in analyzing this kind of data (in our case Google Analytics and survey data) would be great. Some of what we want to learn from the data may require data analysis outside of Google Analytics.
  • We have many product goals. Firefox Screenshots is built as a WebExtension using pretty straight-forward JavaScript. The server is built with Node.js and React. Someone with knowledge of JavaScript together with HTML/CSS can get in and make positive changes quickly.
  • Our basic experience will be in place by the summer, but there will be many opportunities for optimizing the performance and size of the screenshots and pages that we're delivering, including offline access. In addition to development skills this will require research and experimentation to plan out the best approach.

If you are interested please check out the repository and try to follow the instructions. If you have problems that's okay! We want to make setup easy for everyone, but we still have work to do. Come to the IRC channel so we can help get you setup and improve the experience for future people. We have a list of good first bugs. If you want to start on one, please get your development environment setup first, and after that comment on a bug that you intend to work on it.

Note that the Firefox Screenshots developers work during the day, in timezones from UTC-8 to UTC-5. If an applicant can't work during many of those hours it is unlikely to be a good fit.

HTML+CSS demos of our new browser engine

Mentor:Lin Clark
IRC: linclark Email: lclark@mozilla.com

Project Description: At Mozilla, we're making our browser faster. This started as a research effort, building a next generation browser engine called Servo. Now parts of Servo are being merged into Firefox with Project Quantum.

The numbers are promising. For example, the new CSS style system (Stylo) can reduce the time it takes to render a page (like Barack Obama's wikipedia page) from 130ms to 30ms.

We want to show this off. In this internship, you'd be making demos that catch people's attention and show off these performance improvements.

For this internship, you will need HTML and CSS skills. We would love to see demos or prototypes you have created in the past that delight and surprise. An understanding of web page performance and how to analyze performance in the browser is preferred but not required.

Security audit of Firefox code

Mentor: Stéphanie Ouillon
IRC: arroway

Project Description: The Security Engineering team works on building and ensuring security into Firefox. Part of this work involves conducting security audits of the code shipped in Firefox. The candidate should be comfortable reading C++ and JavaScript Firefox code, and have an interest in learning about security engineering.

The scope of this project includes two main areas we're putting focus on:

1) Security auditing of third-party libraries used in Firefox Firefox relies on a vast amount of third-party Open Source libraries. Code review and security practices vary from one library to another, or new releases with security fixes might go unnoticed. We want to reduce the risk of including unsafe code in Firefox and auditing more thoroughly the most critical libraries we use.

Tasks include:

  • Identifying libraries with security concerns
  • Identifying code paths for additional fuzzing
  • Documenting the current process for using a new third-party library in mozilla-central
  • Setting security metrics (e.g number of security bugs related to the lib) to measure risk associated with a certain lib

2) Sandbox auditing Firefox is getting a security sandbox (https://wiki.mozilla.org/Security/Sandbox/Process_model). Hardening Firefox against attacks involves:

  • Checking IPC mechanisms are safe
  • Fuzzing IPC for bugs
  • Reviewing Firefox components with respect to sandbox controls

To get started, please visit this page: https://wiki.mozilla.org/SecOutreachy

Implement Telemetry health ping

Mentor: Georg Fritzsche
IRC: gfritzsche

Project Description Firefox Telemetry enables engineers and decision-makers to measure how Firefox behaves in the real world. As you use Firefox, Telemetry measures and collects non-personal information, such as performance, hardware, usage and customizations.

To more reliably monitor the quality of our incoming data and error conditions, we want to implement a small & minimal Telemetry health ping. This will be small enough to be sent without bandwidth concerns and include essential information about failures.

For this project, you will need:

  • JavaScript for the Firefox implementation
  • Python for processing and validating the incoming data using PySpark

This project will involve:

  • working with team members on the design of the health reporting
  • implementing the new design on the client, including test coverage
  • working with QA on a test plan for the reporting
  • validating incoming data
  • working with team members to make the data available in our re:dash instance

You can find more details on the project page.

Improve cross-browser and functional testing for webcompat.com

Mentor: Mike Taylor (Note: will be on PTO from March 9 - 19, but will check email sporadically. @karlcow has agreed to help with PRs and in issues).
IRC: miketaylr (I can be found in the #webcompat channel. If my nick is zz_miketaylr, I'm away but will get your messages when I come back!).

Project Description: webcompat.com is an open source project and website with the ambitious goal of making the web work for all users, in any browser. We want to improve our functional and cross-browser testing capabilities.

In this project, the Outreachy participant will work on the following:

  • Define a cross-browser testing matrix
  • Get functional tests running in non-Firefox browsers
  • Make improvements to BrowserStack - Travis CI Integration (this may or may not be done by the time this Outreachy round starts, we'll see!)
  • Create a working sub-set of tests for external contributors without access to authentication secrets.
  • Create a script to "bootstrap" a test repo to meet current functional test expectations
  • Improve test coverage (writing new functional tests, refactoring existing ones)
  • Implement a solution for mocking GitHub authentication
  • Investigate intermittent Intern failures
  • Explore unit testing with Intern

To be successful, the participant will need to be comfortable writing JavaScript and configuring 3rd party testing services. Some Python and Node.js experience will prove useful, but the rest can be learned!

To get started: 

 1. Clone the repo
 2. Set up a local development environment
 3. Get functional tests running locally
 4. Report any bugs or problems you ran into with that process, if any.
 5. Send an email to miket@mozilla.com with a screenshot showing tests have completed locally. We'll talk about next contribution steps!
 (Note: it's OK if many of them are failing, as long as they all run!)

Site permission management UI

Mentor: Johann Hofmann
IRC: johannh

Project Description: "We would like to add a section to Firefox preferences that allows users to manage their saved site permissions (Geolocation, Camera, Microphone, ...). Our UX team is currently designing a nice-looking UI for this. Features include viewing and removing permissions and globally disabling access to a certain permission for all sites. Your task would be to implement this UI inside the Firefox preferences using JavaScript, HTML and CSS and wire up any missing pieces in the Firefox internals (moderate JavaScript experience is recommended).

You might enjoy this project if you like working on user interfaces, care about privacy and security and want to have a sizeable impact on the privacy and security of millions of Firefox users.

You can get started by solving any good first Firefox bug:

More details can be found in our contributing guide: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Introduction

It is highly recommended that you hop on IRC (https://wiki.mozilla.org/IRC) and join the #fx-team channel. Feel free to ask for help there (ping johannh).

CSS Layout Bug Squasher

Mentor: Josh Matthews
IRC: jdm

Project Description: Servo is a new, experimental web browser engine written in the Rust programming language (http://www.rust-lang.org/). It also has lots of bugs in its implementation of CSS layout. Some of these bugs are filed in the issue tracker with minimized test cases (https://github.com/servo/servo/issues/14947), while others have not been investigated yet (https://github.com/servo/servo/issues/15432). We’re looking for someone who is:

  • comfortable writing code in any programming language
  • experienced in reading and understanding the effects of CSS

We want to teach you how to write Rust code so you can channel that experience into squashing CSS layout implementation bugs in Servo. You will gain experience in:

  • reducing problems into minimal test cases
  • developing in a low-level programming language
  • using debugging strategies to determine the cause of problems in complex code
  • contributing to a large open-source project as part of a distributed team

To get involved:

Automate web accessibility testing

Mentor: Matt Brandt
IRC: mbrandt

Project Description: The internship entails researching how to test for web accessibility standards and then the application of that knowledge by reviewing several open source automated testing frameworks. Once they have chosen the framework that best suits our needs, that minimizes false positives, they will be responsible for codifying a suite of tests that are able to run within our Jenkins CI.

The project requires the intern to spend a short amount of time reading about web accessibility testing to help them gain domain knowledge. Prior experience with Javascript and Python is helpful but not required. Experience with an object oriented programing language is required, but can be gained by taking one of the many freely available online courses. An interest and aptitude in software engineering is encouraged.

As the intern pieces together a solution and implements the tests, they’ll help cleanup and update documentation. A willingness to reach out to members of the Firefox Test Engineering team as well as the Accessibility team for clarification will help round out the internship experience.

Rust: Web Assembly showcase

Mentor: Brian Anderson
IRC: brson

Project Description: Rust is a new systems programming language that is fast and memory safe. It is growing quickly, is pleasant to contribute to, and is in need of contributions in many areas!

In this project you will be developing a showcase application to demonstrate Rust compiled to WebAssembly, a new bytecode that runs in the web browser. With WebAssembly, authors can write software that runs on the web with near-native performance. It will unlock new capabilities for the web, and Rust, with it's focus on low-level performance, is one of the best-positioned languages to take advantage of WebAssembly.

This is a self-contained project where creativity and persistence will lead to success. Design and implement a client-side web application, written in Rust, that demonstrates the promise of running Rust software on the web, by compiling to WebAssembly. Publish and blog about the result.

This serves two important purposes: firstly, as a teaching tool, the project demonstrates two bleeding-edge technologies used successfully together. You will be at the forefront of this technology and people will be looking to your early experience as they try it themselves. Second, by writing a real application we will discover new bugs and other problems with the stack. You will report these bugs to their upstream projects, and even fix them yourself. This process of validating our products by actually using them is called "dogfooding", and it's an important part of product development.

At the end of this project you will have your own Rust-language web application, will have new experience with Rust, WebAssembly, JavaScript, and with collaboration in an active and friendly open source community.

The project will run in 3 phases: in the first weeks you will familiarize yourself with the tools: Rust, WebAssembly, emscripten, and their development environment in and out of the web browser. You'll work with your coach to identify a few key features that the project will demonstrate and plan how to create them. The second phase is where you will do planned implementation work. Finally, with a few weeks left to spare, we will evaluate our progress, decide how to present it most effectively, and then spend the remaining time polishing and documenting it for release.

Good candidates will have moderate programming experience, either in JavaScript or in a systems language like C, C++ or Rust. This work will involve investigating and even debugging new compiler and web browser features - much time will probably be spent examining the Rust compiler's WebAssembly output and comparing it to expectations. Interns will not be expected to fix bugs the Rust compiler itself on their own, though they are certainly welcome to - their task is to write an interesting web applications.

Unsafe Code Linting Tool for Rust

Mentor: Nicholas Matsakis
IRC: nmatsakis

Project Description: Rust is a new systems programming language that is fast and memory safe. It is growing quickly, is pleasant to contribute to, and is in need of contributions in many areas!

A crucial part of Rust's design is the ability for authors to use ""unsafe code"" to build up new abstractions and libraries. Unsafe code allows you to locally suspend some of the Rust type system rules, effectively giving you a lower-level language closer to C. The idea is that these lower-level details are encapsulated within a library that exports a safe interface. For example, the Rayon library exposes very convenient, simple primitives for writing threaded programs. If you stick to those primitives, your program will be free of data-races and other nasty parallel programming bugs. But internally the Rayon library makes use of traditional C-style threads to implement this abstraction.

At present, Rust doesn't give you very fine-grained tools for reasoning about unsafe code. Once you start writing an unsafely implemented library, it's entirely up to you to track whether a given pointer is safe to use and so forth. Just as when writing C code, this can easily go awry, particularly as code is updated. It could easily happen, for example, that an array index i is known to be in-bounds, and hence an unsafe array access (no bounds check) like vec[i] is safe. But as the program is updated, perhaps that assumption no longer holds -- now the array access could be out of bounds, leading to memory safety errors.

The goal with this internship is to develop a lint tool that would integrate with the rustc front-end to help improve the experience of writing unsafe code. This tool would allow unsafe code authors to write out and check more of their reasoning automatically: for example, they might document that why they believe that the variable i is in bounds (e.g., because it is compared against the length of the array, and the variable vec is not updated in the meantime). Then the tool can help check whether any of these assumptions stops being true (e.g., perhaps vec is changed to point to a different vector).

The project will involve both design and implementation. There is a general plan for how the linting tool should work, but part of the fun will be iterating on the tool once we try to put it to use and see how well it works. If all goes to plan, we can release the tool to the public.

Good candidates will have moderate programming experience in some language; experience with C, C++, or Rust specifically is not required. This work will primarily involve building a lint, which interfaces with the front-end of the Rust compiler, but will also involve learning a bit about the Rayon codebase (or some other suitable example of an unsafely implemented library).

Push Notifications for Signin Confirmation

Mentor: Sean McArthur
IRC: seanmonstar

Project Description: You will be implementing a form of 2FA in Firefox Accounts. Once completed, if a user has multiple devices connected to their Firefox Account, they will be able to receive a push notification to one of their other devices asking for confirmation when trying to log in to their Firefox Account.

Skills required: Git, JavaScript (node and browser)

As part of your application please try to fix a ‘good first bug’ at: https://waffle.io/mozilla/fxa?label=good-first-bug

To get started with Firefox Accounts servers please visit: https://github.com/mozilla/fxa-local-dev

To learn more about Firefox Accounts project check out: https://fxa.readthedocs.io/en/latest/

bugzilla.mozilla.org improvements

Mentor: Emma Humphries
IRC: emceeaich

Project Description:

Participant would select from one of these projects:

1) [BMO RESKIN] Mozilla recently re-branded, and BMO doesn't match the new look. It would be nice to reskin it to look like the central Mozilla property it is.

Skills: CSS, HTML Templates, Perl

2) [TRIAGE VIEW] Build a supplemental bug editing view optimized for triaging bugs. This would afford the participant the chance to do rapid prototyping, test ideas with senior engineers, and help with an important workflow

Skills: JavaScript, CSS, HTML, Perl

See our list of Good First Bugs for bugs to attempt as part of application.

Upgrade ActiveData to use Elasticsearch v5+

Mentor: Kyle Lahnakoski
IRC: ekyle

LIVE DOCUMENT WITH ANSWERS

Project Description: About ActiveData
ActiveData is a publicly accessible data warehouse holding many billions of records, for some dozen+ datasets concerning Mozilla's testing infrastructure: This includes test results, job results, code coverage, and extracts from other systems. The ActiveData code itself is really only a stateless query translation layer; leaving the hard work of high speed filtering and aggregation to Elasticsearch.

Background
Elasticsearch is designed for text search, but can also serve as an extremely fast data warehouse. The speed comes from using [inverted indices](https://www.elastic.co/guide/en/elasticsearch/guide/current/inverted-index.html) to provide high performance data filtering and aggregation. Elasticsearch can index almost any JSON document, perform schema merging, and index all its properties, with almost no human intervention. By letting the machine manage the schema, we can query the JSON without transforming it

Elasticsearch does have a drawback: Its query language is designed for text search and is painful to use in a data warehouse context. Hence the need for ActiveData.

Problem
Elasticsearch 1.7.x was the last version that did a reasonable job of schema merging. Newer versions (2.0+) have disallowed schema merging, preventing ingestion of JSON documents that have a schema that conflicts with previous documents. We would like to use newer, faster, and more stable versions of Elasticsearch, but they can not handle varied data.

Solution
Build a translator will convert a variety of JSON formats into a single, strictly-typed, schema. The translator will use schema merging and property-renaming to perform a translation on documents before they go Elasticsearch.

Benefits
ElasticSearch's schema merging is great, but has always been incomplete: 1. It could not merge inner objects `{"a":{"b":1}}` with nested objects `{"a":[{"b":0}]}`, and 2. Merging numbers `{"a": 1}` with strings `{"b": "1"}` did not cause failure, but did leave the schema ambiguous, and made the queries clumsy. This upgrade will make ActiveData more flexible, improve service stability, and provide a step towards promoting this project to production.

Required Skills
Some particular experience will make this task easier (most important first):

  • Python
  • SQL and query languages
  • Database normalization and functional dependencies
  • Denormalization and data warehousing

References
1. Similar project for smaller data: [Mapping JSON to strict DB schema](https://github.com/klahnakoski/JSONQueryExpressionTests/blob/master/docs/GSOC%20Proposal.md)
2. [ELT](https://en.wikipedia.org/wiki/Extract,_transform,_load) Links: [A](http://hexanika.com/why-shift-from-etl-to-elt/), [B](https://www.ironsidegroup.com/2015/03/01/etl-vs-elt-whats-the-big-difference/)
3. [data cubes](https://en.wikipedia.org/wiki/OLAP_cube)
4. [fact tables](https://en.wikipedia.org/wiki/Fact_table) in a [data warehouse](https://en.wikipedia.org/wiki/Data_warehouse).
5. [MDX](https://en.wikipedia.org/wiki/MultiDimensional_eXpressions).

Upgrade Lightbeam

Mentor: Paul Theriault IRC: pauljt

Project Description: The Mozilla Lightbeam extension is a key tool for Mozilla to educate the public about privacy and it’s due for an upgrade. It needs to be rewritten as a Web Extension and we will take this opportunity to investigate potential new features or integrations with Firefox. We are seeking a candidate with web development skills to work with the security engineering team to make this happen. We are looking for a front-end web developer who is passionate about privacy on the web. They should have an interest in design and visualization as the key part of this upgrade would be exploring how we can convey complex privacy & security concepts to the all Firefox users. Experience working with Web Extensions is a bonus but not required.

See the getting started guide here.

Improve DevTools Network Monitor

Mentor: Jan Odvarko
IRC: Honza

Project Description: "Firefox Developer tools can be used to intercept all HTTP requests and responses executed by a page. This feature is represented by a Network panel that shows list of all HTTP requests and related details (like e.g. headers, formatted response body, timings, etc.)

In order to improve value of the panel we'd like to connect the existing UI to other backends performing HTTP activity (for example, Chrome browser or NodeJS) and adapt our current remote protocol (RDP) to a new environment."

Retrieved from "https://wiki.mozilla.org/index.php?title=Outreachy/Round/14&oldid=1196030"