mozilla

Mozilla Nederland LogoDe Nederlandse
Mozilla-gemeenschap

Questions About .org

Mozilla Blog - di, 03/12/2019 - 15:01

Last month, the Internet Society (ISOC) announced plans to sell the Public Interest Registry (PIR) — the organization that manages all the dot org domain names in the world — to a private equity firm named Ethos. This caught the attention of Mozilla and other public benefit orgs.

Many have called for the deal to be stopped. It’s not clear that this kind of sale is inherently bad. It is possible that with the right safeguards a private company could act as a good steward of the dot org ecosystem. However, it is clear that the stakes are high — and that anyone with the power to do so should urgently step in to slow things down and ask some hard questions.

For example: Is this deal a good thing for orgs that use these domains? Is it structured to ensure that dot org will retain its unique character as a home for non-commercial organizations online? What accountability measures will be put in place?

In a letter to ISOC, the EFF and others summarize why the stakes are high. Whoever runs the dot org registry has the power to: set (and raise) prices; define rights protection rules; and suspend or take down domains that are unlawful, a standard that varies widely from jurisdiction to jurisdiction. It is critical that whoever runs the dot org registry is a reliable steward who can be held accountable for exercising these powers fairly and effectively.

ISOC and Ethos put up a site last week called keypointsabout.org which argues that the newly privatized PIR will be just such a steward. Measures outlined on the site include the creation of a stewardship council, price caps, and the incorporation of the new PIR as a B Corp. These sound like good plans at first read, but they need much more scrutiny and detail given what is at stake.

ICANN and the ISOC board are both in a position to slow things down and offer greater scrutiny and public transparency. We urge them to step back and provide public answers to questions of interest to the public and the millions of orgs that have made dot org their home online for the last 15 years. Specific questions should include:

  1. Are the stewardship measures proposed for the new PIR sufficient to protect the interests of the dot org community? What is missing?
  2. What level of scope, authority and independence will the proposed Stewardship Council possess? Will dot org stakeholders have opportunities to weigh in on the selection of the Council and development of its bylaws and its relationship to PIR and Ethos?
  3. What assurances can the dot org community have that Ethos and PIR will keep their promises regarding price increases? Will there be any remedy if these promises are not kept?
  4. What mechanisms does PIR currently have in place to implement measures to protect free speech and other rights of domain holders under its revised contract, and will those mechanisms change in any way with the transfer of ownership and control? In particular, how will PIR handle requests from government actors?
  5. When is the planned incorporation of PIR as a B corp? Are there any repercussions for Ethos and/or PIR if this incorporation does not take place?
  6. What guarantees are in place to retain the unique character of the dot org as a home for non-commercial organizations, one of the important stewardship promises made by PIR when it was granted the registry?
  7. Did ISOC receive multiple bids for PIR? If yes, what criteria in addition to price were used to review the bids? Were the ICANN criteria originally applied to dot org bidders in 2002 considered? If no, would ISOC consider other bids should the current proposal be rejected?
  8. How long has Ethos committed to stay invested in PIR? Are there measures in place to ensure continued commitment to the answers above in the event of a resale?
  9. What changes to ICANN’s agreement with PIR should be made to ensure that dot org is maintained in a manner that serves the public interest, and that ICANN has recourse to act swiftly if it is not?

In terms of process, ICANN needs to approve or reject the transfer of control over the dot org contract. And, presumably, the ISOC board has the power to go back and ask further questions about the deal before it is finalized. We urge these groups to step up to ask questions like the ones above — and not finalize the deal until they and a broad cross section of the dot org community are satisfied with the answers. As they address these questions, we urge them to post their answers publicly.

Also, the state attorneys general of the relevant jurisdictions may be in a position to ask questions about the conversion of PIR into a for profit or about whether ISOCs sale of PIR represents fair market value. If they feel these questions are in their purview, we urge them to share the results of their findings publicly.

One of Mozilla’s principles is the idea that “a balance between commercial profit and public benefit is critical” to maintaining a healthy internet. Yes, much of the internet is and should be commercial — but it is important that significant parts of the internet also remain dedicated to the public interest. The current dot org ecosystem is clearly one of these parts.

The organization that maintains the underpinnings of this ecosystem needs to be a fair and responsible steward. One way to ensure this is to entrust this role to a publicly accountable non-profit, as ICANN did when it picked ISOC as a steward in 2002. While it’s also possible that a for-profit company could effectively play this stewardship role, extra steps would need to be taken to ensure that the company is accountable to dot org stakeholders and not just investors, now and for the long run. It is urgent that we take such steps if the sale of PIR is to go through.

A small postscript: We have sent a letter to ICANN encouraging them to ask the questions above.

The post Questions About .org appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

Firefox Preview Beta reaches another milestone, with Enhanced Tracking Protection and several intuitive features for ease and convenience

Mozilla Futurereleases - di, 03/12/2019 - 15:00

In June we made an announcement, that left us — just like many of our users — particularly excited: we introduced Firefox Preview, a publicly available test version of our upcoming best in class browser for Android that will be fueled by GeckoView. GeckoView is Mozilla’s own high-performance mobile browser engine, which enables us to deliver an even better, faster and more private Firefox to Android device owners. Hundreds of thousands of users have downloaded and tested Firefox Preview since it became available.

Over the past 5 months we’ve been working diligently on improvements to the app. We’ve been listening closely to user feedback and are basing app development on users’ requests and needs; one very recent example is our support for extensions through the WebExtensions API. We will still continue to test Firefox Preview Beta and we’re expecting to launch as a final product in the first half of 2020. Today, we want to provide an update on our progress, and share some of the amazing new features we’ve added to Firefox Preview since the beta release of 1.0.

