http://www.ncameron.org/blog/rustfmt-1-rc/

I’m excited to announce that Amy Keating will be joining us in September as Mozilla’s new General Counsel.

Amy will work closely with me to help scale and reinforce our legal capabilities. She will be responsible for all aspects of Mozilla’s legal work including product counseling, commercial contracts, licensing, privacy issues and legal support to the Mozilla Foundation.

“Mozilla’s commitment to innovation and an internet that is open and accessible to all speaks to me at a personal level, and I’ve been drawn to serving this kind of mission throughout my career,” said Amy Keating, Mozilla incoming General Counsel. “I’m grateful for the opportunity to learn from Mozilla’s incredible employees and community and to help promote the principles that make Mozilla a trusted and unique voice in the world.”

Amy joins Mozilla from Twitter, Inc. where she has been Vice President, Legal and Deputy General Counsel. When she joined Twitter in 2012, she was the first lawyer focused on litigation, building out the functions and supporting the company as both the platform and the employee base grew in the U.S. and internationally. Her role expanded over time to include oversight of Twitter’s product counseling, regulatory, privacy, employment legal, global litigation, and law enforcement legal response functions. Prior to Twitter, Amy was part of Google, Inc.’s legal team and began her legal career as an associate at Bingham McCutchen LLP.

From her time at Twitter and prior, Amy brings a wealth of experience and a deep understanding of the product, litigation, regulatory, international, intellectual property and employment legal areas.

Join me in welcoming Amy to Mozilla!

Denelle

The post Welcome Amy Keating, our incoming General Counsel appeared first on The Mozilla Blog.

https://blog.mozilla.org/blog/2018/08/14/welcome-amy-keating-our-incoming-general-counsel/

Please meet Oriol Brufau, our newest Friend of Add-ons! Oriol is one of 23 volunteer community members who have landed code for the WebExtensions API in Firefox since the technology was first introduced in 2015. You may be familiar with his numerous contributions  if you have set a specific badge text color for your browserAction, highlighted multiple tabs with the tabs.query API, or have seen your extension’s icon display correctly in about:addons.

While our small engineering team doesn’t always have the resources to implement every approved request for new or enhanced WebExtensions APIs, the involvement of community members like Oriol adds considerable depth and breadth to technology that affects millions of users. However, the Firefox code base is large, complex, and full of dependencies. Contributing code to the browser can be difficult even for experienced developers.

As part of celebrating Oriol’s achievements, we asked him to share his experience contributing to the WebExtensions API with the hope that it will be helpful for other developers interested in landing more APIs in Firefox.

When did you first start contributing code to Firefox? When did you start contributing code to WebExtensions APIs?

I had been using Firefox Nightly, reporting bugs and messing with code for some time, but my first code contribution wasn’t until February 2016. This was maybe not the best choice for my first bug. I managed to fix it, though I didn’t have much idea about what the code was doing, and my patch needed some modifications by Jonathan Kew.

For people who want to start contributing, it’s probably a better idea to search Bugzilla for a bug with the ‘good-first-bug’ keyword. (Editor’s note: you can find mentored good-first-bugs for WebExtensions APIs here.)

I started contributing to the WebExtensions API in November 2017, when I learned that legacy extensions would stop working even if I had set the preference to enable legacy extensions in Nightly. Due to the absence of good compatible alternatives to some of my legacy add-ons, I tried to write them myself, but I couldn’t really do what I wanted because some APIs were buggy or lacked various features. Therefore, I started making proposals for new or enhanced APIs, implementing them, and fixing bugs.

What were some of the challenges to building and landing code for the WebExtensions API?

I wasn’t very familiar with WebExtensions APIs, so understanding their implementation was a bit difficult at first. Also, debugging the code can be tricky. Some code runs in the parent process and some in the content one, and the debugger can make Firefox crash.

Initially, I used to forget about testing for Android. Sometimes I had a patch that seemed to work perfectly for Linux, but it couldn’t land because it broke some Android tests. In fact, not being able to run Android tests locally in my PC is a big annoyance.

What resources did you use to overcome those challenges?

I use https://searchfox.org, a source code indexing tool for Firefox, which makes it easy to find the code that I want to modify, and I received some help from mentors in Bugzilla.

Reading the documentation helps but it’s not very detailed. I usually need to look at the Firefox or Chromium code in order to answer my questions.

Did any of your past experiences contributing code to Firefox help you create and land the WebExtensions APIs?

Yes. Despite being unfamiliar with WebExtensions APIs at first, I had a considerable experience with searching code using Searchfox, using ‘./mach build fast’ to recompile only the frontend, running tests, managing my patches with Mercurial, and getting them reviewed and landed.

Also, I already had commit access level 1, which allows me to run

Читать далее...

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

Welcome!

After a quick pause in July, your primary source of localization information at Mozilla is back!

New content and projects

What’s new or coming up in Firefox desktop

