At 5pm we rounded off another fully featured day at the HTTP workshop. Here’s some of what we touched on today:

Moritz started the morning with an interesting presentation about experiments with running the exact same site and contents on h1 vs h2 over different kinds of networks, with different packet loss scenarios and with different ICWND set and more. Very interesting stuff. If he makes his presentation available at some point I’ll add a link to it.

I then got the honor to present the state of the TCP Tuning draft (which I’ve admittedly been neglecting a bit lately), the slides are here. I made it brief but I still got some feedback and in general this is a draft that people seem to agree is a good idea – keep sending me your feedback and help me improve it. I just need to pull myself together now and move it forward. I tried to be quick to leave over to…

Jana, who was back again to tell us about QUIC and the state of things in that area. His presentation apparently was a subset of slides he presented last week in the Berlin IETF. One interesting take-away for me, was that they’ve noticed that the amount of connections for which they detect UDP rate limiting on, has decreased with 2/3 during the last year!

Here’s my favorite image from his slide set. Apparently TCP/2 is not a name for QUIC that everybody appreciates! ;-)

While I think the topic of QUIC piqued the interest of most people in the room and there were a lot of questions, thoughts and ideas around the topic we still managed to get the lunch break pretty much in time and we could run off and have another lovely buffet lunch. There’s certainly no risk for us loosing weight during this event…

After lunch we got ourselves a series of Lightning talks presented for us. Seven short talks on various subjects that people had signed up to do

One of the lightning talks that stuck with me was what I would call the idea about an extended Happy Eyeballs approach that I’d like to call Even Happier Eyeballs: make the client TCP connect to all IPs in a DNS response and race them against each other and use the one that responds with a SYN-ACK first. There was interest expressed in the room to get this concept tested out for real in at least one browser.

We then fell over into the area of HTTP/3 ideas and what the people in the room think we should be working on for that. It turned out that the list of stuff we created last year at the workshop was still actually a pretty good list and while we could massage that a bit, it is still mostly the same as before.

Anne presented fetch and how browsers use HTTP. Perhaps a bit surprising that soon brought us over into the subject of trailers, how to support that and voil'a, in the end we possibly even agreed that we should perhaps consider handling them somehow in browsers and even for javascript APIs… ( nah, curl/libcurl doesn’t have any particular support for trailers, but will of course get that if we’ll actually see things out there start to use it for real)

I think we deserved a few beers after this day! The final workshop day is tomorrow.

https://daniel.haxx.se/blog/2016/07/27/workshop-day-two/

This is #1 of 5 posts I identified as perhaps, being worth finishing and sharing.   Writing never feels finished, and it’s a vulnerable thing… to share ideas – but perhaps better than never sharing them at all?

I wrote most of this post in April of this year (making this outdated with the current work of the Participation Team), thinking about ways the learning format of the Leadership Summit in Singapore could evolve into a valuable tool for community leadership development and credentialing.  Community Leadership Passport(s) perhaps…

At the Participation Leadership Summit in Singapore, we designed the schedule in time blocks sorted by the Leadership Framework.  This meant that everyone attended at least one session identified under each of the building blocks.  The schedule was structured something like this…

As you can see, the structure  ensured that everyone experienced learning outcomes of the entire framework, while still providing choice in what felt most relevant, exciting or interesting in their personal development.  You can find some of this content here.

I started wondering..

How might we evolve the schedule design and content into a format for leadership development that also provides real world credentials?

I don’t think the answer is to take this schedule and make it a static ‘course’ or offering, I don’t think it is about ‘event in box’,  but I do think there’s something in using the framework to enforce quality leadership development, while giving power to what people want to learn, and how they prefer to learn.

Merging this idea + my previous work with participation ‘steps & ladders’ into something like a passport, or series of passports for leadership.

Really, this is about creating a mechanism for helping people build leadership credentials in a way that intersects what they want to learn and do, and what the project needs. It could be used for anything from developing strong mentors, to project leads in areas like IoT and Rust, to governance and diversity & inclusion. Imagining Passports with  3 attributes:

Experience – Taking action, completing tasks, generating experiences associated with learning and project outcomes. Should be clear, and feel doable without too much detail.

Mozilla Content – Completing a course either developed by, or approved as Mozilla content.   These could be online, or in person events.

Learner Choice – Encouraging exploration, and learning that feels valuable, interesting and fun – but with some guidelines for topics, outcomes and likely recommendations to make things easier.  For example, some people might want to complete a Coursera Course on IOT and Embedded systems, while others might prefer a ‘learning by doing’ approach via YouTube channels.

Something like a Leadership Passport would obviously require more thought in implementation, tracking and issuing certification. It could also be used to test and evolve Leadership Framework. I prefer it over a participation ladder because it feels less prescriptive in ‘how’ we step up as leaders and more supportive of ways want to learn and lead — and ultimately help us recognize and invest in emerging leaders sooner.

Image Credit:  Kate Harding – Quilt of Nations.

Share

http://tiptoes.ca/passports-for-community-leadership/

When we rolled out Firefox for iOS late last year, we got a tremendous response and millions of downloads. Lots of Firefox users were ecstatic they could use the browser they love on the iPhone or iPad they had chosen. Today, we’re thrilled to release some big improvements to Firefox for iOS. These improvements will give users more speed, flexibility and choice, three things we care deeply about.

A Faster Firefox Awaits You