Please note: The rollout of Firefox Preview Beta 3.0 is currently delayed. The newest features, such as Site Protections, will be made available within the next couple of days. Thanks for your patience.

Browse the web conveniently on mobile with privacy by default

At Firefox, we foster user choice and individual decision making. However, we’ve noticed the massive change the internet economy has undergone over the last couple of years. This transformation has distorted the value exchange between online businesses, the ad industry in particular, and users. It is no longer transparent and consumers are being taken advantage of more and more. We want a better web for people. One that puts users first while still being fast, performant and, above all, private and secure. Still, we can’t expect every user to become an expert on these topics in order to protect themselves. That’s why we’re now making next-level privacy protections the default instead of an option for only the tech-savvy.

This is a guiding principle for the whole Firefox product family and it’s why we’re now taking Firefox Preview to the next level by equipping it with Enhanced Tracking Protection, an innovative technology we first introduced in Firefox for desktop earlier this year, and have been improving ever since. Enhanced Tracking Protection is our approach to put users back in control of their online life by stopping third-party tracking cookies from following them around on the web.

When mapping out how to implement this feature in the next Firefox for Android, we took the distinct use-cases for mobile and desktop into account. On the phone or tablet, most users care much more about performance and blocking of annoyances compared to desktop. Users are more forgiving when a site doesn’t load exactly like it’s meant to. So we decided that while Firefox for desktop’s default mode is “Standard”, Firefox Preview will use “Strict” mode. “Standard” prevents third-party trackers from (re)using cookies to identify a user while still allowing the trackers to run on the site, “strict” actually blocks the trackers, which makes the browser up to 20% percent faster. Users will no longer face ad banners that contain trackers and therefore have a rather uninterrupted browsing experience, though there is a chance that some website content may not work. If users prefer to avoid that they can always switch to “Standard” mode with just 3 taps or turn off Enhanced Tracking Protection with only 2 taps.

Enhanced Tracking Protection in Firefox Preview defaults to “Strict” mode, blocking tracking cookies and trackers for stronger protection and enhanced performance.

We’re looking forward to hearing what users think about Enhanced Tracking Protection on mobile as well as these additional new features in Firefox Preview:

      • Firefox Site Protections: Only recently, we introduced the Privacy Protection report to Firefox for desktop, which brings more visibility into how users are being tracked online so they can better combat it. On mobile, we decided to implement an abbreviated version. When tapping on the shield icon, users can now see the type of trackers, such as third-party trackers, social media trackers or cryptominers, that Firefox Preview blocks for them on each site. Another tap on the individual categories then opens a list of the trackers blocked for additional transparency.
      • Adding and customizing a Search Widget: Users who want to be prepared to do a web search really quickly can add the Firefox Preview Search Widget to their Android home screen, so they don’t have to open the app first anymore: just long-press on the Firefox Preview icon on the home screen, tap on the widget icon, then add it. User can also easily choose their preferred search engine and resize the widget to make it fit their needs and taste.
      • Getting organized with our Send Tab: No need to spam one’s own email folder again with links intended to use on another device! Firefox account holders can now send a tab or a collection of tabs from their Android phone or tablet to any other device they’ve logged into with their Firefox account.

Firefox Preview makes mobile browsing convenient: with intuitive search widgets and easy tab sharing between your devices.

 

Help us shape the mobile product that puts users in control of their digital life again

We’re excited to see Firefox Preview develop further and can’t wait to share out what the final product will look like! In the meantime, we continue to welcome more testers to Firefox Preview and look forward to hearing more of users’ feedback. All the features described above, plus everything else we recently added to our new mobile browser, has been picked, prioritized and added based on what our users requested. This has been our approach, especially in the mobile sphere, for many years and we’re planning to maintain it: not only is feedback immensely important for us in order to improve our products before their actual launch and during further development; we also want to make sure to deliver exactly what users need and demand. They can help surface what that is and shape our new mobile product. So, download Firefox Preview now and let us know what you think!

And in the spirit of the upcoming holiday season: thanks to the whole Firefox community for your support!

 

 

The post Firefox Preview Beta reaches another milestone, with Enhanced Tracking Protection and several intuitive features for ease and convenience appeared first on Future Releases.

Categorieën: Mozilla-nl planet

News from Firefox on Mobile, Private Network and Desktop

Mozilla Blog - di, 03/12/2019 - 15:00

As the year comes to a close, we look back at what we’ve accomplished. As recently noted in the press, this year may be the mark of our privacy-renaissance. We’ve built additional privacy protections in the browser which included blocking third party tracking cookies and cryptomining by default and created an easy-to-view report which shows the trackers that follow you and collect your online browsing habits and interests. To date, we’ve blocked more than 1 Trillion tracking requests that attempt to follow you around the web! Privacy has always been part of our DNA. We’ve always believed our role is and has always been to help give people more control over their online lives.

1 Trillion tracking requests have been blocked with Enhanced Tracking Protection

Today, we’ve got something for everyone, for tech savvy folks who want to test-drive privacy-first features and products or those who love to multitask while on their desktop. We have a lot in store for the next year, and will continue to uphold our promise to create privacy-focused products and features. Before we roll anything out widely to consumers, we’ve still got some fine-tuning to do. So today we’re kicking off the next phase in our ongoing testing of our Firefox Private Network Beta, and the latest Firefox Preview app for Android powered by GeckoView. Although the year might be winding down, just like Santa’s elves, we’re working around the clock to deliver experiments and the latest versions of our Firefox browser for desktop and iOS.

Latest Firefox Private Network Beta test protects users just in time for the holidays

