mozilla

Mozilla Nederland LogoDe Nederlandse
Mozilla-gemeenschap

Software-update: Pale Moon 27.4.2 - Tweakers

Nieuws verzameld via Google - di, 22/08/2017 - 19:53

Tweakers

Software-update: Pale Moon 27.4.2
Tweakers
Pale Moon logo (75 pix) Er is een tweede update voor versie 27.4 van Pale Moon uitgekomen. Deze webbrowser maakt gebruik van de broncode van Mozilla Firefox, maar is geoptimaliseerd voor moderne hardware. De Windows-versie van Mozilla Firefox ...

Categorieën: Mozilla-nl planet

The Mozilla Blog: The Battle to Save Net Neutrality: A Panel with Tom Wheeler, Ro Khanna, Mozilla, Leading TV Producers and Others

Mozilla planet - di, 22/08/2017 - 19:18
On September 18, net neutrality experts will gather at the Internet Archive to discuss dire threats to the open web. You’re invited

 

Net neutrality — and the future of a healthy internet — is at stake.

In May, the FCC voted to move forward with plans to gut net neutrality. It was a decision met with furor: Since then, many millions of Americans have written, phoned and petitioned the FCC, demanding an internet that belongs to individual users, not broadband ISP gatekeepers. And scores of nonprofits and technology companies have organized to amplify Americans’ voices.

The first net neutrality public comment period ends on August 30, and the FCC is moving closer to a vote.

So on Monday, September 18, Mozilla is gathering leaders at the forefront of protecting net neutrality. We’ll discuss why it matters, what lies ahead, and what can be done to protect it.

RSVP: The Battle to Save Net Neutrality

Leaders like former FCC Chairman Tom Wheeler and Congressman Ro Khanna will discuss net neutrality’s importance to free speech, innovation, competition and social justice.

This free public event, titled “Battle to Save Net Neutrality,” will feature a panel discussion, reception and audience Q&A. It will be held at the Internet Archive (300 Funston Avenue, San Francisco) from 6 p.m. to 9 p.m. Participants include:

  • Panelist Tom Wheeler, former FCC Chairman who served under President Obama and architect of the 2015 net neutrality rules

 

  • Panelist and Congressman Ro Khanna (D-California), who represents California’s 17th congressional district in the heart of Silicon Valley. Khanna is a vocal supporter of net neutrality

 

  • Panelist Amy Aniobi, TV writer and producer for “Insecure” (HBO) and “Silicon Valley” (HBO), and member of the Writers Guild of America, West

 

  • Panelist Luisa Leschin, TV writer and producer for “From Dusk til Dawn” (Netflix) and “Just Add Magic” (Amazon), and a member of the Writers Guild of America, West

 

  • Panelist Denelle Dixon, Mozilla Chief Legal and Business Officer. Dixon spearheads Mozilla’s business, policy and legal activities in defense of a healthy internet. She is a vocal advocate for net neutrality, encryption and greater user choice and control online

 

  • Panelist Malkia Cyril, Executive Director of the Center for Media Justice. Cyril has spent the past 20 years building the capacity of racial and economic justice movements to win media rights, access and power in the digital age

 

  • Moderator Gigi Sohn, Mozilla Tech Policy Fellow and former counselor to FCC Chairman Tom Wheeler (2013-2016). One of the nation’s leading advocates for an open, fair, and fast internet, Sohn was named “one of the heroes that saved the Internet” by The Daily Dot for her leadership in the passage of the FCC’s strong net neutrality rules in 2015

Join us as we discuss the future of net neutrality, and what it means for the health of the internet. Register for this free event here.

The post The Battle to Save Net Neutrality: A Panel with Tom Wheeler, Ro Khanna, Mozilla, Leading TV Producers and Others appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

The Battle to Save Net Neutrality: A Panel with Tom Wheeler, Ro Khanna, Mozilla, Leading TV Producers and Others

Mozilla Blog - di, 22/08/2017 - 19:18
On September 18, net neutrality experts will gather at the Internet Archive to discuss dire threats to the open web. You’re invited

 

Net neutrality — and the future of a healthy internet — is at stake.

In May, the FCC voted to move forward with plans to gut net neutrality. It was a decision met with furor: Since then, many millions of Americans have written, phoned and petitioned the FCC, demanding an internet that belongs to individual users, not broadband ISP gatekeepers. And scores of nonprofits and technology companies have organized to amplify Americans’ voices.

The first net neutrality public comment period ends on August 30, and the FCC is moving closer to a vote.

So on Monday, September 18, Mozilla is gathering leaders at the forefront of protecting net neutrality. We’ll discuss why it matters, what lies ahead, and what can be done to protect it.

RSVP: The Battle to Save Net Neutrality

Leaders like former FCC Chairman Tom Wheeler and Congressman Ro Khanna will discuss net neutrality’s importance to free speech, innovation, competition and social justice.

This free public event, titled “Battle to Save Net Neutrality,” will feature a panel discussion, reception and audience Q&A. It will be held at the Internet Archive (300 Funston Avenue, San Francisco) from 6 p.m. to 9 p.m. Participants include:

  • Panelist Tom Wheeler, former FCC Chairman who served under President Obama and architect of the 2015 net neutrality rules

 

  • Panelist and Congressman Ro Khanna (D-California), who represents California’s 17th congressional district in the heart of Silicon Valley. Khanna is a vocal supporter of net neutrality

 

  • Panelist Amy Aniobi, TV writer and producer for “Insecure” (HBO) and “Silicon Valley” (HBO), and member of the Writers Guild of America, West

 

  • Panelist Luisa Leschin, TV writer and producer for “From Dusk til Dawn” (Netflix) and “Just Add Magic” (Amazon), and a member of the Writers Guild of America, West

 

  • Panelist Denelle Dixon, Mozilla Chief Legal and Business Officer. Dixon spearheads Mozilla’s business, policy and legal activities in defense of a healthy internet. She is a vocal advocate for net neutrality, encryption and greater user choice and control online

 

  • Panelist Malkia Cyril, Executive Director of the Center for Media Justice. Cyril has spent the past 20 years building the capacity of racial and economic justice movements to win media rights, access and power in the digital age

 

  • Moderator Gigi Sohn, Mozilla Tech Policy Fellow and former counselor to FCC Chairman Tom Wheeler (2013-2016). One of the nation’s leading advocates for an open, fair, and fast internet, Sohn was named “one of the heroes that saved the Internet” by The Daily Dot for her leadership in the passage of the FCC’s strong net neutrality rules in 2015

