Mozilla Firefox

These are notes on my recent attempts to get Android builds of Firefox working under WSL 1. After tinkering with this I ultimately decided to do my Android builds in a full blown VM running Linux, but figure these notes may serve useful to myself or ... [More] others. This was done on Windows 10 using a Debian 9 WSL machine. The steps below assume an already cloned copy of mozilla-unified or mozilla-central. Create a .mozconfig ensuring that LF line endings are used, CRLF seems to break parsing of the config under WSL: # Build GeckoView/Firefox for Android: ac_add_options --enable-application=mobile/android # Targeting the following architecture. # For regular phones, no --target is needed. # For x86 emulators (and x86 devices, which are uncommon): ac_add_options --target=i686 # For newer phones. # ac_add_options --target=aarch64 # Write build artifacts to: mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../mozilla-builds/objdir-droid-i686-opt Bootstrap via ./mach bootstrap. After the bootstrap I found I still needed to install yasm in my package manager. Now you should be ready to build with ./mach build. However, note that the object directory being built into needs to live on the WSL drive, i.e. mk_add_options MOZ_OBJDIR= should point to somewhere like ~/objdir and not /mnt/c/objdir. This is because the build system will expect to files to be handled in a case sensitive manner and will create files like String.h and string.h in the same directory. Windows doesn't do this outside of WSL by default, and it causes issues with the build. I've got a larger discussion on the nuts and bolts of this, as well as a hacky work around below if you're interested in the details. At this stage you should have an Android build. It can be packaged via ./mach package and then moved to the Windows mount – or if you have an Android emulator running under windows you can simply use ./mach install – this required required me to ~.mozbuild/android-sdk-linux/platform-tools/adb kill-server then ~.mozbuild/android-sdk-linux/platform-tools/adb start-serverafter enabling debugging on my emulated phone to get my WSLadb` to connect. For other commands, your mileage may vary. For example ./mach crashtest fails, seemingly due to being unable to call su as expected under WSL. Case sensitivity of files under Windows When attempting to build Firefox for Android into an objdir on my Windows C drive I ended up getting a number of errors for due to files including String.h. This was a little confusing, as I recognize string.h, but the upper case S version not so much. The cause is that the build system contains a list of headers and that there are several cases of headers with the same name only differing by uppercase initial letter, including the above string ones. In fact, there are 3 cases in that file: String.h, Strings.h, and Memory.h, and in my builds they can be safely removed to allow the build to progress. I initially though this happened because the NTFS file system doesn't support case sensitive file names, whilst whatever file system was being used by WSL did. However, the reality is that NTFS does support case sensitivity and Windows itself is the one imposing case insensitivity. Indeed, Windows is now exposing functionality to set case sensitivity on directories. Under WSL all directories are created with by default as case sensitive, but fsutil can be used to set the flag on directories outside WSL. In fact, using fsutil to flag dirs as case sensitive allows for working around the issue with building to a objdir outside of WSL. For example I was able to do this fsutil.exe file setCaseSensitiveInfo ./dist/system_wrappers in the root of my objdir and then perform my build from WSL to outside WSL without issue. This isn't particularly ergonomic for normal use though, because Firefox's build system will destroy and recreate that dir which drops the flag. So I'd either need to manually restore it each time, or modify the build system. The case sensitivity handling of files on Windows is interesting in a software archeology sense, and I plan to write more on it, but want to avoid this post (further) going off on a tangent around Windows architecture. [Less]

Without much fanfare or fireworks we put together and shipped a fresh new version of tiny-curl. We call it version 0.10 and it is based on the 7.65.3 curl tree. tiny-curl is a patch set to build curl as tiny as possible while still being able to ... [More] perform HTTPS GET requests and maintaining the libcurl API. Additionally, tiny-curl is ported to FreeRTOS. Changes in 0.10 The largest and primary change is that this version is based on curl 7.65.3, which brings more features and in particular more bug fixes compared to tiny-curl 0.9. Parts of the patches used for tiny-curl 0.9 was subsequently upstreamed and merged into curl proper, making the tiny-curl 0.10 patch much smaller. Download As before, tiny-curl is an effort that is on a separate track from the main curl. Download tiny-curl from wolfssl.com! [Less]