In September, we introduced the beta release of our Firefox Private Network (FPN), an extension which provides a secure, encrypted path to the web to protect your connection and personal information when you use the Firefox browser. Since then, we’ve received feedback from our beta testers on how they’re using FPN, its protections, and we learned about websites that weren’t compatible as well as connection issues. This allowed us to quickly identify and fix bugs, and ensure a stable product.

As we continue our beta testing, we are considering various ways to bring additional privacy protections to our users. Today we’re announcing an additional beta test for US-based Firefox account users who didn’t get a chance to get in the initial group, and are interested in testing FPN.

In the next phase of our beta, we are offering a limited-time free service that lets you encrypt your Firefox connections for up to 12 hours a month. With the holidays around the corner, the FPN couldn’t come at a more convenient time. We know people are traveling and might have to rely on an unsecured public Wi-Fi network, like the one at the airport, at your local coffee shop, or even at your doctor’s office. FPN provides encrypted internet traffic thus giving you peace of mind whenever you’re using our browser.

This limited-time free service is currently available in the US on the Firefox desktop browser and you’ll need a Firefox account to try the service. You can sign up directly from the extension which can be found here.

For those looking to extend their protection beyond the browser, you can now sign up to be one of the first to experience the newest member of the FPN family. This month, Firefox account holders can request invitations to experience device-level protection with our new full-device VPN (virtual private network). Join the waitlist and if you’re eligible, we’ll follow up with a link to access the VPN at an introductory price of $4.99 per month. Currently the VPN will be available for Windows 10 only, and like the rest of the FPN, it is only available to US-based Firefox account holders. Pricing and platform availability will continue to evolve and we look forward to hearing your feedback.

Attention mobile beta testers: Firefox Preview Beta release now available

This past summer we introduced Firefox Preview Beta, a publicly available test version of our Firefox browser for Android powered by GeckoView, Mozilla’s own high-performance mobile browser engine. It allows us to deliver a better, faster and more private online experience for Android users. Today, we have an update on our progress, including new features we’ve added since its initial beta release in June. To learn more visit the announcement here.

Picture-in-Picture available in today’s Firefox browser release

Let’s face it, we’re all guilty of multi-tasking whether it’s checking email in a meeting or online shopping and watching product videos before we press the buy button. We all have busy lives and want to get the most out of every minute. In today’s Firefox release we’re rolling out Picture-in-Picture available in all video sites.

Picture-in-Picture allows a video to be contained in a separate and small window, and still be viewable whether you switch from tab-to-tab or outside the Firefox browser. To see if Picture-in-Picture is available to you, hover your mouse over the video to see a small blue “Picture in Picture” option. Once you click the option, the video will pop into its own and will always stay as the top window, allowing you to continue to watch the video even if you switch tabs. Currently, Picture-in-Picture will only be available on Windows OS. It will be available to MacOS and Linux in our next browser release in January 2020.

Hover your mouse over the video to see a small blue “Picture in Picture” option

To see what else is new or what we’ve changed in today’s desktop and iOS release, you can check out our release notes.

Check out and download the latest version of Firefox available here.

 

The post News from Firefox on Mobile, Private Network and Desktop appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

Mozilla and the Contract for the Web

Mozilla Blog - do, 28/11/2019 - 21:42

Mozilla supports the Contract for the Web and the vision of the world it seeks to create. We participated in helping develop the content of the principles in the Contract. The result is language very much aligned with Mozilla, and including words that in many cases echo our Manifesto. Mozilla works to build momentum behind these ideas, as well as building products and programs that help make them real.

At the same time, we would like to see a clear method for accountability as part of the signatory process, particularly since some of the big tech platforms are high profile signatories. This gives more power to the commitment made by signatories to uphold the Contract about privacy, trust and ensuring the web supports the best in humanity.

We decided not to sign the Contract but would consider doing so if stronger accountability measures are added. In the meantime, we continue Mozilla’s work, which remains strongly aligned with the substance of the Contract.

The post Mozilla and the Contract for the Web appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

Wladimir Palant: Internal Kaspersky API exposed to websites

Mozilla planet - di, 26/11/2019 - 10:06

In December 2018 I discovered a series of vulnerabilities in Kaspersky software such as Kaspersky Internet Security 2019. Due to the way its Web Protection feature is implemented, internal application functionality can used by any website. It doesn’t matter whether you allowed Kaspersky Protection browser extension to be installed, Web Protection functionality is active regardless and exploitable.

Kaspersky's communication with the browser protected by an easy to find key

Note: This is the high-level overview. If you want all the technical details you can find them here.

Table of Contents What does Web Protection do?

Indicating benign and malicious search results is a common antivirus feature by now, and so it is part of the Web Protection feature in Kaspersky applications. In addition, functionality like blocking advertising and tracking is included, as well as a virtual keyboard as a (questionable) measure to protect against keyloggers.

URL Advisor pop-up on a link

The issue

In order to do its job, Web Protection needs to communicate with the main Kaspersky application. In theory, this communication is protected by a “signature” value that isn’t known to websites. In practice however, websites can find the “signature” value fairly easily. This allows them to establish a connection to the Kaspersky application and send commands just like Web Protection would do.

As of December 2018, websites could use this vulnerability for example to silently disable ad blocking and tracking protection functionality. They could also do quite a few things where the impact wasn’t quite as obvious, I didn’t bother investigating all of them.

The fix that made things worse

Initially, Kaspersky declared the issue resolved in July 2019 when the 2020 family of their products was released. Unexpected to me, preventing websites from establishing a connection to the application wasn’t even attempted here. Instead, parts of the functionality were rendered inaccessible to websites. Which parts? The ones I used to demonstrate the vulnerabilities: completely disabling ad blocking and tracking protection.

Other commands would still be accepted and I immediately pointed out that websites could still disable ad blocking on their own domain. They could also attempt to add ad blocking rules, something that the user still had to confirm however.

