The Mozilla Blog: Disney and Pixar’s “Turning Red” movie Browser Wallpapers only available on Firefox for Android and iOS |
Last month we created new Firefox desktop colorways celebrating Disney and Pixar’s “Turning Red” streaming only on Disney+ March 11 (subscription required. 18+ to subscribe). It’s a fun way to show your personality by changing the way your Firefox browser looks, with colors and moods inspired by some of the main characters in the film. Today, we’ve got mobile wallpapers inspired by the all-new movie, based on the coming-of-age story of Mei Lee, a teen who when she gets too excited, transforms into a giant red panda (fun fact: a red panda is also known as a fire fox!). We’ve also created a destination for all things 2002 nostalgia and will be having conversations with people about their journeys to embrace their true colors online.
You can find the wallpapers feature by opening your Firefox Mobile app and double clicking the Firefox logo on the homepage or in your Customization Settings. We will have a variety of wallpapers for you to choose and pick one that suits your style. The wallpapers will be only available to US users. We will have new wallpaper options to share globally in the coming months.
For more on Firefox:
Digital Checklist: How to Start 2022 Right
New Year, New Privacy Protection for Firefox Focus on Android
Firefox’s mobile homepage makes it easier to jump back in to the stuff you care about
The post Disney and Pixar’s “Turning Red” movie Browser Wallpapers only available on Firefox for Android and iOS appeared first on The Mozilla Blog.
https://blog.mozilla.org/en/products/disney-and-pixars-turning-red-movie-browser-mobile-wallpapers/
|
|
The Rust Programming Language Blog: Security advisory for the regex crate (CVE-2022-24713) |
This is a cross-post of the official security advisory. The official advisory contains a signed version with our PGP key, as well.
The Rust Security Response WG was notified that the regex crate did not
properly limit the complexity of the regular expressions (regex) it parses. An
attacker could use this security issue to perform a denial of service, by
sending a specially crafted regex to a service accepting untrusted regexes. No
known vulnerability is present when parsing untrusted input with trusted
regexes.
This issue has been assigned CVE-2022-24713. The severity of this vulnerability
is "high" when the regex crate is used to parse untrusted regexes. Other uses
of the regex crate are not affected by this vulnerability.
The regex crate features built-in mitigations to prevent denial of service
attacks caused by untrusted regexes, or untrusted input matched by trusted
regexes. Those (tunable) mitigations already provide sane defaults to prevent
attacks. This guarantee is documented and it's considered part of the crate's
API.
Unfortunately a bug was discovered in the mitigations designed to prevent untrusted regexes to take an arbitrary amount of time during parsing, and it's possible to craft regexes that bypass such mitigations. This makes it possible to perform denial of service attacks by sending specially crafted regexes to services accepting user-controlled, untrusted regexes.
All versions of the regex crate before or equal to 1.5.4 are affected by this
issue. The fix is include starting from regex 1.5.5.
We recommend everyone accepting user-controlled regexes to upgrade immediately
to the latest version of the regex crate.
Unfortunately there is no fixed set of problematic regexes, as there are practically infinite regexes that could be crafted to exploit this vulnerability. Because of this, we do not recommend denying known problematic regexes.
We want to thank Addison Crump for responsibly disclosing this to us according to the Rust security policy, and for helping review the fix.
We also want to thank Andrew Gallant for developing the fix, and Pietro Albini for coordinating the disclosure and writing this advisory.
|
|
Jan-Erik Rediger: Four-year Moziversary |
It's my fourth Moziversary. It's been 4 years (and three days) now since I joined Mozilla as a Telemetry engineer. I joined Mozilla as a Firefox Telemetry Engineer in March 2018, I blogged three times already: 2019, 2020, 2021.
The past year continued to be challenging. Except for a brief 3-week period the Berlin office stayed close, so we all continue to work from home. I haven't met (most of) my team mates in person since 2020. I hope that in 2022 I will have the chance to meet some of them again, maybe even all at once.
I already spent some time on looking back on most of the work that happened on the Glean project last year in a This Week in Glean post, so no need to reiterate that.
For 2022 Glean will be about stabilizing, some new features and more widespread adoption across our products. I'm still excited to continue that work. We will see what else I pick up along the way.
Thanks to my team mates Alessio, Bea, Chris, Travis, and Mike, and also thanks to the bigger data engineering team within Mozilla. And thanks to all the other people at Mozilla I work with.
|
|
The Mozilla Blog: The website security ecosystem protects individuals against fraud and state-sponsored surveillance. Let’s not break it. |
Principle four of the Mozilla Manifesto states that “Individuals’ security and privacy on the internet are fundamental and must not be treated as optional.” We’ve made real progress on improving security on the Internet, but unfortunately, a draft law under discussion in the EU – the eIDAS Regulation – threatens to reverse that progress. Mozilla and many others have been raising the alarm in the last few months. Today, leading cybersecurity experts are weighing in too, in an open letter to EU lawmakers that warns of the risks that eIDAS represents to web security.
Website certificates sit at the heart of web security. When you make a connection to a web site, say “mozilla.org”, that connection is protected with TLS, but TLS only protects the connection itself; each server has a certificate which ensures that the server on the other end is “mozilla.org” and not an attacker impersonating Mozilla. Certificates are issued by Certificate Authorities (CAs), who are responsible for verifying that a given entity controls the site in question.
A malicious CA — or just one which did not have secure practices — could issue incorrect certificates which could then be used by attackers to attack people’s connections and steal their data. In order to ensure that CAs are held to high standards, each major browser and operating system maintains their own “Root Program,” which is responsible for vetting CAs to ensure that they have acceptable issuance practices, and, where necessary, removing CAs who do not adhere to those practices. For 18 years, Mozilla has operated its Root Program in the open, with published practices and where each proposed CA is considered on a public mailing list, ensuring that any stakeholder can be heard.
Proposed EU legislation threatens to disrupt this balance. Article 45.2 of the eIDAS Regulation mandates support for a new kind of certificate called a Qualified Website Authentication Certificate (QWAC). Under this regulation, QWACs would be issued by Trust Service Providers (another name for CAs), with those TSPs being approved not by the browsers but rather by the governments of individual EU member states. Browsers would be required to trust certificates issued by those TSPs regardless of whether they would meet Root Program security requirements, and without any way to remove misbehaving CAs.
This change would weaken the security of the web by preventing browsers from protecting their users from the security risks – such as identity theft and financial fraud – that a misbehaving CA can expose them too. Worse, compelled inclusion of CAs in our root program would set a precedent for action by repressive regimes. We have already seen state actors (such as Kazakhstan) try to ramp up their surveillance capacities by forcing browsers to automatically trust their CAs — a dangerous practice that browsers and civil society organizations have successfully resisted so far, but if we set the precedent that web browser can’t hold CAs to appropriate security standards that could change quickly.
Technical experts at Mozilla, the Internet Society, the Electronic Frontier Foundation, as well as European civil society organisations have all spoken out about how these requirements would be bad for the web. Today, Mozilla and the EFF are publishing a letter signed by 38 cybersecurity experts about the danger of Article 45.2 to web security and recommendations for how lawmakers can avoid those dangers. The letter demonstrates that the cybersecurity community believes this provision is a threat to web security, creating more problems than it solves.
The post The website security ecosystem protects individuals against fraud and state-sponsored surveillance. Let’s not break it. appeared first on The Mozilla Blog.
|
|
Hacks.Mozilla.Org: Announcing Interop 2022 |
A key benefit of the web platform is that it’s defined by standards, rather than by the code of a single implementation. This creates a shared platform that isn’t tied to specific hardware, a company, or a business model.
Writing high quality standards is a necessary first step to an interoperable web platform, but ensuring that browsers are consistent in their behavior requires an ongoing process. Browsers must work to ensure that they have a shared understanding of web standards, and that their implementation matches that understanding.
Interop 2022 is a cross-browser initiative to find and address the most important interoperability pain points on the web platform. The end result is a public metric that will assess progress toward fixing these interoperability issues.
In order to identify the areas to include, we looked at two primary sources of data:
During the process of collecting this data, it became clear there are two principal kinds of interoperability problems which affect end users and developers:
Problems of the first kind have been termed “focus areas”. For these we use web-platform-tests: a large, shared testsuite that aims to ensure web standards are implemented consistently across browsers. It accepts contributions from anyone, and browsers, including Firefox, contribute tests as part of their process for fixing bugs and shipping new features.
The path to improvement for these areas is clear: identify or write tests in web-platform-tests that measure conformance to the relevant standard, and update implementations so that they pass those tests.
Problems of the second kind have been termed “investigate areas”. For these it’s not possible to simply write tests as we’re not really sure what’s necessary to reach interoperability. Such unknown unknowns turn out to be extremely common sources of developer and user frustration!
We’ll make progress here through investigation. And we’ll measure progress with more qualitative goals, e.g., working out what exact behavior sites depend on, and what can be implemented in practice without breaking the web.
In all cases, the hope is that we can move toward a future in which we know how to make these areas interoperable, update the relevant web standards for them, and measure them with tests as we do with focus areas.
Interop 2022 has ten new focus areas:
Unlike the others the Web Compat area doesn’t represent a specific technology, but is a group of specific known problems with already shipped features, where we see bugs and deviations from standards cause frequent site breakage for end users.
There are also five additional areas that have been adopted from Google and Microsoft’s “Compat 2021” effort:
A browser’s test pass rate in each area contributes 6% — totaling at 90% for fifteen areas — of their score of Interop 2022.
We believe these are areas where the standards are in good shape for implementation, and where improving interoperability will directly improve the lives of developers and end users.
Interop 2022 has three investigate areas:
These are areas in which we often see complaints from end users, or reports of site breakage, but where the path toward solving the issues isn’t clear. Collaboration between vendors is essential to working out how to fix these problem areas, and we believe that Interop 2022 is a unique opportunity to make progress on historically neglected areas of the web platform.
The overall progress in this area will contribute 10% to the overall score of Interop 2022. This score will be the same across all browsers. This reflects the fact that progress on the web platform requires browsers to collaborate on new or updated web standards and accompanying tests, to achieve the best outcomes for end users and developers.
Whilst the focus and investigate areas for 2022 are now set, there is still much to do. For the investigate areas, the detailed targets need to be set, and the complex work of understanding the current state of the art, and assessing the options to advance it, are just starting. Additional tests for the focus areas might be needed as well to address particular edge cases.
If this sounds like something you’d like to get involved with, follow the instructions on the Interop 2022 Dashboard.
Finally, it’s also possible that Interop 2022 is missing an area you consider to be a significant pain point. It won’t be possible to add areas this year, but, if the effort is a success we may end up running further iterations. Feedback on browser differences that are making your life hard as developer or end user are always welcome and will be helpful for identifying the correct focus and investigate areas for any future edition.
Bringing Interop 2022 to fruition was a collaborative effort and you might be interested in the other announcements:
The post Announcing Interop 2022 appeared first on Mozilla Hacks - the Web developer blog.
|
|
The Mozilla Blog: How to secure your data in less than 10 minutes |
|
|
The Mozilla Blog: How to make sure you aren’t spreading misinformation online |
Facts can be empowering during uncertain times, and perhaps there’s no fact-finding tool more accessible than the internet. But as past years have taught us, the internet can also mislead — to dangerous lengths. We know when world events are scary, the internet gets loud and overwhelming. So here are three best practices to spot misinformation online.
Understanding events happening halfway around the world is tricky. Heck, understanding events happening in our own communities can be hard. After all, if we can’t see events unfold before our own eyes, then how can we really know what’s real or not?
That’s why we need to pick trustworthy news organizations that are able to send people on the ground, speak to vetted experts and produce stories that undergo a thorough fact-checking process. Another thing to consider, as journalist and fact-checking expert Kaitlyn Jakola told Mozilla: the money. Who’s funding the organization? Why do they publish certain stories?
Once you’ve decided that an organization is trustworthy, verify the web address to make sure that it’s not impersonating a real news website.
Now onto the stories themselves: Consider the sources. “See where else these experts have been quoted before,” Jakola said. “Though keep in mind this can go both ways. There are some people who make their whole career out of making media appearances and not doing any of the work. On the other hand, you have folks like Dr. Anthony Fauci who does the work and has been trusted by journalists for decades.”
From out-of-context media to Photoshopped images to deepfakes, unreliable photos and videos proliferate across social media. BBC journalist Shayan Sardarizadeh, who reports on disinformation, has this important advice: Look closer. In videos, zoom into billboards, street signs, license plates and other clues that could hint at whether a certain event really took place at the time and location as stated by the social media account that shared the footage. If anything looks off, take it as a sign to investigate further into the source of the video. Did the person take the video themselves? If not, where did this person get the footage?
The same goes for images. You can use reverse image lookup tools like the Search by Image or the TinEye Reverse Image add-on for Firefox. Even if it’s a real photo, make sure if it’s an image taken at the right time and location.
Remember: If it’s not from a trusted news source, don’t take anything at face value.
This may be obvious but bears repeating: Read more than the headline. An article’s title doesn’t tell the whole story. Even trusted news sources write headlines meant to capture attention in crowded social media feeds, so they emphasize the most emotional or outrageous part of a story. This can be misleading, especially if you don’t read the full article.
Going past the headline and social media caption lets you think critically about the information presented by the story. You should also check the date and the author. When was the story written? Does it have updated information? Is the author a reporter, an opinion writer or a satirist? What other stories or sources are linked to in the piece that provide more context and information?
An internet free of misinformation may be impossible, but taking a few extra steps before hitting that share button can help us get closer.
Additional resources:
The post How to make sure you aren’t spreading misinformation online appeared first on The Mozilla Blog.
https://blog.mozilla.org/en/internet-culture/spotting-misinformation-online/
|
|
Hacks.Mozilla.Org: A new year, a new MDN |
If you’ve accessed the MDN website today, you probably noticed that it looks quite different. We hope it’s a good different. Let us explain!
MDN has undergone many changes in its sixteen-year history from its early beginning as a wiki to the recent migration of a static site backed by GitHub. During that time MDN grew organically, with over 45,000 contributors and numerous developers and designers. It’s no surprise that the user experience became somewhat inconsistent throughout the website.
In mid-2021 we started to think about modernizing MDN’s design, to create a clean and inviting website that makes navigating our 44,000 articles as easy as possible. We wanted to create a more holistic experience for our users, with an emphasis on improved navigability and a universal look and feel across all our pages.
The MDN community is the reason our content can be counted on to be both high quality and trustworthy. MDN content is scrutinized, discussed, and yes, in some cases argued about. Anyone can contribute to MDN, either by writing content, suggesting changes or fixing bugs.
We wanted to acknowledge and celebrate our awesome community and our homepage is the perfect place to do so.
The new homepage was built with a focus on the core concepts of community and simplicity. We made an improved search a central element on the page, while also showing users a selection of the newest and most-read articles.
We will also show the most recent contributions to our GitHub content repo and added a contributor spotlight where we will highlight MDN contributors.
It’s been years—five of them, in fact—since MDN’s core content presentation has received a comprehensive design review. In those years, MDN’s content has evolved and changed, with new ways of structuring content, new ways to build and write docs, and new contributors. Over time, the documentation’s look and feel had become increasingly disconnected from the way it’s read and written.
While you won’t see a dizzying reinvention of what documentation is, you’ll find that most visual elements on MDN did get love and attention, creating a more coherent view of our docs. This redesign gives MDN content its due, featuring:
We’re especially proud of some subtle improvements and conveniences. For example, in-page navigation is always in view to show you where you are in the page as you scroll:
We’re also revisiting the way browser compatibility data appears, with better at-a-glance browser support. So you don’t have to keep version numbers in your head, we’ve put more emphasis on yes and no iconography for browser capabilities, with the option to view the detailed information you’ve come to expect from our browser compatibility data. We think you should check it out.
And we’re not stopping there. The work we’ve done is far-reaching and there are still many opportunities to polish and improve on the design we’re shipping.
As we began working on both the redesign and expanding MDN beyond WebDocs we realized it was also time for a new logo. We wanted a modern and easily customizable logo that would represent what MDN is today while also strengthening its identity and making it consistent with Mozilla’s current brand.
We worked closely with branding specialist Luc Doucedame, narrowed down our options to eight potential logos and put out a call to our community of users to help us choose and invited folks to vote on their favorite. We received over 10,000 votes in just three days and are happy to share with you “the MDN people’s choice.”
The winner was Option 4, an M monogram using underscore to convey the process of writing code. Many thanks to everyone who voted!
In recent years, MDN content has grown more sophisticated for authors, such as moving from a wiki to Git and converting from HTML to Markdown. This has been a boon to contributors, who can use more powerful and familiar tools to create more structured and consistent content.
With better tools in place, we’re finally in a position to build more visible and systematic benefits to readers. For example, many of you probably navigate MDN via your favorite search engine, rather than MDN’s own site navigation. We get it. Historically, a wiki made large content architecture efforts impractical. But we’re now closer than ever to making site-wide improvements to structure and navigation.
Looking forward, we have ambitious plans to take advantage of our new tools to explore improved navigation, generated standardization and support summarizes, and embedding MDN documentation in the places where developers need it most: in their IDE, browser tools, and more.
MDN has built a reputation as a trusted and central resource for information about standards, codes, tools, and everything you need as a developer to create websites. In 2015, we explored ways to be more than a central resource through creating a Learning Area, with the aim of providing a useful counterpart to the regular MDN reference and guide material.
In 2020, we added the first Front-end developer learning pathway to it. We saw a lot of interest and engagement from users, the learning area currently being responsible for 10% of MDN’s monthly web traffic. This started us on a path to see what more we can do in this area for our community.
Last year we surveyed users and asked them what they wanted out of their MDN experience. The top requested features included notifications, article collections and an offline experience on MDN. The overall theme we saw was that users wanted to be able to organize MDN’s vast library in a way that worked for them.
We are always looking for ways to meet our users’ needs whether it’s through MDN’s free web documentation or personalized features. In the coming months, we’ll be expanding MDN to include a premium subscription service based on the feedback we received from web developers who want to customize their MDN experience. Stay tuned for more information on MDN Plus.
We appreciate the thousands of people who voted for the new logo as well as everyone who participated in the early beta testing phase since we started this journey. Also, many thanks to our partners from the Open Web Docs, who gave us valuable feedback on the redesign and continue to make daily contributions to MDN content. Thanks to you all we could make this a reality and we will continue to invest in improving even further the experience on MDN.
The post A new year, a new MDN appeared first on Mozilla Hacks - the Web developer blog.
|
|
Wladimir Palant: Skype extension: All functionality broken? Still exploitable! |
One of the most popular Chrome extensions is Skype, a browser extension designed as a helper for the Skype application. Back when I reported the issues discussed here it was listed in Chrome Web Store with more than 10 million users, at the time of writing more than 9 million users still remain. What these users apparently didn’t realize: the extension was unmaintained, with the latest release being more than four years old. All of its functionality was broken, it being reduced to a bookmark for Skype for Web.
Yet despite being essentially useless, the Skype extension remained a security and privacy risk. One particularly problematic issue allowed every website to trivially learn your identity if you were logged into your Microsoft account, affecting not merely Skype users but also users of Office 365 for example.
Last week Microsoft, after a lengthy period of communication silence, finally published an update to resolve the issues. In fact, the new release shares no functionality with the old extension and is essentially a completely new product. Hopefully this one will no longer be abandoned.
One piece of functionality still working in the Skype extension was keeping track of your identity. The extension would notice if you logged into a Microsoft account, be it on skype.com, outlook.com or any other Microsoft website. It would recognize your identity and call the following function:
setUserId: function(userId)
{
this.currentUserId(userId);
if (!userId)
sessionStorage.removeItem("sxt-user");
else
sessionStorage.setItem("sxt-user", userId);
}
So the user identifier is stored in the extension’s session storage where the extension can look it up later. Except that, from the look of it, the extension never bothered to use this value later. And that the code above executed in the extension’s content scripts as well.
In content script context sessionStorage is no longer extension’s storage, it’s the website’s. So the website can read it out trivially:
console.log(sessionStorage["sxt-user"]);
This will produce an output like “8:live:.cid.0123456789abcdef.” And the part after “8:” is your Skype ID. That anybody can put into the Skype search to see your name and avatar. Available to each and every website you visit, because the Skype extension would run its content scripts everywhere despite only integrating with a selected few sites.
Speaking of website integration, the Skype extension integrated with Gmail, Google Calendar, Google Inbox (yes, the service shut down in 2019), Outlook and Twitter. The idea was to add a button that, when clicked, would create a Skype conversation and add the corresponding link to your message. Except that these websites evolved, and these days the extension could only somewhat add its button on Gmail.
The configuration used for Gmail looks as following:
{
id: "gmail",
host: "mail.google.*",
allowGuests: true,
allowProspects: true,
silentLoginOnInjectEnabled: false,
injectionHandles: [{
method: "insert-after",
selector: "div[command=\"+emoticon\"]",
titleSelector: "input[name=\"subjectbox\"]",
descriptionSelector: "div[role=\"textbox\"]"
}],
...
}
Yes, the host value is a terribly permissive regular expression that will match lots of different websites. But, despite its name, this value is actually applied to the full website address. So even https://example.com/#mail.google.com counts as Gmail.
Then a malicious page merely needs to have the right elements and the Skype extension will inject its button. That the page can click programmatically. Resulting in a Skype conversation being created. And the extension putting a link to it into a text field that the website can read out. And then the website can use the link to spam you for example. And, unlike with regular spam, you don’t even need to accept these messages. Because it’s “you” who created this conversation, despite the whole process working without you doing or noticing anything.
Actually, it’s how this would have worked. And how it worked until around mid-2021 when Microsoft shut down api.scheduler.skype.com, one of the old Skype backend servers that this extension relied on. So now a malicious website only succeeded creating a conversation, but the extension failed retrieving the link to it, meaning that the website would no longer get it.
Microsoft has MSRC Researcher Portal, the system that vulnerability reports should be submitted through. I submitted both issues on December 1, 2021. Three days later the submission status changed into “Reviewing.” By mid-January 2022 Microsoft was still “reviewing” this issue, and I could see that the proof-of-concept pages on my server have not been accessed. So on January 19, 2022 I asked on MSRC about the issue’s progress, noting the disclosure deadline.
As there was still no reaction, I decided that naming Microsoft publicly was an acceptable risk, them having a large number of different products. On February 2, 2022 I asked for help on Twitter and Mastodon, maybe someone else could bring Microsoft’s attention to this issue. A reporter then asked Microsoft’s PR department about it. Whether there is a connection or not, on February 7, 2022 my submission was finally accepted as a valid vulnerability and status changed to “under development.”
On February 14, 2022 I again noted the impending deadline on MSRC and asked about the issue’s status. Again no reaction. Only on February 23 I finally got a response apologizing about the delay and promising a release soon. On February 24 this release indeed happened. And on February 25 my proof-of-concept pages were accessed, for the first time.
While the communication was problematic to say the least, the fix is as thorough as it can get: all the problematic code is completely gone. In fact, the extension no longer has content scripts at all. All functionality is now located in the extension’s pop-up, and it’s all new functionality as well. It’s essentially a completely different product.
Microsoft would still need to update their website which currently says:
Read a good article? Now you can share a site directly with your Skype contacts.
…
The Skype extension also makes calling a number from search results easy.
Neither feature is part of the current release, and in fact the second feature listed already wasn’t part of the previous four years old release either.
This page seems to be similarly badly maintained as the extension itself. The Skype extension was removed from Mozilla Add-ons website a few years ago due to being incompatible with Firefox 57 (released in 2017) and above. Microsoft didn’t bother uploading their Chrome extension there which would have been compatible with a few minor tweaks to the extension manifest. Yet the “Get Skype extension for Firefox” link is still present on the page and leads nowhere.
https://palant.info/2022/03/01/skype-extension-all-functionality-broken-still-exploitable/
|
|
Robert Kaiser: Connecting the Mozilla Community |
https://home.kairo.at/blog/2022-02/connecting_the_mozilla_community
|
|
Jan-Erik Rediger: This Week in Glean: Your personal Glean data pipeline |
(“This Week in Glean” is a series of blog posts that the Glean Team at Mozilla is using to try to communicate better about our work. They could be release notes, documentation, hopes, dreams, or whatever: so long as it is inspired by Glean.) All "This Week in Glean" blog posts are listed in the TWiG index (and on the Mozilla Data blog). This article is cross-posted on the Mozilla Data blog.
On February 11th, 2022 we hosted a Data Club Lightning Talk session. There I presented my small side project of setting up a minimal data pipeline & data storage for Glean.
The premise:
Can I build and run a small pipeline & data server to collect telemetry data from my own usage of tools?
To which I can now answer: Yes, it's possible. The complete ingestion server is a couple hundred lines of Rust code. It's able to receive pings conforming to the Glean ping schema, transform them and store it into an SQLite database. It's very robust, not crashing once on me (except when I created an infinite loop within it).
You can watch the lightning talk here:
Instead of creating some slides for the talk I created an interactive report. The full report can be read online.
Besides actually writing a small pipeline server this was also an experiment in trying out Irydium and Datasette to produce an interactive & live-updated data report.
Irydium is a set of tooling designed to allow people to create interactive documents using web technologies, started by wlach a while back. Datasette is an open source multi-tool for exploring and publishing data, created and maintained by simonw. Combining both makes for a nice experience, even though there's still some things that could be simplified.
My pipeline server is currently not open source. I might publish it as an example at a later point.
https://fnordig.de/2022/02/25/your-personal-glean-data-pipeline
|
|
Data@Mozilla: This Week in Glean: Your personal Glean data pipeline |
(“This Week in Glean” is a series of blog posts that the Glean Team at Mozilla is using to try to communicate better about our work. They could be release notes, documentation, hopes, dreams, or whatever: so long as it is inspired by Glean.) All “This Week in Glean” blog posts are listed in the TWiG index (and on the Mozilla Data blog).
On February 11th, 2022 we hosted a Data Club Lightning Talk session. There I presented my small side project of setting up a minimal data pipeline & data storage for Glean.
The premise:
Can I build and run a small pipeline & data server to collect telemetry data from my own usage of tools?
To which I can now answer: Yes, it’s possible. The complete ingestion server is a couple hundred lines of Rust code. It’s able to receive pings conforming to the Glean ping schema, transform them and store it into an SQLite database. It’s very robust, not crashing once on me (except when I created an infinite loop within it).
You can watch the lightning talk here:
Instead of creating some slides for the talk I created an interactive report. The full report can be read online.
Besides actually writing a small pipeline server this was also an experiment in trying out Irydium and Datasette to produce an interactive & live-updated data report.
Irydium is a set of tooling designed to allow people to create interactive documents using web technologies, started by wlach a while back. Datasette is an open source multi-tool for exploring and publishing data, created and maintained by simonw. Combining both makes for a nice experience, even though there’s still some things that could be simplified.
My pipeline server is currently not open source. I might publish it as an example at a later point.
https://blog.mozilla.org/data/2022/02/25/this-week-in-glean-your-personal-glean-data-pipeline/
|
|
Cameron Kaiser: Next update set available for TenFourFox |
The workaround is needed because TenFourFox doesn't support IntersectionObserver. I'm pondering whether this is the point to add a global polyfill to the browser that could potentially cover this and other deficiencies, but although it would be nice to not play whack-a-mole so much, that would have some consequences for performance and memory use over a targetted fix like this. I don't want to get too complex with having a "black list" for sites that need the polyfill you can add to, but maybe that's the least bad option. I'll do some thinking.
In case you missed it, I've always maintained that the most logical upgrade path from a PowerPC-based computer is to ... another PowerPC-based computer. SheepShaver, the well-known classic Mac OS emulator (which many of you use to run Classic apps in Leopard), is now ported to OpenPOWER, so you can run it on a POWER9-based workstation like the Raptor Talos II or Blackbird. Myself, with this port working, I've migrated almost entirely from QEMU to SheepShaver except for a few apps that still have compatibility issues. Come on in: Power ISA isn't dead, not by a long shot.
http://tenfourfox.blogspot.com/2022/02/next-update-set-for-tenfourfox.html
|
|
The Rust Programming Language Blog: Announcing Rust 1.59.0 |
The Rust team has published a new version of Rust, 1.59.0. Rust is a programming language that is empowering everyone to build reliable and efficient software.
Today's release falls on the day in which the world's attention is captured by the sudden invasion of Ukraine by Putin's forces. Before going into the details of the new Rust release, we'd like to state that we stand in solidarity with the people of Ukraine and express our support for all people affected by this conflict.
If you have a previous version of Rust installed via rustup, you can get 1.59.0 with:
rustup update stable
If you don't have it already, you can get rustup
from the appropriate page on our website, and check out the
detailed release notes for 1.59.0 on GitHub.
The Rust language now supports inline assembly. This enables many applications that need very low-level control over their execution, or access to specialized machine instructions.
When compiling for x86-64 targets, for instance, you can now write:
use std::arch::asm;
// Multiply x by 6 using shifts and adds
let mut x: u64 = 4;
unsafe {
asm!(
"mov {tmp}, {x}",
"shl {tmp}, 1",
"shl {x}, 2",
"add {x}, {tmp}",
x = inout(reg) x,
tmp = out(reg) _,
);
}
assert_eq!(x, 4 * 6);
The format string syntax used to name registers in the asm! and global_asm!
macros is the same used in Rust format strings, so it should feel quite familiar
to Rust programmers.
The assembly language and instructions available with inline assembly vary according to the target architecture. Today, the stable Rust compiler supports inline assembly on the following architectures:
You can see more examples of inline assembly in Rust By Example, and find more detailed documentation in the reference.
You can now use tuple, slice, and struct patterns as the left-hand side of an assignment.
let (a, b, c, d, e);
(a, b) = (1, 2);
[c, .., d, _] = [1, 2, 3, 4, 5];
Struct { e, .. } = Struct { e: 5, f: 3 };
assert_eq!([1, 2, 1, 4, 5], [a, b, c, d, e]);
This makes assignment more consistent with let bindings, which have long
supported the same thing. Note that destructuring assignments with operators
such as += are not allowed.
Generic types can now specify default values for their const generics. For example, you can now write the following:
struct ArrayStorage {
arr: [T; N],
}
impl ArrayStorage {
fn new(a: T, b: T) -> ArrayStorage {
ArrayStorage {
arr: [a, b],
}
}
}
Previously, type parameters were required to come before all const parameters. That restriction has been relaxed and you can now interleave them.
fn cartesian_product<
T, const N: usize,
U, const M: usize,
V, F
>(a: [T; N], b: [U; M], f: F) -> [[V; N]; M]
where
F: FnMut(&T, &U) -> V
{
// ...
}
Sometimes bugs in the Rust compiler cause it to accept code that should not have been accepted. An example of this was borrows of packed struct fields being allowed in safe code.
While this happens very rarely, it can be quite disruptive when a crate used by your project has code that will no longer be allowed. In fact, you might not notice until your project inexplicably stops building!
Cargo now shows you warnings when a dependency will be rejected by a future
version of Rust. After running cargo build or cargo check, you might see:
warning: the following packages contain code that will be rejected by a future version of Rust: old_dep v0.1.0
note: to see what the problems were, use the option `--future-incompat-report`, or run `cargo report future-incompatibilities --id 1`
You can run the cargo report command mentioned in the warning to see a full
report of the code that will be rejected. This gives you time to upgrade your
dependency before it breaks your build.
It's often useful to strip unnecessary information like debuginfo from binaries you distribute, making them smaller.
While it has always been possible to do this manually after the binary is
created, cargo and rustc now support stripping when the binary is linked. To
enable this, add the following to your Cargo.toml:
[profile.release]
strip = "debuginfo"
This causes debuginfo to be stripped from release binaries. You can also supply
"symbols" or just true to strip all symbol information where supported.
The standard library typically ships with debug symbols and line-level
debuginfo, so Rust binaries built without debug symbols enabled still include
the debug information from the standard library by default. Using the strip
option allows you to remove this extra information, producing smaller Rust
binaries.
See Cargo's documentation for more details.
The 1.59.0 release disables incremental by default (unless explicitly asked for
by via an environment variable: RUSTC_FORCE_INCREMENTAL=1). This mitigates
the effects of a known bug, #94124, which can cause deserialization errors (and panics) during compilation
with incremental compilation turned on.
The specific fix for #94124 has landed and is currently in the 1.60 beta, which will ship in six weeks. We are not presently aware of other issues that would encourage a decision to disable incremental in 1.60 stable, and if none arise it is likely that 1.60 stable will re-enable incremental compilation again. Incremental compilation remains on by default in the beta and nightly channels.
As always, we encourage users to test on the nightly and beta channels and report issues you find: particularly for incremental bugs, this is the best way to ensure the Rust team can judge whether there is breakage and the number of users it affects.
The following methods and trait implementations are now stabilized:
std::thread::available_parallelismResult::copiedResult::clonedarch::asm!arch::global_asm!ops::ControlFlow::is_breakops::ControlFlow::is_continueTryFrom for u8 char::TryFromCharError
implementing Clone, Debug, Display, PartialEq, Copy, Eq, Erroriter::zipNonZeroU8::is_power_of_twoNonZeroU16::is_power_of_twoNonZeroU32::is_power_of_twoNonZeroU64::is_power_of_twoNonZeroU128::is_power_of_twoDoubleEndedIterator for ToLowercaseDoubleEndedIterator for ToUppercaseTryFrom<&mut [T]> for [T; N]UnwindSafe for OnceRefUnwindSafe for OnceThe following previously stable functions are now const:
mem::MaybeUninit::as_ptrmem::MaybeUninit::assume_initmem::MaybeUninit::assume_init_refffi::CStr::from_bytes_with_nul_uncheckedThere are other changes in the Rust 1.59.0 release. Check out what changed in Rust, Cargo, and Clippy.
Many people came together to create Rust 1.59.0. We couldn't have done it without all of you. Thanks!
|
|
The Talospace Project: Brief status update on the POWER9 JavaScript JIT |
Told you it was a productive holiday weekend. Onward to conquering the test suite.
https://www.talospace.com/2022/02/brief-status-update-on-power9.html
|
|
Mozilla Attack & Defense: Fixing a Security Bug by Changing a Function Signature |
|
|
Wladimir Palant: Breaking Custom Cursor to p0wn the web |
Browser extensions make attractive attack targets. That’s not necessarily because of the data handled by the extension itself, but too often because of the privileges granted to the extension. Particularly extensions with access to all websites should better be careful and reduce the attack surface as much as possible. Today’s case study is Custom Cursor, a Chrome extension that more than 6 million users granted essentially full access to their browsing session.
The attack surface of Custom Cursor is unnecessarily large: it grants custom-cursor.com website excessive privileges while also disabling default Content Security Policy protection. The result: anybody controlling custom-cursor.com (e.g. via one of the very common cross-site scripting vulnerabilities) could take over the extension completely. As of Custom Cursor 3.0.1 this particular vulnerability has been resolved, the attack surface remains excessive however. I recommend uninstalling the extension, it isn’t worth the risk.
The Custom Cursor extension will let you view cursor collections on custom-cursor.com website, installing them in the extension works with one click. The seamless integration is possible thanks to the following lines in extension’s manifest.json file:
"externally_connectable": {
"matches": [ "*://*.custom-cursor.com/*" ]
},This means that any webpage under the custom-cursor.com domain is allowed to call chrome.runtime.sendMessage() to send a message to this extension. The message handling in the extension looks as follows:
browser.runtime.onMessageExternal.addListener(function (request, sender, sendResponse) {
switch (request.action) {
case "getInstalled": {
...
}
case "install_collection": {
...
}
case "get_config": {
...
}
case "set_config": {
...
}
case "set_config_sync": {
...
}
case "get_config_sync": {
...
}
}
}.bind(this));
This doesn’t merely allow the website to retrieve information about the installed icon collections and install new ones, it also provides the website with arbitrary access to extension’s configuration. This in itself already has some abuse potential, e.g. it allows tracking users more reliably than with cookies as extension configuration will survive clearing browsing data.
Originally I looked at Custom Cursor 2.1.10. This extension version used jQuery for its user interface. As noted before, jQuery encourages sloppy security practices, and Custom Cursor wasn’t an exception. For example, it would create HTML elements by giving jQuery HTML code:
collection = $(
`${collname}">
${item.name}
${collname}">
With collname being unsanitized collection name here, this code allows HTML injection. A vulnerability like that is normally less severe for browser extensions, thanks to their default Content Security Policy. Except that Custom Cursor doesn’t use the default policy but instead:
"content_security_policy": "script-src 'self' 'unsafe-eval'; object-src 'self'",This 'unsafe-eval' allows calling inherently dangerous JavaScript functions like eval(). And what calls eval() implicitly? Why, jQuery of course, when processing a
https://palant.info/2021/09/28/breaking-custom-cursor-to-p0wn-the-web/
|
|