Summary Socorro Engineering team covers several projects: Socorro is the crash ingestion pipeline and Crash Stats web service for Mozilla's products like Firefox. Tecken is the symbols server for uploading, downloading, and symbolicating stacks. ... [More] Buildhub2 is the build information index. Buildhub is the previous iteration of Buildhub2 that's currently deprecated and will get decommissioned soon. PollBot and Delivery Dashboard are something something. This blog post summarizes our activities in July. Highlights of July Socorro: Added modules_in_stack field to super search allowing people to search the set of module/debugid for functions that are in teh stack of the crashing thread. This lets us reprocess crash reports that have modules for which symbols were just uploaded. Socorro: Added PHC related fields, dom_fission_enabled, and bug_1541161 to super search. Socorro: Fixed some things further streamlining the local dev environment. Socorro: Reformatted Python code with Black. Socorro: Extracted supersearch and fetch-data commands as a separate Python library: https://github.com/willkg/crashstats-tools Tecken: Upgraded to Python 3.7 and adjusted storage bucket code to work better for multiple storage providers. Tecken: Added GCS emulator for local development environment. PollBot: Updated to use Buildhub2. Hiatus and project changes In April, we picked up Tecken, Buildhub, Buildhub2, and PollBot in addition to working on Socorro. Since then, we've: audited Tecken, Buildhub, Buildhub2, and PollBot updated all projects, updated dependencies, and performed other necessary maintenance documented deploy procedures and basic runbooks deprecated Buildhub in favor of Buildhub2 and updated projects to use Buildhub2 Buildhub is decomissioned now and is being dismantled. We're passing Buildhub2 and PollBot off to another team. They'll take ownership of those projects going forward. Socorro and Tecken are switching to maintenance mode as of last week. All Socorro/Tecken related projects are on hold. We'll continue to maintain the two sites doing "keep the lights on" type things: granting access to memory dumps adding new products adding fields to super search making changes to signature generation and updating siggen library responding to outages fixing security issues All other non-urgent work will be pushed off. As of August 1st, we've switched to Mozilla Location Services. We'll be auditing that project, getting it back into a healthy state, and bringing it in line with current standards and practices. Given that, this is the last Socorro Engineering status post for a while. Read more… (6 min remaining to read) [Less]