Confirmation pop-up showing when a blocking filter is added

Also, new issues showed up which weren’t there before. Websites could now gather lots of information about the user’s system, including a unique user identifier which could be used to recognize the user even across different browsers on the same system.

Various pieces of information leaked by Kaspersky API

And last but not least, the fix introduced a bug that allowed websites to trigger a crash in the antivirus process! So websites could make the antivirus shut down and leave the system completely unprotected.

Message displayed by Kaspersky when restarted after a crash

Further fix attempts

The next fix came out as Patch E for the 2020 family of Kaspersky products. It moved configuring ad blocking functionality into the “not for websites” section, and it would no longer leak data about the user’s system. The crash was also mostly fixed. As in: under some circumstances, antivirus would still crash. At least it doesn’t look like websites can still trigger it, only browser extensions or local applications.

So another patch will become available this week, and this time the crash will hopefully be a thing of the past. One thing won’t change however: websites can still send commands to Kaspersky applications. Is all the functionality they can trigger there harmless? I wouldn’t bet on it.

Categorieën: Mozilla-nl planet

This Week In Rust: This Week in Rust 314

Mozilla planet - di, 26/11/2019 - 06:00

Hello and welcome to another issue of This Week in Rust! Rust is a systems language pursuing the trifecta: safety, concurrency, and speed. This is a weekly summary of its progress and community. Want something mentioned? Tweet us at @ThisWeekInRust or send us a pull request. Want to get involved? We love contributions.

This Week in Rust is openly developed on GitHub. If you find any errors in this week's issue, please submit a PR.

Updates from Rust Community News & Blog Posts #Rust2020

Find all #Rust2020 posts at Read Rust.

Crate of the Week

This week's crate is rerast, a rule-based Rust code transformation tool.

Thanks to Jan Riemer for the suggestions!

Submit your suggestions and votes for next week!

Call for Participation

Always wanted to contribute to open-source projects but didn't know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!

Some of these tasks may also have mentors available, visit the task page for more information.

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

Updates from Rust Core

260 pull requests were merged in the last week

Approved RFCs

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

No RFCs were approved this week.

Final Comment Period

Every week the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.

RFCs

No RFCs are currently in final comment period.

Tracking Issues & PRs New RFCs Upcoming Events Online Africa Asia Pacific Europe North America

If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access.

Rust Jobs

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

Quote of the Week

I said it before, and I'll say it again: If one views Rust as a critique on C++, one should view it as a constructive critique.

llogiq on /r/rust

Thanks to Dmitry Kashitsyn for the suggestion!

Please submit quotes and vote for next week!

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

Discuss on r/rust.

Categorieën: Mozilla-nl planet

About:Community: Firefox 71 new contributors

Mozilla planet - ma, 25/11/2019 - 16:00

With the release of Firefox 71, we are pleased to welcome the 38 developers who contributed their first code change to Firefox in this release, 31 of whom were brand new volunteers! Please join us in thanking each of these diligent and enthusiastic individuals, and take a look at their contributions:

Categorieën: Mozilla-nl planet

Mozilla Open Policy & Advocacy Blog: Disconnecting the Connected: How Regulatory and Tax Treatment of Over-the-Top-Services in Africa Creates Barriers for Internet Access.

Mozilla planet - ma, 25/11/2019 - 10:37

Mozilla and the African Union Commission (AUC)  released a new study examining the misconceptions, challenges and real-life impact of additional taxes on Over the Top Services (OTTs) imposed by governments across the African continent. The Regulatory Treatment of OTTs in Africa study found that these taxation regimes – often imposed without public consultation and impact assessments – have increased barriers to access, pushed people offline, and limited access to information, and access to services. The study conducted the analysis based on the available evidence and a select number of case studies.

These regressive regulatory measures are taking place as governments rush to introduce digital transformation initiatives, and instead of focusing on how to connect more people to the internet, the region is building barriers that keep them off it.

The study examined the 2018 Ugandan government excise duties which included a mobile money tax of 1% on the transaction value of payments, transfers and withdrawals increasing mobile money fees from 10% to 15% and a new levy on more than 60 online platforms, including Facebook, WhatsApp, and Twitter that amounted to 200 Ugandan Shillings ($0.05) per day. The impact was immediate: the estimated number of internet users in Uganda dropped by nearly 30% between March and September 2018. But the impact is far wider than just the number of lost internet users. An initial estimate in August 2018 was that Uganda had forgone 2.8% in economic growth and 400 billion Ugandan shillings in taxes.

These types of sector-specific taxes pose a considerable threat to internet access and affordability for all users, but especially low income and marginalised people. Internet costs in Uganda are already prohibitively high. Uganda’s gross domestic product (GDP) per capita per day, is currently at 7,000 Ugandan shillings ($1.90), and many live off less. Paying 1,000 Ugandan shillings per day for internet data of 50 megabytes and an additional 200 shillings tax is a major challenge. 200 Ugandan shillings ($0.05), is a kilogram of maize in Uganda.

The study further dives into the misconceptions that have contributed to the rise of these types of taxes across the region. The fundamental misunderstanding of the impact of social media on the Internet value chain, and the lack of a clear definition of OTTs has made evidence-based discussions about the impact of OTTs difficult. As a result of these misconceptions, regulatory interventions have used unsuitable tools and have been carried out by the wrong organisations.

Moctar Yedaly, Head of Information Society Division of the African Union Commission (AUC) noted that this study is “a good starting point for understanding the nuances of the impact of OTTs on the ICT ecosystem. We hope that it will lead to regional discussions that would consider more progressive and productive digital taxation models, appropriate policies and regulatory frameworks.”