It’s summer intern season and our Firefox for iOS Engineer intern Tyler Lacroix pulled out all the stops this month when he unveiled the results of his pet project – making Firefox faster. In Tyler’s testing, he saw up to 40% reduction in CPU usage and up to 30% reduction in memory usage when using this latest version of Firefox. What this means is that users can get to their Web pages faster while seeing battery life savings. Of course, all devices and humans are different so results may vary. Either way, we are psyched to roll out these improvements to you today.

It’s Now Easy to Add Any Website Specific Search Engine. And Change Your Mind.

We’ve already included a set of the most popular search engines in Firefox for iOS, but users may want to search other sites right from the address bar. Looking for that perfect set of moustache handlebars for a vintage road bike? Users can add sites like Craigslist and eBay. Want to become a trivia champ? Get one tap access to Wikipedia. Simply go to a website with a search box and tap on the the magnifying glass to add that search to your list of search engines.

New Menu for Easier Navigation

Navigation in iOS browsers is a huge pain point for users who have come to expect the same seamless experience that’s available on their desktop or laptop. Firefox for iOS features a brand new menu on the toolbar that allows for easier navigation and quick access to frequently used features – from adding a bookmark to finding text in page.

Recover Closed Tabs and Quickly Flip Through Open Tabs

Browser tabs on mobile devices have traditionally been difficult to use. Hard to see, hard to manage, hard to navigate, and gone forever in a tap. In this upgraded Firefox for iOS users can easily recover all closed tabs and navigate through open tabs.

Home Again, Home Again, With One Quick Tap

Almost everyone has one page they go to first and return to often. Further expanding the ability to customize their Firefox for iOS experience, users can now set their favorite site as their homepage. The designated website will open immediately with a tap of the “home” button. This makes it easier than ever before to visit preferred sites in a matter of seconds.

We created these new features in Firefox for iOS because of what we heard from our users, and we look forward to more feedback on the updates. To check out our handiwork, download Firefox for iOS from the App Store and let us know what you think.

From iOS to Android to Windows to Linux, we are supporting a healthy and open web by building a better Firefox. And we couldn’t do it without our hundreds of millions of active users across all platforms and our vibrant community. Thanks, everyone!

For more information:

• Release Notes for Firefox for iOS

https://blog.mozilla.org/blog/2016/07/26/mozilla-delivers-improved-user-experience-in-firefox-for-ios/

Weekly project updates from the Mozilla Connected Devices team.

https://air.mozilla.org/connected-devices-weekly-program-update-20160726/

The W3C Browser Tools- and Testing Working Group met again 13-14 July 2016 in Redmond, WA to discuss the progress of the WebDriver specification. I will try to summarise the discussions, but if you’re interested in all the details the meetings have been meticulously scribed.

I wrote about the progress from our TPAC 2015 meeting previously, and we appear to have made good progress since then. The specification text is nearing completion, although it is missing a few important chapters: Some particularly obvious omissions are the complete lack of input handling, and a big, difficult void where advanced user actions are meant to be.

Actions

James has been hard at work drafting a proposal for action semantics, which we went over in great detail. I think it’s fair to say there had been conceptual agreement in the working group on what the actions were meant to accomplish, but that the details of how they were going to work were extremely scarce.

WebDriver tries to innovate on the actions as they appear in Selenium. Actions in Selenium were originally meant to provide a way to pipeline a sequence of interactions—such as pressing down a mouse button, moving the mouse, and releasing it—through a complex data structure to a single command endpoint. The idea was that this would help address some of the race conditions that are intrinsically part of the one-directional design of the protocol, and reduce latency which may be critical when interacting with a document.

Unfortunately the pipelining design to reduce the number of HTTP requests was never quite implemented in Selenium, and the API design suffered from over-specialisation of different types of input devices and actions. The specification attempts to rectify this by generalising the range of input device classes, and by associating the actions that can be performed with a certain class. This means we are moving away from a flat sequence of types, such as [{type: "mouseDown"}, {type: "mouseMove"}, {type: "mouseUp"}] to a model where each input device has its own “track”. This limits the actions you can perform with each device, which makes some conceptual sense because it would be impossible to i.e. type keys with a mouse or press a mouse button with a stylus/pen input device.

The side-effect of this design is that it allows for parallelisation of actions from one or more types of input devices. This is an important development, as it makes it possible to combine primitives for input methods such as touch: In reality, a device cannot determine whether two fingers are “associated” with the same hand. So instead of defining high-level actions such as pinch and flick, it gives you the right level of granularity to combine actions from two or more touch “finger” devices to synthesise more complex movements. We believe this is a good approach with the right level of granularity that doesn’t try to over-specify or shoehorn in primitives that might not make sense in a cross-browser automation setting.

I’m looking forward to seeing James’ work land in the specificaton text. I think probably some explanatory notes and examples are required to fully explain this concept for both implementors and users.

Input locality

A known limitation of Selenium that we are not proud of is that it does not have a good story for input with alternative keyboard layouts. We have explicitly phrased the specification in such a way that it doesn’t make it impossible to retrofit in support for multiple layouts in the future. But right now we want to finish the baseline of the specification before we try moving into this.

The current design ideas floating around are to have some way of setting a keyboard layout either through a command or a capability. This would allow / to generate key events for Shift and ? on an American layout, and Shift and 7 on Norwegian layout. The biggest reason this is hard is because we need to find the right key code conversion tables for what would happen when typing for example