Over a month ago we organized the ninth annual IndieWeb Summit in Portland, Oregon, June 29-30. As frequently happens to organizers, the combination of follow-ups, subsequent holiday, and other events did not allow for much time to blog ... [More] afterwards. On the other hand, it did allow for at least some reflection and appreciation. Somethings Sooner Rather than feeling overwhelmed by the pressure of a thorough summary post about the entire Summit, I decided it would be better to write at least about one aspect, session, or portion there of, to get started. Something is better than nothing. Something sooner (even if it wasn’t immediate) is better than a lot, later, or a lot later. Day 1 Badges, Pins, Shirts, And Breakfast! Saturday morning June 29th went relatively smoothly. We had everything setup in time. I finished preparing my “state of” outline. Everyone signed-in when they arrived, got a badge, chose their color of lanyard (more on that later), pronoun pin(s), and an array of decorative stickers to customize their badge. For the first time we had an anonymous donor who chipped in enough in addition to the minimal $10 registration fee for us to afford IndieWebCamp t-shirts in a couple of shapes and a variety of sizes. We had a warm breakfast (vegetarian and vegan) ready to go for participants. Captions, Codes of Conduct, Safety, And Photo Policy! Another first for any IndieWebCamp, we arranged a captioner who live-captioned the first two hours of Summit keynotes, introductions, and demos. After welcoming everyone and introducing co-organizers Tiara and Aaron, I showed & briefly summarized our codes of conduct for the Summit: IndieWeb Code of Conduct Mozilla Community Participation Guidelines In particular I emphasized the recent addition from XOXO 2018’s Code of Conduct regarding safety vs. comfort, which is worth its own blog post. Another Summit first, also inspired by XOXO (and other conferences like Open Source Bridge), color-coded lanyards for our photo policy. Which was a natural lead-in for the heads-up about session live-streaming and where to sit accordingly (based on personal preference). Lastly, pronoun pins and a huge thanks to Aaron Parecki for arranging the logistics of all those materials! I told people about the online tools that would help their Summit experience (chat, the wiki, Etherpad), summarized the day 1 schedule, and thanked the sponsors. Video, Outline, And Always Aspiring Here’s the 8 minute video of the Welcome. I think it went ok, especially with so many firsts for this Summit! In the future I’d like to: reduce it to no more than 5 minutes (one or two rounds of practice & edit should help), and consider what else could or should be included (while staying under 5 minutes). That being said, I feel pretty good about our continuous improvement with organizing and welcoming to IndieWebCamps. As we’ve learned from other inclusive conferences, I encourage all conference organizers to explicitly cover similar aspects (excerpted from the online outline I spoke from) Code(s) of conduct (with multiple organizers and contacts) Photo policy (with clear indicators to self-select) Pronoun pins (or stickers) Consider these a minimum baseline, a place to build from, more than goals. Ideally we should aspire to provide a safe and inclusive experience for an increasingly diverse community. Two more ways conference organizers can do so is by recognizing what the conference has done better this year, and by choosing keynote speakers to provide diverse perspectives. More on that with State of the IndieWeb, and the IndieWeb Summit 2019 invited keynote speakers. Photos 1, 2, & 4 by Aaron Parecki [Less]