Finally, the study proposes best practices to help governments create an efficient taxation system while balancing the objectives of collecting taxes, and economic growth, job creation and inclusion of the poor into the information society.

Mozilla and the African Union Commission will continue to engage and support regional discussions, including policy and regulatory efforts, in line with the “Specialized Technical Committee on Communications and Information Technologies (STC-CICT) 3, 2019 declaration, which calls on the AUC to “develop guidelines on Privacy and Over The Top Services in collaboration with relevant institutions and submit the guidelines to the STC-CICT 4 in 2021”.

The post Disconnecting the Connected: How Regulatory and Tax Treatment of Over-the-Top-Services in Africa Creates Barriers for Internet Access. appeared first on Open Policy & Advocacy.

Categorieën: Mozilla-nl planet

Wladimir Palant: Kaspersky: The art of keeping your keys under the door mat

Mozilla planet - ma, 25/11/2019 - 09:52

Kaspersky’s web protection feature will block ads and trackers, warn you about malicious search results and much more. The complication here: this functionality runs in the browser and needs to communicate with the main application. For this communication to be secure, an important question had to be answered: under which doormat does one put the keys to the kingdom?

Kaspersky's communication with the browser protected by an easy to find key

Note: Lots of technical details ahead. If you only want a high-level summary, there is one here.

This post sums up five vulnerabilities that I reported to Kaspersky. It is already more than enough ground to cover, so I had to leave unrelated vulnerabilities out. But don’t despair, there is a separate blog post discussing those.

Table of Contents Summary of the findings

In December 2018 I could prove that websites can hijack the communication between Kaspersky browser scripts and their main application in all possible configurations. This allowed websites to manipulate the application in a number of ways, including disabling ad blocking and tracking protection functionality.

Kaspersky reported these issues to be resolved as of July 2019. Yet further investigation revealed that merely the more powerful API calls have been restricted, the bulk of them still being accessible to any website. Worse yet, the new version leaked a considerable amount of data about user’s system, including a unique identifier of the Kaspersky installation. It also introduced an issue which allowed any website to trigger a crash in the application, leaving the user without antivirus protection.

Why is it so complicated?

Antivirus software will usually implement web protection via a browser extension. This makes communication with the main application easy: browser extensions can use native messaging which is trivial to secure. There are built-in security precautions, with the application specifying which browser extensions are allowed to connect to it.

Firefox asking the user to enable Kaspersky extension

But browser extensions are not the only environment to consider here. If the user declines installing their browser extension, Kaspersky software doesn’t simply give up. Instead, it will inject the necessary scripts into all web pages directly. This works even on HTTPS sites because, as we’ve seen earlier, Kaspersky will break up HTTPS connections in order to manipulate all websites.

In addition, there is the Internet Explorer add-on which is rather special. With Internet Explorer not providing proper extension APIs, that add-on is essentially limited to injecting scripts into web pages. While this doesn’t require manipulating the source code of web pages, the scripts still execute in the context of these pages and without any special privileges.

So it seems that the goal was to provide a uniform way for these three environments to communicate with the Kaspersky application. Yet in two of these environments Kaspersky’s scripts have exactly the same privileges as the web pages that they have been injected into. How does one keep websites from connecting to the application using the same approach? Now you can hopefully see how this task is challenging to say the least.

Kaspersky’s solution

Kaspersky developers obviously came up with a solution, or I wouldn’t be writing this now. They decided to share a secret between application and the scripts (called “signature” in their code). This secret value has to be provided when establishing a connection, and the local server will only respond when receiving the correct value.

How do extensions and scripts know what the secret is? Chrome and Firefox extensions use native messaging to retrieve it. As for the Internet Explorer extension and scripts that are injected directly into web pages, here it becomes part of the script’s source code. And since websites cannot download that source code (forbidden by same-origin policy), they cannot read out the secret. At least in theory.

Extracting the secret

When I looked into Kaspersky Internet Security 2019 in December last year, their web integration code was leaking the secret in all environments (CVE-2019-15685). It didn’t matter which browser you used, it didn’t matter whether you had browser extensions installed or not, every website could extract the secret necessary to communicate with the main Kaspersky application.

From injected scripts

As mentioned earlier, without a browser extension Kaspersky software will inject its scripts directly into web pages. Now JavaScript is a highly dynamic execution environment, it can be manipulated almost arbitrarily. For example, a website could replace the WebSocket object by its own and watch the script establish the connection to the local server. Of course, Kaspersky developers have thought of this scenario, so they made sure their script runs before any of the website scripts do. It will also make a copy of the WebSocket object and only use that copy then.

Yet this approach is far from being watertight. For example, the website can simply make sure that the same script executes again, this time in a manipulated environment. It needs to know the script URL for that, but it can download itself and extract the script URL from the response. Here is how I’ve done it:

fetch(location.href).then(response => response.text()).then(text => { let match = /<script\b[^>]*src="([^"]+kaspersky[^"]+\/main.js)"/.exec(text); if (!match) return; let origWebSocket = WebSocket; WebSocket = function(url) { let prefix = url.replace(/(-labs\.com\/).*/, "$1"); let signature = /-labs\.com\/([^\/]+)/.exec(url)[1]; alert(`Kaspersky API available under ${prefix}, signature is ${signature}`); }; WebSocket.prototype = origWebSocket.prototype; let script = document.createElement("script"); script.src = match[1]; document.body.appendChild(script); }); From Internet Explorer extension

The Internet Explorer extension puts the bar slightly higher. While the scripts here also run in an environment that can be manipulated by the website, their execution is triggered directly by the extension. So there is no script URL that the website can find and execute again.

On the other hand, the script doesn’t keep a copy of every function it uses. For example, String.prototype.indexOf() will be called without making sure that it hasn’t been manipulated. No, this function doesn’t get to see any secrets. But, as it turns out, the function calling it gets the KasperskyLabs namespace passed as first parameter which is where all the important info is stored.