As localization drivers, we’re currently working on rethinking and improving the experience of multilingual users in Firefox. While this is a project that will span through several releases of Firefox, the first part of this work already landed in Nightly (Firefox 63): it’s a language switcher in Preferences, hidden behind the intl.multilingual.enabled preference, that currently allows to switch to another language already installed on the system (via language packs).

The next step will be to allow installing a language pack directly from Preferences (for the release version), and install dictionaries when user chooses to add a new language. For that reason, we’re creating a list of dictionaries for each locale. For more details, and discover how you can help, read this thread on dev-l10n.

We’re also working on building a list of native language names to use in the language switcher; once again, check dev-l10n for more info.

Quite a few strings landed in the past weeks for Nightly:

• Pages for certificate errors have a new look. To test them, you currently need to change the setting browser.security.newcerterrorpage.enabled to true in about:config. The testing instructions available in our documentation remain valid.
• There’s a whole new section dedicated to Content blocking in preferences, enabled by default in Nightly.

What’s new or coming up in mobile

It’s summer time in the western hemisphere, which means many projects (and people!) are taking a break – which also means not many strings are expected to land in mobile land during this period.

One notable thing is that Firefox iOS v13 was just released, and Marathi is a new locale this time around. Congratulations to the team.

On Firefox for Android front, Bosnian (bs), Occitan (oc) and Triqui (trs) are new locales that shipped with on current release version, v61. And we just added English from Canada (en-CA) and Ligurian (lij) to our Nightly v63 multi-locale build, which is available through the Google Play Store. Congratulations to everyone!

Other than that, most mobile projects are on a bit of a hiatus for the rest of the month. However, do expect some new and exciting projects to come in the pipeline over the course of the next few weeks. Stay tuned for more information!

What’s new or coming up in web projects

AMO

About two weeks ago, over 160 sets of curated add-on titles and descriptions were landed in Pontoon. Once localized, they will be included in a Shield Study to be launched on August 13. The study will run for about 2 months. This is probably the largest and longest study the AMO team has conducted.

The current Disco Pane (about:addons) lists curated extensions and themes which are manually programmed. TAAR (Telemetry Aware Add-on Recommender) is a new machine-learning extension discovery system that makes personalized recommendations based on information available in Firefox standard Telemetry. Based on TAAR’s potential to enhance content discovery by surfacing more diversified and personalized recommendations, the team wants to integrate TAAR as a product feature of Disco Pane.  It’s called “Disco-TAAR”.

The localized titles and description will increase users’ likelihood to install and install more than one. To be part of this study, you need to make sure your locale has completed at least 80% of the AMO strings by August 12.

Common Voice

Like many of you, the team is taking a summer break. However, when they

Читать далее...

For the first time in my life I tracked a real bug's root cause to incorrect usage of weak memory orderings. Until now weak memory bugs were something I knew about but had subconciously felt were only relevant to wizards coding on big iron, partly because until recently I've spent most of my career using desktop x86 machines.

Under heavy load a Pernosco service would assert in Rust's std::thread::Thread::unpark() with the error "inconsistent state in unpark". Inspecting the code led to the disturbing conclusion that the only way to trigger this assertion was memory corruption; the value of self.inner.state should always be between 0 and 2 inclusive, and if so then we shouldn't be able to reach the panic. The problem was nondeterministic but I was able to extract a test workload that reproduced the bug every few minutes. I tried recording it in rr chaos mode but was unable to reproduce it there (which is not surprising in hindsight since rr imposes sequential consistency).

With a custom panic handler I was able to suspend the process in the panic handler and attach gdb to inspect the state. Everything looked fine; in particular the value of self.inner.state was PARKED so we should not have reached the panic. I disassembled unpark() and decided I'd like to see the values of registers in unpark() to try to determine why we took the panic path, in particular the value of self.inner (a pointer) loaded into RCX and the value of self.inner.state loaded into RAX. Calling into the panic handler wiped those registers, so I manually edited the binary to replace the first instruction of the panic handler with UD2 to trigger an immediate core-dump before registers were modified.

The core-dump showed that RCX pointed to some random memory and was not equal to self.inner, even though we had clearly just loaded it from there! The value of state in RAX was loaded correctly via RCX, but was garbage because we were loading from the wrong address. At this point I formed the theory the issue was a low-level data race, possibly involving relaxed memory orderings — particularly because the call to unpark() came from the Crossbeam implementation of Michael-Scott lock-free queues. I inspected the code and didn't see an obvious memory ordering bug, but I also looked at the commit log for Crossbeam and found that a couple of memory ordering bugs had been fixed a long time ago; we were stuck on version 0.2 while the released version is 0.4. Upgrading Crossbeam indeed fixed our bug.

Observation #1: stick to sequential consistency unless you really need the performance edge of weaker orderings.

Observation #2: stick to sequential consistency unless you are really, really smart and have really really smart people checking your work.

Observation #3: it would be really great to have user-friendly tools to verify the correctness of unsafe, weak-memory-dependent code like Crossbeam's.

