mozilla

Mozilla Nederland LogoDe Nederlandse
Mozilla-gemeenschap

Take control over your data with Rally, a novel privacy-first data sharing platform

Mozilla Blog - vr, 25/06/2021 - 12:00

Mozilla teams up with Princeton University researchers to enable crowdsourced science for public good; collaborates with research groups at Princeton, Stanford on upcoming studies.

Your data is valuable. But for too long, online services have pilfered, swapped, and exploited your data without your awareness. Privacy violations and filter bubbles are all consequences of a surveillance data economy. But what if, instead of companies taking your data without giving you a say, you could select who gets access to your data and put it to work for public good?

Today, we’re announcing the Mozilla Rally platform. Built for the browser with privacy and transparency at its core, Rally puts users in control of their data and empowers them to contribute their browsing data to crowdfund projects for a better Internet and a better society. At Mozilla, we’re working on building a better internet, one that puts people first, respects their privacy and gives them power over their online experience. We’ve been a leader in privacy features that help you control your data by blocking trackers. But, being “data-empowered” also requires the ability to choose who you want to access your data. 

“Cutting people out of decisions about their data is an inequity that harms individuals, society and the internet. We believe that you should determine who benefits from your data. We are data optimists and want to change the way the data economy works for both people and day-to-day business. We are excited to see how Rally can help understand some of the biggest problems of the internet and make it better.”

Rebecca Weiss, Rally Project Lead

As a first step on this journey, we’re launching the new Rally research initiative, a crowdsourced scientific effort we developed in collaboration with professor Jonathan Mayer’s research group at Princeton University. Computer scientists, social scientists and other researchers will be able to launch groundbreaking studies about the web and invite you to participate. A core focus of the initiative is enabling unprecedented studies that hold major online services accountable.

“Online services constantly experiment on users, to maximize engagement and profit. But for too long, academic researchers have been stymied when trying to experiment on online services. Rally flips the script and enables a new ecosystem of technology policy research.”

Jonathan Mayer, Princeton’s Center for Information Technology Policy

We’re kickstarting the Mozilla Rally research initiative with our first two research collaborator studies. Our first study is “Political and COVID-19 News” and comes from the Princeton team that helped us develop the Rally research initiative. This study examines how people engage with news and misinformation about politics and COVID-19 across online services.  

Soon, we’ll also be launching our second academic study, “Beyond the Paywall”, a study, in partnership with Shoshana Vasserman and Greg Martin of the Stanford University Graduate School of Business. It aims to better understand news consumption, what people value in news and the economics that could build a more sustainable ecosystem for newspapers in the online marketplace.

“We need research to get answers to the hard questions that we face as a society in the information age. But for that research to be credible and reliable, it needs to be transparent, considered and treat every participant with respect. It sounds simple but this takes a lot of work. It needs a standard bearer to make it the expectation in social science. In working with Rally, we hope to be part of that transformation.”

Shoshana Vasserman, Assistant Professor of Economics at the Stanford Graduate School of Business

We are also launching a new toolkit today, WebScience, that enables researchers to build standardized browser-based studies on Rally. WebScience also encourages data minimization, which is central to how Rally will respect people who choose to participate in studies. WebScience was developed and open sourced by Jonathan Mayer’s team at Princeton and is now co-maintained with Mozilla. 

With Rally, we’ve built an innovative, consent-driven data sharing platform that puts power back into the hands of people. By leveraging the scale of web browsers – a piece of software used by billions of people around the world – Rally has the potential to help address societal problems we could not solve before. Our goal is to demonstrate that there is a case for an equitable market for data, one where every party is treated fairly, and we welcome mission-aligned organizations that want to join us on this journey. 

Rally is currently available for Firefox desktop users over age 19 in the United States. We plan to launch Rally for other web browsers and in other countries in the future. 

To participate in Rally, join us at rally.mozilla.org

————————————————————————————

Interested in joining Rally and want to know how it works?

When you join Rally, you have the opportunity to participate in data crowdsourcing projects — we call them “studies” — focused on understanding and finding solutions for social problems caused by the data economy. You will always see a simple explanation of a study’s purpose, the data it collects, how the data will be used, and who will have access to your data. All your data is stored in Mozilla’s restricted servers, and access to the analysis environment is tightly controlled. For those who really want to dig deep, you can read our detailed disclosures and even inspect our code

The post Take control over your data with Rally, a novel privacy-first data sharing platform appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

Mozilla Racial Justice Commitments: One Year In

Mozilla Blog - do, 24/06/2021 - 02:25

One year ago, we made a set of commitments to make diversity and inclusion more than a catchphrase or hot button topic. We decided to roll up our sleeves and get busy establishing significant goals, putting resources behind them and making sure that everyone, including our company leadership, was taking action to create a more diverse and equitable place at Mozilla and in society.

We have taken steps to address the issue of anti-Black racism and the lack of diversity and inclusion in our company, and hopefully, in society, through programming and people initiatives.  We have seen a significant increase in participation in diversity and inclusion initiatives, and perhaps, equally important, in our engagement survey results and in particular the increased scores on diversity and inclusion questions by people of color and women. While we have made strides on many of the goals established on June 18, 2020, we recognize this progress is the “First Step Toward Lasting Change.”  We continue to be committed through our actions and resources to improve Mozilla as a place to work for people of color and the internet for all.

1. Who we are: Our employee base and our communities

In our upcoming diversity and inclusion disclosure, you will find that we have greatly invested in improving diversity and enhancing a culture of inclusion at Mozilla. Through a balance of fun, education, celebration and conversations, we created safe spaces for people of color to share the totality of their human experience, honoring the beauty and joy of their lives and holding space to contend with the more sobering and harsh realities of race in society. 

We hosted three  panel discussions that each covered pertinent and insightful topics as designed by our Mozilla Resource Groups. There were the ones that gave us belly laughs – “What does it mean to lose your black card?” – and there were the ones that challenged us – “What is the impact of the model minority myth?” 

We held facilitated discussions designed to provide employees with an opportunity to engage in deep listening and sharing following an onslaught of racial violence across the U.S. These sessions, aptly named Gather @Mozilla, gave us an opportunity to collectively process some of the traumatic and triggering events happening around us. 

Our goal was to provide various options for employees to connect and learn. Recognizing that learning is a personal experience, we offered paths for individual learning and collective learning. We published resource libraries (and shared them publicly: Black History Month, Asian Pacific Islander Heritage Month), hosted virtual cooking lessons, convened talks with renowned authors, curated music playlists (Latin and Hispanic Heritage Month, Black History Month, Women’s History Month, API Heritage Month Playlist) and much more. By providing a breadth of opportunities to celebrate (Latin and Hispanic Heritage Month celebration, Black History Month celebration, Women’s History Month celebration, and Asian Pacific Islander Heritage Month celebration), we increased participation and invited our organization on a journey of co-creating an inclusive culture.  

As we round out the second half of 2021, we will be rolling out an Inclusion Champion program, working with DEI councils within each business group to promote organization-specific D&I programming, deploying a D&I skill development platform, and diversifying our talent acquisition pipeline.

2. What we build: Our outreach with our products

At Mozilla, we work to build a better internet and our products can help elevate the best of the internet. Through Pocket Collections, selections of stories curated by Pocket editors and guest editors, we introduced Collections that elevated diverse voices and gave insight into issues impacting BIPOC communities and the context around which they emerged (Racial Justice Collections, Essential Reading: Celebrating Juneteenth). We hoped to provide readers with content and perspectives they may not otherwise encounter.

We understood that when you point a finger at someone else, there is a finger pointing back at you. Thus, we launched a project that examined when and where biases creep into user research and design and initiated work efforts to reduce the amount of racist language in code (Remove all references to blacklist/whitelist within Gecko, Remove references to slave).

In the second half of 2021, our product teams will continue to identify opportunities to elevate diverse voices and combat unconscious biases in our products.

3. What we do beyond products: Our broader engagement with the world

We leveraged Dialogues & Debates, a speaker series, to address issues of A.I. and race and ethnicity and the challenges presented to communities of color because of this problem in tech and media. We had robust discussions about the use of technology to surveil historically vulnerable populations and used our network to call on fellow technology companies to be mindful of how they use technology in service to the criminal justice system instead of the communities of color we serve. The Mozilla Foundation launched campaigns calling on Nextdoor and Amazon Ring to pause their relationships with police departments and assess the impact of the platforms on users and communities of color. More than 28,000 people signed the petitions and several organizations partnered with Mozilla on escalation actions. 

We were able to have these critical community discussions and collaborations by being more thoughtful and intentional with the ways in which we used available funding from Mozilla Foundation in our commitment to social justice in tech and society. We granted 33% of Mozilla Foundation funds to black-led tech and social justice initiatives. Unfortunately, we fell short of our 40% target. While some may see this as a failure, we see it as an opportunity to acknowledge an area where we still need improvement and to commit to continuing to fund and elevate voices of color.

We also partnered with three Historically Black Colleges and Universities Engineering and Computer Science programs to promote the role of African Americans in tech, to engage in ethical computing discussions, and to cultivate relationships with aspiring scientists, designers and tech leaders so they understand there is a place for them in this industry.

Over the coming year, we are looking forward to deepening our relationships with institutions that serve and support communities of color and communities that have been historically marginalized. The First Step Toward Lasting Change squarely moves us along the journey of diversity, equity, inclusion and belonging but is not the middle nor final step. There remains significant room for improvement and we are committed to continue the course in closing the gaps that exist in tech and society.  

The post Mozilla Racial Justice Commitments: One Year In appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

Gary Linden, legendary surfer & Firefox fan

Mozilla Blog - vr, 18/06/2021 - 18:00

On the internet you are never alone, and because of that at Mozilla we know that we can’t work to build a better internet alone. We believe in and rely on our community — from our volunteers, to our staff, to our users and even the parent’s of our staff (who also happen to be some of our power users). For Father’s Day, Mozilla’s Natalie Linden sat down with her father, big wave surf legend and surfboard maker, Gary Linden to talk the ocean, the internet and where humanity goes from here.

We should probably start by telling people who we are. I am Natalie Linden, the Director of the Creative Studio in Mozilla marketing.

And I’m Gary Linden. I’m your father. That’s probably my best accomplishment.

Awww Dad.

I make surfboards, run surfing events and surf. I’m semi-retired. Sort of.

Gary Linden

I don’t think you’re giving yourself enough credit. When I tell people I’m Gary Linden’s daughter, they always say “Gary Linden?! He’s a legend!”

You know, if you’re involved in something for all your life, and you do a reasonably good job, you’ll get old and then you’ll be the oldest one around. So of course you’ll be the legend! 

One of the things you’re the oldest guy doing is paddling into really, really big waves. 

Yeah I’m a big wave surfer, that’s been my passion. I wasn’t afraid of the ocean or of big waves, and that set me apart from most other surfers. So I got admission to a club that was pretty exclusive. And that was pretty cool. Then I started the Big Wave World Tour so younger surfers could have a career path to becoming a big wave rider. Big wave surfing takes more time and resources: you have to have the means to travel, the boards are more expensive. We weren’t seeing the younger people really be able to surf the big waves so we weren’t seeing what could be done in the peak athletic performance years. I’m pretty proud of that tour.

One of the questions I was going to ask you is why you do what you do, and I think you’re starting to answer that. The way you’ve always described it to me is that from the first time you rode a wave on a surfboard, you knew that’s what you wanted to do, and you’ve oriented your whole life around being able to surf as much as possible.

Yes. Even before I rode a surfboard, my father took me to the ocean and taught me to play in the waves, and about the currents, and body surfing. The freedom of it was like nothing else. I had asthma and hay fever, and when I was in the ocean I didn’t feel any of that. Whereas on land the pollens and the dryness just made being on the land kind of miserable. Like a fish out of water in a lot of ways. It was always rewarding for me to go into the ocean. It goes beyond just feeling good. It’s a state of mind as well. 

So you started making surfboards, too. 

I started making surfboards because surfing went into a transitional period — we all had longboards and then in the 70s, some of the Australians started experimenting with boards that were a foot shorter. There was nobody in San Diego making them, so I got a blank and shaped a board. And then I started making them for my friends, and it just set me on a path. But I’ve always made surfboards so that I could have the boards I needed to surf. If somebody else wanted one, that was fine, but I wasn’t making it for them. I was making it for me. Because surfing — not surfboard making — was my primary focus. 

How has the internet changed what you do?

Well first, the internet has made it incredibly easy to find out where the best waves of the day are. There are cameras all over the world now and you get surf reports. You don’t have to drive to the beach — you can live inland and plan ahead. And this year with the pandemic, live surfing competition was pretty much shut down. So a friend and I created a virtual surfing world tour called Surf Web Series, where we could take video clips of surfers who had gone out the prior year, take a little video of their best waves and then we’d put those in heats just like a regular event and judge them and take it all the way to a final like a surfing competition. That was a lot of fun because it filled the gaps for a lot of the kids who are surfing professionally but they couldn’t give anything back to their sponsors during the pandemic because they weren’t competing, they didn’t have a way to get exposure, they didn’t have a way to further their career. This gave them an opportunity to keep going in their career, and keep the world interested in the sport of surfing. It’s opened up another avenue for the sport. 

I just focus on being in the best shape I possibly can, so I can surf. And I’m going to do it as long as I can. And when I can’t stand up anymore, I’ll be on a belly board. And when I can’t do that, I’ll jump in the waves.

One of the things I really admire about you, dad, is that you never stop having ideas. You set this intention of surfing for your life, and you keep finding new ways at it. You’re 71 and you’re still growing, you’re still changing, you’re still figuring out how to use the latest tools and culture to do the thing you set out to do. It inspires me every single day. It also helps that I see it up close, because we share an office!

Well you inspire me too, because of your energy and motivation. I don’t think you’re ever going to stop either, because you are inspired, you are motivated. That’s what surfing was for me: it gave me something to focus on 100%. I love it so much, and it’s so good for me, that I don’t go snowboarding, I don’t skateboard, I don’t play football, I don’t ride bicycles. I don’t want to get hurt doing anything else. I don’t drink, or stay out at night. I just focus on being in the best shape I possibly can, so I can surf. And I’m going to do it as long as I can. And when I can’t stand up anymore, I’ll be on a belly board. And when I can’t do that, I’ll jump in the waves. I don’t really care. I just like that original feeling of going in the ocean with my dad and feeling clean and involved with the earth. My connection with the earth is the ocean. 

Speaking of staying in shape, how has your relationship with the internet changed since the pandemic?

You know the answer to this one, since we share a yoga room at our office. I started yoga about three years ago now because I wanted to be in better shape for surfing. I didn’t want to go at first because everyone was so young and as a beginner, it was intimidating. I couldn’t really keep up and felt awkward. But I found a geriatric yoga class, and it was really fun. I was getting better. Then with the pandemic, they started a zoom class. And now it’s actually even better. Because for older people, it’s still really intimidating. Now we can focus on the teacher and not feel self-conscious. It’s pretty awesome. Now you can do your work on the internet too — all the meetings and stuff. I mean, sometimes I wish the internet wasn’t there because you have to focus a lot more to stay grounded on the earth. Otherwise you’re just in that cloud. And that’s a really all-consuming place to be. I don’t think we were really made for that. So it’s another area where you have to find your balance. But you gotta find your balance in everything anyway. Even pigeon pose! 

Is there something about technology that blows your mind?

Yeah, it doesn’t ever stop. It’s like watching science fiction happen in real life. It goes so fast. I’m fortunate enough that I was born before television, so I’ve seen a lot of stuff change. It’s so rapid. If you go back in history and think about evolution, it took so long for us not to be covered in hair, and to be able to talk, and now we’re talking about having chips in our bodies to help us heal, and artificial intelligence. If you dwell on it, it’s really overwhelming for someone my age. It can be scary. But there’s a lot of positive to it, so you’ve gotta stay on that side. 

Speaking of positivity, what’s your favorite fun stuff to do online?

I like Facebook and Instagram because I get to have some kind of contact with people all over the world. I’ve got friends everywhere from my life of traveling, and when I post something, the person who comments could be someone I haven’t talked to for 50 years! I like going on Surfline to see the surf report. And I like to write and receive emails. Because it used to be such a lag! I used to write letters to my friends, and it would be a month between receipt. And you’d change in that month. But with email, you can keep the conversation going without interruption.

…it took so long for us not to be covered in hair, and to be able to talk, and now we’re talking about having chips in our bodies to help us heal, and artificial intelligence. If you dwell on it, it’s really overwhelming for someone my age. It can be scary. But there’s a lot of positive to it, so you’ve gotta stay on that side.

What’s your hope for how technology can change or improve the future? What do you want [your grandson] Nimo to be able to do?

I would like my grandson to be able to use the internet to feed and shelter the world. I don’t know how it’ll work, but you can already see… GoFundMe has helped the lives of a lot of my friends who got to my age or older, and just didn’t put anything away. Everybody throws a hundred bucks in, and all the sudden the guy’s at least got a chance to make it to hospice. That’s the kind of thing I hope we can do, that the communication will help us realize that it’s not just one person or one country versus another. It’s our world, and we have to all live together. I hope we get to the point that we see it’s a global economy, a global outcome. That we have to live as humans and not Americans or Chinese or Russians. I just think being able to communicate and see that we’re all the same, we all have the same needs. Food, shelter, companionship. If you get all that, you don’t really need anything else. 

That’s exactly why I work at Mozilla: I believe our collective future will be decided on the internet. So we need to make sure it’s a place that can breed a positive outcome. 

