11institutetext:  Macquarie University
11email<EMAIL_ADDRESS>{muhammad.ikram, Dali.Kaafar,
<EMAIL_ADDRESS>
# Empirical Security and Privacy Analysis of Mobile Symptom Checking
Applications on Google Play

I Wayan Budi Sentana  Muhammad Ikram  Mohamed Ali Kaafar  Shlomo Berkovsky

###### Abstract

Smartphone technology has drastically improved over the past decade. These
improvements have seen the creation of specialized health applications, which
offer consumers a range of health-related activities such as tracking and
checking symptoms of health conditions or diseases through their smartphones.
We term these applications as _Symptom Checking_ apps or simply
_SymptomCheckers_. Due to the sensitive nature of the private data they
collect, store and manage, leakage of user information could result in
significant consequences. In this paper, we use a combination of techniques
from both static and dynamic analysis to detect, trace and categorize security
and privacy issues in 36 popular SymptomCheckers on Google Play. Our analyses
reveal that SymptomCheckers request a significantly higher number of sensitive
permissions and embed a higher number of third-party tracking libraries for
targeted advertisements and analytics exploiting the privileged access of the
SymptomCheckers in which they exist, as a mean of collecting and sharing
critically sensitive data about the user and their device. We find that these
are sharing the data that they collect through unencrypted plain text to the
third-party advertisers and, in some cases, to malicious domains. The results
reveal that the exploitation of SymptomCheckers is present in popular apps,
still readily available on Google Play.

Smartphone users are increasingly using their smartphones for health-related
activities. The majority of smartphones now have the ability to passively
collect health data as users progress through their day [50]. The result of
this passive logging has been the creation of specialized health-related
mobile applications (SymptomCheckers) which track, manage and store the health
data of users. The logging capabilities of SymptomCheckers go beyond passive
tracking, as users can self-monitor their activities and manually record their
personal data. A wide variety of categories are offered including; exercise
and fitness tracker, sleep patterns and quality, cardiology and vascular
health, mental and emotional health, and blood sugar levels for diabetes [46].

Leveraging upon previous work [29], this paper presents the first
characterization study of SymptomCheckers with a focus on security and privacy
offered by these apps. In particular, we perform static and dynamic analysis
to analyze the Android permissions, the presence of malicious code as well as
third-party tracking libraries, and investigate the (un)encrypted traffic for
content and end-points of the exfiltrated sensitive data.

We collect and extract from a corpus of more than 1.7 million Android apps, 36
SymptomChecker for which the name or the description suggest they enable to
either track or check health-related activities of users. We then manually
check that the apps actually fall into the category of SymptomChecker (§ 1.1).
We use a set of tools to decompile the SymptomChekers and analyze the source
code of each of the mobile SymptomChekers. We then inspect the apps to reveal
the presence of third-party tracking libraries and sensitive permissions for
critical resources on users’ mobile devices. We summarize our analysis as
follow:

  * •

13.8% (5) of SymptomCheckers’ use a vulnerable encryption scheme (i.e., SHA1 +
RSA) for signing certificates and security purposes.

  * •

44.4% (16), 58.3% (21), and 63.86% (23) of SymptomCheckers provide Exported
Activities, Exported Services and Exported Broadcast Receiver, respectively,
which can be exploited by a malicious app. We found that 10.81% (4) of
SymptomCheckers contain malware code embedded in their source codes.

  * •

To avoid source code analysis 89% (32) of SymptomChekers rely upon different
types of anti-analytics or obfuscation techniques.

  * •

22.2% (8) of SymptomChekers embed at least five different third-party tracking
and advertisement libraries sharing sensitive user information such as
location with third-party analytics and advertisers.

  * •

5% of the traffic generated by SymptomCheckers’ use insecure HTTP protocol for
transmitting users’ sensitive data in plaintext which can be intercepted and
modified by malicious in-path proxies.

##  1 DATA COLLECTION AND ANALYSIS METHODOLOGY

In this Section, we present our data collection and analysis methodology.

###  1.1 Data Collection Methodology

Given that Google Play store does not contain “Symptom Checking” apps’
category, we devise a search methodology to find SymptomCheckers on Google
Play. First, we use several keywords including “symptom”, “SymptomChecker”,
and “health checker” in the description of 1.7 million Android applications
collected in [28]. We obtained 353 apps that match those keywords. We conduct
manual check apps description to ensure our SymptomCheckers apps are real
SymptomChecker. As the research scope is to analyze the SymptomCheckers apps
that are intended for end-user, we removed apps that only containing symptom
trackers, health dictionaries or apps that are used to store _only_ user
health history. We also discard the apps used for the learning process by
medical students or the apps used to assist health practitioners. Overall we
found 36 apps that met our search criteria.

We then use gplaycli [33] to download 36 apps. We then installed these four
apps on a mobile device via Android Debug Bridge (ADB) shell, a development
tool that facilitates communication between an Android device and a personal
computer, for further analysis. We also scraped textual information including
apps unique identifier, category and price, regional availability,
description, number of installs, developer information, user reviews, and apps
rating.

Table 1 shows the top 10 SymptomCheckers apps sort by number of install and
average ratings. Among the 36 apps, 83.3% (30) apps have at least 1,000
devices. We found that WebMD [52] is the most popular app with at least 10
Millions installs. The average rating, number of raters and number of reviews
are respectively 3.27, 10646.81, and 4341.35, showing the popularity of
SymptomCheckers among users. We also found that ADA [24] is highly rated by
290,484 users with an average rating of 4.74.

Table 1: Top 10 Free SymptomCheckers sort by number of installs. The lower part of the table summarises the average statics of SymptomCheckers. # | Apps Name | # of Installs | Rating
---|---|---|---
1 | com.webmd.android | 10,000,000+ | 4.44
2 | com.ada.app | 5,000,000+ | 4.74
3 | md.your | 1,000,000+ | 4.1
4 | com.mayoclinic.patient | 1,000,000+ | 3.9
5 | com.programming. | 500,000+ | 4.52
| progressive.diagnoseapp |  |
6 | com.symptomate.mobile | 100,000+ | 4.41
7 | nl.japps.android.depressiontest | 100,000+ | 3.82
8 | air.com.sensely.asknhs | 100,000+ | 4.29
9 | com.caidr | 100,000+ | 4.08
10 | com.teckelmedical.mediktor | 50,000+ | 3.62
Average Statistics: |
Avg. # of Install | 50,000+
Avg. # of Ratings | 3.27

###  1.2 Analysis Methodology

To have a wider perspective of the existing SymptomCheckers security, we
perform comprehensive static and dynamic analyses to inspect apps source code
and investigate the behaviour of the app during the runtime, respectively. We
also conduct a user review analysis to determine the user perception of the
analyzed SymptomCheckers.

Source Code Analysis: An APK is a mobile _app package_ file format supported
by the Android operating system (OS) for distribution and installation. APK
encloses all of the program’s codes and it supports resources including .dex
files, resources, assets, certificates, and manifest files, which are
considered as the important objects in this SymptomCheckers static analysis.
Since the APK is distributed in byte-code format, we conduct pre-processing by
leveraging APKTools [2] to decompile the APK into Smali format and get all
those files that will be useful in the following further analysis:

  1. 1.

Certificate Signing Mechanism. The Android platform requires all APKs to be
digitally signed with a certificate before it is uploaded to Google Play Store
or installed on a device. Application signing simplifies developers to
identify the app’s author and to update their application without
administering complicated permissions and interface. This process also becomes
an insurance policy for developers in terms of apps integrity and the
accountability of their apps’ behavior. [47] illustrates the importance of
this process to prevent adversaries from inserting malware into legitimate
apps by modifying and repackaging apps on the apps market.

Certificate signing in Android is conducted by integrating the identity and
private key of the author into a digital certificate. The certificate is then
attached to the app during packaging or before it is uploaded to the apps
market. Since the certificate is publicly available during the distribution
stage, the integrity and the accountability of the apps is highly dependent on
the encryption and hashing mechanism tailored in this process.

To evaluate the certificate signing mechanism adopted by the SymptomCheckers,
we extract the CERT.RSA file among all the files generated during the apps de-
compilation. We customized a script leveraging Keytool[38] to obtain
encryption and hashing mechanisms as well as the length of the public key
written into the certificate.

  2. 2.

Apps Permission Request. The permission system is a core security architecture
in the Android OS. All application requests to access sensitive data, system
features, components or other sensitive resources in the operating system are
managed by these systems. As an important point in security architecture,
permission systems are very vulnerable to exploitation and become the attack
surface of the Android system. Therefore, in this study, we included a
permission system analysis to find potential dangerous permissions that could
become a point of attack for malicious activities. For this purpose, we
elaborated on Manifest.xml on each app to find dangerous type permissions.

  3. 3.

Exported Component Analysis. Android apps consist of several components:
Activity, Service, Content Provider, and Broadcast Receiver. Activity
analogous to the presentation layer and each activity represents each
graphical user interface in the application while Service is a component that
is responsible for handling background processes in the application. Content
Provider and Broadcast receiver are responsible for exchanging data between
apps and listening for system message requests called intents, respectively.
These components collaborate to manage all functions in the apps. Commonly, a
function in an app will be triggered by the user via the activity. The Android
platform allows these components to be accessed and triggered from other
applications by setting the exported status equal to True. However, this
exported component is also a surface attack for malware to exploit an app.
Melamed et al., [35] demonstrates how these exported components can manipulate
apps’ components to compromise apps for malicious activities [13] [54]. To
identify the presence of an exported component in the SymptomCheckers, we use
the Android Drozer[16] to analyze the Manifest file for each app. Drozer–a
commonly used penetration testing tool–uses several checks to exploit
vulnerabilities in mobile apps.

  4. 4.

Malware Detection. To detect the presence of malicious codes in the
SymptomCheckers, we scan APKs using VirusTotal [51]. VirusTotal is a multitude
of malware scanning tools that provide a comprehensive result by aggregating
more than 70 anti-virus engine and URL/domain blacklisting services. The tools
has been widely used to identify the emergence of malicious apps, executable
files, application software as well as domains [29]. To automate the scanning
process, we take advantage of the API provided by VirusTotal, and create a
script to upload all samples to the VirusTotal repository.

Due to the file size restriction, among the total of 36 apps, we only manage
to scan 25 (69.4%) apps that have less than 32 MB in size through VirusTotal
API. We perform manual analysis through VirusTotal interface for the rest of
11(30.5%) apps including 8(22.2%) apps that have a size larger than 32 MB and
4(11.1%) apps that consist of multiple APK. Specifically for the apps with
multiple APK, we conduct manual scanning to both the base and split APK to
anticipate the malware that resides on the split APK.

  5. 5.

Anti-Analysis Detection. Anti-analysis technique refers to any means of
evading, obscuring, or disrupting the analysis process by parties other than
application developers. These techniques have both positive and negative
sides. On the one hand, this technique is useful for hardening the apps and
protecting the source code against analyzing and reproducing. On the other
hand, this technique can be used by malware developers to evade basic analysis
layers of application distribution services such as Google Play [7]. Research
in [23] found that 52% of its malware samples leverage this technique to evade
the analysis tools.

To detect such behaviour in the SymptomCheckers, we use APKID [41] to analyze
the .dex files obtained in decompiled APK. APKID returns at least one compiler
name for each APK. If the apps leveraging any anti-analysis technique, the
APKID will return several labels that we grouped as a manipulator, anti-
virtual machine (vm), anti-debug, anti-disassembly and obfuscator.

  6. 6.

Tracker Detection. The existence of third-party libraries and trackers on
android apps has sparked concern about privacy violations for app users. These
libraries can exchange information and infer user personal information based
on demographic data and user behavior harvested during user interaction with
the apps. Hence, in this study, we include the presence of these libraries as
a factor associated with privacy violations of SymptomCheckers users.

To reveal the existence of these libraries, we analyze the decompiled APK and
comprehensively search sub-directories in decompiled APKs. These unique
directories names correspond to the libraries embedded by apps’ developers in
the source codes. We rely on our list of libraries to the previous research
conducted in [21] [22] [28] to filter and obtain the third-parties in
SymptomChecking apps.

Runtime Behaviour Analysis: We conduct runtime behaviour (also called dynamic
analysis) to measure the security and privacy of SymptomCheckers apps during
the runtime by capturing the traffic transmitted by Apps to the Internet. To
avoid the Anti-Virtual Machine detection adopted by certain apps, we use a
dedicated Android device and channelling the connection via MITMProxy [36] to
the WiFi access point. Since all the SymptomCheckers developed in SDK version
25 or above, we create a script to add self-signed security certificate
exemption to read the traffic transmitted in HTTPS protocol. Although the
security exemption was added to all apps, we failed to capture the traffic of
6 apps including 4 apps with multiple APK and 2 apps with a single APK. All of
these applications deny self-signed certificate exemption and required TLS
handshake on the early phase of runtime, which causes the application to
always be in a force stop condition.

Given that the number of SymptomCheckers is small, once the apps are installed
on the device, we navigate the apps manually and observe all activities on the
apps while MITMProxy intercepts the transmission between each app to the
internet. The result of the interception is then saved in .dump form.

User-review Analysis: A user review analysis was performed to capture the
users’ perceptions of SymptomCheckers. In this analysis, we have fetched
Google Play store reviews (N = 76,817) of 30 apps. App reviews were
categorized as positive (93.74%) with rating = 3,4,5 and negative (6.26%) with
rating = 2 . We have only considered reviews of rating $\leq 2$ that were in
total N = 4,807 negative reviews to understand the user’s perception of app
usability, mal-behaviour, privacy and security. To carry this analysis, we
have used a dictionary of 60 keywords that mapped to 12 complaint categories
(see Table 5). For instance, keyword ‘force close’ mapped to ‘bugs’ under
app’s ‘usability’ category and ‘personal data’ mapped to ‘privacy’ for the
‘Privacy’ category. We found a total of N = 2,078 complaints across various
categories that suggest the user’s perception of each of them.

##  2 ANALYSIS

We explore the vulnerability of SymptomCheckers by identifying security gaps,
suspicious behavior, level of communication security and user perspective. The
results of the analysis present several aspects including; The strength of the
encryption algorithm, exploitation of attack surface, intrusive permission,
suspicious malware and anti-analysis appearance, adoption of secure
communication protocol, and user-related security aspects.

###  2.1 Certificate Signing Summary

Based on the evaluation results of the certificate signing mechanism for the
SymptomCheckers, we found 31 (86.1%) apps signed using the SHA256 and RSA
encryption mechanism. While the remaining 5 (13.8%) apps were signed using a
combination of SHA1 and RSA encryption mechanisms. During the exploration
process, we received a warning from the key tool stating that apps with a SHA1
and RSA mechanism were categorized as having a fairly weak security level.
SHA-1 was considered a weak signing mechanism after the first collision attack
for the full SHA-1 white paper released by Google in [48].

Table 2: Summary of Certificate Signing Analysis; Top: Certificate signing mechanism; Bottom: Public Key length written in Digital certificate. Signature Algorithm | # of Apps, N=36 (%)
---|---
SHA256 + RSA | 31 (86.1%)
SHA1 + RSA (weak) | 5 (13.8%)
Key Length (bits) | # of Apps, N=36 (%))
4096 | 15 (41.6%)
2048 | 21 (58.3%)

We also include the length of the public key as part of the security measures
in the SymptomCheckers certificate signing scheme. We are referring to the
minimum standard public key length of 2048 bits published by [12]. This
document contains guidance on policy and security planning requirements for
United States government agencies.

As shown in Table 2, all SymptomCheckers have met minimum security standards
of public key length, where 21 (58.3%) apps adopting a public key with a
length of 2048 bits and 15 (41.6%) apps adopting 4096 bits.

###  2.2 Permission Analysis

The dangerous permissions curve that approximate the total permissions curve
in Figure 2 indicates that the number of dangerous permissions is close to the
total permissions requested by the SymptomCheckers. Out of a total of 427
permission requests, 73 % (312) permissions were categorized as dangerous, 20
% (84) were categorized as normal, and 8 % (33) permissions were categorized
as signatures. The number of dangerous permissions is requested by 33 of the
36 apps on the SymptomCheckers list.

From a total of 79 unique type permissions, 51 permissions in Figure 1.
INTERNET is the most requested permission with 32 permissions, followed by
WRITE_EXTERNAL_STORAGE and WAKE_LOCK with 22 and 19 requests, respectively.

Figure 1: Overview of _Dangerous_ permissions requested by SymptomCheckers.
INTERNET, WRITE_EXTERNAL_STORAGE, and WAKE_LOCK become the most popular
permission request.

We then observe whether all the available list permissions are used by the
functions in the respective SymptomCheckers. Therefore, we map the API calls
or methods of each app with the permission requests in the Manifest using
AXPLORER [6]. As a result, all permission lists in the SymptomCheckers are
requested at least once in the API calls or methods.

Figure 2: Cummulative Distributed Function of Permission request by
SymptomCheckers. Dangerous permission approximated Total permission request.

###  2.3 Exported Component Analysis

Figure 3 depicts 44.4 % (16) of the analyzed SymptomCheckers apps contain
_Exported Activities_. While, apps that have Exported Services and Exported
Broadcast Receivers are 58.3 % (21) and 63.86 % (23) apps, respectively. None
of SymptomCheckers apps containing Exported Content Providers. In total there
are 74 Exported Activities, 42 Exported Services, 78 Exported Broadcast
Receivers and none Exported Content Provider.

Figure 3: Results of SymptomCheckers’ _Exported Component_ analysis. None of
the apps containing Exported Content Provider.

We then group the apps based on the number of Exported Components in each app
as shown in Table 3. In the table, it can be seen that 11 (30.5 %) apps have
Exported Component, 21 (58.3 %) apps have Exported Services, and 18 (50 %)
apps have Exported Broadcast Receiver, in the range of 1 to 5 respectively. In
addition, there are 9 (25 %) apps that have Exported Components in the range
of 6 to 10. We also notice massive Exported Activities by WebMD [52] with 12
activities, indicating that there are 12 surface attacks that can be exploited
by malicious activities in this app. For instance, WebMD [52] consists of 66
activities, 10 Services, 11 Broadcast Receivers, and 6 Content Providers. This
application is also listed as a SymptomCheckers with the highest number of
installs (10,000,000+) with the number of reviews and ratings of 13,448
reviews and 64,152 users.

Table 3: Summary of _exported components_ analysis. Range | Activities | Services | Receivers | Providers
---|---|---|---|---
| # of Apps | # of Comp | # of Apps | # of Comp | # of Apps | # of Comp | # of Apps | # of Comp
$>$10 | 1 | 12 | 0 | 0 | 0 | 0 | 0 | 0
6-10 | 4 | 36 | 0 | 0 | 5 | 30 | 0 | 0
1-5 | 11 | 26 | 21 | 42 | 18 | 46 | 0 | 0
0 | 20 | 0 | 15 | 0 | 13 | 2 | 36 | 0

###  2.4 Malware Presence

To simplify the interpretation of VirusTotal result, we introduce VTScore
which represents the number of detection by anti-virus engine in the
VirusTotal. The score range is between 0 to 70 where the maximum score is
equal to the number of anti-virus engines in VirusTotal.

Upon scanning SymptomCheckers using VirusTotal, we find 4 (10.81%) apps
detected to contain malware with a VTScore of 1. Those are the apps that
manually scanned through the VirusTotal interface including MiA SymptomChecker
[8], Mediktor [34], HealthNav [26], and Mayo Clinic [10]. Those are popular
apps with a number of installs above 10,000+ and has been released for more
than three years except for MiA SymptomChecker which was only installed by
100+ users and was only released in December 2019. 50% of the apps have a
rating score above the average of the entire sample except for the MiA
SymptomChecker and Mediktor which have a rating score of 0 and 3.62
respectively.

Further identification finds that all the VTScore were contributed by Sangfor
Engine Zero anti-virus.Sangfor Engine Zero (SAVE Engine) is Artificial
Intelligence based anti-virus engine developed by Sangfor Security Team. This
engine leverages machine learning technology to analyze and synthesize the
input data. This engine has become a part of VirusTotal since November 2019.
Unfortunately, Sangfor Engine Zero detection results only provide a general
label of malware so we cannot identify the malware type and family.

Based on the previous researches in [4] and [29] that establish minimum
confidence VTScore of 2 and 5 respectively, and the reputation of Sangfor
Engine Zero explored in [11, 40], we consider that the detection result has a
possibility of being false-positive.

###  2.5 Anti-Analysis Techniques

Figure 4: Anti-Analysis techniques adopted by SymptomCheckers. 89%
SymptomCheckers apps leveraging anti-VM technique to detect emulated
environment.

The Evaluation results of the SymptomCheckers show that 89% of SymtomCheckers
have adopted at least one anti-analysis techniques in their source codes. The
details of the measurement results are described as follows:

  * •

Manipulator: Each APK consists of Dalvix Executable (.dex)  files converted
from Java.class using (originally) dx compiler. We marked the apps containing
the manipulator if the .dex files were created using other than dx compiler.
There are two condition that make the manipulator label can be given; first,
when the original .dex files created using dx compiler is modified using
modificator library such as dexmerge, and second, when .dex files created from
reverse-engineered source code using dexlib library that commonly used by
decompiler tools such as apktool or smali [43]. Besides being used as a
logical reference for the Dalvik Virtual Machine (DVM) or Android Runtime
(ART), .dex files also store a history of changes experienced by the apps.
APKID checked that history by analyzing Map Ordering Type of the .dex files
since the code sequence resulted from original .dex compiler, dexmerge, dexlib
or dex2lib is different [17].

As shown in figure 4, we found that 8 (22%) SymptomCheckers leverage dexmerge
compiler to protect their source codes.

  * •

Anti Virtual Machine: This technique is used to detect whether the apps are
running on the emulator or real devices. The emulator detection aims to
increase the difficulty level of apps running on emulators which impedes
certain reverse-engineering tools and techniques. The reverse engineer
required additional tools to deceive the emulator detection or utilized the
physical devices to reverse the source code. There are several indicators to
check whether the device is emulated [39]. The first indicator can be found in
file build.prop that contains a static list of Build API methods including
Build.Fingerprint, Build.Hardware, Build.Device and other devices properties.
The other set static indicator can be checked from Telephony manager which
have fixed API values of Android emulators including getNetworkType(),
getNetworkOperator(), getPhoneType()  and other network-related properties.

We found 32 (89%) apps use anti-virtual machine techniques to check the
emulator presence based on various indicators in build.prop and Telephony
Manager.

  * •

Anti Debug: There are two types of anti-debuging which are preventive and
reactive. Preventive anti-debuging prevents any kind of debugger activities
from the first time. While reactive anti-debuging started with detecting
debuggers and reacting in certain ways, such as triggering hidden behavior or
terminating the apps. There are two levels of debugging as well as anti-
debugging protocol in Android [39]. First, the debugging can be conducted in
Java level using Java Debug Wire Protocol (JDWP) which is used as
communication protocol between debugger and Java Virtual Machine. In this
level we can trace anti-debugging setup by checking the debuggable flag in
ApplicationInfo or by checking the timer checks routine. Second, we can
conduct debugging in native layer level by using ptrace in Linux system call.
This anti-debugging level check is also known as a traditional anti-debugging
process.

We found 18 (50%) SymptomCheckers tailor anti-debug techniques to avoid
analysis tools. All of those apps detect debuggable state by activated
isDebuggerConnected() routine in android.os.Debug class, which is part of JDWP
anti-debugging level technique.

  * •

Anti Disassembly: Anti-disassembly could be the most advanced mechanism in the
anti-reversing domain. The developer needs to craft their code in order to
protect their byte-code from being disassembled by the reverse engineer. A
common technique to protect the byte-code in Android is to create the
important code segment in C or C++ using Native Development Kit (NDK)[45]. NDK
provides platform libraries to manage native activities and access physical
device components[14]. NDK uses CMake as a native library compiler that
creates a different byte-code structure compared to the code written in Java
or Kotlin. Hence, it impedes common Android tools such as Apktool or Smali to
disassemble the byte-code. It required advanced reverse engineering that was
familiar to ARM processor architecture, Assembler language, Java Native
Interface (JNI) convention and Application Binary Interface (ABI) compiler to
decompile the byte-code. More advanced technique used by malware developers to
evade disassembly tools explained by [37]. The technique leveraging jmp and
call command in byte-code level to direct the instruction flow to a certain
location with a constant value, or directing the flow to the same target
memory location. This technique will produce a false listing of source code
when it disassembles using a decompiler tool.

We found 3 (8%) SymptomCheckers use anti-disassembly techniques, including
AITibot [1], Appstronout [3] and Mayo Clinic [10]. Analysis of those apps
returns the value of “illegal class name”, indicating the decompiler result
violating the standard structure of Java or Kotlin.

  * •

Obfuscator: Code obfuscation is the process of modifying code into meaningless
phrases by renaming or encrypting the file names, methods, or strings without
reducing the code functionality. The aim is to protect the executable file
from being analyzed or being reversed by an unauthorized party. Other than
renaming and encrypting, [53] describes more advanced techniques to conduct
code obfuscation including control flow obfuscation and instruction pattern
transformation. Proguard [15] and Dexguard [20] are two most common tools
utilized in Android programming obfuscation. Proguard is a free and open-
source tools that provide an optimizer for general Java byte-code. It enables
developers to obfuscate, compress, and optimize desktop, embedded and mobile
Android applications. Dexguard is proprietary tool designed to protect Android
applications. It provides multi-layer protection against the static and
dynamic analysis of byte-code, manifest, and all other resources included in
distribution packages.

We found 2 (6%) SymptomCheckers deploying obfuscators. Analysis results on
Healhtily [25] return ’unreadable field names’ and ’unreadable method names’
indicating that a certain number of field names and method names in that app
were renamed or encrypted. However, APKID failed to identify the tools used to
conduct obfuscation. While analysis on Mayo Clinic [10] identifies the apps
adopting Dexguard to conduct the obfuscation.

###  2.6 Third-party Ads and Tracking Analysis

The results of the tracking library analysis show that 69.4% (25)
SymptomCheckers adopt at least one tracker. There are even 22.2% (8) apps
leveraging more than 5 tracking libraries in their code. The application with
the highest number of tracking libraries was listed by com.caidr.apk with 10
trackers. com.caidr is a popular app with over 100,000+ installations and
rating of 4.1 . These apps consist of 26 activities where almost 50% of the
activities are proposed to handle third-party libraries including tracker.
More details about the results of this measurement can be seen in Figure 5.

The detection results show that the adoption of a third-party library on
SymptomCheckers is dominated by two large company groups, namely Google which
includes Google Analytics, Google Tag Manager, Google Admob, Google Firebase
Analytic, and Google CraschLytic, and the Facebook group consisting of
Facebook Ads, Facebook. Analytic, Facebook Login, Facebook Share, and Facebook
Place. Totally, Google groups are dominated by 55 libraries attached to the
SymptomCheckers, followed by Facebook groups with 35 libraries. In this
research, Google Firebase Analytic became the most popular third-party library
that is adopted by 44.4% (16) of SymptomCheckers.

Firebase Analytics is a library used to infer personal user information
including gender, age range, and location, based on demographic and behavior
of users when interacting with applications[18, 19]. This library is
integrated with Google Analytics which on the surface can be detected only
harvesting network data and device information[44]. Although each library
collects limited information, when all these libraries exchange information,
it raises concerns about privacy violations because these third-party
libraries can infer personal information based on the behavior and demographic
data exchanges.

Figure 5: Apps to third-party libraries mapping. Left column indicating the
number of third-party libraries adopted by SymptomChekcers, while right column
figuring the name of third-party library and the number of usage by
SymptomCheckers.

###  2.7 Traffic Analysis

Upon the interception process, we then convert the dump file into HTTP/S
Archive (.har) file to simplify traffic analysis of each SymptomCheckers. We
direct our analysis of security by extracting the secure communication line
and privacy factors by observing the potential of privacy leaks.

From the security factor, we analyzed the percentage of the encrypted HTTPS
protocol adoption on the SymptomCheckers’ communication lines. For this
purpose, we extract intercepted unique URLs and identify the type of
transmission protocol used. Based on the Cumulative Distribution Function
(CDF) in Figure 6a, it can be seen that the HTTPS protocol adoption curve
approaches the total communication line curve. This shows that most of the
communication traffic for SymptomCheckers have adopted the HTTPS protocol.
However, from a total of 1584 unique URLs detected, 74 (5%) communications
were passed through the HTTP protocol. 3 SymptomCheckers communicate 50% of
their traffic un-encrypted via HTTP.

(a) HTTP and HTTPS Traffic

(b) First Party and third-party Traffic

Figure 6: Cumulative distribution function of Traffic Captured in
SymptomCheckers. 95% SymptomCheckers adopting encrypted HTTPS protocol and 81%
of the traffic are directed to the first-party or supporting domains.

To observe potential privacy leaks, we consider the existence of third-party
libraries adopted by each SymptomCheckers. Hence, we refer to Section 2.6 to
create a list of third-party libraries and compare it to the intercepted
unique URLs. We then categorize the corresponding URLs as traffics that are
directed to third-party domains and the rest is traffics that are directed to
domains provided by the app developer (first-party) or domains that are used
to support apps functionality. The percentage of traffic leading to a third-
party domain is an indicator of a possible privacy leak.

The first-party traffic curve approximates the total transmission traffic
curve in Figure 6b indicating that most of the traffic in the SymptomCheckers
is directed to the first-party domain or apps supporting domain. However, out
of 1,584 total traffic intercepted, there are 301 (19 %) unique URLs that
point to a third-party domain. Our further observation found that there were 8
(22%) apps that had traffic leading to a third-party with more than 50% of the
total traffic. This indicates that the app uses more than 50% of its
functionality for third-party libraries.

Table 4: Summary of Traffic Analysis. 19% traffic directed to third-party domains and 1% of the traffic relying on un-encrypted HTTP protocol. | Unique URL | HTTP | HTTPS
---|---|---|---
First-party | 1,283 (81%) | 69(4%) | 1,214 (77%)
Third-party | 301 (19%) | 5 (1%) | 296 (19%)
Total | 1,584 (100%) | 74 (5%) | 1,510 (95%)

Table 4 summarises our traffic analysis. Of 1,584 intercepted unique URLs,
there are 1,510 (95%) traffic transmitted over the encrypted HTTPS protocol
line and 74 (5%) traffic transmitted via the un-encrypted HTTP protocol. In
addition, of the total Unique URLs, there are 1,283 (81%) URLs pointing to
first-party or supporting domains and 301 (19%) URLs pointing to third-party
domains. In more detail, 69 (4%) of traffic to the first-party domain is
transmitted via the un-encrypted HTTP and 1,214 (77%) of traffic to the first-
party domain is transmitted via the encrypted HTTP. While, 5 (1%) and 296
(19%) unique URLs were directed to the third-party domain via HTTP and HTTPS,
respectively.

Table 5: Analysis of users’ perception of SymptomCheckers analyzed through user reviews categories and keywords.  Complaint Category | #Comp (%) | # Apps (%) |  Case-insensitive, Searched Keywords
---|---|---|---
Usability |
Bugs | 429(20.64) | 12(41) |  force close; crash; bug; freeze; glitch; froze; stuck; stick; error; disconnect; not work; not working
Battery | 74(3.56) | 9(31) |  battery; cpu; processor; processing; ram ; memory
Mobile Data | 87(4.19) | 10(34) |  mobile data; gb; mb; background data;
Mal-behaviour |
Scam | 28(1.35) | 6(21) |  scam; credit card; bad business; bad app
Adult | 23(1.11) | 6(21) |  porn; adult; adult ad
Offensive/Hate | 2(0.10) | 2(7) |  hate; offensive; sexist; LGBT; trolling; racism; offensive; islamophobia; vile word; minorities; hate speech; shit storm
Privacy |
Privacy | 53(2.55) | 7(24) |  privacy; private; personal details; personal info; personal data
Ads | 1280(61.60) | 24(83) |  ads; ad; advertisement; advertising; intrusive; annoying ad; popup; inappropriate; video ads; in-app ads
Trackers | 43(2.07) | 10(34) |  tracker; track; tracking
Security |
Security | 12(0.58) | 4(14) |  security; tls; certificate; attack
Malware | 5(0.24) | 3(10) |  malware; trojan; adware; phishing; suspicious; malicious; spyware
Intrusive Permissions | 42(2.02) | 6(21) |  permission

###  2.8 User Perception Analysis

Users often complained about apps’ usability (see Table 5) where bugs, battery
and mobile data issues caused frustration. For instance, 429(20.64%)
complaints were made for 12 (41%) apps where users raised their concerns and
requested to fix the usability issues to improve the user experience. While
some might find the app useful but an apparent usability issue may hinder
useful experience. Some users stated that ”great app is very useful; however I
have gotten a lot of ’force close’ messages please fix.”, ”would not load
pictures and kept freezing” or ”had to uninstall as they kept crashing every
time you open the app”.

Apps mal-behaviour had captured minor users’ attention where such apps were
listed as scams and raised concerns about presenting adult or offensive
content. User stated as ”No way to verify that this is a legitimate app. No
clear connection to the NHS. Looks like a scam to steal personal information”.

Notably, under the privacy category users mainly complained about in-app
advertisements 1280 (61.60%) for 24 (83%) reviewed apps. Users elaborated
”don’t want seeing this app advertisement through my phone”, ”I need to answer
your questions and all I see is advertisement…” or ”… I cannot find anything
not my blood type not my last appointment everything is advertisement…”.
Comparatively user reviews suggest little understanding of apps privacy and
tracking behaviour. However, some users stated ”privacy policy is bad”,
”sharing personal data is not cool” or ”removed the app after finding out that
it shared private health data with third-parties”.

Similar to privacy users’ perception of apps security was also limited. There
were minor complaints made for app security, presence of malware and app
requiring intrusive permissions as shown in Table 5. Users mentioned their
concerns for specific apps as ”security risk, asks for personal details that
would facilitate identity theft. if in doubt be cautious.” or ”spyware, why
does it need my device serial number; my location; read SD card; to record
audio when I get up and go to sleep; all combined with full internet access?”.

We found that 20.6% and 61.6% of users’ complaints were related to usability
issues such as bugs (20.64%) and advertisements, respectively. A fraction of
users complaints approx. 3% (57) are related to security issues in 13
SymptomCheckers.

##  3 Related Work

Our study builds on previous work in static and dynamic analysis of mobile
apps Static analysis is parsing the source-code of mobile apps, while dynamic
analysis is studying the behavior of apps using runtime network analysis [29].

Static analysis can be performed by either static data flow analysis [28],
[5], [27], or symbolic execution [30]. Previous studies have highlighted
several PII leaks [49] [9] albeit with higher false positives. The cases where
Android apps load the code at run time only (as presented by Lindorfer et al.
[32]), can result in higher false negatives, while, symbolic execution can be
too time-intensive to be practical [42]. Au et al. [5] and Leontiadis et al.
[31] leverage static analysis to inspect app permissions and their associated
system calls. By developing a version-independent static analysis tool called
PScount, Au et al. [5] found that around 22% of the non-system permissions are
redundant. While Leontiadis et al. [31] proposed a feedback control loop
framework, that can alter the level of privacy protection on mobile phones by
examining 250 thousand applications.

Dynamic analysis suffers from false overhead, adding to its challenges when
running on a large scale. Moreover, it accumulates run-time overhead, adding
to its challenges when running on a large scale. Perhaps, a much closer work
to our’s is by Ren et al. [42], where they monitored the network traffic to
detect personally identifiable information (PII) leaks of 512 Android apps
across different versions. They show that apps leak PII to more third-party
domains over time. We build on this work by conducting a compliance analysis
of apps across different versions by taking the union of leaks that are
detected in static and dynamic analysis.

##  4 CONCLUSION

The increasing number of mobile SymptomCheckers available on apps’ markets
such as Google Play and the growing number of complaints raised by users
indicate serious security and privacy as well as usability issues thus
necessitate the urge to analyse this unexplored eco-system. The average mobile
user rates SymptomCheckers positively even when 10% have malware presence.
According to our study, 3% of negative reviews are related to (or concerned
with) the security and privacy issues of SymptomCheckers. Our app review
analysis suggests an alarming situation as users show minimal interest or
awareness of SymptomCheckers privacy and security. The results found in this
paper reveal serious security and privacy issues in Google Play. We believe
that our work could be extended to study the qualitative analysis such as
users satisfaction and effectiveness of SymptomCheckers’ functionalities.

## References

  * [1] AITibot: Understand skin problems - ai tool for skin. https://play.google.com/store/apps/details?id=ai.tibot (2021)
  * [2] Apktool: A tool for reverse engineering 3rd party, closed, binary android apps. https://ibotpeaches.github.io/Apktool/ (2020)
  * [3] Appstrounout: Headache tracker - migraine & headache log. https://play.google.com/store/apps/details?id=com.appstronautstudios.headachetracker (2021)
  * [4] Arp, D., Spreitzenbarth, M., Hübner, M., Gascon, H., Rieck, K.: Drebin: Effective and explainable detection of android malware in your pocket. In: NDSS (2014)
  * [5] Au, K.W.Y., Zhou, Y.F., Huang, Z., Lie, D.: Pscout: Analyzing the android permission specification. In: CCS (2012)
  * [6] Backes, M., Bugiel, S., Derr, E., McDaniel, P., Octeau, D., Weisgerber, S.: On demystifying the android application framework: Re-visiting android permission specification analysis. In: USENIX Sec (2016)
  * [7] Chau, N., Jung, S.: An entropy-based solution for identifying android packers. IEEE Access (2019)
  * [8] Checker, M.S.: Mia symptom checker. https://play.google.com/store/apps/details?id=com.nextgenblue.symptomchecker (2021)
  * [9] Chen, X., Zhu, S.: Droidjust: Automated functionality-aware privacy leakage analysis for android applications. In: WiSec (2015)
  * [10] Clinic, M.: Mayo clinic medical. https://play.google.com/store/apps/details?id=com.mayoclinic.patient (2021)
  * [11] Community, S.: Incorrect detection at virus total by sangfor engine zero antivirus. https://community.sangfor.com/forum.php?mod=viewthread\&tid=2854 (2020)
  * [12] CSRC: Recommendation for key management, part 1: General (revision 3), computer security resource center. https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-3/archive/2012-07-10 (2016)
  * [13] CWE-926: Cwe-926: Improper export of android application components. https://cwe.mitre.org/data/definitions/926.html (2020), accessed: 18/12/2020
  * [14] Developer, A.: The android ndk: toolset that lets you implement parts of your app in native code, using languages such as c and c++. https://developer.android.com/ndk (2020)
  * [15] Developer, A.S.: Shrink, obfuscate, and optimize your app. https://developer.android.com/studio/build/shrink-code (2020)
  * [16] F-Secure-Labs: Drozer: Comprehensive security and attack framework for android. https://labs.f-secure.com/tools/drozer/ (2020), accessed: 18/12/2020
  * [17] Fenton, C.: Building with and detecting android’s jack compiler. https://calebfenton.github.io/2016/12/01/building-with-and-detecting-jack/ (2016)
  * [18] Google-Analytic: User properties — analytics. https://developers.google.com/analytics/devguides/collection/firebase/android/properties (2020)
  * [19] Google-Firebase: Predefined user dimensions - firebase. https://support.google.com/firebase/answer/6317486 (2016)
  * [20] Guardsquare-Mobile-Application-Protection: Dexguard: Android app security - protecting android applications and sdks against reverse engineering and hacking. https://www.guardsquare.com/en/products/dexguard (2020)
  * [21] Hashmi, S.S., Ikram, M., Kaafar, M.A.: A longitudinal analysis of online ad-blocking blacklists. In: 2019 IEEE 44th LCN Symposium on Emerging Topics in Networking (LCN Symposium). pp. 158–165. IEEE (2019)
  * [22] Hashmi, S.S., Ikram, M., Smith, S.: On optimization of ad-blocking lists for mobile devices. In: Proceedings of the 16th EAI International Conference on Mobile and Ubiquitous Systems: Computing, Networking and Services. pp. 220–227 (2019)
  * [23] He, R., Wang, H., Xia, P., Wang, L., Li, Y., Wu, L., Zhou, Y., Luo, X., Guo, Y., Xu, G.: Beyond the virus: A first look at coronavirus-themed mobile malware (2020)
  * [24] Health, A.M.: Ada – check your health. https://play.google.com/store/apps/details?id=com.ada.app (2021)
  * [25] Healthily: Self-care & health journal. https://play.google.com/store/apps/details?id=md.your (2021)
  * [26] HealthNav: Healthnav baycare health system, inc. https://play.google.com/store/apps/details?id=baycare.com.healthnav (2021)
  * [27] Ikram, M., Beaume, P., Kaafar, M.A.: Dadidroid: An obfuscation resilient tool for detecting android malware via weighted directed call graph modelling. In: SECRYPT (2019)
  * [28] Ikram, M., Kaafar, M.A.: A first look at mobile ad-blocking apps. In: 2017 IEEE 16th International Symposium on Network Computing and Applications (NCA). pp. 1–8. IEEE (2017)
  * [29] Ikram, M., Vallina-Rodriguez, N., Seneviratne, S., Kaafar, M.A., Paxson, V.: An analysis of the privacy and security risks of android vpn permission-enabled apps. In: IMC (2016)
  * [30] Jeon, J., Micinski, K.K.: Symdroid : Symbolic execution for dalvik (2013)
  * [31] Leontiadis, I., Efstratiou, C., Picone, M., Mascolo, C.: Don’t kill my ads! balancing privacy in an ad-supported mobile application market. https://doi.org/10.1145/2162081.2162084
  * [32] Lindorfer, M., Neugschwandtner, M., Weichselbaum, L., Fratantonio, Y., van der Veen, V., Platzer, C.: ANDRUBIS - 1,000,000 Apps Later: A View on Current Android Malware Behaviors. In: BADGERS 2014 (2014)
  * [33] matlink: Google play downloader via command line v3.25. https://github.com/matlink/gplaycli (2018), accessed: 10/10/2020
  * [34] Mediktor: Mediktor tecker medical. https://play.google.com/store/apps/details?id=com.teckelmedical.mediktor (2021)
  * [35] Melamed, T.: Hacking android apps through exposed components. https://www.linkedin.com/pulse/hacking-android-apps-through-exposed-components-tal-melamed (2020)
  * [36] mitmproxy: - an interactive https proxy. https://mitmproxy.org (2020)
  * [37] Nair, R.: Techbliss - tutorial anti-disassembly techniques used by malware (a primer). https://www.techbliss.org/threads/anti-disassembly-techniques-used-by-malware-a-primer-by-rahul-nair.804/ (2015)
  * [38] Oracle: keytool. https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html (2020), accessed: 18/12/2020
  * [39] OWASP: Testing anti-debugging detection (mstg-resilience-2) - android anti-reversing defenses. https://mobile-security.gitbook.io/mobile-security-testing-guide/android-testing-guide/0x05j-testing-resiliency-against-reverse-engineering (2020), oWASP Mobile Security Guide - Accessed: 18/01/2020
  * [40] Reddit, F.: Virustotal detects malware. https://www.reddit.com/r/pathofdiablo/comments/ewooys/virustotal\\_detects\\_malware/ (2020)
  * [41] RedNaga: Apkid - anti-analyisis open source tools. https://github.com/rednaga/APKiD (2016)
  * [42] Ren, J., Lindorfer, M., Dubois, D.J., Rao, A., Choffnes, D.R., Vallina-Rodriguez, N.: Bug fixes, improvements, … and privacy leaks: A longitudinal study of pii leaks across android app versions. In: NDSS (2018)
  * [43] Security, R.: Apkid and android compiler fingerprinting. https://rednaga.io/2016/07/30/apkid_and_android_compiler_fingerprinting/ (2016)
  * [44] Seneviratne, S., Kolamunna, H., Seneviratne, A.: A measurement study of tracking in paid mobile applications. In: WiSeC (2015)
  * [45] SIMFORM: How to avoid reverse engineering of your android app? https://www.simform.com/how-to-avoid-reverse-engineering-of-your-android-app/ (2015)
  * [46] Smahel, D., Elavsky, S., Machackova, H.: Functions of mhealth applications: A user’s perspective. Health informatics journal 25(3), 1065–1075 (2019)
  * [47] SSL: Why you need code signing certificate for your android app? https://aboutssl.org/why-you-need-code-signing-certificate-for-android-app/ (2020)
  * [48] Stevens, M., Bursztein, E., Karpman, P., Albertini, A., Markov, Y.: The First Collision for Full SHA-1. In: International Cryptology Conference — CRYPTO 2017. pp. 570–596. IACR, Santa-Barbara, United States (Aug 2017). https://doi.org/10.1007/978-3-319-63688-7_19, https://hal.archives-ouvertes.fr/hal-01982005
  * [49] Tangari, G., Ikram, M., Ijaz, K., Kaafar, M.A., Berkovsky, S.: Mobile health and privacy: cross sectional study. bmj 373 (2021)
  * [50] Trifan, A., Oliveira, M., Oliveira, J.L.: Passive sensing of health outcomes through smartphones: Systematic review of current solutions and possible limitations. JMIR mHealth and uHealth (2019)
  * [51] VirusTotal: Multitude anti-virus engines. https://www.virustotal.com/gui/home/upload (2020)
  * [52] WebMD: Webmd: Check symptoms, rx. https://play.google.com/store/apps/details?id=com.webmd.android (2021)
  * [53] Weerasekara, S.I.: Gitconnected - obfuscation in android. https://levelup.gitconnected.com/android-obfuscation-e608f79f0d09 (2020)
  * [54] Zhao, B.Z.H., Ikram, M., Asghar, H.J., Kaafar, M.A., Chaabane, A., Thilakarathna, K.: A decade of mal-activity reporting: A retrospective analysis of internet malicious activity blacklists. In: Proceedings of the 2019 ACM Asia Conference on Computer and Communications Security. pp. 193–205 (2019)

Table 6: Overview of our analyses of SymtomCheckers. Col.2-4: SymptomChecking
apps IDs, number of installs, and average rating (Av. Rat.). Col.5-8:
Certificate signing algorithm, number of exported components, VirusTotal’s
number of positives, number of anti-analysis techniques implemented by
SymtomCheckers. Col.9-11: Fraction of requests communicated with HTTP, number
of third-parties domains, and fraction of negative reviews to the total number
of users’ reviews.

No. | Apps Name | # of Installs | Av. Rat. | Cert. | # of Exp. | VTS | # of Anti | % HTTP | # Third- | % of Neg.
---|---|---|---|---|---|---|---|---|---|---
|  |  |  | Signing | Comp. |  | Analysis |  | party | Review
1 | com.webmd.android | 10,000,000+ | 4.44 | SHA1 | 17 | 0 | 2 | n.a. | 9 | 17.9
2 | com.ada.app | 5,000,000+ | 4.74 | SHA256 | 3 | 0 | 1 | 37.5 | 4 | 3.7
3 | md.your | 1,000,000+ | 4.1 | SHA256 | 12 | 0 | 3 | 5.13 | 6 | 15.3
4 | com.mayoclinic.patient | 1,000,000+ | 3.9 | SHA1 | 12 | 1 | 3 | 2.11 | 1 | 32.1
5 | com.programming.progressive |  |  |  |  |  |  |  |  |
| .diagnoseapp | 500,000+ | 4.52 | SHA256 | 0 | 0 | 1 | 25 | 2 | 5.5
6 | com.symptomate.mobile | 100,000+ | 4.41 | SHA1 | 1 | 0 | 1 | 1.49 | 0 | 11
7 | nl.japps.android.depressiontest | 100,000+ | 3.82 | SHA1 | 4 | 0 | 2 | 3.45 | 2 | 13.9
8 | air.com.sensely.asknhs | 100,000+ | 4.29 | SHA256 | 2 | 0 | 2 | 1.80 | 2 | 25.7
9 | com.caidr | 100,000+ | 4.08 | SHA256 | 16 | 0 | 2 | 1.92 | 10 | 33.6
10 | com.teckelmedical.mediktor | 50,000+ | 3.62 | SHA256 | 7 | 1 | 2 | 2.08 | 9 | 30
11 | au.org.healthdirect.healthdirectapp | 50,000+ | 3.88 | SHA256 | 8 | 0 | 2 | 2.15 | 5 | 25.4
12 | ai.mayamd.mayamd | 50,000+ | 4.3 | SHA256 | 18 | 0 | 2 | 3.23 | 9 | 9.8
13 | de.msmix.foody.android | 10,000+ | 4.11 | SHA256 | 1 | 0 | 2 | 37.50 | 1 | 13.3
14 | dk.kalorieopslag.symdir | 10,000+ | 3.39 | SHA256 | 0 | 0 | 3 | 40 | 3 | 28.6
15 | com.appcolliders.doctordiagnose | 10,000+ | 3.5 | SHA256 | 2 | 0 | 1 | 0 | 1 | 47.8
16 | com.epainassist.symptomchecker | 10,000+ | 3.28 | SHA256 | 1 | 0 | 3 | 1.02 | 0 | 44.4
17 | baycare.com.healthnav | 10,000+ | 4.18 | SHA256 | 4 | 1 | 2 | 7.89 | 8 | 34.5
18 | com.app.babycheck | 10,000+ | 3.03 | SHA256 | 0 | 0 | 2 | 2.86 | 1 | 63.3
19 | com.bluecreate.vitamincheck | 10,000+ | 4.42 | SHA256 | 16 | 0 | 2 | n.a. | 0 | 2.4
20 | ai.tibot | 10,000+ | 3.74 | SHA256 | 9 | 0 | 3 | 3.06 | 8 | 27.6
21 | andy.symptomes | 10,000+ | 3.79 | SHA256 | 1 | 0 | 2 | 25 | 1 | 0
22 | com.appstronautstudios.heada |  |  |  |  |  |  |  |  |
| chetracker | 5,000+ | 4.19 | SHA256 | 6 | 0 | 2 | 12.50 | 3 | 15.6
23 | com.app.diagnose | 5,000+ | 2.8 | SHA256 | 6 | 0 | 2 | 1.41 | 2 | 38.5
24 | com.ro.doctor31 | 5,000+ | 3.69 | SHA256 | 1 | 0 | 2 | 12.50 | 1 | 40
25 | com.worthyworks.multihtml | 1,000+ | 4.55 | SHA256 | 0 | 0 | 1 | 2.48 | 2 | 5.3
26 | com.sylextech.youshieldapp | 1,000+ | 4.09 | SHA256 | 0 | 0 | 2 | 20 | 0 | 14.3
27 | developer007.magdy.symptomchecker | 1,000+ | n.a. | SHA256 | 0 | 0 | 1 | n.a. | 0 | n.a.
28 | com.pharma.mydiagnosis | 1,000+ | 3.88 | SHA256 | 8 | 0 | 2 | 13.04 | 2 | 0
29 | com.prembros.symptomator | 1,000+ | 3.64 | SHA256 | 4 | 0 | 1 | 33.33 | 0 | 0
30 | com.myownmed.quinnipiac | 500+ | n.a. | SHA256 | 5 | 0 | 2 | n.a. | 3 | n.a.
31 | com.francotiveron.SymptomsChecker | 500+ | n.a. | SHA256 | 0 | 0 | 0 | 7.89 | 0 | n.a.
32 | com.worthyworks.myapplication | 500+ | 3.5 | SHA256 | 2 | 0 | 1 | n.a. | 0 | 20
33 | com.dietchartapp.medweiser | 100+ | 3.67 | SHA256 | 0 | 0 | 0 | 0.32 | 0 | 50
34 | com.nextgenblue.symptomchecker | 100+ | n.a. | SHA256 | 8 | 1 | 2 | n.a. | 0 | n.a.
35 | com.socmedica.symptomchecker | 50+ | n.a. | SHA256 | 18 | 0 | 1 | 10 | 8 | n.a.
36 | de.pr2.ebmapp | 10+ | n.a | SHA256 | 0 | 0 | 1 | 46.43 | 0 | n.a


# Existence of unimodular element in a projective module over symbolic Rees
algebras

Chandan Bhaumik and Husney Parvez Sarwar  (Chandan Bhaumik) Department of
Mathematics, Indian Institute of Technology Kharagpur, Kharagpur 721302, West
Bengal, India<EMAIL_ADDRESS>(H.P. Sarwar) Department of
Mathematics, Indian Institute of Technology Kharagpur, Kharagpur 721302, West
Bengal, India<EMAIL_ADDRESS><EMAIL_ADDRESS>
###### Key words and phrases:

projective modules, unimodular element, symbolic Rees algebra

###### 2020 Mathematics Subject Classification:

Primary 13C10; Secondary 19A13

> _Abstract._ Let $A$ be a symbolic (or an extended symbolic) Rees algebra
> (need not be Noetherian) of dimension $d$. Let $P$ be a finitely generated
> projective $A$-module of rank $\geq$ $d$. Then P has a unimodular element.
> This improves the classical result of Serre for the mentioned class of
> algebras.

##  1\. Introduction

Let $R$ be a commutative ring and $P$ a finitely generated projective
$R$-module. An element $p\in P$ is said to be a unimodular if there exists
$\phi\in{\rm Hom}(P,R)$ such that $\phi(p)=1$, in other words, $P$ splits off
a free summand of rank one, i.e. $P\cong Q\oplus R$ for some projective
$R$-module $Q$. If $R$ is a Noetherian commutative ring of dimension $d$, then
a classical result of Serre [21] asserts that every finitely generated
projective $R$-modules of rank $>d$ has a unimodular element. In fact, this is
the best possible result in general as a common example which can be found
easily in the literature is the tangent bundle over the real algebraic sphere.
Therefore if the ${\rm rank}(P)\leq d$, then the question that $P$ has a
unimodular element, is subtle. In the case ${\rm rank}(P)=\text{\rm dim}(R)$,
where $R$ is an affine algebra over an algebraically closed field, there is a
well developed obstruction theory which is due to Murthy [12, Theorem 3.7].
(For a proof of the hypotheses in [12, Theorem 3.7], see [10, Corollary 1.5]).

Other than Murthy’s works, there are various fascinating obstruction theory in
the literature when $rank(P)\leq\text{\rm dim}(R)$. For this, we recommend the
reader to look at MathSciNet citations of Murthy’s paper [12]. We do not deal
with such a fancy theory here as our paper is in the pursuit of discovering
commutative rings where such an obstruction does not exist.

In this paper, we show that symbolic Ress algebra and extended symbolic Rees
algebras (see Definition 2.6) are examples of commutative rings where such an
obstruction does not exist. The importance of symbolic Rees algebra first
comes from the counterexample of Hilbert’s 14th problem. Rees [16] provided
the first counterexample to Zariski’s version of Hilbert’s 14th problem by
proving an ideal $J$ of $R$ whose symbolic Rees algebra $\mathcal{R}_{s}(J)$
is not finitely generated. We prove the following result about an existence of
a unimodular element in a projective module over a symbolic Rees algebra or
over an extended symbolic Rees algebra.

######  Theorem 1.1.

(Theorem 3.5) Let $R$ be a commutative noetherian domain of dimension $d$ and
$I$ an ideal of $R$. Let $A=\mathcal{R}_{s}(I)$ or $\mathcal{R}_{s}(I,x^{-1})$
(symbolic or extended symbolic Rees algebra)(see Definition 2.6) and $P$ a
finitely generated projective $A$-module of rank $\geq d+1$. Then $P$ has a
unimodular element, i.e. $P\cong Q\oplus A$ for some projective $A$-module
$Q$.

The similar results are obtained for polynomial rings by Plumstead [13], for
Laurent polynomial rings by Mandal [11] and for overring of polynomial rings
by Rao [14]. For Rees algebras, the analogous conjectures are considered in
[15]. The above results are generalized to polynomial and Laurent polynomial
rings for several variables by Bhatwadekar–Roy [3] and Bhatwadekar–Lindel–Rao
[2]. For monoid extension, existence of unimodular problem is considered by
Sarwar [19] [20], Keshari–Sarwar [8], and Keshari–Mathew [9].

Let $R$ be a commutative Noetherian domain of Krull dimension $d$. Then the
Rees algebras over $R$ are Noetherian but symbolic Rees algebras need not be
Noetherian (for example, see [17]). However we can prove the Theorem 1.1
without using the assumption that symbolic Rees algebras are Noetherian. This
is possible because of Heitmann’s result [6] over non-Noetherian rings. For an
extension of Heitmann’s result, see the results of Gupta [5]. Our method is to
use standard sheaf patching techniques. More precisely, we find two covers,
then we prove the results separately on each cover, finally we patch/glue to
get the results over the original space. A similar technique is used in [15].
However there to prove the result in one of the two covers, they have used
Plumstead’s generalized dimension function. Here we prove the similar result
using Heitmann’s result as symbolic Rees algebras need not be Noetherian. In
section $2$, we have recalled some basic definitions and results which will be
used throughout the paper, also we have studied the Krull dimension of
(extended) symbolic Rees algebras via valuation dimension. Theorem 3.5 is
proved in section $3$.

##  2\. Recollection of basic definitions and results

###  2.1. Notation.

Throughout the paper, we assume that the rings are commutative with the unity
and the modules are finitely generated. Also, we assume that projective module
have the constant rank function.

Now we recall some basic notions. For a ring $R$, let $\text{\rm dim}R$ denote
the Krull dimension of $R$. Let ${\rm Ass}\,(R)$ denote the set of associated
prime ideals of $R$, and $\rm ht(I)$ denote the height of the ideal $I$.

######  Definition 2.1 (Unimodular Element).

Let $R$ be a ring $R$ and $M$ an $R$-module. For $m\in M$, we define an ideal
$O_{M}(m)=\\{\varphi(m):\varphi\in M^{*}={\rm Hom}_{R}(M,R)\\}$ of $R$ which
is called the order ideal. The element $m$ in $M$ is called a unimodular
element if $O_{M}(m)=R$, i.e. there exists a surjective $R$-linear map
$\varphi\in M^{*}$ such that $\varphi(m)=1$. Let $\mbox{\rm Um\,}(M)$ denote
the set of all unimodular elements in $M$.

Valuation dimension. The notion of the valuation dimension was introduced by
Jaffard [7]. Let $A$ be an integral domain, an overring $B$ of $A$ is a
subring of the field of fractions $K$ of $A$ that contains $A$, i.e.
$A\subseteq B\subseteq K$.

Valuation overring of $A$ means an overring of $A$ which is a valuation ring.

######  Definition 2.2 (Valuation Dimension).

Let $R$ be an integral domain, the valuation dimension of $R$ is the supremum
of dimensions of the valuation overring of $R$. Valuation dimension of $R$ is
denoted by $\text{\rm dim}_{v}R$, i.e.

$\text{\rm dim}_{v}R={\rm Sup\ }\\{\text{\rm dim}V:V\ \text{is a valuation
overring of}\ R\\}.$

######  Theorem 2.3.

[1, Theorem 0.1] Let $R$ be an integral domain which is not a field, $K$ is a
field of fraction of $R$. Let $F$ denote the algebraic extension of $K$, and
$d$ a positive integer. Then we say, $R$ have finite valuation dimension $d$
(write $\text{\rm dim}_{v}R=d$) if the following equivalent conditions are
satisfied:

  1. (1)

Each valuation overring of $R$ in $F$ has dimension $\leq d$ and there exists
a valuation overring of $R$ in $F$ of dimension $d$.

  2. (2)

Each overring of $R$ in $F$ has dimension $\leq d$ and there exists a overring
of $R$ in $F$ of dimension $d$.

  3. (3)

$\text{\rm dim}R[x_{1},\ldots,x_{d}]=2d$.

  4. (4)

$\text{\rm dim}R[x_{1},\ldots,x_{n}]=n+d$ if $n\geq d-1$.

We say that $\text{\rm dim}_{v}R=\infty$ if there exists no $d$ satisfying the
conditions $1$ to $4$. For the sake of completeness, each field is assigned
valuation dimension $0$.

Clearly $\text{\rm dim}R\leq\text{\rm dim}_{v}R$ for every domain $R$ and if
$B$ is an overring of $A$, then $\text{\rm dim}_{v}B\leq\text{\rm dim}_{v}A$.

###  2.2. Recollection of Rees algebra and Symbolic Rees Algebras.

Let $R$ be a commutative ring and $I$ an ideal of $R$. The Rees algebra (also
known as blow-up algebra) of $R$ with respect to $I$ as a subring of $R[x]$
define to be

$R[Ix]=\\{\sum_{i=0}^{n}a_{i}x^{i}:a_{i}\in I^{i}\\}=\bigoplus_{n\geq 0}\
I^{n}x^{n}\subseteq R[x].$

The extended Rees algebra of $R$ with respect to $I$ as a subring of
$R[x,x^{-1}]$ define to be

$R[Ix,x^{-1}]=\\{\sum_{i=-n}^{n}a_{i}x^{i}:a_{i}\in
I^{i}\\}=\bigoplus_{n\in\mathbb{Z}}\ I^{n}x^{n}\subseteq R[x,x^{-1}].$

where for $n\leq 0$, $I^{n}=R$ by convention.

The following theorem is for the Krull dimension of Rees algebra and extended
Rees algebra (see [22, Theorem 5.1.4]).

######  Theorem 2.4.

Let $R$ be a Noetherian ring and $I$ an ideal of $R$. If $\text{\rm dim}R$ is
finite, then

  1. (1)

$\text{\rm dim}R[Ix]$ = $\text{\rm dim}R+1$, if $I\nsubseteq\mathfrak{p}$ for
some $\mathfrak{p}\in{\rm Spec\,}R$ with $\text{\rm
dim}(R/\mathfrak{p})=\text{\rm dim}R$ and $\text{\rm dim}R[Ix]=\text{\rm
dim}R$, otherwise.

  2. (2)

$\text{\rm dim}R[Ix,x^{-1}]=\text{\rm dim}R+1$.

######  Corollary 2.5.

Let $R$ be a Noetherian domain of dimension $d$ and $(0)\neq I$ an ideal of
$R$. Then $\text{\rm dim}_{v}R[Ix]=d+1$.

For further properties of Rees algebras $R[Ix]$ and extended Rees algebras
$R[Ix,x^{-1}]$, one can see [22].

######  Definition 2.6.

[Symbolic Power, Symbolic Rees Algebra] Let $R$ be a commutative Noetherian
ring and $I$ an ideal of $R$. The $n$-th symbolic power of $I$ is an ideal of
$R$ defined by

$I^{(n)}=\bigcap\limits_{\mathfrak{p}\in{\rm
Ass}\,(R/I)}(I^{n}R_{\mathfrak{p}}\cap R).$

In general, given an ideal $I$ of $R$ the ordinary power $I^{n}$ do not
coincide with the symbolic power $I^{(n)}$. In particular, if
$I=\mathfrak{p}\in{\rm Spec\,}(R)$, then
$\mathfrak{p}^{(n)}=\mathfrak{p}^{n}R_{\mathfrak{p}}\cap R$ and if $I$ is a
maximal ideal $\mathfrak{m}$, then $\mathfrak{m}^{(n)}=\mathfrak{m}^{n}$.
Clearly from the definition $I^{(1)}=I$, $I^{n}\subseteq I^{(n)}$ and
$I^{(n+1)}\subseteq I^{(n)}$ for all $n\geq 1$.

Let $R$ be a commutative noetherian ring and $I$ an ideal of $R$. The symbolic
Rees algebra of $R$ with respect to $I$ is a graded algebra defined as

$\mathcal{R}_{s}(I)=\\{\sum_{i=0}^{n}a_{i}x^{i}:a_{i}\in
I^{(i)}\\}=\bigoplus_{n\geq 0}\ I^{(n)}x^{n}\subseteq R[x].$

Sometimes it is also known as symbolic blow-up algebra. In particular, for all
$n\geq 2$ if $I^{(n)}=I^{n}$, then the symbolic Rees algebra
$\mathcal{R}_{s}(I)$ coincide with the Rees algebra $R[Ix]$.

One can define the extended symbolic Rees algebra of an ideal $I$ of $R$ as an
extension of $\mathcal{R}_{s}(I)$. Let us denote $\mathcal{R}_{s}(I,x^{-1})$
as extended symbolic Rees algebra define to be

$\mathcal{R}_{s}(I,x^{-1})=\\{\sum_{i=-n}^{n}a_{i}x^{i}:a_{i}\in
I^{(i)}\\}=\bigoplus_{n\in\mathbb{Z}}\ I^{(n)}x^{n}\subseteq R[x,x^{-1}].$

where for $n\leq 0$, $I^{(n)}=R$ by convention.

For further properties of $\mathcal{R}_{s}(I)$ and
$\mathcal{R}_{s}(I,x^{-1})$, one can see [4], [22].

######  Lemma 2.7.

Let $R$ be a commutative Noetherian domain of dimension $d$. Then

$\text{\rm dim}\mathcal{R}_{s}(I)=\begin{cases}d,&\text{if}\ I=(0);\\\
d+1,&\text{otherwise}.\end{cases}$

###### Proof.

For $I=(0)$, there is nothing to prove. So we can assume $I\neq(0)$. By
Corollary 2.5, $\text{\rm dim}_{v}R[Ix]=1+d=\text{\rm dim}R[Ix]$. Consider
$R[Ix]\subseteq\mathcal{R}_{s}(I)\subseteq R[x]$. Then $\text{\rm
dim}_{v}\mathcal{R}_{s}(I)\leq\text{\rm dim}_{v}R[Ix]=d+1$ and $\text{\rm
dim}_{v}\mathcal{R}_{s}(I)\geq\text{\rm dim}_{v}R[x]=d+1$. This implies
$\text{\rm dim}_{v}\mathcal{R}_{s}(I)=d+1$. We know that $\text{\rm
dim}\mathcal{R}_{s}(I)\leq\text{\rm dim}_{v}\mathcal{R}_{s}(I)$. Hence
$\text{\rm dim}\mathcal{R}_{s}(I)\leq d+1$.

For the other inequality, note that
$\mathcal{R}_{s}(I)=\mathcal{R}_{s}(I)_{0}\oplus\mathcal{R}_{s}(I)_{+}$, where
$\mathcal{R}_{s}(I)_{0}=R$ and $\mathcal{R}_{s}(I)_{+}=Ix\oplus
I^{(2)}x^{2}\oplus\cdots$, and $\mathcal{R}_{s}(I)/\mathcal{R}_{s}(I)_{+}\cong
R$. Hence $\mathcal{R}_{s}(I)_{+}$ is a prime ideal of $\mathcal{R}_{s}(I)$
and $\rm ht(\mathcal{R}_{s}(I)_{+})>0$. Then we have

$\text{\rm dim}(\mathcal{R}_{s}(I)/\mathcal{R}_{s}(I)_{+})+\rm
ht(\mathcal{R}_{s}(I)_{+})\leq\text{\rm dim}\mathcal{R}_{s}(I).$

This implies that $\text{\rm dim}R+1\leq\text{\rm dim}\mathcal{R}_{s}(I)$.
Therefore $\text{\rm dim}\mathcal{R}_{s}(I)=d+1$. ∎

######  Lemma 2.8.

Let $R$ be a Noetherian domain of dimension $d$. Then $\text{\rm
dim}\mathcal{R}_{s}(I,x^{-1})=d+1.$

###### Proof.

Note that $\text{\rm dim}_{v}R[x^{-1}]=d+1$. Consider
$R[x^{-1}]\subseteq\mathcal{R}_{s}(I,x^{-1})\subseteq R[x,x^{-1}].$ By [1,
Lemma 1.15], $\text{\rm dim}_{v}R[x^{-1}]=\text{\rm dim}_{v}R[x,x^{-1}]$.
Hence $\text{\rm dim}_{v}\mathcal{R}_{s}(I,x^{-1})=1+d$. Then we have
$\text{\rm dim}\mathcal{R}_{s}(I,x^{-1})\leq\text{\rm
dim}_{v}\mathcal{R}_{s}(I,x^{-1})=d+1$.

For the other inequality, from
$R[x^{-1}]\subseteq\mathcal{R}_{s}(I,x^{-1})\subseteq R[x,x^{-1}]$, we observe
that $\mathcal{R}_{s}(I,x^{-1})_{x^{-1}}=R[x,x^{-1}]$. Then we have

$\text{\rm dim}\mathcal{R}_{s}(I,x^{-1})\geq\text{\rm
dim}\mathcal{R}_{s}(I,x^{-1})_{x^{-1}}=\text{\rm dim}R[x,x^{-1}].$

Hence $\text{\rm dim}\mathcal{R}_{s}(I,x^{-1})\geq d+1$. Therefore $\text{\rm
dim}\mathcal{R}_{s}(I,x^{-1})=d+1$. ∎

If $R$ is a Noetherian ring, then we know that the Rees algebra is a finitely
generated $R$-algebra. Unlike Rees algebra, the symbolic Rees algebra is not
necessarily finitely generated $R$-algebra. For example, see [17].

##  3\. Existence of a unimodular element

######  Lemma 3.1.

Let $R$ be a Noetherian ring, $I$ an ideal of $R$, and $T$ be a
multiplicatively closed subset of $R$. Then
$T^{-1}\mathcal{R}_{s}(I)=T^{-1}\mathcal{R}_{s}(T^{-1}I)$, where
$T^{-1}\mathcal{R}_{s}(T^{-1}I)$ means the symbolic Rees algebra of $T^{-1}R$
with respect to $T^{-1}I$.

###### Proof.

By definition $\mathcal{R}_{s}(I)=R\oplus Ix\oplus I^{(2)}x^{2}\oplus\cdots$,
and since the localization commutes with direct sums, we have

$\begin{split}T^{-1}\mathcal{R}_{s}(I)&=T^{-1}R\oplus T^{-1}(I)x\oplus
T^{-1}(I^{(2)})x^{2}\oplus\cdots\\\ &=T^{-1}R\oplus T^{-1}(IR)x\oplus
T^{-1}(I^{(2)}R)x^{2}\oplus\cdots.\end{split}$

Now for $n\geq 1$,

$\begin{split}T^{-1}(I^{(n)})&=T^{-1}(\bigcap\limits_{{\rm
Ass}\,(R/I)}(I^{n}R_{\mathfrak{p}}\cap R))\\\ &=\bigcap\limits_{{\rm
Ass}\,(T^{-1}(R/I))}T^{-1}(I^{n}R_{\mathfrak{p}}\cap R)\\\
&=\bigcap\limits_{{\rm
Ass}\,(T^{-1}R/T^{-1}I))}((T^{-1}I)^{n}(T^{-1}R)_{\mathfrak{p}}\cap
T^{-1}R)\\\ &=(T^{-1}I)^{(n)}.\end{split}$

