Mauro Cherubini
email: mauro.cherubini@unil.ch

Alexandre Meylan
email: alexandre.meylan@unil.ch

Bertil Chapuis
email: bertil.chapuis@unil.ch

Mathias Humbert
email: mathias.humbert@epfl.ch

Igor Bilogrevic
email: ibilogrevic@google.com

Kévin Huguenin
email: kevin.huguenin@unil.ch

Towards Usable Checksums: Automating the Integrity Verification of Web Downloads for the Masses

Keywords:

Internet users can download software for their computers from app stores (e.g., Mac App Store and Windows Store) or from other sources, such as the developers' websites. Most Internet users in the US rely on the latter, according to our representative study, which makes them directly responsible for the content they download. To enable users to detect if the downloaded files have been corrupted, developers can publish a checksum together with the link to the program file; users can then manually verify that the checksum matches the one they obtain from the downloaded file. In this paper, we assess the prevalence of such behavior among the general Internet population in the US (N = 2,000), and we develop easyto-use tools for users and developers to automate both the process of checksum verification and generation. Specifically, we propose an extension to the recent W3C specification for sub-resource integrity in order to provide integrity protection for download links. Also, we develop an extension for the popular Chrome browser that computes and verifies checksums of downloaded files automatically, and an extension for the WordPress CMS that developers can use to easily attach checksums to their remote content. Our in situ experiments with 40 participants demonstrate the usability and effectiveness issues of checksums verification, and shows user desirability for our extension.

CCS CONCEPTS

• Security and privacy → Web protocol security; Usability in security and privacy; Hash functions and message authentication codes;

INTRODUCTION

Nowadays, Internet is the main source for users to obtain programs for their computers. A popular and convenient way to download programs is to use official app stores such as Apple's Mac App Store and Microsoft's Windows Store. Such platforms, however, have several drawbacks for developers, including long review and validation times, technical restrictions (e.g., sandboxing), incompatibility with software licenses, and substantial commissions [START_REF] Turner | Developers Consider Apple's App Store Restrictive and Anticompetitive, Report Shows[END_REF]. Therefore, it is quite common that developers make their programs available directly from their websites. This is the case of popular programs such as VLC media player, OpenOffice, and GIMP.

When developers make programs available from their websites, they can either host them directly on the same server as the website or rely on so-called third-party hosting platforms, such as mirrors and content delivery networks (CDNs) that provide substantial improvements for the users in terms of performance (e.g., bandwidth) and availability. However, this latter solution means relinquishing control over the program files and fully trusting the third-party platform: If the CDN is hacked, the programs can be corrupted to include all sorts of malware, thus infecting the computers of the users willing to install and run the original program. Recently, both the popular BitTorrent client Transmission [START_REF]Transmission Hijacked Again to Spread Malware[END_REF][START_REF] Khandelwal | Flaw in Popular Transmission BitTorrent Client Lets Hackers Control Your PC Remotely[END_REF] and the Linux Mint distribution [START_REF]Linux Mint Website Hacked; ISO Downloads Replaced with a Backdoor -Security News -Trend Micro USA[END_REF][START_REF] Warren | Popular BitTorrent Client Transmission Gets Infected With Malware Again[END_REF] were corrupted by injecting, in the original programs, a ransomware in the former, and a backdoor in the latter. Such corruptions are particularly problematic for privacy and security software (e.g., PGP) used by at-risk populations such as journalists and political dissidents. This applies to all files that can harm a user's device; even PDF files can be infected. In general, it is crucial for website administrators to make sure that the content of the files downloaded by their visitors through external links matches the content of the files at the time the link was created. It would indeed be problematic (not only from a security point of view) if a picture linked from a website would be replaced by another one.

A popular way for developers to enable users to detect accidental or intentional modifications of their program files hosted on external platforms, such as mirrors and CDNs, is to provide so-called checksums on their websites. This practice is quite common in the open-source community but also for companies such as Google (e.g., checksums for Android Studio). Such checksums are usually derived from the output of cryptographic hash functions (e.g., SHA-1), in the form of sequences of alphanumeric digits called digests and displayed on the download webpages, or from digital (detached) signatures provided in separate files. Users can verify the integrity of the program files they download based on the provided checksums;1 however, it usually requires the users to execute dedicated (command line) 2 programs and to manually compare long sequences, which has been proven, in contexts different from web downloads (e.g., PGP key fingerprint verification), to suffer from usability issues and to be error prone [START_REF] Hsu-Chun | A Study of User-Friendly Hash Comparison Schemes[END_REF][START_REF] Dechand | An Empirical Study of Textual Key-Fingerprint Representations[END_REF]. Other solutions, such as code-signing, also suffer from some limitations and only partially address the aforementioned problem. These issues call for automated and reliable methods.

In this paper, we consider the context of a website administrator (e.g., a software developer or vendor) who includes a link on one of their webpages for downloading a file such as a program. The program file is hosted on a third-party server (i.e., different from the server hosting the website, e.g., mirrors, CDNs) that is not controlled by the website administrator. In order to check the integrity of the file after download, this website administrator includes a checksum of the program file on their website (not hosted on the third party server) . The threat we consider is the case where the file pointed to by the link is corrupted, for instance by the third-party server operator or by hackers; furthermore, the checksum of the corrupted file can partially match that of the original file (e.g., the first ten digits match). And the users who download the file do not verify its checksum or do so in an inattentive way. To the best of our knowledge, no practical solution has been proposed for automatically verifying web downloads and the general topic of the integrity of programs downloaded on the Web has been mostly overlooked. We explore this research gap and address these challenges by performing a thorough analysis of the common practices regarding the use of checksums and their usability and effectiveness, and by proposing technical solutions to the issues we identify. Specifically, our contributions are as follows:

• We conduct the first comprehensive study on the use of checksums for verifying the integrity of web downloads. We rely on several instruments: a large-scale online survey with 2,000 participants to assess Internet users' knowledge of checksums and security behavior in general with respect to web downloads of program files; a website survey of 20 download pages of popular programs to assess how developers use checksums; and an in situ experiment with 40 participants that uses an eye-tracker to precisely evaluate how users verify checksums. It is the first time that eye-tracking technologies are used for studying usability and attention during the checksum verification process. We identify the main challenges with checksums from the point of view of usability, efficiency, security and adoption. • To address the usability and effectiveness issues of checksums, we propose an extension to the current World Wide Web Consortium (W3C) specification for subresource integrity (SRI) [START_REF]Subresource Integrity[END_REF]; it standardizes the use of checksums for external resources such as Javascript files, in order to cover download links of program files. Our solution enables developers to rely on a standardized method that would significantly reduce the user burden of checksum verification. • We develop two novel extensions for improving checksum verification. The first one is an automated checksum verification browser extension that alerts users when there is a potential mismatch between the checksum computed from the downloaded file and that (or those) available on the developer's website, even when the checksum is displayed in the page (and not through SRI), as is the case today. The second one is a checksum generation plugin for a popular web content-management system (CMS), which automatically implements our proposed extension to the W3C's SRI specification on the websites managed by such systems.

Our proposed solution would be deployed as follows: The use of checksums for web downloads and their inclusion in links would be standardized as an extension of SRI; alternatively, checksums would be extracted from the "Download" webpages in an ad-hoc fashion. The automatic extraction and verification of the checksums would be implemented in the web browser (or in an extension).

The results of our large-scale online survey demonstrate that, although 71% of the respondents declare to download program files from sources where they could be potentially corrupted, only 1.7% check the integrity of these downloads. Furthermore, when asked about what they would do if they saw a checksum on a website they downloaded a program from, only 5.2% of the participants stated they would use it to verify the file's integrity (out of 6 possible options), thus revealing the sheer number of computer users who know about this security technology. The results of our website survey show that a substantial fraction of download webpages include only checksums generated with weak hash functions (MD5 and SHA1). And, only a small fraction of the websites include instructions on how to verify file integrity with checksums or a description of their utility. Finally, our in-person experiments demonstrate that, despite being explicitly asked to verify the checksums, more than one third of our participants fail to detect the mismatch (i.e., partial pre-image attack) between the checksum displayed on a fake download webpage and the one computed from the (corrupted) downloaded file. Our eye-tracking analysis shows that users pay more attention to the first digits of the checksums, which reduces drastically the security provided by such checksums. It also suggests that failure to detect mismatch between checksums is caused by a low number of fixations. The user feedback also shows a good desirability of verification mechanisms integrated in web browsers.

The rest of the paper is organized as follows. We survey the related work in Section 2. We introduce the system and threat models as well as the background about checksums and file integrity verification in Section 3. We present the survey of websites that use checksums in Section 4. We follow up with the online user survey on Internet security behavior in Section 5. We then describe the proposed solutions in Section 6, and present the in situ user experiments with eye-tracking in Section 7. We discuss the main findings and limitations in Section 8. We conclude the paper in Section 9, by describing the outlook and perspectives for future work.

RELATED WORK

From a high-level perspective, our work can be framed within the broader category of online security behaviors as it touches upon the subject of security warnings through the lenses of file integrity verification. Hereafter we first present studies that focused on Internet users download behavior, then we focus on the works related to the effectiveness of security warnings and we then focus on the sub-area dedicated to file integrity verification.

Download Behavior

