mozilla

Mozilla Nederland LogoDe Nederlandse
Mozilla-gemeenschap

Abonneren op feed Mozilla planet
Planet Mozilla - https://planet.mozilla.org/
Bijgewerkt: 2 dagen 3 uur geleden

Data@Mozilla: This Week in Glean: Data Reviews are Important, Glean Parser makes them Easy

di, 07/09/2021 - 17:27

(“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).

At Mozilla we put a lot of stock in Openness. Source? Open. Bug tracker? Open. Discussion Forums (Fora?)? Open (synchronous and asynchronous).

We also have an open process for determining if a new or expanded data collection in a Mozilla project is in line with our Privacy Principles and Policies: Data Review.

Basically, when a new piece of instrumentation is put up for code review (or before, or after), the instrumentor fills out a form and asks a volunteer Data Steward to review it. If the instrumentation (as explained in the filled-in form) is obviously in line with our privacy commitments to our users, the Data Steward gives it the go-ahead to ship.

(If it isn’t _obviously_ okay then we kick it up to our Trust Team to make the decision. They sit next to Legal, in case you need to find them.)

The Data Review Process and its forms are very generic. They’re designed to work for any instrumentation (tab count, bytes transferred, theme colour) being added to any project (Firefox Desktop, mozilla.org, Focus) and being collected by any data collection system (Firefox Telemetry, Crash Reporter, Glean). This is great for the process as it means we can use it and rely on it anywhere.

It isn’t so great for users _of_ the process. If you only ever write Data Reviews for one system, you’ll find yourself answering the same questions with the same answers every time.

And Glean makes this worse (better?) by including in its metrics definitions almost every piece of information you need in order to answer the review. So now you get to write the answers first in YAML and then in English during Data Review.

But no more! Introducing glean_parser data-review and mach data-review: command-line tools that will generate for you a Data Review Request skeleton with all the easy parts filled in. It works like this:

  1. Write your instrumentation, providing full information in the metrics definition.
  2. Call python -m glean_parser data-review <bug_number> <list of metrics.yaml files> (or mach data-review <bug_number> if you’re adding the instrumentation to Firefox Desktop).
  3. glean_parser will parse the metrics definitions files, pull out only the definitions that were added or changed in <bug_number>, and then output a partially-filled-out form for you.

Here’s an example. Say I’m working on bug 1664461 and add a new piece of instrumentation to Firefox Desktop:

fog.ipc: replay_failures: type: counter description: | The number of times the ipc buffer failed to be replayed in the parent process. bugs: - https://bugzilla.mozilla.org/show_bug.cgi?id=1664461 data_reviews: - https://bugzilla.mozilla.org/show_bug.cgi?id=1664461 data_sensitivity: - technical notification_emails: - chutten@mozilla.com - glean-team@mozilla.com expires: never

I’m sure to fill in the `bugs` field correctly (because that’s important on its own _and_ it’s what glean_parser data-review uses to find which data I added), and have categorized the data_sensitivity. I also included a helpful description. (The data_reviews field currently points at the bug I’ll attach the Data Review Request for. I’d better remember to come back before I land this code and update it to point at the specific comment…)

Then I can simply use mach data-review 1664461 and it spits out:

!! Reminder: it is your responsibility to complete and check the correctness of !! this automatically-generated request skeleton before requesting Data !! Collection Review. See https://wiki.mozilla.org/Data_Collection for details. DATA REVIEW REQUEST 1. What questions will you answer with this data? TODO: Fill this in. 2. Why does Mozilla need to answer these questions? Are there benefits for users? Do we need this information to address product or business requirements? TODO: Fill this in. 3. What alternative methods did you consider to answer these questions? Why were they not sufficient? TODO: Fill this in. 4. Can current instrumentation answer these questions? TODO: Fill this in. 5. List all proposed measurements and indicate the category of data collection for each measurement, using the Firefox data collection categories found on the Mozilla wiki. Measurement Name | Measurement Description | Data Collection Category | Tracking Bug ---------------- | ----------------------- | ------------------------ | ------------ fog_ipc.replay_failures | The number of times the ipc buffer failed to be replayed in the parent process. | technical | https://bugzilla.mozilla.org/show_bug.cgi?id=1664461 6. Please provide a link to the documentation for this data collection which describes the ultimate data set in a public, complete, and accurate way. This collection is Glean so is documented [in the Glean Dictionary](https://dictionary.telemetry.mozilla.org). 7. How long will this data be collected? This collection will be collected permanently. **TODO: identify at least one individual here** will be responsible for the permanent collections. 8. What populations will you measure? All channels, countries, and locales. No filters. 9. If this data collection is default on, what is the opt-out mechanism for users? These collections are Glean. The opt-out can be found in the product's preferences. 10. Please provide a general description of how you will analyze this data. TODO: Fill this in. 11. Where do you intend to share the results of your analysis? TODO: Fill this in. 12. Is there a third-party tool (i.e. not Telemetry) that you are proposing to use for this data collection? No.