Since the localization commutes with direct sums, we also have

$T^{-1}\mathcal{R}_{s}(T^{-1}I)=T^{-1}R\oplus
T^{-1}I(T^{-1}R)x\oplus(T^{-1}I(T^{-1}R))^{(2)}x^{2}\oplus\cdots.$

But we already have $(T^{-1}I)^{(n)}=T^{-1}(I^{(n)})$, hence we conclude that
$T^{-1}\mathcal{R}_{s}(I)=T^{-1}\mathcal{R}_{s}(T^{-1}I)$. ∎

The following lemma is a particular case of the previous one. We use the
following version later.

######  Lemma 3.2.

Let $R$ be a commutative Noetherian domain and $(0)\neq I$ an ideal of $R$.
Then

  1. (1)

If $T:=$ set of all non-zero-divisors of $R$,
$T^{-1}\mathcal{R}_{s}(I)=T^{-1}R[x]$.

  2. (2)

If $T=\\{1,a,a^{2},\ldots\\}$ with $a\in I$ is a non-zero-divisor of $R$,
$T^{-1}\mathcal{R}_{s}(I)=R_{a}[x]$.

###### Proof.

$(1)$ Since $R$ is a domain, $T=R^{*}=R\backslash\\{0\\}$. For $n\geq 1$,
$I^{(n)}$ is an ideal of $R$ and $T\cap I^{(n)}\neq\emptyset$. This implies
$T^{-1}(I^{(n)})=T^{-1}R$. Hence by 1st part of the proof of Lemma 3.1, we get
$T^{-1}\mathcal{R}_{s}(I)=T^{-1}R[x]$.