Join us as we discuss the future of net neutrality, and what it means for the health of the internet. Register for this free event here.

The post The Battle to Save Net Neutrality: A Panel with Tom Wheeler, Ro Khanna, Mozilla, Leading TV Producers and Others appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

Hacks.Mozilla.Org: Inside a super fast CSS engine: Quantum CSS (aka Stylo)

Mozilla planet - di, 22/08/2017 - 17:30

You may have heard of Project Quantum… it’s a major rewrite of Firefox’s internals to make Firefox fast. We’re swapping in parts from our experimental browser, Servo, and making massive improvements to other parts of the engine.

The project has been compared to replacing a jet engine while the jet is still in flight. We’re making the changes in place, component by component, so that you can see the effects in Firefox as soon as each component is ready.

And the first major component from Servo—a new CSS engine called Quantum CSS (previously known as Stylo)—is now available for testing in our Nightly version. You can make sure that it’s turned on for you by going to about:config and setting layout.css.servo.enabled to true.

This new engine brings together state-of-the-art innovations from four different browsers to create a new super CSS engine.

4 browser engines feeding in to Quantum CSS

It takes advantage of modern hardware, parallelizing the work across all of the cores in your machine. This means it can run up to 2 or 4 or even 18 times faster.

On top of that, it combines existing state-of-the-art optimizations from other browsers. So even if it weren’t running in parallel, it would still be one fast CSS engine.

Racing jets

But what does the CSS engine do? First let’s look at the CSS engine and how it fits into the rest of the browser. Then we can look at how Quantum CSS makes it all faster.

What does the CSS engine do?

The CSS engine is part of the browser’s rendering engine. The rendering engine takes the website’s HTML and CSS files and turns them into pixels on the screen.

Files to pixels

Each browser has a rendering engine. In Chrome, it’s called Blink. In Edge, it’s called EdgeHTML. In Safari, it’s called WebKit. And in Firefox, it’s called Gecko.

To get from files to pixels, all of these rendering engines basically do the same things:

  1. Parse the files into objects the browser can understand, including the DOM. At this point, the DOM knows about the structure of the page. It knows about parent/child relationships between elements. It doesn’t know what those elements should look like, though.Parsing the HTML into a DOM tree
  2. Figure out what the elements should look like. For each DOM node, the CSS engine figures out which CSS rules apply. Then it figures out values for each CSS property for that DOM node.Styling each DOM node in the tree by attaching computed styles
  3. Figure out dimensions for each node and where it goes on the screen. Boxes are created for each thing that will show up on the screen. The boxes don’t just represent DOM nodes… you will also have boxes for things inside the DOM nodes, like lines of text.Measuring all of the boxes to create a frame tree
  4. Paint the different boxes. This can happen on multiple layers. I think of this like old-time hand drawn animation, with onionskin layers of paper. That makes it possible to just change one layer without having to repaint things on other layers.Painting layers
  5. Take those different painted layers, apply any compositor-only properties like transforms, and turn them into one image. This is basically like taking a picture of the layers stacked together. This image will then be rendered on the screen.Assembling the layers together and taking a picture

This means when it starts calculating the styles, the CSS engine has two things:

  • a DOM tree
  • a list of style rules

It goes through each DOM node, one by one, and figures out the styles for that DOM node. As part of this, it gives the DOM node a value for each and every CSS property, even if the stylesheets don’t declare a value for that property.

I think of it kind of like somebody going through and filling out a form. They need to fill out one of these forms for each DOM node. And for each form field, they need to have an answer.

Blank form with CSS properties

To do this, the CSS engine needs to do two things:

  • figure out which rules apply to the node — aka selector matching
  • fill in any missing values with values from the parent or a default value—aka the cascade
Selector matching

For this step, we’ll add any rule that matches the DOM node to a list. Because multiple rules can match, there may be multiple declarations for the same property.

Person putting check marks next to matching CSS rules

Plus, the browser itself adds some default CSS (called user agent style sheets). How does the CSS engine know which value to pick?

This is where specificity rules come in. The CSS engine basically creates a spreadsheet. Then it sorts the declarations based on different columns.

Declarations in a spreadsheet

The rule that has the highest specificity wins. So based on this spreadsheet, the CSS engine fills out the values that it can.

Form with some CSS properties filled in

For the rest, we’ll use the cascade.

The cascade

The cascade makes CSS easier to write and maintain. Because of the cascade, you can set the color property on the body and know that text in p, and span, and li elements will all use that color (unless you have a more specific override).

To do this, the CSS engine looks at the blank boxes on its form. If the property inherits by default, then the CSS engine walks up the tree to see if one of the ancestors has a value. If none of the ancestors have a value, or if the property does not inherit, it will get a default value.

Form will all CSS properties filled in

So now all of the styles have been computed for this DOM node.

A sidenote: style struct sharing

The form that I’ve been showing you is a little misrepresentative. CSS has hundreds of properties. If the CSS engine held on to a value for each property for each DOM node, it would soon run out of memory.

Instead, engines usually do something called style struct sharing. They store data that usually goes together (like font properties) in a different object called a style struct. Then, instead of having all of the properties in the same object, the computed styles object just has pointers. For each category, there’s a pointer to the style struct that has the right values for this DOM node.

Chunks of the form pulled out to separate objects

This ends up saving both memory and time. Nodes that have similar properties (like siblings) can just point to the same structs for the properties they share. And because many properties are inherited, an ancestor can share a struct with any descendants that don’t specify their own overrides.

Now, how do we make that fast?

So that is what style computation looks like when you haven’t optimized it.

 selector matching, sorting by specificity, and computing property values

There’s a lot of work happening here. And it doesn’t just need to happen on the first page load. It happens over and over again as users interact with the page, hovering over elements or making changes to the DOM, triggering a restyle.

Initial styling plus restyling for hover, DOM nodes added, etc

This means that CSS style computation is a great candidate for optimization… and browsers have been testing out different strategies to optimize it for the past 20 years. What Quantum CSS does is take the best of these strategies from different engines and combine them to create a superfast new engine.

