2022 was a busy year for AppEsteem. Here's what we accomplished:
- We moved forward with two new ACRs that affect the bundler industry: ACR-013 (which prevents interrupting install/uninstall/conversion with un-consented offers), and ACR-060 (which requires offers to disclose the offering network). These two ACRs are meant to reduce consumer confusion and dissatisfaction, and they will go into effect on April 1. You can read more about them, including the requirement, our intent, and our guidance, on our Requirements checklist.
- We took a stand against ad pollution by publishing pollution indicators, and publicly calling out our first set of ad polluters.
- We updated our browser safety consumer apps and services (available on Browse.live) by releasing Browse.live Ad Control, a free browser extension that blocks ads from ad polluters, and Browse.live Search, an ad-pollution-free, anonymous search engine.
- We called out hundreds of active Deceptors, and we certified hundreds of clean, consumer-respecting apps.
- We ran monthly tests against the main AV products to determine how good they were at blocking Deceptors and allowing certified apps.
Not bad for a year where we're mostly still working from home and postponing almost all customer visits.
In 2023, our mission won't change. We'll continue to help clean apps thrive by finding ways to protect consumers from getting tricked, scared, or fooled. Here's what we plan to focus on:
- We'll start enforcing the bundler ACRs (ACR-013 and ACR-060). We'll work to stop apps from violating these ACRs, including hunting for them, reaching out to them, and listing them on our active Deceptor list.
- We'll keep calling out Deceptors and Ad Polluters, so we can get them to clean up.
- We'll continue to expand our Browse.live consumer safety product line so that consumers can have safer and cleaner internet experiences.
- We'll look for more ways to encourage the AVs to better protect consumers, both on the system and in the browser. We'll do this with our feeds, our testing, our technology, and with releasing our own apps.
We're winning the fight against deceptive apps, and our clean ecosystem makes this possible. Thank you to our app makers who get their clean apps certified, our AV partners who use our Deceptor and Certified feeds to protect consumers, and our customers who use our Browse.live apps to make their internet experiences safer and cleaner.
Happy New Year from all of us at AppEsteem!
(Hong Jia and Dennis Batchelder)
We think that many AVs need to update their (potentially) unwanted software policies to make sure they can block apps that reduce security without first obtaining informed user consent. We gave a talk yesterday at AVAR 2022 in Singapore to make our case, show which AVs are currently struggling with protecting their customers against these apps, and ask them to update their policies so their customers can be better protected.
You can see the slides we used for the presentation here.
This was our abstract:
As Avs get better operationalized in their fight against unwanted software (UwS), their combined pressure is driving the software monetization industry toward finding the gaps in AV policies so they can continue to exploit consumers for easy money.
The big gap in AV policies these days, unfortunately, is around apps that make their computers more vulnerable to attacks. The result? A proliferation of apps that needlessly reduce their customers’ security postures and set them up for future attacks, without first obtaining informed user consent. Examples of these apps include VPNs that install self-signed trusted root certificates and free apps that monetize by installing proxies that share their internet connection and processor.
Lately these security-reducing apps that don’t obtain informed consent are grabbing public attention: articles about them are popping up in both security blogs and computer industry news. Some platforms and AVs are beginning to respond – they detect after others have called them out. But the platforms and AVs have been slow to update their policies, and slow to detect these apps as UwS, which leaves a gap that software monetizers continue to exploit.
Our session will show examples of how these apps reduce their customers’ security postures. We will highlight the platform and AV public policy gaps that have led to the spread of them. We’ll make suggestions as to how Avs can enhance their policies to better protect their customers from these apps.
Last January, Microsoft posted a blog titled Protecting customers from being intimidated into making an unnecessary purchase. The blog announced that effective March 1, they would be tightening up what they considered to be coercive messaging. The two new areas they called out were:
- Reporting the results in an exaggerated or alarming manner
- Requiring the user to "pay" to fix free scan results
We welcomed these changes, as it demonstrated Microsoft's resolve to go after the app vendors who were taking advantage of consumers to push unnecessary system utilities. But we also recognized that this was a significant change for many system utilities, including those that we had already certified.
Facing this change, we decided that the first step was to see if the anti-malware ecosystem could align on our understanding of Microsoft's principles. We worked with our security partners to come up with wording for a new application certification requirement (ACR-004). We also worked with many affected app vendors, CleanApps.org, compliance partners, and consumer groups to clarify the wording and provide examples of apps that either passed or failed ACR-004.
This took a few months to work through. These kinds of discussions are not easy, especially when the affected parties also include anti-malware vendors. But after all the discussions, we ended up with a requirement that we believe will both help consumers and still allow vendors to continue to demonstrate and monetize the value of their apps.
We set our enforcement date to be December 13, 2018. This means that any apps that do not meet ACR-004 by December 13, including new versions of apps that we have previously certified, may be added to our active Deceptor list.
ACR-004 states: When showing free scan results with the intent to monetize, results are substantiated and avoid any exaggerated sense of urgency, and app provides free fixes for all free scan results shown when the fix is not anticipated to be permanent or the fix offered is an ongoing service.
So what does this mean? If you're using free system utility scan results to monetize your solution, keep the following points in mind:
- Make sure your free scan results are truthful, detailed, and can be substantiated.
- Don't map free scan results to graphs, gauges, meters, or other ways to "measure" how important they are
- Unless you're reporting on immediate threats to the system or consumer (a good example of this is active malware), don't use differentiating colors to highlight your free scan results
- Unless you're providing a one-time permanent fix that's not an ongoing subscription, let the consumer "try" your solution by fixing all the results you show for free.
- If you're fixing free scan results for free as part of a "trial", don't pre-collect payment details or ask the consumer to perform any other tasks beyond providing their email.
You can read more details and see both good and bad examples for ACR-004 on our requirements checklist. We're happy to help vendors understand ACR-004, and we offer both free and paid services to help companies comply.
Over the past few months, new standards for ads have been released by both BetterAds.org and the IAB. We think that these are in response to the proliferation of more and more ad blockers; the ad industry has started taking responsibility for the quality of online ads.
And while we felt that this is great news for consumers, we also realized that it was time to update our own certification requirements for apps that inject or block ads. So we spent the past few months working with our customers, some of the larger ad injector vendors, compliance partners, various security and platform companies, and CleanApps.org.
This work drove significant changes: not only did we adjust the requirements, but some of the requirements were promoted to Deceptor-level. Starting in October, we'll be reviewing and calling out bad ad injectors and blockers and adding them to our active Deceptor list.
You can find a summary of the changes in the following ad injector requirement updates document. Please feel free to use this to understand the context behind the changes. Also, all the changes are live in our online requirements checklist.