That’s right. And that’s the scary part we saw in the last election. All the junk that was online! So many lies! We didn’t know what was true, and what wasn’t true, and we had to decide for ourselves. We had to create our own filters. We had to choose the truth we wanted, the one that reflected the future of the world we want. 

You’re my hero, Dad. Happy Father’s Day.

Natalie Linden and her dad,
Gary Linden

The post Gary Linden, legendary surfer & Firefox fan appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

What is the difference between the internet, browsers, search engines and websites?

Mozilla Blog - do, 17/06/2021 - 20:32

Real talk: this web stuff can get confusing. And it’s really important that we all understand how it works, so we can be as informed and empowered as possible. Let’s start by breaking down the differences between the internet, browsers, search engines and websites. Lots of us get these four things confused with each other and use them interchangeably, though they are different. In this case, the old “information superhighway” analogy comes in handy.

Let’s start by breaking down the differences between internet, search engine, and browser. Lots of us get these three things confused with each other.

In this case, the old “internet superhighway” analogy comes in handy.

The internet

The internet is the superhighway’s system of roads, bridges and tunnels. It is the technical network and infrastructure that connect all the computers and devices that are online together across the world. Being connected to the internet means devices, and whoever is using them, can communicate with each other and share information.

Browsers

The browser is the car that gets you everywhere. You type a destination into the address bar and zoooom: your browser takes you anywhere on the internet. Firefox is a browser — one built specifically for people, not profit.

Search engines

Search engines like Yahoo, Google, Bing and DuckDuckGo are the compass and the map. You tell a search engine an idea of where you want to go by typing your search terms, and it gives you some possible destinations. Search engines are websites, and they can also be apps. More on apps later.

Websites and the web

Effectively, you drive along the internet highway, stopping at whatever towns, stores and roadside attractions catch your fancy, aka websites. Websites are the specific destinations you visit throughout the internet. This is the content — the webpages, websites, documents, social media, news, videos, images and so on that you view and experience via the internet. The “web” (which is short for “world wide web”, hence “www”) is the collection of all these websites.

Apps

Any program that you download and install on your device is an app. Browsers are apps. Some websites — like Facebook, YouTube, Spotify and The New York Times, for example — double up as apps, so you get the same or similar content on the app as you would on the corresponding website. 

The key thing to remember about apps, especially social media apps, is that while they are accessed via a connection to the internet (the infrastructure), content on them does not represent the full web. It’s just a slice. In addition, not everything published in an app is necessarily publicly accessible on the web. 
The web is the largest software platform ever, a great equalizer that works on any device, anywhere. By design, the web is open for anyone to participate in. Read more about Mozilla’s mission to keep the internet open and accessible to all.

Know someone who gets these things mixed up? It’s easy to do!
Pass this article along to share the knowledge.

The post What is the difference between the internet, browsers, search engines and websites? appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

Celebrating our community: 10 years of the Reps Program

Mozilla Blog - wo, 16/06/2021 - 16:33

Mozilla has always been about community and understanding that the internet is a better place when we work together. Ten years ago, Mozilla created the Reps program to add structure to our regional programs, further building off of our open source foundation. Over the last decade, the program has helped activate local communities in over 50 countries, tested Mozilla products and launches before they were released to the public, and collaborated on some of our biggest projects. 

The last decade also has seen big shifts in technology, and it has only made us at Mozilla more thankful for our volunteers and more secure in our belief that community and collaboration are key to making a better internet.  

“As the threats to a healthy internet persist, our network of collaborative communities and contributors continues to provide an essential role in helping us make it better,” said Mitchell Baker, CEO and Chairwoman of Mozilla. “These passionate Mozillians give up their time to educate, empower and mobilize others to support Mozilla’s mission and expand the impact of the open source ecosystem – a critical part of making the internet more accessible and better than how they found it.”

Ahead of our 10 year anniversary virtual celebration for the Reps Mozilla program, or ReMo for short, we connected with six of the 205 current reps to talk about their favorite parts of the internet, why community is so important, and where the Reps program can go from here. 

Please introduce yourself! What community do you represent and how long have you been in the Mozilla Reps program?

Ioana Chiorean: I am the Reps Module Owner at this time. I am part of Mozilla Romania, but have always been involved in technical communities directly, like QA, Firefox OS and support. My latest roles have been more on the advocacy side as Tech Speaker and building the Reps community. I’ve been in the Reps program since 2011.

Irvin Chen: I’m a Mozilla Rep from Taipei, Taiwan. I’m representing the Mozilla Taiwan Community, one of the oldest Mozilla communities.

Lidya Christina: I’m a Mozilla Reps from Jakarta, Indonesia. I’ve been involved in the Reps program for more than two years now. I am also part of the review and resources team, provide operational support for the Mozilla community space in Jakarta, and a translator for the Mozilla localization project.

Michael Kohler: I have been part of the Reps program since 2012, and I am currently a Reps Peer helping out with strategy-related topics within the Reps program. After organizing events and building the community in Switzerland, I moved to Berlin in 2018 and started to help there. In the past 13 years I have worked on different Mozilla products such as Firefox, Firefox OS and Common Voice. 

Pranshu Khanna: I’m Pranshu Khanna, a Reps Council Member for the current term and a Rep from Mozilla Gujarat. I started my journey as a Firefox Student Ambassador from an event in January 2016, where my first contribution was to introduce the world of Open Source to over 150 college students. Since then, I’ve spoken to thousands of people about privacy, open web and open source to people across the world and have been a part of hundreds of events, programs and initiatives.

Robert Sayles: Currently, I reside in Dallas, Texas, and I represent the North American community. I first joined the Mozilla Reps program in 2012, focusing mainly on my volunteer contribution to the Mozilla Festival Volunteer Coordinator 2013. 

What part of the internet do you get the most joy from?

Irvin: For me, the most exciting thing about the internet is that no matter who you are or where you are located, you can always find and make some friends on the internet. For example, apart from each other, we could still collaborate online and successfully host the release party of Firefox in early 2000. Mozilla gives us, the local community contributors, the opportunity to participate, contribute and learn from each other on a global scale.

Michael: Nyan Cat is probably the part of the internet that I get most joy from. Kidding aside, for me the best part of the internet is probably the possibility to learn new astonishing facts about things I otherwise would never have looked up. All the knowledge is a few clicks away.

Pranshu: The most joyful moments from the internet have always come from being connected to people. It was 2006, and the ability to be on chat boards on a dial-up modem on 256Kbps to connect with people about anything, and scraping people on Orkut (remember that?). It’s been a ride, and now I speak to my mother everyday through FaceTime who is thousands of miles away and to my colleagues across the world. I would have been a kid in a small town in India who would not have imagined a world this big without the internet. It helped me embrace the idea of open knowledge and learn so much.

Why did you join the Mozilla family?

Lidya: I started in 2016, when I attended an offline localization event at the Mozilla community space in Jakarta for the first time. I have continued to be involved in localization (L10N) events since then, and I also joined the Mozilla Indonesia community to help manage events and the community space in Jakarta.

What makes me really engage with the community is that I appreciate that it is a supportive environment where the opportunities to learn (locally and globally) are wide. 

Michael: When I was in high school one of my teachers was a Firefox contributor. At some point he showed us what he is working on and that got me hooked into Mozilla. Already back then I had a big interest in open source, however it hadn’t occurred to me to contribute until that moment. I was mostly impressed by the kindness and willingness to help volunteers to contribute to Mozilla’s mission and products. I didn’t have much in-person contact with the community for the first three years, but the more I got to know many more Mozillians all around the world, the more I felt like I belonged in this community. I have found friends from all over the world due to my involvement with Mozilla!

Pranshu: Roots. Mozilla has its roots in activism since the time the internet was born, and my connection with the Mozilla manifesto was instant. I realized that it wasn’t just marketing fluff since this is a community built with passion like the company is, from a small community of developers working to build not just a browser, but user’s freedom of choice. Mozilla’s community is important to how it started and where it’s being taken, and — if you’re committed to be a part of the journey — shape the future of the internet. I have been a part of protesting Aadhaar for user privacy, building India’s National Privacy Law, mentor Open Source Leaders, and much much more. I’m so grateful for being a part of this family that genuinely wants to help people fall in love with what they are doing.

What is your favorite Mozilla product or Firefox project, and why?

Lidya: Beside the browser, my top favorite project/product are Pontoon (localization tool) and Firefox Monitor to get notified if my account was part of a data breach or not.

Michael: My favorite Mozilla product got to be Firefox. I’ve been a Firefox user for a long time and since 2008 I’ve been using Firefox Nightly (appropriately called “Minefield” back then). Since then I have been an avid advocate for Firefox and suggested Firefox to everyone who wasn’t already using Firefox. Thanks to Firefox my software engineering knowledge grew over time and up to this day has helped me in my career. And all that of course apart from being the window to the online world!

Pranshu: I love Common Voice! If I could use emojis, this would be filled with hearts. Common Voice is such a noble project to help people around the world give a voice. The beauty of the project is how it democratizes locales and gives people across all demographics a voice in the binary technological world.

Robert: I enjoyed working with Firefox Flicks many moons ago; as a Mozilla Rep, I had the privilege of interacting with the many talented creators and exploring how they were able to express themselves; I thought it was fantastic.   

Mozilla uses the term “community” quite a bit, and it means different things to different people – what does the Mozilla community mean to you?

Ioana: For me, it literally means the people. Especially those that dedicate their free time to help others, to volunteer. It is the place I grew up as a professional and learned so much about different cultures worldwide.

Pranshu: The Mozilla community is my family. I’ve met so many people across the world who passionately believe in the open web. This is a very different ecosystem than what the world considers a community, we are really close to each other. After all, doing good is a part of all of our code. 

Robert: Mozilla community means everyone brings something different to the table; I have witnessed a powerful movement over the years. When everyone gets together and brings their knowledge to the table, we can make a difference in the world.   

How has the ReMo program evolved over the past decade, and where do you think the program is headed?

Irvin: The Reps program had played an important role in connecting the isolated local communities. With regular meetups and events, we can meet with each other, receive regular updates from various projects, and collaborate on different efforts. As a community with years of history, we can extend our help beyond local users to foreign Mozillians by sharing our experience, such as experiences on community building, planning events, setting up the local website…etc.

Michael: In the past years Reps continued to provide important knowledge about their regions, such as organizing bug hunting events to test local websites to make sure they work for Firefox Quantum. There would have been quite a few bugs without the volunteers testing local websites that Mozilla employees wouldn’t have been able to test themselves. Additionally, Reps have always been great at coordinating communities and helping out with conflicts in the community.

I see a bright future for the Reps program. Mozilla can do so much more with the help of volunteers. Mozilla Reps is the perfect program to help coordinate, find and grow communities to advance Mozilla’s vision and mission over the coming years to come.

Pranshu: In the last decade the ReMo program has evolved from helping people to read, write and build on the internet to making the ecosystem better through creating leaders and helping users focus on their privacy. The program is headed to create pillars in the society that are committed to catalyse collaboration amongst diverse communities together for the common good, destroying silos that divide people. ReMo has Reps across the world, and I can imagine the community building great things together.

The post Celebrating our community: 10 years of the Reps Program appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

Mozilla Localization (L10N): L10n Report: June 2021 Edition

Mozilla planet - do, 10/06/2021 - 19:29

Please note some of the information provided in this report may be subject to change as we are sometimes sharing information about projects that are still in early stages and are not final yet. 

Welcome!

Are you a locale leader and want us to include new members in our upcoming reports? Contact us!

New content and projects Firefox 89 (MR1)

On June 1st, Mozilla released Firefox 89. That was a major milestone for Firefox, and a lot of work went into this release (internally called MR1, which stands for Major Release 1). If this new update was well received — see for example this recent article from ZDNet — it’s also thanks to the amazing work done by our localization community.

For the first time in over a decade, we looked at Firefox holistically, making changes across the board to improve messages, establish a more consistent tone, and modernize some dialogs. This inevitably generated a lot of new content to localize.

Between November 2020 and May 2021, we added 1637 strings (6798 words). To get a point of reference, that’s almost 14% of the entire browser. What’s amazing is that the completion levels didn’t fall drastically:

  • Nov 30, 2020: 89.03% translated across all shipping locales, 99.24% for the top 15 locales.
  • May 24, 2021: 87.85% translated across all shipping locales, 99.39% for the top 15 locales.

The completion level across all locales is lower, but that’s mostly due to locales that are completely unmaintained, and that we’ll likely need to drop from release later this year. If we exclude those 7 locales, overall completion increased by 0.10% (to 89.84%).

Once again, thanks to all the volunteers who contributed to this successful release of Firefox.

What’s new or coming up in Firefox desktop

These are the important deadlines for Firefox 90, currently in Beta:

  • Firefox 90 will be released on July 13. It will be possible to update localizations until July 4.
  • Firefox 91 will move to beta on July 12 and will be released on August 10.

Keep in mind that Firefox 91 is also going to be the next ESR version. Once that moves to release, it won’t generally be possible to update translations for that specific version.

Talking about Firefox 91, we’re planning to add a new locale: Scots. Congratulations to the team for making it so quickly to release!

On a final note, expect to see more updates to the Firefox L10n Newsletter, since this has proved to be an important tool to provide more context to localizers, and help them with testing.

What’s new or coming up in mobile

Next l10n deadlines for mobile projects:

  • Firefox for Android v91: July 12
  • Firefox for iOS v34.1: June 9

Once more, we want to thank all the localizers who worked hard for the MR1 (Proton) mobile release. We really appreciate the time and effort spent on helping ensure all these products are available globally (and of course, also on desktop). THANK YOU!

What’s new or coming up in web projects AMO