let origIndexOf = String.prototype.indexOf; String.prototype.indexOf = function(...args) { let ns = arguments.callee.caller.arguments[0]; if (ns && ns.SIGNATURE) alert(`Kaspersky API available under ${ns.PREFIX}, signature is ${ns.SIGNATURE}`); return origIndexOf.apply(this, args); }; From Chrome and Firefox extensions

Finally, there are Chrome and Firefox extensions. Unlike with the other scenarios, the content scripts here execute in an independent environment which cannot be manipulated by websites. So these don’t need to do anything in order to avoid leaking sensitive data, they merely shouldn’t be actively sending it to web pages. And you already know how this turns out: the Chrome and Firefox extensions leak API access as well.

The attack here abuses a flaw in the way content scripts communicate with frames they inject into pages. The URL Advisor frame is easiest to trigger programmatically, so this attack has to be launched from an HTTPS website with a host name like www.google.malicious.com. The host name starting with www.google. makes sure that URL Advisor is enabled and considers the following HTML code a search result:

<h3 class="r"><a href="https://example.com/">safe</a></h3>

URL Advisor will add an image next to that link indicating that it is safe. When the mouse is moved over that image a frame will open with additional details.

URL Advisor frame showing next to a link

And that frame will receive some data to initialize itself, including a commandUrl value which is (you guessed it) the way to access Kaspersky API. Rather than using the extension-specific APIs to communicate with the frame, Kaspersky developers took a shortcut:

function SendToFrame(args) { m_balloon.contentWindow.postMessage(ns.JSONStringify(args), "*"); }

I’ll refer to what MDN has to say about using window.postMessage in extensions, particularly about using “*” as the second parameter here:

Web or content scripts can use window.postMessage with a targetOrigin of "*" to broadcast to every listener, but this is discouraged, since an extension cannot be certain the origin of such messages, and other listeners (including those you do not control) can listen in.

And that’s exactly it – even though this frame was created by extension’s content script, there is no guarantee that it still contains a page belonging to the extension. A malicious webpage can detect the frame being created and replace its contents, which allows it to listen in on any messages sent to this frame. And frame creation is trivial to trigger programmatically with a fake mouseover event.

let onMessage = function(event) { alert(`Kaspersky API available under ${JSON.parse(event.data).commandUrl}`); }; let frameSource = `<script>window.onmessage = ${onMessage}<\/script>`; let observer = new MutationObserver(list => { for (let mutation of list) { if (!mutation.addedNodes || !mutation.addedNodes.length) continue; let node = mutation.addedNodes[0]; if (node.localName == "img") node.dispatchEvent(new MouseEvent("mouseover")); else if (node.localName == "iframe") node.src = "data:text/html," + encodeURIComponent(frameSource); } }); observer.observe(document, {childList: true, subtree: true});

This scenario is slightly different from the two presented earlier: commandUrl doesn’t contain the signature value necessary to connect to the application. It contains the ajaxId and sessionId values however (explained in the next section), so it allows sending commands via an already established session.

Doing some damage

There isn’t technically a local web server running here but rather Kaspersky software messing with all internet connections. It will answer requests to kis.v2.scr.kaspersky-labs.com subdomain directly, to provide its API among other things. That API can be accessed both via WebSockets and via AJAX calls. I’ll stick to the latter because it is easier to demonstrate.

Once the “signature” is known, any website can initiate a session by loading an address like https://ff.kis.v2.scr.kaspersky-labs.com/<SIGNATURE>/init?url=https://www.google.com/. Here, the prefix ff is specific to Firefox, it will be gc in Chrome, me in Edge and ie in Internet Explorer. We are claiming to be a script injected into https://www.google.com/, but that doesn’t really matter. What we get as response is lots of JSON data:

Response to init command containing ajaxId and sessionId values

The important values here are ajaxId and sessionId, you need these to call further commands. Anything goes that the browser extensions are capable of, for example disabling ad blocking and tracking protection functionality. These features being there to protect users, having websites disable such functionality is obviously bad which is why my initial proof-of-concept pages did just that. You first have to connect to the light_popup plugin:

POST /14B5494F-B7D9-3144-8889-C542E89DC9EC/E039014D-D6B8-1C40-82CA-4670F4165F27/to/light_popup.connect HTTP/1.1 Host: ff.kis.v2.scr.kaspersky-labs.com Content-Length: 60 {"result":0,"method":"light_popup.connect","parameters":[1]}

And then send the actual command to silently disable tracking protection:

POST /14B5494F-B7D9-3144-8889-C542E89DC9EC/E039014D-D6B8-1C40-82CA-4670F4165F27/to/light_popup.command HTTP/1.1 Host: ff.kis.v2.scr.kaspersky-labs.com Content-Length: 86 {"result":0,"method":"light_popup.command","parameters":["dnt","EnableDntTask",false]}

Parameters ["ab", "EnableAntiBannerTask", false] would similarly disable ad blocking functionality.

But that’s not all of it of course, there is a whole lot of functionality being controlled here. For example, you can show or hide the virtual keyboard. You can mess with internal statistics and other data. Or you can add the filter * to the advertising blocklist, which unlike the other actions at least requires the user to confirm it.

Confirmation pop-up showing when a blocking filter is added

If the user isn’t careful and just accepts this prompt, the web will be broken for them without an obvious way to fix it. And all of that might be only the tip of the iceberg: if internals of an application are exposed to arbitrary websites, any vulnerabilities hidden there are exposed as well.

All fixed?