Over a month ago we organized the ninth annual IndieWeb Summit in Portland, Oregon, June 29-30. As frequently happens to organizers, the combination of follow-ups, subsequent holiday, and other events did not allow for much time to blog ... [More] afterwards. On the other hand, it did allow for at least some reflection and appreciation. Somethings Sooner Rather than feeling overwhelmed by the pressure of a thorough summary post about the entire Summit, I decided it would be better to write at least about one aspect, session, or portion there of, to get started. Something is better than nothing. Something sooner (even if it wasn’t immediate) is better than a lot, later, or a lot later. Day 1 Badges, Pins, Shirts, And Breakfast! Saturday morning June 29th went relatively smoothly. We had everything setup in time. I finished preparing my “state of” outline. Everyone signed-in when they arrived, got a badge, chose their color of lanyard (more on that later), pronoun pin(s), and an array of decorative stickers to customize their badge. For the first time we had an anonymous donor who chipped in enough in addition to the minimal $10 registration fee for us to afford IndieWebCamp t-shirts in a couple of shapes and a variety of sizes. We had a warm breakfast (vegetarian and vegan) ready to go for participants. Captions, Codes of Conduct, Safety, And Photo Policy! Another first for any IndieWebCamp, we arranged a captioner who live-captioned the first two hours of Summit keynotes, introductions, and demos. After welcoming everyone and introducing co-organizers Tiara and Aaron, I showed & briefly summarized our codes of conduct for the Summit: IndieWeb Code of Conduct Mozilla Community Participation Guidelines In particular I emphasized the recent addition from XOXO 2018’s Code of Conduct regarding safety vs. comfort, which is worth its own blog post. Another Summit first, also inspired by XOXO (and other conferences like Open Source Bridge), color-coded lanyards for our photo policy. Which was a natural lead-in for the heads-up about session live-streaming and where to sit accordingly (based on personal preference). Lastly, pronoun pins and a huge thanks to Aaron Parecki for arranging the logistics of all those materials! I told people about the online tools that would help their Summit experience (chat, the wiki, Etherpad), summarized the day 1 schedule, and thanked the sponsors. Video, Outline, And Always Aspiring Here’s the 8 minute video of the Welcome. I think it went ok, especially with so many firsts for this Summit! In the future I’d like to: reduce it to no more than 5 minutes (one or two rounds of practice & edit should help), and consider what else could or should be included (while staying under 5 minutes). That being said, I feel pretty good about our continuous improvement with organizing and welcoming to IndieWebCamps. As we’ve learned from other inclusive conferences, I encourage all conference organizers to explicitly cover similar aspects (excerpted from the online outline I spoke from) Code(s) of conduct (with multiple organizers and contacts) Photo policy (with clear indicators to self-select) Pronoun pins (or stickers) Consider these a minimum baseline, a place to build from, more than goals. Ideally we should aspire to provide a safe and inclusive experience for an increasingly diverse community. Two more ways conference organizers can do so is by recognizing what the conference has done better this year, and by choosing keynote speakers to provide diverse perspectives. More on that with State of the IndieWeb, and the IndieWeb Summit 2019 invited keynote speakers. Photos 1, 2, & 4 by Aaron Parecki [Less]

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 ... [More] 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 News & Blog Posts We rewrote our IoT platform in Rust and got away with it. About the future of nphysics: a pure rust 2D and 3D real-time physics engine. Building GTK+ app in Rust for a first time. Understanding Rust through AVL trees. Writing an OS in Rust: Updates in July 2019. Rust reverses research ruin. Veloren: A multiplayer voxel RPG written in Rust. Minimum safe abstractions. How to serve static files with Rust. Rust Rocks NB-IoT! STM32 Blue Pill with Quectel BC95-G on Apache Mynewt. Crate of the Week This week's crate is broot, a program to show the gist of a directory tree. Thanks to Willi Kappler for the suggestion! Submit your suggestions and votes for next week! Call for Participation Always wanted to contribute to open-source projects but didn't know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started! Some of these tasks may also have mentors available, visit the task page for more information. Actix: Call to community and participation. Kate editor: Support Rust LSP server auto-detect some useful root path based on location of Cargo.toml. If you are a Rust project owner and are looking for contributors, please submit tasks here. Updates from Rust Core 249 pull requests were merged in the last week Avoid ICE when suggestion span is at Eof On format!() arg count mismatch provide extra info Syntax: Recover on for ( $pat in $expr ) $block dead_code: Properly inspect fields in struct patterns with type relative paths Collect file → edition mapping after AST expansion Unsupport the await!(future) macro Round generator sizes to a multiple of their alignment miri: Fix determining size of an "extra function" allocation miri: Add misssing 'roundf32' and 'roundf64' intrinsics Impl Debug for Chars const fn-ify std::any::type_name hashbrown: Replace FxHash with AHash as the default hasher hashbrown: Experimentally expose RawTable under the "raw" feature rustc: Stabilize options for pipelined compilation cargo: Enable pipelined compilation by default cargo: Improve error message for unmatched prerelease dependencies rustdoc: Use doc comments from 'pub use' statements Approved RFCs Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week: No RFCs were approved this week. Final Comment Period Every week the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now. RFCs No new RFCs were proposed this week. Tracking Issues & PRs [disposition: merge] [Stabilization] async/await MVP. [disposition: merge] Stabilize duration_float. [disposition: merge] Stabilize checked_duration_since for 1.38.0. [disposition: merge] Give built-in macros stable addresses in the standard library. [disposition: merge] Tracking issue for {HashMap, BTreeMap}::get_key_value stabilization. New RFCs Add a new unsafe trait TypeInfo to core::any, and implement it for all types. Upcoming Events Asia Pacific Aug 10. Singapore, SG - Rust Meetup. Aug 17. Taipei, TW - "Everything in Rust" at COSCUP 2019. Aug 15. Wellington, NZ - Rust Wellington - Coffee & cake. Europe Aug 21. Berlin, DE - OpenTechSchool Berlin - Rust Hack and Learn. Aug 21. Berlin, DE - Rust Berlin - Rust for Decentralised Technology. North America Aug 13. Toronto, ON, CA - Rust Toronto - Toronto Rustaceans Tech and Talk. Aug 13. Denver, CO, US - Rust Boulder/Denver - Hack 'N Snack. Aug 13. Seattle, WA, US - Seattle Rust Meetup - Monthly meetup. Aug 21. Vancouver, BC, CA - Vancouver Rust meetup. If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access. Rust Jobs Blockchain Runtime Engineer at Parity, Berlin, DE or remote. Senior Platform Engineer - Layout as Mozilla, Portland, US. Senior Software Engineer at ConsenSys R&D, Remote. Rust Developer at Finhaven, Vancouver, CA. Tweet us at @ThisWeekInRust to get your job offers listed here! Quote of the Week If you want to block threads, get your own threads. – kornel on rust-users Thanks to Tom Phinney for the suggestion! Please submit quotes and vote for next week! This Week in Rust is edited by: nasa42, llogiq, and Flavsditz. Discuss on r/rust. [Less]