Observation #4: we need a better way of detecting when dependent crates have known subtle correctness bugs like this (security bugs too). It would be cool if the crates.io registry knew about deprecated crate versions and cargo build warned about them.

http://robert.ocallahan.org/2018/08/for-first-time-in-my-life-i-tracked.html

As of today, TLS certificates issued by Symantec are distrusted in Firefox Nightly.

You can learn more about what this change means for websites and our release schedule for that change in our Update on the Distrust of Symantec TLS Certificates post published last July by the Mozilla security team.

The Symantec distrust is already effective in Chrome Canary which means that visitors to a web site with a Symantec certificate which was not replaced now get a warning page:

(left is Chrome Canary, right is Firefox Nightly)

We strongly encourage website operators to replace their distrusted Symantec certificate as soon as possible before this change hits the Firefox 63 release planned for October 23.

If you are a Firefox Nightly user, you can also get involved and help this transition by contacting the support channels of these websites to warn them about this change!

https://blog.nightly.mozilla.org/2018/08/14/symantec-distrust-in-firefox-nightly-63/

While I’m not a lawyer – and I’m definitely not your lawyer – licensing questions are on my plate these days. As I’ve been digging into one, I’ve come across what looks like a strange edge case in GPL licensing compliance that I’ve been trying to understand. Unfortunately it looks like it’s one of those Affero-style, unforeseen edge cases that (as far as I can find…) nobody’s tested legally yet.

I spent some time trying to understand how the definition of “linking” applies in projects where, say, different parts of the codebase use disparate, potentially conflicting open source licenses, but all the code is interpreted. I’m relatively new to this area, but generally speaking outside of copying and pasting, “linking” appears to be the critical threshold for whether or not the obligations imposed by the GPL kick in and I don’t understand what that means for, say, Javascript or Python.

I suppose I shouldn’t be surprised by this, but it’s strange to me how completely the GPL seems to be anchored in early Unix architectural conventions. Per the GPL FAQ, unless we’re talking about libraries “designed for the interpreter”, interpreted code is basically data. Using libraries counts as linking, but in the eyes of the GPL any amount of interpreted code is just a big, complicated config file that tells the interpreter how to run.

At a glance this seems reasonable but it seems like a pretty strange position for the FSF to take, particularly given how much code in the world is interpreted, at some level, by something. And honestly: what’s an interpreter?

The text of the license and the interpretation proposed in the FAQ both suggest that as long as all the information that a program relies on to run is contained in the input stream of an interpreter, the GPL – and if their argument sticks, other open source licenses – simply… doesn’t apply. And I can’t find any other major free or open-source licenses that address this question at all.

It just seems like such a weird place for an oversight. And given the often-adversarial nature of these discussions, given the stakes, there’s no way I’m the only person who’s ever noticed this. You have to suspect that somewhere in the world some jackass with a very expensive briefcase has an untested legal brief warmed up and ready to go arguing that a CPU’s microcode is an “interpreter” and therefore the GPL is functionally meaningless.

Whatever your preferred license of choice, that really doesn’t seem like a place we want to end up; while this interpretation may be technically correct it’s also very-obviously a bad-faith interpretation of both the intent of the GPL and that of the authors in choosing it.

The position I’ve taken at work is that “are we technically allowed to do this” is a much, much less important question than “are we acting, and seen to be acting, as good citizens of the larger Open Source community”. So while the strict legalities might be blurry, seeing the right thing to do is simple: we treat the integration of interpreted code and codebases the same way we’d treat C/C++ linking, respecting the author’s intent and the spirit of the license.

Still, it seems like something the next generation of free and open-source software licenses should explicitly address.

http://exple.tive.org/blarg/2018/08/13/licensing-edgecases/

When I started the blog, I didn’t add a message board below each article because I don’t have the time to deal with spam. Due to broken windows theory, if I leave the spam unattended my blog will soon become a landfill for spammers. But nowadays many e-commerce site or brand sites have a live chatting box, which will solve my problem because I can simply ignore spam, while interested readers can ask questions and provide feedbacks easily. That’s why when my sponsor, Chatra.io, approached me with their great tool, I fell in love with it right away and must share it with everyone.

How it works

First, signup for a free account here, and you’ll be logged into a clean and modern chat interface.

[показать]

You’ll get a JavaScript widget snippet (in the “Set up & customize” page or email), which you can easily place onto your site (even if you don’t have a backend, like this site). A chat button will immediately appear on your site. Your visitor can now send you messages, and you can choose to reply them right away or followup later using their web dashboard, desktop or mobile app.

[показать]

What I love about Chatra

Easy setup and clean UI

As you can see, the setup is simply pasting a block of code into your blog template (or use their app or plugin for your platform), and it works right away. The chat interface is modern and clean, you can “get it” within no time if you ever used any chat app.

Considerations for bloggers who can’t be online all day