In July 2019 Kaspersky notified me about all issues being resolved. However, when I tried the new Kaspersky Internet Security 2020, extracting the secret from injected scripts was still trivial and the main challenge was adapting my proof-of-concept code to changes in the API calling convention. Frankly, I cannot blame Kaspersky developers for not even trying – I think that defending their scripts in an environment that they cannot control is a lost cause.

Somewhat more surprising finding: the communication between content scripts and frames in Chrome and Firefox extensions, something that would have been trivial to fix, didn’t change at all. My proof-of-concept page could still connect to the Kaspersky API without any changes. Not that this really matters: due to the way Kaspersky addressed the privacy issue reported by Heise Online, the injected script was now available under a fixed address. So even if a browser extension is active and not vulnerable, a malicious website can always load and exploit that script.

Actual changes

It appears that rather than giving up on storing secrets in insecure environments, Kaspersky developers have given up on protecting access to their API. All changes I noticed are merely mitigating the issue. In particular:

  • When connecting to the API, a script can no longer claim to originate from any URL – the application will now validate that the URL matches the Origin HTTP header. This check is only bypassed if Origin header is missing, when origin is null in Internet Explorer or moz-extension:// in Firefox.
  • Commands provided by the light_popup plugin (so in particular enabling/disabling ad blocking and tracking protection functionality) are now only available to scripts originating from about:blank, moz-extension:// and chrome-extension:// (extension pop-ups in Internet Explorer, Firefox and Chrome extensions respectively).

As far as I can tell, these restrictions can only be circumvented in some edge cases. For example, in Firefox 64 and below it was possible to avoid sending Origin header. Origin null in Internet Explorer applies to local files and only those it seems. So any local file could circumvent the restrictions, but these usually aren’t even allowed to run JavaScript code without an additional confirmation. Other than that, any Chrome or Firefox extension could circumvent these restrictions, and any application installed locally of course.

What’s left to be exploited

These provisions really only manage to restrict access to light_popup functionality. Other functionality cannot be locked in the same way because it is used by injected scripts as well, not merely browser extensions. So web pages can no longer disable ad blocking functionality altogether, but they can still call abn.SetBlockStatus command to silently add themselves to the whitelist (CVE-2019-15686).

Also, websites can no longer disable tracking protection. But the response to the init command now contains a value called AntiBannerHelpUrlSettings which contains all kinds of identifying information about the user (CVE-2019-15687). Meant for Kaspersky support of course, but now any website can read it.

Various pieces of information leaked by Kaspersky API

Not to mention that Kaspersky still gives websites access to internals of their application. I didn’t expect delivering proof that it was a bad idea, but I stumbled upon an issue accidentally.

Making it crash

Turns out, Kaspersky developers introduced a bug when they added origin checks. Passing an invalid URL when initiating a session caused the application to crash, with roughly a minute delay (CVE-2019-15686). Let me repeat this: that’s the antivirus application being crashed by an arbitrary website, leaving your system without any antivirus protection whatsoever. And even if the application is restarted, which sometimes happens automatically, its web protection component won’t work any more – this one requires the browser to be restarted as well.

Message displayed by Kaspersky when restarted after a crash

What happens here? The webpage tries to load https://ff.kis.v2.scr.kaspersky-labs.com/<SIGNATURE>/init?url=ha!. When processing this request, the application parses the URL specified here and tries to copy the origin part from it. It does that by copying the part from the start of the URL to the end of the host name. Except: there is no host name here, the corresponding member of the structure being a null pointer. This makes the application allocate a huge memory buffer for the copy result (pointer difference as an unsigned integer), and if it is lucky memory allocation fails – the application can deal with the resulting exception. Usually however, the memory allocation succeeds and the application starts copying data. Eventually, it hits an unassigned memory area and crashes with an out-of-bounds read error.

Now I’m not an expert on memory safety errors. While this article lists “corruption of sensitive information” and “code execution” as potential impact of such vulnerabilities, I don’t really see how this could happen here. To my untrained eye, this issue facilitates denial-of-service attacks, nothing else. And that is bad enough already.

Second round of fixes

A few weeks ago Kaspersky once again notified me about the issues being resolved. As expected, the access to their API hasn’t really been restricted. Even in the scenario where the browser extension is installed, the insecure communication between content script and frame is still in place. So websites can still connect to the Kaspersky application.

What apparently changed: disabling anti-banner functionality on a website moved into the light_popup plugin which cannot be used by websites. So the impact has been reduced further. The response to the init call changed as well, it no longer exposes any private data.

And what about that crash? It no longer happens. Unless you pass a value like http:/// which is a valid address with an empty host name, that will still crash. Luckily, this only happens when the origin check is bypassed, so websites shouldn’t be able to trigger that crash any more – only local applications or browser extensions. According to Kaspersky, the remaining issue here will be resolved with another patch, to become available in a few days.

Altogether, the fixes don’t give me a good feeling. Close to a year after the initial reports, the root issues here remain unaddressed, Kaspersky merely working on containing the damage.

Conclusions

As long as Kaspersky developers insist on injecting scripts into web pages as a fallback for the scenario where the user rejected installing their extensions, protecting access to their internal API seems to be a lost cause. They appear to have come to the same conclusion, so they don’t even try. Instead, they try to protect the more powerful API calls which are used exclusively by browser extensions. This still leaves way too much functionality accessible to web pages however.

Especially the out-of-bounds read vulnerability is troubling. This particular vulnerability “only” seems to have the potential to crash the application, something that leaves users without antivirus protection. But I noticed large chunks of code using data structures without built-in memory safety there. Much of that code is accessible to web pages, thanks to the issues described here, and it is reasonable to expect more memory safety issues to pop up.