https://sny.no/2016/07/bttup

This post will take a look at the evolution of signature algorithms and schemes in the TLS protocol since version 1.0. I at first started taking notes for myself but then decided to polish and publish them, hoping that others will benefit as well.

(Let’s ignore client authentication for simplicity.)

Signature algorithms in TLS 1.0 and TLS 1.1

In TLS 1.0 as well as TLS 1.1 there are only two supported signature schemes: RSA with MD5/SHA-1 and DSA with SHA-1. The RSA here stands for the PKCS#1 v1.5 signature scheme, naturally.

select (SignatureAlgorithm)
{
    case rsa:
        digitally-signed struct {
            opaque md5_hash[16];
            opaque sha_hash[20];
        };
    case dsa:
        digitally-signed struct {
            opaque sha_hash[20];
        };
} Signature;

An RSA signature signs the concatenation of the MD5 and SHA-1 digest, the DSA signature only the SHA-1 digest. Hashes will be computed as follows:

h = Hash(ClientHello.random + ServerHello.random + ServerParams)

The ServerParams are the actual data to be signed, the *Hello.random values are prepended to prevent replay attacks. This is the reason TLS 1.3 puts a downgrade sentinel at the end of ServerHello.random for clients to check.

The ServerKeyExchange message containing the signature is sent only when static RSA/DH key exchange is not used, that means we have a DHE_* cipher suite, an RSA_EXPORT_* suite downgraded due to export restrictions, or a DH_anon_* suite where both parties don’t authenticate.

Signature algorithms in TLS 1.2

TLS 1.2 brought bigger changes to signature algorithms by introducing the signature_algorithms extension. This is a ClientHello extension allowing clients to signal supported and preferred signature algorithms and hash functions.

enum {
    none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5), sha512(6)
} HashAlgorithm;

enum {
    anonymous(0), rsa(1), dsa(2), ecdsa(3)
} SignatureAlgorithm;

struct {
    HashAlgorithm hash;
    SignatureAlgorithm signature;
} SignatureAndHashAlgorithm;

If a client does not include the signature_algorithms extension then it is assumed to support RSA, DSA, or ECDSA (depending on the negotiated cipher suite) with SHA-1 as the hash function.

Besides adding all SHA-2 family hash functions, TLS 1.2 also introduced ECDSA as a new signature algorithm. Note that the extension does not allow to restrict the curve used for a given scheme, P-521 with SHA-1 is therefore perfectly legal.

A new requirement for RSA signatures is that the hash has to be wrapped in a DER-encoded DigestInfo sequence before passing it to the RSA sign function.

DigestInfo ::= SEQUENCE {
    digestAlgorithm DigestAlgorithm,
    digest OCTET STRING
}

This unfortunately led to attacks like Bleichenbacher’06 and BERserk because it turns out handling ASN.1 correctly is hard. As in TLS 1.1, a ServerKeyExchange message is sent only when static RSA/DH key exchange is not used. The hash computation did not change either:

h = Hash(ClientHello.random + ServerHello.random + ServerParams)

Signature schemes in TLS 1.3

The signature_algorithms extension introduced by TLS 1.2 was revamped in TLS 1.3 and MUST now be sent if the client offers a single non-PSK cipher suite. The format is backwards compatible and keeps old code points.

enum {
    /* RSASSA-PKCS1-v1_5 algorithms */
    rsa_pkcs1_sha1 (0x0201),
    rsa_pkcs1_sha256 (0x0401),
    rsa_pkcs1_sha384 (0x0501),
    rsa_pkcs1_sha512 (0x0601),

    /* ECDSA algorithms */
    ecdsa_secp256r1_sha256 (0x0403),
    ecdsa_secp384r1_sha384 (0x0503),
    ecdsa_secp521r1_sha512 (0x0603),

    /* RSASSA-PSS algorithms */
    rsa_pss_sha256 (0x0700),
    rsa_pss_sha384 (0x0701),
    rsa_pss_sha512 (0x0702),

    /* EdDSA algorithms */
    ed25519 (0x0703),
    ed448 (0x0704),

    /* Reserved Code Points */
    private_use (0xFE00..0xFFFF)
} SignatureScheme;

Instead of SignatureAndHashAlgorithm, a code point is now called a SignatureScheme and tied to a hash function (if applicable) by the specification. TLS 1.2 algorithm/hash combinations not listed here are deprecated and MUST NOT be offered or negotiated.

New code points for RSA-PSS schemes, as well as Ed25519 and Ed448-Goldilocks were added. ECDSA schemes are now tied to the curve given by the code point name, to be enforced by implementations. SHA-1 signature schemes SHOULD NOT be offered, if needed for backwards compatibility then only as the lowest priority after all other schemes.

The current draft-13 still lists RSASSA-PSS as the only valid signature algorithm allowed to sign handshake messages with an RSA key. The rsa_pkcs1_* values solely refer to signatures which appear in certificates and are not defined for use in signed handshake messages. There is hope.

To prevent various downgrade attacks like FREAK and Logjam the computation of the hashes to be signed has changed significantly and covers the complete handshake, up until CertificateVerify:

h = Hash(Handshake Context + Certificate) + Hash(Resumption Context)