$(2)$ By [15, Lemma 3.1], we have $T^{-1}R[Ix]=T^{-1}R[(T^{-1}I)x]$. Since
$T\cap I\neq\emptyset$ this implies $T^{-1}R[Ix]=T^{-1}R[x]$. Consider

$R[Ix]\subseteq\mathcal{R}_{s}(I)\subseteq R[x].$

After localize at $T$, we have

$T^{-1}R[Ix]\subseteq T^{-1}\mathcal{R}_{s}(I)\subseteq T^{-1}R[x].$

Therefore $T^{-1}\mathcal{R}_{s}(I)=R_{a}[x]$. ∎

######  Lemma 3.3.

Let $R$ be a commutative domain of dimension $d$ and $A=R_{1+aR}$, where $a$
is a non-zero non-unit element of $R$. Let $P$ be a projective $R$-module of
rank $\geq d$. Let $Q:=P_{1+aR}$. Then $Q$ has a unimodular element.

###### Proof.

Let ‘overbar’ denote the going modulo the ideal $aR$. Since $(0)$ is the
minimum prime ideal in the domain $R$, we observe that $dim(\overline{R})<d$.
By [6, Corollary 2.6], $\overline{P}$ has a unimodular element. Therefore
there exists $\overline{p}$ such that the order ideal
$O_{\overline{P}}(\overline{p})=\overline{R}$. Let $p\in P$ be a lift of
$\overline{p}$. Now observe that $1+aR\subset$ of the order ideal $O_{P}(p)$.
Hence $p_{1+aR}$ is a unimodular element of $Q$. This finishes the proof. ∎