Internet users are increasingly exposed to security threats, as found by Furnell et al. [START_REF] Furnell | Assessing the Security Perceptions of Personal Internet Users[END_REF]: They conducted a survey with 415 home users to assess their perceptions of security issues, and their attitudes towards the use of related safeguards. The survey revealed that, although the responders had a high degree of confidence, they lacked desirable knowledge of different safeguards that can increase their security. They also found that there were notable shortcomings among users who considered themselves "experts". A similar survey conducted more recently with 594 home computer users revealed that security-related behavior is influenced by a combination of cognitive (i.e., understanding of the related threats), social, and psychological components (i.e., time pressure to complete the related task) [START_REF] Anderson | Practicing Safe Computing: A Multimedia Empirical Examination of Home Computer User Security Behavioral Intentions[END_REF]. Furthermore, a recent survey conducted in the UK on businesses and charity organizations [START_REF] Rishi | Cyber Security Breaches Survey[END_REF] revealed that security knowledge of employees is the weakest link leading to many successful cyber-attacks and that often times enforcing security policies is ineffective. Download behavior is often also influenced by security recommendations, as studied by Redmiles et al. [START_REF] Redmiles | How I Learned to Be Secure: A Census-Representative Survey of Security Advice Sources and Behavior[END_REF][START_REF] Redmiles | Where Is the Digital Divide?: A Survey of Security, Privacy, and Socioeconomics[END_REF]. The authors conducted semi-structured interviews and deployed a large-scale questionnaire to study security advice. In these studies, they found that users evaluate digital-security recommendations based on the trustworthiness of the source of the advice. When advised by knowledgeable peers, users might trust the source over the content of the recommendation. Unfortunately, none of these studies focused specifically on Internet downloads, which is one of the goals of this study.

Effectiveness of Security Warnings

A security warning is a cautionary message usually delivered by the operating system or a third-party app to users when they are about to perform an action on their system that could potentially have negative consequences. Such actions include downloading or opening a file containing a virus, visiting a website that contains malware or has phishing intents, or simply installing an app from an untrusted source. The users can either act on such warnings or ignore them. Over the past decade, the research community has extensively studied how users interact with such warnings, and whether the warnings are effective and understandable [START_REF] Akhawe | Alice in Warningland: A Large-Scale Field Study of Browser Security Warning Effectiveness[END_REF][START_REF] Bianchi | What the App Is That? Deception and Countermeasures in the Android User Interface[END_REF][START_REF] Egelman | You've Been Warned: An Empirical Study of the Effectiveness of Web Browser Phishing Warnings[END_REF][START_REF] Egelman | The Importance of Being Earnest [in Security Warnings[END_REF][START_REF] Jenkins | More Harm than Good? How Messages That Interrupt Can Make Us Vulnerable[END_REF][START_REF] Modic | Reading This May Harm Your Computer: The Psychology of Malware Warnings[END_REF][START_REF] Reeder | An Experience Sampling Study of User Reactions to Browser Warnings in the Field[END_REF][START_REF] Silic | Deterrent Effects of Warnings on User's Behavior in Preventing Malicious Software Use[END_REF][START_REF] Sunshine | Crying Wolf: An Empirical Study of SSL Warning Effectiveness[END_REF]. These studies are relevant to our work as we also designed an intervention through a browser extension.

The research on security warnings has shown that they are, on the one hand, effective at reducing the rate at which users perform potentially harmful actions after they have been warned [START_REF] Akhawe | Alice in Warningland: A Large-Scale Field Study of Browser Security Warning Effectiveness[END_REF][START_REF] Reeder | An Experience Sampling Study of User Reactions to Browser Warnings in the Field[END_REF][START_REF] Silic | Deterrent Effects of Warnings on User's Behavior in Preventing Malicious Software Use[END_REF]. On the other hand, users tend to ignore such warnings due to their excessive frequency [START_REF] Bravo-Lillo | Your Attention Please: Designing Security-Decision UIs to Make Genuine Risks Harder to Ignore[END_REF] and habituation effects [START_REF] Sunshine | Crying Wolf: An Empirical Study of SSL Warning Effectiveness[END_REF]. In another work, Modic and Anderson [START_REF] Modic | Reading This May Harm Your Computer: The Psychology of Malware Warnings[END_REF] studied what makes a warning effective, and they have found that warnings should (i) contain a clear and non-technical description of a potential negative consequence and (ii) they should be given from a "position of authority" [START_REF] Modic | Reading This May Harm Your Computer: The Psychology of Malware Warnings[END_REF]. In addition to the content, the design matters as well, as shown in two separate instances: First, by Akhawe and Felt [START_REF] Akhawe | Alice in Warningland: A Large-Scale Field Study of Browser Security Warning Effectiveness[END_REF] who compared SSL warnings from two different web browsers and showed that users of one browser proceeded to potentially malicious websites twice as often as the users of the other web browser; second, by Bravo-Lillo et al. [START_REF] Bravo-Lillo | Your Attention Please: Designing Security-Decision UIs to Make Genuine Risks Harder to Ignore[END_REF] who showed that by changing the user interface (UI) elements in the warning to highlight the most important elements for the users, they can reduce by half the installation rate of potentially malicious apps.

When looking at what motivates users for act or ignore security warnings and advice, several studies point out that the most important factors are the perceived security/convenience trade-off and the perceived risk of pursuing potentially dangerous actions [START_REF] Fagan | Why Do They Do What They Do?: A Study of What Motivates Users to (Not) Follow Computer Security Advice[END_REF][START_REF] Tam | The Psychology of Password Management: A Tradeoff between Security and Convenience[END_REF][START_REF] Weir | User Perceptions of Security, Convenience and Usability for Ebanking Authentication Tokens[END_REF]. For instance, Fagan and Khan [START_REF] Fagan | Why Do They Do What They Do?: A Study of What Motivates Users to (Not) Follow Computer Security Advice[END_REF] show that most users who follow a security advice do so for security benefits, whereas those who do not follow it do so to avoid an inconvenience mostly related to the lack of time.

File Integrity Verification

Several works have studied, by means of online surveys, the security and usability of different fingerprint representations for authentication and integrity verifications. Hsiao et al. have compared the speed and accuracy of hash verification with various textual and visual representations [START_REF] Hsu-Chun | A Study of User-Friendly Hash Comparison Schemes[END_REF]. Their between-subjects online study with 436 participants is the first to show that users struggle with comparing long fingerprints. More recently, Dechand et al. have studied the performance and usability of six textual fingerprint representations [START_REF] Dechand | An Empirical Study of Textual Key-Fingerprint Representations[END_REF]. Their online experiment with 1,047 participants demonstrates that the state-of-the-art hexadecimal representation is prone to partial pre-image attacks more than others, with more than 10% of attacks being missed by the users. Similarly, Tan et al. evaluate the usability and security of eight textual and visual fingerprint representations [START_REF] Tan | Can Unicorns Help Users Compare Crypto Key Fingerprints?[END_REF]. The results of their 661-participant experiments suggest that, when security is paramount, the best strategy is to remove the human from the loop and automate the verification process, which the authors did not test.

Research on secure messaging also provides us with relevant findings on the usability and security of fingerprints for authenticating the communicating entities. In their systematization of knowledge on secure messaging, Unger et al. emphasize the usability and adoption limitations of manual fingerprint verification [START_REF] Unger | SoK: Secure Messaging[END_REF]. Moreover, they mention short authentication strings, which rely on truncated cryptographic hashes, as a more usable alternative to fingerprints. In a 60-participant study on secure communication tools, Abu-Salma et al. show that fingerprints are not understood by participants, thus indirectly hindering the adoption of such tools [START_REF] Abu-Salma | Obstacles to the Adoption of Secure Communication Tools[END_REF]. Vaziripour et al. evaluate the usability of the authentication processes in three popular messaging applications (WhatsApp, Viber, Facebook Messenger) through a two-phase study involving 36 pairs of participants [START_REF] Vaziripour | Is That You, Alice? A Usability Study of the Authentication Ceremony of Secure Messaging Applications[END_REF]. These participants notably report that fingerprint strings are too long, and some WhatsApp users appreciate being able to scan QR codes instead of having to compare long digit strings. Note that in these contexts, unlike for web downloads, automating fingerprint comparison is not possible because fingerprints usually come from a different channel. On the practical side, a number of programs (including browser extensions [1, 2]) to compute and verify checksums with graphical user interface are available. Yet, they only enable users to compute checksums, not to automatically verify them against those extracted from webpages.

Finally, digital certificates can be used to certify the authenticity and integrity of programs. Such a solution, however, has shortcomings including the fact that certificates are costly, that the problem of certificate validation remains, and that private keys (of developers and certification authorities) can be compromised [START_REF]Certificates and Digitally Signed Applications: A Double Edged Sword[END_REF][START_REF] Vratonjic | The Inconvenient Truth About Web Certificates[END_REF]. In fact, digital certificates (used for code-signing) do not provide the same guarantees that checksums do: Certificates guarantee that the downloaded files have been produced by certain developers, whereas checksums guarantee that the downloaded files are those the website administrators intended to point to. Therefore, checksums do not provide protection in the case where a malicious website administrator includes a link to a corrupted version of a program (e.g., Transmission). And certificates do not provide protection in the case where a hacker replaces a program file with a corrupted version of the program signed with the (valid) account of a malicious developer (or with a stolen account).

In our work, we focused on one aspect that was neglected by prior research: What is the behavior of the users when they are asked to verify file integrity? Instead of testing different design of the checksum, we focused on the process by which participants were comparing a checksum with the output of the hash functions and their overall understanding of it. This point is highly relevant for this area of research as finding that people have a hard time understanding the whole idea behind checksum, like we did, would make automating the verification process a more secure solution over designing simpler checksums. In summary, we go beyond the sole investigation of manual fingerprint comparison, and we consider the overlooked context of web download integrity. We also employ eye-tracking techniques to gain a deeper understanding of how people perform fingerprint/checksum comparisons.