So let’s look at the details of how these all work together.

Run it all in parallel

The Servo project (which Quantum CSS comes from) is an experimental browser that’s trying to parallelize all of the different parts of rendering a web page. What does that mean?

A computer is like a brain. There’s a part that does the thinking (the ALU). Near that, there’s some short term memory (the registers). These are grouped together on the CPU. Then there’s longer term memory, which is RAM.

CPU with ALU (the part that does the thinking) and registers (short term memory)

Early computers could only think one thing at a time using this CPU. But over the last decade, CPUs have shifted to having multiple ALUs and registers, grouped together in cores. This means that the CPU can think multiple things at once — in parallel.

CPU chip with multiple cores containing ALUs and registers

Quantum CSS makes use of this recent feature of computers by splitting up style computation for the different DOM nodes across the different cores.

This might seem like an easy thing to do… just split up the branches of the tree and do them on different cores. It’s actually much harder than that for a few reasons. One reason is that DOM trees are often uneven. That means that one core will have a lot more work to do than others.

Imbalanced DOM tree being split between multiple cores so one does all the work

To balance the work more evenly, Quantum CSS uses a technique called work stealing. When a DOM node is being processed, the code takes its direct children and splits them up into 1 or more “work units”. These work units get put into a queue.

Cores segmenting their work into work units

When one core is done with the work in its queue, it can look in the other queues to find more work to do. This means we can evenly divide the work without taking time up front to walk the tree and figure out how to balance it ahead of time.

Cores that have finished their work stealing from the core with more work

In most browsers, it would be hard to get this right. Parallelism is a known hard problem, and the CSS engine is very complex. It’s also sitting between the two other most complex parts of the rendering engine — the DOM and layout. So it would be easy to introduce a bug, and parallelism can result in bugs that are very hard to track down, called data races. I explain more about these kinds of bugs in another article.

If you’re accepting contributions from hundreds or thousands of engineers, how can you program in parallel without fear? That’s what we have Rust for.

Rust logo

With Rust, you can statically verify that you don’t have data races. This means you avoid tricky-to-debug bugs by just not letting them into your code in the first place. The compiler won’t let you do it. I’ll be writing more about this in a future article. In the meantime, you can watch this intro video about parallelism in Rust or this more in-depth talk about work stealing.

With this, CSS style computation becomes what’s called an embarrassingly parallel problem — there’s very little keeping you from running it efficiently in parallel. This means that we can get close to linear speed ups. If you have 4 cores on your machine, then it will run close to 4 times faster.

Speed up restyles with the Rule Tree

For each DOM node, the CSS engine needs to go through all of the rules to do selector matching. For most nodes, this matching likely won’t change very often. For example, if the user hovers over a parent, the rules that match it may change. We still need to recompute style for its descendants to handle property inheritance, but the rules that match those descendants probably won’t change.

It would be nice if we could just make a note of which rules match those descendants so we don’t have to do selector matching for them again… and that’s what the rule tree—borrowed from Firefox’s previous CSS engine— does.

The CSS engine will go through the process of figuring out the selectors that match, and then sorting them by specificity. From this, it creates a linked list of rules.

This list is going to be added to the tree.

A linked list of rules being added to the rule tree

The CSS engine tries to keep the number of branches in the tree to a minimum. To do this, it will try to reuse a branch wherever it can.

If most of the selectors in the list are the same as an existing branch, then it will follow the same path. But it might reach a point where the next rule in the list isn’t in this branch of the tree. Only at that point will it add a new branch.

The last item in the linked list being added to the tree

