mozilla

Mozilla Nederland LogoDe Nederlandse
Mozilla-gemeenschap

Abonneren op feed Mozilla planet
Planet Mozilla - http://planet.mozilla.org/
Bijgewerkt: 4 maanden 4 dagen geleden

Air Mozilla: Bugzilla Project Meeting, 07 Jun 2017

wo, 07/06/2017 - 22:00

Bugzilla Project Meeting The Bugzilla Project Developers meeting.

Categorieën: Mozilla-nl planet

Air Mozilla: The Joy of Coding - Episode 101

wo, 07/06/2017 - 19:00

The Joy of Coding - Episode 101 mconley livehacks on real Firefox bugs while thinking aloud.

Categorieën: Mozilla-nl planet

Air Mozilla: Weekly SUMO Community Meeting June 07, 2017

wo, 07/06/2017 - 18:00

Weekly SUMO Community Meeting June 07, 2017 This is the sumo weekly call

Categorieën: Mozilla-nl planet

Mozilla Open Policy & Advocacy Blog: Engaging on e-Privacy at the European Parliament

wo, 07/06/2017 - 17:26

Last week, I participated in the European Parliament’s Technical Roundtable regarding the draft e-Privacy Regulation currently under consideration – specifically, I joined the discussion on “cookies”. The Roundtable was hosted by lead Rapporteur on the file, MEP Marju Lauristin (Socialists and Democrats, Estonia), and MEP Michal Boni (European People’s Party, Poland). It was designed to bring together a range of stakeholders to inform the Parliament’s consideration of what could be a major change to how Europe regulates the privacy and security of communications online, related to but with a different scope and purpose than the recently adopted General Data Protection Regulation (GDPR).

Below the fold is a brief overview of my intervention, which describes our proposed changes for some of the key aspects of the Regulation, including how it handles “cookies”, and more generally how to deliver maximal benefits for the privacy and security of communications, with minimum unnecessary or problematic complexities for technology design and engineering. I covered the following three points:

  1. We support incentives for companies to offer privacy protective options to users.
  2. The e-Privacy Regulation must be future-proofed by ensuring technological neutrality.
  3. Browsers are not gatekeepers nor ad-blockers; we are user agents.

The current legal instrument on this topic, the e-Privacy Directive, leaves much to be desired when it comes to effective privacy protections and user benefit, illustrated quite prominently by the “cookie banner” which users click through to “consent” to the use of cookies by a Web site. The e-Privacy Regulation is is an important piece of legislation – for Mozilla, for Europe, and ultimately, for the health of the global internet. We support the EU’s ambitious vision,  and we will continue working with the Parliament, the Commission, and the Council by sharing our views and experiences with investing in privacy online. We hope that the Regulation will contribute to a better communications ecosystem, one that offers meaningful control, transparency, and choice to individuals, and helps to rebuild trust online.

1 – We support incentives for companies to offer privacy protective options to users.

We view one of the primary objectives of the Regulation to be catalyzing more offerings of privacy protective technologies and services for users. We strongly support this objective. This is the approach we take with Firefox: Users can browse in regular mode, which permits Web sites to place cookies, or in private browsing mode, which has our Tracking Protection technology built in. We invest in making sure that both options are desirable user experiences, and the user is free to choose which they go with – and can switch between them at will, and use both at the same time. We’d like to see more of this in the industry, and welcome the language in Article 10(1) of the draft Regulation which we believe is intended to encourage this.

2 – The e-Privacy Regulation must be future-proofed by ensuring technological neutrality.

One of the principles that shaped the current e-Privacy Directive was technological neutrality. It’s critical that the Regulation similarly follow this principle, to ensure practical application and to keep it future-proof. It should therefore focus on the underlying privacy risk to users created by cross-site and cross-device tracking, rather than on specific technologies that create that risk. To achieve that, the current draft of the Regulation would benefit from two changes.

First, the Parliament should revise  references to specific tracking techniques, like first and third party cookies to ensure that other forms of tracking aren’t overlooked. While blocking third party cookies may seem at first glance to be a low hanging fruit to better protect user privacy and security online — see this Firefox add-on called Lightbeam, which demonstrates the amount of first and third party sites that can “follow” you online — there are a number of different ways a user can be tracked online; via third party cookies is only an implementation of one form (albeit a common one). Device fingerprinting, for example, creates a unique, persistent identifier that undermines user consent mechanisms and that requires a regulatory solution. Similarly, Advertising identifiers are a pervasive tracking tool on mobile platforms that are currently not addressed. The Regulation should use terminology that more accurately captures the targeted behavior, and not only one possible implementation of tracking.