The following theorem is a result of Ravi A. Rao [14, Theorem 5.1(I)].

######  Theorem 3.4.

Let $R$ be a commutative Noetherian ring of dimension $d$, and $S$ be a
multiplicative closed set of non-zero-divisors of $R[x]$. Let $A$ be a ring
lying between $R[x]$ and $S^{-1}R[x]$. Then for $n\geq d+2$, E${}_{n}(A)$ acts
transitively on Um$(A^{n})$.

######  Theorem 3.5.

Let $R$ be a commutative Noetherian domain of dimension $d$ and $I$ an ideal
of $R$. Let $A=\mathcal{R}_{s}(I)$ or $\mathcal{R}_{s}(I,x^{-1})$ and $P$ a
finitely generated projective $A$-module of ${\rm rank}\geq d+1$. Then $P$ has
a unimodular element.

###### Proof.

First, we assume that $A=\mathcal{R}_{s}(I)$. Let ${\rm rank}(P)=m>d$. Since
$A$ is a subring of an integral domain $R[x]$, $A$ is an integral domain. If
$I=(0)$, then $I^{(n)}=(0)$ this implies $A=R$. In this case, the theorem
follows from Serre [21]. If $I=(1)$, then $I^{(n)}=(1)$ this implies $A=R[x]$.
In this case, the theorem follows from Plumstead [13, Corollary 4]. So we can
assume $I\neq(0)$ and $I\neq(1)$. By Lemma 2.7, $\text{\rm
dim}\mathcal{R}_{s}(I)=d+1$.