You might wonder, “I don’t have an army of customer service agents, how can I keep everyone happy with only myself replying messages?”. But Chatra already considered that for you with messenger mode, which can receive messages 24/7 even if you are offline. A bot will automatically reply to your visitor and ask for their contact details, so you can follow up later with an email. Every live or missed message can be configured to be sent to your email, so you can check them in batch after a while. Also messaging history are preserved even if the visitor left and come back later, so you get the context of what they were saying. It’s also important to to set expectations for your visitor, to let them know you are working alone and can’t reply super fast. That brings us to the next point: customizable welcome messages and prompts.

Customizable and programmable

Almost everything in Chatra is customizable. From the welcome message, chat button text, to the automatic reply content. So instead of saying “We are a big team and we’ll reply in 10 mins, guaranteed!”, you can instead say something along the line of “Hi, I’m running this site alone and I’d love to hear from you. I’ll get back to you within days”. Besides customizing the look and feel and tone of speech, you can also setup triggers that automatically initiate a chat when criteria meet. For example we can send a automated message when a visitor reads the article for more then 1 minute. Of course you can further customize the experience using the developer API.

[показать]

Out-of-the-box Google Analytics integration

One thing I really care about is understanding how my visitors interact with the site, and how I can optimize the content and UX to further engage them. I did that through Google Analytic. Much to my amazement, Chatra detected my Google analytics configuration and automatically send relevant events to my Google Analytic tracking, without me even setting up anything. I can directly create goals based on the events and track the conversion funnel leading to a chat.

Pricing and features

Chatra has a free and a

Читать далее...

On friday the IETF published TLS 1.3 as RFC 8446. It’s already shipping in Firefox and you can use it today. This version of TLS incorporates significant improvements in both security and speed.

Transport Layer Security (TLS) is the protocol that powers every secure transaction on the Web. The version of TLS in widest use, TLS 1.2, is ten years old this month and hasn’t really changed that much from its roots in the Secure Sockets Layer (SSL) protocol, designed back in the mid-1990s. Despite the minor number version bump, this isn’t the minor revision it appears to be. TLS 1.3 is a major revision that represents more than 20 years of experience with communication security protocols, and four years of careful work from the standards, security, implementation, and research communities (see Nick Sullivan’s great post for the cool details).

Security

TLS 1.3 incorporates a number of important security improvements.

First, it improves user privacy. In previous versions of TLS, the entire handshake was in the clear which leaked a lot of information, including both the client and server’s identities. In addition, many network middleboxes used this information to enforce network policies and failed if the information wasn’t where they expected it.  This can lead to breakage when new protocol features are introduced. TLS 1.3 encrypts most of the handshake, which provides better privacy and also gives us more freedom to evolve the protocol in the future.

Second, TLS 1.3 removes a lot of outdated cryptography. TLS 1.2 included a pretty wide variety of cryptographic algorithms (RSA key exchange, 3DES, static Diffie-Hellman) and this was the cause of real attacks such as FREAK, Logjam, and Sweet32. TLS 1.3 instead focuses on a small number of well understood primitives (Elliptic Curve Diffie-Hellman key establishment, AEAD ciphers, HKDF).

Finally, TLS 1.3 is designed in cooperation with the academic security community and has benefitted from an extraordinary level of review and analysis.  This included formal verification of the security properties by multiple independent groups; the TLS 1.3 RFC cites 14 separate papers analyzing the security of various aspects of the protocol.

Speed

While computers have gotten much faster, the time data takes to get between two network endpoints is limited by the speed of light and so round-trip time is a limiting factor on protocol performance. TLS 1.3’s basic handshake takes one round-trip (down from two in TLS 1.2) and TLS 1.3 incorporates a “zero round-trip” mode in which the client can send data to the server in its first set of network packets. Put together, this means faster web page loading.

What Now?

TLS 1.3 is already widely deployed: both Firefox and Chrome have fielded “draft” versions. Firefox 61 is already shipping draft-28, which is essentially the same as the final published version (just with a different version number). We expect to ship the final version in Firefox 63, scheduled for October 2018. Cloudflare, Google, and Facebook are running it on their servers today. Our telemetry shows that around 5% of Firefox connections are TLS 1.3. Cloudflare reports similar numbers, and Facebook reports that an astounding 50+% of their traffic is already TLS 1.3!

TLS 1.3 was a big effort with a huge number of contributors., and it’s great to see it finalized. With the publication of the TLS 1.3 RFC we expect to see further deployments from other browsers, servers and toolkits, all of which makes the Internet more secure for everyone.

 

The post TLS 1.3 Published: in Firefox

Читать далее...

Send encrypts your files in the browser. This is good for your privacy because it means only you and the people you share the key with can decrypt it. For me, as a software engineer, the challenge with doing it this way is the limited API set available in the browser to “go full circle”. There’s a few things that make it a difficult problem.

The biggest limitation on Send today is the size of the file. This is because we load the entire thing into memory and encrypt it all at once. It’s a simple and effective way to handle small files but it makes large files prone to failure from running out of memory. What size of file is too big also varies by device. We’d like everyone to be able to send large files securely regardless of what device they use. So how can we do it?