The DOM node will get a pointer to the rule that was inserted last (in this example, the div#warning rule). This is the most specific one.

On restyle, the engine does a quick check to see whether the change to the parent could potentially change the rules that match children. If not, then for any descendants, the engine can just follow the pointer on the descendant node to get to that rule. From there, it can follow the tree back up to the root to get the full list of matching rules, from most specific to least specific. This means it can skip selector matching and sorting completely.

Skipping selector matching and sorting by specificity

So this helps reduce the work needed during restyle. But it’s still a lot of work during initial styling. If you have 10,000 nodes, you still need to do selector matching 10,000 times. But there’s another way to speed that up.

Speed up initial render (and the cascade) with the style sharing cache

Think about a page with thousands of nodes. Many of those nodes will match the same rules. For example, think of a long Wikipedia page… the paragraphs in the main content area should all end up matching the exact same rules, and have the exact same computed styles.

If there’s no optimization, then the CSS engine has to match selectors and compute styles for each paragraph individually. But if there was a way to prove that the styles will be the same from paragraph to paragraph, then the engine could just do that work once and point each paragraph node to the same computed style.

That’s what the style sharing cache—inspired by Safari and Chrome—does. After it’s done processing a node, it puts the computed style into the cache. Then, before it starts computing styles on the next node, it runs a few checks to see whether it can use something from the cache.

Those checks are:

  • Do the 2 nodes have the same ids, classes, etc? If so, then they would match the same rules.
  • For anything that isn’t selector based—inline styles, for example—do the nodes have the same values? If so, then the rules from above either won’t be overridden, or will be overridden in the same way.
  • Do both parents point to the same computed style object? If so, then the inherited values will also be the same.

 yes

Those checks have been in earlier style sharing caches since the beginning. But there are a lot of other little cases where styles might not match. For example, if a CSS rule uses the :first-child selector, then two paragraphs might not match, even though the checks above suggest that they should.

In WebKit and Blink, the style sharing cache would give up in these cases and not use the cache. As more sites use these modern selectors, the optimization was becoming less and less useful, so the Blink team recently removed it. But it turns out there is a way for the style sharing cache to keep up with these changes.

In Quantum CSS, we gather up all of those weird selectors and check whether they apply to the DOM node. Then we store the answers as ones and zeros. If the two elements have the same ones and zeros, we know they definitely match.

first-child

If a DOM node can share styles that have already been computed, you can skip pretty much all of the work. Because pages often have many DOM nodes with the same styles, this style sharing cache can save on memory and also really speed things up.

Skipping all of the work

Conclusion

This is the first big technology transfer of Servo tech to Firefox. Along the way, we’ve learned a lot about how to bring modern, high-performance code written in Rust into the core of Firefox.

We’re very excited to have this big chunk of Project Quantum ready for users to experience first-hand. We’d be happy to have you try it out, and let us know if you find any issues.

Categorieën: Mozilla-nl planet

Fake news: Mozilla joins the fight to stop it polluting the web - Naked Security

Nieuws verzameld via Google - di, 22/08/2017 - 15:16

Naked Security

Fake news: Mozilla joins the fight to stop it polluting the web
Naked Security
The fight against fake news has a new participant: Mozilla. The organization, which wants to keep the internet a healthy public resource, has announced its Mozilla Information Trust Initiative (MITI), which is a multi-pronged effort to keep the ...

Categorieën: Mozilla-nl planet

Joshua Cranmer: A review of the solar eclipse

Mozilla planet - di, 22/08/2017 - 06:59
On Monday, I, along with several million other people, decided to view the Great American Eclipse. Since I presently live in Urbana, IL, that meant getting in my car and driving down I-57 towards Carbondale. This route is also what people from Chicago or Milwaukee would have taken, which means traffic was heavy. I ended up leaving around 5:45 AM, which puts me around the last clutch of people leaving.

Our original destination was Goreville, IL (specifically, Ferne Clyffe State Park), but some people who arrived earlier got dissatisfied with the predicted cloudy forecast, so we moved the destination out to Cerulean, KY, which meant I ended up arriving around 11:00 AM, not much time before the partial eclipse started.

Partial eclipses are neat, but they're very much a see-them-once affair. When the moon first entered the sun, you get a flurry of activity as everyone puts on the glasses, sees it, and then retreats back into the shade (it was 90°F, not at all comfortable in the sun). Then the temperature starts to drop—is that the eclipse, or this breeze that started up? As more and more gets covered, then it starts to dim: I had the impression that a cloud had just passed in front of the sun, and I wanted to turn and look at that non-existent cloud. And as the sun really gets covered, then trees start acting as pinhole cameras and the shadows take on a distinctive scalloped pattern.

A total eclipse though? Completely different. The immediate reaction of everyone in the group was to start planning to see the 2024 eclipse. For those of us who spent 10, 15, 20 hours trying to see 2-3 minutes of glory, the sentiment was not only that it was time well spent, but that it was worth doing again. If you missed the 2017 eclipse and are able to see the 2024 eclipse, I urge you to do so. Words and pictures simply do not do it justice.

What is the eclipse like? In the last seconds of partiality, everyone has their eyes, eclipse glasses on of course, staring at the sun. The thin crescent looks first like a side picture of an eyeball. As the time ticks by, the tendrils of orange slowly diminish until nothing can be seen—totality. Cries come out that it's safe to take the glasses off, but everyone is ripping them off anyways. Out come the camera phones, trying to capture that captivating image. That not-quite-perfect disk of black, floating in a sea of bright white wisps of the corona, not so much a circle as a stretched oval. For those who were quick enough, the Baily's beads can be seen. The photos, of course, are crap: the corona is still bright enough to blot out the dark disk of the moon.

Then, our attention is drawn away from the sun. It's cold. It's suddenly cold; the last moment of totality makes a huge difference. Probably something like 20°F off the normal high in that moment? Of course, it's dark. Not midnight, all-you-see-are-stars dark; it's more like a dusk dark. But unlike normal dusk, you can see the fringes of daylight in all directions. You can see some stars (or maybe that's just Venus; astronomy is not my strong suit), and of course a few planes are in the sky. One of them is just a moving, blinking light in the distance; another (chasing the eclipse?) is clearly visible with its contrail. And the silence. You don't notice the usual cacophony of sounds most of the time, but when everyone shushes for a moment, you hear the deafening silence of insects, of birds, of everything.

Naturally, we all point back to the total eclipse and stare at it for most of the short time. Everything else is just a distraction, after all. How long do we have? A minute. Still more time for staring. A running commentary on everything I've mentioned, all while that neck is craned skyward and away from the people you're talking to. When is it no longer safe to keep looking? Is it still safe—no orange in the eclipse glasses, should still be fine. How long do we need to look at the sun to damage our eyes? Have we done that already? Are the glasses themselves safe? As the moon moves off the sun, hold that stare until that last possible moment, catch the return of the Baily's beads. A bright spark of sun, the photosphere is made visible again, and then clamp the eyes shut as hard as possible while you fumble the glasses back on to confirm that orange is once again visible.

Finally, the rush out of town. There's a reason why everyone leaves after totality is over. Partial eclipses really aren't worth seeing twice, and we just saw one not five minutes ago. It's just the same thing in reverse. (And it's nice to get back in the car before the temperature gets warm again; my dark grey car was quite cool to the touch despite sitting in the sun for 2½ hours). Forget trying to beat the traffic; you've got a 5-hour drive ahead of you anyways, and the traffic is going to keep pouring onto the roads over the next several hours anyways (10 hours later, as I write this, the traffic is still bad on the eclipse exit routes). If you want to avoid it, you have to plan your route away from it instead.

I ended up using this route to get back, taking 5 hours 41 minutes and 51 seconds including a refueling stop and a bathroom break. So I don't know how bad I-57 was (I did hear there was a crash on I-57 pretty much just before I got on the road, but I didn't know that at the time), although I did see that I-69 was completely stopped when I crossed it. There were small slowdowns on the major Illinois state roads every time there was a stop sign that could have been mitigated by sitting police cars at those intersections and effectively temporarily signalizing them, but other than that, my trip home was free-flowing at speed limit the entire route.

Some things I've learned:

  • It's useful to have a GPS that doesn't require cellphone coverage to figure out your route.
  • It's useful to have paper maps to help plan a trip that's taking you well off the beaten path.
  • It's even more useful to have paper maps of the states you're in when doing that.
  • The Ohio River is much prettier near Cairo, IL than it is near Wheeling, WV.
  • The Tennessee River dam is also pretty.
  • Driving directions need to make the "I'm trying to avoid anything that smells like a freeway because it's going to be completely packed and impassable" mode easier to access.
  • Passing a car by crossing the broken yellow median will never not be scary.
  • Being passed by a car crossing the broken yellow median is still scary.
  • Driving on obscure Kentucky state roads while you're playing music is oddly peaceful and relaxing.
  • The best test for road hypnosis is seeing how you can drive a long, straight, flat, featureless road. You have not seen a long, straight, flat, featureless road until you've driven something like an obscure Illinois county road where the "long, straight" bit means "20 miles without even a hint of a curve" and the "featureless" means "you don't even see a house, shed, barn, or grain elevator to break up corn and soy fields." Interstates break up the straight bit a lot, and state highways tend to have lots of houses and small settlements on them that break up endless farm fields.
  • Police direction may not permit you to make your intended route work.