Automating Integrity Verification

In certain contexts, checksum verification is automated. It is the case with W3C's subresource integrity, described below in the background section. It is also the case of package managers such as brew (macOS) or aptitude (Linux), which enable users to download packages and programs from so-called repositories. They automatically compare the checksums of the downloaded packages to those specified in the package description: A typical brew "cask" package contains a link to an installer hosted on an external platform, a command line to run it and a checksum to verify its integrity (see that of VLC3 ). Such package managers, however, are mostly popular on Linux systems and they are used mainly by experienced users (e.g., users familiar with the terminal). Note that package managers are also subject to attacks [START_REF] Cappos | A Look in the Mirror: Attacks on Package Managers[END_REF].

SYSTEM AND THREAT MODEL

In this section, we describe the general system and adversarial model, as well as the technical background necessary to understand the work (i.e., checksums and digital signatures). Readers familiar with these concepts can skip the corresponding paragraphs.

System and Threat Model

We consider a website hosted on a given web server. The website contains a download page that includes a link to a program hosted on an external web server (a hosting platform, typically on a mirror or a content delivery network) managed by a different entity. The original website is managed by the developers. We consider an adversary who is able to tamper with the program files hosted on the external server. It could be the operator of the external hosting platform or a hacker. In order to enable users to check the integrity of the files they download from the external server, when clicking on the link in the download page hosted on the original server, the download page contains a checksum of the program, generated as explained below.

Checksums and Digital Signatures

Checksum. A checksum is a fixed-size binary string derived from a block of data of arbitrary size (e.g., a file): it is used to verify the integrity of the data, i.e., that the data has not been corrupted (e.g., when the data is transmitted or stored). In adversarial settings, the output of cryptographic hash functions, called hashes or digests, are used as checksums. Checksums are usually represented as hexadecimal strings (e.g., 2cae915ae0e...), the sizes of which usually range from 32 digits (i.e., 128 bits) to 128 digits (i.e., 512 bits). Cryptographic hash functions enjoy three core properties: pre-image resistance, second pre-image resistance, and collision resistance [START_REF] Preneel | Cryptographic Hash Functions[END_REF][START_REF] Rogaway | Cryptographic Hash-Function Basics: Definitions, Implications, and Separations for Preimage Resistance, Second-Preimage Resistance, and Collision Resistance[END_REF]. In the settings of web downloads hosted on external servers, the second property is key: It guarantees that it is computationally hard for an adversary with access to the original file (and its hash) to forge a different file (e.g., a malware) that has the same hash. Essentially, an adversary would have to rely on brute-force attacks, that is, to generate a huge number of different versions of a program (e.g., by varying a number of innocuous bytes such as strings in the program file) until it finds one with a hash that matches that of the original file. An adversary can perform a brute-force attack to forge a file with a hash that partially matches that of the original file, namely partial pre-image attacks. In addition, hash functions usually ensure that even a minor change (even just one bit) in the input data results in a completely different output hash. That is, two checksums should be very different if applied to very similar (but not identical) data.

Today, the most popular cryptographic hash functions are: MD5, SHA-1, SHA-2 (with 256, 384 or 512 bits) and the upcoming SHA-3. MD5 was one of the first proposed cryptographic hash functions; it was broken in the late 1990's and its use is strongly discouraged.

SHA-1 was recommended by the National Institute of Standards and Technology (NIST) until 2015, when it was broken. SHA-2 is the most popular hash function today and it is currently the recommended (by NIST) algorithm for file integrity verification [START_REF]NIST Policy on Hash Functions -Hash Functions[END_REF].

For integrity verification, users must input the downloaded file to a dedicated program (e.g., shasum) and compare the computed checksum to the one specified on the download page.

Digital Signature. Digital signatures usually rely on asymmetric cryptography. The signer (e.g., the developer) has a pair of cryptographic keys: a public one, known to everyone, and a private one, kept secret. By using their private key, the signer can generate a fixed-size block of data, i.e., a (detached) digital signature, from a file. Based on the signer's public key, a user can verify the validity of the signature and thus the integrity (and authenticity) of the corresponding file. To do so, users must input the downloaded file, the signature and the public key of the signer to a dedicated program (e.g., gpg). A popular cryptographic standard for digital signature is OpenPGP4 that relies on the RSA and DSA cryptographic schemes.

Subresource Integrity

Subresource integrity (SRI) was introduced by the W3C in 2016 [START_REF]Subresource Integrity[END_REF]. It specifies that, for external resources linked to a webpage through an HTML element, an integrity attribute containing a checksum can be added to the element. 5 This mechanism was introduced to detect corruption of externally hosted scripts. Therefore, in its current form, SRI covers only two elements: the link6 and script. These elements are used to include external style sheets (e.g., cascading style sheets-CSS) and scripts (e.g., JavaScript-JS) respectively. The verification of the integrity of the subresources, based on the provided checksum, is performed by the user agent, typically the web browser. SRI is currently supported by all the major browser except Internet Explorer.

SURVEY OF WEBSITES

In order to assess the current practices of developers regarding the use of checksums and signatures7 in the context of web downloads, we analyzed the download pages of various popular programs for computers (not for smartphones), such as VLC media player.

Methodology

To obtain a list of software programs to analyze, we wanted to focus on popular programs that can be freely downloaded on the Internet and that have an associated checksum on their download pages (on the official website). We started by looking at websites from the Alexa top 500 ranking, but we were unable to find any meaningful datasets, not to mention the fact that the number of visits on the website is not necessarily correlated with the number of downloads of the program. We then explored a second dataset from App Annie that provides a list of popular apps but only for mobile devices. A third possibility would have been to look at the official app stores, but this would make little sense, as those apps can already be safely downloaded from there. In addition, some popular apps are not on such app stores. Hence, we collected examples of free software programs from within our lab as well as from lists of popular free software gathered from the Web. 8 We converged on 20 programs that (i) can be freely downloaded from their respective websites, (ii) are provided with their associated checksums and (iii) are from different app categories, according to Wikipedia. We manually analyzed each of the download pages in a systematic way, by checking the following properties:

• If the checksum and the program are hosted on the same server, on different servers in the same domain, or on different servers in different domains. We compared the URLs of the checksum file (or of the webpage, if the checksum is embedded in the webpage) to that of the program. We performed a complementary comparison of the corresponding IP addresses. 9 From a security point of view, it is better to host the website and the program on different servers, as this reduces the risks that an attacker can tamper with both the checksum displayed on the page and program file. This is less problematic for signatures as they cannot be forged. • Whether the checksum and the program are served through HTTP or HTTPS by default. From a security perspective, HTTPS is better as it protects the integrity of the data while in transit and authenticates the hosting website. • Which cryptographic schemes are used to generate the checksum (i.e., MD5, SHA1, SHA2 with 256 or 512 bits, or PGP). As of today, both MD5 and SHA1 are considered insecure and their use is strongly discouraged [START_REF]NIST Policy on Hash Functions -Hash Functions[END_REF]. • Whether the webpage contains instructions on how to verify the integrity of the downloaded program with the corresponding checksum. • Whether our browser extension (described in Section 6) can extract the checksum from the original download page and verify the integrity of the downloaded program.

We collected, whenever available, the average number of downloads per day. We conducted the survey in April 2018. To limit the possible data collection errors, three experts from our lab independently verified each website according to the properties above and found no discrepancies. Table 1 shows the raw data of this survey. Note that the Tor client was included in our survey, even though it does not include a checksum (but includes a signature). This is because the integrity of such a program is particularly important, considering the contexts in which it is used (e.g., censorship circumvention).

Results and Analysis

It is important to note that the list of analyzed programs is not representative of all the programs available for download on the Web. Therefore, the statistics derived from this survey are useful mostly to obtain a sense of the current practices and the relevant criteria regarding the use of checksums for securing web downloads of programs. For future work, we intend to perform such an analysis 1: Raw results of the website survey on the use of checksum on the download pages of popular programs. "ext." stands for "extension", "instr." for "instructions", and "#dl/day" for "average number of downloads per day". In the host column, the "*" denotes that, although the program and the checksum files are hosted on the same server, they are also mirrored on a different server (typically under a different domain).

on a much larger scale, which would also enable us to assess the prevalence of checksums on the web.

From the results, we observe the following. First, 2 out of 20 (2/20) websites did not serve the checksum in a secure way (i.e., over HTTPS). This is problematic, as the webpage and the checksum it contains could be tampered with by an adversary through a manin-the-middle attack. It should be noted, however, that, for Audacity, even though the website was by default served over HTTP, it was also possible to retrieve it over HTTPS. Second, 9/20 websites host the checksum and the program on the same server (according to our heuristic). This could be problematic, as an adversary who is able to break into the server could tamper with both the program file and its checksum, hence cover up the tampering.

We also observed that 7/20 websites include multiple checksums (e.g., Handbrake with SHA1 and SHA2), possibly in combination with PGP signatures (e.g., OpenOffice). A non-negligible fraction (5/20) of the websites analyzed (e.g., Blender and GIMP) include only checksums generated from weak hash functions, namely MD5 and SHA1. Furthermore, only 6/20 websites (e.g., OpenOffice and GnuPG) include instructions on how to verify checksums or a description of their utility. Finally, the fact that our extension does not work on 13/20 analyzed websites is due to the fact that it is currently instrumented to work in the cases were the checksum is available in the HTML code of the same website that contains the link to the program file. If the checksum is stored in a separate file, our extension would currently not detect it. As for Tor, the download page includes a detached signature (hosted on the same server, but this is not a problem for signatures) together with the instructions to check it.