The first challenge is to not load and encrypt the file all at once. RFC 8188 specifies a standard for an encrypted content encoding over HTTP that is designed for streaming. This ensures we won’t run out of memory during encryption and decryption by breaking the file into smaller chunks. Implementing the RFC as a Stream give us a nice way to represent our encrypted content.

With a stream instead of a Blob we run into another challenge when it’s time to upload. Streams are not fully supported by the fetch API in all the browsers we want to support yet, including Firefox. We can work around this though, with WebSockets.

Now we’re able to encrypt, upload, download, and decrypt large files without using too much memory. Unfortunately, there’s one more problem to face before we’re able to save a file. There’s no easy way to download a stream from javascript to the local filesystem. The standard way to download data from memory as a file is with createObjectURL, which needs a blob. To stream the decrypted data as a download requires a trip through a ServiceWorker. StreamSaver.js is a nice implementation of the technique. Here again we run into browser support as a limiting factor. There isn’t a work around that doesn’t require having the whole file in memory, which is another case of our original problem. But, streams will be stable in Firefox soon so we’ll be able to support large files as soon as they’re available.

In the end, it’s quite complicated to do end-to-end encryption of large files in the browser compared to small ones, but it is possible. It’s one of many improvements we’re working on for Send this summer that we’re excited about.

As always, you’re welcome to join us on GitHub, and thank you to everyone who’s contributed so far.

---

Send: Going Bigger was originally published in Firefox Test Pilot on Medium, where people are continuing the conversation by highlighting and responding to this story.

https://medium.com/firefox-test-pilot/send-going-bigger-75a499e397df?source=rss----46b1a2ddb811---4

Protocolbuffer Binary Format(.pbf) and Mapbox Vector Tiles(.mvt) are two popular formats for sharing map data. Prior to this GSoC project, the iD editor in OSM supported GPX data. GPX is an XML schema designed as a common GPS data format for software applications. It can be used to describe waypoints, tracks, and routes.

The main objective of the project was to add support for vector tile data to iD. MVT and PBF contain data of a particular tile. These files contain data in Protocolbuffer binary format and can have various sets of data like name of cities, or train stations etc. This data can be in the form of points, lines or polygons. A vector tile looks something like this :

The goal is to draw the data of these tile on iD and it should show up on the screen like this :

For implementing the feature the following steps were followed:

1. Creating a new layer : A new mvt layer is created that would accept a pbf/mvt file. d3_request library is used to read the data in arraybuffer format.
2. Converting data to GeoJSON : The arraybuffer data is converted to GeoJSON format before passing to the drawMvt function.
   For converting vector tile data to GeoJSON data, Mapbox provides with two libraries:
   1. vt2geojson
   2. vector-tile-js
   vt2geojson is great for changing vector tiles to GeoJSON from remote URLs or local system files but it works with Node.js only.
   For iD we have used mapbox’s vector-tile-js, it read Mapbox Vector Tiles and allows access to the layers and features, these features can be further converted to GeoJSON.
3. MVT drawing : This GeoJSON data is pass directly to the D3 draw functions which renders the data. (iD uses D3 for all of our drawing already)

All the work related to the above steps is here.

4. Next step was writing the tests for the above code. Tests for the code are here.

Performance Testing

1. Choosing data : The data which was used to create the vector tiles for testing is this : https://data.cityofnewyork.us/Environment/2015-Street-Tree-Census-Tree-Data/pi5s-9p35/data
   It is a dense data consisting of only points.
2. Creating MVTs : Vector tiles were created using the above data using a tool called tippecanoe. Mapbox’s tippecanoe is used to build vector tilesets from large (or small) collections of GeoJSON, Geobuf, or CSV features.
3. Tippecanoe converts GeoJSON data to mbtiles format, these files contain data for more than one tile. Mapbox/mbview was used to view these tiles in localhost and extract individual tiles from the network tab.

4. This URL when passed to iD draws the vector tile like this :

URL used : http://preview.ideditor.com/master/#background=Bing&disable_features=boundaries&map=9.00/39.7225/-74.0153&mvt=https://a.tiles.mapbox.com/v4/mapbox.mapbox-terrain-v2,mapbox.mapbox-streets-v7/12/1207/1541.vector.pbf?access_token= ‘pk.0000.1111’
# replace value with your mapbox public access token

Some More Interesting Stuff

There is much more that can be done with vector tiles. One thing is better styling of the drawings. A very next step is to provide different colors to different layers of the tile data.

For more discussion, you can follow here.
My earlier blogs can be found 

Читать далее...

Imagine we have a client and a server. The client wants to create logical connections to the server (think of them as "queries"); the client sends a small amount of data when it opens a connection, then the server sends a sequence of response messages and closes the connection. The responses must be delivered in-order, but the order of responses in different connections is irrelevant. It's important to minimize the start-to-finish latency of connections, and the latency between the server generating a response and the client receiving it. There could be hundreds of connections opened per second and some connections produce thousands of response messages. The server uses many threads; a connection's responses are generated by a specific server thread. The client may be single-threaded or use many threads; in the latter case a connection's responses are received by a specific client thread. What's a good way to implement this when both client and server are running in the same OS instance? What if they're communicating over a network?