Categorieën: Mozilla-nl planet

Mozilla Marketing Engineering & Ops Blog: MozMEAO SRE Status Report - August 22, 2017

Mozilla planet - di, 22/08/2017 - 02:00

Here’s what happened on the MozMEAO SRE team from August 15th - August 22nd.

Current work MDN Migration to AWS Upcoming Portland Deis 1 cluster decommissioning

The Deis 1 cluster in Portland decommissioning has been pushed out until next week due to support issues related to other applications.

Links
Categorieën: Mozilla-nl planet

Air Mozilla: Mozilla Weekly Project Meeting, 21 Aug 2017

Mozilla planet - ma, 21/08/2017 - 20:00

Mozilla Weekly Project Meeting The Monday Project Meeting

Categorieën: Mozilla-nl planet

Air Mozilla: Mozilla Weekly Project Meeting, 21 Aug 2017

Mozilla planet - ma, 21/08/2017 - 20:00

Mozilla Weekly Project Meeting The Monday Project Meeting

Categorieën: Mozilla-nl planet

Mozilla GFX: WebRender newsletter #2

Mozilla planet - ma, 21/08/2017 - 17:38

Here comes the second installment of the WebRender newsletter. Last week’s newsletter had some instructions about enabling WebRender but I apparently didn’t make it clear enough that the Gecko integration is still in a very rough shape and will be for a while. If Gecko+WebRender spectacularly crashes at startup or renders some things incorrectly on your computer, worry not, it is to be expected. We’ll fix these issues in due time and we will let you know through this newsletter when WebRender gets to a dogfoodable state, and later when it is ready for use by a wider audience.

Notable WebRender changes
  • This week saw mostly bug fixes in the WebRender repo.
Notable Gecko changes
  • The texture cache rewrite has landed in gecko.
  • All text (including shadows and decorations) are handled by WebRender now. This is probably the most noticeable performance improvement of the week. Our current blob image path for fonts is very slow (That will be fixed by bug 1380014).
  • APZ works in layers-free now.
  • Removed a bunch of malloc/free from blob image playback. This will speed up blob image playback especially when there are multiple blob images to be played back because we don’t end up running into the malloc/free lock.
  • Support for perspective transforms.

Categorieën: Mozilla-nl planet

The Mozilla Blog: Welcome Michael DeAngelo, Chief People Officer

Mozilla planet - ma, 21/08/2017 - 17:00

Michael DeAngelo joins the Mozilla leadership team this week as Chief People Officer.

As Chief People Officer, Michael is responsible for all aspects of HR and Organizational Development at Mozilla Corporation with an overall focus on ensuring we’re building and growing a resilient, high impact global organization as a foundation for our next decade of growth and impact.

Michael brings two decades of experience leading people teams at Pinterest, Google and Pepsico. Earlier in his career Michael held a number of HR roles in Organization Development, Compensation, and People Operations at Microsoft, Merck and AlliedSignal.

At Pinterest, Michael built out the majority of the HR function. One of the most important teams was the Diversity and Inclusion function which is recognized as one of the best in the industry. Two of his proudest moments there were being the first company ever to set public diversity goals. and growing new hires from under-represented backgrounds from 1% to 9% in one year.

Michael brings a global perspective from his tenure at Google, where for four years he led HR for the Europe/Middle East/Africa region based in Zurich, Switzerland. At Google he also led the HR team supporting 10,000 employees for Search, Android, Chrome, and Google+. Prior to Google, Michael was Vice President of HR at Pepsico leading all people functions for the Quaker Foods global P&L.

“Having spent so much of my career in technology, I have long been an admirer of Mozilla and the important contributions it has made to keeping the Internet open and accessible to all. This is an exciting time for Mozilla as we’re about to deliver a completely revitalized Firefox, we’re ramping investments in new emerging technologies and we’re making important strides in fighting for a healthier Internet platform for all. I am excited to come on board and support the continued development and growth of the organization’s talent and capabilities to help us reach our goals.”

Michael will be based in the Bay Area and will work primarily out of our San Francisco office.

Welcome Michael!

chris

The post Welcome Michael DeAngelo, Chief People Officer appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

Welcome Michael DeAngelo, Chief People Officer

Mozilla Blog - ma, 21/08/2017 - 17:00

Michael DeAngelo joins the Mozilla leadership team this week as Chief People Officer.

As Chief People Officer, Michael is responsible for all aspects of HR and Organizational Development at Mozilla Corporation with an overall focus on ensuring we’re building and growing a resilient, high impact global organization as a foundation for our next decade of growth and impact.

Michael brings two decades of experience leading people teams at Pinterest, Google and Pepsico. Earlier in his career Michael held a number of HR roles in Organization Development, Compensation, and People Operations at Microsoft, Merck and AlliedSignal.

At Pinterest, Michael built out the majority of the HR function. One of the most important teams was the Diversity and Inclusion function which is recognized as one of the best in the industry. Two of his proudest moments there were being the first company ever to set public diversity goals. and growing new hires from under-represented backgrounds from 1% to 9% in one year.

Michael brings a global perspective from his tenure at Google, where for four years he led HR for the Europe/Middle East/Africa region based in Zurich, Switzerland. At Google he also led the HR team supporting 10,000 employees for Search, Android, Chrome, and Google+. Prior to Google, Michael was Vice President of HR at Pepsico leading all people functions for the Quaker Foods global P&L.

“Having spent so much of my career in technology, I have long been an admirer of Mozilla and the important contributions it has made to keeping the Internet open and accessible to all. This is an exciting time for Mozilla as we’re about to deliver a completely revitalized Firefox, we’re ramping investments in new emerging technologies and we’re making important strides in fighting for a healthier Internet platform for all. I am excited to come on board and support the continued development and growth of the organization’s talent and capabilities to help us reach our goals.”