As you can see, this Data Review Request skeleton comes partially filled out. Everything you previously had to mechanically fill out has been done for you, leaving you more time to focus on only the interesting questions like “Why do we need this?” and “How are you going to use it?”.

Also, this saves you from having to remember the URL to the Data Review Request Form Template each time you need it. We’ve got you covered.

And since this is part of Glean, this means this is already available to every project you can see here. This isn’t just a Firefox Desktop thing.

Hope this saves you some time! If you can think of other time-saving improvements we could add once to Glean so every Mozilla project can take advantage of, please tell us on Matrix.

If you’re interested in how this is implemented, glean_parser’s part of this is over here, while the mach command part is here.

:chutten

(( This is a syndicated copy of the original post. ))

Categorieën: Mozilla-nl planet

Chris H-C: This Week in Glean: Data Reviews are Important, Glean Parser makes them Easy

di, 07/09/2021 - 17:26

(“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).

At Mozilla we put a lot of stock in Openness. Source? Open. Bug tracker? Open. Discussion Forums (Fora?)? Open (synchronous and asynchronous).

We also have an open process for determining if a new or expanded data collection in a Mozilla project is in line with our Privacy Principles and Policies: Data Review.

Basically, when a new piece of instrumentation is put up for code review (or before, or after), the instrumentor fills out a form and asks a volunteer Data Steward to review it. If the instrumentation (as explained in the filled-in form) is obviously in line with our privacy commitments to our users, the Data Steward gives it the go-ahead to ship.

(If it isn’t _obviously_ okay then we kick it up to our Trust Team to make the decision. They sit next to Legal, in case you need to find them.)

The Data Review Process and its forms are very generic. They’re designed to work for any instrumentation (tab count, bytes transferred, theme colour) being added to any project (Firefox Desktop, mozilla.org, Focus) and being collected by any data collection system (Firefox Telemetry, Crash Reporter, Glean). This is great for the process as it means we can use it and rely on it anywhere.

It isn’t so great for users _of_ the process. If you only ever write Data Reviews for one system, you’ll find yourself answering the same questions with the same answers every time.

And Glean makes this worse (better?) by including in its metrics definitions almost every piece of information you need in order to answer the review. So now you get to write the answers first in YAML and then in English during Data Review.

But no more! Introducing glean_parser data-review and mach data-review: command-line tools that will generate for you a Data Review Request skeleton with all the easy parts filled in. It works like this:

  1. Write your instrumentation, providing full information in the metrics definition.
  2. Call python -m glean_parser data-review <bug_number> <list of metrics.yaml files> (or mach data-review <bug_number> if you’re adding the instrumentation to Firefox Desktop).
  3. glean_parser will parse the metrics definitions files, pull out only the definitions that were added or changed in <bug_number>, and then output a partially-filled-out form for you.

Here’s an example. Say I’m working on bug 1664461 and add a new piece of instrumentation to Firefox Desktop:

fog.ipc: replay_failures: type: counter description: | The number of times the ipc buffer failed to be replayed in the parent process. bugs: - https://bugzilla.mozilla.org/show_bug.cgi?id=1664461 data_reviews: - https://bugzilla.mozilla.org/show_bug.cgi?id=1664461 data_sensitivity: - technical notification_emails: - chutten@mozilla.com - glean-team@mozilla.com expires: never

I’m sure to fill in the `bugs` field correctly (because that’s important on its own _and_ it’s what glean_parser data-review uses to find which data I added), and have categorized the data_sensitivity. I also included a helpful description. (The data_reviews field currently points at the bug I’ll attach the Data Review Request for. I’d better remember to come back before I land this code and update it to point at the specific comment…)

Then I can simply use mach data-review 1664461 and it spits out:

!! Reminder: it is your responsibility to complete and check the correctness of !! this automatically-generated request skeleton before requesting Data !! Collection Review. See https://wiki.mozilla.org/Data_Collection for details. DATA REVIEW REQUEST 1. What questions will you answer with this data? TODO: Fill this in. 2. Why does Mozilla need to answer these questions? Are there benefits for users? Do we need this information to address product or business requirements? TODO: Fill this in. 3. What alternative methods did you consider to answer these questions? Why were they not sufficient? TODO: Fill this in. 4. Can current instrumentation answer these questions? TODO: Fill this in. 5. List all proposed measurements and indicate the category of data collection for each measurement, using the Firefox data collection categories found on the Mozilla wiki. Measurement Name | Measurement Description | Data Collection Category | Tracking Bug ---------------- | ----------------------- | ------------------------ | ------------ fog_ipc.replay_failures | The number of times the ipc buffer failed to be replayed in the parent process. | technical | https://bugzilla.mozilla.org/show_bug.cgi?id=1664461 6. Please provide a link to the documentation for this data collection which describes the ultimate data set in a public, complete, and accurate way. This collection is Glean so is documented [in the Glean Dictionary](https://dictionary.telemetry.mozilla.org). 7. How long will this data be collected? This collection will be collected permanently. **TODO: identify at least one individual here** will be responsible for the permanent collections. 8. What populations will you measure? All channels, countries, and locales. No filters. 9. If this data collection is default on, what is the opt-out mechanism for users? These collections are Glean. The opt-out can be found in the product's preferences. 10. Please provide a general description of how you will analyze this data. TODO: Fill this in. 11. Where do you intend to share the results of your analysis? TODO: Fill this in. 12. Is there a third-party tool (i.e. not Telemetry) that you are proposing to use for this data collection? No.

As you can see, this Data Review Request skeleton comes partially filled out. Everything you previously had to mechanically fill out has been done for you, leaving you more time to focus on only the interesting questions like “Why do we need this?” and “How are you going to use it?”.

Also, this saves you from having to remember the URL to the Data Review Request Form Template each time you need it. We’ve got you covered.

And since this is part of Glean, this means this is already available to every project you can see here. This isn’t just a Firefox Desktop thing. 

Hope this saves you some time! If you can think of other time-saving improvements we could add once to Glean so every Mozilla project can take advantage of, please tell us on Matrix.

If you’re interested in how this is implemented, glean_parser’s part of this is over here, while the mach command part is here.

:chutten

Categorieën: Mozilla-nl planet

Cameron Kaiser: TenFourFox FPR32 SPR4 available

zo, 05/09/2021 - 07:28
TenFourFox Feature Parity Release 32 Security Parity Release 4 "32.4" is available for testing (downloads, hashes). There are, as before, no changes to the release notes nor anything notable about the security patches in this release. Assuming no major problems, FPR32.4 will go live Monday evening Pacific time as usual. The final official build FPR32.5 remains scheduled for October 5, so we'll do a little look at your options should you wish to continue building from source after that point later this month.
Categorieën: Mozilla-nl planet

Firefox Add-on Reviews: uBlock Origin—everything you need to know about the ad blocker

vr, 03/09/2021 - 19:38

Rare is the browser extension that can satisfy both passive and power users. But that’s an essential part of uBlock Origin’s brilliance—it is an ad blocker you could recommend to your most tech forward friend as easily as you could to someone who’s just emerged from the jungle lost for the past 20 years. 

If you install uBlock Origin and do nothing else, right out of the box it will block nearly all types of internet advertising—everything from big blinking banners to search ads and video pre-rolls and all the rest. However if you want extremely granular levels of content control, uBlock Origin can accommodate via advanced settings. 

We’ll try to split the middle here and walk through a few of the extension’s most intriguing features and options…

Does using uBlock Origin actually speed up my web experience? 

Yes. Not only do web pages load faster because the extension blocks unwanted ads from loading, but uBlock Origin utilizes a uniquely lightweight approach to content filtering so it imposes minimal impact on memory consumption. It is generally accepted that uBlock Origin offers the most performative speed boost among top ad blockers. 

But don’t ad blockers also break pages? 

Occasionally that can occur, where a page breaks if certain content is blocked or some websites will even detect the presence of an ad blocker and halt passage. 

Fortunately this doesn’t happen as frequently with uBlock Origin as it might with other ad blockers and the extension is also extremely effective at bypassing anti-ad blockers (yes, an ongoing battle rages between ad tech and content blocking software). But if uBlock Origin does happen to break a page you want to access it’s easy to turn off content blocking for specific pages you trust or perhaps even want to see their ads.

<figcaption>Hit the blue on/off button if you want to suspend content blocking on any page.</figcaption> Show us a few tips & tricks

Let’s take a look at some high level settings and what you can do with them. 

  • Lightning bolt button enables Element Zapper, which lets you temporarily remove page elements by simply mousing over them and clicking. For example, this is convenient for removing embedded gifs or for hiding disturbing images you may encounter in some news articles.
  • Eye dropper button enables Element Picker, which lets you permanently remove page elements. For example, if you find Facebook Stories a complete waste of time, just activate Element Picker, mouse over/click the Stories section of the page, select “Create” and presto—The End of Facebook Stories.    