Let $T$ be the set of all non-zero-divisors of $R$. By Lemma 3.2(1),
$T^{-1}A=T^{-1}R[x]$, where $T^{-1}R$ is a quotient field of $R$. Since
$T^{-1}R[x]$ is a PID, $T^{-1}P$ is a free module over $T^{-1}A$. Since $P$ is
finitely generated, there exists $t\in T$ such that $P_{t}$ is a free
$\mathcal{R}_{s}(I)_{t}$-module. Let $0\neq a$ be a non-unit element of $I$.
Then $P_{at}$ is a free $\mathcal{R}_{s}(I)_{at}$-module.

Denote $b=at$. By Lemma 3.2(2), we have $\mathcal{R}_{s}(I)_{b}\cong
R_{b}[x]$. Now consider the following Cartesian square of rings

${\mathcal{R}_{s}(I)}$${\mathcal{R}_{s}(I)_{b}\cong
R_{b}[x]}$${\mathcal{R}_{s}(I)_{1+b\mathcal{R}_{s}(I)}}$${R_{b}[x]_{1+b\mathcal{R}_{s}(I)}.}$$\scriptstyle{i_{1}}$$\scriptstyle{i_{2}}$$\scriptstyle{j_{1}}$$\scriptstyle{j_{2}}$

Since $P_{b}$ is a free $A_{b}$-module of rank $m$, $P_{b}\cong A_{b}^{m}$.
Hence $P_{b}$ has a unimodular element say $p_{1}$. Since $P_{1+bA}$ is
projective $A_{1+bA}$-module, by Lemma 3.3(1), $P_{1+bA}$ has a unimodular
element say $p_{2}$. Hence we have $P_{1+bA}\cong p_{2}A_{1+bA}\oplus Q$, with
projective $A_{1+bA}$-module $Q$.