This problem seems quite common: the network case closely resembles a Web browser fetching resources from a single server via HTTP. The system I'm currently working on contains an instance of this internally, and communication between the Web front end and the server also looks like this. Yet even though the problem is common, as far as I know it's not obvious or well-known what the best solutions are.

A standard way to handle this would be to multiplex the logical connections into a single transport. In the local case, we could use a pair of OS pipes as the transport, a client-to-server pipe to send requests and a server-to-client pipe to return responses. The client allocates connection IDs and the server attaches connection IDs to response messages. Short connections can be very efficient: a write syscall to open a connection, a write syscall to send a response, maybe another write syscall to send a close message, and corresponding read syscalls. One possible problem is server write contention: multiple threads sending responses must make sure the messages are written atomically. In Linux this happens "for free" if your messages are all smaller than PIPE_BUF (4096), but if they aren't you have to do something more complicated, the simplest being to hold a lock while writing to the pipe, which could become a bottleneck for very parallel servers. There is a similar problem with client read contention, which is mixed up with the question of how you dispatch received responses to the thread reading from a connection.

A better local approach might be for the client to use an AF_UNIX socket to send requests to the server, and with each request message pass a file descriptor for a fresh pipe that the server should use to respond to the client. It requires a few more syscalls but client threads require no user-space synchronization, and server threads require no synchronization after the dispatch of a request to a server thread. A pool of pipes in the client might help.

The network case is harder. A naive approach is to multiplex the logical connections over a TCP stream. This suffers from head-of-line-blocking: a lost packet can cause delivery of all messages to be blocked while the packet is retransmitted, because all messages across all connections must be received in the order they were sent. You can use UDP to avoid that problem, but you need encryption, retransmits, congestion control, etc so you probably want to use QUIC or something similar.

The Web client case is interesting. You can multiplex over a WebSocket much like a TCP stream, with the same disadvantages. You could issue an HTTP request for each logical connection, but this would limit the number of open connections to some unknown maximum, and could have even worse performance than the Websocket if the browser and server don't negotiate QUIC + HTTP2. A good solution might be to multiplex the connections into a RTCDataChannel in non-ordered mode. This is probably quite simple to implement in the client, but fairly complex to implement in the server because the RTCDataChannel protocol is complicated (for good reasons AFAIK).

This multiplexing problem seems quite common, and its solutions interesting. Maybe there are known best practices or libraries for this, but I haven't found them yet.

http://robert.ocallahan.org/2018/08/the-parallel-stream-multiplexing-problem.html

TenFourFox Feature Parity Release 9 beta 2 is now available (downloads, hashes, release notes). This version tightens up the geometry on the date/time pickers a little, adds some more hosts to basic adblock, fixes a rare but easily wallpapered crash bug and further tunes up hash tables using a small patch from Firefox 63 (!). I am looking at a new JavaScript issue which does not appear to be a regression, but I'd like to fix it anyway since it may affect other sites. However, I'm not sure if this is going to make FPR9 final, which is still scheduled on or about September 4 due to the American Labor Day holiday on the usual Monday.

The WiFi fix in beta 1 was actually to improve HTML5 geolocation accuracy, and Chris T has confirmed that it does, so that's been updated in the release notes. Don't worry, you are always asked before your location is sent to a site.

On the Talos II side, I've written an enhancement to KVMPPC allowing it to actually monkeypatch Mac OS X with an optimized bcopy in the commpage. By avoiding the overhead of emulating dcbz's behaviour on 32-bit PPC, this hack improves the T2's Geekbench score by almost 200 points in Tiger. Combined with another small routine to turn dcba hints into nops so they don't cause instruction faults, this greatly reduces stalls and watchdog tickles when running Mac apps in QEMU. I'll have a formal article on that with source code for the grubby proletariat shortly, plus a big surprise launch of something I've been working on very soon. Watch this space.

http://tenfourfox.blogspot.com/2018/08/tenfourfox-fpr9b2-available.html

One of my hobbies is to collect information about where curl is used. The following car brands feature devices, infotainment and/or navigation systems that use curl - in one or more of their models.

These are all brands about which I've found information online (for example curl license information), received photos of or otherwise been handed information by what I consider reliable sources (like involved engineers).

Do you have curl in a device installed in another car brand?

List of car brands using curl

Baojun, BMW, Buick, Cadillac, Chevrolet, Ford, GMC, Holden, Mazda, Mercedes, Nissan, Opel, Renault, Seat, Skoda, Subaru, Suzuki, Tesla, Toyota, VW and Vauxhall.

All together, this is a pretty amazing number of installations. This list contains seven (7) of the top-10 car brands in the world 2017! And all the top-3 brands. By my rough estimate, something like 40 million cars sold in 2017 had curl in them. Presumably almost as many in 2016 and a little more in 2018 (based on car sales stats).

Not too shabby for a little spare time project.