This is cross-posted from a Medium article by Akshitha Shetty, a Summer of Code student I have been mentoring. It’s been a pleasure and I wish her luck in her next endeavor! For me, getting all set to read a book would mean spending hours hopping ... [More] between stores to find the right lighting and mood to get started. But with Firefox’s Reader Mode it’s now much more convenient to get reading on the go. And this summer, I have been fortunate to shift roles from a user to a developer for the Reader Mode . As I write this blog, I have completed two months as a Google Summer of Code student developer with Mozilla. It has been a really enriching experience and thus I would like to share some glimpses of the project and my journey so far. Motivation behind choosing this organization and project I began as an open-source contributor to Mozilla early this year. What really impressed me was how open and welcoming Mozillians were. Open-source contribution can be really intimidating at first. But in my case, the kind of documentation and direction that Mozilla provided helped me steer in the right direction really swiftly. Above all, it’s the underlying principle of the organization — “people first” that truly resonated with me. On going through the project idea list, the “Firefox Reader Mode Revamp” was of great interest to me. It was one of the projects where I would be directly enhancing the user-experience for Firefox users and also learning a lot more about user-experience and accessibility in the process. Redesign of the Reader mode in making The new design of the reader mode has the following features - A vertical toolbar is to replaced by a horizontal toolbar so that it is the sync with the other toolbars present in Firefox. The toolbar is now being designed so that it complies with the Photon Design System (the latest design guidelines proposed by the organization). The accessibility of the Reader Mode is being improved by making it keyboard friendly. Mock-up for Reader Mode Redesign Thanks to Abraham Wallin for designing the new UI for the Reader mode. Get Set Code Once the design was ready, I began with the coding of the UI. I thoroughly enjoyed the process and learnt a lot from the challenges I faced during this process. One of the challenges I faced during this phase was to make the toolbar adjust it’s width as per the content width of the main page. This required me to refactor certain portions of the existing code base as well make sure the newly coded toolbar follows the same. To Sum it all up All in all, it has been a really exciting process. I would like to thank my mentor — Eitan Isaacson for putting in the time and effort to mentor this project. Also I would like to thank — Gijs Kruitbosch and Yura Zenevich for reviewing my code at various points of time. I hope this gets you excited to see the Reader Mode in its all new look ! Stay tuned for my next blog where I will be revealing the Revamped Reader Mode into action. [Less]