Now consider
$B=A_{b(1+bA)}=(1+bA)^{-1}\mathcal{R}_{s}(I)_{b}=(1+bR)^{-1}D^{-1}R_{b}[x]=D^{-1}R^{{}^{\prime}}[x]$,
where $D$ is a multiplicative closed subset of $R^{{}^{\prime}}[x]$ and
$R^{{}^{\prime}}=R_{b(1+bR)}$ is of dimension $d-1$. Since $P_{b(1+bA)}$ is a
free $B$-module of rank $m$, $P_{b(1+bA)}\cong B^{m}$. Let $\bar{u}$ and
$\bar{v}$ be the image of $p_{1}$ and $p_{2}$ respectively in $P_{b(1+bA)}$.
Now consider the following cartesian square of projective modules.

${P}$${P_{b}}$${P_{1+bA}}$${P_{b(1+bA)}\cong
B^{m}}$$\scriptstyle{i_{1}}$$\scriptstyle{i_{2}}$$\scriptstyle{j_{1}}$$\scriptstyle{j_{2}}$

Note that the ring $B$ lying between $R^{{}^{\prime}}[x]$ and
$S^{-1}R^{{}^{\prime}}[x]$, where $S$ is a set of all non-zero-divisors in
$R^{{}^{\prime}}[x]$. Then by Theorem 3.4, there exists $\sigma\in$
E${}_{m}(B)$ such that $\sigma(\bar{u})=\bar{v}$. By [18, Corollary 3.2] (see
also [2, Proposition 3.2]), we can split $\sigma$ as
$(\sigma_{1})_{b}(\sigma_{2})_{1+bA}$, where $\sigma_{2}\in$ E$(P_{b})$ and
$\sigma_{1}\in$ E$(P_{1+bA})$. Since
$(\sigma_{1})_{b}(\sigma_{2})_{1+bA}(\bar{u})=\bar{v}$, for suitably changing
$p_{1}$ and $p_{2}$, we can assume that $\bar{u}=\bar{v}$.