How to find curl in your car

Sometimes the curl open source license is included in a manual (it includes my name and email, offering more keywords to search for). That's usually how I've found out many uses purely online.

Sometimes the curl license is included in the "open source license" screen within the actual infotainment system. Those tend to list hundreds of different components and without any search available, you often have to scroll for many minutes until you reach curl or libcurl. I occasionally receive photos of such devices.

Related: why is your email in my car and I have toyota corola.

https://daniel.haxx.se/blog/2018/08/12/a-hundred-million-cars-run-curl/

Git-cinnabar is a git remote helper to interact with mercurial repositories. It allows to clone, pull and push from/to mercurial remote repositories, using git.

Get it on github.

These release notes are also available on the git-cinnabar wiki.

What’s new since 0.4.0?

• git-cinnabar-helper is now mandatory. You can either download one with git cinnabar download on supported platforms or build one with make.
• Performance and memory consumption improvements.
• Metadata changes require to run git cinnabar upgrade.
• Mercurial tags are consolidated in a separate (fake) repository. See the README file.
• Updated git to 2.18.0 for the helper.
• Improved memory consumption and performance.
• Improved experimental support for pushing merges.
• Support for clonebundles for faster clones when the server provides them.
• Removed support for the .git/hgrc file for mercurial specific configuration.
• Support any version of Git (was previously limited to 1.8.5 minimum)
• Git packs created by git-cinnabar are now smaller.
• Fixed incompatibilities with Mercurial 3.4 and >= 4.4.
• Fixed tag cache, which could lead to missing tags.
• The prebuilt helper for Linux now works across more distributions (as long as libcurl.so.4 is present, it should work)
• Properly support the pack.packsizelimit setting.
• Experimental support for initial clone from a git repository containing git-cinnabar metadata.
• Now can successfully clone the pypy and GNU octave mercurial repositories.
• More user-friendly errors.

Development process changes

It took about 6 months between version 0.3 and 0.4. It took more than 18 months to reach version 0.5 after that. That’s a long time to wait for a new version, considering all the improvements that have happened under the hood.

From now on, the release branch will point to the last tagged release, which is roughly the same as before, but won’t be the default branch when cloning anymore.

The default branch when cloning will now be master, which will receive changes that are acceptable for dot releases (0.5.x). These include:

• Changes in behavior that are backwards compatible (e.g. adding new options which default to the current behavior).
• Changes that improve error handling.
• Changes to existing experimental features, and additions of new experimental features (that require knobs to be enabled).
• Changes to Continuous Integration/Tests.
• Git version upgrades for the helper.

The next branch will receive changes for the next “major” release, which as of writing is planned to be 0.6.0. These include:

• Changes in behavior.
• Changes in metadata.
• Stabilizing experimental features.
• Remove backwards compability with older metadata (< 0.5.0).

https://glandium.org/blog/?p=3884

https://blog.mozvr.com/this-week-in-mixed-reality-issue-15/

https://hacks.mozilla.org/2018/08/mdn-changelog-for-july-2018-cdn-tests-goodbye-zones-and-bcd/

Greetings Mozillians!

We are happy to let you know that Friday, August 17th, we are organizing Firefox 62 DevEdition Beta 18 Testday. We’ll be focusing our testing on  Activity Stream, React Animation Inspector and Toolbars & Window Controls features. We will also have fixed bugs verification  and unconfirmed bugs triage ongoing.

Check out the detailed instructions via this etherpad.

No previous testing experience is required, so feel free to join us on #qa IRC channel where our moderators will offer you guidance and answer your questions.

Join us and help us make Firefox better!

See you on Friday!

https://quality.mozilla.org/2018/08/firefox-devedition-62-beta-18-testday-august-17th/

Hello, present and future Mozillians!

We are happy to share with you the final post of the series, which started with two external research report analyses, moved on to sharing updates and plans for support forums, social support, and localization, and now is about to conclude with our strategic summary.

The presentation that is the source of this post can be accessed here. The document is meant to be a set of recommendations for the Marketing team’s leadership as to the state and direction of Support (the Support team being a part of Marketing as of mid-2018).

An important disclaimer before we dive into the summary: as it is customary with projects and ideas, everything described below as a future move or plan is not set in stone and may not happen or can significantly change in nature or details, depending on many factors. That said, this summary should give you a general idea on where we are coming from and where we are headed to as Mozilla’s Support.

The recommendations are a result of external research, data analysis, and recent experiments. In general, we learned that:

• Our site is not delivering optimal support the way it could (when compared to other support sites)
• Our approach should probably be more tuned to specific product requirements (not a “one-size-fits-all” way of doing things)
• Our community is stretched to its limits and needs more support and growth
• We need to look into alternative approaches and experimental methods that may contradict our “old ways”
• We can and should participate in shaping product development through the insights our community and users provide

Thus, the Support vision within Mozilla is evolving from “Partner with the Mozilla community to maximize user success and happiness.” into “People seek out support when they have a problem while using our products. We need to be there for them in ways they expect and in unexpected ways that will delight. We deliver product support that earns user’s trust, helps them take control, and empowers them to do more online.”