In the afternoon of August 5 2019, I successfully made curl request a document over HTTP/3, retrieve it and then exit cleanly again. (It got a 404 response code, two HTTP headers and 10 bytes of content so the actual response was certainly ... [More] less thrilling to me than the fact that it actually delivered that response over HTTP version 3 over QUIC.) The components necessary for this to work, if you want to play along at home, are reasonably up-to-date git clones of curl itself and the HTTP/3 library called quiche (and of course quiche’s dependencies too, like boringssl), then apply pull-request 4193 (build everything accordingly) and run a command line like: curl --http3-direct https://quic.tech:8443 The host name used here (“quic.tech”) is a server run by friends at Cloudflare and it is there for testing and interop purposes and at the time of this test it ran QUIC draft-22 and HTTP/3. The command line option --http3-direct tells curl to attempt HTTP/3 immediately, which includes using QUIC instead of TCP to the host name and port number – by default you should of course expect a HTTPS:// URL to use TCP + TLS. The official way to bootstrap into HTTP/3 from HTTP/1 or HTTP/2 is via the server announcing it’s ability to speak HTTP/3 by returning an Alt-Svc: header saying so. curl supports this method as well, it just needs it to be explicitly enabled at build-time since that also is still an experimental feature. To use alt-svc instead, you do it like this: curl --alt-svc altcache https://quic.tech:8443 The alt-svc method won’t “take” on the first shot though since it needs to first connect over HTTP/2 (or HTTP/1) to get the alt-svc header and store that information in the “altcache” file, but if you then invoke it again and use the same alt-svc cache curl will know to use HTTP/3 then! Early days Be aware that I just made this tiny GET request work. The code is not cleaned up, there are gaps in functionality, we’re missing error checks, we don’t have tests and chances are the internals will change quite a lot going forward as we polish this. You’re of course still more than welcome to join in, play with it, report bugs or submit pull requests! If you help out, we can make curl’s HTTP/3 support better and getting there sooner than otherwise. QUIC and TLS backends curl currently supports two different QUIC/HTTP3 backends, ngtcp2 and quiche. Only the latter currently works this good though. I hope we can get up to speed with the ngtcp2 one too soon. quiche uses and requires boringssl to be used while ngtcp2 is TLS library independent and will allow us to support QUIC and HTTP/3 with more TLS libraries going forward. Unfortunately it also makes it more complicated to use… The official OpenSSL doesn’t offer APIs for QUIC. QUIC uses TLS 1.3 but in a way it was never used before when done over TCP so basically all TLS libraries have had to add APIs and do some adjustments to work for QUIC. The ngtcp2 team offers a patched version of OpenSSL that offers such an API so that OpenSSL be used. Draft what? Neither the QUIC nor the HTTP/3 protocols are entirely done and ready yet. We’re using the protocols as they are defined in the 22nd version of the protocol documents. They will probably change a little more before they get carved in stone and become the final RFC that they are on their way to. The libcurl API so far The command line options mentioned above of course have their corresponding options for libcurl using apps as well. Set the right bit with CURLOPT_H3 to get direct connect with QUIC and control how to do alt-svc using libcurl with CURLOPT_ALTSVC and CURLOPT_ALTSVC_CTRL. All of these marked EXPERIMENTAL still, so they might still change somewhat before they become stabilized. [Less]