The five buttons on this row will only affect the page you’re on.

  • Pop-up button blocks—you guessed it—pop-ups
  • Film button blocks large media elements like embedded video, audio, or images
  • Eye slash button disables cosmetic filtering, which is on by default and elegantly reformats your pages when ads are removed, but if you’d prefer to see pages laid out as they were intended (with just empty spaces instead of ads) then you have that option
  • “Aa” button blocks remote fonts from loading on the page
  • “</>” button disables JavaScript on the page
Does uBlock Origin protect against malware? 

In addition to using various advertising block lists, uBlock Origin also leverages potent lists of known malware sources, so it automatically blocks those for you as well. To be clear, there is no software that can offer 100% malware protection, but it doesn’t hurt to give yourself enhanced protections like this. 

All of the content block lists are actively maintained by volunteers who believe in the mission of providing users with more choice and control over the content they see online. “uBlock Origin stands uncompromisingly for all users’ best interests, it’s not monetized, and its development and maintenance is driven only by volunteers who share the same view,” says uBlock Origin founder and developer Raymond Hill. “As long as I am the maintainer of [uBlock Origin], this will not change.”

We could go into a lot more detail about uBlock Origin—how you can create your own custom filter lists, how you can set it to block only media of a certain size, cloud storage sync, and so on—but power users will discover these delights on their own. Hopefully we’ve provided enough insight here to help you make an informed choice about exploring uBlock Origin, whether it be your first ad blocker or just the latest. 

If you’d like to check out other amazing ad blocker options, please see What’s the best ad blocker for you?

Categorieën: Mozilla-nl planet

Mark Mayo: Celebrating 10k KryptoSign users with an on-chain lottery feature!

do, 02/09/2021 - 04:22

TL;DR: we’re adding 3 new features to KryptoSign today!

  • CSV downloads of a document’s signers
  • Document Locking (prevent further signing)
  • Document Lotteries (pick a winner from list of signers)

Why? Well, you folks keep abusing this simple Ethereum-native document signing tool to run contests for airdrops and pre-sales, so we thought we’d make your lives a bit easier! :)

up and to the right graph showing exponential growth of KS

We launched KryptoSign in May this year as tool for Kai, Bart, and I to do the lightest possible “contract signing” using our MetaMask wallets. Write down a simple scope of work with someone, both parties sign with their wallet to signal they agree. When the job is complete, their Ethereum address is right there to copy-n-paste into a wallet to send payment. Quick, easy, delightful. :)

But as often happens, users started showing up and using it for other things. Like guestbooks. And then guestbooks became a way to sign up users for NFT drops as part of contests and pre-sales, and so on. The organizer has everyone sign a KS doc, maybe link their Discord or Twitter, and then picks a winner and sends a NFT/token/etc. to their address in the signature block. Cool.

As these NFT drops started getting really hot the feature you all wanted was pretty obvious: have folks sign a KS document as part of a pre-sales window, and have KS pick the winner automatically. Because the stakes on things like hot NFT pre-sales are high, we decided to implement the random winner using Chainlink’s VRF — verifiable random functions — which means everyone involved in a KryptoSign lottery can independently confirm how the random winner was picked. Transparency is nice!

The UI for doing this is quite simple, as you’d hope and expect from KryptoSign. There’s an action icon on the document now:

screenshot of menu option to pick a winner from the signers of a document

When you’re ready to pick a winner, it’s pretty easy. Lock the document, and hit the button:

Of note, to pick a winner we’re collecting to 0.05 ETH from you to cover the cost of the 2 LINK required to invoke the VRF on mainnet. You don’t need your own LINK and all the gas-incurring swapping that would imply. Phew! The user approves a single transaction with their wallet (including gas to interact with the smart contract) and they’re done.

Our initial users really wanted the on-chain trust of a VRF, and are willing to pay for it so their communities can trust the draw, but for other use cases you have in mind, maybe it’s overkill? Let us know! We’ll continue to build upon KryptoSign as long as people find useful things to do with it.

Finally, big props to our team who worked through some rough patches with calling the Chainlink VRF contract. Blockchain is weird, yo! This release saw engineering contributions from Neo Cho, Ryan Ouyang, and Josh Peters. Thanks!

— Mark

Celebrating 10k KryptoSign users with an on-chain lottery feature! was originally published in Block::Block on Medium, where people are continuing the conversation by highlighting and responding to this story.

Categorieën: Mozilla-nl planet