Second, the Regulation includes a particular focus on Web browsers (such as Recitals 22-24), without proper consideration of the diversity of forms of online communications today. We aren’t suggesting that the Regulation exclude Web browsing, of course. But to focus on one particular client-side software technology risks missing other technology with significant privacy implications, such as tracking facilitated by mobile operating systems or cloud services accessed via mobile apps. Keeping a principle-based approach will ensure that the Regulation doesn’t impose a specific solution that does not meaningfully deliver on transparency, choice, and control outside of the Web browsing context.

3 – Browsers are not gatekeepers nor ad-blockers; we are user agents.

Building on the above, the Parliament ought to view the Web browser in a manner that reflects its place in the technology ecosystem. Web browsers are user agents facilitating the communication between internet users and Web sites. For example, Firefox offers deep customisation options, and its goal is to put the user in the driver seat. Similarly, Firefox private browsing mode includes Tracking Protection technology, which blocks certain third party trackers through a blacklist (learn more about our approach to content blocking here). Both of these are user agent features, embedded in code shipped to users and run on their local devices – neither is a service that we functionally intermediate or operate as it is used. It’s not constructive from a regulatory perspective, nor an accurate understanding of the technology, to describe Web browsers as gatekeepers in the way the Regulation does today.

The post Engaging on e-Privacy at the European Parliament appeared first on Open Policy & Advocacy.

Categorieën: Mozilla-nl planet

Jan Varga: A Time for Mourning Again.

wo, 07/06/2017 - 16:52

Our dog Aida passed away today from a kidney failure. I knew there’s a little chance to help her, but I really hoped she would magically overcome it.

She was the greatest dog I’ve ever had. She was a family member, a friend … I will miss her terribly.

Rest in peace our beloved Aida…

Jan

 


Categorieën: Mozilla-nl planet

Hacks.Mozilla.Org: Introducing FilterBubbler: A WebExtension built using React/Redux

wo, 07/06/2017 - 16:47

A  few months ago my long time Free Software associate, Don Marti, called me about an idea for a WebExtension. WebExtensions is the really cool new standard for browser extensions that Mozilla and the Chrome team are collaborating on (as well as Opera, Edge and a number of other major browsers). The WebExtensions API lets you write add-ons using the same JavaScript and HTML methodologies you use to implement any other web site.

Don’s idea was basically to build a text analysis toolkit with the new WebExtensions API. This toolkit would let you monitor various browser activities and resources (history, bookmarks, etc.) and then let you use text analysis modules to discover patterns in your own browsing history. The idea was to turn the tables on the kinds of sophisticated analysis that advertisers do with the everyday browsing activities we take for granted. Big companies are using advanced techniques to model user behavior and control the content they receive, in order to manipulate outcomes like the time a user spends on the system or the ads they see. If we provided tools for users to do this with their own browsing data, they would have a better chance to understand their own behaviors and and a greater awareness of when external systems are trying to manipulate them.

The other major goal would be to provide a well-documented example of using the new WebExtensions API.  The more I read about WebExtensions the more I realized they represent a game-changer for moving web browsing intelligence “out to the edge”. All sorts of analysis and automation can be done with WebExtensions in a way that potentially lets the tools be used on any of the popular modern web browsers. About the only thing I saw missing was a way to easily collaborate around these “recipes” for analysing web content. I suggested we create a WordPress plugin that would supply a RESTful interface for sharing classifications and the basic plan for “FilterBubbler” was born.

Our initial prototype was a proof of concept that used an extremely basic HTML pop-up and a Bayesian classifier. This version proved that we could provide useful classification of web page content based on hand-loaded corpora, but it was clear that we would need additional tooling to get to a “consumer” feel. Before we could start adding important features like remote recipe servers, classification displays and configuration screens, we clearly needed to make some decisions about our infrastructure. In this article, I will cover our efforts to provide a modern UI environment and the challenges that posed when working with WebExtensions.

React/Redux