In summary, due to frequent flaws in the way checksums are currently used (e.g., insecure communication, single server, weak hash function) and the lack of details on their utility and how-to guides, checksums do not achieve their full potential in securing web downloads.

LARGE-SCALE USER SURVEY

To date, little research has focused on the problem of checksum verification. In particular, we know little about the proportion of Internet users who know about checksums and those who regularly apply checksum verification to their downloads. Therefore, we pose the following research questions: (RQ1) Which proportion of Internet users install programs that are manually downloaded directly from websites, therefore exposing themselves to potentially corrupted programs? (RQ2) What proportion of Internet users know about checksum verification methods? Among those who know, how many actually do it when they download programs from developer websites?

Methodology

In order to study the current security behaviors of Internet users, and the associated risks, with respect to programs downloaded from the Internet and to answer the above research questions, we conducted a large-scale online user survey. The survey was approved by our institution's ethics committee. We contracted a vendor to deploy and conduct the survey; the vendor was in charge of selecting a representative sample, in terms of demographics, of Internet users based in the US [START_REF] File | Computer and Internet Use in the United States[END_REF]. The panelists were recruited via partnerships and invited via banners and messaging, and then go through quality controls. Panelists receive virtual points in exchange for their participation in active research campaigns, which can be later redeemed for donations to charity or for vouchers to buy goods and services. The total cost of the survey was ∼USD 5600 with an average incentive of ∼USD 1.9/participant (excluding administrative costs).

We deployed the questionnaire twice in order to collect both qualitative and quantitative information from participants while avoiding potential biases in the answers. The first deployment (Q1) lasted one week and some of the questions were left as open ended. We collected responses from around 200 participants. Qualitative answers provided for Questions A5, A7, and A10 (see Appendix A) were categorized at the end of the week by two coders. The codebook was developed through inductive analysis and it was used to define multiple-choice questions for the second deployment of the questionnaire (Q2). We measured inter-coder agreement through Cohen's kappa at 0.89 and judged it sufficient. The few cases of conflict were resolved via discussion. Before deployment of Q1, to improve the effectiveness and readability of the questions, we conducted a cognitive pretest of the questions with 5 test participants. For instance one of the changes consisted in simplifying language. Instead of using technical terms such as "checksums", we mainly used: "sequences of numbers and characters". The questionnaire Q2 was deployed in April 2018. It should be noted that, as for most user surveys on security-related behavior, the information reported by the respondents might not exactly reflect their actual behaviors; this fact is well documented in the literature (see for instance Egelman et al. [START_REF] Egelman | Behavior Ever Follows Intention?: A Validation of the Security Behavior Intentions Scale (SeBIS)[END_REF]).

Demographics and General Statistics

Two thousand valid responses were collected (N = 2,000) from questionnaire Q2. The proportion of female respondents was 51% and the age distribution was as follows: 18-29 (22%, or 440 respondents), 30-39 (17%, or 340), 40-49 (19%, or 380), 50-59 (18%, or 360), 60+ (24%, or 480). Respondents were well distributed across the four macro regions of the US: 22.1% (or 442) live in the Midwest, 20.1% (or 401) live in the Northeast, 34.2% (or 683) live in the South, and 23.7% (or 474) live in the West.

The large majority of the respondents (90.6%) use a laptop or desktop computer; the remaining 9.4% (or 189) use only a smartphone or tablet. Of those who use a computer, 75.9% use a computer running Windows, 12.4% use a computer running macOS, and 2.3% use a computer running Linux (A1). For the remaining of the statistics in this section, we will always refer to respondents who use a computer. We found that 89.7% of the respondents owned a smartphone, 8.5% owned a feature phone, and 1.8% did not own a mobile phone. We leave studying downloads of mobile apps to future work.

Results and Analysis

RQ1. In our survey (A4), 29.4% of the respondents declared to never run any program downloaded from the Internet or to do so from official app stores exclusively (6.1%), which could be considered a safe behavior. Out of the remaining 70.6% of the respondents, 58.6% declared downloading content from developers' websites, and 42.6% using P2P networks at least once a year. The majority of respondents using computers (62.2%) declared using official app stores (e.g., Mac App Store) for downloading programs. However, only 6.1% of respondents used this source exclusively. These results reveal that the large majority of Internet users are exposed to potential corruption of externally hosted programs, thus confirming the relevance of this research.

RQ2. For a final question, we asked (A9) our respondents whether they had ever noticed checksums on websites and (A10) what they would do with them if they ever found them when downloading programs. We found that 23.4% of respondents remembered seeing them on websites they used in the past. Concerning what they would do with them, most selected responses had nothing to do with what checksums are meant for (83% see Question A10). Interestingly, for 18.2% of the respondents, displaying the checksums on the webpage of the app would make them doubt of the website and search for something else. Consequently, using this security technology would be detrimental to the overall user experience. About 11.8% of the respondents would simply ignore checksums and continue installing the app. Regarding the purpose of checksums, only 5.2% of the respondents selected the correct answer (out of 6 possible options, plus the "not sure" and "other" options), i.e., to check the integrity of the downloaded programs. Therefore, we can estimate the proportion of users who know about checksums between 1.7% and 5.2%.

Summary

The results of the large-scale survey revealed that, based on Internet user behaviors, corruption of externally hosted programs could have a substantial negative effect. Integrity verification offers a defense against this. Unfortunately, only a tiny fraction of Internet users knows about this security technology and uses it on a regular basis. Developers, who rely on checksums, currently require users to perform the check manually. We learned, however, that this might be perceived negatively by less experienced users and might lead to users preferring a different developer.

Limitations

After the deployment of the survey, we realized that some of the terminology and the wording of the questions could have led to an ambiguous interpretation. For instance, in question A4, we did not provide any examples of P2P programs. Furthermore, the distinction between 'developer' and 'vendor' might not have been entirely clear to the respondents.

AUTOMATING CHECKSUM VERIFICATION

In the previous sections, we demonstrated through various surveys and experiments that checksums currently do not fully achieve their goals of securing web downloads. One of the main causes is that the task of computing and verifying checksums needs to be done manually by the users. In addition, checksums are not widespread on the web and Internet users are unaware of their utility and usage. In this section, we address these problems by proposing both recommendations and technical solutions that we designed, implemented and made available for testing (see below). Our solutions address the problems of generating, computing and verifying checksums.

Extending Subresource Integrity to Links

A direct solution for making checksum verifications automatic is to extend the subresource integrity (SRI) feature [START_REF]Subresource Integrity[END_REF], recently introduced by the W3C and described in Section 3, to HTML a elements (i.e., hyperlinks) that point to files to be downloaded.

Our proposal is to include an integrity attribute to the a elements, and optionally the meta and iframe elements, as web developers sometimes rely on them to trigger automatic downloads. Below, we give an example hyperlink that specifies, in an integrity attribute, the checksum of the file it points to. 10<a href="https://github.com/.../Transmission-2.93.dmg" integrity="sha256-Yc2bdMxUJFj..

.">download</a>

Upon a successful download of a file pointed to by a hyperlink that includes an integrity attribute, the integrity of the downloaded file should be checked by the user agent (i.e., the web browser or a web browser extension) by comparing its (computed) checksum to the one specified in the integrity attribute.

Checksum Verification: Browser Extension

As web browsers do not currently handle SRI for hyperlinks, to automatically check the integrity of downloaded files, we developed a Chrome extension 11 . This extension should, of course, be considered as a proof of concept and not as a final product.

Design and Implementation. Our extension supports three popular algorithms used to generate checksums: the MD5, SHA-1 and SHA-2 hash functions, 12 and PGP signatures (partially). It is implemented in JS and it relies on the md5.js library for computing MD5 digests, 13 the asmcrypto.js library for computing SHA digests, 14and the openpgp.js library for checking PGP signatures. In total, the extension consists of ∼400 lines of JavaScript code (excluding the libraries); it requires permission to access the browser's download manager in order to initiate and monitor downloads, as well as read-only access to the file system in order to compute the digests of the downloaded files.

As SRI for hyperlinks is currently not supported by web developers, our extension is also capable of extracting checksums directly from the text of HTML pages, thus requiring no changes to existing websites such as VLC. It operates as follows:

(1) For each visited webpage, it navigates the HTML DOM tree and extract, by using regular expressions, hexadecimal strings that have the same format as checksums as well as the corresponding hash function names (e.g., SHA-1). ( 2) If checksums are detected (on the webpage or in the integrity attribute of the a element), it intercepts click events triggered by hyperlinks. If a hyperlink points to a file with a sensitive extension (e.g., dmg, exe, pkg) and/or mime type 15 (e.g., application/x-apple-diskimage, application/xmsdownload, application/x-debian-package), 16 the download is followed by the verification of the checksum, essentially a comparison between the checksum that is detected and the one computed from the downloaded file. (3) If multiple checksums are extracted from the webpage, the verification is considered successful, as long as the computed checksum matches any one of them. 17 The webpage is greyed out and a pop-up message is displayed to the user, as illustrated in Figure 1. Additionally, if the checksum originates from the text of the webpage, the matching text with the checksum is revealed (if originally hidden) and highlighted. The extension displays a general message to the user and a status indicator (e.g., "downloading", "computing checksum") with an animation. Additionally, it can show four different messages according to the result of the verification (Figure 2), depending on the origin of the checksum (webpage text or integrity attribute) and on the outcome of the verification (success or failure). In the case of failure, users are offered the option to delete the possibly corrupted downloaded file (through a link). Clearly, there are multiple ways to communicate the result of the verification to the user, and the UI elements have a significant effect on the usability of our extension [START_REF] Akhawe | Alice in Warningland: A Large-Scale Field Study of Browser Security Warning Effectiveness[END_REF]. For the initial proof of concept, we experimented with the four messages shown in Figure 2. A careful consideration of alternatives that incorporate user feedback should be conducted before the actual deployment in a product. We leave the careful design of the extension user interface for future work. The extension can be downloaded from at the following address: https://checksum-lab.github.io/chrome_extension.zip. 18 A test webpage can also be found at the following address: https: //checksum-lab.github.io/. It contains test download links with and without (valid/invalid) integrity attributes and links to the download pages (that include checksums) of popular software (e.g., Android Studio, Plex, VLC) on which the extension can be successfully tested. Alternatively, a demo video can be downloaded at the following address: https://checksum-lab.github.io/demo.mp4. Shortcomings and Perspectives. There are several limitations and missing features that we intend to address in the future. First, the UI and the textual messages of the browser extension should be carefully designed by taking into account user feedback (see Section 7.4 for more details) and best practices for the design of security warnings (see for instance [START_REF] Akhawe | Alice in Warningland: A Large-Scale Field Study of Browser Security Warning Effectiveness[END_REF][START_REF] Brinton Anderson | How Polymorphic Warnings Reduce Habituation in the Brain: Insights from an fMRI Study[END_REF][START_REF] Bravo-Lillo | Your Attention Please: Designing Security-Decision UIs to Make Genuine Risks Harder to Ignore[END_REF][START_REF] Egelman | You've Been Warned: An Empirical Study of the Effectiveness of Web Browser Phishing Warnings[END_REF][START_REF] Egelman | The Importance of Being Earnest [in Security Warnings[END_REF][START_REF] Porter Felt | Improving SSL Warnings: Comprehension and Adherence[END_REF][START_REF] Modic | Reading This May Harm Your Computer: The Psychology of Malware Warnings[END_REF][START_REF] Silic | Deterrent Effects of Warnings on User's Behavior in Preventing Malicious Software Use[END_REF][START_REF] Silic | Warning! A Comprehensive Model of the Effects of Digital Information Security Warning Messages[END_REF][START_REF] Sunshine | Crying Wolf: An Empirical Study of SSL Warning Effectiveness[END_REF]). Second, the extension does not handle the case of concurrent downloads from the same tab (e.g., multiple downloads from the same webpage). Third, the extension works only when the checksum and the direct link to the file are on the same page; for instance, the case where a download link redirects to a page with an automatic download based on a meta or iframe element is not supported. Similarly, it does not support the case where the checksums are in a separate file linked on the download page. Furthermore, it does not include any settings UI for managing the features, such as disabling the extension on certain websites or making the verification process silent (e.g., do not show any message and simply delete the file in the background if the checksum does not match). Finally, the extension currently does not alert users when no checksums are available on the website, for any of the downloaded files. Finding the optimal way of informing users of such aspects is another design problem we intend to address by reviewing the best practices for security warning design, and by conducting additional user studies.

Checksum Generation: CMS Extension

In order for web browsers to automatically verify checksums as described above, checksums must be embedded in download links. Therefore, to alleviate the burden on the website administrators, we developed a tool to automatically generate and embed checksums in download links for websites that are managed through a Content Management Systems (CMS).

Design and Implementation. Because a substantial fraction of websites are powered by content management systems (CMS), and by WordPress in particular, 19 we implemented our tool in the form of a WordPress extension.

Our WordPress extension is implemented as a hook for the page/post update operation. Similarly to the Chrome extension, it should be considered as a proof of concept. It consists of ∼100 lines of PHP code; it can be downloaded at the following address for testing purposes: https://checksum-lab.github.io/wordpress_plugin. html. The extension parses the HTML code of the page and extracts all the links (i.e., the a elements). For each link, the extension determines the mime type of the target by making a HTTP HEAD request on the server side. If the target is downloadable (i.e., not a webpage, or more generally, content that is not displayed in the browser), the extension fetches it (by making a HTTP GET request on the server side), computes the SHA-2 checksum and embeds it in the corresponding link, i.e., in an integrity attribute of the a element. For performance reasons, the computed checksums are cached in a database. Yet, they can be refreshed on demand, in order to adapt to potential changes of the linked file at different points in time. Moreover, the extension can be further enhanced to automatically re-compute the checksums for the target of the links (i.e., the a element) and to alert the website administrator in case of changes (caused by file update or corruption). It should be noted that downloading the file on the server side could be avoided by using the content-md5 [START_REF] Fielding | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content[END_REF] or instance digest [START_REF] Mogul | Instance Digests in HTTP[END_REF] feature of HTTP. Unfortunately, because the former is deprecated and the latter is not standardized, neither are supported by major HTTP servers. In the production version of the extension, we intend to implement the download and the checksum computation in an asynchronous fashion and to include a configuration widget in the HTML editor that is embedded into WordPress.

USER EXPERIMENT

In this section, we study the usability and the effectiveness of checksums in the context of web downloads. More specifically, we pose the following research questions: (RQ3) Do users thoroughly verify checksums?, (RQ4) Can users be fooled by replacing some characters in the middle of the checksum?, (RQ5) Does automating the checksum verification improve general usability metrics?

