dataesr/scientific-paragraphs-categorization huggingface dataset:
First, data generated by health sensors are inserted into HBase using a mass insertion script, and then a data analysis algorithm is proposed in order to retrieve valuable data and help in predicting disease. In  [14] , the authors proposed a Hadoop-based framework in order to secure the transmitted data from biosensors to the server. The proposed framework relies on three main pillars: The Hadoop clusters for storing, backing up, and recovering data; a digital signature method, called ECC (Elliptic Curve Cryptography), which is implemented in Sunspot nodes in order to secure communication; and the Sqoop tool, which is used to import and export data between Mysql and Hadoop HDFS. In  [15] , a modern platform for healthcare information systems consisting of three layers is proposed. The first layer is composed of various data health sources such as sensors, clinical report, medication, etc.
The second layer aims to process and store data and it uses various Hadoop tools including Sqoop, HDFS, HBase, MapReduce. and Hive. The last layer is responsible for applying business intelligence (BI) solutions over the stored data and it uses SpagoBI tools as an open source BI suite. Lastly, the authors of  [16]  proposed a correlation-based outlier detection platform, relying on Hadoop, to handle streaming of data generated in health applications. The objective of the platform is to search statistical relationships among biosensors, and then, in a later step, to predict contextual anomalies using an aggregated outlier checker. Recently, the authors of  [19] [20] [21] [22]  opened a new trend in sensing-based healthcare by proposing several frameworks for real-time patient monitoring and assessment.
• Real time patient monitoring: This layer consists of data sources and data ingestion tools. Data sources are the active biosensors which allow continuously monitoring a patient and send data in real-time toward the data storage via data ingestion tools. In addition, data sources could be an archive of patients' records which is already built by the hospital, mostly based on relational database system, and should also be sent toward the data storage center. We use two ingestion tools, namely kafka [23] and sqoop  [24] , to process and store streaming of data coming from different data sources.
Kafka Kafka  [23]  is an open-source data ingestion tool used to handle massive real-time data. Today, it is used in many applications such as real-time monitoring of British gas smart home, matching driver and passenger at Uber, etc. Among other data ingestion tools, the selection of Kafka is motivated by: (1) its high horizontal scalability (up to hundreds of server nodes); (2) it can read data directly from the biosensors; (3) it decreases latency much than other tools; and (4) it is easy to be implemented and used thanks to built-in libraries in Python. Generally, Kafka is based on the concept of "topics" and data are stored in the form of key-values. In our platform, we installed Kafka on the master cluster node (called broker) and we create a topic, named "Col2Proc", allowing to read streaming data from biosensors then send them to further processing (e.
Sqoop Sqoop [24] is a command line interface application used to transfer data between relational databases (RDB) and Hadoop nodes. Import and Export Sqoop are the major operations in Sqoop and used to transfer data from RDB to Hadoop and vice versa, respectively. In our platform, Sqoop is used in allow medical administrators to directly integrate their patients' archive, supposed to be built with RDB, into Hadoop cluster nodes without any further processing operation. This service makes our platform more efficient and attractive for hospitals.
Apache Spark Spark  [25]  is an open-source cluster computing platform which is widely used for data processing in Hadoop ecosystems. In our framework, Spark is selected among other existing tools due to three major characteristics required in sensing-based healthcare: first, it supports both batch and streaming processing which are necessary to apply various data analytical algorithms; second, it ensures a lower latency level than other tools such as MapReduce, which is strongly required in health applications; and third it guarantees scalability to any number of cluster nodes required for the health application requirements. Therefore, in our platform, we implemented Spark on the master cluster node in order to receive data streaming from Kafka, perform processing, and send data to the Hadoop HDFS for storing purpose.
Hadoop HDFS Hadoop HDFS  [26]  It is a distributed file system that stores data across a set of machines, known as cluster nodes. Hadoop HDFS splits received data into blocks, and then it distributes across the nodes. Generally, it is characterized by two aspects: First, it ensures high data reliability thanks to the replication process of data into nodes (at least three). This aspect is very useful in sensing-based healthcare so patient archives will never be lost if any hardware failure occurs. Second, data in Hadoop HDFS are treated in parallel computing so a high data retrieval process is ensured, which is necessary for heath application especially in emergency cases. In our platform, we created three cluster nodes while implementing Hadoop HDFS on each of them to store patient records in HDFS files.
In our platform, we benefit from the Python open source libraries which offer a huge number of functions allowing to preprocess the data before any analysis. Some of the most useful libraries dealing with missing values in Python include Pandas, NumPy, and Scikit-Learn. Subsequently, the missing values can be estimated using functions such as replace, isnull, dropna, fillna, and fit_transform, or using prediction functions such as interpolate. In our simulation, we created a script for Spark called MissRec that allows estimating the missing records during a period of time while focusing on two main functions: ExponentialSmoothing and nanmean. After estimating the missing records, the Spark script sends the regenerated records to the HDFS for storage.
Therefore, stab ranges between 0 and 100, where 0 means that both patients have similar stable situation and 100 indicates a severely unstable situation for both patients. Basically, SKmeans allows patients with similar situation progress to be grouped together in order to find patient correlation and understand the behavior of certain diseases. In our platform, patients can be classified according to one or all vital signs depending on the medical needs. For the sake of simplicity, we describe, in the next section, the process of SKmeans based on one patient's vital signs v ∈ V but similar process can be adapted to all other vital signs. Similar to traditional Kmeans, the idea of SKmeans is to first define a positive number of clusters (K) and then a set of K datasets is randomly selected as the initial centroids of the clusters.
After that, for each dataset, the distances to all centroids are calculated where the dataset is assigned to the nearest one. At this point, the new centroid is recomputed for each cluster and the process is repeated until the convergence of the algorithm. Obviously, the optimal number of clusters (K) can be selected depending on the number of patients in the hospital and their situations. However, compared to traditional Kmeans, SKmeans has two main differences: • First, patients are grouped according to the scores of records and not the records themselves.
Layer 4: Data Retrieval and Visualization The last layer of our platform is dedicated to allow medical staff access to the patient records stored in the Hadoop HDFS. It relies on two data retrieval tools (Hive and Spark SQL) and one graphing tool (Matplotlib). On the one hand, data retrieval tools are responsible for obtaining data from the Hadoop storage system using a set of criteria defining via queries. The retrieved data are mostly stored in a file or displayed on the screen. On the other hand, data visualization is simply a graphical representation of the retrieved data using statistical graphics or plots. In the next sections, we highlight each tool used in our platform.
Hive Hive [28] is software used for data warehousing implemented on top of Hadoop HDFS in order to provide data query and analysis. In addition, Hive allows creating a metadata storage in the form of tables in a relational database system. This makes our platform more efficient in terms of reducing the access time to the patient archive. On the other hand, it helps the medical staff to keep track of the criticality of patients in real-time. In our platform, we installed Hive on the cluster master node and we created an external table located in the HDFS main directory, where the medical staff can explore the data imported to HDFS using HiveQL console. To retrieve the data, they have to write HiveQL queries depending on their requirements. For instance, they can ask for all patient IDs having critical HR records as follows: SELECT patient_id FROM Patient W HERE record < 51 or record > 90.
Spark SQL Spark SOL [25] is a component that can be installed on top of Spark core and aims to provide a data abstraction called DataFrames to handle structured database. DataFrames is usually handled using a specific language named domain-specific language (DSL)  [25] , which is manipulated using Python in our platform. After installing it on the master node, the medical staff can run the Spark SQL console using the command spark-sql to access the patient data on Hadoop storage. Then, they have to use HiveQL syntax, which is supported by Spark SQL to make various queries.
Matplotlib Matplotlib  [29]  is the most used plotting library in Python programming with its extension NumPy. In our platform, we created a Python script that allows reading periodic patient data sent to Hadoop storage and visualizing them, using Matplotlib, on a real-time graph to the medical staff. An important extension which can be added later to our platform is to send plotting graphs to the clinicians using mobile application, so that they can monitor the patient situation far from the hospital.
System Demonstration and Evaluation To evaluate its performance, we developed our platform based on two phases: Hadoop installation and algorithms' implementation. On the one hand, we installed Hadoop 3. 0. 1 on a physical machine with an i7 processor, 8 CPUs 2. 70 GHz, and 16 GB of memory. Then, we created a four-node Hadoop cluster on four virtual machines with Ubuntu 18. 04 as an operating system. In addition, a virtual machine was configured to act as the master node and the three other machines were configured to act as slave nodes. We installed all layer tools (ingestion, processing, and visualization) on the master node while the slave nodes were responsible for storing patient data. On the other hand, we used real health data collected from MultipleIntelligent Monitoring in Intensive Care (MIMIC) database of PhysioNet  [32].
MIMIC contains data for about 72 patients where records about vital signs include Heart Rate (HR), Systolic Blood Pressure (SBP), Respiration Rate (RR), and Oxygen Saturation (OS). Every second, the biosensor collects new reading for each vital sign, and then it sends toward the Hadoop cluster for processing and archiving purposes. In our simulation, we used a file that includes a log of about 100,000 readings for each patient. To make our simulation more realistic, patient records are stored separately in a file in the main directory of the master node. Then, we created Java and Python scripts that allow reading data for each patient while applying one of the proposed algorithms. Table  2  summarizes the parameters used in our platform with their tested values.
Records Patients Study In this section, we show the patient situation progress after storing data in the HDFS which can help in understanding the stability level of each patient. In Figure  4a , we show a portion of 15, 000 record values (e. g. , 4 h) for each vital sign of a patient while, in Figure  4b , we only show HR records for three patients with different criticality situations, namely low, medium, and high. The obtained results reveal many observations: First, the stored records for each vital sign of a patient are highly redundant. Second, we can also observe that some vital signs are correlated where the variation/stability of one can influence the others (Figure  4a ). Third, we notice that low and high criticality patient situations produce more data redundancy than a patient with medium situation (Figure  4b ).
Real time data decision and data storage: This layer uses Spark [25] and Hadoop HDFS (Hadoop Distributed File System) [26] to process and store data, respectively. After installing it on the master cluster node, Spark receives data coming from Kafka and applies two algorithms: the first one allows detecting emergency situations and then taking the right action by the medical staff and the other searches for missing records before sending the final data to the HDFS for storage. Subsequently, data are stored in three Hadoop nodes according to HDFS cluster computing. • Patient classification and disease diagnosis: This layer uses batch mode processing and aims to classify and find the correlation after data storing. Two algorithms are proposed: The first one uses an adapted version of Kmeans [27] clustering and aims to find patients with similar situations.
• Real time data decision and data storage: This layer uses Spark [25] and Hadoop HDFS (Hadoop Distributed File System) [26] to process and store data, respectively. After installing it on the master cluster node, Spark receives data coming from Kafka and applies two algorithms: the first one allows detecting emergency situations and then taking the right action by the medical staff and the other searches for missing records before sending the final data to the HDFS for storage. Subsequently, data are stored in three Hadoop nodes according to HDFS cluster computing. • Patient classification and disease diagnosis: This layer uses batch mode processing and aims to classify and find the correlation after data storing. Two algorithms are proposed: The first one uses an adapted version of Kmeans [27] clustering and aims to find patients with similar situations.
Online advertising is a wealthy industry that generated more than $100B in 2018 only in the US and delivers billions of ads to Internet users every day with. These impressive numbers have also attracted the attention of malicious players that try to exploit the online advertising ecosystem for their own benefit. In particular, one of the most harmful practices refers to malicious users that act as advertisers to deliver unsafe ads. The goal of these ads is to compromise the security of the users that receive those ads. This practice is referred to as Malvertising. Some reports have estimated the economic loss caused by malvertising to the online advertising sector to $1. 1B in 2017. This paper is the first work that analyses and quantifies the impact of malvertising in Facebook. To accomplish this study, we rely on a dataset that includes more than 5 M ads delivered to 3 K Facebook users from 126 K advertisers between October 2016 and May 2018.
Most of these works works rely on datasets including only tens of thousands of ads to derive their conclusions. Our paper contributes to the literature by performing the first analysis of malvertising in Facebook (FB). FB is one of the most popular online services in the Internet with more than 2. 4 B monthly active users  [11] , and it is the second player in terms of revenue in the online advertising ecosystem after Google  [12]. The FB advertising platform differs from the standard online advertising ecosystem operating in websites and mobile apps, because it does not allow including code in the ads. While ads running malicious code is one of the main sources of malvertising in websites and mobile apps, this attack cannot be run in FB. Hence, all the solutions in the literature that analyze code injected in ads do not apply in the case of Facebook.
To this end, we rely on a large dataset that includes more than 5 M ads delivered to 3 K FB users from 122 K advertisers in the period October 2016-May 2018. This dataset has been collected using the web browser extension FDVT  [14]. The FDVT retrieves, among other things, the ads FB delivers to FDVT users. To our knowledge, this is the largest dataset that is used to study malvertising. It is also important to highlight that our research is the only one that quantifies the portion of users actually exposed to malvertising. This happens because our work relies on ads delivered to real users, whereas previous research works use automated software browsing in websites or mobile apps but does not involve real users. In addition, we aim to understand whether the impact of malvertising in FB is more relevant than in other online services.
To this end, we compare the results of malvertising in FB to the malvertising observed in regular websites. To measure malvertising in regular websites, we use a dataset  [15]  that includes 40 K ads delivered to 589 users from more than 20 K advertisers. Finally, our last contribution is a solution that blocks potentially unsafe ads in FB in real-time in the end-user premises. To conclude the introduction, we summarize the main findings of our work: • Despite that malvertising only contributes 0. 17% of the ads in our dataset, our results reveal that 1/3 of the FDVT users were exposed to unsafe ads, and almost 18% to an ad related to highly risky malvertisers.
Fdvt: Data Valuation Tool for Facebook Users The FDVT  [14]  is a web-browser add-on that informs Facebook users of an estimation of the revenue that they are generating for FB based on the ads they receive and click while browsing in FB. After installing the add-on, users have to follow a registration process in which they are asked to fill a small profile: country, gender, age, and relationship status. Only the country parameter is compulsory to use the FDVT. In addition, users have to accept the terms of use, the privacy policy and proactively provide permission to use the data (anonymously) collected for research purposes. To the best of our knowledge, this guarantees that the dataset used in this paper is compliant with the most recent data protection regulations. The FDVT also collects information related to the ads delivered to the user.
In particular, the FDVT collects: the timestamp when the ad was delivered, the position of the ad (either newsfeed or right side of the wall), and the url(s) embedded in the ad that will forward the user to the advertiser landing page. All of this information is collected from each FB session. The core dataset of this study has been collected while using the FDVT add-on and it includes information of ads delivered to 3 K users between October 2016 and May 2018  [16].
Facebook Dataset Our research relies on a large dataset  [16]  that includes 5,302,179 ads delivered to 3001 FDVT users across 564,138 sessions. This dataset was collected between October 2016 and May 2018. In this study, we identify advertisers by the web-domain associated to the landing page the user would reach in the case she clicks on the ad. In turn, we classify the risk level of advertisers based on the reputation field that we obtain from the McAfee's SiteAdvisor service  [13]  for the advertiser's web domain. The reputation field defines the risk level McAfee assigns to that website and is divided into four potential categorical values: Minimal Risk, Slightly Risky, Highly Risky, Unknown. Note that the reputation values used in this paper were retrieved in December 2018, and some of them may have changed by the time this article becomes public.
Next, for a better understanding we classify advertisers into the following security levels: (i) Safe when its associated web domain was assigned the Minimal Risk reputation; (ii) Unsafe when the reputation field was either Slightly or Highly risky; (iii) Highly Risky in the case the reputation field was Highly Risky. In our work, Unsafe and Highly Risky advertisers are considered as potential malvertisers, and the ads they deliver as potentially unsafe for FB users. Finally, note that the advertisers classified as Unknown by McAfee are filtered from our dataset, since we cannot establish whether they are safe or unsafe. In addition to the risk label, McAfee also assigns topic labels (e. g. , online shopping, marketing, phishing, etc. ) to the domains we evaluate. There are more than hundred different topics and each domain is assigned between one and three topics.
We complete our dataset with the topics that are associated to each advertiser. As we already clarified in the introduction, this paper adopts a conservative approach widely applied in the area of cybersecurity. Our goal is to reduce as much as possible the impact of attacks by minimizing the number of false negatives. Let us assume a scenario where there are N sources classifying domains as either NO RISK or RISK. There could be approaches that aim to maximize the accuracy on the detection of RISK domains by combining the signals received from the N sources. Although this may be a reasonable approach that tries to avoid both false positive and false negatives, in the area of cybersecurity usually the goal is to minimize as much as possible false negatives. To this end, the best option is to adopt a conservative approach that considers as unsafe a domain as soon as one of the N sources reports that website as RISK.
Web Dataset In this paper, we compare the volume of malvertising in FB to regular websites. To that end, we borrowed a dataset collected from ads delivered in regular websites from Iordanou et al. [15]. This dataset includes 589 users that received 41 K ads from 20. 5 K advertisers across standard websites. As we did for the case of FB, we classify the ads (and associated advertisers) using the reputation category McAfee assigns to the landing domain associated to the ad into: Safe, Unsafe, and Highly Risky. Note that the this dataset is not a representative sample of the whole web, and thus the extracted result are not generalizable. Still, we believe comparing FB and the web using two datasets involving real users is a relevant analysis to understand whether we can expect a similar exposure of users to unsafe ads across different online services.
User Exposure to Malvertising Metrics The previous two metrics quantify the presence of malvertisers and the ads they generate, but they are not valid to measure the actual exposure of users to unsafe ads. Theoretically, a single advertiser with a single ad campaign could reach all of the users in FB. Therefore, to measure the exposure of users to malvertising we need to quantify the portion of users that have received unsafe ads. To this end, we define the following metrics: - U tot , where U risky refers to the number of users in our dataset that have received some highly risky ad.
Methodology Overview Our analysis starts by applying the defined metrics to the FB dataset to understand the presence of malvertisers and unsafe ads and the exposure of users to them in FB. Next, we compare the malvertising in the case of FB to the case of the web. Finally, for the case of FB, we divide the users in our dataset based on gender and age in order to analyze whether there are significant differences in the exposure of different demographic groups to malvertisers and unsafe ads. This analysis allows to reveal, for instance, whether women are more exposed than men to malvertising, or if young users are more likely to receive unsafe ads than senior ones.