The React framework and its associated Flux implementation took the HTML UI world by storm when Facebook released the tool as Free Software in 2013. React was originally deployed in 2011 as part of the newsfeed display infrastructure on Facebook itself. Since then the library has found use in Instagram, Netflix, AirBnB and many other popular services. The tool revolves around a strategy called Flux which tightly defines the way state is updated in an application.

Flux is a strategy not an actual implementation, and there are many libraries that provide its functionality. One of the most popular libraries today is Redux. The Redux core value is a simplified universal view of the application state. Because there is a single state for the application, the behavior that results from a series of action events is completely deterministic and predictable. This makes your application easier to reason about, test and debug. A full discussion of the concepts behind React and Redux is beyond the scope of this article so if you are just getting started, I would recommend that you read the Redux introductory material or check out Dan Ambramov’s excellent introductory course at Egghead.

Integrating with WebExtensions

Digging into the WebExtensions framework, one of the first hurdles is that the UI pop-up and config page context is separate from the background context. The state of the UI context is recreated each time you open and close the UI displays. Communication between the UI context and the background script context is achieved via a message-passing architecture.

The state of the FilterBubbler extension will be stored in the background context but we’ll need to bind that state to UI elements in the pop-up and config page context. Alexander Ivantsov’s Redux-WebExt project offers one solution for this problem. His tool provides an abstraction layer between the UI and background pages with a proxy. The proxy gives the appearance of direct access to the Redux store in the UI, but it actually forwards actions to the background context, and then sends resulting state modifications generated by the reducers back to the UI context.

Action mapping

It took me some effort to get things working across the Redux-WebExt bridge. The React components that run in the UI contexts think they are talking to a Redux store; in fact, it’s a facade that is exchanging messages with your background context. The action objects that you think are headed to your reducers are actually serialized into messages, sent to the background context and then unpacked and delivered to the store. Once the reducers finish their state modifications, the resulting state is packed up and sent back to the proxy so that it can update the state of the UI peers.

Redux-WebExt puts a mapping table in the middle of this process that lets you modify how action events from the front-end get delivered to the store. In some cases (i.e., asynchronous operations) you really need this mapping to separate out actions that can’t be serialized into message objects (like callback functions).

In some cases this may be a straight mapping that only copies the data from a UI action event, like this one from FilterBubbler’s mappings in store.js:

actions[formActionTypes.TOUCH] = (data) => { return { type: formActionTypes.TOUCH, ...data }; }

Or, you may need to map that UI action to something completely different, like this mapping that calls an asynchronous function only available in the background store:

actions[UI_REQUEST_ACTIVE_URL] = requestActiveUrl;

In short, be mindful of the mapper! It took me a few hours to get my head wrapped around its purpose. Understanding this is critical if you want to use React/Redux in your extension as we are.

This arrangement makes it possible to use standard React/Redux tooling with minimal changes and configuration. Existing sophisticated libraries for form-handling and other major UI tasks can plug into the WebExtension environment without any knowledge of the underlying message-based connectivity. One example tool we have already integrated is Redux Form, which provides a full system for managing form input with validation and the other services you would expect in a modern development effort.

Having established that we can use a major UI toolkit without starting from scratch, our next concern is to make things look good. Google’s Material Design is one popular look and feel standard and the React platform has the popular Material UI, which implements the Google standard as a set of React/Redux components. This gives us the ability to produce great looking UI popups and config screens without having to develop a new UI toolkit.

Get thunky

Some of the operations we need to perform are callback-based, which makes them asynchronous. In the React/Redux model this presents some issues. Action generator functions and reducers are designed to do their work immediately when called. Solutions like providing access to the store within an action generator and calling dispatch in a callback are considered an anti-pattern. One popular solution to this problem is the Redux-Thunk middleware. Adding Redux-Thunk to your application is easy, you just pass it in when you create the store.

import thunk from 'redux-thunk' const store = createStore(    reducers,    applyMiddleware(thunk))

With Redux-Thunk installed you are provided with a new style of action generators in which you return a function to the store that will later be passed a dispatch function. This inversion of control allows Redux to stay in the driver’s seat when it comes to sequencing your asynchronous operations with other actions in the queue. As an example, here’s a function that requests the URL of the current tab and then dispatches a request to set the result in the UI:

export function requestActiveUrl() {    return dispatch => {        return browser.tabs.query({active: true}, tabs => {            return dispatch(activeUrl(tabs[0].url));        })    } }

The activeUrl() function looks more typical:

export function activeUrl(url) {    return {        type: ACTIVE_URL,        url    } }

Since WebExtensions span several different contexts and communicate with asynchronous messaging, a tool like Redux-Thunk is indispensable.

Debugging WebExtensions

Debugging WebExtensions presents a few new challenges that work a little differently depending on the browser you are using. Whichever browser you use, the first major difference is that the background context of the extension has no visible page and must be specifically selected for debugging. Let’s walk through getting started with that process on Firefox and Chrome.

Firefox

On Firefox, you can access your extension by typing “about:debugging” into the browser’s URL field. This page will allow you to load an unpacked extension with the “Load Temporary Add-On” button (or you can use the handy web-ext tool that allows you to start the process from the command line). Pressing the “Debug” button here will bring up a source debugger for your extension. With FilterBubbler, we are using the flexible webpack build tool to take advantage of the latest JavaScript features. Webpack uses the babel transpiler to convert new JavaScript language features into code that is compatible with current browsers. This means that the sources run by the browser are significantly altered from their originals. Be sure to select the “Show Original Sources” option from the preferences menu in the debugger or your code will seem very unfamiliar!

Once you have that selected you should see something more like what you expect:

From here you can set breakpoints and do everything else you would expect.

Chrome

On Chrome it’s all basically the same idea, just a few small differences in the UI. First you will go to the main menu, dig down to “more tools” and then select “extensions”:

That will take you to the extension listing page.

The “Inspect views” section will allow you to bring up a debugger for your background scripts.

Where the Firefox debugger shows all of your background and foreground activity in one place, the Chrome environment does things a little differently. The foreground UI view is activated by right-clicking the icon of your WebExtension and selecting the “Inspect popup” option.

From there things are pretty much as you would expect. If you have written JavaScript applications and used the browser’s built-in functionality then you should find things pretty familiar.

Classification materials

With all our new infrastructure in place and a working debugger we were back on track adding features to FilterBubbler.  One of our goals for the prototype is to provide the API that recipes will run in. The main ingredients for FilterBubbler recipes are:

One or more sources: A source provides a stream of classification events on given URLs. The prototype provides a simple source which will emit a classification request any time the browser switches to a particular page. Other possible sources could include a source that scans a social network or a newsfeed for content, a stream of email messages or a segment of the user’s browser history.

A classifier: The classifier takes content from a source and returns at least one classification label with a strength value. The classifier may return an array of label and strength value pairs. If the array is empty then the system assumes that the classifier was not able to produce a match.

One or more corpora: FilterBubbler corpora provide a list of URLs with label and strength values. The labels and strength values are used to train the classifier.

One or more sinks: A sink is the destination for the classification events. The prototype includes a simple sink that connects a given classifier to a UI widget, which displays the classifications in the WebExtensions pop-up. Other possible sinks could generate outbound emails for certain classification label matches or a sink that writes URLs into a bookmark folder named with the classification label.

Maybe a diagram helps. The following configuration could tell you whether the page you are currently looking at is “awesome” or “stupid”!

Passing on the knowledge

The configurations for these arrangements are called “recipes” and can be loaded into your local configuration. A recipe is defined with a simple JSON format like so:

{ “recipe-version”: “0.1”, “name”: “My Recipe”, “classifier”: “naive-bayes”, “corpora”: [ “http://mywpblog.com/filterbubbler/v1/corpora/fake-news”, “http://mywpblog.com/filterbubbler/v1/corpora/ufos”, “http://mywpblog.com/filterbubbler/v1/corpora/food-blog” ], “source”: [ “default” ], “sink”: [ “default” ] }

The simple bit of demo code above can help a user differentiate between fake news, UFO sightings and food blogs (more of a problem than you might expect in some cities). Currently the classifiers, sources and sinks must be one of the provided implementations and cannot be loaded dynamically in the initial prototype. In upcoming articles, we will expand this functionality and describe the challenges these activities present in the WebExtensions environment.

References

FilterBubbler on GitHub: https://github.com/filterbubbler/filterbubbler-web-ext
React based Material UI: http://www.material-ui.com/
Redux WebExt: https://github.com/ivantsov/redux-webext
Redux Form: http://redux-form.com/6.7.0/
Mozilla browser polyfill: https://github.com/mozilla/webextension-polyfill

Categorieën: Mozilla-nl planet

Pagina's