Now consider the following fiber product diagram of projective modules.

${P}$${P_{b}\cong A_{b}^{m}}$${A}$${A_{b}}$${P_{1+bA}\cong A_{1+bA}\oplus
Q}$${P_{b(1+bA)}}$${A_{1+bA}}$${A_{b(1+bA)}}$$\scriptstyle{\psi}$$\scriptstyle{\psi_{1}}$$\scriptstyle{\psi_{2}}$

Since $\psi_{1}$ and $\psi_{2}$ are surjective homomorphisms, from the above
diagram, we get a surjective homomorphism $\psi:P\twoheadrightarrow A$. Hence
there is $p\in P$ such that $\psi(p)=1$. Therefore $P$ has a unimodular
element.

When $A=\mathcal{R}_{s}(I,x^{-1})$, the proof is a verbatim copy of the above.
However one needs to use [11, Theorem 2.1] in the second corner. A diligent
reader can work out the details. ∎

Acknowledgement: H.P. Sarwar would like to thank S.E.R.B. Govt. of India for
the grant SRG/2020/000272.

## References

  * [1] D.F. Anderson, A.Bouvier, D. Dobbs, M.Fontana and S.Kabbaj. On Jaffard domains, Expo. Math. 6 (1988), 145-175.
  * [2] S.M. Bhatwadekar, H. Lindel and R.A. Rao. The Bass-Murthy question: Serre dimension of Laurent polynomial extensions, Invent. Math. 81 (1985) 189-203.
  * [3] S.M. Bhatwadekar and A. Roy. Some theorems about projective modules over polynomial rings, J. Algebra 86 (1984), 150-158.
  * [4] W. Bruns and U. Vetter. Determinantal Rings, Lecture Notes in Mathematics. Springer-Verlag, Berlin 1988.
  * [5] A. Gupta. On the existence of unimodular elements and cancellation of projective modules over noetherian and non-noetherian rings, J. Algebra 446 (2016), 323-345.
  * [6] R. Heitmann. Generating non-noetherian modules efficiently, Michigan Math. 31 (1984), no 2, 167-180.
  * [7] P. Jaffard. Th$\acute{e}$orie de la Dimension des Anneaux de Polyn$\hat{o}$mes, M$\acute{e}$m. Sc. Math. 146, Gauthier-Villars, Paris, 1960.
  * [8] M.K. Keshari and H.P. Sarwar. Serre dimension of monoid algebras, Proc. Indian Acad. Sci. Math. Sci. 127 (2017), no. 2, 269-280.
  * [9] M.K. Keshari and M.A. Mathew. On Serre dimension of monoid algebras and Segre extensions, Journal of Pure and Applied Algebra 226 (2022), no. 9, Paper No. 107058, 16 pp.
  * [10] A. Krishna. Murthy’s conjecture on 0-cycles. Invent. Math. 217 (2019), no. 2, 549–602.
  * [11] S. Mandal. Basic elements and cancellation over Laurent polynomial rings, J. Algebra 79 (1982), 251-257.
  * [12] M.P. Murthy. Zero cycles and projective modules. The Annals of Mathematics, 140(2), 405, 1994.
  * [13] B. Plumstead. The conjectures of Eisenbud and Evans, Amer. J. Math. 105 (1983), 1417–1433.
  * [14] R.A. Rao. Stability theorems for overrings of polynomial rings. II. J. Algebra 78 (1982), no. 2, 437–444.
  * [15] R.A. Rao and H.P. Sarwar. Stability results for projective modules over Rees algebras, Journal of Pure and Applied Algebra, 223 (2019), no 1, 1-9.
  * [16] D. Rees. On a problem of Zariski, Illinois Journal of Mathematics 2 (1958), no. 1, 145-149.
  * [17] P.C. Roberts. A prime ideal in a polynomial ring whose symbolic blow-up is not noetherian, Proc. Amer. Math. Soc. 94 (1985), no. 4, 589-592.
  * [18] A. Roy. Application of patching diagrams to some questions about projective modules, J. Pure Appl. Algebra 24 (1982), no. 3, 313-319.
  * [19] H.P. Sarwar, Some results about projective modules over monoid algebras. Comm. Algebra 44 (2016), no. 5, 2256–2263.
  * [20] H.P. Sarwar. $K_{0}$-stability over monoid algebras, Annals of K-theory, 6 (2021), no. 4, 629–649.
  * [21] J.-P. Serre, Modules projectifs et espaces fibrés à fibre vectorielle, 1958 Séminaire P. Dubreil, M.-L. Dubreil-Jacotin et C. Pisot, 1957/58, Fasc. 2, Exposé 23 18 pp.
  * [22] I. Swanson and C. Huneke. Integral closure of ideals, rings, and modules, London Mathematical Society, Lecture Note Series 336, Cambridge, 2006.