By now I’ve looked into a bunch of other antivirus solutions already (F-Secure, McAfee, Norton, Avast/AVG). All of them rely exclusively on browser extensions for the “web protection” component. Maybe Kaspersky is so attached to scripts injected directly into web pages because these are considered a distinguishing feature of their product, it being able to do its job even if users decline to install extensions. But that feature also happens to be a security hazard and doesn’t appear to be reparable. So I can only hope that they will eventually come around and get rid of it.

Timeline
  • 2018-12-21: Sent three reports on API hijacking via Kaspersky bug bounty program: affecting injected scripts, Internet Explorer extension and Chrome/Firefox extension respectively.
  • 2018-12-24: Kaspersky confirmed the vulnerabilities and stated that they were working on a fix.
  • 2019-07-29: Kaspersky marked the issues as resolved.
  • 2019-07-29: Requested the reports to be disclosed.
  • 2019-08-05: Kaspersky denied disclosure request, stating that users needed time to update from older versions. Additional discussion results in “around November” being given as a timeline.
  • 2019-08-19: Sent two more reports to Kaspersky via email: internal API still accessible to web pages and leaking private information, and denial-of-service attacks possible by passing invalid URLs. Disclosure deadline: 2019-11-25.
  • 2019-08-19: Notified Kaspersky that I plan to publish a blog post covering older issues on 2019-11-25.
  • 2019-08-19: Kaspersky confirmed receiving the new reports, promising further communication after the initial analysis is complete (that communication never happened).
  • 2019-08-23: Sent a follow-up email noting that the internal API can also be misused in various ways, such as manipulating ad blocking configuration.
  • 2019-11-07: Kaspersky notified me about the issues being resolved in 2019 (Patch I) as well as 2020 (Patch E) family of products.
  • 2019-11-15: Evaluated the fixes and notified Kaspersky about the incomplete crash fix.
  • 2019-11-20: Kaspersky notified me about an upcoming patch to fix the crash completely, supposed to become available by 2019-11-28.
Categorieën: Mozilla-nl planet

The Mozilla Blog: Mozilla and BMZ Announce Cooperation to Open Up Voice Technology for African Languages

Mozilla planet - ma, 25/11/2019 - 09:11

Mozilla and the German Ministry for Economic Cooperation and Development (BMZ) to jointly build new alliance to foster open voice data and technology in Africa and beyond

Berlin – 25 November 2019. Today, Mozilla and the German Ministry for Economic Cooperation and Development (BMZ) have announced to join forces in the collection of open speech data in local languages, as well as the development of local innovation ecosystems for voice-enabled products and technologies. The initiative builds on the pilot project, which our Open Innovation team and the Machine Learning Group started together with the organization “Digital Umuganda” earlier this year. The Rwandan start-up collects language data in Kinyarwanda, an African language spoken by over 12 million people. Further languages in Africa and Asia are going to be added.

Kelly Davis, Head of Mozilla’s Machine Learning Group, explaining the design and technology behind Deep Speech and Common Voice at a Hackathon in Kigali

Kelly Davis, Head of Mozilla’s Machine Learning Group, explaining the design and technology behind Deep Speech and Common Voice at a Hackathon in Kigali, February 2019.

Mozilla’s projects Common Voice and Deep Speech will be the heart of the joint initiative, which aims at collecting diverse voice data and opening up a common, public database. Mozilla and the BMZ are planning to partner and collaborate with African start-ups, which need respective training data in order to develop locally suitable, voice-enabled products or technologies that are relevant to their Sustainable Development Goals (SDGs). Mozilla and the BMZ are also inviting like-minded companies and identifying further countries interested in joining their efforts to open up language data.

The German Ministry and Mozilla share a similar vision and work towards the responsible use of automated decision-making and artificial intelligence for sustainable development on scale. Supporting partner countries in reaching the SDGs, today, the BMZ is carrying out more than 470 digitally enhanced projects in over 90 countries around the world. As part of the National Strategy for Artificial Intelligence, the Federal German Government has agreed to support developing countries in building up capacities and knowledge on opportunities and challenges of AI – an area of expertise that the Mozilla Foundation has heavily invested in with their work on trustworthy AI.

“Artificial Intelligence is changing and shaping our societies globally. It is critical that these technologies are both trustworthy and truly serve everyone. And that means they need to be developed with local needs and expertise in mind, diverse, decentralized, and not driven by monopolies,” says Mark Surman, Executive Director of the Mozilla Foundation.

“Innovating in AI poses complex technological, regulatory and ethical challenges. This is why I am very pleased to see multiple teams within Mozilla working together in this promising cooperation with the BMZ, building on our shared visions and objectives for a positive digital future,” adds Katharina Borchert, Chief Open Innovation Officer of the Mozilla Corporation.

The cooperation was announced at Internet Governance Forum (IGF) in Berlin and will be part of the BMZ initiative “Artificial Intelligence for All: FAIR FORWARD”. A Memorandum of Understanding (MoU) was signed at Mozilla’s headquarters in Mountain View on November 14.

Representatives of the BMz and Mozilla signing the Memorandom of Understanding

From left to right: Björn Richter, Head of Digital Development Sector Program, GIZ, Dr. Andreas Foerster, Head of Division Digital Technologies in Development Cooperation, BMZ, Katharina Borchert, Chief Open Innovation Officer, Mozilla, Ashley Boyd, VP, Advocacy Mozilla Foundation, and Udbhav Tiwari, Public Policy Advisor, Mozilla

Mozilla believes that the internet is a global public resource that must remain open and accessible for all people, no matter where they are and which language they speak. With projects such as Common Voice and Deep Speech, Mozilla’s Machine Learning Group is working on advancing and democratizing voice recognition technology on the web.

Useful Links:

The post Mozilla and BMZ Announce Cooperation to Open Up Voice Technology for African Languages appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

Pagina's