This includes amongst other data the client and server random, key shares, the cipher suite, the certificate, and resumption information to prevent replay and downgrade attacks. With static key exchange algorithms gone the CertificateVerify message is now the one carrying the signature.

https://timtaubert.de/blog/2016/07/the-evolution-of-signatures-in-tls/

Piwik is a great FLOSS website analytics platform. I've been self hosting it for different small websites I've managed through the years. Although it's fairly easy to setup and maintain at this level of use, I want to avoid having another service in my maintenance list.

While looking for user and web respecting alternatives -read looking for something else than Google Analytics- I realized that Sandstorm Oasis does support Piwik.

I logged-in and setup my Piwik instance, or Grain as Sandstorm calls instances, in less than 30 of seconds. The tricky part is to copy the code provided by Sandstorm instead of using the code in Piwik documentation, since that's customized to work with Sandstorms special API interface. Paste in the HTML and you're done!

So if you're looking for decent solutions that respect your users and the web, give Sandstorm a try. They are on a "mission to make open source and indie web applications viable as an ecosystem" and they are doing so by developing a platform which makes it super easy to run many open source web apps, like Piwik, Rocket.Chat, Ghost, GitLab, Wordpress and others. Their hosted Oasis platform also comes with a free plan.

https://giorgos.sealabs.net/user-friendly-website-analytics-with-sandstorm-oasis-and-piwik.html

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 an email! 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

• The 2016 Rust conference lineup.
• Rust performance: A story featuring perf and flamegraph on Linux.
• Sebastian Ullrich has formally verified Rust's binary_search function by transpiling Rust to the Lean theorem prover.
• A short walkthrough of WebRender 2.
• Rust code coverage guide. kcov + Travis CI + Codecov / Coveralls.
• Rust: The new LLVM. Making a case for using Rust as compile target for new languages.
• Test setup and teardown in Rust without a framework.
• [podcast] New Rustacean podcast episode 16. Digging deeper on smart pointers and mutability with Cell and RefCell.

New Crates & Project Updates

• rustup 0.4.0 released.
• error-chain 0.2.2 released, featuring a minor ergonomic improvement.
• Termion 1.0 released.
• Call for proposals for next Rust Doc Days crates. For the second Rust Doc Days, propose crates that need better documentation!
• All the Clippy lints. Overview and documentation of all Clippy lints with search and filtering.
• RMP. MessagePack implementation for Rust.
• electrolysis. A tool for formally verifying Rust programs by transpiling them into definitions in the Lean theorem prover.
• rustsym. A tool to query symbols from Rust code for use in IDEs.
• cargo-benchcmp is rewritten in Rust (from Python).
• This week in Servo 72.
• This week in Rust docs 14.
• This week in TiKV 2016-07-23.
• This week in Ruma 2016-07-24.

Crate of the Week

In what seems to become a kind of tradition, User gsingh93 suggested his trace crate, a syntax extension to insert print! statements to functions to help trace execution. Thanks, gsingh93!

Submit your suggestions 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.

• [easy] rust: move coerce_match, coerce_calls and related tests into run-pass-valgrind. Just moving tests around. Easy introduction to the build system.
• [easy] cargo: Can't specify precise crate version if there are multiple versions.
• [easy] error-chain: Display implementation should show the error's Display, not just the description. Looks like a simple fix.
• [easy] rust: Parsing inconsistencies (lambda, proc, return). This bug identifies some bugs where the rustc parser disagrees with the reference parser. Good first bug for someone interested in parsers.
• [easy] rust: rustbuild should warn on quotes in PATH. Easy fix for Rust's new build system.
• [easy] rust: Make it easier to locate deadlocked tests. A simple enhancement to the test runner to notify the user about long-running tests.
• [easy] rust: Remove obsolete no_stack_check attribute and test. Easy introduction to the compiler and contribution process.
• [easy] rustfmt: Wrap overlong function signatures. There are several rustfmt bugs along these lines so this is a fertile entrypoint for contributors.
• [easy] rustup: Add command to install shell completions.
• [easy] rustup: Clean up toolchain directories after uninstall. A simple bug with a clear fix.
• [moderate] rust: improve error message when resolution via Deref actually required DerefMut. Good first type system bug.
• [easy] imag: Switch to clap in the imag binary.

If you are a Rust project owner and are looking for contributors, please submit tasks here.

Updates from Rust Core

76 pull requests were merged in the last two weeks.