In the afternoon of August 5 2019, I successfully made curl request a document over HTTP/3, retrieve it and then exit cleanly again. (It got a 404 response code, two HTTP headers and 10 bytes of content so the actual response was certainly ... [More] less thrilling to me than the fact that it actually delivered that response over HTTP version 3 over QUIC.) The components necessary for this to work, if you want to play along at home, are reasonably up-to-date git clones of curl itself and the HTTP/3 library called quiche (and of course quiche’s dependencies too, like boringssl), then apply pull-request 4193 (build everything accordingly) and run a command line like: curl --http3-direct https://quic.tech:8443 The host name used here (“quic.tech”) is a server run by friends at Cloudflare and it is there for testing and interop purposes and at the time of this test it ran QUIC draft-22 and HTTP/3. The command line option --http3-direct tells curl to attempt HTTP/3 immediately, which includes using QUIC instead of TCP to the host name and port number – by default you should of course expect a HTTPS:// URL to use TCP + TLS. The official way to bootstrap into HTTP/3 from HTTP/1 or HTTP/2 is via the server announcing it’s ability to speak HTTP/3 by returning an Alt-Svc: header saying so. curl supports this method as well, it just needs it to be explicitly enabled at build-time since that also is still an experimental feature. To use alt-svc instead, you do it like this: curl --alt-svc altcache https://quic.tech:8443 The alt-svc method won’t “take” on the first shot though since it needs to first connect over HTTP/2 (or HTTP/1) to get the alt-svc header and store that information in the “altcache” file, but if you then invoke it again and use the same alt-svc cache curl will know to use HTTP/3 then! Early days Be aware that I just made this tiny GET request work. The code is not cleaned up, there are gaps in functionality, we’re missing error checks, we don’t have tests and chances are the internals will change quite a lot going forward as we polish this. You’re of course still more than welcome to join in, play with it, report bugs or submit pull requests! If you help out, we can make curl’s HTTP/3 support better and getting there sooner than otherwise. QUIC and TLS backends curl currently supports two different QUIC/HTTP3 backends, ngtcp2 and quiche. Only the latter currently works this good though. I hope we can get up to speed with the ngtcp2 one too soon. quiche uses and requires boringssl to be used while ngtcp2 is TLS library independent and will allow us to support QUIC and HTTP/3 with more TLS libraries going forward. Unfortunately it also makes it more complicated to use… The official OpenSSL doesn’t offer APIs for QUIC. QUIC uses TLS 1.3 but in a way it was never used before when done over TCP so basically all TLS libraries have had to add APIs and do some adjustments to work for QUIC. The ngtcp2 team offers a patched version of OpenSSL that offers such an API so that OpenSSL be used. Draft what? Neither the QUIC nor the HTTP/3 protocols are entirely done and ready yet. We’re using the protocols as they are defined in the 22nd version of the protocol documents. They will probably change a little more before they get carved in stone and become the final RFC that they are on their way to. The libcurl API so far The command line options mentioned above of course have their corresponding options for libcurl using apps as well. Set the right bit with CURLOPT_H3 to get direct connect with QUIC and control how to do alt-svc using libcurl with CURLOPT_ALTSVC and CURLOPT_ALTSVC_CTRL. All of these marked EXPERIMENTAL still, so they might still change somewhat before they become stabilized. Update Starting on August 8, the option is just --http3 and you ask libcurl to use HTTP/3 directly with CURLOPT_HTTP_VERSION. [Less]

Firefox for Android (Fennec) now supports the Web Authentication API as of version 68. WebAuthn blends public-key cryptography into web application logins, and is our best technical response to credential phishing. Applications leveraging WebAuthn ... [More] gain new  second factor and “passwordless” biometric authentication capabilities. Now, Firefox for Android matches our support for Passwordless Logins using Windows Hello. As a result, even while mobile you can still obtain the highest level of anti-phishing account security. https://blog.mozilla.org/security/files/2019/07/webauthn-android-fennec-1.mp4 Firefox for Android uses your device’s native capabilities: On certain devices, you can use built-in biometrics scanners for authentication. You can also use security keys that support Bluetooth, NFC, or can be plugged into the phone’s USB port. The attached video shows the usage of Web Authentication with a built-in fingerprint scanner: The demo website enrolls a new security key in the account using the fingerprint, and then subsequently logs in using that fingerprint (and without requiring a password). Adoption of Web Authentication by major websites is underway: Google, Microsoft, and Dropbox all support WebAuthn via their respective Account Security Settings’ “2-Step Verification” menu. A few notes For Microsoft Accounts, you’ll need to be running the latest release of Windows 10. Look under the heading “Windows Hello and security keys”. For Google Accounts, due to Google limitations you must enroll your security keys via a desktop browser, and then you can use them with Firefox for Android. Look for the heading “Security keys” and choose a USB or NFC key. Additionally you can try Web Authentication out at a variety of demo sites: https://webauthn.org/, https://webauthn.io/, https://webauthn.me/, https://webauthndemo.appspot.com/, or learn more about it on MDN. For technical reasons, Firefox for Android does not support the older, backwards-compatible FIDO U2F Javascript API, which we enabled on Desktop earlier in 2019. For details as to why, see bug 1550625. Currently Firefox Preview for Android does not support Web Authentication. As Preview matures, Web Authentication will be joining its feature set.   The post Web Authentication in Firefox for Android appeared first on Mozilla Security Blog. [Less]