Michael will be based in the Bay Area and will work primarily out of our San Francisco office.

Welcome Michael!

chris

The post Welcome Michael DeAngelo, Chief People Officer appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

The Firefox Frontier: Outfoxin’ the Trackers: Android Private Browsing with Firefox Focus

Mozilla planet - ma, 21/08/2017 - 14:49

Want to avoid trackers when you click links in Android apps? Set Firefox Focus as your default. It’s hard not to appreciate the ingenuity (and snark) of Redditors. These frontierspeople of … Read more

The post Outfoxin’ the Trackers: Android Private Browsing with Firefox Focus appeared first on The Firefox Frontier.

Categorieën: Mozilla-nl planet

Firefox 57: So will Mozilla endlich sein Browser-Comeback schaffen ... - STERN

Nieuws verzameld via Google - zo, 20/08/2017 - 14:06

STERN

Firefox 57: So will Mozilla endlich sein Browser-Comeback schaffen ...
STERN
Jahrelang war Mozillas Firefox in Deutschland der Browser der Wahl. Dann lief Chrome ihm den Rang ab. Jetzt will der Fuchs endlich den Sprung zurück auf ...
Mozilla-Manager: Firefox 57 wird Chrome in vielen Fällen schlagen ...derStandard.at

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

Kartikaya Gupta: Firewalling, part 2

Mozilla planet - zo, 20/08/2017 - 00:57

I previously wrote about setting up multiple VLANs to segment your home network and improve the security characteristics. Since then I've added more devices to my home network, and keeping everything in separate VLANs was looking like it would be a hassle. So instead I decided to put everything into the same VLAN but augment the router's firewall rules to continue restricting traffic between "trusted" and "untrusted" devices.

The problem is that didn't work. I set up all the firewall rules but for some reason they weren't being respected. After (too much) digging I finally discovered that you have to install the kmod-ebtables package to get this to actually work. Without it, the netfilter code in the kernel doesn't filter traffic between hosts on the same VLAN and so any rules you have for that get ignored. After installing kmod-ebtables my firewall rules started working. Yay!

