TenFourFox Feature Parity Release 27 final is now available for testing (downloads, hashes, release notes). Unfortunately, I have thus far been unable to solve issue 621 regarding the crashes on LinkedIn, so to avoid drive-by crashes, scripts are now globally disabled on LinkedIn until I can (no loss since it doesn't work anyway). If you need them on for some reason, create a pref tenfourfox.troublesome-js.allow and set it to true. I will keep working on this for FPR28 to see if I can at least come up with a better wallpaper, though keep in mind that even if I repair the crash it may still not actually work anyway. There are otherwise no new changes since the beta except for outstanding security updates, and it will go live Monday evening Pacific assuming no new issues.
For our struggling Intel friends, if you are using Firefox on 10.9 through 10.11 Firefox ESR 78 is officially your last port of call, and support for these versions of the operating system will end by July 2021 when support for 78ESR does. The Intel version of TenFourFox may run on these machines, though it will be rather less advanced, and of course there is no official support for any Intel build of TenFourFox.
http://tenfourfox.blogspot.com/2020/09/tenfourfox-fpr27-available.html
Highlights
- We’re testing some variations on the Picture-in-Picture toggle
-
An animated GIF shows a Picture-in-Picture toggle being moused over. When the mouse reaches the toggle, it extends, showing the text “Watch in Picture-in-Picture”
An animated GIF shows a Picture-in-Picture toggle being moused over. Text describing Picture-is-Picture is shown.
-
- Camera and microphone global mutes have landed, but are being held to Nightly
-
The WebRTC sharing indicator shows microphone, camera, and minimize buttons. The microphone button shows that it is muted.
-
- Urlbar Design Update 2 is live in Nightly. Access “search mode” from the refresh one-off buttons, including one-offs for bookmarks, history, and tabs. This feature is targeting 82. Please file bugs against Bug 1644572!
Friends of the Firefox team
Introductions/Shout-Outs
- Welcome mtigley and daisuke to the Firefox Desktop team!
Resolved bugs (excluding employees)
Fixed more than one bug
- manas
Project Updates
Add-ons / Web Extensions
Addon Manager & about:addons
- Shane landed a patch to make sure that Firefox will double-check the version compatibility for the installed langpacks and disable them if they are not strictly compatible with the currently running Firefox version (Bug 1646016), this was likely a major cause for some YSOD (yellow screen of death) issues that were originally triggered by an issue on the AMO side.
WebExtensions Framework
- Matt Woodrow fixed a webRequest API regression which was preventing pages multipart/x-mixed-replace content to finish loading when extensions using webRequest blocking listeners are installed (e.g. uBlock origin) (Fixed in Bug 1638422, originally regressed by Bug 1600211)
WebExtensions API
- As part of fission-related work on the extensions framework and APIs, Tomislav landed some changes needed to make the browser.tabs.captureTab API method to work with Fission iframes (Bug 1636508)
Applications
Sync and Storage
- 98% of our sync storage nodes have been migrated over to the new Rust based sync storage service, aka “Durable Sync”.
- JR Conlin is working on implementing a sync quota; we’ll limit users to 2GB per sync collection (ie, bookmarks, tabs, history, etc) and plan to roll this out in late September.
Fission
- Fission Nightly experiment is tentatively targeted for Nightly 83
Installer & Updater
- Mhowell and Nalexander are researching how to move forward with a Gecko based background update agent. Work will continue on this effort through the end of the year.
- Bytesized has a patch open to add telemetry to track windows verified app settings to help us better understand barriers to installation for Win10 users.
Lint
- Sonia has continued work on enabling rules that were previously disabled when *.xul files moved to *.xhtml, with toolkit and accessible landing in the last week.
As a followup to my previous rant on the obnoxious new Blogger "upgrade," I will grudgingly admit Blogger has done some listening. You can now embed images and links similarly to the way you used to, which restores some missing features and erases at least a part of my prior objections. But not the major one, because usability is still a rotting elephant's placenta. I remain an inveterate user of the HTML blog view and yet the HTML editor still thinks it knows better than you how to format your code and what tags you should use, you can't turn it off and you can't make it faster. And I remain unclear what the point of all this was because there is little improvement in functionality except mobile previewing.
Naturally, Google has removed the "return to legacy Blogger" button, but you can still get around that at least for the time being. On your main Blogger posts screen you will note a long multidigit number in the URL (perhaps that's why they're trying to hide URLs in Chrome). That's your blog ID. Copy that number and paste it in where the XXX is in this URL template (all one line):
https://www.blogger.com/blogger.g?blogID=XXX&useLegacyBlogger=true#allposts
Bookmark it and you're welcome. I look forward to some clever person making a Firefox extension to do this very thing very soon, and if you make one post it in the comments.
http://tenfourfox.blogspot.com/2020/09/google-nobody-asked-to-make-blogger.html
I’ve long maintained that persistence is one of the main qualities you need in order to succeed with your (software) project. In order to manage to ship a product that truly conquers the world. By continuously and never-ending keeping at it: polishing away flaws and adding good features. On and on and on.
Today marks the day when I landed my 15,000th commit in the master branch in curl’s git repository – and we don’t do merge commits so this number doesn’t include such. Funnily enough, GitHub can’t count and shows a marginally lower number.
This is of course a totally meaningless number and I’m only mentioning it here because it’s even and an opportunity for me to celebrate something. To cross off an imaginary milestone. This is not even a year since we passed 25,000 total number of commits. Another meaningless number.
15,000 commits equals 57% of all commits done in curl so far and it makes me the only committer in the curl project with over 10% of the commits.
The curl git history starts on December 29 1999, so the first 19 months of commits from the early curl history are lost. 15,000 commits over this period equals a little less than 2 commits per day on average. I reached 10,000 commits in December 2011, so the latest 5,000 commits were done at a slower pace than the first 10,000.
I estimate that I’ve spent more than 15,000 hours working on curl over this period, so it would mean that I spend more than one hour of “curl time” per commit on average. According to gitstats, these 15,000 commits were done on 4,271 different days.
We also have other curl repositories that aren’t included in this commit number. For example, I have done over 4,400 commits in curl’s website repository.
With these my first 15,000 commits I’ve added 627,000 lines and removed 425,000, making an average commit adding 42 and removing 28 lines. (Feels pretty big but I figure the really large ones skew the average.)
The largest time gap ever between two of my commits in the curl tree is almost 35 days back in June 2000. If we limit the check to “modern times”, as in 2010 or later, there was a 19 day gap in July 2015. I do take vacations, but I usually keep up with the most important curl development even during those.
On average it is one commit done by me every 12.1 hours. Every 15.9 hours since 2010.
I’ve been working full time on curl since early 2019, up until then it was a spare time project only for me. Development with pull-requests and CI and things that verify a lot of the work before merge is a recent thing so one explanation for a slightly higher commit frequency in the past is that we then needed more “oops” commits to rectify mistakes. These days, most of them are done in the PR branches that are squashed when subsequently merged into master. Fewer commits with higher quality.
curl committers
We have merged commits authored by over 833 authors into the curl master repository. Out of these, 537 landed only a single commit (so far).
We are 48 authors who ever wrote 10 or more commits within the same year. 20 of us committed that amount of commits during more than one year.
We are 9 authors who wrote more than 1% of the commits each.
We are 5 authors who ever wrote 10 or more commits within the same year in 10 or more years.
Our second-most committer (by commit count) has not merged a commit for over seven years.
To reach curl’s top-100 committers list right now, you only need to land 6
This is a copy of the email I sent a few days ago to all of Mozilla. I just realized that I'm possibly not the only person with a mail filter to auto-delete company-wide "Upcoming $COUNTRY Holidays" emails, so I'm reposting here.
Maybe I'll blog later about my experience at Mozilla.
Subject: Upcoming US Holidays (for Mike Taylor)
Howdy all,
This is my last full week at Mozilla, with my last day being Monday, September 21. It’s been just over 7 years since I joined (some of them were really great, and others were fine, I guess).
I’m grateful to have met and worked with so many kind and smart people across the company.
I’m especially grateful for Karl Dubost inviting me to apply to Mozilla 7 years ago, and for getting to know and become friends with the people who joined our team after (Cipri, Dennis, James, Ksenia, Oana, Tom, Guillaume, Kate, et al). I believe they’ve made Firefox a significantly better browser for our users and will continue to unbreak the web.
Anyways, you can find me on the internet in all the usual places. Don’t be a stranger.
Blog: https://miketaylr.com/posts/ Twitter: https://twitter.com/miketaylr Facebook: https://fishbrain.com/anglers/miketaylr LinkedIn: https://www.linkedin.com/in/mike-taylor-7a09163/ Email: (redacted, stalkers. also it's TOTALLY unguessable don't even try)
Later,
-- Mike Taylor Web Compat, Mozilla
https://miketaylr.com/posts/2020/09/upcoming-us-holidays-for-mike-taylor.html
As Mozilla tightens and refines its product focus in 2020, today we are announcing the end of life for two legacy services that grew out of the Firefox Test Pilot program: Firefox Send and Firefox Notes. Both services are being decommissioned and will no longer be a part of our product family. Details and timelines are discussed below.
Firefox Send was a promising tool for encrypted file sharing. Send garnered good reach, a loyal audience, and real signs of value throughout its life. Unfortunately, some abusive users were beginning to use Send to ship malware and conduct spear phishing attacks. This summer we took Firefox Send offline to address this challenge.
In the intervening period, as we weighed the cost of our overall portfolio and strategic focus, we made the decision not to relaunch the service. Because the service is already offline, no major changes in status are expected. You can read more here.
Firefox Notes was initially developed to experiment with new methods of encrypted data syncing. Having served that purpose, we kept the product as a little utility tool For Firefox and Android users. In early November, we will decommission the Android Notes app and syncing service. The Firefox Notes desktop browser extension will remain available for existing installs and we will include an option to export all notes, however it will no longer be maintained by Mozilla and will no longer be installable. You can learn more about how to export your notes here.
Thank you for your patience as we’ve refined our product strategy and portfolio over the course of 2020. While saying goodbye is never easy, this decision allows us to sharpen our focus on experiences like Mozilla VPN, Firefox Monitor, and Firefox Private Network.
The post Update on Firefox Send and Firefox Notes appeared first on The Mozilla Blog.
https://blog.mozilla.org/blog/2020/09/17/update-on-firefox-send-and-firefox-notes/
In June, we announced that we were making changes to add-on usage statistics on addons.mozilla.org (AMO). Now, we’re making a similar change to add-on download statistics. These statistics are aggregated from the AMO server logs, do not contain any personally identifiable information, and are only available to add-ons developers via the Developer Hub.
Just like with usage stats, the new download stats will be less expensive to process and will be based on Firefox telemetry data. As users can opt out of telemetry reporting, the new download numbers will be generally lower than those reported from the server logs. Additionally, the download numbers are based on new telemetry introduced in Firefox 80, so they will be lower at first and increase as users update their Firefox. As before, we will only count downloads originating from AMO.
The good news is that it’ll be easier now to track attribution for downloads. The old download stats were based on a custom src parameter in the URL. The new ones will break down sources with the more standard UTM parameters, making it easier to measure the effect of social media and other online campaigns.
Here’s a preview of what the new downloads dashboard will look like:
We expect to turn on the new downloads data on October 8. Make sure to export your current download numbers if you’re interested in preserving them.
The post Download Statistics Update appeared first on Mozilla Add-ons Blog.
https://blog.mozilla.org/addons/2020/09/17/download-statistics-update/
As in many parts of the world, EU lawmakers are eager to get greater insight into the ways in which digital technologies and online discourse can serve to both enhance and create friction in democratic processes. In context of its recent ‘Democracy Action Plan’ (EDAP), we’ve just filed comments with the European Commission, with the aim of informing thoughtful and effective EU policy responses to key issues surrounding democracy and digital technologies.
Our submission complements our recent EU Digital Services Act filing, and focuses on four key areas:
- The future of the EU Code of Practice on Disinformation: Mozilla was a founding signatory of the Code of Practice, and we recognise it as a considerable step forward. However, in policy terms, the Code is a starting point. There is more work to be done, both to ensure that the Code’s commitments are properly implemented, and to ensure that it is situated within a more coherent general EU policy approach to platform responsibility.
*** - Meaningful transparency to address disinformation: To ensure transparency and to facilitate accountability in the effort to address the impact and spread of disinformation online, the European Commission should consider a mandate for broad disclosure of advertising through publicly available ad archive APIs.
*** - Developing a meaningful problem definition for microtargeting: We welcome the Commission’s consideration of the role of microtargeting with respect to political advertising and its contribution to the disinformation problem. The EDAP provides an opportunity to gather the systematic insight that is a prerequisite for thoughtful policy responses to limit the harms in microtargeting of political content.
*** - Addressing disinformation on messaging apps while maintaining trust and security: In its endeavours to address misinformation on messaging applications, the Commission should refrain from any interventions that would weaken encryption. Rather, its focus should be on enhancing digital literacy; encouraging responsive product design; and enhancing redress mechanisms.
A high-level overview of our filing can be read here, and the substantive questionnaire response can be read here.
We look forward to working alongside policymakers in the European Commission to give practical meaning to the political ambition expressed in the EDAP and the EU Code of Practice on Disinformation. This, as well as our work on the EU Digital Services Act will be a key focus of our public policy engagement in Europe in the coming months.
The post Mozilla files comments with the European Commission on safeguarding democracy in the digital age appeared first on Open Policy & Advocacy.
Hello and welcome to another issue of This Week in Rust! Rust is a systems language pursuing the trifecta: safety, concurrency, and speed. This is a weekly summary of its progress and community. Want something mentioned? Tweet us at @ThisWeekInRust or send us a pull request. Want to get involved? We love contributions.
This Week in Rust is openly developed on GitHub. If you find any errors in this week's issue, please submit a PR.
Updates from Rust Community
No newsletters this week.
Official
Tooling
Observations/Thoughts
- Which Parsing Approach?
- Challenging LR Parsing
- What I Learnt from Benchmarking Http4k, Ktor (Kotlin) and Actix v2, v3 (Rust) Microservices
- No Namespaces in Rust is a Feature
- Building devserver: An Ultra-Tiny Rust Server
- Taming nalgebra's Rustdoc
- Rust in Science and ever-changing requirements
- From @Test to #[test]: an essay about testing between Java and Rust
- What I Learnt from Benchmarking Http4k, Ktor (Kotlin) and Actix v2, v3 (Rust) Microservices
Learn Standard Rust
- Collecting Data from an API
- SQLite File Parser Pt. 1: The Header
- An introduction to Data Oriented Design with Rust
- Rust for Java developers
- Oxidizing portals with zbus
Learn More Rust
- Implementing Records in x7
- Let's build a single binary gRPC server-client with Rust in 2020 - Part 4
- Make A Language - Part Three: Defining variables
- Rust HTTP Testing with httpmock
Project Updates
- Announcing the CCS811 indoor air quality sensor driver.
- OpenPGP in Rust: the Sequoia project
- AssemblyLift v0.2 preview: RPC-based IO modules
- Announcing Actix Web v3.0
Miscellaneous
With iOS 14, Apple users will finally have the power to choose any default browser on iPhones and iPads. And now that there’s a choice, make it count with Firefox! … Read more
The post Make Firefox your default browser on iOS (finally!) appeared first on The Firefox Frontier.
Intro
There’s a new Sync back-end! The past year or so has been a year of a lot of changes and some of those changes broke things. Our group reorganized, we moved from IRC to Matrix, and a few other things caught us off guard and needed to be addressed. None of those should be excuses for why we kinda stopped keeping you up to date about Sync. We did write a lot of stuff about what we were going to do, but we forgot to share it outside of mozilla. Again, not an excuse, but just letting you know why we felt like we had talked about all of this, even though we absolutely had not.
So, allow me to introduce you to the four person “Services Engineering” team whose job it is to keep a bunch of back-end services running, including Push Notifications and Sync back-end, and a few other miscellaneous services.
For now, let’s focus on Sync.
Current Situation
Sync probably didn’t do what you thought it did.
Sync’s job is to make sure that the bookmarks, passwords, history, extensions and other bits you want to synchronize between one copy of Firefox gets to your other copies of Firefox. Those different copies of Firefox could be different profiles, or be on different devices. Not all of your copies of Firefox may be online or accessible all the time, though, so sync has to do is keep a temporary, encrypted copy on some backend servers which it can use to coordinate later. Since it’s encrypted, Mozilla can’t read that data, we just know it belongs to you. A side effect is that adding a new instance of Firefox (by installing and signing in on a new device, or uninstalling and reinstalling on the same device, or creating a new Firefox profile you then sign in to), just adds another copy of Firefox to Sync’s list of things to synchronize. It might be a bit confusing, but this is true even if you only had one copy of Firefox. If you “lost” a copy of Firefox because you uninstalled it, or your computer’s disc crashed, or your dog buried your phone in the backyard, when you re-installed Firefox, you add another copy of Firefox to your account. Sync would then synchronize your data to that new copy. Sync would just never get an update from the “old” version of Firefox you lost. Sync would just try to rebuild your data from the temporary echoes of the encrypted data that was still on our servers.
That’s great for short term things, but kinda terrible if you, say, shut down Firefox while you go on walk-about only to come back months later to a bad hard drive. You reinstall, try to set up sync, and due to an unexpected Sync server crash we wound up losing your data echos.
That was part of the problem. If we lost a server, we’d basically tell all the copies of Firefox that were using that server, “Whoops, go talk to this new server” and your copy of Firefox would then re-upload what it had. Sometimes this might result in you losing a line of history, sometimes you’d get a duplicate bookmark, but generally, Sync would tend to recover OK and you’d be none the wiser. If that happens when there are no other active copies of Firefox for your account , however, all bets were off and you’d probably lose everything since there were no other copies of your data anywhere.
A New Hope Service
A lot of folks expected it to be a Backup service. The good news is, now it is a backup service. Sync is more reliable now. We use a distributed database to store your data securely, so we no longer lose databases (or your data echos). There’s a lot of benefit for us as well. We were able to rewrite the service in Rust, a more efficient programming language that lets us run on less machines.
Of course, there are a few challenges we face when standing up a service like this.
Sync needs to run with new versions of Firefox, as well as older ones. In some cases, very old ones, which had some interesting “quirks”. It needs to continue to be at least as secure as before while hopefully giving devs a chance to fix some of the existing weirdness as well as add new features. Oh, and switching folks to the new service should be as transparent as possible.
It’s a long, complicated list of requirements.
How we got here
First off we had to decide a few things. Like what data store were we going to use. We picked Google Cloud’s Spanner database for its own pile of reasons, some technical, some non-technical. Spanner provides a SQL like database which means that we don’t have to radically change existing MySQL based code. This means that we can provide some level of abstraction allowing for those who want to self-host without radically altering
Mozilla and AfriLabs – a Pan-African community and connector of African tech hubs with over 225 technology innovation hubs spread across 47 countries – have partnered to convene a series of roundtable discussions with African startups, entrepreneurs, developers and innovators to better understand the tech ecosystem and identify new product ideas – to spur the next generation of open innovation.
This strategic partnership will help develop more relevant, sustainable support for African innovators and entrepreneurs to build scalable resilient products while leveraging honest and candid discussions to identify areas of common interest. There is no shortage of innovators and creative talents across the African continent, diverse stakeholders coming together to form new ecosystems to solve social, economic problems that are unique to the region.
“Mozilla is pleased to be partnering with AfriLabs to learn more about the intersection of African product needs and capacity gaps and to co-create value with local entrepreneurs,” said Alice Munyua, Director of the Africa Innovation Program.
Mozilla is committed to supporting communities of technologists by putting people first while strengthening the knowledge-base. This partnership is part of Mozilla’s efforts to reinvest within the African tech ecosystem and support local innovators with scalable ideas that have the potential to impact across the continent.
The post Mozilla announces partnership to explore new technology ideas in the Africa Region appeared first on Open Policy & Advocacy.
The security implications of Just-in-Time (JIT) Compilers in browsers have been getting attention for the past decade and the references to more recent resources is too great to enumerate. While it’s not the only class of flaw in a browser, it is a common one; and diving deeply into it has a higher barrier to entry than, say, UXSS injection in the UI. This post is about lowering that barrier to entry.
If you want to understand what is happening under the hood in the JIT engine, you can read the source. But that’s kind of a tall order given that the folder js/ contains 500,000+ lines of code. Sometimes it’s easier to treat a target as a black box until you find something you want to dig into deeper. To aid in that endeavor, we’ve landed a feature in the js shell that allows you to get the assembly output of a Javascript function the JIT has processed. Disassembly is supported with the zydis disassembly library (our in-tree version).
To use the new feature; you’ll need to run the js interpreter. You can download the jsshell for any Nightly version of Firefox from our FTP server – for example here’s the latest Linux x64 jsshell. Helpfully, these links always point to the latest version available, historical versions can also be downloaded.
You can also build the js shell from source (which can be done separately from building Firefox, but doing the full browser build can also create the shell.) If building from source, in your .mozconfig, you’ll want to following to get the tools and output you want but also emulate the shell as the Javascript engine is released to users:
ac_add_options --enable-application=js
ac_add_options --enable-js-shell
ac_add_options --enable-jitspew
ac_add_options --disable-debug
ac_add_options --enable-optimize
# If you want to experiment with the debug and optimize flags,
# you can build Firefox to different object directories
# (and avoid an entire recompilation)
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-nodebug-opt
# mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-debug-noopt
After building the shell or Firefox, fire up `obj-dir/dist/bin/js[.exe]` and try the following script:
function add(x, y) { x = 0+x; y = 0+y; return x+y; }
for(i=0; i<500; i++) { add(2, i); }
print(disnative(add))
You’ll be greeted by an initial line indicating which backend is being used. The possible values and their meanings are:
- Wasm – A WebAssembly
In Firefox 81, we have improved error messages for extension developers and updated user-facing notifications to provide more information on how extensions are modifying their settings.
For developers, the menus.create API now provides more meaningful error messages when supplying invalid match or url patterns. This updated message should make it easier for developers to quickly identify and fix the error. In addition, webNavigation.getAllFrames and webNavigation.getFrame will return a promise resolved with null in case the tab is discarded, which is how these APIs behave in Chrome.
For users, we’ve added a notification when an add-on is controlling the “Ask to save logins and passwords for websites” setting, using the privacy.services.passwordSavingEnabled settings API. Users can see this notification in their preferences or by navigating to about:preferences#privacy.
Thank you Deepika Karanji for improving the error messages, and our WebExtensions and security engineering teams for making these changes possible. We’re looking forward to seeing what is next for Firefox 82.
The post Extensions in Firefox 81 appeared first on Mozilla Add-ons Blog.
https://blog.mozilla.org/addons/2020/09/14/extensions-in-firefox-81/
Mozilla applauds the Telecom Regulatory Authority of India (TRAI) for its decision to maintain the existing regulatory framework for OTT services in India. The regulation of OTT services sparked the fight for net neutrality in India in 2015, leading to over a million Indians asking TRAI to #SaveTheInternet and over time becoming one of the most successful grassroots campaigns in the history of digital activism. Mozilla’s CEO, Mitchell Baker, wrote an open letter to Prime Minister Modi at the time stating: “We stand firm in the belief that all users should be able to experience the full diversity of the Web. For this to be possible, Internet Service Providers must treat all content transmitted over the Internet equally, regardless of the sender or the receiver.”
Since then, as we have stated in public consultations in both 2015 and 2019, we believe that imposing a new uniform regulatory framework for OTT services, akin to how telecom operators are governed, would irredeemably harm the internet ecosystem in India. It would create legal uncertainty, chill innovation, undermine security best practices, and eventually, hurt the promise of Digital India. TRAI’s thoughtful and considered approach to the topic sets an example for regulators across the world and helps mitigate many of these concerns. It is a historical step for a country which already has among the strongest net neutrality regulations in the world. We look forward to continuing to work with TRAI to create a progressive regulatory framework for the internet ecosystem in India.
The post Mozilla applauds TRAI for maintaining the status quo on OTT regulation, upholding a key aspect of net neutrality in India appeared first on Open Policy & Advocacy.
Are you looking for opportunities to contribute to the Rust community? Have some spare time to donate? And maybe learn something interesting along the way?
The WG-prioritization can be the right place for you: we are looking for new contributors!
What is the WG-prioritization?
The Prioritization WG is a compiler Working Group dedicated to handling the most important bugs found in the Rust compiler (rustc), to ensure that they are resolved. We stand at the frontline of the Github Rust issue tracker and our job is to do triaging, mainly deciding which bugs are critical (potential release blockers) and prepare the weekly agenda for the Compiler Team with the most pressing issues to be taken care of.
Here is a bit more comprehensive description. How we work is detailed on the Rust Forge.
Our tooling is mainly the triagebot, a trustful messenger that helps us by sending notification to our Zulip stream when an issue on Github is labelled.
We also have a repository with some issues and meta-issues, where we basically note down how we would like our workflow to evolve. Contributions to these issues are welcome, but a bit more context about the workflow of this Working Group is probably necessary.
Documentation is also a fundamental part of the onboarding package that we provide to newcomers. As we basically "organize and sort stuff", a lot happens without writing a single line of code but rather applying procedures to optimize triaging and issues prioritization.
This requires our workflow to be as efficient and well documented as possible. As such, we are always open to contributions to clarify the documentation (and fresh eyeballs are especially precious for that!).
The typical week of a WG-prioritization member
Our week starts on Thursday/Friday after the Rust Compiler Team meeting (one of the cool teams that keep that beast at bay) by preparing a new agenda for the following meeting, leaving placeholders to be filled during the week.
In the following days the WG-prioritization and other teams will asynchronously monitor the issue tracker - everyone at their own pace, when time allows - trying to assign a priority to new issues. This greatly helps the compiler team to sort and prioritize their work.
If the issue priority is not immediately clear, it will be tagged with a temporary label and briefly discussed on Zulip by the WG-prioritization: is this issue critical? Is it clear? Does it need a minimal reproducible example (often abbreviated in MCVE) or even better a bisect to find a regression (we love contributors bisecting code)? We then assign the priority by choosing a value in a range from P-low to P-critical. The rationale behind the priority levels is detailed in our guide.
The day before the meeting the agenda is filled and handed to the Compiler Team.
Someone from the WG-Prioritization will attend the meeting and provide some support (if needed).
Rinse and repeat for the next meeting.
Everything is described in excruciating detail on Rust Forge. Feel free to have a look there to learn more. The quantity of information there can be a bit overwhelming at first (there is quite a bit of lingo we use), but things will become clearer.
How can I contribute?
- Help with triaging compiler issues: helping
It is again the time of year when the Rust team is calling for blog post as input to the next annual roadmap. This is my contribution.
The Foundation
I wish either the Rust Foundation itself or at least a sibling organization formed at the same time was domiciled in the EU. Within the EU, Germany looks like the appropriate member state.
Instead of simply treating the United States as the default jurisdiction for the Rust Foundation, I wish a look is taken at the relative benefits of other jurisdictions. The Document Foundation appears to be precedent of Germany recognizing Free Software development as having a public benefit purpose.
Even if the main Foundation ends up in the United States, I still think a sibling organization in the EU would be worthwhile. A substantial part of the Rust community is in Europe and in Germany specifically. Things can get problematic when the person doing the work resides in Europe but entity with the money is in the United States. It would be good to have a Rust Foundation-ish entity that can act as an European Economic Area-based employer.
Also, being domiciled in the European Union has the benefit of access to EU money. Notably, Eclipse Foundation is in the process of relocating from Canada to Belgium.
Technical Stuff
My technical wishes are a re-run of 2018, 2019, and 2020. Most of the text below is actual copypaste.
Promote packed_simd to std::simd
Rust has had awesome portable (i.e. cross-ISA) SIMD since 2015—first in the form of the simd crate and now in the form of the packed_simd crate. Yet, it’s still a nightly-only feature.
As a developer working on a product that treats x86_64, aarch64, ARMv7+NEON, and x86 as tier-1, I wish packed_simd gets promoted to std::simd (on stable) in 2021. There now appears to be forward motion on this.
At this point, people tend to say: “SIMD is already stable.” No, not portable SIMD. What got promoted was vendor intrinsics for x86 and x86_64. This is the same non-portable feature that is available in C. Especially with Apple Silicon coming up, it’s bad if the most performant Rust code is built for x86_64 while aarch64 is left as a mere TODO item (not to mention less popular architectures). The longer Rust has vendor intrinsics on stable without portable SIMD on stable, the more the crate ecosystem becomes dependent on x86_64 intrinsics and the harder it becomes to restructure the crates to use portable SIMD where portable SIMD works and to confine vendor intrinsics only to specific operations.
Non-Nightly Benchmarking
The library support for the cargo bench feature has been in the state “basically, the design is problematic, but we haven’t had anyone work through those issues yet” since 2015. It’s a useful feature nonetheless. Like I said a year ago, the year before, and the year before that, it’s time to let go of the possibility of tweaking it for elegance and just let users use it on non-nighly Rust.
Better Integer Range Analysis for Bound Check Elision
As a developer writing performance-sensitive inner loops, I wish rustc/LLVM did better integer range analysis for bound check elision. See my Rust 2019 post.
likely() and unlikely() for Plain if Branch Prediction Hints
Also, as a developer writing performance-sensitive inner loops, I wish likely() and unlikely() were available on stable Rust. Like benchmarking, likely() and unlikely() are a simple feature that works but has stalled due to concerns about lack of perfection. Let’s have it for plain if and address match and if let once there actually is a workable design for those.
No LTS
Rust has successfully delivered on “stability without stagnation” to the point that Red Hat delivers Rust updates for RHEL on a 3-month frequency instead of Rust getting stuck for the duration of the lifecycle of a
After almost a year’s worth of deliberation, the Kris Gopalakrishnan Committee released its draft report on non-personal data regulation in India in July 2020. The report is one of the first comprehensive articulations of how non-personal data should be regulated by any country and breaks new ground in interesting ways. While seemingly well intentioned, many of the report’s recommendations leave much to be desired in both clarity and feasibility of implementation. In Mozilla’s response to the public consultation, we have argued for a consultative and rights respecting approach to non-personal data regulation that benefits communities, individuals and businesses alike while upholding their privacy and autonomy.
We welcome the consultation, and believe the concept of non-personal data will benefit from a robust public discussion. Such a process is essential to creating a rights-respecting law compatible with the Indian Constitution and its fundamental rights of equality, liberty and privacy.
The key issues outlined in our submission are:
- Mitigating risks to privacy: Non-personal data can also often constitute protected trade secrets, and its sharing with third parties can raise significant privacy concerns. As we’ve stated before, information about sales location data from e-commerce platforms, for example, can be used to draw dangerous inferences and patterns regarding caste, religion, and sexuality.
- Clarifying community data: Likewise, the paper proposes the nebulous concept of community data while failing to adequately provide for community rights. Replacing the fundamental right to privacy with a notion of ownership akin to property, vested in the individual but easily divested by state and non-state actors, leaves individual autonomy in a precarious position.
- Privacy is not a zero-sum construct: More broadly, the paper focuses on how to extract data for the national interest, while continuing to ignore the urgent need to protect Indians’ privacy. Instead of contemplating how to force the transfer of non-personal data for the benefit of local companies, the Indian Government should leverage India’s place in the global economy by setting forth an interoperable and rights respecting vision of data governance.
- Passing a comprehensive data protection law: The Indian government should prioritize the passage of a strong data protection law, accompanied by reform of government surveillance. Only after the implementation of such a law that makes the fundamental right of privacy a reality for all Indians to all should we begin to look into non-personal data.
The goal of data-driven innovation oriented towards societal benefit is a valuable one. However, any community-oriented data models must be predicated on a legal framework that secures the individual’s rights to their data, as affirmed by the Indian Constitution. As we’ve argued extensively to MeitY and the Justice Srikrishna Committee, such a law has the opportunity to build on the globally standard of data protection set by Europe, and position India as a leader in internet regulation.
We look forward to engaging with the Indian government as it deliberates how to regulate non-personal data over the coming years.
Our full submission can be found here.
The post India’s ambitious non personal data report should put privacy first, for both individuals and communities appeared first on Open Policy & Advocacy.
TenFourFox Feature Parity Release 27 beta 1 is now available (downloads, hashes, release notes).
The big user-facing update for FPR27 is a first pass at "sticky" Reader View. I've been paying attention more to improving TenFourFox's implementation of Reader View because, especially for low-end Power Macs (and there's an argument to be made that all Power Macs are, by modern standards, low end), rendering articles in Reader View strips out extraneous elements, trackers, ads, social media, comments, etc., making them substantially lighter and faster than "full fat." Also, because the layout is simplified, this means less chance for exposing or choking on layout or JavaScript features TenFourFox currently doesn't support. However, in regular Firefox and FPR26, you have to go to a page and wait for some portion of it to render before you enter Reader View, which is inconvenient, and worse still if you click any link in a Reader-rendered article you exit Reader View and have to manually repeat the process. This can waste a non-trivial amount of processing time.
So when I say Reader View is now "sticky," that means links you click in an article in reader mode are also rendered in reader mode, and so on, until you explicitly exit it (then things go back to default). This loads pages much faster, in some cases nearly instantaneously. In addition, to make it easier to enter reader mode in fewer steps (and on slower systems, less time waiting for the reader icon in the address bar to be clickable), you can now right click on links and automatically pop the link into Reader View in a new tab ("Open Link in New Tab, Enter Reader View").
As always this is configurable, though "sticky" mode will be the default unless a serious bug is identified: if you set tenfourfox.reader.sticky to false, the old behaviour is restored. Also, since you may be interacting differently with new tabs you open in Reader View, it uses a separate option than Preferences' "When I open a link in a new tab, switch to it immediately." Immediately switching to the newly opened Reader View tab is the default, but you can make such tabs always open in the background by setting tenfourfox.reader.sticky.tabs.loadInBackground to false also.
Do keep in mind that not every page is suitable for Reader View, even though allowing you to try to render almost any page (except for a few domains on an internal blacklist) has been the default for several versions. The good news is it won't take very long to find out, and TenFourFox's internal version of Readability is current with mainline Firefox's, so many more pages render usefully. I intend to continue further work with this because I think it really is the best way to get around our machines' unfortunate limitations and once you get spoiled by the speed it's hard to read blogs and news sites any other way. (I use it heavily on my Pixel 3 running Firefox for Android, too.)
Additionally, this version completes the under-the-hood changes to get updates from Firefox 78ESR now that 68ESR is discontinued, including new certificate and EV roots as well as security patches. Part of the security updates involved pulling a couple of our internal libraries up to current versions, yielding both better security and performance improvements, and I will probably do a couple more as part of FPR28. Accordingly, you can now select Firefox 78ESR as a user-agent string from the TenFourFox preference pane if needed as well (though the usual advice to choose as old a user-agent string as you can get away with still applies). OlgaTPark also discovered what we were missing to fix enhanced tracking protection, so if you use that feature, it should stop spuriously blocking various innocent images and stylesheets.
What is not in this release is a fix for issue 621 where logging into LinkedIn crashes due to a JavaScript bug. I don't have a proper understanding of this crash, and a couple speculative ideas didn't pan out, but it is not PowerPC-specific or associated with the JavaScript JIT compiler as it occurs in Intel builds as well. (If any Mozillian JS deities have a good guess why an object might get created with the wrong number of slots, feel free to commment here or on Github.) Since it won't work anyway I may decide to temporarily blacklist LinkedIn to avoid drive-by crashes if I can't sort this out before final release, which will be on or around September 21.
Summary
2020h1 was rough. Layoffs, re-org, Berlin All Hands, Covid-19, focused on MLS for a while, then I switched back to Socorro/Tecken full time, then virtual All Hands.
It's September now and 2020h1 ended a long time ago, but I'm only just getting a chance to catch up and some things happened in 2020h1 that are important to divulge and we don't tell anyone about Socorro events via any other medium.
Prepare to dive in!
Read more… (15 min remaining to read)
https://bluesock.org/~willkg/blog/mozilla/socorro_2020_h1.html