dataesr/scientific-paragraphs-categorization huggingface dataset:
02) and CRTC2 (P = 0. 02). Immunoprecipitation of the Star promoter by the CRTC3 antibody also revealed a significant effect of ACTH on CRTC3 binding (P < 0. 001; Fig. 4C ). Binding of CRTC3 to the Star promoter was detected by 15 min (P = 0. 001), the earlier point measured, and remained at similar levels at 30 min (P < 0. 001). D). Star hnRNA was normalised to Gapdh mRNA and is expressed as fold-changes of time 0 (n = 3-6/ time point). In C, pCREB was measured in the nuclear extract, was normalised to HDAC, and is expressed as fold-changes of time 0 (n = 4-5/time point). In D, pCREB was measured in the whole cell extract, was normalised to vinculin, and is expressed as fold-change of time 0 (n = 3/time point). Data in A were analysed using one-way ANOVA followed by Fisher LSD post-hoc test; data in B, C and D were analysed using Welch ANOVA followed by Dunnett T3 post-hoc test.
Star hnRNA levels were measured either prior to or 30 min after treatment with 10 nM ACTH, 1 mM 8-Br-cAMP, 100 nM PMA or 3 nM EGF in Y1-BS1 (A) and ATC7-L (B), or 60 min after treatment in dispersed rat adrenal cells (C). For inhibition studies, Y1-BS1 cells (D), ATC7-L (E) and dispersed rat adrenal cells (F) were pre-incubated for 15 min with either vehicle (0. 5% DMSO), 10 μM H89, 1 μM UO126, or 10 μM H89+1 μM UO126 before addition of ACTH at a final concentration of 10 nM. Bars represent the mean ± SEM of 3-6 experiments, normalised to Gapdh mRNA and expressed as fold-change from basal vehicle values. PMA treated cells in C represent the mean of data from 2 independent experiments. Data in A were analysed using one-way ANOVA followed by Fisher LSD post-hoc test; data in B were analysed using Welch ANOVA followed by Dunnett T3 posthoc test.
Data in D, E and F were analysed using Two-way ANOVA followed by Fisher LSD post-hoc test. *P ≤ 0. 05, **P ≤ 0. 01, ***P ≤ 0. 001 vs untreated vehicle control. #P ≤ 0. 05, ###P ≤ 0. 001 vs ACTH-treated vehicle control. their interaction was not significant (P = 0. 213 and P = 0. 412, for inhibitors and interaction, respectively). As in ATC7-L cells, Star hnRNA increases in the ACTH-treated vehicle (P = 0. 035) and UO126 (P = 0. 008) groups were significant compared to basal, whilst pre-incubation with H89, but not with UO126, blunted Star hnRNA response to ACTH (P = 0. 242). Also similar to ATC7-L cells, pre-incubation with UO126 did not inhibit but tended to increase the effect of ACTH compared with vehicle pre-treated cells. 3. 6. Inhibition of PKA and calcineurin decreases ACTH-mediated nuclear translocation of CRTC1, CRTC2 and CRTC3 in ATC7-L cells but not ACTHmediated Star transcription To investigate the role of PKA, MEK and calcineurin on CRTCmediated regulation of ACTH-induced Star transcription, the effect of 10 min treatment with ACTH on Star hnRNA levels and nuclear levels of CRTC1, CRTC2 and CRTC3 were measured in ATC7-L cells pre-treated with UO126, H89 or the calcineurin inhibitor CsA.
Acknowledgements This work was supported by the  Intramural Research Program, National Institute of Child Health and Human Development, National Institutes of Health , and  Medical Research Council   programme grant  [ MR/J008893/1 ]. The authors are grateful to  Dr Bernard Schimmer ,  University of Toronto, Canada , for providing the  Y1-BS1  cells and  Dr Pierre Val ,  University of Clermont, France  for his guidance with ATC-7L cells.
Data The Baltimore Longitudinal Study of Aging (BLSA) is a long running study of aging among community dwelling adults started in 1958  [19]. While there are more than 1100 participants in the study; we chose a subset of participants who were ! 60 years old and underwent both brain MRI scans and vestibular testing in the same study visit between 2013 and 2015. The mean age (AESD) of the group was 77. 5 years (AE8. 9 years), and 80% were male. All participants provided written informed consent, and the BLSA study protocol (03-AG-0325) was approved by the National Institute of Environmental Health Sciences Institutional Review Board.
The test statistic we used was a ratio between maximum squared errors of null and alternate hypotheses. Maximum squared error generally is less robust than summed square error. But this approach is typically used in our group because it is conservative, since it compares our results to the least favorable outcome under permuted group labels, rather than average outcomes. We note that in this nonparametric testing procedure, the level of the tests (i. e. the validity of our p-values) do not depend on our data following any particular distribution or on our choice of test statistic, but the power of the tests do. Another limitation is that with the shape analysis methodology, the population template is generated based on the particular sample. Our sample included 80 participants from the BLSA, a longitudinal study of the normative aging process.
Future work In this study, we have investigated the relationship between vestibular function and the volume and shape of structures in the brain. While such a cross-sectional study is useful to observe relationships within many structures, it does not provide definite information about causeeffect relationships. A next step would be a longitudinal study, where the hypothesis that vestibular loss precedes structural changes can be tested. Statistical techniques like structural equation modelling can be used with longitudinal data to investigate simultaneous or bidirectional relationships between vestibular function and structure. Additionally, changepoint analysis can be applied to longitudinal data to determine when non-linearities occur in trajectories of structural change. For cortical structures like the ERC and the insula, changes in thickness might also offer relevant insights, and can be similarly modelled.
g. , mirrors, content delivery networks). Hosting software on a website has several advantages for the developers, but it could also negatively affect the users. In particular, security is an important concern when downloading files from the Internet. Users could be tricked into downloading corrupted software that contains malware, which could impair the performance of their machine or even steal personal data from it. This scenario is not limited to the case where the software is hosted on a malicious platform, but can also happen if a legitimate hosting platform is compromised. In any case, by choosing to host their software on the web, developers also accept the risk that it could be accidentally or intentionally modified in an unpredictable way. Recently, both the popular BitTorrent client Transmission  [3]  and the Linux Mint distribution  [4]  were corrupted; the former by a ransomware and the latter with a backdoor.
Such corruptions are particularly problematic for privacy and security softwaresuch as Tor -used by at-risk populations such as journalists and political dissidents. 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. To mitigate such threats, developers can publish alphanumeric strings whose purpose is to enable users to verify that the downloaded software has not been accidentally or intentionally modified from the moment it was published and linked by its developer. Such strings, called checksums, are commonly used in the open-source community but also by companies such as Google (for their software Android Studio and Golang).
Moreover, we describe and report in detail on our 4-month in-the-wild experiment, which was conducted after our original work  [1]. Finally, we make available to the community the dataset we collected through the eye-tracking device. We also open-source the browser extension on GitHub and distribute it on the Chrome Web Store. The rest of the article 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 describe the proposed solutions -i. e. , the browser extension -in Section 4, and present the in situ user experiments with eye-tracking in Section 5. We present the in-the-wild experiment in Section 6. We discuss the main findings and limitations of our work in Section 7.
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 VLC 3  ). Such package managers, however, are mostly popular on UNIX systems and they are used mainly by experienced users (e. g. , users familiar with the terminal). 4 ote that package managers are also subject to attacks  [36].
Subresource Integrity Subresource integrity (SRI) was introduced by the W3C in 2016  [7]. 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 link 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 browsers (except Internet Explorer). If the integrity verification of a subresource fails, it is not loaded.
Extending Subresource Integrity to Links A direct solution for making checksum verifications automatic is to extend the subresource integrity (SRI) feature  [7] , introduced by the W3C and described in Section 3, to HTML a elements (i. e. , links) that point to files to be downloaded. Our proposal is to include an integrity attribute in 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 link that specifies in an integrity attribute the checksum of the file it points to. <a href="https://github. com/. /file. dmg" integrity="sha256-Yc2bdMx. ">download</a> Upon a successful download of a file pointed to by a link that includes an integrity attribute, the integrity of the downloaded file should be checked by the user agent (i.
Checksum Verification: Browser Extension As browsers do not currently handle SRI for links, we developed a Chrome extension to automatically check the integrity of downloaded files. 6 This extension should 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. 7 It is implemented in JS and it relies on the md5. js library for computing MD5 digests 8  and the asmcrypto. js library for computing SHA digests. 9 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 digest of the downloaded file.
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  [16]. For the initial proof of concept, we experimented with the four messages shown in Figure  3. A careful consideration of alternatives that incorporate user feedback should be conducted before a public release of such an extension. We leave the careful design of the extension UI for future work. An archive containing the source code of the extension used in the experiment can be downloaded at the following address: https://checksum-lab. github. io/chrome_extension. zip (SHA-256: 237ac0154e5d951d22f54c97300d3de81a88333c29ec66334c061edb44f2d368).
12 A test webpage can also be found at the following address: https://checksum-lab. github. io/. It contains test download links with and without (correct/incorrect) 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 or watched at the following address: https://checksum-lab. github. io/demo. mp4. Performance Evaluation. In order to assess the delays induced by the verification of the checksums, we measured the computation times for different hash functions (namely MD5, SHA-1 and SHA-2 with 256 bits), based on the implementation of the libraries used in the Chrome extension, and for different file sizes ranging from 45MB (corresponding to VLC's app file) to 1.
The number of participant was chosen so that it provides sufficient power to the statistical tests and keeps the total duration of the experimentation 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 (OS) 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.
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.
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. 16 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. 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.
Data availability. The eye-tracking data is available online. 21 The dataset is a 40GB Tobii Pro Studio (version 3. 4. 8) archive in the. nas format. The archive includes all the screen recordings; the sound and the webcam streams are not included for privacy reasons. The archive is shipped with a spreadsheet that contains the anonymized responses to the screener and exit questionnaires and the notes taken by the experimenter. The IDs in the spreadsheet corresponds to the participant number and recording number in the Tobii dataset.
Basically, while for the lab experiment the participant could easily ignore the popup, in the field deployment we took a safer approach for which the user was actually required to read the warning and to explicitly click on a link if they wanted to bypass the verification. The code of the revised browser extension was structured and implemented using the Google developers guidelines and the Chrome extension APIs. The extension had three main functions. Checksum verification are usually proposed for files that can be executed on the computer. However, according to our adversary model, any file hosted on a different server can benefit from an integrity verification (i. e. , Microsoft Office or PDF documents [CVE-2017-0199],  [51] ). To collect relevant information, the extension monitored the Chrome download manager and sent back all information available in the downloadItem object (Object available through the Chrome Extension API).
At the end of the survey -and only for qualifying respondents -a request was made to our server to be assigned a participant ID. The server created a new ID in the users table and returned that to the survey platform that stored the ID together with the other responses of the screener. This process was used to separate the personal identifiable information of the participants (or PII) from the collected dataset. Also, this process would assign each new participant at random to the experimental or the control group. Once the survey platform received the ID, the participant was automatically redirected to the extension installation instruction page. 22 The page contained a link to the extension on the Chrome web store and step-by-step guide on how to complete the setup. Participants also received the same information via e-mail.
The page also provided information on how to pause the data collection of the extension, if the user wished to do so (e. g. , for a browsing session that they might wanted to exclude from the data collection). Participants were also instructed to contact us via email if they wished to delete a browsing session that had been already captured. On startup, the extension verified two conditions. The first one was checking that the user ID existed in the database. This variable was saved using synchronized storage from the Chrome API. In the event that participant would start using Chrome on another computer and would log in their Google account, the extension would be installed on the new computer and the participant ID would be automatically added. This user ID also determines if users would see the download verification messages.
6% of downloads are PDFs and office documents that could also be injected with corrupted macros or other harmful code. During the study, a total of 17 executable downloads contained a checksum on the page that was verified by the browser extension. For 6 of the 17 downloads the participants that originated the download was in the experiment group, hence the browser extension presented popup messages about the verification to the users. A large proportion of the downloaded files came from e-mail attachments accessed via a webmail. The modest number of executable files downloaded can be explained by the fact that users download the bulk of the programs they need when they set-up their computers and only a few ones, sporadically, after that. (RQ5) What is the prevalence and the current practices of checksums included in download webpages? Of the 17,400 downloads recorded in the final dataset, 4,853 files (or 27.
9%) were hosted on a server that had a distinct domain name from the server that served the webpage of the site. This shows that about a third of the downloaded files we recorded in this study could potentially be compromised following the threat model described in this paper. Similarly, we found that 923 downloads (or 5. 3%) originated from a server that was not configured with HTTPS, hence allowing potential attackers to modify the files while being transferred to the machine requesting the download. Out of the 657,608 webpages visited by the participants during the study, only 153 pages (or 0. 02%) contained a checksum string, and of the 17,400 downloads events in the final dataset, 37 originated from one of these webpages. We manually inspected these webpages and classified them into four categories: (i) 70 (or 45.
7%) webpages linked executable files and references the name of the algorithm used to generate the checksum (i. e. , SHA-256, MD5); (ii) 43 (or 28. 1%) were false positives (i. e. , webpages that contained alphanumeric strings that matched our regular expression but that were not checksums); (iii) 29 (or 19%) webpages linked torrent files (we will discuss this case below); and (iv) 11 (or 7. 2%) webpages contained true checksums but the connected file was not an executable, hence the extension did not verify the integrity. For instance, Zenodo provides checksums for PDFs  24  , and Digicert for security certificates. 25 Concerning the webpages with checksum that linked torrent files, in these cases the participants visited a webpage that contained checksum information about one or multiple files seeded through the peer-to-peer network.
GENERAL DISCUSSION The number of Internet users potentially exposed to corrupted files is alarming. Our previous large-scale study  [1]  showed that, out of the 62. 2% of all the respondents who download programs from the Internet, only 6. 1% do so exclusively from official app stores, such as the Mac App Store or the Microsoft Store. Checksums, if used correctly, could therefore prevent the execution of potentially malicious code for more than half of the users who download files from the Internet. Sadly and as expected, our recent in-the-wild experiment confirmed that the vast majority of participants (88. 6%) do not notice the presence of checksums, even when they are visible on the download page. To make things worse, most participants in our experiments did not know how to use this information even when we pointed them to the part of the page that contains the checksum.
ACKNOWLEDGEMENTS The authors express their sincere gratitude to  Italo Dacosta ,  Andreas Kramm ,  Nicolas Le Scouarnec ,  Adrienne Porter Felt ,  Nina Taft ,  Lawrence You , and  Blase Ur  for their feedback. The authors also warmly thank  Holly Cogliati  for her great editing job on the manuscript. This work was partially funded with grant # 19024  from the  Hasler Foundation  and with a grant from  HEC Lausanne. This work was carried out while Alexandre Meylan and  Bertil Chapuis  were with UNIL.
An updated version is available at: https://github. com/isplab-unil/download-checksum; alternatively, it can be installed from the Chrome Web Store: https://chrome. google. com/webstore/detail/automated-checksum-verifi/ kabghagbpkdbojdeklmcbfamenmpilga ACM Trans. Priv. Sec. , Vol. 24, No. 1, Article 4. Publication date: August 2020.
Acknowledgments The authors want to thank  Thomas Brown  for his comments and manuscript corrections. We also thank  S. Andrieu ,  M. Lapierre ,  L. Romian ,  F. Mehr , and  F. Rimet  for animal care and  F. Vossier  and  L. De Macedo  for mouse genotyping. The  Photonic Imaging Center of Grenoble Institute Neuroscience (Univ Grenoble Alpes-Inserm   U1216 ) is part of the  ISdV core facility  and certified by the  IBiSA label.