Along the way I also discovered that OpenWRT is basically dead now (they haven't had a release in a long time) and the LEDE project is the new fork/successor project. So if you were using OpenWRT you should probably migrate. The migration was relatively painless for me, since the images are compatible.

There's one other complication that I've run into but haven't yet resolved. After upgrading to LEDE and installing kmod-ebtables, for some reason I couldn't connect between two FreeBSD machines on my network via external IP and port forwarding. The setup is like so:

  • Machine A has internal IP address 192.168.1.A
  • Machine B has internal IP address 192.168.1.B
  • The router's external IP address is E
  • The router is set to forward port P to machine A
  • The router is set to forward port Q to machine B

Now, from machine B, if connect to E:P, it doesn't work. Likewise, from machine A, connecting to E:Q doesn't work. I can connect using the internal IP address (192.168.1.A:P or 192.168.1.B:Q) just fine; it's only the via the external IP that it doesn't work. All the other machines on my network can connect to E:P and E:Q fine as well. It's only machines A and B that can't talk to each other. The thing A and B have in common is they are running FreeBSD; the other machines I tried were Linux/OS X.

Obviously the next step here is to fire up tcpdump and see what's going on. Funny thing is, when I run tcpdump on my router, the problem goes away and the machines can connect to each other. So there's that. I'm sure with more investigation I'll get to the bottom of this but for now I've shelved it under "mysteries that I can work around easily". If anybody has run into this before I'd be interested in hearing about it.

Also if anybody knows of good tools to visualize and debug iptables rules I'd be interested to try them out, because I haven't found anything good yet. I've been using the counters in the tables to try and figure out which rules the packets are hitting but since I'm debugging this "live" there's a lot of noise from random devices and the counters are not as reliable as I'd like.

Categorieën: Mozilla-nl planet

Robert Kaiser: Celebrating LCARS With One Last Theme Release

Mozilla planet - zo, 20/08/2017 - 00:21
30 years ago, a lot of people were wondering what the new Star Trek: The Next Generation series would bring when it would debut in September 1987. The principal cast had been announced, as well as having a new Enterprise and even the pilot's title was known, but - as always with a new production - a lot of questions were open, just like today in 2017 with Star Trek Discovery, which is set to debut in September almost to the day on the 30th anniversary of The Next Generation.

Given that the story was set to play 100 years after the original and what was considered "futuristic" had significantly changed between the late 1960s and 1980s, the design language had to be significantly updated, including the labels and screens on the new Enterprise. Scenic art supervisor and technical consultant Michael Okuda, who had done starship computer displays for The Voyage Home, was hired to do those for the new series, and was instructed by series creator and show runner Gene Roddenberry that this futuristic ship should have "simple and clean" screens and not much animation (the latter probably also due to budget and technology constraints - the "screens" were built out of colored plexiglass with lights behind them).



With that, Okuda created a look that became known as "LCARS" (for Library Computer Access and Retrieval System (which actually was the computer system's name). Instead of the huge gray panels with big brightly-colored physical buttons in the original series, The Next Generation had touch-screen panels with dark background and flat-style buttons in pastel color tones. The flat design including the fonts and flat-design frames are very similar to quite a few designs we see on touch-friendly mobile apps 30 years later. Touch screens (and even cell phones and tablets) were pretty much unheard of and "future talk" when Mike Okuda created those designs, but he came to pretty similar design conclusions as those who design UIs for modern touch-screen devices (which is pretty awesome when you think of it).

I was always fascinated with that style of UI design even on non-touch displays (and am even more so now that I'm using touch screens daily), and so 18 years ago, when I did my first experiments with Mozilla's new browser-mail all-in-one package and realized that the UI was displayed with the same rendering engine and the same or very similar technologies as websites, I immediately did some CSS changes to see if I could apply LCARS-like styling to this software - and awesomeness ensued when I found out that it worked!

Image No. 23114

Over the years, I created a full LCARStrek theme from those experiments (first release, 0.1, was for Mozilla suite nightlies in late 2000), adapted it to Firefox (starting with LCRStrek 2.1 for Firefox 4), refined it and even made it work with large Firefox redesigns. But as you may have heard, huge changes are coming to Firefox add-ons, and full-blown themes in a manner of LCARStrek cannot be done in the new world as it stands right now, so I'm forced to stop developing this theme.

Image No. 23308

Given that LCARS has a huge anniversary this year, I want to end my work on this theme on a high instead of a too sad a note though, so right along the very awesome Star Trek Las Vegas convention, which just celebrated 30 years of The Next Generation, of course, I'm doing one last LCARStrek release this weekend, with special thanks to Mike Okuda, whose great designs made this theme possible in the first place (picture taken by myself at that convention just two weeks ago, where he was talking about the backlit LCARS panels that were dubbed "Okudagrams" by other crew members):
Image No. 23314

Live long and prosper!
Categorieën: Mozilla-nl planet

Robert Kaiser: Lantea Maps: GPS Track Upload to OpenStreetMap Broken

Mozilla planet - za, 19/08/2017 - 16:49
During my holidays, when I was using Lantea Maps daily to record my GPS tracks, I suddenly found out one day that upload of the tracks to OpenStreetMap was broken.

I had added that functionality so that people (including myself) could get their GPS tracks out of their mobile devices and into a place from which they can download them anywhere. A bonus was that the tracks were available to the OpenStreetMap project as guides to improve the maps.

After I had wasted about EUR 50 of data roaming costs to verify that it was not only broken on hotel networks but also my mobile network that usually worked, I tried on a desktop Nightly and used the Firefox devtools to find out the actual error message, which was a CORS issue. I filed a GitHub issue but apparently it was an intentional change and OpenStreetMap doesn't support GPS track uploads any more in a way that is simple for pure web apps and also doesn't want to re-add support for that. Find more details in the GitHub issue.

Because of that, I think that this will mark the end of uploading tracks from Lantea Maps to OpenStreetMap. When I have time, I will probably add a GPS track store on my server instead, where third-party changes can't break stuff while I'm on vacation. If any Lantea Maps user wants their tracks on OpenStreetMap in the future, they'll need to manually upload the tracks themselves.
Categorieën: Mozilla-nl planet

J.C. Jones: The State of CRLs Today

Mozilla planet - vr, 18/08/2017 - 23:41

Certificate Revocation Lists (CRLs) are a way for Certificate Authorities to announce to their relying parties (e.g., users validating the certificates) that a Certificate they issued should no longer be trusted. E.g., was revoked.

As the name implies, they're just flat lists of revoked certificates. This has advantages and disadvantages:

Advantages:

  • It's easy to see how many revocations there are
  • It's easy to see differences from day to day
  • Since processing the list is up to the client, it doesn't reveal what information you're interested in

Disadvantages:

  • They can quickly get quite big, leading to significant latency while downloading a web page
  • They're not particularly compressible
  • There's information in there you probably will never care about

CRLs aren't much used anymore; Firefox stopped checking them in version 28 in 2014, in favor of online status checks (OCSP).

The Baseline Requirements nevertheless still require that CRLs, if published, remain available:

4.10.2 Service availability

The CA SHALL operate and maintain its CRL and OCSP capability with resources sufficient to provide a response time of ten seconds or less under normal operating conditions.

Since much as been written about the availability of OCSP, I thought I'd check-in on CRLs.

Collecting available CRLs

When a certificate's status will be available in a CRL, that's encoded into the certificate itself (RFC 5280, 4.2.1.13). If that field is there, we should expect the CRL to survive for the lifetime of the certificate.

I went to Censys.io and after a quick request to them for SQL access, I ran this query:

SELECT parsed.extensions.crl_distribution_points FROM certificates.certificates WHERE validation.nss.valid = true AND parsed.extensions.crl_distribution_points LIKE 'http%' AND parsed.validity.end >= '2017-07-18 00:00' GROUP BY parsed.extensions.crl_distribution_points

Today, this yields 3,035 CRLs, the list of which I've posted on Github.

Downloading those CRLs into a directory downloaded_crls can be done serially using wget quite simply, logging to a file named wget_log-all_crls.txt:

mkdir downloaded_crls script wget_log-all_crls.txt wget --recursive --tries 3 --level=1 --force-directories -P downloaded_crls/ --input-file=all_crls.csv

This took 2h 36m 31s on my Internet connection.

Analyzing the Download Process

Out of 3,035 CRLs, I ended up downloading 2,993 files. The rest failed.

I post-processed the command line wget log (wget_log-all_crls.txt) using a small Python script to categorize each CRL download by how it completed.

Ignoring all the times when requesting a file resulted in the file straightaway (hey, those cases are boring), here's the graphical breakdown of the other cases:

Problems with CRL Downloads

Missing CRLs

There are 40 CRLs that weren't available to me when I checked, or more simply put, 1% of CRLs appear to be dead.

Some of them are dead in temporary-looking ways, like the load balancer giving a 500 Internal Server Error, some of them have hostnames that aren't resolving in DNS.

These aren't currently resolving for me:

Searching Censys' dataset, these CRLs are only used by intermediate CAs, so presumably if one of the handful of CA certificates covered would need to be revoked, their IT staff could fix these links.

Except for http://atospki/, which is clearly an internal name. Mistakes like that can only be revoked via technologies like OneCRL and CRLSets.

The complete list of 400s, 404s, and timeouts by URL is available in crl_resolutions.csv.

Are the missing CRLs a problem?

This doesn't attempt to eliminate possible false-positives where the CRL was for a certificate which is revoked by its parent. For example, if there is a chain Root -> A -> B -> C, and A is revoked, it may not be important that A's CRL exist. (Thanks, @sleevi for pointing this out!)

Redirects

As could be expected, there were a fair number of CRLs which are now serviced by redirects. Interestingly, while section 7.1.2.2(b) of the Baseline Requirements require CRLs to have a "HTTP URL", 13 of the CRL fetches redirect to HTTPS, two of them through HSTS headers [1].

There was a recent thread on Mozilla.dev.security.policy about OCSP responders that were only available over HTTPS; these are problematic as OCSP and CRLs are used to decide whether a secure connection is possible. Having to make such a determination for the revocation check leads to a potential deadlock, so most software will refuse to try it.

Interestingly, there's one CRL that is encoded as HTTPS directly in certificates: https://crl.firmaprofesional.com/fproot.crl [Censys.io search][Example at crt.sh] That's pretty clearly a violation of the Baseline Requirements.

Sizes

I've generally understood that most CRLs are small, but some are very large, so I expected some kind of bi-modal distribution. It's really not, though the retrieved CRLs do have a wild size distribution:

Size Distribution of CRLs

In table form [2]:

Size Buckets# of CRLs 0.5 KB174 0.5 KB to 0.625 KB264 0.625 KB to 0.75 KB246 0.75 KB to 1 KB310 1 KB to 2 KB366 2 KB to 4 KB237 4 KB to 8 KB232 8 KB to 32 KB500 32 KB to 64 KB297 64 KB to 128 KB218 128 KB to 1 MB106 1 MB to 8 MB33 8 MB to 128 MB9

I figured that most CRLs would be tiny, and we'd have a handful of outliers. Indeed, 50% of the CRLs are less than 4 Kbytes, and 75% are less than 32 Kbytes:
Cumulative Distribution of CRL size

On the top end, however, are 9 CRLs larger than 8 MB:

URLSize http://www.sk.ee/repository/crls/esteid2011.crl66.57 MB http://crl.godaddy.com/repository/mastergodaddy2issuing.crl36.22 MB http://crl.eid.belgium.be/eidc201208.crl16.03 MB http://crl.eid.belgium.be/eidc201204.crl10.84 MB http://crl.eid.belgium.be/eidc201207.crl10.82 MB http://crl.eid.belgium.be/eidc201202.crl10.67 MB http://crl.eid.belgium.be/eidc201203.crl10.66 MB http://crl.eid.belgium.be/eidc201201.crl10.47 MB

Remember, these are part of the WebPKI, not some private hierarchy.[3] For a convenient example of why browsers don't download CRLs when connecting somewhere, just point to these.

Download Latency

Latency matters. I'm on a pretty fast Internet connection, but even so, some of the CRLs that were even reasonable sizes took a while to download. I won't harp on this, but just a quick histogram:

Histogram of CRLs bucketed by download time

CRLs that took longer than 1 second to download on a really fast Internet connection -- 142 of them, or 4.7% -- are clear reasons for users' software to not check them for live revocation status.

Conclusions (such as there are any)

CRLs are not an exciting technology, but they're still used by the Web PKI. Since they're not exciting, it appears that some CAs believe they don't even need to keep their CRLs online; I mean, who checks these things, anyway?

Oh, yeah, me...

Still, with technologies such as CRLSets depending on CRLs as a means for revocation data, they clearly still have a purpose. It's not particularly convenient to make a habit of crawling OCSP responders to figure out the state of revocations on the Web.

Footnotes

[1] Note, that's not found by the Python script ; you'll need to grep the log for "URL transformed to HTTPS due to an HSTS policy"

[2] I admit that the buckets are a bit arbitrary, but here's what it looks like without some manual massaging:
Auto-generated buckets

[3] Most of these are not realistically going to be reached by browsers, however. The largest contains revocations that appear to belong to a government's national ID card list. GoDaddy's is a master list, but is only referred to by a revoked cert [crt.sh link].

Categorieën: Mozilla-nl planet

Jared Wein: Photon Engineering Newsletter #13

Mozilla planet - vr, 18/08/2017 - 22:18

This week I’m taking over for Dolske as he takes a vacation to view the eclipse. This is issue #13 of the Photon Engineering Newsletter.

This past week the Nightly team has had some fun with the Firefox icon. We’ve seen the following icons grace Nightly builds in the past week:

The icon in the top-left was created in 2011 by Sean Martell. The icon in the top-right was the original Phoenix icon. Phoenix was later renamed Firebird, and then the name was later changed to Firefox. The icon in the bottom left was the first “Firefox” icon, designed by Steven Garrity in 2003. The icon in the bottom-right, well it is such logo with much browser, we couldn’t help ourselves to not share it.

Recent Changes Menus/structure:

The Report Site Issue button has been moved to the Page Action menu in Nightly and Dev Edition. This button doesn’t ship to users on Beta or Release.

2017-08-18_1554

Probably the biggest visual change this week is that we now have spacers in the toolbar. These help to separate the location bar from the other utility buttons, and also keep the location bar relatively centered within the window. We have also replaced the bookmarks menu button with the Library button (it’s the icon that looks like books on a shelf).

2017-08-18_1557

We also widened various panels to help fit more text in them.

Animation:

The Pin to Overflow animation has also been tweaked to not move as far. This will likely be the final adjustment to this animation (seen on the left). The Pocket button has moved to the location bar and the button expands when a page is saved to Pocket (seen on the right).

Preferences:

Preferences has continued to work towards their own visual redesign for Firefox 57. New icons were landed for the various categories within Preferences, and some borders and margins have been adjusted.

Visual redesign:

The tab label is no longer centered on Mac. This now brings Linux, Mac, and Windows to all have the same visual treatment for tabs.

Changing to Compact density within Customize mode changes the toolbar buttons to now use less horizontal space. The following GIF shows the theme changing from Compact to Normal to Touch densities.

density

Onboarding:

New graphics for the onboarding tour have landed.

Performance:

Two of the main engineers focusing on Performance were on PTO this past week so we don’t have an update from them.


Tagged: firefox, photon, planet-mozilla
Categorieën: Mozilla-nl planet

Mitchell Baker: Resignation as co-chair of the Digital Economy Board of Advisors

Mozilla planet - vr, 18/08/2017 - 21:12

For the past year and a half I have been serving as one of two co-chairs of the U.S. Commerce Department Digital Economy Board of Advisors. The Board was appointed in March 2016 by then-Secretary of Commerce Penny Pritzer to serve a two year term. On Thursday I sent the letter below to Secretary Ross.

Dear Secretary Ross,
I am resigning from my position as a member and co-chair of the Commerce Department’s Digital Economy Board of Advisors, effective immediately.
It is the responsibility of leaders to take action and lift up each and every American. Our leaders must unequivocally denounce bigotry, racism, sexism, hate, and violence.
The digital economy is fundamental to creating an economy that offers opportunity to all Americans. It has been an honor to serve as member and co-chair of this board and to work with the Commerce Department staff.
Sincerely,
Mitchell Baker
Executive Chairwoman
Mozilla

Categorieën: Mozilla-nl planet

Pagina's