• mtwt is now hygiene and cleaned up – nomen est omen
• impl From for Option
• MIR optimization test groundwork
• Fixed interplay between precision and width in format specifiers (breaking change)
• ExactSizeIterator::is_empty()
• No more MIPS Soft-Float
• Macros: Statements are now matched greedily
• Nested macro_rules!
• impl Debug for {Entry, VacantEntry, OccupiedEntry} in btree_map and hash_map
• More privacy for linker symbols (improves perf)
• impl AddAssign for String (wasn't there already?!)
• beta gets new jemalloc
• cargo publish --dry-run

New Contributors

• Evgeny Safronov
• Matt Horn

Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

• RFC 1559: Allow all literals in attributes.

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. This week's FCPs are:

• Promote ! to a type
• Add language support for bitfields.
• Add support for 128-bit integers.
• Add space-friendly arguments. Add -C link-arg and -C llvm-arg which allow you to pass along argument with spaces.
• Exclude macros from importing with #[macro_use(not(...))].
• Add global_asm! for module-level inline assembly.
• Some internal and language-level changes to name resolution.
• Define a best practices procedure for making bug fixes in the compiler.
• RFC process for formatting style and Rustfmt defaults.
• Add a compiler flag that emits crate dependencies on a best-effort basis.
• Replace synchronization primitives with those from parking_lot.
• Dedicated strike team to resolve unsafe code guidelines.
• Add assert_ne to compliment assert_eq.
• Introduce non-panicking borrow methods on RefCell.
• Propose asserts. This rfc proposes that the following macros be added: assert_gt, assert_lt, assert_ge, and assert_le.
• Clarify behaviour when writing to a union field that implements Drop.

New RFCs

• Add API documentation front page styleguide.
• Deprecate anonymous parameters.
• Add an environment variable to choose between whether to link the static CRT or dynamic CRT.
• Create a team responsible for documentation for the Rust project.
• Propose a shorthand syntax for constructing struct-like values with named fields.

Upcoming Events

• 7/27. Rust Community Team Meeting at #rust-community on irc.mozilla.org.
• 7/27. Rust Berlin July Meetup.
• 7/28. Rust Bay Area: Machine Learning, Bioinformatics, and Embedded OSes.
• 8/3. Rust Community Team Meeting at #rust-community on irc.mozilla.org.
• 8/4. Rust release triage at #rust-triage on irc.mozilla.org.
• 8/8. Seattle Rust Meetup.

If you are running a Rust event please add it to the calendar to get it mentioned here. Email Erick Tryzelaar or Brian Anderson for access.

fn work(on: RustProject) -> Money

No jobs listed for this week.

Tweet us at @ThisWeekInRust to get your job offers listed here!

Quote of the Week

you have a problem. you decide to use Rust. now you have a Rc>>

kmc on #rust.

Thanks to Alex Burka for the tip. Submit your quotes for next week!

This Week in Rust is edited by: nasa42, llogiq, and brson.

https://this-week-in-rust.org/blog/2016/07/26/this-week-in-rust-140/

I decided I’d show up a little early at the Sheraton as I’ve been handling the interactions with hotel locally here in Stockholm where the workshop will run for the coming three days. Things were on track, if we ignore how they got the wrong name of the workshop on the info screens in the lobby, instead saying “Haxx Ab”…

Mark welcomed us with a quick overview of what we’re here for and quick run-through of the rough planning for the days. Our schedule is deliberately loose and open to allow for changes and adaptations as we go along.

Patrick talked about the 1 1/2 years of HTTP/2 working in Firefox so far, and we discussed a lot around the numbers and telemetry. What do they mean and why do they look like this etc. HTTP/2 is now at 44% of all HTTPS requests and connections using HTTP/2 are used for more than 8 requests on median (compared to slightly over 1 in the HTTP/1 case). What’s almost not used at all? HTTP/2 server push, Alt-Svc and HTTP 308 responses. Patrick’s presentation triggered a lot of good discussions. His slides are here.

RTT distribution for Firefox running on desktop and mobile, from Patrick’s slide set:

The lunch was lovely.

Vlad then continued to talk about experiences from implementing and providing server push at Cloudflare. It and the associated discussions helped emphasize that we need better help for users on how to use server push and there might be reasons for browsers to change how they are stored in the current “secondary cache”. Also, discussions around how to access pushed resources and get information about pushes from javascript were briefly touched on.

After a break with some sweets and coffee, Kazuho continued to describe cache digests and how this concept can help making servers do better or more accurate server pushes. Back to more discussions around push and what it actually solved, how much complexity it is worth and so on. I thought I could sense hesitation in the room on whether this is really something to proceed with.

We intend to have a set of lightning talks after lunch each day and we have already have twelve such suggested talks listed in the workshop wiki, but the discussions were so lively and extensive that we missed them today and we even had to postpone the last talk of today until tomorrow. I can already sense how these three days will not be enough for us to cover everything we have listed and planned…

We ended the evening with a great dinner sponsored by Mozilla. I’d say it was a great first day. I’m looking forward to day 2!

https://daniel.haxx.se/blog/2016/07/25/a-workshop-monday/

The Monday Project Meeting

https://air.mozilla.org/mozilla-weekly-project-meeting-20160725/

I’m excited to announce that Susan Chen has been appointed Vice President of Business Development at Mozilla, a new role we are creating to recognize her achievements.

Susan joined Mozilla in 2011 as Head of Strategic Development. During her five years at Mozilla, Susan has worked with the Mozilla team to conceive and execute multiple complex negotiations and concluded hundreds of millions dollar revenue and partnership deals for Mozilla products and services.

As Vice President of Business Development, Susan is now responsible for planning and executing major business deals and partnerships for Mozilla across its product lines including search, commerce, content, communications, mobile and connected devices. She is also in charge of managing the business development team working across the globe.

We are pleased to recognize Susan’s achievements and expanded scope with the title of Vice President. Please join me in welcoming Susan to the leadership team at Mozilla!

Background:

Susan’s bio & Mozillians profile

LinkedIn profile

High-resolution photo

https://blog.mozilla.org/blog/2016/07/25/susan-chen-vp-business-development/

I’ve been a big fan of Windows Phone (now Windows Mobile) for a while and have had a few phones across versions 7, 8, and now 10. A while ago I switched to FastMail as my e-mail provider [1], but had been stuck using Google as my calendar provider still (and my contacts were on my Windows Live account). I had a desire to move all these onto a single account, but Windows 10 Mobile only officially supports e-mail from arbitrary providers. Calendar and contacts are limited to a few special providers.

Below I’ve outlined how I’ve gotten all three services (email, contacts, and calendar) from my FastMail account onto my Windows Mobile device.

http://patrick.cloke.us/posts/2016/07/24/windows-mobile-or-windows-phone-and-fastmail/

The HTTP Workshop 2016 will take place in Stockholm starting tomorrow Monday, as I’ve mentioned before. Today we’ll start off slowly by having a few pre workshop drinks and say hello to old and new friends.

I did a casual count, and out of the 40 attendees coming, I believe slightly less than half are newcomers that didn’t attend the workshop last year. We’ll see browser people come, more independent HTTP implementers, CDN representatives, server and intermediary developers as well as some friends from large HTTP operators/sites. I personally view my attendance to be primarily with my curl hat on rather than my Firefox one. Firmly standing in the client side trenches anyway.

Visitors to Stockholm these days are also lucky enough to arrive when the weather is possibly as good as it can get here with the warmest period through the summer so far with lots of sun and really long bright summer days.

News this year includes the @http_workshop twitter account. If you have questions or concerns for HTTP workshoppers, do send them that way and they might get addressed or at least noticed.

I’ll try to take notes and post summaries of each workshop day here. Of course I will fully respect our conference rules about what to reveal or not.

https://daniel.haxx.se/blog/2016/07/24/http-workshop-2016-day-1/

A couple folks have asked if there will still be a G3 version and I am pleased to announce the answer will very likely be yes; the JavaScript JIT in 45 does not mandate SIMD features in the host CPU, so I don't see any technical reason why not (for that matter, the debug build I'm typing this on isn't AltiVec accelerated either). Still, if you're bravely rocking a Yosemite in 2016 you might want to think about a G4 for that ZIF socket.

I've been slack on some other general interest posts such as the Power Mac security rollup and the state of the user base, but I intend to write them when 45 gets a little more stabilized since there have been some recurring requests from a few of you. Watch for those soon also.

http://tenfourfox.blogspot.com/2016/07/tenfourfox-45-is-more-of-thing.html

Hey SUMO Nation!

During the Work Week in London we had the utmost pleasure of hanging out with some of you (we’re still a bit sad about not everyone making it… and that we couldn’t organize a meetup for everyone contributing to everything around Mozilla).

Among the numerous sessions, working groups, presentations, and demos we also had a SUMO Show & Tell – a story-telling session where everyone could showcase one cool thing they think everyone should know about.

I have asked those who presented to help me share their awesome stories with everyone else – and here you go, with the second one presented by Andrew, a jack-of-all-trades and Bugzilla tamer.

Take a look below and relive the origin story of a great Mozillian – someone just like you!

It all started… with an issue that I had with Firefox on my desktop computer running Windows XP, back in 2011. Firefox wouldn’t stop crashing! I then discovered the support site for Firefox. There I found help with my issue through support articles, and at the same time, I was also intrigued by the ability to help other users through the very same site as well.

As I looked into the available opportunities to contribute to the support team, I landed upon live chat. Live chat was a 1-on-1 chat to help out users with the issues they had. Unfortunately, after I joined the team, the live chat was placed on a hiatus. It was recommended that I move on to the forums and knowledge base, because rather than just helping one user and only them benefiting, on the forums I could help many more people through a single suggestion. For some, this floated well and with others it didn’t, because we weren’t taking care of the user personally (like on the chat).

It definitely took some time for me to adjust to this new setting, as things were (and are) handled differently on the forum and on the knowledge base. Users on the forum sometimes do respond immediately, but most of the time they respond later, and some actually don’t respond at all. This is one of the differences between helping out through live chat and through the forums.

The knowledge base on the other hand, can be really complex. There is markup being used to present text in a different way to different users. We must be as clear and precise as possible when writing the article, since although we may know really well what we are talking about, the article reader (usually a user in need of helpful information) may not. It is definitely challenging for some Mozillians to get involved with writing, but once you do, you get the hang of it and truly enjoy it.

From there on, I kept contributing to the forum and knowledge base, but I also went to find out how I could contribute to other areas of Mozilla. I landed upon triaging bugs within Mozilla sites thanks to the help of Liz Henry and Tyler Downer. Furthermore, as Firefox OS rolled out, I started to provide support to the users, write more articles and file bugs in regards to the OS.

As things moved forward so did life – at the moment I am contributing through the Social Support team. Contributing through Social helps our users on social media realise that we are listening to them and that their comments and woes are not falling on deaf ears. We respond to all types of concerns, be they praises or complaints. Helping users on Twitter while being restricted to 140 characters is difficult, whereas on Facebook we can provide a more detailed explanation and response. With Social Support, a single response from us sometimes reaches only a single person – other times it can reach thousands through re-sharing.

Social media makes it easy to identify issues, crises, and hot topics – it is where people nowadays now go to seek assistance, rant, and share their experiences. Also, as posts and tweets can spread easily on social media, it is a double-edged sword: if something positive is spreading, we hope it spreads more. However, if something negative is spreading, we must contain it, identify, and address the root cause of the issue. The bottom line is: we must help our users while keeping everything in the balance and being constantly vigilant.

In 2013, I was very thankful that I was able to attend the Summit that was held in 3 places across the world. I was invited to Toronto, where I held a session called “What does ‘Mozillian’ mean?” In that session, we defined what the term “Mozillian” meant, who was included, not included, and what roles and capabilities were necessary to classify an individual to be a Mozillian. At the end of the session, we touched base via email to finalize our thoughts and gather the necessary information to pass along to others. Although we made some progress, defining who a Mozillian is, who can (or can’t) be one, and setting a specific criteria is somewhat impossible. We must be accepting of those who come and go, those with different backgrounds, personal preferences regarding getting things done, and (sometimes highly) different opinions. All that said, we are a huge family – a huge Mozilla family.

Thank you Andrew for sharing your story with us. I personally appreciate your relaxed and flexible perspective on (sometimes inevitable) changes and challenges we all face when trying to make Mozilla work for the users of the web.

Here’s to many more great chances for you to rock the (helpful, but not only) web with Mozilla and others!

https://blog.mozilla.org/sumo/2016/07/23/sumo-show-tell-how-i-got-involved-with-mozilla/

Last week saw the latest WebDriver F2F to work on the specification. We held the meeting at the Microsoft campus in Redmond, Washington.

The agenda for the meeting was placed, as usual, on the W3 Wiki. We had quite a lot to discuss and, as always, was a very productive meeting.

The meeting notes are available for Wednesday and Thursday. The most notable items are;

• Finalising Actions in the specification
• newSession
• Certificate handling on navigation
• Specification tests

We also welcomed Apple to their first WG meeting. You may have missed it, but there is going to be a Safari Driver built in in macOS.

http://www.theautomatedtester.co.uk/blog/2016/webdriver-f2f-july-2016.html

It is critical to ensure that women are active participants in digital life. Without this we won’t reach full economic empowerment. This is the perspective and focus I bring to the UN High Level Panel for Women’s Economic Empowerment (HLP), which met last week in Costa Rica, hosted by President Luis Guillermo Solis.

(Here is the previous blog post on this topic.)

Many thanks to President Solis, who led with both commitment and authenticity. Here he shows his prowess with selfie-taking:

Members of the High Level Panel – From Left to Right: Tina Fordham, Citi Research; Laura Tyson, UC Berkeley; Alejandra Mora, Government of Costa Rica; Ahmadou Ba, AllAfrica Global Media; Renana Jhabvala, WIEGO; Elizabeth Vazquez, WeConnect; Jeni Klugman, Harvard Business School; Mitchell Baker, Mozilla; Gwen Hines, DFID-UK; Phumzile Mlambo, UN Women; Jos'e Manuel Salazar Xirinachs, International Labour Organization; Simona Scarpaleggia, Ikea; Winnie Byanyima, Oxfam; Fiza Farhan, Buksh Foundation; Karen Grown, World Bank; Margo Thomas, HLP Secretariat.

Photo Credit: Luis Guillermo Solis, President, Costa Rica

In the meeting we learned about actions the Panel members have initiated, and provided feedback and guidelines on the first draft of the HLP report. The goal for the report is to be as concrete as possible in describing actions in women’s economic empowerment which have shown positive results so that interested parties could adopt these successful practices. An initial version of the report will be released in September, with the final report in 2017.  In the meantime, Panel members are also initiating, piloting and sometimes scaling activities that improve women’s economic empowerment.

As Phumzile Mlambo-Ngcuka, the Executive Director of UN Women often says, the best report will be one that points to projects that are known to work. One such example is a set of new initiatives, interventions and commitments to be undertaken in the Punjab, announced by the Panel Member and Deputy from Pakistan, Fiza Farhan and Mahwish Javaid.

Mozilla, too, is engaged in a set of new initiatives. We’ve been tuning our Mozilla Clubs program, which are on-going events to teach Web Literacy, to be interesting and more accessible to women and girls. We’ve entered into a partnership with UN Women to deepen this work and the pilots are underway. If you’d like to participate, consider applying your organizational, educational, or web skills to start a Mozilla Club for women and girls in your area. Here are examples of existing clubs for women in Nairobi and Cape Town.

Mozilla is also involved in the theme of digital inclusion as a cross-cutting, overarching theme of the HLP report. This is where Anar Simpson, my official Deputy for the Panel, focuses her work. We are liaising with companies in Silicon Valley who are working in the fields of connectivity and distribution of access to explore if, when and and how their projects can empower women economically.  We’re looking to gather everything they have learned about what has been effective. In addition to this information/content gathering task, Mozilla is working with the Panel on the advocacy and publicity efforts of the report.

I joined the Panel because I see it as a valuable mechanism for driving both visibility and action on this topic. Women’s economic empowerment combines social justice, economic growth benefits and the chance for more stability in a fragile world. I look forward to meeting with the UN Panel again in September and reporting back on practical and research-driven initiatives.

http://blog.lizardwrangler.com/2016/07/22/update-on-the-united-nations-high-level-panel-on-womens-economic-empowerment/

Most people believe that having an atomic reference counter makes them safe to use RefPtr on multiple threads without any more synchronization.  Opposite may be truth, though!

Imagine a simple code, using our commonly used helper classes, RefPtr<> and an object Type with ThreadSafeAutoRefCnt reference counter and standard AddRef and Release implementations.

Sounds safe, but there is a glitch most people may not realize.  See an example where one piece of code is doing this, no additional locks involved:

RefPtr local = mMemeber; // mMember is RefPtr, holding an object

And other piece of code then, on a different thread presumably:

mMember = new Type(); // mMember's value is rewritten with a new object

Usually, people believe this is perfectly safe.  But it’s far from it.

Just break this to actual atomic operations and put the two threads side by side:

local.value = mMemeber.value;
/* context switch */ 
.
.
.
.
.
.
local.value->AddRef();

.
.
Type* temporary = new Type();
temporary->AddRef();
Type* old = mMember.value; 
mMember.value = temporary; 
old->Release(); 
/* context switch */ 
.

Similar for clearing a member (or a global, when we are here) while some other thread may try to grab a reference to it:

RefPtr service = sService;
if (!service) {
  return; // service being null is our 'after shutdown' flag
}

And another thread doing, usually during shutdown:

sService = nullptr; // while sService was holding an object

And here what actually happens:

local.value = sService.value;
/* context switch */
.
.
.
.
local.value->AddRef();

.
.
Type* old = sService.value; 
sService.value = nullptr; 
old->Release(); 
/* context switch */
.

And where is the problem?  Clearly, if the Release() call on the second thread is the last one on the object, the AddRef() on the first thread will do its job on a dying or already dead object.  The only correct way is to have both in and out assignments protected by a mutex or, ensure that there cannot be anyone trying to grab a reference from a globally accessed RefPtr when it’s being finally released or just being re-assigned. The letter may not always be easy or even possible.

Anyway, if somebody has a suggestion how to solve this universally without using an additional lock, I would be really interested!

The post Illusion of atomic reference counting appeared first on mayhemer's blog.

http://www.janbambas.cz/illusion-atomic-reference-counting/

A slow hand clap for Samsung, who have managed to create versions of the S4 Mini phone with model numbers (among others):

• GT-i9195
• GT-i9195L (big-ell)
• GT-i9195i (small-eye)
• GT-i9195l (small-ell)

And of course, the small-ell variant, as well as being case-confusable with the big-ell variant and visually confusable with the small-eye variant if it’s written with a capital I as, say, here, is in fact an entirely different phone with a different CPU and doesn’t support the same aftermarket firmware images that all of the other variants do.

See this post for the terrible details.

http://feedproxy.google.com/~r/HackingForChrist/~3/9tyyhoeFX7w/

By default, on Windows, Firefox is a 32-bit application. This means that it is limited to using at most 4 GiB of memory, even on machines that have more than 4 GiB of physical memory (RAM). In fact, depending on the OS configuration, the limit may be as low as 2 GiB.

Now, 2–4 GiB might sound like a lot of memory, but it’s not that unusual for power users to use that much. This includes:

• users with many (dozens or even hundreds) of tabs open;
• users with many (dozens) of extensions;
• users of memory-hungry web sites and web apps; and
• users who do all of the above!

Furthermore, in practice it’s not possible to totally fill up this available space because fragmentation inevitably occurs. For example, Firefox might need to make a 10 MiB allocation and there might be more than 10 MiB of unused memory, but if that available memory is divided into many pieces all of which are smaller than 10 MiB, then the allocation will fail.

When an allocation does fail, Firefox can sometimes handle it gracefully. But often this isn’t possible, in which case Firefox will abort. Although this is a controlled abort, the effect for the user is basically identical to an uncontrolled crash, and they’ll have to restart Firefox. A significant fraction of Firefox crashes/aborts are due to this problem, known as address space exhaustion.

Fortunately, there is a solution to this problem available to anyone using a 64-bit version of Windows: use a 64-bit version of Firefox. Now, 64-bit applications typically use more memory than 32-bit applications. This is because pointers, a common data type, are twice as big; a rough estimate for 64-bit Firefox is that it might use 25% more memory. However, 64-bit applications also have a much larger address space, which means they can access vast amounts of physical memory, and address space exhaustion is all but impossible. (In this way, switching from a 32-bit version of an application to a 64-bit version is the closest you can get to downloading more RAM!)

Therefore, if you have a machine with 4 GiB or less of RAM, switching to 64-bit Firefox probably won’t help. But if you have 8 GiB or more, switching to 64-bit Firefox probably will help the memory usage situation.

Official 64-bit versions of Firefox have been available since December 2015. If the above discussion has interested you, please try them out. But note the following caveats.

• Flash and Silverlight are the only supported 64-bit plugins.
• There are some Flash content regressions due to our NPAPI sandbox (for content that uses advanced features like GPU acceleration or microphone APIs).

On the flip side, as well as avoiding address space exhaustion problems, a security feature known as ASLR works much better in 64-bit applications than in 32-bit applications, so 64-bit Firefox will be slightly more secure.

Work is being ongoing to fix or minimize the mentioned caveats, and it is expected that 64-bit Firefox will be rolled out in increasing numbers in the not-too-distant future.

UPDATE: Chris Peterson gave me the following measurements about daily active users on Windows.

• 66.0% are running 32-bit Firefox on 64-bit Windows. These users could switch to a 64-bit Firefox.
• 32.3% are running 32-bit Firefox on 32-bit Windows. These users cannot switch to a 64-bit Firefox.
• 1.7% are running 64-bit Firefox already.

https://blog.mozilla.org/nnethercote/2016/07/22/firefox-64-bit-for-windows-can-take-advantage-of-more-memory/