In order to answer the above questions, we conducted an in situ user experiment involving an eye-tracking screen. This methodology has been used extensively in the last decade to study usability of new services, programs or mobile apps as it enables the collection of accurate objective measurements of where the user looks on the screen without obtruding or disturbing their action [START_REF] Poole | Eye Tracking in Human-Computer Interaction and Usability Research: Current Status and Future Prospects[END_REF]. The two metrics extracted through this method were the total number of fixations and the total dwell time. Fixations are indicative of the amount of processing being applied to objects at the point-ofregard [START_REF] Joseph | Eye Tracking in Web Search Tasks: Design Implications[END_REF]. A longer dwell time indicates difficulty in extracting information, or it means that the object is more engaging in some way [START_REF] Adam | Eye Fixations and Cognitive Processes[END_REF]. Our hypothesis was that participants who checked thoroughly the checksums would have to produce more fixations (and 19 WordPress is the most widely used CMS; according to W3Tech (https://w3techs. com/technologies/overview/content_management/all; Last visited: March 2018), about 51% of all websites are powered by a CMS and 31% of all websites are powered by WordPress.

spend more time fixating) in the part of the user interface where these sequences were displayed.

The experiment was split in two phases. During the first phase, we asked participants to verify manually the checksums of four downloaded apps (this was addressing RQ3 and RQ4). In the second part of the experiment, we activated a browser extension that took care of verifying the integrity of the downloaded files based on their checksums (this was addressing RQ5). We did not counterbalance the presentation of these two parts for two reasons: (i) the second part of the experiment made explicit what the core of the experiment was and could have biased the results of the first part; (ii) the two parts of the study addressed different research questions. However, this design also had drawbacks that we report below in Section 7.4. The experiment was approved by our institution's ethics committee.

Participants

We recruited the participants of our experiment from a student population through flyers displayed on two university campuses (i.e., UNIL and EPFL in Lausanne, Switzerland). To sign up for the experiment, potential subjects had to fill an online screening questionnaire first. In this questionnaire, they were asked about their basic demographic information (age and gender), major field of study, knowledge of checksums (i.e., "Do you know how and what for the elements circled in red on the following screenshots are used? 20 If yes, please describe it briefly in the text box below. "), tech savviness (i.e., "Check the technical terms related to computers that you understand well: ad-blocker, digest, firewall, VPN, etc.). Finally, we asked which was the OS of their main computer.

We selected a total of 40 subjects (out of the 120 who completed the screener) and invited them to participate in the experiment. We number of participant was chosen so that it provides sufficient power to the statistical tests and keeps the total duration of the experimentations reasonable (we had only one eye-tracker). The sample was selected to maximize diversity. About half of the participants were macOS users (i.e., 21/40, that is 53%) and half Windows users (the actual breakdown in terms of operating systems among the participants who filled the screener was 56% macOS, 41% Windows, 3% Linux). The subject pool included 40% of female subjects and it was diverse in terms of major fields of studies, with more than 15 different majors represented. The average age of the subjects was 22.5±2.9. Out of the 40 subjects, 12 (30%) knew about checksums, 33 (83%) downloaded programs from developers websites and 20 (50%) from app stores, and 25 (63%) had an antivirus installed on their computers. The experiment took approximately 50 minutes per person to complete and the participants were compensated with CHF 20 (∼USD 20). The whole experiment was conducted in French (i.e., the local language in Lausanne).

Apparatus

The experiment took place in a UX-lab, a small room with a desktop computer. The computer was equipped with an eye-tracking system (maker Tobii, model X2-60 21 ) which was sampling gaze at 60Hz. 20 The screenshot depicted the official VLC download page with checksums circled. 21 https://www.tobiipro.com/product-listing/tobii-pro-x2-60/ Two cameras and a few microphones were also placed in the room to record the experiment.

Depending on the OS the participant was most familiar with (either macOS or Windows), we switched the computer that was used by the participants during the course of the experiment. Aside from the OS, the employed apps and the layout of the windows were the same on the two different OSes. Three windows were placed and arranged on the screen: the web browser (Chrome) that occupied the left half of the screen, the "Downloads" folder (Windows explorer/macOS finder) that occupied the top right quadrant, and the terminal that occupied the bottom right quadrant (see Figure 3). Participants were asked to not change the position of the three windows, and scrolling was disabled in the browser in order to reduce shifts in the areas of interest (AOI) of the screen that were displaying the checksums.

All necessary pages were pre-loaded in the browser window in different tabs. We tampered with the checksum on the third webpage (i.e., Transmission) for the first part of the study and the second webpage (i.e., Audacity) for the second part of the study. All the other checksums were correct. Based on our running hypothesis that users check only the first and last digits of the checksum, we changed the 44 digits (out of 64) in the middle of the checksums; this means that only the first and last 10 digits remained unchanged. 22

Procedure

First and foremost, we informed the participants that they would be recorded during the course of the experiment (and about our data management plan, including data anonymization and retention) and we asked them to sign, if they agreed, an informed consent agreement. We told the participants that we were conducting a study on the way people download applications on their computers and that they had to download several applications on the lab computer. We asked the participants to behave as if they were using their own computer and we told them to not hesitate to call the experimenter in case of doubts or problems. We also explained that the experimenter had nothing to do with the design and implementation of the extension, therefore, the participants could freely express negative opinions without the risk of affecting the experimenter.

Next, we asked participants several preliminary questions, mainly to confirm some of the information they provided in the screener: the OS of their computer, whether they had an antivirus installed and whether they downloaded apps from the Internet from places other than official app stores. Then, we asked the participants to sit at the computer, and a 13-point calibration procedure for the eye-tracking system was completed. Finally, the participants were given a checklist containing the steps to follow during the session. All materials were prepared in French and the sessions were conducted in French, which the main language spoken where the study was conducted.

First Phase. We asked the participants to download from the official website and execute/install four different programs (in this Figure 3: Screenshot of the window arrangement on the computer used for the experiment (macOS). The left half of the screen is occupied by the Chrome web browser in which multiple tabs have been pre-opened: the download pages of the first four programs, the extension tab to activate the extension, the download pages of the next two programs, and the questionnaire website (Qualtrics) for the exit survey. The right half of the screen is occupied by the terminal application where the participants must type the command lines to compute the checksums of the downloaded programs (bottom) and the "Downloads" folder (top) were the programs downloaded from the browser are placed; the participants had to click on the icons of the downloaded programs (in that window) to execute them. specific order): VLC, Handbrake, Transmission, and Android Studio. Specifically, for each application, the participants were asked to (1) Download the application. For the sake of simplicity, the download webpages were already opened in individual tabs of the web browser. (2) Compute the checksum of the downloaded program and compare it to that specified on the webpage. The participants were provided with the exact command to type in the terminal, e.g., clear ; shasum -a 256 Handbrake-1.1.0.dmg for macOS. 23 All the checksums were SHA-2 with 256 bits. (3) Run the program and report some information on the instruction leaflet: program version and copyright years found in the "About" box (macOS) or digital certificate issuer (Windows). The purpose of this last step was to avoid calling too much attention to the checksum verification as being the core of the experiment.

As explained in the previous subsection, the checksum of the third webpage, i.e., Transmission, was set to be incorrect.

Second Phase. We asked the participants to activate the extension (by clicking on a button in the fifth tab of the browser), and to download and run/install two additional applications i.e., RealVNC and Audacity, in this order. We asked the participants to perform the same steps as in the first phase, except from the manual checksum verification that was automated by our browser extension. The first application's checksum was correct, resulting in the display of a confirmation message by the browser extension (see Figure 1), whereas the second one was incorrect, hence resulting in the display of a warning message (see at the bottom right of Figure 2). The terminology used in the messages was inspired by the instructions found on the download pages of popular programs (e.g., Ubuntu). We recognize that it could be improved with a better design and with user feedback. We intend to revise the design of the extension in the future. For the last step, we asked the participants to fill a short questionnaire online to get some feedback about their perception of the manual verification of checksums and of the browser extension, satisfaction with the extension and net promoter score.

Results

We describe and analyze the results related to the manual verification of checksums (first phase), and then report on the usability and effectiveness of the browser extension (second phase).

In order to study the gaze behavior, in our analysis, we surrounded the parts of the UI that displayed the checksums, and we labelled each area. These were the AOIs described prior in the text. Unfortunately, we had to remove eye-tracking recording for one participant due to corrupted data. RQ3. From a qualitative analysis of the fixation heatmaps of the participants looking at the AOIs that contained the checksums, we could observe three distinct behaviors: (a) some participants produced extensive fixations throughout the sequence of characters (i.e., the checksum) covering most/all of the sequence; (b) other participants produced less fixations but still "sampled" the sequence at several points from beginning to end; (c) finally some other participants produced fewer fixations in the AOIs, typically pointing to the beginning and the end of the sequence. Examples of these three behaviors can be seen in Figure 4. While the first two behaviors typically led to identifying the incorrect checksum, the third was typically associated with not identifying the incorrect checksums. This was confirmed by our quantitative analysis presented below.

To understand whether all the digits of the checksum were treated equally by the participants, we further subdivided the area where the checksum is displayed in four sub-AOIs (see Figure 5) and measured differences of the total number of fixations falling in each of these areas. As the assumptions for parametric inferential statistics were violated, we used nonparametric statistics for the subsequent quantitative analysis. 24 24 Concerning the total number of fixations, the Shapiro-Wilk normality tests were close to rejection: AOI 1 -(W = .95, p = 0.085), AOI 2 -(W = .94, p = 0.027), We conducted a Friedman test of differences among repeated measures to compare the total number of fixations that fell in each of the four sub-AOIs. There was a significant difference in the scores: AOI 1 -M=25.15, SD= 13.11, AOI 2 -M=21.92, SD= 13.96, AOI 3 -M=13.92, SD= 9.55, and AOI 4 -M=10.58, SD= 6.99; χ 2 (3) = 77.32, p < 0.001. Six Wilcoxon signed rank tests with continuity correction were conducted to make post-hoc comparisons between AOIs. All the tests indicated that there was a significant difference between the number of fixations falling in each AOI. We include the detailed results of the tests and the boxplot of the distribution of fixations for each AOI, in Figure 6 and Table 2. These results suggest that the attention given to the digits of the checksum is highest at AOI 3 -(W = .94, p = 0.037), AOI 4 -(W = .92, p = 0.008) and the assumption of homoscedasticity was violated when using the Modified Levene's Test (F = 6.23, p < 0.001). The conclusion was similar for the total dwell time.

the beginning and decreases as we progress in the sequence. This means that a partial pre-image attack should focus on keeping the first digits of the checksum unchanged. RQ4. We observed that 15 (38%) of the participants did not detect the mismatch (for Transmission) between the checksum displayed on the download webpage and the checksum computed from the downloaded file (displayed in the terminal). This constitutes a substantial proportion of our subject pool. This number could be higher in real life as the subjects are likely to be more careful in a controlled environment compared to a situation where they are eager to run the program they just downloaded. We did not find a significant difference in the detection rate for participants who had prior checksum knowledge (p = 1, Fisher's exact test). Participants with prior knowledge understand better the importance and functioning of checksums but, at the same time, they might be more sloppy in their verification as they know that an accidental modification would very likely change the first digits of the checksum. The same result -specifically the lack of difference between the group of participants who were knowledgeable and those who were notwas observed for the previous results on RQ3.

To study more quantitatively if some behavioral differences existed between those who detected the mismatch and those who did not, we operated a post-hoc split of the participants. A Wilcoxon rank sum test was conducted to compare the total number of fixations in the AOIs for the two groups. The values of the task with the modified checksum were not considered in order to compare the usual behavior. There was a significant difference in the number of fixations for participants who detected the corrupted checksum (M=12.47 fixations, SD=5.01) and those who did not (M=3.88 fixations, SD=2.09); W=338.5, p < 0.001. Furthermore, the same test was conducted to compare total dwell time in the AOIs for the two groups. There was a significant difference in the amount of time spent in the checksum AOIs for participants who detected the corrupted checksum (M=15.63 seconds, SD=9.50) and those who did not (M=3.97 seconds, SD=2.60); W=333, p < 0.001.

These results suggest that participants who detected the corrupted checksum fixated the checksums significantly more frequently and spent significantly more time than those who did not detect the mismatch. The observed ratios between the two behaviors were approximately 4:1. This analysis was also extended to tasks 1, 2 and 4 for the two groups of participants (i.e., those who detected the mismatch vs. those who did not). We observed the same difference reported for Task 3; this reveals that those who were thorough were consistently so, during the entire experiment.

RQ5. We now report the results of our user experiment related to the browser extension carried out in the second phase. As explained in Section 7, in order to study user reaction to the messages displayed by the extension and to collect user feedback, in the second phase of our user experiment (with eye tracking), we asked the subjects to activate the extension and to download two programs (RealVNC and Audacity) from the corresponding official websites. The checksum of the second download (Audacity) was incorrect.

During the experiment, 40% of the participants stopped when shown the warning message for the (corrupted) Audacity download. For those who did not, the reason they reported most frequently (in the exit survey) was that they tend to ignore popups shown on webpage systematically because they are too frequent and often irrelevant or even scams.

Among the participants who did stop, 50% removed the download file: 37.5% of them clicked on the dedicated "delete" link embedded in the warning message to delete the (corrupted) downloaded file and the remaining 62.5% manually removed the file.

In the exit survey, the participants reported an average satisfaction score of 5.2±1.4 (on a scale from 1 to 7). 25 Furthermore, the participants reported an average desirability score of 4.6±1.9 ("Should the extension be available for download, how likely would you be to use it?"), with 55% of the participants answering positively, and an average net promoter score of 4.5±1.9 ("How likely would you be to recommend it to a friend or relative?"), with 55% of the participants answering positively. In these questions, the comparison was implicit to the status-quo offered by the commandline interface that the participants tested in the first part of the experiment.

Another observation from the user experiment was that 26/40 participants (65%) could not explain the objective of integrity verification in the exit questionnaire (before the debriefing). This reveals the inability of non-technical users to grasp the concept behind checksum-based integrity verification.

Finally, the participants gave us feedback on the messages displayed by the browser extension. The main comments were the following: The terminology used in the message was too technical or unclear (7 participants): "Plutôt sobre je trouve bien mais pour un neophyte, il n'est pas très clair par rapport à son rôle. (It is rather sober I think but for a newbie it is not clear enough in relation to its role)"; the popup did not sufficiently catch their attention (4 participants)they suggested using larger icons and using colors for the text messages themselves or even to remove the icons-:"Sans le petit logo vert, qui fait penser à celui d'un antivirus, c'est personnellement le genre de message auquel je fais très rarement attention. (The little green logo, which makes me think about an antivirus, should be removed as it is the kind of message that I would rarely pay attention to.)"; the design of the skip button allowed participants to easily skip it (2 participants): Pour éviter que le message ne soit fermé tout de suite, il faudrait peut-être bloquer le reste de la navigation tant que le message n'est pas fermé. Ou le laisser ouvert obligatoirement pendant quelques secondes. (To prevent the user from immediately dismissing the message the message, it would be necessary to block the user from pursuing navigation until the message is closed. Or to force the message to remain open for a few seconds). . Interestingly, during the informal feedback with the experimenter, several participants reported that they are, in general, annoyed by popups displayed within webpages and tend to ignore them. 26 Also, they mentioned that a warning originating directly from the browser in a standalone window would have been more effective.

During the experiment, we also received positive feedback on the extension. Several participants commented positively that the design of the message and the terms used were clear: Le message est assez clair et explique bien pourquoi le fichier devrait être supprimé (The message is rather clear and it explains well why the file has to be deleted), Ce message apparaît de manière assez claire dans la page, donc cela permet à l'utilisateur d'être au courant sur ce qu'il télécharge. (This message appears in a clear way on the page. This allows the user to be aware of what she is downloading.) These results suggest that the extension was rated slightly desirable by most participants. The study helped identify several areas for improvement of the design, namely around the behavior of the extension and the messages displayed to encourage the users to delete the downloaded file in case of mismatch (see Section 8).

Limitations. Like any lab study, the experiment suffered from low ecological validity. Also, the prescriptiveness of the sequence of tasks that we gave to participants reduced the ability to observe participants' spontaneous behavior when downloading files. Also, we might have introduced a learning bias by choosing not to randomize the presentation of the first and the second part of the study might have .

DISCUSSION

Our large-scale user survey shows that the majority of computer users are vulnerable to attacks through corrupted download files. Checksum is one of the most prevalent solutions for countering such attacks. However, most users have a hard time grasping the idea behind integrity verification. Through the survey, we learned that users neither understand nor use them (95% do not know how to use them, 98% do not use them for verifying a file integrity). Through the user experiment, we also consolidated this finding: Even when users were explicitly asked to verify checksums, most of them have had a hard time understanding what they were doing and often failed at detecting strategic replacements (38% of the time). Furthermore, after having spent over 30 minutes manually verifying checksums, looking at our extension and answering questions related to checksums, 65% of the participants still had troubles explaining what was the purpose of checksums. Therefore, we argue that raising awareness around manual checksums verification would require substantial efforts.

In this paper, we argue that a viable solution to increase the security and usability of web downloads is to automate the checksum verification process. Through the lab study, we tested an initial design for an extension that would automate the integrity verification. In our initial design the user was left in charge of deciding whether the downloaded file (for which there was a mismatch) had to be removed from the system. Unfortunately, we learned that this design was not really effective at making people aware of potential threats. This finding resonates well with the suggestions of Tan et al. [START_REF] Tan | Can Unicorns Help Users Compare Crypto Key Fingerprints?[END_REF]. As highlighted by prior work, security warnings might be skipped for a variety of reasons: notifications overload, habituation [START_REF] Sunshine | Crying Wolf: An Empirical Study of SSL Warning Effectiveness[END_REF], inattention blindness [START_REF] Varakin | Unseen and Unaware: Implications of Recent Research on Failures of Visual Awareness for Human-Computer Interface Design[END_REF], etc.

We argue that designers should choose defaults to privilege users' security over preserving user's choice. In fact, a lack of action from the user does not necessarily mean that she is willing to accept the risk of proceeding but might simply be due to the aforementioned effects. Concretely, in the case of a mismatch, instead of warning the users and suggesting them to delete the corrupted files (opt-in approach), the extension should block access to the downloaded files a priori and ask for users' action to unblock it. This opt-out approach is similar to the one implemented by antivirus or spam filters which put files or e-mails in quarantine.

CONCLUSION & FUTURE WORK

In this work, we opened a line of research on the use of checksums for integrity verification of web downloads and made a number of contributions.

Given the user feedback and results of our in situ experiments, we plan to improve the user interface of our extension to make it clearer about the potential risks of installing corrupted download files. More specifically, we will deploy an instrumented beta version of our extension and run a longitudinal study to gather more feedback from the end users and at a larger scale. To do so, we will rely on the well-established experience sampling method that collects in situ data by requesting participants to provide short self-reports at multiple random occasions over time [START_REF] Pablo | Your Browsing Behavior for a Big Mac: Economics of Personal Information Online[END_REF][START_REF] Cherubini | A Refined Experience Sampling Method to Capture Mobile User Experience[END_REF]. This will also enable us to collect data about checksums in the wild.

Finally, we believe it is paramount to robustify and improve the software artifacts (browser and CMS extensions) we produced and make them available to a wide audience. In addition we intend to promote our proposals to (and collaborate with) the different stakeholders involved, that is the W3C, web browsers (e.g., Google, Mozilla) and CMS (e.g., WordPress, Drupal) development teams in order to have a concrete impact on the security of Internet users.

Figure 1 :

 1 Figure1: Screenshot of the extension on the Plex download page (https://www.plex.tv/downloads/). The checksum of the downloaded file is computed and successfully checked against that extracted from the webpage (highlighted).

Figure 2 :

 2 Figure 2: Messages displayed by the browser extension: left (integrity attribute) / right (text of the webpage), top (success) / bottom (failure).

Figure 4 :

 4 Figure 4: Sample subject gaze heat maps captured by the eye-tracking system on macOS.

Figure 5 :

 5 Figure 5: Areas of interest used for the checksums displayed in the terminal.

Figure 6 :

 6 Figure 6: Boxplots of the distribution of user fixations across the four areas of interests covering the checksums.

Table

	name	description	host	checksum program MD5 SHA1 SHA2 PGP ext. instr. #dl/day
	Android Studio	programming suite	diff. domain	https	https	✗	✗	✓	✗	✓	✗	-
	Audacity	audio editor	diff. domain	http	https	✗	✗	✓	✗	✗	✗	6k
	Blender	3D graphics editor	diff. domain	https	https	✓	✗	✗	✗	✗	✗	16k
	FileZilla	FTP client	diff. domain	https	https	✗	✗	✗	✗	✗	✗	11k
	GIMP	raster graphics editor	diff. domain* https	https	✓	✗	✗	✗	✓	✗	-
	GnuPG	cryptographic suite	same server	https	https	✗	✓	✗	✓	✗	✓	-
	Handbrake	video transcoder	diff. domain* https	https	✗	✓	✓	✓	✓	✓	-
	Inkscape	vector graphics editor	same server	https	https	✓	✗	✗	✗	✗	✗	-
	IntelliJ	programming suite	same server	https	https	✗	✗	✓	✗	✗	✗	-
	KeePass	password manager	diff. domain	https	https	✗	✗	✗	✗	✗	✗	15k
	Notepad++	text editor	same server	https	https	✓	✓	✗	✗	✗	✗	-
	OpenOffice	office suite	diff. domain	https	https	✓	✗	✓	✓	✗	✓	85k
	Plex	media server	same server	https	https	✗	✗	✓	✗	✓	✗	-
	RealVNC	remote administration	same server	https	https	✗	✗	✓	✗	✓	✗	-
	SpyBot	antivirus	same server	https	https	✓	✓	✓	✗	✗	✗	-
	Tor	anonymity network	same server	https	https	✗	✗	✗	✓	✗	✓	90k
	Transmission	BitTorrent client	diff. domain	https	https	✗	✗	✓	✗	✓	✗	-
	Ubuntu	operating system	same server	http	http	✓	✓	✓	✓	✗	✓	-
	VLC	media player	diff. domain	https	https	✗	✗	✓	✗	✓	✗	527k
	VMware Fusion virtual machine hypervisor diff. server	https	https	✓	✓	✓	✗	✗	✓	-

Note that checksums only enable users to verify that the file they downloaded is indeed the one the website administrator intended to share.

By default, the major operating systems include only command-line tools to compute checksums, e.g., shasum for macOS and Linux and certutil for Windows.

https://github.com/caskroom/homebrew-cask/blob/master/Casks/vlc.rb

https://www.openpgp.org

https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity

The link element should not be confused with the a element which defines hyperlinks users can click on to download files or to navigate to other webpages.

For the sake of clarity, in this section, we refer to both digests produced by cryptographic hash functions and signatures as checksums.

See, e.g., https://www.techradar.com/news/the-best-open-source-software

Note that this method is a heuristic; as such, it could induce both false positives and false negatives.

For PGP, the integrity attributes include the string "pgp", the ID and fingerprint of the PGP key used for generating the signature, and the base-64 representation of the detached signature of the file.

Ideally, such verifications should be performed by the web browser. One option would be to integrate directly in the Chromium open-source browser project.

We chose to support the MD5 and SHA-1 functions despite their known weaknesses because they are still used, as mentioned in Section 4.

[START_REF] Pablo | Your Browsing Behavior for a Big Mac: Economics of Personal Information Online[END_REF] https://github.com/blueimp/JavaScript-

MD5 14 https://github.com/asmcrypto/asmcrypto.js

The mime type is determined by issuing a HEAD request to the target of the link.

The complete list was built based on the extension-mime types mappings of the Apache and nginx web servers.

Note that this reduces only slightly the security of the verification procedure as download pages usually contains only a few checksums (8 at most in the websites we surveyed, i.e., for Android Studio). As part of future work, we intend to match automatically checksums to download links by analyzing the DOM of the webpages.

Instructions: Download the zip file and unzip it. In the extension tab of Chrome, activate developer mode and load the extension by clicking on the "Load unpacked" button and selecting the folder where the extension was unzipped.

We considered, as in[START_REF] Dechand | An Empirical Study of Textual Key-Fingerprint Representations[END_REF], that a realistic adversary can forge, through brute-force, a corrupted program in such a way that the first and last 10 digits of its checksum match those of the original program's checksum.

The clear command is used to ensure that the checksum is always displayed at the same location on the screen, for eye-tracking purposes.

For all the self-reported scores given in this section, we used a 7-level Likert scale.

Showing fake (security) warnings within webpages to push users to download and install malicious programs is a common practice, e.g, fake antivirus or flash players.

ACKNOWLEDGMENTS

The authors express their sincere gratitude to Italo Dacosta, Andreas Kramm, Nicolas Le Scouarnec, Adrienne Porter Felt, Lawrence You, Blase Ur (our shepherd) and the anonymous reviewers for their insightful feedback. The authors also warmly thank Holly Cogliati for her great editing job on the manuscript. The work was partially funded with a UNIL-HEC Lausanne Research Fund.

The warning message was customized depending on the answer provided by the respondent to question A1. 28 The actual survey presented three distinct examples of popular websites to respondents. Respondents were asked whether they recalled seeing any similar "sequence of numbers and characters" in the past months from websites they visited. 29 The same screenshots of question A9 were also displayed for question A10. Here respondents were presented a concrete scenario of downloading an app from a website with checksum and asked what they would do with the "sequence of letters and numbers".


Brice Bouvier

Adriana Savescu

Sonia Duprey

Raphaël Dumas

Hand

Hand position estimation using inertial sensors

teaching and research institutions in France or abroad, or from public or private research centers.

ABSTRACT PREMUS 2016

Hand position estimation using inertial sensors

Magneto-Inertial Measurement Units sensors (MIMU) are more and more used in various applications, including ergonomics, as they allow for ambulatory measurements. Despite much interest from the scientific community in this topic, several aspects of research deserve more investigation. Since MIMU only deliver 3D orientation data, the determination of MIMU-based segment positions remains challenging. This work proposes the assessment of MIMU-based hand positioning error. 10 subjects participated in this study. They were equipped with four MIMU, placed on the thorax, right upper arm, right forearm and right hand segments. Each subject repeated five experimental sessions, each consisting in four test conditions: two static poses (rest-pose, T-pose) and two series of movement (maximal shoulder flexion, circular multi-joint movement). The MIMUbased upper limb kinematic chain was obtained by associating information of (1) 3D segment orientations, determined during a static pose calibration, and (2) segment lengths, estimated by regression rules based on the subject height. The hand positioning error was calculated by using an optoelectronic system as reference (REF) and by aligning both MIMU and REF thorax segments together. The root mean square error (RMSE) was extracted for each experimental session and was then averaged over them (N = 50). Results showed a global RMSE in the range of 7 -15 cm confounding the four test conditions. This range of error is consistent with values mentioned in other studies, performed on a robotic arm [1] or without considering the wrist motion [2]. 3D visualization of the upper limb represents a complementary source of information to joint angles data, especially for shoulder joint, in order to ease the interpretation of postures and movements in a general context of musculoskeletal disorder prevention. If a better precision for upper limb positioning is expected, a more advanced kinematic chain and dedicated calibration steps represent interesting approaches to investigate.

[

  , Brice, SAVESCU, Adriana, DUPREY, Sonia, DUMAS, Raphaël, 2016, Hand position estimation using inertial sensors, 9th International Scientific Conference on the Prevention ofWork-Related Musculoskeletal Disorders, TORONTO, CANADA, 2016-06-20, 1 p

	1]	D. Galinski and B. Dehez, "Evaluation of initialization procedures for estimating upper limb
		kinematics with MARG sensors," … (BioRob), 2012 4th IEEE RAS EMBS …, 2012.
	[2]	L. Peppoloni, A. Filippeschi, E. Ruffaldi, and C. A. Avizzano, "A novel 7 degrees of freedom
		model for upper limb kinematic reconstruction based on wearable sensors," SISY 2013 -IEEE
		11th Int. Symp. Intell. Syst. Informatics, Proc., pp. 105-110, 2013.

BOUVIER


Mélanie Ottenio

Florence Podwojewski

Doris Tran

Philippe Beillas

David Mitton

Gaétan Guérin

Frédéric Turquier

Biomechanical experiments on the abdominal wall: from ex vivo to in vivo

à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Biomechanical experiments on the abdominal wall: from ex vivo to in-vivo

Mélanie Ottenio [START_REF] Podwojewski | Mechanical response of animal abdominal walls in vitro: Evaluation of the influence of a hernia defect and a repair with a mesh implanted intraperitoneally[END_REF][START_REF] Podwojewski | Mechanical response of human abdominal walls ex vivo: Effect of an incisional hernia and a mesh repair[END_REF][START_REF] Tran | Contribution of the skin, rectus abdominis and their sheaths to the structural response of the abdominal wall ex vivo[END_REF] , Florence Podwojeski [START_REF] Podwojewski | Mechanical response of animal abdominal walls in vitro: Evaluation of the influence of a hernia defect and a repair with a mesh implanted intraperitoneally[END_REF][START_REF] Podwojewski | Mechanical response of human abdominal walls ex vivo: Effect of an incisional hernia and a mesh repair[END_REF][START_REF] Tran | Contribution of the skin, rectus abdominis and their sheaths to the structural response of the abdominal wall ex vivo[END_REF] , Doris Tran [START_REF] Podwojewski | Mechanical response of animal abdominal walls in vitro: Evaluation of the influence of a hernia defect and a repair with a mesh implanted intraperitoneally[END_REF][START_REF] Podwojewski | Mechanical response of human abdominal walls ex vivo: Effect of an incisional hernia and a mesh repair[END_REF][START_REF] Tran | Contribution of the skin, rectus abdominis and their sheaths to the structural response of the abdominal wall ex vivo[END_REF] , Philippe Beillas [START_REF] Podwojewski | Mechanical response of animal abdominal walls in vitro: Evaluation of the influence of a hernia defect and a repair with a mesh implanted intraperitoneally[END_REF][START_REF] Podwojewski | Mechanical response of human abdominal walls ex vivo: Effect of an incisional hernia and a mesh repair[END_REF][START_REF] Tran | Contribution of the skin, rectus abdominis and their sheaths to the structural response of the abdominal wall ex vivo[END_REF] , David Mitton [START_REF] Podwojewski | Mechanical response of animal abdominal walls in vitro: Evaluation of the influence of a hernia defect and a repair with a mesh implanted intraperitoneally[END_REF][START_REF] Podwojewski | Mechanical response of human abdominal walls ex vivo: Effect of an incisional hernia and a mesh repair[END_REF][START_REF] Tran | Contribution of the skin, rectus abdominis and their sheaths to the structural response of the abdominal wall ex vivo[END_REF] , Gaétan Guérin (4) , Frédéric Turquier (4) [START_REF] Podwojewski | Mechanical response of animal abdominal walls in vitro: Evaluation of the influence of a hernia defect and a repair with a mesh implanted intraperitoneally[END_REF] Université de Lyon, F-69622, Lyon, France; [START_REF] Podwojewski | Mechanical response of human abdominal walls ex vivo: Effect of an incisional hernia and a mesh repair[END_REF] Université Claude Bernard Lyon 1, Villeurbanne ; [START_REF] Tran | Contribution of the skin, rectus abdominis and their sheaths to the structural response of the abdominal wall ex vivo[END_REF] IFSTTAR, UMR_T9406, LBMC Laboratoire de Biomécanique et Mécanique des Chocs, F69675, Bron ; (4) Covidien, Trévoux, France.

Abstract :

The aim of the abdominal wall is to protect the internal organs. But the presence of a defect (a hole) on the abdominal wall can result to the protusion of an organ under the skin. This is called an incisional hernia. A surgical operation is then needed to repair the abdominal wall. But the reparation can fail due to critical loading imposed to the abdominal wall. If the surgery is successful, the patient may still suffer from pain or limited mobility. In this context, it is believed that the treatment of a hernia can be greatly improved by a better knowledge of the biomechanical response of the abdominal wall. In addition, it is planned to build a valid numerical model from this knowledge, which will constitute a useful tool to help in the design of new repair surgical meshes.

We here present different experimental protocols to get mechanical information on the abdominal wall in the context of the incisional hernia:

-a series of ex-vivo tests that have been performed to register the biomechanical response of the abdominal wall subjected to controlled and idealized mechanical loadings. The mechanical differences between the global response of an intact, damaged, and repaired abdominal wall have been quantified ([1], [2]), and the contribution of the different components tried to be extracted ( [3]).

-a series of in-vivo tests that have enabled a collection of data under physiological loadings (i.e. active muscles). These tests have been applied to healthy subjects, as well as patients before the surgical reparation of a hernia.