There is no reason for alarm due to the “Mozilla community” part missing from the updated vision. Just like all of Mozilla, Support happens in a huge part thanks to the tireless engagement of hundreds of people around the world. Going forward, the community should not be its only engine and driver. Meanwhile, the focus on the user through many different means (sometimes experimental) is at the core of Support’s vision for 2018 and beyond.

Further integration of Support into Mozilla’s overall product strategy means consciously diversifying between solid support for our flagship product (Firefox) while being agile and flexible about new and challenging projects coming from different parts of Mozilla that require support – be it Knowledge Base, Social, support forums, 1:1 or any other format.

For Firefox support, this means focusing on what we already know works and making it work better. For new products, we may want to try new ways of delivering support that step outside of what we have been doing so far. These new, experimental ways may be later expanded into Firefox support. On both fronts, Support will also focus on delivering interesting and impactful insights that shape what the future of Mozilla’s products.

The above is broken down into five separate recommendations, described in more detail below.

Securing the foundation

With a huge number of users visiting the Support site every day for quality help powered by a small group of core contributors, we do not have a stable and solid foundation at the moment.

To avoid running into a one-way street and not delivering support to our users, we want to develop and redesign our community approach with the help of the Open Innovation team. This will come through a series of research explorations and experiments taking place in 2018.

The platform itself should also receive a few tweaks thanks to a more streamlined support from the Marketing Developer team.

Some of the options considered for this segment are:

• Contextual recognition and unobtrusive gamification for our existing core contributors.
• Prototyping a DIY learning program and experimenting with changing community communication channels.
• Combining community coordination with Mission Driven Mozillians and the core Localization team.
• Experimenting with pay-per-use services as backups.
• Investing time and resources into pushing Social support to a new level.

Improving user experience

The Support site has not been reviewed or streamlined for user experience in the recent years, resulting in its current

Читать далее...

Firefox supports DNS-over-HTTPS (aka DoH) since version 62.

You can instruct your Firefox to only use DoH and never fall-back and try the native resolver; the mode we call trr-only. Without any other ability to resolve host names, this is a little tricky so this guide is here to help you. (This situation might improve in the future.)

In trr-only mode, nobody on your local network nor on your ISP can snoop on your name resolves. The SNI part of HTTPS connections are still clear text though, so eavesdroppers on path can still figure out which hosts you connect to.

There's a name in my URI

A primary problem for trr-only is that we usually want to use a host name in the URI for the DoH server (we typically need it to be a name so that we can verify the server's certificate against it), but we can't resolve that host name until DoH is setup to work. A catch-22.

There are currently two ways around this problem:

1. Tell Firefox the IP address of the name that you use in the URI. We call it the "bootstrapAddress". See further below.
2. Use a DoH server that is provided on an IP-number URI. This is rather unusual. There's for example one at 1.1.1.1.

Setup and use trr-only

There are three prefs to focus on (they're all explained elsewhere):

network.trr.mode - set this to the number 3.

network.trr.uri - set this to the URI of the DoH server you want to use. This should be a server you trust and want to hand over your name resolves to. The Cloudflare one we've previously used in DoH tests with Firefox is https://mozilla.cloudflare-dns.com/dns-query.

network.trr.bootstrapAddress- when you use a host name in the URI for the network.trr.uri pref you must set this pref to an IP address that host name resolves to for you. It is important that you pick an IP address that the name you use actually would resolve to.

Example

Let's pretend you want to go full trr-only and use a DoH server at https://example.com/dns. (it's a pretend URI, it doesn't work).

Figure out the bootstrapAddress with dig. Resolve the host name from the URI:

$ dig +short example.com
93.184.216.34

or if you prefer to be classy and use the IPv6 address (only do this if IPv6 is actually working for you)

$ dig -t AAAA +short example.com
2606:2800:220:1:248:1893:25c8:1946

dig might give you a whole list of addresses back, and then you can pick any one of them in the list. Only pick one address though.

Go to "about:config" and paste the copied IP address into the value field for network.trr.bootstrapAddress. Now TRR / DoH should be able to get going. When you can see web pages, you know it works!

DoH-only means only DoH

If you happen to start Firefox behind a captive portal while in trr-only mode, the connections to the DoH server will fail and no name resolves can be performed.

In those situations, normally Firefox's captive portable detector would trigger and show you the login page etc, but when no names can be resolved and the captive portal can't respond with a fake response to the name lookup and redirect you to the login, it won't get anywhere. It gets stuck. And currently, there's no good visual indication anywhere that this is what happens.

You simply can't get out of a captive portal with trr-only. You probably then temporarily switch mode, login to the portal and switch the mode to 3 again.

If you "unlock" the captive portal with another browser/system, Firefox's regular retries while in trr-only will soon detect that and things should start working again.

https://daniel.haxx.se/blog/2018/08/10/how-to-doh-only-with-firefox/