There are a few strings exposed to Pontoon that do not require translation. Only Mozilla staff in the admin role to the product would be able to see them. The developer for the feature will add a comment of “no need to translate” or context to the string at a later time. We don’t know when this will be added. For the time being, please ignore them. Most of the strings with a source string ID of src/olympia/scanners/templates/admin/* can be ignored. However, there are still a handful of strings that fall out of the category.

MDN

The project continues to be on hold in Pontoon. The product repository doesn’t pick up any changes made in Pontoon, so fr, ja, zh-CN, and zh-TW are now read-only for now.  The MDN site, however, is still maintaining the articles localized in these languages plus ko, pt-BR, and ru.

Mozilla.org

The websites in ar, hi-IN, id, ja, and ms languages are now fully localized through vendor service since our last report. Communities of these languages are encouraged to help promote the sites through various social media platforms to  increase download, conversion and create new profiles.

What’s new or coming up in SuMo

Lots of exciting things happening in SUMO in Q2. Here’s a recap of what’s happening:

  • You can now subscribe to Firefox Daily Digest to get updates about what people are saying about Firefox and other Mozilla products on social media like Reddit and Twitter.
  • We now have release notes for Kitsune in Discourse. The latest one was about advanced search syntax which is a replacement for the former Advanced Search feature.
  • We are trying something new for Firefox 89 by collecting MR1 (Major Release 1) specific feedback from across channels (support forum, Twitter, and Reddit). You can look into how we’re doing it on the contributor thread and learn more about MR1 changes from a list that we put together on this spreadsheet.

As always, feel free to join SUMO Matrix room to discuss or just say hi to the rest of the community.

What’s new or coming up in Pontoon

Since May, we’ve been running experiments in Pontoon to increase the number of users reading notifications. For example, as part of this campaign, you might have seen a banner encouraging you to install the Pontoon Add-on — which you really should do — or noticed a slightly different notification icon in the top right corner of the window.

Pontoon NotificationRecently, we also sent an email to all Pontoon accounts active in the past 2 years, with a link to a survey specifically about further improving notifications. If you haven’t completed the survey yet, or haven’t received the email, you can still take the survey here (until June 20th).

Look out for pilcrows

When a source string includes line breaks, Pontoon will show a pilcrow character (¶) where the line break happens.

This is how the Fluent file looks like:

onboarding-multistage-theme-tooltip-automatic-2 = .title = Inherit the appearance of your operating system for buttons, menus, and windows.

While in most cases the line break is not relevant — it’s just used to make the source file more readable — double check the resource comment: if the line break is relevant, it will be pointed out explicitly.

If they’re not relevant, you can just put your translation on one line.

If you want to preserve the line breaks in your translation, you have a few options:

  • Use SHIFT+ENTER to create a new line while translating.
  • Click the ¶ character in the source: that will create a new line in the position where your cursor currently sits.
  • Use the COPY button to copy the source, then edit it. That’s not really efficient, as your locale might need a line break in a different place.

Do not select the text with your mouse, and copy it in the translation field. That will copy the literal character in the translation, and it will be displayed in the final product, causing bugs.

If you see the ¶ character in the translation field (see red arrow in the image below), it will also appear in the product you are translating, which is most likely not what you want. On the other hand, it’s expected to see the ¶ character in the list of translations under the translation field (green arrow), as it is in the source string and the string list.

Events
  • We have held our first Localization Workshop Zoom event on Saturday June 5th. Next iterations will happen on Friday June 11th and Saturday June 12th. We have invited active managers and translators from a subset of locales. If this experience turns out to be useful, we will consider opening up to an even larger audience with expanded locales.
  • Want to showcase an event coming up that your community is participating in? Reach out to any l10n-driver and we’ll include that (see links to emails at the bottom of this report)
Friends of the Lion

Know someone in your l10n community who’s been doing a great job and should appear here? Contact one of the l10n-drivers and we’ll make sure they get a shout-out (see list at the bottom)!

Useful Links Questions? Want to get involved?
  • If you want to get involved, or have any question about l10n, reach out to:

Did you enjoy reading this report? Let us know how we can improve by reaching out to any one of the l10n-drivers listed above.

Categorieën: Mozilla-nl planet

Mozilla Open Policy & Advocacy Blog: Working in the open: Enhancing privacy and security in the DNS

Mozilla planet - do, 10/06/2021 - 15:00

In 2018, we started pioneering work on securing one of the oldest parts of the Internet, one that had till then remained largely untouched by efforts to make the web safer and more private: the Domain Name System (DNS). We passed a key milestone in that endeavor last year, when we rolled out DNS-over-HTTPS (DoH) technology by default in the United States, thus improving privacy and security for millions of people. Given the transformative nature of this technology and in line with our mission commitment to transparency and collaboration, we have consistently sought to implement DoH thoughtfully and inclusively. Today we’re sharing our latest update on that continued effort.

Between November 2020 and January 2021 we ran a public comment period, to give the broader community who care about the DNS – including human rights defenders; technologists; and DNS service providers – the opportunity to provide recommendations for our future DoH work. Specifically, we canvassed input on our Trusted Recursive Resolver (TRR) policies, the set of privacy, security, and integrity commitments that DNS recursive resolvers must adhere to in order to be considered as default partner resolvers for Mozilla’s DoH roll-out.

We received rich feedback from stakeholders across the world, and we continue to reflect on how it can inform our future DoH work and our TRR policies. As we continue that reflection, we’re today publishing the input we received during the comment period – acting on a commitment to transparency that we made at the outset of the process. You can read the comments here.

During the comment period and prior, we received substantial input on the blocklist publication requirement of our TRR policies. This requirement means that resolvers in our TRR programme  must publicly release the list of domains that they block access to. This blocking could be the result of either legal requirements that the resolver is subject to, or because a user has explicitly consented to certain forms of DNS blocking. We are aware of the downsides associated with blocklist publication in certain contexts, and one of the primary reasons for undertaking our  comment period was to solicit constructive feedback and suggestions on how to best ensure meaningful transparency when DNS blocking takes place. Therefore, while we reflect on the input regarding our TRR policies and solutions for blocking transparency, we will relax this blocklist publication requirement. As such, current or prospective TRR partners will not be required to mandatorily publish DNS blocklists from here on out.

DoH is a transformative technology. It is relatively new and, as such, is of interest to a variety of stakeholders around the world. As we bring the privacy and security benefits of DoH to more Firefox users, we will continue our proactive engagement with internet service providers, civil society organisations, and everyone who cares about privacy and security in the internet ecosystem.

We look forward to this collaborative work. Stay tuned for more updates in the coming months.

The post Working in the open: Enhancing privacy and security in the DNS appeared first on Open Policy & Advocacy.

Categorieën: Mozilla-nl planet

Firefox UX: Content design considerations for the new Firefox

Mozilla planet - wo, 09/06/2021 - 18:17
How we collaborated on a major redesign to clean up debt and refresh the product. Image of a Firefox browser window with the application menu opened on the right.

Introducing the redesigned Firefox browser, featuring the Alpenglow them

We just launched a major redesign of the Firefox desktop browser to 240 million users. The effort was so large that we put our full content design team — all two of us — on the case. Over the course of the project, we updated nearly 1,000 strings, re-architected our menus, standardized content patterns, established new principles, and cleaned up content debt.

Creating and testing language to inform visual direction

The primary goal of the redesign was to make Firefox feel modern. We needed to concretize that term to guide the design and content decisions, as well as to make the measurement of visual aesthetics more objective and actionable.

To do this, we used the Microsoft Desirability Toolkit, which measures people’s attitudes towards a UI with a controlled vocabulary test. Content design worked with our UX director to identify adjectives that could embody what “modern” meant for our product. The UX team used those words for early visual explorations, which we then tested in a qualitative usertesting.com study.

Based on the results, we had an early idea of where the designs were meeting goals and where we could make adjustments.

Image of a word cloud that includes words like ‘clean,’ ‘easy,’ and ‘simple, as well as two comments from research participants about the application menu redesign.

Sampling of qualitative feedback from the visual appeal test with word cloud and participant comments.

Improving way-finding in menus

Over time, our application menu had grown unwieldy. Sub-menus proliferated like dandelions. It was difficult to scan, resulting in high cognitive load. Grouping of items were not intuitive. By re-organizing the items, prioritizing high-value actions, using clear language, and removing icons, the new menu better supports people’s ability to move quickly and efficiently in the Firefox browser.

To finalize the menu’s information architecture, we leveraged a variety of inputs. We studied usage data, reviewed past user research, and referenced external sources like the Nielsen Norman Group for menu design best practices. We also consulted with product managers to understand the historical context of prior decisions.

Before and after images of the redesigned Firefox application menu.

The Firefox application menu, before and after the information architecture redesign.

Image of the redesigned Firefox application menu with annotations about what changed.

Changes made to the Firefox application menu include removing icons, grouping like items together, and reducing the number of sub-menus.

As a final step, we created principles to document the rationale behind the menu redesign so a consistent approach could be applied to other menu-related decisions across the product and platforms.

Image of content design principles for menus, such as ‘Use icons sparingly’ and ‘Write options as verb phrases.’

Content design developed these principles to help establish a consistent approach for other menus in the product.

Streamlining high-visibility messages

Firefox surfaces a number of messages to users while they use the product. Those messages had dated visuals, inconsistent presentation, and clunky copy.

We partnered with our UX and visual designers to redesign those message types using a content-first approach. By approaching the redesign this way, we better ensured the resulting components supported the message needs. Along the way, we were able to make some improvements to the existing copy and establish guidelines so future modals, infobars, and panels would be higher quality.

Cleaning up paper cuts in modal dialogues

A modal sits on top of the main content of a webpage. It’s a highly intrusive message that disables background content and requires user interaction. By redesigning it we made one of the most interruptive browsing moments smoother and more cohesive.
Before and after images of a redesigned Firefox modal dialog. Content decisions are highlighted.
Annotated example of the content decisions in a redesigned Firefox modal dialog.

Before and after images of a redesigned Firefox modal dialog. Content decisions are highlighted.

Annotated example of the content decisions in a redesigned Firefox modal dialog

Defining new content patterns for permissions panels

Permissions panels get triggered when you visit certain websites. For example, a website may request to send you notifications, know your location, or gain access to your camera and microphone. We addressed inconsistencies and standardized content patterns to reduce visual clutter. The redesigned panels are cleaner and more concise.
Before and after images of a redesigned Firefox permissions panel. Content decisions are highlighted.

Before and after images of a redesigned Firefox permissions panel. Content decisions are highlighted.

Annotated example of the content decisions in a redesigned Firefox permissions panel.

Closing thoughts

This major refresh appears simple and somewhat effortless, which was the goal. A large amount of work happened behind the scenes to make that end result possible — a whole lot of auditing, iteration, communication, collaboration, and reviews. As usual, the lion’s share of content design happened before we put ‘pen to paper.’

Like any major renovation project, we navigated big dreams, challenging constraints, tough compromises, and a whole lot of dust. Software is never ‘done,’ but we cleared significant content weeds and co-created a future-forward design experience.

As anyone who has contributed to a major redesign knows, this involved months of collaboration between our user experience team, engineers, and product managers, as well as our partners in localization, accessibility, and quality assurance. We were fortunate to work with such a smart, hard-working group.

This post was originally published on Medium.

Categorieën: Mozilla-nl planet

Mozilla Attack & Defense: Eliminating Data Races in Firefox – A Technical Report

Mozilla planet - wo, 09/06/2021 - 10:18

We successfully deployed ThreadSanitizer in the Firefox project to eliminate data races in our remaining C/C++ components. In the process, we found several impactful bugs and can safely say that data races are often underestimated in terms of their impact on program correctness. We recommend that all multithreaded C/C++ projects adopt the ThreadSanitizer tool to enhance code quality.

What is ThreadSanitizer?

ThreadSanitizer (TSan) is compile-time instrumentation to detect data races according to the C/C++ memory model on Linux. It is important to note that these data races are considered undefined behavior within the C/C++ specification. As such, the compiler is free to assume that data races do not happen and perform optimizations under that assumption. Detecting bugs resulting from such optimizations can be hard, and data races often have an intermittent nature due to thread scheduling.

Without a tool like ThreadSanitizer, even the most experienced developers can spend hours on locating such a bug. With ThreadSanitizer, you get a comprehensive data race report that often contains all of the information needed to fix the problem.

An example for a ThreadSanitizer report, showing where each thread is reading/writing, the location they both access and where the threads were created. ThreadSanitizer Output for this example program (shortened for article)

One important property of TSan is that, when properly deployed, the data race detection does not produce false positives. This is incredibly important for tool adoption, as developers quickly lose faith in tools that produce uncertain results.

Like other sanitizers, TSan is built into Clang and can be used with any recent Clang/LLVM toolchain. If your C/C++ project already uses e.g. AddressSanitizer (which we also highly recommend), deploying ThreadSanitizer will be very straightforward from a toolchain perspective.

Challenges in Deployment Benign vs. Impactful Bugs

Despite ThreadSanitizer being a very well designed tool, we had to overcome a variety of challenges at Mozilla during the deployment phase. The most significant issue we faced was that it is really difficult to prove that data races are actually harmful at all and that they impact the everyday use of Firefox. In particular, the term “benign” came up often. Benign data races acknowledge that a particular data race is actually a race, but assume that it does not have any negative side effects.

While benign data races do exist, we found (in agreement with previous work on this subject [1] [2]) that data races are very easily misclassified as benign. The reasons for this are clear: It is hard to reason about what compilers can and will optimize, and confirmation for certain “benign” data races requires you to look at the assembler code that the compiler finally produces.

Needless to say, this procedure is often much more time consuming than fixing the actual data race and also not future-proof. As a result, we decided that the ultimate goal should be a “no data races” policy that declares even benign data races as undesirable due to their risk of misclassification, the required time for investigation and the potential risk from future compilers (with better optimizations) or future platforms (e.g. ARM).

However, it was clear that establishing such a policy would require a lot of work, both on the technical side as well as in convincing developers and management. In particular, we could not expect a large amount of resources to be dedicated to fixing data races with no clear product impact. This is where TSan’s suppression list came in handy:

We knew we had to stop the influx of new data races but at the same time get the tool usable without fixing all legacy issues. The suppression list (in particular the version compiled into Firefox) allowed us to temporarily ignore data races once we had them on file and ultimately bring up a TSan build of Firefox in CI that would automatically avoid further regressions. Of course, security bugs required specialized handling, but were usually easy to recognize (e.g. racing on non-thread safe pointers) and were fixed quickly without suppressions.

To help us understand the impact of our work, we maintained an internal list of all the most serious races that TSan detected (ones that had side-effects or could cause crashes). This data helped convince developers that the tool was making their lives easier while also clearly justifying the work to management.

In addition to this qualitative data, we also decided for a more quantitative approach: We looked at all the bugs we found over a year and how they were classified. Of the 64 bugs we looked at, 34% were classified as “benign” and 22% were “impactful” (the rest hadn’t been classified).

We knew there was a certain amount of misclassified benign issues to be expected, but what we really wanted to know was: Do benign issues pose a risk to the project? Assuming that all of these issues truly had no impact on the product, are we wasting a lot of resources on fixing them? Thankfully, we found that the majority of these fixes were trivial and/or improved code quality.

The trivial fixes were mostly turning non-atomic variables into atomics (20%), adding permanent suppressions for upstream issues that we couldn’t address immediately (15%), or removing overly complicated code (20%). Only 45% of the benign fixes actually required some sort of more elaborate patch (as in, the diff was larger than just a few lines of code and did not just remove code).

We concluded that the risk of benign issues being a major resource sink was not an issue and well acceptable for the overall gains that the project provided.

False Positives?

As mentioned in the beginning, TSan does not produce false positive data race reports when properly deployed, which includes instrumenting all code that is loaded into the process and avoiding primitives that TSan doesn’t understand (such as atomic fences). For most projects these conditions are trivial, but larger projects like Firefox require a bit more work. Thankfully this work largely amounted to a few lines in TSan’s robust suppression system.

Instrumenting all code in Firefox isn’t currently possible because it needs to use shared system libraries like GTK and X11. Fortunately, TSan offers the “called_from_lib” feature that can be used in the suppression list to ignore any calls originating from those shared libraries. Our other major source of uninstrumented code was build flags not being properly passed around, which was especially problematic for Rust code (see the Rust section below).

As for unsupported primitives, the only issue we ran into was the lack of support for fences. Most fences were the result of a standard atomic reference counting idiom which could be trivially replaced with an atomic load in TSan builds. Unfortunately, fences are fundamental to the design of the crossbeam crate (a foundational concurrency library in Rust), and the only solution for this was a suppression.

We also found that there is a (well known) false positive in deadlock detection that is however very easy to spot and also does not affect data race detection/reporting at all. In a nutshell, any deadlock report that only involves a single thread is likely this false positive.

The only true false positive we found so far turned out to be a rare bug in TSan and was fixed in the tool itself. However, developers claimed on various occasions that a particular report must be a false positive. In all of these cases, it turned out that TSan was indeed right and the problem was just very subtle and hard to understand. This is again confirming that we need tools like TSan to help us eliminate this class of bugs.

Interesting Bugs

Currently, the TSan bug-o-rama contains around 20 bugs. We’re still working on fixes for some of these bugs and would like to point out several particularly interesting/impactful ones.

Beware Bitfields

Bitfields are a handy little convenience to save space for storing lots of different small values. For instance, rather than having 30 bools taking up 240 bytes, they can all be packed into 4 bytes. For the most part this works fine, but it has one nasty consequence: different pieces of data now alias. This means that accessing “neighboring” bitfields is actually accessing the same memory, and therefore a potential data race.

In practical terms, this means that if two threads are writing to two neighboring bitfields, one of the writes can get lost, as both of those writes are actually read-modify-write operations of all the bitfields:

If you’re familiar with bitfields and actively thinking about them, this might be obvious, but when you’re just saying myVal.isInitialized = true you may not think about or even realize that you’re accessing a bitfield.

We have had many instances of this problem, but let’s look at bug 1601940 and its (trimmed) race report:

When we first saw this report, it was puzzling because the two threads in question touch different fields (mAsyncTransformAppliedToContent vs. mTestAttributeAppliers). However, as it turns out, these two fields are both adjacent bitfields in the class.

This was causing intermittent failures in our CI and cost a maintainer of this code valuable time. We find this bug particularly interesting because it demonstrates how hard it is to diagnose data races without appropriate tooling and we found more instances of this type of bug (racy bitfield write/write) in our codebase. One of the other instances even had the potential to cause network loads to supply invalid cache content, another hard-to-debug situation, especially when it is intermittent and therefore not easily reproducible.

We encountered this enough that we eventually introduced a MOZ_ATOMIC_BITFIELDS macro that generates bitfields with atomic load/store methods. This allowed us to quickly fix problematic bitfields for the maintainers of each component without having to redesign their types.

Oops That Wasn’t Supposed To Be Multithreaded

We also found several instances of components which were explicitly designed to be single-threaded accidentally being used by multiple threads, such as bug 1681950:

The race itself here is rather simple, we are racing on the same file through stat64 and understanding the report was not the problem this time. However, as can be seen from frame 10, this call originates from the PreferencesWriter, which is responsible for writing changes to the prefs.js file, the central storage for Firefox preferences.

It was never intended for this to be called on multiple threads at the same time and we believe that this had the potential to corrupt the prefs.js file. As a result, during the next startup the file would fail to load and be discarded (reset to default prefs). Over the years, we’ve had quite a few bug reports related to this file magically losing its custom preferences but we were never able to find the root cause. We now believe that this bug is at least partially responsible for these losses.

We think this is a particularly good example of a failure for two reasons: it was a race that had more harmful effects than just a crash, and it caught a larger logic error of something being used outside of its original design parameters.

Late-Validated Races

On several occasions we encountered a pattern that lies on the boundary of benign that we think merits some extra attention: intentionally racily reading a value, but then later doing checks that properly validate it. For instance, code like:

See for example, this instance we encountered in SQLite.

Please Don’t Do This. These patterns are really fragile and they’re ultimately undefined behavior, even if they generally work right. Just write proper atomic code — you’ll usually find that the performance is perfectly fine.

What about Rust?

Another difficulty that we had to solve during TSan deployment was due to part of our codebase now being written in Rust, which has much less mature support for sanitizers. This meant that we spent a significant portion of our bringup with all Rust code suppressed while that tooling was still being developed.

We weren’t particularly concerned with our Rust code having a lot of races, but rather races in C++ code being obfuscated by passing through Rust. In fact, we strongly recommend writing new projects entirely in Rust to avoid data races altogether.

The hardest part in particular is the need to rebuild the Rust standard library with TSan instrumentation. On nightly there is an unstable feature, -Zbuild-std, that lets us do exactly that, but it still has a lot of rough edges.

Our biggest hurdle with build-std was that it’s currently incompatible with vendored build environments, which Firefox uses. Fixing this isn’t simple because cargo’s tools for patching in dependencies aren’t designed for affecting only a subgraph (i.e. just std and not your own code). So far, we have mitigated this by maintaining a small set of patches on top of rustc/cargo which implement this well-enough for Firefox but need further work to go upstream.

But with build-std hacked into working for us we were able to instrument our Rust code and were happy to find that there were very few problems! Most of the things we discovered were C++ races that happened to pass through some Rust code and had therefore been hidden by our blanket suppressions.

We did however find two pure Rust races:

The first was bug 1674770, which was a bug in the parking_lot library. This Rust library provides synchronization primitives and other concurrency tools and is written and maintained by experts. We did not investigate the impact but the issue was a couple atomic orderings being too weak and was fixed quickly by the authors. This is yet another example that proves how difficult it is to write bug-free concurrent code.

The second was bug 1686158, which was some code in WebRender’s software OpenGL shim. They were maintaining some hand-rolled shared-mutable state using raw atomics for part of the implementation but forgot to make one of the fields atomic. This was easy enough to fix.

Overall Rust appears to be fulfilling one of its original design goals: allowing us to write more concurrent code safely. Both WebRender and Stylo are very large and pervasively multi-threaded, but have had minimal threading issues. What issues we did find were mistakes in the implementations of low-level and explicitly unsafe multithreading abstractions — and those mistakes were simple to fix.

This is in contrast to many of our C++ races, which often involved things being randomly accessed on different threads with unclear semantics, necessitating non-trivial refactorings of the code.

Conclusion

Data races are an underestimated problem. Due to their complexity and intermittency, we often struggle to identify them, locate their cause and judge their impact correctly. In many cases, this is also a time-consuming process, wasting valuable resources. ThreadSanitizer has proven to be not just effective in locating data races and providing adequate debug information, but also to be practical even on a project as large as Firefox.

Acknowledgements

We would like to thank the authors of ThreadSanitizer for providing the tool and in particular Dmitry Vyukov (Google) for helping us with some complex, Firefox-specific edge cases during deployment.

Categorieën: Mozilla-nl planet

Dennis Schubert: WebCompat Tale: CSS Flexbox and the order of things

Mozilla planet - di, 08/06/2021 - 20:40

Have you thought about the order of things recently? Purely from a web development perspective, I mean.

The chances are that you, just like me, usually don’t spend too much time thinking about the drawing order of elements on your site when writing HTML and CSS. And that’s generally fine because things usually just feel right. Consider the following little example:

Source:

<style> #order-demo-one { position: relative; height: 100px; width: 100px; } #order-demo-one .box { position: absolute; bottom: 0; left: 0; right: 0; top: 0; } #order-demo-one .first { background-color: blue; } #order-demo-one .second { background-color: red; } </style> <section id="order-demo-one"> <div class="box first"></div> <div class="box second"></div> </section>

Result:

You could probably tell, without even looking at the result, that the second box - the red one - should be “on top”, completely covering up the blue box. After all, both boxes have the same size and the same position, but since the second box is placed after the first box, it’s drawn on top of the first one. To me, this feels pretty intuitive.

Let’s add some Flex to it

Now, let’s make things a bit more complicated. If you’re reading this article, I hope you’re at least slightly familiar with CSS Flexbox. And as you might know, flex-items have an order property, which you can use to reorder the items inside a flex container. Here’s the same example as before, but this time inside a flexbox container, with the items reordered. Note that this demo uses the same source as above, but I’m only showing relevant changes here.

Source:

<style> #order-demo-two { display: flex; } #order-demo-two .first { order: 2; } #order-demo-two .second { order: 1; } </style> <section id="order-demo-two"> <div class="box first"></div> <div class="box second"></div> </section>

Result:

Okay, now we used order to swap positions of the first and second boxes. And as you can see in the demo … nothing changed. What? This is where things start becoming a bit counter-intuitive because this test case is actually a bit of a trick question.

Here is what the CSS Flexbox spec says about the order property:

  1. A flex container lays out its content in order-modified document order, starting from the lowest numbered ordinal group and going up. Items with the same ordinal group are laid out in the order they appear in the source document.
  2. This also affects the painting order, exactly as if the flex items were reordered in the source document.
  3. Absolutely-positioned children of a flex container are treated as having order: 0 for the purpose of determining their painting order relative to flex items.

(List points added by me; the original is a single block of text.)

Point 1 is what we intuitively know. An element with order: 2 is shown after order: 1. So far, so good. Point 2, however, says that if you specify order, the elements should behave as if they have been reordered in the HTML. For our example above, this should mean that both of these HTML snippets should behave the same:

<section id="order-demo-two"> <div class="box first"></div> <div class="box second"></div> </section> <section id="order-demo-two"> <div class="box second"></div> <div class="box first"></div> </section>

But we can clearly see that that’s not how it works. That is because in the spec text above, point 3 says that if a flex item is absolutely-positioned, it is always treated as having order: 0, so what we define in our CSS doesn’t actually matter.

Flex order, for real this time.

So instead of having the absolutely positioned element as the flex item, let’s build another demo that has the absolute element inside the flex item.

Source:

<style> #order-demo-three { display: flex; position: relative; height: 100px; width: 100px; } #order-demo-three .first { order: 2; } #order-demo-three .second { order: 1; } #order-demo-three .inner { position: absolute; bottom: 0; left: 0; right: 0; top: 0; } #order-demo-three .first .inner { background-color: blue; } #order-demo-three .second .inner { background-color: red; } </style> <section id="order-demo-three"> <div class="box first"> <div class="inner"></div> </div> <div class="box second"> <div class="inner"></div> </div> </section>

Result:

And now, I might have lost you. Because, as of the time of writing this, what you see as the result depends on which browser you read this blog post in. In Firefox, you’ll see the blue box on top; but pretty much everywhere else, the red box will still be on top.

The question now is: who is right? And instead of just telling you the answer, let’s work it out together. Rule 3 from above does not apply here: The flex items are not absolutely positioned, so the order should be taken into consideration. To check if that’s the case, we can look at rule 2: the code should behave the same if we reorder the elements in the HTML. We can build a test for that:

Source:

<section id="order-demo-four"> <div class="box second"> <div class="inner"></div> </div> <div class="box first"> <div class="inner"></div> </div> </section>

Result:

(again, the code is the same as the one in #order-demo-three, but I’m just showing the HTML to keep it easier to read)

If you’re reading this in Firefox, then the last two test cases behave the same: they’ll show the blue box. However, if you’re in Chrome, Safari, or Edge, there will be a difference: the first case will show the red box, the second case shows the blue box. If you now think that this is a bug in Blink and WebKit: you are right, and that bug has been known for a while.

Uh, what now?

This might sound like a super weird edge-case, and that’s probably right. It is a weird edge case. But unfortunately, as with pretty much all things that end up on my desk, we discovered this edge-case by investigating real-world breakage. Here, we received a report about the flight date picker on flydubai.com being broken, where in Firefox, there is an advertising banner on top of the picker. That’s caused by what I described here.

The Blink issue I linked earlier was opened in 2016, and there hasn’t been much progress on there since. I’m not saying this to blame Google folks; that’s just highlighting that changing things like this is a bit tricky sometimes. While there appears to be a consensus that Firefox is right, changing Chrome to match Firefox could result in an undefined number of broken sites. So you have to be careful when pushing such a change.

For now, I decided to go ahead and add a web-platform-test for this, because there is none yet. Currently, there’s also a cross-browser compat effort, “Compat2021”, going on, and CSS Flexbox is one of the key areas everyone wants to work on to make it a bit less of a pain for web developers. Maybe we can get some progress done on this issue as well. I will certainly try!

And with that, I have to end this post. There is no happy end, there isn’t even a certainty on what - if anything - will happen next. Sometimes, that’s the nature of our work. And I think that’s worth sharing, too.

Categorieën: Mozilla-nl planet

Hacks.Mozilla.Org: Implementing Private Fields for JavaScript

Mozilla planet - di, 08/06/2021 - 17:26

This post is cross-posted from Matthew Gaudet’s blog

When implementing a language feature for JavaScript, an implementer must make decisions about how the language in the specification maps to the implementation. Sometimes this is fairly simple, where the specification and implementation can share much of the same terminology and algorithms. Other times, pressures in the implementation make it more challenging, requiring or pressuring the implementation strategy diverge to diverge from the language specification.

Private fields is an example of where the specification language and implementation reality diverge, at least in SpiderMonkey– the JavaScript engine which powers Firefox. To understand more, I’ll explain what private fields are, a couple of models for thinking about them, and explain why our implementation diverges from the specification language.

Private Fields

Private fields are a language feature being added to the JavaScript language through the TC39 proposal process, as part of the class fields proposal, which is at Stage 4 in the TC39 process. We will ship private fields and private methods in Firefox 90.

The private fields proposal adds a strict notion of ‘private state’ to the language. In the following example, #x may only be accessed by instances of class A:

class A { #x = 10; }

This means that outside of the class, it is impossible to access that field. Unlike public fields for example, as the following example shows:

class A { #x = 10; // Private field y = 12; // Public Field } var a = new A(); a.y; // Accessing public field y: OK a.#x; // Syntax error: reference to undeclared private field

Even various other tools that JavaScript gives you for interrogating objects are prevented from accessing private fields (e.g. Object.getOwnProperty{Symbols,Names} don’t list private fields; there’s no way to use Reflect.get to access them).

A Feature Three Ways

When talking about a feature in JavaScript, there are often three different aspects in play: the mental model, the specification, and the implementation.

The mental model provides the high-level thinking that we expect programmers to use mostly. The specification in turn provides the detail of the semantics required by the feature. The implementation can look wildly different from the specification text, so long as the specification semantics are maintained.

These three aspects shouldn’t produce different results for people reasoning through things (though, sometimes a ‘mental model’ is shorthand, and doesn’t accurately capture semantics in edge case scenarios).

We can look at private fields using these three aspects:

Mental Model

The most basic mental model one can have for private fields is what it says on the tin: fields, but private. Now, JS fields become properties on objects, so the mental model is perhaps ‘properties that can’t be accessed from outside the class’.

However, when we encounter proxies, this mental model breaks down a bit; trying to specify the semantics for ‘hidden properties’ and proxies is challenging (what happens when a Proxy is trying to provide access control to properties, if you aren’t supposed to be able see private fields with Proxies? Can subclasses access private fields? Do private fields participate in prototype inheritance?) . In order to preserve the desired privacy properties an alternative mental model became the way the committee thinks about private fields.

This alternative model is called the ‘WeakMap’ model. In this mental model you imagine that each class has a hidden weak map associated with each private field, such that you could hypothetically ‘desugar’

class A { #x = 15; g() { return this.#x; } }

into something like

class A_desugared { static InaccessibleWeakMap_x = new WeakMap(); constructor() { A_desugared.InaccessibleWeakMap_x.set(this, 15); } g() { return A_desugared.InaccessibleWeakMap_x.get(this); } }

The WeakMap model is, surprisingly, not how the feature is written in the specification, but is an important part of the design intention is behind them. I will cover a bit later how this mental model shows up in places later.

Specification

The actual specification changes are provided by the class fields proposal, specifically the changes to the specification text. I won’t cover every piece of this specification text, but I’ll call out specific aspects to help elucidate the differences between specification text and implementation.

First, the specification adds the notion of [[PrivateName]], which is a globally unique field identifier. This global uniqueness is to ensure that two classes cannot access each other’s fields merely by having the same name.

function createClass() { return class { #x = 1; static getX(o) { return o.#x; } }; } let [A, B] = [0, 1].map(createClass); let a = new A(); let b = new B(); A.getX(a); // Allowed: Same class A.getX(b); // Type Error, because different class.

The specification also adds a new ‘internal slot’, which is a specification level piece of internal state associated with an object in the spec, called [[PrivateFieldValues]] to all objects. [[PrivateFieldValues]] is a list of records of the form:

{ [[PrivateName]]: Private Name, [[PrivateFieldValue]]: ECMAScript value }

To manipulate this list, the specification adds four new algorithms:

  1. PrivateFieldFind
  2. PrivateFieldAdd
  3. PrivateFieldGet
  4. PrivateFieldSet

These algorithms largely work as you would expect: PrivateFieldAdd appends an entry to the list (though, in the interest of trying to provide errors eagerly, if a matching Private Name already exists in the list, it will throw a TypeError. I’ll show how that can happen later). PrivateFieldGet retrieves a value stored in the list, keyed by a given Private name, etc.

The Constructor Override Trick

When I first started to read the specification, I was surprised to see that PrivateFieldAdd could throw. Given that it was only called from a constructor on the object being constructed, I had fully expected that the object would be freshly created, and therefore you’d not need to worry about a field already being there.

This turns out to be possible, a side effect of some of the specification’s handling of constructor return values. To be more concrete, the following is an example provided to me by André Bargull, which shows this in action.

class Base { constructor(o) { return o; // Note: We are returning the argument! } } class Stamper extends Base { #x = "stamped"; static getX(o) { return o.#x; } }

Stamper is a class which can ‘stamp’ its private field onto any object:

let obj = {}; new Stamper(obj); // obj now has private field #x Stamper.getX(obj); // => "stamped"

This means that when we add private fields to an object we cannot assume it doesn’t have them already. This is where the pre-existence check in PrivateFieldAdd comes into play:

let obj2 = {}; new Stamper(obj2); new Stamper(obj2); // Throws 'TypeError' due to pre-existence of private field

This ability to stamp private fields into arbitrary objects interacts with the WeakMap model a bit here as well. For example, given that you can stamp private fields onto any object, that means you could also stamp a private field onto a sealed object:

var obj3 = {}; Object.seal(obj3); new Stamper(obj3); Stamper.getX(obj3); // => "stamped"

If you imagine private fields as properties, this is uncomfortable, because it means you’re modifying an object that was sealed by a programmer to future modification. However, using the weak map model, it is totally acceptable, as you’re only using the sealed object as a key in the weak map.

PS: Just because you can stamp private fields into arbitrary objects, doesn’t mean you should: Please don’t do this.

Implementing the Specification

When faced with implementing the specification, there is a tension between following the letter of the specification, and doing something different to improve the implementation on some dimension.

Where it is possible to implement the steps of the specification directly, we prefer to do that, as it makes maintenance of features easier as specification changes are made. SpiderMonkey does this in many places. You will see sections of code that are transcriptions of specification algorithms, with step numbers for comments. Following the exact letter of the specification can also be helpful where the specification is highly complex and small divergences can lead to compatibility risks.

Sometimes however, there are good reasons to diverge from the specification language. JavaScript implementations have been honed for high performance for years, and there are many implementation tricks that have been applied to make that happen. Sometimes recasting a part of the specification in terms of code already written is the right thing to do, because that means the new code is also able to have the performance characteristics of the already written code.

Implementing Private Names

The specification language for Private Names already almost matches the semantics around Symbols, which already exist in SpiderMonkey. So adding PrivateNames as a special kind of Symbol is a fairly easy choice.

Implementing Private Fields

Looking at the specification for private fields, the specification implementation would be to add an extra hidden slot to every object in SpiderMonkey, which contains a reference to a list of {PrivateName, Value} pairs. However, implementing this directly has a number of clear downsides:

  • It adds memory usage to objects without private fields
  • It requires invasive addition of either new bytecodes or complexity to performance sensitive property access paths.

An alternative option is to diverge from the specification language, and implement only the semantics, not the actual specification algorithms. In the majority of cases, you really can think of private fields as special properties on objects that are hidden from reflection or introspection outside a class.

If we model private fields as properties, rather than a special side-list that is maintained with an object, we are able to take advantage of the fact that property manipulation is already extremely optimized in a JavaScript engine.

However, properties are subject to reflection. So if we model private fields as object properties, we need to ensure that reflection APIs don’t reveal them, and that you can’t get access to them via Proxies.

In SpiderMonkey, we elected to implement private fields as hidden properties in order to take advantage of all the optimized machinery that already exists for properties in the engine. When I started implementing this feature André Bargull – a SpiderMonkey contributor for many years – actually handed me a series of patches that had a good chunk of the private fields implementation already done, for which I was hugely grateful.

Using our special PrivateName symbols, we effectively desuagar

class A { #x = 10; x() { return this.#x; } }

to something that looks closer to

class A_desugared { constructor() { this[PrivateSymbol(#x)] = 10; } x() { return this[PrivateSymbol(#x)]; } }

Private fields have slightly different semantics than properties however. They are designed to issue errors on patterns expected to be programming mistakes, rather than silently accepting it. For example:

  1. Accessing an a property on an object that doesn’t have it returns undefined. Private fields are specified to throw a TypeError, as a result of the PrivateFieldGet algorithm.
  2. Setting a property on an object that doesn’t have it simply adds the property. Private fields will throw a TypeError in PrivateFieldSet.
  3. Adding a private field to an object that already has that field also throws a TypeError in PrivateFieldAdd. See “The Constructor Override Trick” above for how this can happen.

To handle the different semantics, we modified the bytecode emission for private field accesses. We added a new bytecode op, CheckPrivateField which verifies an object has the correct state for a given private field. This means throwing an exception if the property is missing or present, as appropriate for Get/Set or Add. CheckPrivateField is emitted just before using the regular ‘computed property name’ path (the one used for A[someKey]).

CheckPrivateField is designed such that we can easily implement an inline cache using CacheIR. Since we are storing private fields as properties, we can use the Shape of an object as a guard, and simply return the appropriate boolean value. The Shape of an object in SpiderMonkey determines what properties it has, and where they are located in the storage for that object. Objects that have the same shape are guaranteed to have the same properties, and it’s a perfect check for an IC for CheckPrivateField.

Other modifications we made to make to the engine include omitting private fields from the property enumeration protocol, and allowing the extension of sealed objects if we are adding private field.

Proxies

Proxies presented us a bit of a new challenge. Concretely, using the Stamper class above, you can add a private field directly to a Proxy:

let obj3 = {}; let proxy = new Proxy(obj3, handler); new Stamper(proxy) Stamper.getX(proxy) // => "stamped" Stamper.getX(obj3) // TypeError, private field is stamped // onto the Proxy Not the target!

I definitely found this surprising initially. The reason I found this surprising was I had expected that, like other operations, the addition of a private field would tunnel through the proxy to the target. However, once I was able to internalize the WeakMap mental model, I was able to understand this example much better. The trick is that in the WeakMap model, it is the Proxy, not the target object, used as the key in the #x WeakMap.

These semantics presented a challenge to our implementation choice to model private fields as hidden properties however, as SpiderMonkey’s Proxies are highly specialized objects that do not have room for arbitrary properties. In order to support this case, we added a new reserved slot for an ‘expando’ object. The expando is an object allocated lazily that acts as the holder for dynamically added properties on the proxy. This pattern is used already for DOM objects, which are typically implemented as C++ objects with no room for extra properties. So if you write document.foo = "hi", this allocates an expando object for document, and puts the foo property and value in there instead. Returning to private fields, when #x is accessed on a Proxy, the proxy code knows to go and look in the expando object for that property.

In Conclusion

Private Fields is an instance of implementing a JavaScript language feature where directly implementing the specification as written would be less performant than re-casting the specification in terms of already optimized engine primitives. Yet, that recasting itself can require some problem solving not present in the specification.

At the end, I am fairly happy with the choices made for our implementation of Private Fields, and am excited to see it finally enter the world!

Acknowledgements

I have to thank, again, André Bargull, who provided the first set of patches and laid down an excellent trail for me to follow. His work made finishing private fields much easier, as he’d already put a lot of thought into decision making.

Jason Orendorff has been an excellent and patient mentor as I have worked through this implementation, including two separate implementations of the private field bytecode, as well as two separate implementations of proxy support.

Thanks to Caroline Cullen, and Iain Ireland for helping to read drafts of this post, and to Steve Fink for fixing many typos.

The post Implementing Private Fields for JavaScript appeared first on Mozilla Hacks - the Web developer blog.

Categorieën: Mozilla-nl planet

The Talospace Project: Firefox 89 on POWER

Mozilla planet - di, 08/06/2021 - 03:37

Firefox 89 was released last week with much fanfare over its new interface, though being the curmudgeon I am I'm less enamoured of it. I like the improvements to menus and doorhangers but I'm a big user of compact tabs, which were deprecated, and even with compact mode surreptitously enabled the tab bar is still about a third or so bigger than Firefox 88 (see screenshot). There do seem to be some other performance improvements, though, plus the usual more lower-level changes and WebRender is now on by default for all Linux configurations, including for you fools out there trying to run Nvidia GPUs.

The chief problem is that Fx89 may not compile correctly with certain versions of gcc 11 (see bugs 1710235 and 1713968). For Fedora users if you aren't on 11.1.1-3 (the current version as of this writing) you won't be able to compile the browser at all, and you may not be able to compile it fully even then without putting a # pragma GCC diagnostic ignored "-Wnonnull" at the top of js/src/builtin/streams/PipeToState.cpp (I still can't; see bug 1713968). gcc 10 is unaffected. I used the same .mozconfigs and PGO-LTO optimization patches as we used for Firefox 88. With those changes the browser runs well.

While waiting for the updated gcc I decided to see if clang/clang++ could now build the browser completely on ppc64le (it couldn't before), even though gcc remains my preferred compiler as it generates higher performance objects. The answer is now it can and this time it did, merely by substituting clang for gcc in the .mozconfig, but even using the bfd linker it makes a defective Firefox that freezes or crashes outright on startup; it could not proceed to the second phase of PGO-LTO and the build system aborted with an opaque error -139. So much for that. For the time being I think I'd rather spend my free cycles on the OpenPOWER JavaScript JIT than figuring out why clang still sucks at this.

Some of you will also have noticed the Mac-style pulldown menus in the screenshot, even though this Talos II is running Fedora 34. This comes from firefox-appmenu, which since I build from source is trivial to patch in, and the Fildem global menu GNOME extension (additional tips) paired with my own custom gnome-shell theme. I don't relish adding another GNOME extension that Fedora 35 is certain to break, but it's kind of nice to engage my Mac mouse-le memory and it also gives me a little extra vertical room. You'll notice the window also lacks client-side decorations since I can just close the window with key combinations; this gives me a little extra horizontal tab room too. If you want that, don't apply this particular patch from the firefox-appmenu series and just use the other two .patches.

Categorieën: Mozilla-nl planet

The Rust Programming Language Blog: Announcing Rustup 1.24.3

Mozilla planet - di, 08/06/2021 - 02:00

The rustup working group is happy to announce the release of rustup version 1.24.3. Rustup is the recommended tool to install Rust, a programming language that is empowering everyone to build reliable and efficient software.

If you have a previous version of rustup installed, getting rustup 1.24.3 is as easy as closing your IDE and running:

rustup self update

Rustup will also automatically update itself at the end of a normal toolchain update:

rustup update

If you don't have it already, you can get rustup from the appropriate page on our website.

What's new in rustup 1.24.3

This patch release focusses around resolving some regressions in behaviour in the 1.24.x series, in either low tier platforms, or unusual situations around very old toolchains.

Full details are available in the changelog!

Rustup's documentation is also available in the rustup book.

Thanks

Thanks again to all the contributors who made rustup 1.24.3 possible!

  • Alexander (asv7c2)
  • Ian Jackson
  • pierwill
  • 二手掉包工程师 (hi-rustin)
  • Robert Collins
  • Daniel Silverstone
Categorieën: Mozilla-nl planet

The Talospace Project: Progress on the OpenPOWER SpiderMonkey JIT

Mozilla planet - zo, 06/06/2021 - 01:53
Progress!

% gdb --args obj/dist/bin/js --no-baseline --no-ion --no-native-regexp --blinterp-eager -e 'print("hello world")'
GNU gdb (GDB) Fedora 10.1-14.fc34
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "ppc64le-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from obj/dist/bin/js...
(gdb) run
Starting program: obj/dist/bin/js --no-baseline --no-ion --no-native-regexp --blinterp-eager -e print\(\"hello\ world\"\)
warning: Expected absolute pathname for libpthread in the inferior, but got .gnu_debugdata for /lib64/libpthread.so.0.
warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
[New LWP 2797069]
[LWP 2797069 exited]
[New LWP 2797070]
[New LWP 2797071]
[New LWP 2797072]
[New LWP 2797073]
[New LWP 2797074]
[New LWP 2797075]
[New LWP 2797076]
[New LWP 2797077]
hello world
[LWP 2797072 exited]
[LWP 2797070 exited]
[LWP 2797074 exited]
[LWP 2797077 exited]
[LWP 2797073 exited]
[LWP 2797071 exited]
[LWP 2797076 exited]
[LWP 2797075 exited]
[Inferior 1 (process 2797041) exited normally]

This may not look like much, but it demonstrates that the current version of the OpenPOWER JavaScript JIT for Firefox can emit machine language instructions correctly (mostly — still more codegen bugs to shake out), handles the instruction cache correctly, handles ABI-compliant calls into the SpiderMonkey VM correctly (the IonMonkey JIT is not ABI-compliant except at those edges), and enters and exits routines without making a mess of the stack. Much of the code originates from TenFourFox's "IonPower" 32-bit PowerPC JIT, though obviously greatly expanded, and there is still ongoing work to make sure it is properly 64-bit aware and takes advantage of instructions available in later versions of the Power ISA. (No more spills to the stack to convert floating point, for example. Yay for VSX!)

Although it is only the lowest level of the JIT, what Mozilla calls the Baseline Interpreter, there is substantial code in common between the Baseline Interpreter and the second-stage Baseline Compiler. Because it has much less overhead compared to Baseline Compiler and to the full-fledged Ion JIT, the Baseline Interpreter can significantly improve page loads all by itself. In fact, my next step might be to get regular expressions and the OpenPOWER Baseline Interpreter to pass the test suite and then drag that into a current version of Firefox for continued work so that it can get banged on for reliability and improve performance for those people who want to build it (analogous to how we got PPCBC running first before full-fledged IonPower in TenFourFox). Eventually full Ion JIT and Wasm support should follow, though those both use rather different codepaths apart from the fundamental portions of the backend which still need to be shaped.

A big shout-out goes to Justin Hibbits, who took TenFourFox's code and merged it with the work I had initially done on JitPower way back in the Firefox 62 days but was never able to finish. With him having done most of the grunt work, I was able to get it to compile and then started attacking the various bugs in it.

Want to contribute? It's on Github. Tracing down bugs is labour-intensive, and involves a lot of emitting trap instructions and single-stepping in the debugger, but when you see those small steps add up into meaningful fixes (man, it was great to see those two words appear) it's really rewarding. I'm happy to give tips to anyone who wants to participate. Once it can pass the test suite at some JIT level, it will be time to forward-port it and if we can get our skates on it might even be possible to upstream it into the next Firefox ESR.

For better or worse, the Web is a runtime. Let's get OpenPOWER workstations running it better.

Categorieën: Mozilla-nl planet

Mozilla Open Policy & Advocacy Blog: The Van Buren decision is a strong step forward for public interest research online

Mozilla planet - vr, 04/06/2021 - 23:30

In a victory for security research and other public interest work, yesterday the U.S Supreme Court held that the Computer Fraud and Abuse Act’s (CFAA) “exceeding authorized access” provision should be narrowly interpreted and cannot be used to criminalize every single violation of a computer-use policy. This is encouraging news for journalists, bug bounty hunters, social science researchers, and many other practitioners who could legitimately access information in a myriad of ways but were at the risk of being prosecuted as criminals.

As we stated in our joint amicus brief to the Court in July 2020, over the years some federal circuit courts had interpreted the CFAA so broadly as to threaten important practices to protect the public, including research and disclosure of software vulnerabilities by those in the security community. The scope of such broad interpretation went beyond security management and has also been used to stifle legitimate public interest research, such as looking into the advertising practices of online platforms, something Mozilla has pushed back against in the past.

In its ruling, the Supreme Court held that authorized access under the CFAA is not exceeded when information is accessed on a computer for a purpose that the system owner considers improper. For example, the ruling clarifies that employees would not violate the CFAA simply by using a work computer to check personal email if that is contrary to the company’s computer use policies. The decision overrules some of the most expansive interpretations of the CFAA and makes it less likely that the law will be used to chill legitimate research and disclosures. The decision does, however, leave some open questions on the role of contractual limits in the CFAA that will likely have to be settled via litigation over the coming years.

However, the net impact of the decision leaves the “exceeding authorized access” debate under the CFAA in a much better place than when it began and should be celebrated as a clear endorsement of the years of efforts by various digital rights organizations to limit its chilling effects with the goal of protecting public interest research, including in cybersecurity.

The post The Van Buren decision is a strong step forward for public interest research online appeared first on Open Policy & Advocacy.

Categorieën: Mozilla-nl planet

Ryan Harter: Getting Credit for Invisible Work

Mozilla planet - do, 03/06/2021 - 09:00

Last month I gave a talk at csv,conf on "Getting Credit for Invisible Work". The (amazing) csv,conf organizers just published a recording of the talk. (slides here). Give it a watch! It's only 20m long (including the Q&A).

Invisible work is a concept I've been trying to …

Categorieën: Mozilla-nl planet

About:Community: Firefox 89: The New Contributors To MR1

Mozilla planet - wo, 02/06/2021 - 21:29

Firefox 89 would not have been possible without our community, and it is a great privilege for us to thank all the developers who contributed their first code change to MR1, 44 of whom were brand new volunteers!

Categorieën: Mozilla-nl planet

Data@Mozilla: This week in Glean: Glean Dictionary updates

Mozilla planet - wo, 02/06/2021 - 18:16

(“This Week in Glean” is a series of blog posts that the Glean Team at Mozilla is using to try to communicate better about our work. They could be release notes, documentation, hopes, dreams, or whatever: so long as it is inspired by Glean.) All “This Week in Glean” blog posts are listed in the TWiG index (and on the Mozilla Data blog).

Lots of progress on the Glean Dictionary since I made the initial release announcement a couple of months ago. For those coming in late, the Glean Dictionary is intended to be a data dictionary for applications built using the Glean SDK and Glean.js. This currently includes Firefox for Android and Firefox iOS, as well as newer initiatives like Rally. Desktop Firefox will use Glean in the future, see Firefox on Glean (FoG).

Production URL

We’re in production! You can now access the Glean Dictionary at dictionary.telemetry.mozilla.org. The old protosaur-based URL will redirect.

Glean Dictionary + Looker = ❤️

At the end of last year, Mozilla chose Looker as our internal business intelligence tool. Frank Bertsch, Daniel Thorn, Anthony Miyaguchi and others have been building out first class support for Glean applications inside this platform, and we’re starting to see these efforts bear fruit. Looker’s explores are far easier to use for basic data questions, opening up data based inquiry to a much larger cross section of Mozilla.

I recorded a quick example of this integration here:

Note that Looker access is restricted to Mozilla employees and NDA’d volunteers. Stay tuned for more public data to be indexed inside the Glean Dictionary in the future.

Glean annotations!

I did up the first cut of a GitHub-based system for adding annotations to metrics – acting as a knowledge base for things data scientists and others have discovered about Glean Telemetry in the field. This can be invaluable when doing new analysis. A good example of this is the annotation added for the opened as default browser metric for Firefox for iOS, which has several gotchas:

Many thanks to Krupa Raj and Leif Oines for producing the requirements which led up to this implementation, as well as their evangelism of this work more generally inside Mozilla. Last month, Leif and I did a presentation about this at Data Club, which has been syndicated onto YouTube:

Since then, we’ve had a very successful working session with some people Data Science and have started to fill out an initial set of annotations. You can see the progress in the glean-annotations repository.

Other Improvements

Lots more miscellaneous improvements and fixes have gone into the Glean Dictionary in the last several months: see our releases for a full list. One thing that irrationally pleases me are the new labels Linh Nguyen added last week: colorful and lively, they make it easy to see when a Glean Metric is coming from a library:

Future work

The Glean Dictionary is just getting started! In the next couple of weeks, we’re hoping to:

  • Expand the Looker integration outlined above, as our deploy takes more shape.
  • Work on adding “feature” classification to the Glean Dictionary, to make it easier for product managers and other non-engineering types to quickly find the metrics and other information they need without needing to fully understand what’s in the source tree.
  • Continue to refine the user interface of the Glean Dictionary as we get more feedback from people using it across Mozilla.

If you’re interested in getting involved, join us! The Glean Dictionary is developed in the open using cutting edge front-end technologies like Svelte. Our conviction is that being transparent about the data Mozilla collects helps us build trust with our users and the community. We’re a friendly group and hang out on the #glean-dictionary channel on Matrix.

Categorieën: Mozilla-nl planet

William Lachance: Glean Dictionary updates

Mozilla planet - wo, 02/06/2021 - 18:01

(this is a cross-post from the data blog)

Lots of progress on the Glean Dictionary since I made the initial release announcement a couple of months ago. For those coming in late, the Glean Dictionary is intended to be a data dictionary for applications built using the Glean SDK and Glean.js. This currently includes Firefox for Android and Firefox iOS, as well as newer initiatives like Rally. Desktop Firefox will use Glean in the future, see Firefox on Glean (FoG).

Production URL

We’re in production! You can now access the Glean Dictionary at dictionary.telemetry.mozilla.org. The old protosaur-based URL will redirect.

Glean Dictionary + Looker = ❤️

At the end of last year, Mozilla chose Looker as our internal business intelligence tool. Frank Bertsch, Daniel Thorn, Anthony Miyaguchi and others have been building out first class support for Glean applications inside this platform, and we’re starting to see these efforts bear fruit. Looker’s explores are far easier to use for basic data questions, opening up data based inquiry to a much larger cross section of Mozilla.

I recorded a quick example of this integration here:

Note that Looker access is restricted to Mozilla employees and NDA’d volunteers. Stay tuned for more public data to be indexed inside the Glean Dictionary in the future.

Glean annotations!

I did up the first cut of a GitHub-based system for adding annotations to metrics — acting as a knowledge base for things data scientists and others have discovered about Glean Telemetry in the field. This can be invaluable when doing new analysis. A good example of this is the annotation added for the opened as default browser metric for Firefox for iOS, which has several gotchas:

Many thanks to Krupa Raj and Leif Oines for producing the requirements which led up to this implementation, as well as their evangelism of this work more generally inside Mozilla. Last month, Leif and I did a presentation about this at Data Club, which has been syndicated onto YouTube:

Since then, we’ve had a very successful working session with some people Data Science and have started to fill out an initial set of annotations. You can see the progress in the glean-annotations repository.

Other Improvements

Lots more miscellaneous improvements and fixes have gone into the Glean Dictionary in the last several months: see our releases for a full list. One thing that irrationally pleases me are the new labels Linh Nguyen added last week: colorful and lively, they make it easy to see when a Glean Metric is coming from a library:

Future work

The Glean Dictionary is just getting started! In the next couple of weeks, we’re hoping to:

  • Expand the Looker integration outlined above, as our deploy takes more shape.
  • Work on adding “feature” classification to the Glean Dictionary, to make it easier for product managers and other non-engineering types to quickly find the metrics and other information they need without needing to fully understand what’s in the source tree.
  • Continue to refine the user interface of the Glean Dictionary as we get more feedback from people using it across Mozilla.

If you’re interested in getting involved, join us! The Glean Dictionary is developed in the open using cutting edge front-end technologies like Svelte. Our conviction is that being transparent about the data Mozilla collects helps us build trust with our users and the community. We’re a friendly group and hang out on the #glean-dictionary channel on Matrix.

Categorieën: Mozilla-nl planet

Mozilla Security Blog: Updating GPG key for signing Firefox Releases

Mozilla planet - wo, 02/06/2021 - 10:29

Mozilla offers GPG signing to let you verify the integrity of our Firefox builds. GPG signatures for Linux based builds are particularly important, because it allows Linux distributions and other repackagers to verify that the source code they use to build Firefox actually comes from Mozilla.

We regularly rotate our GPG signing subkey — usually every two years — to guard against the unlikely possibility that the key has been leaked without our knowledge. Last week, such a rotation happened, and we switched over to the new signing subkey.

The new GPG subkey’s fingerprint is 14F2 6682 D091 6CDD 81E3 7B6D 61B7 B526 D98F 0353, and will expire on 2023-05-17.

If you are interested in performing a verification of your copy of Firefox, you can fetch the public key directly from our KEY files from the Firefox 89 release, or alternatively directly from below.

 

-----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFWpQAQBEAC+9wVlwGLy8ILCybLesuB3KkHHK+Yt1F1PJaI30X448ttGzxCz PQpH6BoA73uzcTReVjfCFGvM4ij6qVV2SNaTxmNBrL1uVeEUsCuGduDUQMQYRGxR tWq5rCH48LnltKPamPiEBzrgFL3i5bYEUHO7M0lATEknG7Iaz697K/ssHREZfuuc B4GNxXMgswZ7GTZO3VBDVEw5GwU3sUvww93TwMC29lIPCux445AxZPKr5sOVEsEn dUB2oDMsSAoS/dZcl8F4otqfR1pXg618cU06omvq5yguWLDRV327BLmezYK0prD3 P+7qwEp8MTVmxlbkrClS5j5pR47FrJGdyupNKqLzK+7hok5kBxhsdMsdTZLd4tVR jXf04isVO3iFFf/GKuwscOi1+ZYeB3l3sAqgFUWnjbpbHxfslTmo7BgvmjZvAH5Z asaewF3wA06biCDJdcSkC9GmFPmN5DS5/Dkjwfj8+dZAttuSKfmQQnypUPaJ2sBu blnJ6INpvYgsEZjV6CFG1EiDJDPu2Zxap8ep0iRMbBBZnpfZTn7SKAcurDJptxin CRclTcdOdi1iSZ35LZW0R2FKNnGL33u1IhxU9HRLw3XuljXCOZ84RLn6M+PBc1eZ suv1TA+Mn111yD3uDv/u/edZ/xeJccF6bYcMvUgRRZh0sgZ0ZT4b0Q6YcQARAQAB tC9Nb3ppbGxhIFNvZnR3YXJlIFJlbGVhc2VzIDxyZWxlYXNlQG1vemlsbGEuY29t PokCOAQTAQIAIgUCValABAIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQ Ybe1JtmPA1NQqg//Rr6/V7uLqrIwx0UFknyNJasRJZhUkYxdGsLD18zO0Na8Ve3Q sYpOC3ojpqaFUzpqm6KNv8eXfd/Ku7j3WGr9kPkbjZNghvy6V5Lva4JkxO6LMxKk JYqiqF2o1Gfda8NfcK08GFy4C0L8zNwlADvmdMo4382tmHNGbTTft7BeVaRrE9xW 9eGmGQ2jYOsjxb5MsadAdZUuK8IC95ZHlUDR3gH9KqhfbQWp5Bo924Kiv+f2JUzN rrG98eOm1Qb8F9rePzZ2DOYRJyOe4p8Gpl+kojCXNntkJgcwJ1a1yRE6wy9RzpeB lCeoQuLS92MNne+deQZUskTZFoYXUadf6vbdfqL0nuPCKdl9lhef1QNwE30IRymt 6fhJCFffFQjGdeMfSiCHgcI8ichQbrzhBCGGR3bAHan9c2EbQ+puqG3Aa0YjX6Db GJjWOI6A61bqSPepLCMVaXqV2mZEIaZWdZkOHjnRrU6CJdXG/+D4m1YBZwYM60eJ kNu4eMMwMFnRsHiWf7bhqKptwuk8HyIGp2o4j8iqrFRVJEbK/ctdhA3H1AlKug9f NrfwCfqhNCSBju97V03U26j04JMn9nrZ2UEGbpty+8ONTb38WX5/oC61BgwV8Ki4 6Lwyb7fImUzz8jE83pjh7s3+NCKvvbH+VfT12f+V/fsphN3EwGwJPTC3fX2IRgQQ EQIABgUCVaz/SwAKCRB2JUA9fw0VsVNkAKDjhUW5GyFNcyj9ot48v+lSh5GBIACf Ten/Rpo5tf77Uq7445cVs80EK5CIRgQQEQIABgUCVa064wAKCRDDTldH4j3WdwW5 AKCVDRxKjb/XYqGhjBCKYhbQ4xJuOACfVIpzE3wGLC/cm9eUnSVnv+elQnKIXgQQ EQgABgUCVgZXYwAKCRACWrAQaxfqHqzWAP9dzEHoZNwH5JYxotudv3FOotVThaQr jnk+5StnObpxnAD9FmYyAyYGh4o7axeDCgmW1J89+1cZtDnFPKnBpGFMB4uIXgQQ EQoABgUCVa0s/gAKCRDwqefc055FLpQGAP99Z2ISKW+7FYoKJ3vDrxTtfcbZEff7 8ufoinmAlZb2bQD/a2fOcprjWDal9Orfq7g6htkX3VISemg+SDQ/ig+b3uyJARwE EAECAAYFAlWs/X4ACgkQs8WpWFCKQ/JrjAf7B+fGzEs8xfc010a6KZXcO1W4/Va0 Q+zcqF+DpQwK7b3S6oD5tCVKD9oFyDXkrlT6Tnwuu+slZwRDIyH6hI6tPb3G8Gsk vjXMeL0IdgZsw1DSxN0pZ0Z9mxFq/UkC/6TmFA1IJmOWtFCH/1irQWqbDxPmWp+d Xs2EhH8QzX1KQOE9v/YlsCdmTstMiHy3R8r7prsonpCa36zGheC/UNDpycKdT8JL zeCFcIWXmA7SCTeJ0XCSuS68FOwfe7nn9oagQZZe/6gh5ecuCoW9HLBWpyIPqUCz 1CXSImLc6BbZYMpAetacarVPa6hiltNicxFE/A3T1F8ZjAcugPKBngUR/4kBHAQQ AQIABgUCVa0XXAAKCRBlc4Lb/yURCkCYB/95w/9/0rpi+5xtoO2NR0KlqYVG5+NF 1r42XB6t7gVJ9UGF3meV+ekgDSzNrfroqxpzWmV1t3MRJeSMmVS25nC1hAZVQHKd gX9xVxW3SSufX/jPstvo2U/X3k8q8PhLS6Ihk8YJC3ScjMiNMRpkITMeVdXsdQsY WStiT48wlWK4gSNMCG5iovdGDTEKErHTIWJl/Wx5el1kvUwg1rKo9uRS2CS/lnlV 6YztDY0cBBOqXP6pXXiWBuVW39LJxsSHq13vpeQ/GHeDxAJ6Y+fPuaV3qBmGZ91o 1/HkxTABFPkISylkPo/2PCoo4Hu31MZ0jQWdihJ7gzf+B7/w6whS79eAiQEcBBAB AgAGBQJVrWVaAAoJEOQyfGw+ApnAc7AH/0TKg3VR4IEB3NP2C7dX/72PWO0EOh8J w67XDccRK0lXDILg/CujsYq9EzEofv2LmQFvCuCkoBFEcGas+J2vP3jsY/G5bjZp XALHkAx7MKlOgsgfeVqMtwaHIoR+y9Hg12TjM7Gt970UBwTIqC8SG6Z1bVWxUdc+ 7Zsn43Dq8z99saOUKD6HMyl9upbjAYwL28NRQtIrNiDZ5lEmDOLh+4hWblxjxWMX AKjg6sucrNzKD2uKGe9XdB6IkYpdfrNGPtgcnXWdfaRNk16eGVzWDVI/9mkY/G+L E40eK6oRyMf736CvlQjcv7JBVGTsj3W28phNLLU0UidYK/QmS3AVmBeJARwEEAEC AAYFAlXBWXAACgkQiRc/lXxV+V6gKQf/d/KfgiYg0Z4dqO3g1p40sgLuxVplhpDk J4yP5K2isdb6I7GJykVw+po6tUCfB7KeLWiZy0I3KJDU1Ikk+Jv3uGSRMT1riSpM Ja2pVhh+jaamHIFj2o0mG9HmEAuGKktJH8s6Jax3SiPGODRhFO8suc7B8FpB7f5q TUDK2J18MlnSK3NN1/zl6OdXScrISQ0cNyJ0RMgW5RSXC7wKzR89tfcDK1wInD8r cOMHz6Va5g8ehq2XCPKvBAlgo8El17+4UaRLhS0suVz4THPsGASYzZVKIhQQBf+8 xDXd6zJ/UgkC4iBWHtLm5jvm6Xhsu04s28TmgiH4FKLsstAUFzbiQYkBHAQQAQIA BgUCVdIa6gAKCRCtfLmfgki6D8xCB/9Q+rCTDQCbWQkRoSV77+kmIb+KVFTcgxfR Z1L0bKL5YqI6HuCJLgU1ioTxq8W4g+SDv4s69/LIajYYZvSRNv0kGRzm2D4vpcnw ymyYCJkzcZkuBeyR50S69+1cStbFb7jZMpyZ6rwnKdYOccDSMdaynJGt4rqiY+ra DPF0H4LExx9a1JFh21Fd0MDc15vsoRZtrOkM8QaKD85hZ/AGOwlw+Kb3DEfjNGcv nuNp54HfJc0Z5kwVYoOKUatBgjLpRRvl43lUGRaaCCMaNpNZXM20ZhrbTjXRlko8 QVMUXqE20sDNwv+dDa6G8nBkIGNIHeixrVrVPP7hH5JRMtjZbsWFiQEcBBABCAAG BQJVrQFGAAoJEFbucY3ODhVLNDgH/izNHcsr1BRnV3yQ6T9sTJJ187BwF1hRLR+Y 3op+fJr+nQ9301XAqLqNbzEB91hRUi2Gb8LTZxxq0gahWzSqmdAE0ObXGGlrEmfj FSSTFyQ1xRvzooYNZzTjN91XX1dERjyj9SOHBETsZrN01BZB1t3EgoDM7PCNTsX0 qC65unWvBDftnLdiJ6s3UC9sorMk8q3Zl6DacFw8QKSmJL1R0OPvXiSOZtGQK9Jg YyHiXQE3MOP5SFSk61e1IawocYn32CXM+EkgtXK5q/thc8OdwsgLAJmGpVB3qd2K 9OaEOKCUV/V91a2P8hCx8MMV2sQgHcMB221wDIWbD5PTHNtCegaJARwEEAEIAAYF AlWtIrEACgkQo9ZSFzt2Po+mXgf/dUPf6q+aDFoDjLIsfJH5QS8Nn/7frUUdElg8 PdGxtZ6SQep6uR5fgc+PwOElhUxa665WYtRJ459RWAYmbh2kkP/paGBf9nW0A2wS koXyJNydJcanyjwHyqKUbBLsXJAvGFtbYRsbeXkEPM5CaKgRUwc8Ilzo9/53CZF/ avZK4FJX00lZq0/Z8dIY8jUEF64IbJgbaUe1gkuxu7zURgjVKK4bb4lLy/s3tRe0 00hrKVbFcaNoIZs+Vk/3A/TFdYHFY6I2JpLIeSSJd/Ywh6/YZfGkSHfzn87Dfkyr gXKQMQ5JvQQgKbO6GPBZSygxWU7R2tNNAJKHSh0/PJ8J7yrqj4kBHAQQAQgABgUC Va05AwAKCRD20Pdh3MzspCvWB/9DAEaNx5WF3ktmw6jP5cCv60HDwgsmJHusGyAo 53Gwjo4Fx6hv5QYQpTbO4af+4KpFGkex+bZniOJWpT+NJkhx55xbzA903MoZ9+dI oCtG4K41kA2mMYSpR097yF3fwtuP70UgMZqiCmz/iKFzsrdhjE0KvBjptnYGEWk5 MMh5xlpzGom3LV/A+KAmEdPw+GCaj5H6qG3/PtWXz+RmjG0sRPycHaNJCWuLz4xM xV28oAG53Gqc3cDes4Hpds4fPOa8+we7yKTK/2O3lfOUOvKncsoS3vHC/GNfGD86 RX/vz2TW4GMaLmn75xcAYT0MINIFBf/tXjN1BNrmvrGkkxnbiQEcBBABCgAGBQJV rQlbAAoJEDNC4bZno4hjKL8H/An2CRzW8IsEjFKD+J+xa5hJYQbcb5W5wjGSs9PL /pRbH0t8FNS1DevRqoq3xdL5EEUpUgae54gix0An0qKhzC4MRdD9sYFy42mDP7f6 8Vw2sCZltfBtOHaha7Qj2U28DE9j7Dx04lkHWjdHudJV5PVaPpelW8EDIOMx+4nG WnXiYEKKMRWpR2BVV1FXnsfbfP2HWpxVaxxWt7WqOmswU0lJCb2bSLteEn8YoA1i CMLMdMaVXyX92v8Quh2N0NWtzXgc94ug8GiucGKoo2SpdFlXVCysqlPfKBestJlL 93dqP6dOwqoHqOscTJB6rvNzi2tmtAu7WDy4C+BBXNhbYpGJAhwEEAECAAYFAlWs +ygACgkQljt4MQo3sXysaw/+J6Ztawe/qT5aLW6it+zLq+3oD21UgM1TVP81CjwL hlHj9wuuGDe+xE8dZA7kvpngKjAxxXPQX/B4rz27Y+kHCvelOSrLW5kodTsPWIkL cSYMRo4Pws0RIGQBXI8tDIaJJcj7BYb9O7OjCziTEjP5KxDeZ6o4n0NFnZk5NNhS 6B1VnC3Y34DIj4koxm1N5O5br4z8kTc5PN9bMxOZn2u+KxGIeEwZJbHvtrgeAxUP 96B2dUo+jgSuro5jSkIyD+wpfo5o6+/kCtDiXEWo//AHJAwOal02QAodUtrMggwz J19FfnU8RgiKFjivrbfZi6ITM6RHg+DSF+KnaW2wkc3mGTB0qJsgSLGwOgfv37Qx O1tTdPxbSfWnZJAspylC74dgh+XOYYDji9tjPtrKZ8sEaHiUVFlO4QTOTlB9yYwO E7uI/3MKe3Q+0M2a85gvX+S0CdznpXo71aMFj0Hd/7ZMuKNausJZhagHAILbve1M IATkkfbCTxg5bdYgvdVGAIgUEAAO8mvLl1EvOJgkME5a/I/mK6MLxByuCMaT0RMr U9S881f+AJuJ3Qxbbo8vN0Iy9KmiCIptcSMKBKLHeMonYaXM8O392/XUKbgSBXkL oTOybMT+LZhO0upOhpRJqmtyDT1Wjxp7FBku/sUjJXCVy7YpjwkkLxZmvWIhleb7 S8uJAhwEEAECAAYFAlWs/LgACgkQEstOl+B+Z9HYNA//UKMSIfS0bdY6K+zhxuMS lIyol8Z/ynkDZSZ8SOeXZViLyRCRoXhY2g6JsygWLsZpthI8fnleQhwy1GLCxWMF n/PiRjj++VHoJYK/ANP23bC+tyl+jT9gwoPF0eGdWnnot1jGO6f6jFqam0KAL/XN 6ePUrNo0jbrYVrEUer20PYsM3tqGlGgOOFikMoYWwsAVOEh2I5Sgi6iAYfx12RYW eKw37loDwSr2FNZ5zjxdIyUQnKN1YMd0/Rfi2d86OVD7dV2qa94TFUvYmicpdcOM 9pogKVGmbhz7lirjuAidRhdZkuU+rxvIAd07Oc3bQRdsUCJAs/kjO71v9ov/NqKu j/BLixxIa0D0eKE41yL13RCfZIG46nI/F5PvLXhDp7sIeohIWsvYv239A9yXfq6B TeXZ1j8YTlY86yN38JStf8pbGWKlGARM7e1o9DHYY3irLCOWCAnKmF14wbbTMOAe w2VzxV8895Bweeo2fyCOGFI6SzvOSaOQPUlfmiKmtJrwreg71Vsv64X8X6FHajZY V9dYJFS2gO8cYJ/zajzn/oeYVTtpsFpJmq7fWByjGd7pAnZHuuSEy/57GEptmYRu zmI2gn7vYz1rZAbLThFsk/auCU3VYke8Dd3jHnxBuq2+Pa8TmLxibvnE1ZKd0gqZ dMNY/rT4+LZI+xDczzF3Z7mJAhwEEAECAAYFAlWtLOIACgkQirEyljoGU3rjMhAA ijskigHf8Q3D3B4Oz673cLNOGfAyEdHWNqlJW0Vcdo05iF8q8utwqmziRWw4PbpO cdPpUqLb61rWfjSkq4PVTOr8leHHNj/a4aiAYt8DtnpcwJqTmktiijo0Ptn0v8ao fdRJSVLtPcV0FydLzK6oLovszdWAQ4iVdFjppvdDJtjT4ooXFmZgZg6KzqjEGm8G 4wS4tMlFR4AJZIpWN5gAeLZhCg3jfuKWEgAIVwJZfVPp8qFTIMDCbHGcmszqeDKj G5hY8q+KeQBs7/jjibY7QjSk+qFvWPlES2NGCnjrD5NL+T5W0AlQZS3kgbDWbnSm r/xr6OzL8+bi03J3gRW/oWmCIlzvxUJuLgR5M3TRS4GqYfNVs4etgIW7QZXwTo/5 W8zd5P8UcKOuEFPtmfRjoRZYY30TqrmO9BQkHLKcDbqgnWcm55HaRdkK6+j4tKik f12/VXez1tP4CkHcMJWE4g3poANtZmHia2MPO9/+1P/pCxUb5jwBF+CDiDhDel1Y 8b7u/ERIugpl8TqGJx+GkUlw0cotZ7BoweNwLXwDDDQlIoA4BT+LFLGQBtUQKMQY TrDv4PUucMfB96yiEwlw40IdkmHgcBxXFNNxDHMsxEIW2TYoITfmkShiIm7XkcSE oilPpHFmh6JXpnqOsBhfO0FxKSWkNjsCKCMUGLww5kKJAhwEEAEIAAYFAlWs//EA CgkQP/MbrxBL+eLdOg//Z9Tcp9kElDdZl3e6aJqGpGviNqIA20KbvYrham5Kn3B9 1LhvMkypT6fZWAwbNCBHxvOSbOolcSSLpbaHK3A5jsg5MhLJ2G3Xpf7Z91+Mqg/H iOiJkaAhPoJ0Ny6BCB7jg3yaKLDP4wBwDbOH7JWuP7uQmQ12mqu6WFxok7e53bH5 i4gmu3QIO21RXyWoLJy/1Y5X3ljPZ1tNawy/Sz8UjeLau2Sl1mQ6JxWWCeLp7Cvw p+j6nKOFm/hVDlgnFrfIp9aYHjR2fVpwIFxvfff94gm20EywerlcGOAMeT+1QKZy 1V1ekBVX+2zdQ8RPJGZPqXyxnLg9SyUhdLJBPNDNe5ALfolfn2pvBGM3hnRunGOs PrK53WjGqvXXYhyIkJEd+UoyQBp6zUY/KKFK/7yjgZxX7sCSwNjDlFT2fB1gfll1 vKoYocPQl2t/B3beKOZJzBkSMk1hBdE0A7URkOoYrFQTdzsSUVwY+/0IAhvxqGKc HhinLDFON6ee082511VVMrSbCxcnsThjc61CMYA1TxL01Jzb3QIoTWT3W1t2HRZD /aXcDsg6UMHm1xC1MdZKeKpdJWrnnseC9b/tGuqw2EHitYDquVBmPkx0UoAdsbB5 ec3q8n4J45VJFJcSrrps/vRSNn0bUqcZlpZSZERdqBTBkbizxgFnvJx734JLhlaJ AhwEEAEIAAYFAlWtG6MACgkQlWNH9vvzpBVikRAAmfUzps72Opq31lRHZXXGD4/H FP9SyYRnWzaOWGDMfgO9p3IcRl3qRwOuThCvn+qxTHmRT8KUD8uko9zIU+ttx/zx An3hvO1nCzsiW33N4vU+Y78Uvs7Rumm2CNif+dKDL41FnVpA191b3T3NGWfigvqB 78fWv/WJIuPJuAhCoJYFbK0Vv2/QF2UAo9O2wdBo0ELZKmP5tWfJuLbc8XzuzgaP 4xzRdgJ+P+IFA4q1zQ49FHQeRWBSWkxFAp3iI9sdH5Na+Lup2vLSDYYmdDOyII5w 5QQ+Y8M78Bvt5GBOk52KfTH3oNjDwtd7ae46yWrSy7razs75klSxi125IfcPr/r8 e6jt08WVDZRak5mLPryNlf/Y+ymFe07aIp3eiKO1/SJp2K73fCTslXDt/OuzKZSp 656hybxUrRPiXBxHMOWkcPllZqBXf6GxnN+Fdyutk/e+0EBjpK02AxHY3igA3411 2ZGTGXNCL8ywTidVweOfjyqiWAnCSUvF6+efjRgg2mlD1g6ZDRiKpl9p/ZGETjCh urlpGSKhtCZWZIGt0x0iSLy4surqDrwwuBqEPSZ08KRr+q9R8HIPuAwjq2CjqDyj DFNuLx8dhbUUVIAl7a9nJotsph5VK7c/BF0uLW5YnPJYsXG7z1KixL2ydoH1kL41 zXdcIWBP8H7yPVgUxCKJAhwEEAEIAAYFAlWtG98ACgkQvBcwG0kbPyEIVxAA4imw p7Df/j5ZZcZ+kkBwAhFO+WnJMfkNNl4g/7vsFKbWFBpiYuGmlvX+poM3nTsWCuEv v3QohbZHGJS/hY2kdAuxurTI6w4FvvJ0Akz1DUANIF9gfJ9Omu2Znb9xG1fzyCSc EzUgaf3aim7zyp0arjjqR/msmd2sCjqvy5VgRK21tYAfhWmzdJQntIlCEExfTh9x guELDLSK3j7ngZla1T3BwE1dlcPVD6l9bl/7ZV5uXmotOqFU+1dBcFG4NKNXmnG5 TV7x3Ih6Xt982SCpBgVsEow1XFPf0jflPBn6DGJsgpmuIjdymgpJacwZCYkGbTSj wAeSibYvCw1MRYtrCXd7KlmmQxhYTvvzyoQSqaiIQM8daaXddcy4IdHoOoEJVzfA /BCyEkb0KhhjTWXQoRBXcxhJYOUjH5nhHd+zml+MHHiy1dL+xANHaBzFaNHpxYUs FN2MLcMW4rpCnOx/8pRu/o757Y2Ps+ypLUbGPxZJJa26zYXXTAUDDEgEFFM9Rifu jVCps146sRbrodzgIajc4ScgAWVkHDTKYfq6IBLJZHp8KB1fYFkVrUtwjMmyZCpG 7FqWITGTWOoRbYAsInWuzT7PN+vb/sk0xOk1PzSJV1CmCH9izKrTqRAU42jd4yqV IuQ3hN8wXoeolSlK3wl27fDtK2EDzVhklvjGdreJAhwEEAEIAAYFAlbwOBsACgkQ RPRuFG0COV30vQ//Vzyu44NJZrDWdrAyMngMOZ+qIUkeRdtKHEzAFXl6je1ZLyXT aSKhyWtdxD+NPA4E8vQbEqbcpvzkBhOgfNgVOxWUxC+njB5xhg4PuZLcffm+98S3 ncyu+bYuhA/kLgOJA2HL1vIQEobdM0XJhVM8G7bhKKSdS5NUd6BS8AgKL5YXbguO ZwDVq0yuVPg9VNqG5eTwL8fvZhH4L6I5Rh/wv1g++FvnEGRR+7ePprkc2pnJC8j3 7Z08YzRf5aWCJu89EDsL8wWI/jydPcGLnitNEROfovRX/A647VUl7M4kL0oyblJb 9JFbzPK97YeMwQTUYQOHIp8KsYYKjuBvq9q/Rr9DNpyijp1pshfjEiEZ4YDjTkGX uWu5EMSlVpC4nEtiBlKT3kMk1mqmc2F7A/g5ug1w+e72E1EbVJMDtAgzjc0+V4kt RxtTGa8PlfyWouBwL6ReVpEyVz3NS7++QcSY98DgMODMxFggna/zf3bef/lC6RGk kHyIOC+IhI+q72m0MjdCmzsSA8fqT0PNYs349+sCKw6ocgjSHZlR/8gEZbZC+Fwx Jf6be2N7eo6hYctOe5XpLaMApVnD3qtw6C9CxWJ4zT6WLyI0SAF3YWmIgLtlYhfF nRs0ObRXiO7tz0FBuTXD3vljjzq7t8DDK1IS4Cx5AnTZI4rz+/aiD0k5AhmJAhwE EAEIAAYFAlbwOPIACgkQt4bvJaijiaC0TBAAppcnj7MhOQh+yQCzljw403/hEW5/ iVEyhfkEtF8lnJQPwSCvKphln4B9/E/Z6HBZ5MNew9xj/JrL/JZfk+E81vSs/fhg lCXB83bFo/fZ6cnqhubcPlXyXLSAY7J195n+DdInbza5ABuaJW6UeVHbGGM+th7L S6sYmzoOM1oU8mLzugo57M2a0SZNE2GTjeHFzdeFmKtjk6zGhJcdDMvKNalQZyuf KSEc7+9j5r0KlJOWY4VMqfYMY6qgiQ89IVSutWbhj+oiivCgi030sXmrdOSwG8/G gufKpYOQ1ZLXrxzowYJ02vAewYCe20PTyzGt5ReB9XkokffvHnKcxHxhyC6HiAyG B+8+yf0tJk4Fd7uW6zjGDvphPQhH6bPObVVaMiayEfJhhHbRNmJnUKXRc2CGL0X6 vbZ12Y1bAALAttEpsNC544WMwLfUCcGfaRTF1E4OpQucU/uizaxGPiUd8Ateqt+m 3GwjY9HAb9QN8ejiOTkH6XsYSzw4KA4iPqqMySHY/DMyfFuilNWd8m93agApO+8r 9+6xjurnbkh50rYtunP3FCMul2QW1wXaGxPTt7a/IcL00NRVwZmJwa3Ys1OrYMRA OXM0QvRzpHZOsuqHG45jjaRejMZKSQL0zJOyKgtv4YrG1fceLrZWvu7ZjWVNd+0B nGitgBkGm5VQMuGJAhwEEAEIAAYFAlbwjIoACgkQpIWg7VG4t8QFOw//YFD2UifK W2VfUy2ig+ewXOwe/BzVfweN/Im+HSN94ooTEwR5wgdYIjxPV+eEKFfAEsazv8b3 ktZJI+/IxEalHBA+mR4TC2/UlrOgsVCnTHYKL5yJRVHPrdOQ+Zm+kk4vszYocDtC SPp+/aoRE8u91i6Qu0UdGjMe82HG6qdzVj6bXH9ZFRiWRsfkGxB31cnvfE+aZB+V qfuy0pbqegJXUE/6In8XRsS12xAk58KM0b8jKQGqYaBB6xE9WDpip5sPycougy6U 29170n+U57c6+x5JQhHC/Rb2AqB8Yl1msC4bj4UsqxWHmLRdcqZs04GiVsrk2fLD fSfsu023IZPyOhaV/t2KE4DwnAu4b9Sq7PNNzf9yrsgRL4c4OzWEYpMzt38V5QRt ETJvuuthOypREVNuIs21oRomMJd+PjGsayDuKA7xe/SxDe8tPkoy+FdAfevPXfhy NWX0vTtcZDpVustEMmoDs7EzlBddrNplsnRZoqW2JyMLErLujc5N8juDPqmAASVy d7SBUD03e8apjzZSfJhbZsxw4W9z7+rETRSy7o2DPXCabjTGwB1naIc9W4wU/aWU N81qZZecKLVLxpiXeoUwF3VIJme5Ye1KumsQpTJoi3tVmJ7XDaW9OD8shJtvhlOc ddt1E4kl9iximuLfhzUjPJyS/ASYhpPNMVSJAhwEEAEKAAYFAlWtDgMACgkQw701 5G3UXaVUfg/+P9+3vFqijhzT7XkLuNrI9GTn3KslTAPU0Oe/BdLPTMKELqn1YVxk lnrznLbjL9qkwYwXxY5HT6ykeS+CzQIDLLtXqR1NAz3EWVAm4dT+xqaJZmfCoJ40 +VqZdQHLjgmj9PFTK7f3vyZ3Ux6em7Z+h7C1ba8jYZS+6GnmGw6+v6LxzRh1SFUm YBj/X+GPBYg6cnymr+9b2CwTMbczO5XN3hU9UtdF4UlupPvEuV5XWFpCw64kVwxP OQvvUJ3aTqEGiCAqd8ntyVZ1MWtaob7GI/bj7dTOoSogUqF3aZawfoUHPp6izTd4 8aRnZhpsK47Y6jIaHDCILhKoAESTnpN1yjqaRIbviHJyYFOHnQESTS7AWrolQVmP +pmThZWauh+PLVcs4ktp/6CKYvmgnP30HhrPczE7RVKIT32LU3MvT3nFzDmKUruK eLUNO6LnJ8XwZEVIE3TOVcF+2ME3EcKfV4RwAlBBgYa8DB/CM/rCtoyxdxYSRpHn 9bxbNL6kn+CPAwRZGAChfOPGMhHBh3iDUJaIt79Cq9j6QcZUYfhj1sIvvkDyl0Bc 5U4slbTM6KP5aZgFlCcI9HWwGx/5qIbb1rQNVjxwtiUWediS04YaQ6yt7f/yXbdl hxPdXDMe/9gdDyuDvP4+1FZbDiV6VT7Bl+UhQnkwf4kuCbSMFjdu+cyJAjMEEAEI AB0WIQRZyp4tKjMd4lGqJCdfA8dnwkek1QUCWQ72QgAKCRBfA8dnwkek1aBpEACI 6mkO7aXYQyejkTbSyLdE7FoNI4Nq6aKvvQLt+vlGATLgSdz8v7QLGd3KkJYoO5SY kKjrkGZG4Nb3GOCnWnewBmvCqt7C5/Idl1JTVPdF9CgMHQkwP2F8Tg5X1Ag9oZeL yRKB/xWbX1LGizRy5s9G6yhq1rwoatNI+Wz36fdCmCqmphm92uPyxuAxy+JZhAbT /vmANGKlEN5Wjryrp3tmMEhnuJykWq2ZxYiJ9jpx/cNLyjf8fSDBhLXOTG0FYBrZ k+ZJtw1LlzA36K7IbnunO2qOJzDgvemo5FmGYcm6hyYCzqxBj1VJDmhHu7NZMeMn vT4d8Py1xBPGPFRYmaK5AP/D07cdDPYawlZA6dMPGE8xSfQxbrayJrj0+vpjSJPt DUHrg7L+PdpvyVxi8Py0Zfe05h6SjBPrw3eTQS6ODkoZQyh8D7M2HKUiUxvfufvn LEfeWpd7Vp7hl/VdP3TtbOzL9H/89O5ywf7S/oRKaqgOWkYhs3cfyjqz2boQk8nw N29sLzm5cH+APxNcju7sz07klp8dRNeImbmgj8mT1xId10mAixJ0NOY8udLhlwg1 UfsYhP+Yvy9yMcoSZOs5+RjluW/E2qubP3RUt81ohUupdM0NVUJiR/I3Ri6ARb3V S2aAGtW4oS6PpyVT0dkWrlp8VqFpNTUKE95dNi5Og7kCDQRgos3VARAAtSRABroy kqOO+3Zq3pehRGM2aft2djiigKhhVg+eJr+YffIU2Q73l9zniYSzVMkFVuJPd7Wk BnlEMIn8BUGh04op6MV+kzX0guu3v/9i/0agNS31xAdXzmf1i5sbQU1eRylyZRSi sM2iuF7BYrfSsOBHv71cf+iM94KxrzXiB1bDNL4DN0T5+vCoDjgHaXbten4Qdm6O djBCUv9Ix8dhT4OzHwHOUK7gomTrQM6Hyb0vgQsDXKV2Ps/pWOSk/J2cCrQUrafF qkVAAC3m6kaGU8te6YlAU7GFcf4MOPw15WTM2iaKWwPkwK9b/Ro/5RfZbqnde8EB AoFkg0X8mshGVDBtYCaW+1qUA3ZBcQzUvosYUsNQC9Nx8Y9/tkqCwIBUzsxuIrSY HxeqPThxSMvCmg2qHXmmbAxsbOz3DTOwKpWSRGOCTGFpsLBqWigjG+L+9iIx+7kr 2gH8tYck1RPyQm04k9udD8wwXCvylTUzNVd876sN3o1xySaO5nz8JtM//xPPctFF MZmC01bBn+jRuapDqY+qTFL+eKherOUZgs3nHt7cEBz3m8neGg0/JhyBwS6sQF7h 0ETBapVDlKCRuvAgJHIrjejL5v+kVRrH9L6ey5CAdRG9SbffsNwZoo5o8SrdGcX6 hpFiqg1jZWvZv5x7/PPSW7fPuNNHsoxVRn8AEQEAAYkEcgQYAQoAJhYhBBTyZoLQ kWzdgeN7bWG3tSbZjwNTBQJgos3VAhsCBQkDwmcAAkAJEGG3tSbZjwNTwXQgBBkB CgAdFiEEQ2D+IQnEl2MYb44h6+QekPbxL20FAmCizdUACgkQ6+QekPbxL22N6w/+ ObmFWpCr0dmV1tm+1tuCL05sJ031KFl3EkH389FmrMMoVk49e7H5Urn77ezQXO9M e8R0nZgVUavJdKcJzgf1IZtLq5Vq5q563I8gglr8rJaaefGYuv9jitx/Ca2s+uvJ MUHgMeBPmFFOKoIF8QgOJdkSht2lIkd6bd89ayLLoIXlGi8d6K4tEWeMigtds9FY cyX7o8xXmt9XqCIaMbkJtiUzjz63dN0O81UCj0TvK17KXAvclhzrriZuo2rOeDTB cQmKKy2UKZaJjUqiezuOg1t513ZIzhy1oXzg5CJb5jgsmZmjtJjr161fv5d8Yock j73z2/z47wry6ThESfYSkIxJIiIP5SwZyNMeeHSZUnaMTqzd5kDL5qnNrhJHCBBy xcIBcGppv3VjZ1QNU1k0Tx+MzpfZtbE//idw+Q7Iz9T/3zjN79JhYi1tzzaaQR6J oEiNMpHHkdkOGRwfdipM7oKl7HKl+zJCzaLTE4mbInCxSgn+1RhI+rGzTXVxqIKo nYrWra4EVBAgguMrxNMjuEtbsF54Q27x2+H/Mew+et6K/suqyh63Szfd14LWEj4N aR89tEz76nJyJFuFtDeGSmu68/Pi5S8Ls9MxKJJiIJmc3lQqDUTHEiLc7RtZAsgA WlLc6UnFsaCqXKJxuaMs7qFD7pqSGfHxYboBxax7Sqrttw//eC7rghiFzfcnEZQn 6+GPW3FJc5P1diSLto99six3uaWKjvSnZScvPOe8ogJt1JQpQAABoHfd7HzzlGzJ tU/yDL931WD6nETp6b/dk7t3aUpk8WFMG19L+L9QbEpjxDi2wozO7CGg6FhC7mu+ KsSsorLqd3QYKoBLG0Pb2K3Zz3PN7y17kf1Aixa2//prFNfpEGwP9flz2TUvSdtd 9JvcnDz+/3yB63tmuCsUPZaR3lhTkNiXZG7WTALA1AqIUKFpxI+cOQxaO2+H6XXi ON3x8A2Pzd1mZyuUMPk2c6I/c1ZfzJXxF/WJVfuztZXNCGocYF4kB3X07uOuiKrI DMXDT3Op3wJ0RInpjyyPlwwov3zIVQcG3mfWPclXNcIRSAdadLq6yhTBUVbhMd2j 2qga1vtaVlH/m0zFhib88RLf1/FiVX76D1q+anG+gT+SsMPd7hSGQQ2+6ngBAvx4 T1IHtFgPqfNaA49m8b3aAorGo6Bbzmwh4Xr+7DM2fSskBskGdIPZgA4Vyu4/PC5a CTyd0NqlBgj/g7XRQMGvFRkdnEIcVZbvxdzn4j16dS+43dUzFMLKThRbkUaunaYo ZPIYuiqbwCoFX7vJdgBMaTxYfkClc5LJSVr+X+9RYNwlOn4kiQzKstVtl/qfpDow 6QsGmA9J7v8Vt9JEg052REcZZmC5Ag0EValA9AEQAK/z677fpoVUj4zQz0g60wVW f+1y2lGb8iFYICmvrJyaEra5SRkyihYA1WmEzhN4T//tHw3UIfe646+GkY3eIQW2 jY9DM2XaElmMN8k/v54nbn5oD7rNEyCTFTvCOq5d74HH1vw96Lzay1vy45E7jPWv qfg9Se8KAnzElohTJjizyhU+0QbmPHnQlY8gOkT/SvRo9bFEUnqjWh0fRq+K1tdL PhcFB1scc25iFqh9IAKUGDur8jQ+SDHCjgQlkFOg3rbqtaUOnVHPohfrBM90ZNwu neFgQY7ZFSUidCimp/EN4CXnzgjDYXUUA42S8G86+G4KAJC22gRQo4mcVmehwHTH 0glfLmUK7TEu29A1KWNL3R/R7ZdyajjpCvUaK2A0Abj3ZE2BSDbJrVlbBVfy5kfP dZjhd3wUWqFaDHiVcImcjZRWPncllhcy6fhqEy3ELZrkezpJjnARsVkij3GXz6oX +HVULne2w0dkTXydR6muZI/GeNtrLHmA8B3/0/TllmLy8ChmYZVIKZ8zt1ghq3f+ hFTXgtZil7eBewZgA6L+EXXK6dZj14lbe6CMS2kungTX9stU1s42I+WRbiqiLpAx CX6qcLBOWrJwsOep2nvu5bhrPHptSfRhF4Vs1xteVFckCWhcLgdYi/Je1XBEM+AA Va0k1FiywCg7MqlG6toLABEBAAGJBEQEGAECAA8FAlWpQPQCGwIFCQPCZwACKQkQ Ybe1JtmPA1PBXSAEGQECAAYFAlWpQPQACgkQHGnE5V6ZBdsvxQ/6A62ZteN0b/TV fSJ51SdG66amwe2rpRX4UdSw7ifxo3qhgEICQmXR5c09qXwl17MFJWM3FhGrbxnA 5KGgeWGtqrPup4QZPKU+l2Ea2QLSJSiBq5QqqEgZvR14Lhr/hCGhBAq9s/xbp8fb KNJj/uWiZ+uTPbt5T5rgKJ4+g3B6DNO1rH7F70OLrd32mxZs4pSxngHRAyiMPB59 yQVDsVMha0JTqC+P96itUzvnInc/9mwE0EMiBtpDTkoBwbJVPnuv+7FjkOLn5s5u 3RLH9fe8z1xnV0fPC0/ndrlNiuBpAn3zVCsWasvW18Vz8K+CQY8Sw0Jw75edBgFo z2QMFxHfDpMJefvMadB7mdte1lKk/Im9KFFH8Idh9b6zD0a/+Ooujukx6QpFfAVh e2sT2CIm2nmMAuAZI2cCt7SC+REn9n9MSuIWxN8YTE3qgAUB6F3ea0O0hGlLl+z5 UOfX0bNAs+ebx/P6PczJtDzeqpmRb0QXqo55JWXLvmXT/fgjF7fNTTLsyCtV+xH6 ZFKGpvGJGJMHApEbz2a0hy12RZH58eI1ueN3Tzn8nI57+oYSsqFw/QgcdGXDonLG JsPVzIpQRg92/GXSukWF+MsCjVOilHRSY1wfPPmJ7+kMQ4rdXpjAhwNYJc1ff5N+ omCxCKoFgYsCXlFCHFKs4JwRbTdd3MkuqBAAlBlIjym8NyJIBltfWckuhQTX4BiB ltGPNga9CpQsml519EePuLtoe5H0fTUp4UYbL0ZzyJImQE2uw/hMNZ36bA057YtH OoP4FcPUwv6wsl5JC87UR1XFhAXb5xSU0qdi3hWh0hm772X6CBlM8lM6GtT/fDZk SGNXMQaIs1X/O9vf8wGg+HwLJcaCvybI4w7w1K0R7WjWZlJXutCZf8hRc0d88W/q SZYooKD9q2S7foqaJhySIaF11sH5ETvVP3oCfGVIVhKWb0Tp2jXPXlXLeRAQA8S+ 4B1o5XHiM+J3SNXhPQHRGQ3VGcDn45itg3F4xQX2Qvo4SV42NMYd6TykM/dIfQyJ DOVg3CT3+nqfjCknf94SNvyZprHEPmpcDeseoPMw8kjKNwDwPXFLxBRntPgnqVXD cNN41OH2kqx4jF7FLlRmwNpB2mFVH8xeVuRm7h2WZRsaEoqvivhzRtESVA2um5Eg 763CVTcNYlK6MD/iy8JzbMuZBrlOHr58HKDdcOy1W0z2quESGoqrwA995IgPav/1 DSpyuJPNc/oUTWlhpYshqYKoflezAyKj30+UzC3R/mY03ri6zUvCgXHNgZlKUsM3 VEXk6h5oDuaXniHLLzuxjTBVrILnGYgHSFRP80L/knz+o4Uvq4wj7NHnruc5fP1f oFxRNsMt40yRJfW5Ag0EWUvZtQEQAL4dTYeBoI6UxWcu7kERc+Tz13WUwSPmOIU6 RdoXqBc2QyOki8s+uDqIJbpt2YJUPWnPgoU0rDt+msOG9tpAjPVg5pHJe8H9tXxv aPICQ1YxYw1m8E1kRGio4EurP2G/H/YI3vwRskqI8cp04t88k1DfeKvXYVY34kO/ VM12XTfRcsiMdmDubTqNPYU1kmYNeqMT+OzI9QE2kulCK0DHDJzqdJLnOkrn1z0l rFAPoNpVtHZh4D7yB8FH3I1qk9npRdNXvSjhXu4ptvRuszktjEcfHK+ikYP3jVqR 4eWiOKrkVIWJOCsOKIUE27PXndGLbUuDzCvrKusR6W9vF+mYK1p3pT2PYX8HEeJu zrd1UFBvCWPf2k5RQqHk4JIaKfjAlCPnSXmPHXqSGtD083RJhFkbz4U07/glHWer +M+Sw+hYT/v+XOhQm3CG/PUaeX2ud6GFefymX/tA1FYJqVxVOye2axoA3lO7yM5s K/JHMdL7bFZtXVcGCwAqU2mkD2yEkFAzPLBHKigKg+4VimsTbG9jPOS+qtv65x6u IOOsic3Ud2/BB/lfbvplIvQyJYw8HKb8O0XkUPcD3Q1i8p54JSHhiJm42H699uMm iJeLzTkQJG7KApEv6nOb+jLyr2DZXuX82/UvZAmzWZg/XOf2xz44/RDXkL865dqR YenXNaOXABEBAAGJBHIEGAEIACYWIQQU8maC0JFs3YHje21ht7Um2Y8DUwUCWUvZ tQIbAgUJA8JnAAJACRBht7Um2Y8DU8F0IAQZAQgAHRYhBNzqxdlhNbkcTqZyq7u+ vbskxvNVBQJZS9m1AAoJELu+vbskxvNVBVMP/21uU+8NpPLpBn6SHJtIAffFYMSn p0gplOjfiItA8HDbc1vqZlVpdk2xyFw6b7g+vTg1gQzF7uoAZK1czRLCt7ocxntL VgPuSO1ZHt4hJG5Ze1UUJSDq8Pp+TTL43rg6irDLdYDBBHYESnXWAKRAIuPb1e15 6pAdpSynwJ3+qPyqj5vDLkPrtMWGp7qWQpXcHaXMea8m4+/RLNIjvRof/t6jrUer mzs91Z+/C3N8ugD/aZrXTiNkF/H6BiuITZoB0j+rjy4fxEQvTYq9C3NoaBIRxJEP ApxGnHKe9K9N1ZBELjCUCT1MkbBmf4CJtEgJvSScVh1yZNv+TVDfN6RwF9CwOM8b VrOH1VuX/L/XiIRRT02eGrvv3EvQ+BhceJpWN+GsHKQM658trZ7RhHo2PR0ib+D7 hWQprcktqutTfRFPMrgcFTPXKeR57cxvjk+B2LoLSOom3oTNEtUaMuBE8E/jbONX 34QsHWDKfLc3XpLEN+bO65AfTiR4/qtnZBmldBUG9xbrW0qcWz+M5P3S6ssbor3V DxxrX+Fv6pJccwlgYNFQxQOz8GrZhF0cU48e+0XpU2NFeyueHQ8lb9yYdvhc7mkG c87iIb+ILah57Wqi52Jd4f0DS2zkxN6ab5/UVEkffNwXfjN0IW28Ga4BtZvoXVGV Jo4vsGytMFdMRzRB/uAQAI21c3TTrO4TL42NcFQ0RY7yAlaKzXTXVNxC8v/QQKIs DrNvs4w15rF/t2LXc8Cr3aUNuDtE7x+FaNwZLypCe+RFOy66AG2ENuNt5tTGN3mg bJZl+01Cd1xPpOzmRfAJnH7YD+J4QuCEEgraAXPfp3MhjeHWtQaWDu29fbTtPx0k /Bh0qxHFPWxhnYpktnjZEoMmwPMBeitCvcr66UzUmezgVZc0HxJ/LO9Bss7P3egv 60wPnXn579wDGnIriDUhHRcn2KuMI7eT4pL4HHjAAJB/8+vcUzYPuqtxULf5ciu8 V+ajzHtqBcgwNR/gm/7i+4qKPo14fYBftH5PDj9iD88WIQX7paVbYHJZjrmnpM2i niL/DRVuxqAPToIc4hMXj8YPeTqS/1ckOzyYgFI9aRaLxZOR0uno1WTRBifwOcy3 NTwSHK/6YbtJbqoVwISJrGUuvOfBlkJZVlCzVsPG1+QZaPAL3HxVXavYgCu2hze4 OOWUe2Xuqihw8hb+F1rhP64/QtpjPxgLLb1NIBpm6OgdZjRjCbl9xnd3RvH6hYxO +zgdn3icn2fFHhdZ7xtYcZZrg9QOXuv6LDvVe5I4VyszNs0jtdcx0P+T5VIrKFAY yf0CCuL/UQTRrW0SrKOV/RZHuvdpVYK3YIAyd49kKjLk6O9awFQy7cXq3PhjatBi uQINBFzwOeoBEACt8eaLW7jX3n5tQQ+ICeGOBIVbzAnXlH9bjdTqollM+iiwkdlB NNEGku7+uQ9dTofem6cbSUXuh5kJNLy5tUIG4oGZLvpAjLdHP8zslgTglQymoWSb v2ss4pq8xoDbp6E51dkowkyFSuELZKMFHgPiJbfYXxQmbwEiFhGs4+21lwtI4tVO 9zs1XbzJD9XtomxkcYaePeBxpI9JnrWIUKt70JPZi/QcxPMG2si/YitnCVamcVw8 Wri+W7MAJW3SyNjJUqx/cIOib8vdZVxvdWRIZmdkWkFO6vv4IotEBCflt6cD0EIy 3Ijn3nDDf59v7wpdWXidjzVjKF0F8jUiX6S/ZuEz4lvdotpCgJGhDmdi4pVCYbmS hKbffgcSJ/BWn4wCOHKPA+XB75zzPj17dcWR8D9GM/sgusJy2fbHDcOdADPynKW3 Ok1CENJDx7DTDwm2fPRMut4utSL1FMSl7zBDRabcPr1nw+zERjmSjm3R91ayrQ9U KlP/4P8Xkhjc3FFWrRQ1Q7/SlkUmrTqSouQcOolGMa2ENNgqNeOY7oE5xnPs64TL AzQ9z66u0dHTMODAS1A6C0l66LrPVYGoQLDkM7WQn7zznFdnKR2nsPOUi0mMdyrG /62iARtNvuF4xdsUAoCKti3wOsXRuUhiXei4N4qdr8IaIEIFgYEKKtaqzwARAQAB iQRyBBgBCgAmFiEEFPJmgtCRbN2B43ttYbe1JtmPA1MFAlzwOeoCGwIFCQPCZwAC QAkQYbe1JtmPA1PBdCAEGQEKAB0WIQQJezEwd65ioC+E2k3xpmaPu31XLgUCXPA5 6gAKCRDxpmaPu31XLopQEACKv8mYt4aMc0oA25UJXMRig2lXJDqOZBUSvFFm8t6X gdG0zFdzFo4gqpje68kNyt9duhvOMsVwkzUr+5Di7FccvgwceU3X5ngWpnV/GcXg 79m5viipWUdBRoyZ90oi4D5K6fhlmszmWyiD7KDrjdtIdGnjAuprztkc/JBlIwlm u/40JyDR5Dfxp256DlzsJ/HH8LbdjJG/F0XvtZUwcHefa7mDXtIWszsMoJnEoLzO kZvJ13rhJcTHVQImClyS3o9+Pk6DTfy4Ad0w+9nF0rZp+8/GXZGilfn/NXMj0elY u5WiyCBqargRkrHpebNKW9jxRca02aDS2Yrf8dlseO1d9FXZPOBWIxDRG++TqRhB K8FUW00DikRDrrV5RsIiXtgtRqH+hwknE33i8m8/KKC5/pUl3Af5f+vMKsT3s1mM X2zA+NmLUxJCXLz70WqLoShI8QEj+RLk9yuk97bo7KoNSv6xNwXotJKzp08VAnVN X/QddmV6Z7SnocEs+S6Z0L69sEffMgUaCkH09mIt1yu0DaeOl7fM2iD3VcO6jJ94 Dg8olkhBgrZERe3sXR2fciFtsqHxYc9zP7YyL7vPbUQ8BogxEfIQZPGdpnG5pTM0 NSX/mgkOWI2VJFDe/rOFTdTk+8mKVnFdaUfHA48qIeS0V0zMLd4OZkrYlW3iKvZp s6IAEACauiivWdvKvJgKMyi3fvicXn4qL8nV1X6lmOBqDn4bb0N0mtpiqXfvG950 +29rcCJSj6qSMVj8ZHuwVktrEoWX6lpJbWwEdUh+35DnjfGOYN8gW8bx0CfyqEx5 0W++DK5Wj+L+DL7jgJ/l7dMKxLdjijkg+v4yI516nzRbrx3x77U8n+H1V9bHrDfS cESnr3PtWS4ze4yDrr9Xp+YK8A7RkIctH2ToyEixin8utvfa56dGpUai7gIRZ+0b tWY0FX6g/VRHwwhLIzTsaFveQGuzFbXaGkOhRASitKtbQo2fD39qAMixkKOctN9A /nA3dZU8BlJj7258+P36jQDOilr2Y7RlTSTZS5aXeAPbwILwKCNcDjV0keerGSqi V2zkiH0vAJcxVokn+iMj6VOaM1RyxskgFara0Vt3IuAjnirES/OVuIkhgpebmGXB PcHqLWpFDtEdLv6YtOwScE0eYb5/SA3XsmK3qgzEAzBfchwl4PqAhiQAf/tbx5Eg AUbFmwhEcgd9xMY5w6+8/5FjoXwHYmdfjKT9iD7QxF3LnymskoKQQGWBHiwJjaA8 LYPpopUg9we00zNdSGNXv1Lau9AM//ATiusH8iLJj33ofQh6FviQG6W3TlLPqx/o IxxNj5bPAQy6dRKB1TxlWr4X0pUWxuqBeObPoHS9j0ysxKPruw== =81zK -----END PGP PUBLIC KEY BLOCK-----

The post Updating GPG key for signing Firefox Releases appeared first on Mozilla Security Blog.

Categorieën: Mozilla-nl planet

Pagina's