Ific Goudé

Rémi Cozot

Francesco Banterle

HMD-TMO: A Tone Mapping Operator for 360 • HDR images visualization for Head Mounted Displays

Keywords: Head Mounted Display, High Dynamic Range, Tone Mapping Operator, 360, image

We propose a Tone Mapping Operator, denoted HMD-TMO, dedicated to the visualization of 360 • High Dynamic Range images on Head Mounted Displays. The few existing studies about this topic have shown that the existing Tone Mapping Operators for classic 2D images are not adapted to 360 • High Dynamic Range images. Consequently, several dedicated operators have been proposed. Instead of operating on the entire 360 • image, they only consider the part of the image currently viewed by the user. Tone mapping a part of the 360 • image is less challenging as it does not preserve the global luminance dynamic of the scene. To cope with this problem, we propose a novel tone mapping operator which takes advantage of both a view-dependant tone mapping that enhances the contrast, and a Tone Mapping Operator applied to the entire 360 • image that preserves global coherency. Furthermore, we present a subjective study to model lightness perception in a Head Mounted Display.

Introduction

Due to the growth of Virtual Reality (VR) technologies over the last years, the visualization of 360 • images has become common. 360 • images can have a higher dynamic range than classic 2D images. When considering natural outdoor images, the sun can arise in certain zones of the image while dark shadows can appear in other zones. High Dynamic Range (HDR) cameras are now used to capture the whole dynamic of a scene without any loss of information, thereby providing realistic panoramas. The main issue is that all the manufactured Head Mounted Displays (HMDs) still have Standard Dynamic Range (SDR) displays, which prevents them from displaying all the dynamic range of HDR images. To appreciate HDR contents through standard displays, the well known process of Tone Mapping is used to get a limited range corresponding to SDR displays. Many Tone Mapping Operators (TMOs) exist and can be divided into two main Supported by the ANR project ANR-17-CE23-0020.

groups (global and local) and are often based on how the human perceives lightness. Each TMO can be more appropriated for a particular type of image and some user studies (see Section 2) have been conducted to determine which one is a better candidate for 360 • images. These studies show that there is no preferred TMO, and emphasizes on the necessity of developing one dedicated to HMD. For this purpose, two TMOs have been proposed in the literature (see Section 2). There are several different approaches to the problem of tone mapping a 360 • HDR image. One of them is to consider the content overall, the 360 • image is processed at once, toward its entire dynamic range. The obtained result is globally coherent but, when considering a viewport of the entire 360 • image, the contrast is reduced. However, as the user can only watch a limited part of the 360 • image at a time, a TMO may be applied to the current viewport. Thus, the viewport contrast is enhanced while the global coherency is lost.

To overcome this problems, we propose a method that takes into account the results of two TMOs: one applied to the entire 360 • image, and the other to the current viewport. As will be explained later, the viewport TMO provides a better contrast, while the global TMO preserves the spatial coherency. The main contributions of this paper are: (1) a subjective evaluation to model lightness perception on an HMD; (2) a novel TMO for 360 • HDR images that ensures a spatial coherency and enhances contrasts by combining the luminances (physical quantity of light) provided by these two TMOs.

After introducing in Section 2 related works on TMOs dedicated to 360 • images visualization on HMD, we present the user study we conducted to model lightness perception (subjective perception of light by the human eye) in Section 3. As a result, we show that the perception model of the lightness on a classic 2D display is still valid on an HMD. Then, we describe in details our HMD-TMO in Section 4. Next, in Section 5, we comment on our results and discuss the efficiency of our approach. Finally, Section 6 concludes the paper and presents some research avenues for future work.

Related work

Two approaches have been considered to visualize 360 • HDR images on HMDs. The first consists in applying existing TMOs to the entire 360 • image and display the result on the HMD. Some studies performed a comparison of many TMOs for many 360 • HDR images in order to find the most appropriated TMO. As for the second approach, a new TMO is proposed, it considers the specific visualization conditions on an HMD by applying a TMO to the viewport only. The first comparison of existing TMOs for 360 • images using a subjective evaluation has been run by Perrin et al. [START_REF] Perrin | Measuring quality of omnidirectional high dynamic range content[END_REF]. However, none of the evaluated TMOs show a clear increase of perceived quality. Melo et al. [START_REF] Melo | Tone Mapping HDR Panoramas for Viewing in Head Mounted Displays[END_REF] have ran another user study to compare four different TMOs on five 360 • HDR images and found similar results. So, we cannot rely on existing TMOs in the case of visualization of 360 • HDR images on HMD, a specific operator has to be developed. Yu [START_REF] Yu | Dynamic Tone Mapping with Head-Mounted Displays[END_REF] has adapted an existing operator to propose a TMO that takes advantage of the particularity of visualization on HMD. The main contribution was first to take into account the fact that a user only looks at a limited part of the 360 • image at a time, and second to simulate the light and dark adaption of human vision to provide smooth transitions between successive views. When compared to previous evaluations, instead of applying the TMO to the entire 360 • image, Yu's applies a TMO only to the current viewport. He has adapted the Photographic Tone Reproduction operator [START_REF] Reinhard | Photographic Tone Reproduction for Digital Images[END_REF] accordingly to the specific key value (log-average luminance) of the viewport. Indeed, the key value can significantly change from a view to another. To prevent flickering, Yu proposed to smooth the key value between successive views to coarsely reproduce the human eye adaptation behavior. Cutchin and Li [START_REF] Cutchin | View Dependent Tone Mapping of HDR Panoramas for Head Mounted Displays[END_REF] proposed a method that performs a tone mapping on each viewport independently depending on its luminance histogram. The viewport histograms are divided into four groups corresponding to different TMOs. Authors noticed popping effects that happen when two successive views belong to different groups: as the TMO is different, the image shifts dramatically. Both methods benefit from view dependency on an HMD and provide a better perceptible quality, but they still present some limits we want to overcome. These two methods only perform a global operation on the viewport without worrying about the spatial coherency of the entire 360 • image. We propose a method that takes advantage of the viewport dependent operation with smooth transitions between successive viewports to ensure a good contrast while maintaining a global coherency considering the luminance of the entire 360 • image. Our method implement the logarithm of the luminance to mimic the human perception of the lightness. To ensure the validity of this representation in case of visualization on HMD, we conducted a subjective evaluation that models the human perception.

Lightness perception on HMD

For classic 2D displays in a controled visualization environment, the lightness is modelled as the logarithm of the luminance. This result comes from Weber and Fechner [START_REF] Howes | Elements of psychophysics[END_REF] studies about lightness perception, and many TMOs are based on this work. We will show, thanks to a subjective evaluation, that this result holds for HMDs.

The lightness perception model

Weber showed that the human capacity to distinguish a stimulus from the background is linearly proportional to the background luminance. In other words, the lighter the background L, the higher the difference ∆L should be (between stimulus and background) to perceive the stimulus. This ratio is commonly known as the Just Noticeable Difference (JND):

JN D = ∆L L = k, (1)
with ∆L the luminance difference between the stimulus and the background (in cd/m 2 ), L the background luminance (in cd/m 2 ) and k a constant (around 0.01 for traditional visualization condition on a 2D display [START_REF] Reinhard | High Dynamic Range Imaging: Acquisition, Display, and Image-Based Lighting[END_REF]). Fechner integrated Weber's result to obtain the response of the visual system based on the luminance transducer:

dR dl (L) = 1 ∆L(L) , (2)
R(L) = L 0 1 ∆L(l) dl = 1 k ln(L), ( 3
)
where R is the lightness response for a given luminance L, and ∆L is actually the perceived difference measured by Weber's experiment. Accordingly, the subjective perception of lightness is assumed to be the logarithm response to the physical luminance. In our experiment, our objective was to reproduce as closely as possible the Weber's experiment while following the CIECAM recommendations [START_REF] Fairchild | Color appearance models[END_REF]. The CIECAM suggests a circular stimulus with a radius between 2 • and 4 • to match with the foveal vision. The background has an achromatic color with a radius of 20 • to match with the peripheral vision. Finally, the surround field encompasses the rest of the vision field (see Figure 1). Indeed, in case of visualization on HMD, the black plastic structure around the displays is interpreted as the surround. Recall that the CIECAM model has been determined for a background covering a 20 • vision for a classic display, while this angle corresponds to all of the Field of View (FoV) of the HMD. We consider a stimulus of 4 • , a background covering all the FoV of the used HMD (about 100 • ), and the surround field is ignored. Twenty participants have been presented with ten background luminance levels covering all the dynamic range of the HMD. For each background, a slightly lighter stimulus was displayed and incrementally increased until it gets perceived by the participant. This allows us to determine the JND. The test lasted about 15 minutes and our panel consisted of 20 participants (13 men and 7 women) with normal vision, from 20 to 57 years of age, with various socio-cultural backgrounds.

User study

After data fitting (see Figure 2), we found the JND is equal to 2%. Despite of finding linear sensitivity (∆L as a function of L) resulting in a logarithmic response by the Fechner's integration, in line with 2D visualization, the visual system perceives two times less contrast between the stimulus and the background. Indeed, the JND approaches 2%, while traditional visualization on a 2D display is usually around 1%. This result means that we can lose perceptible fine details when we watch an image on an HMD. This evaluation also emphasizes that the logarithmic lightness function (Equation 3) is valid to model the human perception on an HMD. We designed our HMD-TMO accordingly to this result.

HMD-TMO

As seen in previous evaluations [START_REF] Perrin | Measuring quality of omnidirectional high dynamic range content[END_REF][START_REF] Melo | Tone Mapping HDR Panoramas for Viewing in Head Mounted Displays[END_REF], applying a TMO to the entire 360 • image does not produce a satisfying quality. A TMO applied to the entire 360 • image takes into account all the luminance of the scene to produce the tone mapped result. Therefore, it maintains a global coherency but loses contrast in the viewports. Regarding a TMO applied to the viewport, it preserves the contrast but loses the global coherency of the scene. Since none of these methods produces a satisfying result when applied independently, we developed a TMO that combines both methods, global and viewport based, adapted to visualization on HMD in order to preserve global coherency and enhance contrast. Our operator consists in a pipeline with two branches (see Figure 3). The input is a 360 • HDR image and the output is a tone mapped image of the current viewport. The upper branch performs a tone mapping on the entire 360 • image and thus preserves the spatial coherency, while the lower branch performs a tone mapping on the viewport image to enhance the contrast. Note that the time parameter t means the viewports succession due to the movement of the user who is wearing the HMD. The combination of the resulting luminances of these two TMOs (tone mapping of the entire 360 • image G(L w ) and tone mapping of the viewport image V (L w , t)) is calculated by a geometric mean to compute the final tone mapped luminance L d (G, V ). Note that luminance stands for the Y channel in the CIE XYZ color space. Each component of our pipeline (entire image tone mapping, viewport tone mapping, and combination) are detailed in the following subsections.

Global tone mapping

First, we tone map the entire 360

P (b) = bi<b f (b i ) bi f (b i ) , (4)
G L w (x, y) = exp log(L dmin )+ log(L dmax )-log(L dmin ) ×P L w (x, y) , (5)
where L dmin and L dmax are respectively the minimum and maximum luminance of the display, L w (x, y) is the world luminance of the pixel (x, y), P (L w (x, y)) the CDF defined in Equation 4, and G L w (x, y) (our Global TMO) the resulting luminance of the pixel. To better match with human perception, Ward et al. add a pass of histogram adjustment in case of a too high contrast in the tone mapped image. Given the lightness perception values, the log-luminance histogram is clipped to avoid contrast exaggerations, which results in a flat CDF.

Figure 4 shows the result of three TMOs applied to the entire 360 represents the difference between the dark and the bright zone but it is not enough for the expected result due to the histogram clipping. Finally, the TMO using Equation 5(third row) seems perceptually too contrasted (the difference between the red and the green inset is significant) but it is the most representative of the global coherency. As will be seen in the next subsection, the contrast is managed by the viewport TMO.

Viewport tone mapping

The objective of the viewport TMO is to enhance the contrast in the part of the 360 • image currently viewed by the user (the viewport). We used an improved version of the viewport TMO proposed by Yu [START_REF] Yu | Dynamic Tone Mapping with Head-Mounted Displays[END_REF]. His method relies on a simplified Photographic Tone Reproduction operator [START_REF] Reinhard | Photographic Tone Reproduction for Digital Images[END_REF]. To avoid any flickering when changing view, Yu proposed to temporally smooth the key values to simulate the adaptation behavior of the human eye (see Figure 5). This TMO is based on the log-average luminance of the image:

Lw V (t) = 1 N exp x,y log δ + L w (x, y) , (6)
where Lw V (t) is the viewport key value at a given time, L w (x, y) the pixel luminance, δ a small value to avoid singularity in case the image contains black pixels, and N the number of pixels in the viewport. Here, time t corresponds to an orientation of the camera due to the head movement. To ensure a smooth transition between two successive viewports, the key and the white values are interpolated as:

L w (t) = α Lw V (t) + (1 -α) L w (t -1), (7)
L white (t) = αL white V (t) + (1 -α)L white (t -1), (8)
where L w (t) and L white (t) are respectively the smoothed key and white values between two successive views and α is a time dependent interpolation variable. Fig. 5. Photographic Tone Reproduction operator [START_REF] Reinhard | Photographic Tone Reproduction for Digital Images[END_REF] applied to a viewport sequence with smooth transitions. As the key value and the white value evolve from a view to another, the tone curve is modified and a same zone in the scene (red inset) becomes brighter or darker.

Finally, the luminance is scaled and high values are attenuated to avoid clipping:

L(x, y, t) = a L w (t) L w (x, y), (9)
V L w (

where a is a user defined variable which scales the luminance (commonly 0.18), L(x, y, t) the time dependent scaled luminance and V L w (x, y), t (our Viewport TMO) the displayed luminance. In his operator, Yu actually uses Equation 9 that does not avoid clipping in high luminances. We have now the global coherency assured by the 360 • image CDF (G(L w )) and the viewport contrast (V (L w , t)) we want to combine to obtain our final tone mapped image.

TMOs combination

To recap, we want to display a tone mapped viewport of a 360 • HDR image. In order to combine both luminances provided by the global and viewport TMOs, ensuring the global coherency to be preserved and the contrast to be enhanced, we propose to use a geometric mean to combine both luminances. After experimenting with different combinations (arithmetic mean, weighted sum and geometric mean), the geometric mean produces the best results (see Figure 6). The resulting images produced by the weighted sum combination are perceptually unpleasant.

As the lightness is the logarithm of the luminance, this combination is interpreted as a perceptual mean:

n i=1 a i 1 n = exp 1 n n i=1 ln(a i ) , (11)
L d (G, V ) = L d (x, y, t) = V L w (x, y), t × G L w (x, y) , (12)
where L w (x, y) is the world luminance of the pixel (x, y), t is the time, V (L w (x, y), t) is the viewport TMO defined in Equation 10and G L w (x, y) is the global TMO defined in Equation 5. L d (G, V ) is our final tone mapped luminance we display on the viewport. In Figure 7, we show the behavior of global, viewport and combined TMOs in both dark and bright areas of a 360 • image. When only the viewport TMO is applied, the global coherency is lost, both zones seem equally enlightened. Contrarily, regarding the global TMO, the global coherency is preserved but the contrast in the viewport is exaggerated and unnatural. Finally, the combination of these two TMOs preserves global coherency and provides a proper contrast in the viewport.

Results

Once our TMO has calculated the tone mapped luminance, we compute the color of all the pixels of the tone mapped image using the Schlick's approach [START_REF] Schlick | Quantization techniques for the visualization of high dynamic range pictures[END_REF]:

C = C L w s L d , (13)
where C and C are respectively the input and output trichromatic values (RGB), L w the world luminance and L d the tone mapped luminance. The saturation parameter s is set to 0.7 for our results. We implemented our HMD-TMO using Unity3D because of its friendly interface for managing VR and its capacity to handle HDR. We used the HTC Vive Pro3 as HMD. We benefited from GPU programming with shaders to compute 360 • image histograms on the 2048 × 1024 equirectangular projection, and the 1440 × 1600 viewports (left and right views) key values in real time. Rendering (computation of the colored tone mapped image) is achieved with an image effect shader applied to the HDR viewport. The global TMO is computed once for all and takes less than one second. The navigation (calculation and display of successive viewport images) is performed in real-time: 90 frames are computed per second (Intel Core i7 vPro 7th Gen, NVidia Quadro M2200). We used a dataset of 90 views: 15 views for each of the six different 360 • HDR images. We computed the Tone Mapped Image Quality Index (TMQI) [START_REF] Yeganeh | Objective Quality Assessment of Tone Mapped Images[END_REF] score of each view of each 360 • image, which amounted to compute 90 scores. We calculated the average of the viewport scores for our method and three other TMOs. Overall, our method had the best mean score (see Table 1). We also compared visually our results to those of Yu's [START_REF] Yu | Dynamic Tone Mapping with Head-Mounted Displays[END_REF] (see Figure 8). In addition to preserving the global coherency, our TMO avoids clipping luminances out of the dynamic range of the HMD. This improvement is shown on the church wall in the tree image, and in the background and at the bottom left corner of the forest image. Furthermore, due to the exaggerated contrast produced by the CDF, our HMD-TMO enhances the fine details. Indeed, in the tree image, the contrast between the night sky and the tree leaves is higher with our method, which allows us to distinguish holes through the foliage. The branches lying on the ground are also more detailed in the forest image. The same phenomenon occurs in both examples of the village image and in the folds of the curtain in the florist image. However, an unwelcome effect appears in the florist image. The lighting of the box practically disappears when using our TMO because its luminance is not enough represented by the CDF which flattens the zone within the green inset.

Conclusion

HDR imaging enables to capture the whole dynamic of a 360 • scene. Previous subjective studies have shown that naive tone mapping of the entire 360 • image or tone mapping of a viewport does not provide convincing results. To overcome these limitations, we have proposed a new HMD-TMO. More precisely, our contribution is twofold: (1) a logarithmic model of lightness still valid on an HMD;

(2) a novel TMO that combines both global and viewport TMOs. This new TMO doesn't tackle the limits of a viewport tone mapping but ensures a spatial coherency while navigating through the 360 • HDR content. Our future work heads toward HDR video tone mapping for visualization on HMD. The main challenge will consist in accounting for: temporal coherency, sudden change in luminance range through time, naturalness of time adaptation, etc.

Fig. 1 .

 1 Fig. 1. CIECAM conditions recommendations.

Fig. 2 .

 2 Fig. 2. ∆L as a function of L given the JND on an HMD.

Fig. 3 .

 3 Fig. 3. Our operator combines a Global TMO G(Lw) and a Viewport TMO V (Lw, t). The Global TMO (upper branch) aims to preserve the global coherency of the scene while the Viewport TMO (lower branch) aims to enhances contrast. The combination of both produces our final HMD-TMO L d (G, V ).

  where f (b) is the number of pixels for a bin b. The number of bins is set to 100 as proposed by the authors to avoid banding artifacts due to quantization. The tone curve G proposed by Ward et al. is a scaled version of P (b):

Fig. 4 .

 4 Fig.4. From top to bottom: the Photographic Tone Reproduction operator[START_REF] Reinhard | Photographic Tone Reproduction for Digital Images[END_REF], the Visibility Tone Reproduction operator[START_REF] Larson | A Visibility Matching Tone Reproduction Operator for High Dynamic Range Scenes[END_REF], and the CDF (all are applied to the entire 360 • image). To the right of each image, the corresponding tone mapping curves.

Fig. 6 .

 6 Fig.6. Comparison between weighted sum and geometric mean combinations. Combinations are respectively: 100% Viewport, 80% Viewport + 20% Global, 50% Viewport + 50% Global, and the geometric mean. The green, blue and red curves below correspond respectively to the Global TMO, the Viewport TMO and the combination.

Fig. 7 .

 7 Fig. 7. Two opposite views in a same scene, a dark side (top) and a bright side (bottom). From left to right: the viewport TMO V Lw(x, y), t (blue curve), the combination of viewport and global TMOs L d (G, V ) (red curve), and the global TMO G Lw(x, y) (green curve).

Fig. 8 .

 8 Fig. 8. Yu's TMO [3] (left) compared to our HMD-TMO (right). Our method enhances fine details and removes the clipping in high luminance.

  • image in order to preserve the global coherency of the scene. Similarly to Ward et al. Visibility Matching Tone Reproduction operator [9], our method is based on the log-luminance histogram of the image represented by a Cumulative Distribution Function (CDF). First, Ward et al. compute the normalized cumulative histogram of log-luminance value to find the CDF :

Table 1 .

 1 The result of the TMQI quality test: mean value computed on 90 images (Reinhard et al.'s[START_REF] Reinhard | Photographic Tone Reproduction for Digital Images[END_REF] and Ward et al.'s[START_REF] Larson | A Visibility Matching Tone Reproduction Operator for High Dynamic Range Scenes[END_REF] TMOs are applied to the entire 360 • image).

	Reinhard et al. Ward et al.	Yu	Ours
	TMQI quality 0.798	0.854	0.865	0.887

https://www.vive.com/fr/product/vive-pro/

Acknowledgments

All 360 • HDR images come from free SYNS and LizardQ datasets. This work has been supported by the ANR project ANR-17-CE23-0020. We would like to thank Kadi Bouatouch for his help and proofreading. Thanks to all experiment participants for their contributions.


The use of Human Orrery in teacher training, how to

introduce pre-service teachers to mathematics and science subjects by using a HO in primary classes

Maha Abboud, Emmanuel Rollinde

The use of Human Orrery in teacher training

STEAM enacted education with a Human Orrery

The Human Orrery integrates people directly into the Solar System experience. As they engage in the walk along planetary orbits, subjects develop an understanding of the motion of the planets in the Solar System through their sensing and moving bodies. Using a STEAM approach will involve concepts in physics (velocity, forces, reference frames, etc.) and mathematics (measure, proportionality, geometry, etc.) into a tightly coordinated immersive experience.

Initial Teacher training program

The program runs for five 3-hours sessions in teacher training institute and one-day work in primary schools. 1. Trainee teachers discover the Human Orrery throughout a preliminary set of activities developed by the educators. The focus is on the enactment process. 2/3. A science course followed by a mathematics course tackling the main physics, mathematics and astronomy concepts that are/could be engaged when using the HO. Training activities in these two sessions are grounded in theoretical frames from mathematics and science education. 4/5. In small groups, trainees design learning activities using the HO for one primary class each. Once the learning goal is chosen, prep materials are conceived along with observation grid in order to allow the after-implementation analysis. One-day experience in primary school: implementation and observation of the prepared activities with pupils aged 8-10 years. Each activity is conceived into two phases using HO in the courtyard and a printed version of the HO in the classroom connecting thus different levels of space. A last reflective training session takes place in the afternoon based on observations and experiences' feedback.

Feedback: Quotations from trainee teachers



Activities with the HO enabled me to show an effective link between mathematics topics and science topics 

The training I received has contributed to make me more engaged in teaching interdisciplinary themes  I now know better the difficulties of the pupils in relation to the knowledge at stake when learning some astronomy notions. 

Using the HO allows the notion of velocity to make more sense for young learners  Several mathematics concepts seem now to make more sense to pupils: radius, perimeter, distance calculation, time calculation

Discover and reproduce the elliptical shape of the orbits: micro and meso spaces Math: geometrical shape Science: planetary orbits Set-up: • In the courtyard (meso space), discover the SS objects and their orbits + follow the orbit of a comet using the gardener method and estimate the position of the second focus. • In class (micro space): draw the orbit of Saturn with the second focus given by the teacher.

Feedback: High engagement in the meso space. Difficulty to connect the same activity in meso and micro spaces. Too many differences or too high expectations ?

Relative positions in space

Math: Spatial position, alignment Science: Movement of planets in time

Set up:

• In the courtyard, locate children in a specific configuration corresponding to a specific date; children search the observed position among different pictures using geometric properties. • In class, confirm their choice and the date of the observation using Stellarium.

Feedback: Enhance the non-alignement of planets. Combination of different tools for planetary motions.

Measure of lengths to compare speeds

Math and Science: distance, duration, speed

Set up:

• In class, measure length of trajectories of constant duration for different planets using ropes and predict the fastest planet. • In courtyard, observe the different speeds in the courtyard and compare to predictions.

Feedback: speed in class remains abstract and is not effectively related to lengths that are embodied throughout manipulations, whereas in the courtyard speed is enacted, which makes the link between speed and length more meaningful.

What is the age of puppets born on different planet ?

Math: units of time, euclidian division Science: orbital period, velocity of planets Set-up :

• Each group has a puppet (a child born on a different planet). On Earth, the puppet is 10 years old. Feedback: strong identification of the pupils with puppets, difficulty in computation, contentment in the validation in the courtyard.


Jacob Olchowka

Long H B Nguyen

Thibault Broux

Paula Sanz Camacho

Emmanuel Petit

François Fauth

Dany Carlier

Christian Masquelier

Laurence Croguennec

Aluminum substitution for vanadium in the Na3V2(PO4 )2F3 and Na3V2(PO4)2FO2 type materials

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

These last years the booming electric and hybrid vehicle market conjugated to the development of renewable energy technologies have generated a strong interest in alternative electrochemical storage technologies to the Li-ion batteries. 1 Among them, Na-ion batteries are nowadays considered as a reliable and more eco-friendly alternative due to the high abundance of sodium widespread all over the Earth. Within the large panel of possible positive electrode materials, Na3V2(PO4)2F3 (NVPF) is among the most promising ones due to its excellent stability upon long range electrochemical cycling and to its attractive high rate performances when coated with carbon that allows fast charge compared to the layered oxides NaxMO2 (M= transition metal). [2][3][4] Moreover, the reversible extraction of two sodium ions at a potential of ~3.7 V (1 st Na + ) and 4.2 V (2 nd Na + ) vs. Na + /Na leads to an energy density comparable to that of the commercial Li-ion batteries using LiFePO4 at the positive electrode (507 Wh/kg for NVPF versus 530 Wh/kg for LiFePO4). 5 Currently, NVPF is used as a positive electrode material by the start-up TIAMAT that develops and produces functional 18650 cells as Na-ion battery prototypes. Very recently, the attractiveness of NVPF increased even more since Yan et al. demonstrated the possibility to increase the energy density of the full cell NVPF versus hard carbon of ~14% by extracting more than two Na + at high potential and due to its promising performances reported in aqueous systems. 6,7 In order to explore the possibility of modifying the values of the redox couples involved in the insertion/de-insertion reactions and thus the potential, the transport properties and the capacity retention at high rates, different approaches were explored. Anionic substitution of oxygen for fluorine has a significant impact on the crystal structure and electrochemical properties of Na3V2(PO4)2F3-yOy. [8][9][10][11] The richer the oxygen content, the lower the average discharge voltage and thus the energy densities are. Similarly, the effect of cationic doping/substitution for vanadium was studied using for instance yttrium, manganese, lanthanum or titanium in order to improve the electronic conductivity and Na + mobility. [12][13][14] However, only few of these studies actually addressed the characterization of the composition and the structure of the materials as obtained, in relation with the electrochemical performance. Kosova et al. have demonstrated that Lanthanum substitution was in fact a surface modification effect by LaPO4. 15 The group of Ceder has studied gallium and aluminium substitution for vanadium, with the aim to disrupt the charge and Na + orderings within the lattice and thus lower the energy barrier for the reversible extraction of the 3 rd Na. 16,17 Among the different metals, aluminium drew our attention as Al is cheaper, lighter, more environmentally friendly than V and, as a nonelectrochemically active element, could participate to the stabilization of the material upon cycling. Furthermore, the partial substitution of 0.5 Al 3+ for V in Na3V 3+ 2-zAlz(PO4)2F3 would lead to an increase of ~3% of the theoretical gravimetric capacity for the reversible exchange of 2 Na + ions, while keeping the extraction of the third Na + ion possible (i.e. for the exchange of 3 e -or Na + ions per 1.5 V 3+ in the pristine material). Bianchini et al. have reported an aluminium substitution for vanadium in NVPF limited to z = 0.3 (Na3V1.7Al0.3(PO4)2F3) through solid-state reaction. 16 However, a loss of reversible capacity was observed for the substituted materials, as only the V 3+ /V 4+ redox couple appeared to be involved in the redox processes in the potential range of 2 -4.5 V vs. Na + /Na. On the other hand, Lalère et Please do not adjust margins Please do not adjust margins be activated in the partially substituted NASICON Na3V1.5Al0.5(PO4)3 at an average voltage of 3.95 V vs Na + /Na. 18 In order to increase the Al-content in the substituted phases, Na3V2-zAlz(PO4)2F3, we here employed a sol-gel synthesis approach that allows a better chemical homogeneity of the precursors and leads to a higher material purity than through a traditional ceramic approach. 19 We performed the synthesis in acidic and basic media in order to study the effects of the pH on the crystal structure and on the electrochemical performances of the phases obtained.

For the synthesis of Na3V1.5Al0.5(PO4)2F3 in acidic medium (NVPF-Al0.5-acidic), citric acid monohydrate, NH4VO3 and Al(NO3)3.9H2O with an appropriate molar ratio 2 : 1.5 : 0.5 were first dissolved in a Teflon beaker containing about 100 mL of H2O. Then, NH4H2PO4 and NaF (5% in excess), were successively and slowly added to the solution. Once the solution turned green, which corresponded to the reduction of V 5+ to V 3+ , it was heated overnight at 80°C under continuous stirring, resulting in a beige/dark powder. This was finely ground, placed in a golden crucible, and heated at 350°C during 4h to eliminate the volatile species. The as-obtained powder was subjected to a second calcination at 650°C during 10h under continuous argon flow. Finally, the resulting black powder was washed in water to eliminate possible soluble impurities. The chemical composition of NVPF-Al0.5-acidic was confirmed by ICP-OES (Inductively Coupled Plasma -optical emission spectrometry) with Na:V:Al:P cationic ratios of 3 : 1.5 : 0.5 : 2. Several attempts were made to further extend the Na3V2-zAlz(PO4)2F3 solidsolution at z values higher than z = 0.5, with limited success. Most of the time, a mixture of Na3V2(PO4)2F3, Na3Al2(PO4)2F3, AlPO4 and NASICON-type Na3V2(PO4)3 were obtained. The crystal structure of NVPF-Al0.5-acidic was determined by Rietveld refinement using high-resolution synchrotron powder X-ray data (SXRD) from the ALBA synchrotron facility (see Figure 1a).

As for NVPF, NVPF-Al0.5-acidic presents a subtle orthorhombic distortion, which is described in the Amam space group (see Figures 1a andS1-S2, Tables S1-S2). 20 A shrinkage of the cell volume is observed in the NVPF-Al0.5-acidic phase (862.65(1) Å 3 vs. 877.54(1) Å 3 for NVPF), which is due to the smaller ionic radius of Al 3+ vs. V 3+ (respectively 0.535 Å and 0.64 Å in an octahedral coordination) (see Table S3 and Figure 2a-b).

The use of NaF in acidic media may leads to HF release, which is a volatile species that can easily evaporate at 80°C. In order to minimize the possible departure of harmful HF during the evaporation step, which may be the cause of the formation of NASICON-type phases, the synthesis procedure was further modified by using a NH4OH (28-30% NH3 basis) buffer solution to adjust the pH of the solution at ~9.2 during the dissolution process. By controlling the pH, the solution quickly turned into blue indicating the possible presence of V 4+ . Thanks to this modified method, a new family of Al-substituted phases, Na3V2-zAlz(PO4)2F1+zO2-z (0 ≤ z ≤ 2), was obtained (Figures S3-S4 and Table S3). AlPO4 is present as an impurity in some samples; however, this does not hinder the structural determination of the main phase by the use of Rietveld refinement. Figure 1b illustrates the SXRPD Rietveld refinement analysis of Na3V1.5Al0.5(PO4)2F1.5O1.5 synthesized in basic medium, called NVPFO-Al0.5-basic. This phase crystallizes in the tetragonal P42/mnm space group. The reliability factors (RBragg = 4.5% and Rwp = 10.4%) demonstrate the good quality of the Rietveld refinement despite the presence of AlPO4 as a secondary phase (up to ~12.1 wt.%) (Tables S4-S5). The cell parameters determined for the V 4+ -rich phase Na3V1.5Al0.5(PO4)2F1.5O1.5 are a = 8.9593(1) Å and c = 10.5511(1) Å with a cell volume V = 846.93(1) Å 3 , significantly smaller than those reported for the corresponding V 3+ -rich phase Na3V1.5Al0.5(PO4)2F3 (Table S3). Elemental analysis performed by ICP-OES leads to a cationic ratio Na:V:Al:P of 3:1.5:0.5:2, which was shown to be the composition of the main NVPF-type phase despite the presence of AlPO4 as impurity. Indeed, this latter is sparsely soluble in HCl solution, the acid used for the sample dissolution required to perform the chemical analyses (see supplementary information). Figure 2b shows a linear evolution of the cell parameter c (along the bioctahedral unit, see Figure 2a) for all the phases Na3V2-zAlz(PO4)2F1+zO2-z (0 ≤ z ≤ 2) implying a solidsolution formation according to Vegard's law. Interestingly, starting from the same V : Al ratio (V1.5Al0.5) and monitoring the sol-gel synthesis conditions in acidic and basic media, two original materials could be obtained: Na3V 3+ 1.5Al 3+ 0.5(PO4)2F3 and Na3V 4+ 1.5Al 3+ 0.5(PO4)2F1.5O1.5. The first composition maintains the same structure as NVPF, with a small orthorhombic distortion (b/a ~ 1.002) and Na + ions distributed among three different sites in the tunnels, whereas the second one is also stabilized in a structure close to that of NVPF, but described in Please do not adjust margins Please do not adjust margins a tetragonal unit cell with only two sites for the Na + ions. In order to get more insight into the difference in cell parameters between NVPF-Al0.5-acidic and NVPFO-Al0.5-basic, the environments of V (Al) in the two structures were compared, based on the structural determination performed by Rietveld refinement. The major difference was observed for the apical V/Al-(F,O) bond lengths along the bi-octahedral units (V,Al)2O8(F,O)3. As described in Figure 2c, the terminal V/Al-F bonds of the bi-octahedra V1.5Al0.5O8F3 observed in NVPF-Al0.5-acidic are of 1.928(2) Å which is in good accordance with the common value found for a Al/V 3+ -F bond. On the other hand, the terminal V/Al-O/F bond lengths are estimated to be of 1.654(3) Å in NVPFO-Al0.5-basic, which fits well with an average distance corresponding to the contribution of 25% of Al-F bonds close to 1.82 Å and of 75% of V 4+ =O vanadyl bonds close to 1.6 Å. 21 As oxygen and fluorine cannot be distinguished by X-ray diffraction and cannot be easily titrated by chemical analyses, analyses by Fourier Transformed Infrared (FTIR) and 31 P solidstate Nuclear Magnetic Resonance (ss-NMR) spectroscopies were performed and compared to those of Na3V 3+ 2(PO4)2F3 and Na3V 4+ 2(PO4)2FO2 as reference compounds. The absence of vibration bands characteristic of νV=O (vanadyl bond) at ~ 919 cm -1 in the IR spectrum of NVPF-Al0.5-acidic confirms that the material contains only V 3+ (Figure 3a) confirming the Na3V 3+ 1.5Al0.5(PO4)2F3 composition. Additionally, the 31 P ss-NMR spectrum of Na3V 3+ 1.5Al0.5(PO4)2F3 exhibits 5 signals which can be attributed to phosphorus surrounded by different numbers of V 3+ in its first cationic coordination sphere (the signals at ~6000 ppm, ~4500 ppm, ~3000 ppm, ~1500 ppm and ~0 ppm are attributed to P(OV 3+ )4, P(OV 3+ )3(OAl 3+ ), P(OV 3+ )2(OAl 3+ )2, P(OV 3+ )(OAl 3+ )3 and P(OAl 3+ )4 local environments, respectively). Based on our 31 P MAS NMR study of the Na3V 3+ 2-yV 4+ y(PO4)2F3- yOy phases, a V 3+ octahedra sharing a corner with PO4 tetrahedra results in a Fermi contact interaction of about 1500 ppm, whereas a V 4+ one do not lead to any shift contribution. 8 Here, a Al 3+ ion that does not possess unpaired electrons does not contribute to any Fermi contact shift and thus behave similarly as a V 4+ ions in the lattice. Based on the relative signal intensities, the Al 3+ /V 3+ ionic distribution in the material is close to the statistical one. On the other hand, as for the reference Na3V 4+ 2(PO4)2FO2 (blue spectrum), NVPFO-Al0.5basic (green spectrum) displays only a diamagnetic signal at ~0 ppm (see Figure 3b). This observation confirms the absence of V 3+ in the structure. Concomitantly, the FTIR spectrum of NVPFO-Al0.5-basic exhibits intense bands centred at ~925 cm -1 and its overtone at 1850 cm -1 revealing the presence of vanadyl bonds and hence, V 4+ in the structure, which confirms the Na3V 4+ 1.5Al0.5(PO4)2F1.5O1.5 formula (see Figure 3a). 22 The electrochemical signatures of the Na3V 3+ 1.5Al0.5(PO4)2F3 and Na3V 4+ 1.5Al0.5(PO4)2F1.5O1.5 were studied in half cells vs. Na and compared to those of Na3V 3+ 2(PO4)2F3 (carbon-coated) and Na3V 4+ 2(PO4)2FO2. Figure 4a displays the charge/discharge data of the four materials in the potential range 2.8 -4.5 V vs. Na + /Na and at a cycling rate of C/10 per Na + . For Na3V 3+ 1.5Al0.5(PO4)2F3, the charge is characterized by two "sloping plateaus" at average potentials of 3.69 V and 4.23 V vs. Na + /Na, which respectively correspond to the extraction of 1 and 0.5 Na + . The polarization is much greater than for NVPF, as more extensively discussed in the supplementary information, and the "plateaus" are more sloping as indicated by the broad peaks observed on the first derivative data (see Figure 4b). The high polarization induces Please do not adjust margins Please do not adjust margins significant capacity loss between the charge and discharge and the sloping "plateaus" reveal a solid-solution type mechanism upon insertion and desinsertion of Na + whereas intermediate phases and biphasic domains are observed for NVPF. The extraction of 1.5 Na + suggests that only the V 3+ /V 4+ redox couple can be activated in the electrolyte stability window (up to 4.5 V vs. Na + /Na) and the structural distortion in the bioctahedra induced by V/Al substitution does not allow the activation of the V 4+ /V 5+ redox couple in this potential range. The extra-capacity obtained at high potential (> 4.5 V vs. Na + /Na) (Figure S5) is not completely reversible and is discussed in the supplementary part S5).

The electrochemical signature of Na3V 4+ 1.5Al0.5(PO4)2F1.5O1.5 is also characterized by two "plateaus" corresponding to the reversible extraction of ~1 Na + and 0.5 Na + at average potentials of ~3.66 and 4.05 V vs. Na + /Na respectively. Compared to Na3V 4+ 2(PO4)2FO2, the Na + extraction voltage in Na3V 4+ 1.5Al0.5(PO4)2F1.5O1.5 is not affected by the Al-substitution. However, the polarization increases significantly leading to a reduction in the efficiency of the electrode material. The reversible extraction of 1.5 Na + shows that the (V=O) 2+ /(V=O) 3+ redox couple (or V 4+ /V 5+ with V engaged in vanadyl bonds) could be activated, on the contrary to the V 4+ /V 5+ engaged in V-F bonds. For Na3V 4+ 1.5Al0.5(PO4)2F1.5O1.5, the theoretical capacity is experimentally delivered.

To summarize, we succeeded to synthesize a highly substituted (Al for V) range of compositions in the Na3V 3+ 1.5Al0.5(PO4)2F3 solid-solution and reported for the first time the controlled synthesis of a series of combined anionic and cationic substituted positive electrode materials of general formula: Na3V 4+ 2-zAlz(PO4)2F1+zO2-z (0 < z < 2). The Al for V substitution has a minor effect on the average potential of the Na + extraction, on the contrary to F/O substitution that strongly lowers the extraction potential of the high voltage plateau (2 nd Na + ). For Na3V 3+ 1.5Al0.5(PO4)2F3, although the V/Al partial substitution increases the theoretical gravimetric capacity, only the V 3+ /V 4+ redox couple could be activated in the potential range 2.8 -4.5 V vs. Na + /Na which lowers the specific energy.

On the other hand, the theoretical capacity is reached for Na3V 4+ 1.5Al0.5(PO4)2F1.5O1.5. These results confirm also that the (V=O) 2+ /(V=O) 3+ redox couple (or V 4+ /V 5+ with V engaged in vanadyl bonds) could be reversibly activated in the stability window of current electrolytes, on the contrary to the V 4+ /V 5+ engaged in V-F bonds. These solid solutions call to be scrutinized much more in details to determine the substitution in Al and O just sufficient to optimize the properties of the very attractive electrode material for Na-ion batteries, Na3V2(PO4)2F3, the panel of properties being well beyond the reversible capacity only. Indeed, the chemical and thermal stability in the charge state of the battery is for instance one of them, as controlling the safety of the battery but also the long range cyclability.

Figure 1 .

 1 Figure 1. Rietveld refinement of synchrotron powder X-ray diffraction data recorded at λ = 0.6202 Å for: a) NVPF-Al0.5-acidic refined in the Amam space group and b) NVPFO-Al0.5-basic refined in the P42/mnm space group. The secondary phase (bottom grey tick lines) corresponds to AlPO4 and its concentration is refined to ~12.1 wt.%.

Figure 2 .

 2 Figure 2. a) Representation of the Na3(V,Al)2(PO4)2(F,O)3 crystal structure; b) Evolution of the c unit cell parameter of Al-substituted Na3V2-zAlz(PO4)2(F,O)3 phases as a function of the aluminium content; c-d) Description of the vanadium/aluminium bi-octahedra in Na3V 3+ 1.5Al 3+ 0.5(PO4)2F3 (NVPF-Al0.5-acidic) and Na3V 4+ 1.5Al 3+ 0.5(PO4)2F1.5O1.5 (NVPFO-Al0.5-basic).

Figure 3 .

 3 Figure 3. a) FTIR spectra of spectrum) assigned to be Na3V1.5Al0.5(PO4)2F3, Na3V2(PO4)2F3 (black spectrum (green spectrum) assigned to be Na3V1.5Al0.5(PO4)2F1.5O1.5, and Na3V2(PO4)2FO2 (blue spectrum) recorded in the wavenumber range 400 -1990 cm -1 b) 31 P ss-NMR spectra of NVPF-Al0.5acid (red spectrum), Na3V2(PO4)2F3 (black spectrum), NVPFO-Al0.5-basic (green spectrum), and Na3V2(PO4)2FO2 (blue spectrum) recorded at 100 MHz, MAS = 30 kHz c) The phosphorus environments corresponding to the five ss-NMR signals detected.

Figure 4 a

 4 Figure 4 a) Charge/discharge galvanostatic data for Na3V1.5Al0.5(PO4)2F3, Na3V2(PO4)2F3, Na3V1.5Al0.5(PO4)2F1.5O1.5 , and Na3V2(PO4)2FO2 at a cycling rate of C/10 per Na + . The materials were cycled versus Na metal in 1M NaPF6 in EC : DMC = 1 : 1 with 2 wt.% of FEC; b) The first derivative of the corresponding electrochemical data.

The authors thank the RS2E and Alistore-ERI Networks for the funding of LHBN's PhD thesis and TB's postdoctoral fellowship, as well as the financial support of Région Nouvelle Aquitaine, of the French National Research Agency (STORE-EX Labex Project ANR-10-LABX-76-01 and SODIUM Descartes project ANR-13-DESC-0001-02) and of H2020 research and innovation program under the Grant Agreement No. 646433-NAIADES. The authors also want to thank C.DENAGE, A. FARGUES and E.LEBRAUD (ICMCB) for their help with SEM, FTIR and XRD analyses, respectively.

Conflicts of interest

There are no conflicts of interest to declare.

Notes and references


Brandon Carlson

Kevin Leach
email: kjleach@umich.edu

Darko Marinov
email: marinov@illinois.edu

Meiyappan Nagappan
email: mei.nagappan@uwaterloo.ca

Atul Prakash
email: aprakash@umich.edu

Open Source Vulnerability Notification

Keywords: Vulnerable Dependency, Security Disclosure, Open Source

à 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.

Introduction

Open source project maintainers often ignore or overlook important preventative maintenance tasks, including security scans for vulnerabilities in libraries [START_REF] Kula | Do developers update their library dependencies? ESE[END_REF], even with automated upgrades of libraries [START_REF] Mirhosseini | Can automated pull requests encourage software developers to upgrade out-of-date dependencies?[END_REF]. Neglecting such scanning tasks can impact both the end user and the software maintainer. "Using Components with Known Vulnerabilities" [START_REF]Top ten security risks[END_REF] was listed among the top ten application security risks in 2017.

Bug bounty programs can incentivize security disclosures [START_REF]HackerOne: Vulnerability disclosure policy basics: 5 critical components[END_REF] but have not taken hold as a standard policy. The National Institute of Standards and Technology is constructing a new process for receiving, analyzing, and responding to vulnerability disclosures [START_REF]Rapid7: NIST cyber framework updated with coordinated vuln disclosure processes[END_REF], providing at least a guideline for open source projects to establish their own policies. Such vulnerability disclosure policies are growing in importance due to the continued increase of information breaches [START_REF] Cavusoglu | Efficiency of vulnerability disclosure mechanisms to disseminate vulnerability knowledge[END_REF]. For example, Equifax recently fell victim to a high-profile breach, resulting from an unpatched open source dependency (Apache Struts) [START_REF] Podjarny | Open source vulnerabilities tripped Equifax, how can you defend yourself?[END_REF]. In this paper, we suggest approaches to address this shortcoming in the open source community.

This paper makes the following contributions:

-

Motivating Experience

We were originally motivated by the Equifax breach [START_REF] Podjarny | Open source vulnerabilities tripped Equifax, how can you defend yourself?[END_REF], which was related to a vulnerable dependency (Apache Struts). GitHub already provides a dependency scanning tool that will alert project owners if vulnerabilities are discovered in those dependencies [7]. However, project owners are not required to address such reports. Indeed, project owners could decide the vulnerability is unexploitable through their project or that it is not worth the effort to address. In such a scenario, project owners that ignore reports from dependency scanning tools pose a risk to the community at large. Thus, we sought to investigate the prevalence of projects requiring vulnerable versions of Apache Struts. We used Snyk [26], a dependency scanning tool, to analyze various open source projects on GitHub for vulnerable dependencies. Indeed, we found many projects depended on a vulnerable version of Apache Struts. We visited each such repository to determine if a bug bounty program or disclosure process was documented. In the majority of cases, projects contained no guidelines for reporting vulnerabilities. We attempted to communicate this vulnerable dependency through a combination of emails to project owners, opening issues, and submitting pull requests.

Project owners offered myriad responses. While some did not respond and some thanked us for the report, one owner requested private communications over public pull requests or open issues. Unfortunately, attempting personal contact for other projects resulted in our GitHub account being flagged for spam. These diverse and sometimes discouraging responses suggest the open source community could benefit from some standardized practice among open source projects for reporting such vulnerabilities without facing retribution. Motivated by this need, we chose to systematically analyze a corpus of open source projects for vulnerable dependencies and corresponding policies for reporting them. and7). We focused on Java projects because it is a widely used language [START_REF]Octoverse[END_REF] amenable to our software scanning infrastructure [26]. Table 1 summarizes the statistics of the projects from each of these sources.

Evaluation

We seek to answer the following research questions (RQs):

-

Results

In the 600 open source projects we examined, we found an average of 7.8 direct or transitive vulnerabilities per project. Further, we used the severity scale based on the severity rating provided by Snyk as part of the scanning process (derived from CVE and CWE reports). The average number of high severity vulnerabilities was 4.1 per project, compared to medium severity level vulnerabilities which averaged only 3.6 per project, and low severity which averaged 0.1 vulnerabilities per project. We further categorize these open source projects containing vulnerabilities based on the severity level of vulnerabilities. A single project may contain multiple vulnerabilities that range from low to high severity. Overall, we obtained the following numbers of projects:

-266 projects used at least one dependency with a high severity vulnerability; -202 projects used at least one dependency with a medium severity; -39 projects used at least one dependency with a low severity; -215 had no known vulnerability.

Note that some of these sets overlap because some projects contained multiple vulnerabilities with different severity levels.

Overall, 64.2% (385 of 600) of the projects we examined used at least one vulnerable dependency. This result is consistent with a recent report that Java applications are likely to include at least one vulnerable library [START_REF] Williams | The unfortunate reality of insecure libraries[END_REF]. Although a vulnerable library does not necessarily mean that a project using that library can be exploited, it does represent a risk to the community overall. 4 Additionally, OWASP's 2017 report [START_REF]Top ten security risks[END_REF] described how such uncertainty could facilitate adapting known exploits to many projects.

We note that not all vulnerabilities are exploited equally-CVE reports for a vulnerability contain a Common Vulnerability Scoring System (CVSS) score [START_REF]National vulnerability database[END_REF], a measure of how exploitable that vulnerability is. We leave the consideration of CVSS and exploitability for future work.

Based on our results, the open source community is in need of a standard process of reporting potential security vulnerabilities to open source project owners. This process would allow the open source community and cyber security researchers to privately disclose potential security issues in a standardized way. Such a process could improve the quality and software of open source projects.

RQ2: How common are security notification policies?

Determining Whether the Open Source Project has a Security Policy We first scanned the project's README and CONTRIBUTING.md files for the keywords security, vulnerability, reporting, or disclosure. We also looked for files whose name contained a keyword. If no such files or keywords existed, we scanned the owner's user or group account page on GitHub for links to company or user webpages or public Wikis. When such pages existed, we (manually) scanned them for bug bounty or security disclosure policies. In cases where no such information could be gleaned, we considered that project to have no policy for reporting security vulnerabilities. For the remaining 581 projects, there is no standard recourse for reporting vulnerabilities. Recall from Section 2 that opening issues, submitting pull requests, or attempting private contact can result in unpredictable outcomes (including losing a GitHub account to the spam flagging system).

Results

For the 19 open source projects that contained a security notification policy, we manually read through the policy. We broadly categorize these policies as: bug bounty program, email address, or web form. First, 4 of 19 projects had a bug bounty program administered through HackerOne [START_REF] Hackerone | HackerOne[END_REF], which outlined the process, rules, and scope for an individual reporting a vulnerability. Second, 11 of 19 projects provided an email address to contact in case of a security vulnerability. Some projects provided a more specific security reporting policy that a security researcher might follow in reporting potential issues. Third, 1 of 19 projects contained a web form for submitting vulnerabilities. This project provided a detailed security reporting process. The remaining 3 projects had unique notification policies that did not fit into these three categories.

Security Policies at Scale Next, we considered projects from popular hosting platforms GitHub, GitLab, and BitBucket. We used two curated lists, one for BugCrowd [START_REF] Bugcrowd | Bugcrowd[END_REF] and one for HackerOne [START_REF] Hackerone | HackerOne[END_REF], that contained a list of current bug bounty programs [START_REF] Tetelman | bounty-targets-data[END_REF]. We searched the bug bounty lists for projects contained in the Libraries.io's dataset [START_REF] Nesbitt | Libraries.io open source repository and dependency metadata[END_REF]. Specifically, we used the repository owner name and project name from Libraries.io to find Bug Bounty programs.

We found that, of the 30,705,634 repositories in Libraries.io's dataset, only 6,645 open source projects have a bug bounty program. We interpret this as a sign that the open source community does not have a standard process to report security vulnerabilities. Additionally, our analysis suggests that significant effort is required to find security policies in projects where they do exist. This has the potential of inducing failures to report vulnerabilities appropriately or at all. We consider a project to have no contact information available if none of the above steps yield contact information. We used a stopwatch to measure the approximate time taken to find (or fail to find) contact information.

Results We discovered 19.8% (119 of 600) of open source projects contained no publicly available contact information. Among the remaining 481 open source projects that provided contact information, 27.0% (130 of 481) contained contact information in the README file. The remaining 351 projects required more thorough investigation to determine contact information.

Table 2 shows the breakdown of where we found contact information for open source projects. For the majority, we found the contact information on the repository group's or top contributor's account page on GitHub. The next most popular location was within the README file contained in the repository. For the remaining open source projects, we found the contact information in a variety of locations described above.

Table 3 shows the breakdown of different forms of communication we found in these open source projects. In several cases we found multiple forms of communication but no preference or priority associated with each form. The majority of cases had an email address. We note a heterogeneity of communication forms associated with open source projects, adding to the potential communication burden associated with reporting vulnerabilities.

We approximated effort required to find contact information by measuring the time taken to search projects as described above. It took us an average of 44 seconds (± 2.6 seconds with 95% confidence) to search a project for contact information. Times ranged from 7 seconds to 300 seconds. We observed a bimodal effect with times: projects would either take a very short time (e.g., if the top of the README happened to contain contact information) or a very long time (e.g., if it was not clear without searching through many files in the project). While 44 seconds may not seem like a significant burden, Liu et al. [START_REF] Liu | Understanding web browsing behaviors through Weibull analysis of dwell time[END_REF] showed that the first 10 seconds that users observe a newly loaded web page are critical. These results suggest that a person may lose interest before successfully finding contact information for an open source project.

Recommendations and Discussion

In this section, we discuss two potential approaches to addressing the reporting of security vulnerabilities of open source projects. First, we suggest introducing a standardized SECURITY.md file to projects that describes basic contact information and disclosure processes for vulnerabilities. Second, we discuss a potential addition to hosting platforms (such as GitHub) to support private or hidden pull requests that enable developers or security researchers to disclose vulnerabilities.

SECURITY.md Mechanism for Vulnerability Notification

Given the dearth of security reporting policies among open source projects, we recommend the creation of a SECURITY.md file in open source repositories. This file would contain contact information and the disclosure policy of an open source project. Of the 19 open source projects that contained such a policy, only one of those projects described the policy in the repository itself, while the remaining 18 projects required additional effort to find the relevant information.

The creation of a SECURITY.md file would provide a solution to the open source community that is currently lacking a standard process as shown by both our research and in the Snyk's report [START_REF] Snyk | The state of open source[END_REF]. Additionally, lacking public information can make it difficult to assess the overall commitment to security from an open source project and to understand how to disclose newly discovered vulnerabilities to open source project owners [START_REF] Snyk | The state of open source[END_REF].

We suggest an adaptation of an existing RFC, "A Method for Web Security Policies" [START_REF] Foudil | A method for web security policies[END_REF], modified for an open source repository. We suggest using the SECURITY.md file in the root of a repository to contain basic contact information (email addresses) and optionally contain text describing the security policy, encryption, and contribution guidelines for the project. Such a file could help inform the community and cyber security researchers with an effective way to report vulnerabilities as they are discovered.

Adding SECURITY.md provides a beneficial method for standardization of vulnerability reporting processes. This recommendation also helps to fix an issue that was discovered in the 2017 Open Source Survey by GitHub where one of the largest issues was "Incomplete or confusing documentation" [START_REF]Open source survey[END_REF]. Additionally, by including this file in an open source project's repository, it shows that the project has a commitment to improving the security of the project.

Furthermore, Williams and Dabirsiaghi [START_REF] Williams | The unfortunate reality of insecure libraries[END_REF] suggest using a vetting process when choosing whether to use a project's library or source code. Considering the majority of open source projects currently do not have a security reporting process, the addition of the SECURITY.md would fulfill Williams and Dabirsiaghi's recommendation [START_REF] Williams | The unfortunate reality of insecure libraries[END_REF] by providing a way to vet projects.

Adapting Hosts to Facilitate Security Disclosures

As an alternative to SECURITY.md, open source hosting platforms could provide new features to facilitate communication of vulnerabilities. For example, based on our experience described in Section 2, we suggest the creation of a "verified researcher" tags to be associated with an account that has built a reputation for submitting pull requests or issues that disclose security vulnerabilities. These tags would allow project owners to evaluate contributor account reputation. As another example, hosting platforms could provide features for submitting private/hidden pull requests and issues that would be visible to project owners but not fully public.

Our recommendations seek to increase the interaction between the open source communities and vulnerability research communities. Establishing better interaction would reduce burden on reporting vulnerabilities and vetting contributors (e.g., by focusing on the requests from verified accounts). The increased interaction could help improve security in open source projects.

Related Work

We draw inspiration for standardized security policies from several sources. RFC2142 [START_REF] Crocker | Mailbox Names for Common Services, Roles and Functions[END_REF] suggests that organizations maintain a security@domain mailbox that is used for security bulletins and questions. However, it does not specify where or how such information should be made known publicly. We build upon this work by suggesting standardized locations for security policy information to be placed in an open source software repository.

Foudil and Shafranovich [START_REF] Foudil | A method for web security policies[END_REF] suggest placing a security.txt file in the root of a web server that allows websites to define security policies. Such information could define how owners can be contacted with security concerns or how a bug bounty program would work. We build on this work by suggesting SECURITY.md be added to open source repositories.

Snyk's report [START_REF] Snyk | The state of open source[END_REF] investigated the top 400,000 public repositories on GitHub to see if there was any documentation for basic security information for the open source projects. No details were made available in the report about the process they used to look for such information, which programming languages they considered, or a definition for basic security information. Additionally, the report did not propose a solution to this problem, but instead highlighted a current problem in the open source community. In our work we focused on one programming language, Java, and outlined how we selected open source projects and gathered information. Additionally, we proposed a recommendation on how to improve the current lack of security vulnerability reporting process in open source projects.

Decan et al. [START_REF] Decan | On the impact of security vulnerabilities in the npm package dependency network[END_REF] mined statistics about security vulnerabilities from over 600,000 open source projects. They found that 50% of security vulnerabilities survive to 30 months after being introduced. However, they also found that 50% of vulnerabilities were fixed within 1-2 months after discovery. This statistic suggests that having a mechanism in place to disclose vulnerabilities could help contribute to more rapidly fixing vulnerabilities.

GitHub already informs project owners about potentially vulnerable dependencies included in a project by examining commit messages and CVEs [7]. However, GitHub's technique only works for those projects that adopt GitHub's file format for describing dependencies, which is language-specific and limited to Java, JavaScript, .NET, Python, and Ruby. It still does not address the issue of how researchers or other developers (who may have developed other ways to detect vulnerable dependencies) could privately disclose potential vulnerabilities.

Limitations

Our recommendation to add a SECURITY.md file may be a burden for project developers to properly maintain. Additionally, older or abandoned open source projects may not add new files. In this case, the only option for a security researcher is to leave a public issue or pull request on the open source project so that future users of the project are made aware of the security vulnerability and have a way to fix it prior to using the project. We note there is currently a limit-but no transparency!-on how many issues or pull requests a security researcher can make before an account is flagged for spam.

Our other recommendation is that open source hosting platforms provide new features for reporting security vulnerabilities. The limitation is that open source project owners cannot do it just themselves as with the SECURITY.md file.

Conclusion

Both the open source community and the providers of open source repositories need a method to communicate security vulnerabilities, which would both give a voice to project owners about how they want disclosures to occur, and give service providers (e.g., GitHub) better understanding of user needs.

In this study, we evaluated three different aspects of 600 open source Java projects: [START_REF] Bugcrowd | Bugcrowd[END_REF] how frequently open source projects use known vulnerable libraries, [START_REF] Cavusoglu | Efficiency of vulnerability disclosure mechanisms to disseminate vulnerability knowledge[END_REF] whether open source projects contain security vulnerability reporting policies and what kind of policy is it, and (3) how much effort is required to find contact information for an open source project. Our findings showed a high ratio of the open source projects currently contain at least one vulnerable dependency. Although this does not guarantee the vulnerability can be exploited, it does show that there is at least some risk to the project and its users until the dependency can be updated to a non-vulnerable version. Additionally, with the exception of 19 open source projects, the majority of projects lacked some kind of security vulnerability reporting process that was easily accessible. Finally, the majority of open source projects studied did have some kind of contact information, but it was often not easy to find, and there is no guarantee that contact information found would be the correct person or group to contact about potential security vulnerabilities.

To address the current shortcomings of security reporting policies in open source projects, we proposed one recommendation to create a SECURITY.md file that would contain the necessary details about the open source project's security reporting policy and who to contact when (or if) a potential security vulnerability is discovered. To encourage the adoption of SECURITY.md, we could create a website in similar to securitytxt.org [START_REF] Foudil | [END_REF] to gain feedback from the open source community to improve the concept of SECURITY.md. Another recommendation is for open source hosting platforms to provide new features for private disclosure of vulnerabilities. Many challenges remain in the process of reporting potential security vulnerabilities to the open source community.

  An empirical study on how many open source projects are using vulnerable dependencies, contain security policies, and ways for individuals to contact the open source project. -A quantitative analysis of the findings from the data collection process using open source Java projects from GitHub. -Recommendations for improving security of open source projects through improved communication among the open source community, security researchers, and the open source repository providers.

Table 1 .

 1 Projects Selected by Resource

	Resource	Projects Stars Forks Issues Commits Contributors
	Libraries.io [21]	209 141	57 12.6	608.6	12.6
	Legunsen et al. [17]	126 244 103 14.5	333.1	11.8
	Munaiah et al. [20]	83 2195 685 59.1	545.2	16.6
	GitHub trending Java projects [11]	71 2400 923 52.1	1537.5	27.0
	Government-sponsored [9]	68	8	7	3.0	648.1	8.1
	Government-funded research [10]	22	8	5	2.9	152.0	3.4
	Government civic hackers [8]	21	3	3	2.6	2536.4	6.4
	Total Projects	600
	3 Project Selection and Data Collection
	To learn whether open source projects contain both easy to access contact in-
	formation and a security vulnerability reporting policy we selected open source
	Java projects from GitHub using seven different sources: (1) Libraries.io's public
	dataset [21]; (2) Legunsen et al. [17]; (3) Munaiah et al. [20]; (4) GitHub trend-
	ing Java projects [11]; (5) GitHub and Government list of government-sponsored
	open source projects [9]; (6) GitHub and Government list of government-funded,
	research-related open source projects [10]; and (7) GitHub and Government
	list of civic hackers open source projects [8]. These sources entail a combina-
	tion of public repositories (1 and 4), previously published work (2 and 3), and
	government-funded and whitehat hacker projects (5, 6,

  Recall from Section 4.1 that 385 of 600 open source projects contained at least one vulnerable dependency. Of those projects, only 3.4% (13 of 385) had a security vulnerability reporting process. The other 96.6% (372 of 385) open source projects which had a vulnerability had no publicly available security vulnerability reporting process. Overall, out of 600 open source projects, only 3.2% (19 of 600) had some type of security vulnerability reporting process. The remaining 96.8% (581 of 600) had no security vulnerability reporting process based on the aforementioned method.

Table 2 .

 2 Location of Contact Information

	Location of Contact Information	Count
	Account Page	339
	README	130
	Other Locations	12
	None	119
	4.3 RQ3: Is contact information available for open source projects?
	Approximating Effort to Discern Point of Contact We manually in-
	spected each open source project using the following steps:

1. Check the project's README file 2. Check the CONTRIBUTING.md file 3. Check the GitHub Wiki page 4. Check on the repository's account or group page 5. Check any provided website for the project (e.g., in the project description) 6. Check any provided website on the repository's account or group page 7. Check whether the Top Contributor for the project has their contact information publicly available (not just email addresses in Git commits)

Table 3 .

 3 Type of Contact Information Found

	Form of Contact Information	Count
	Email	312
	Website	108
	Gitter	29
	Google Group or Forum	22
	Twitter	17
	IRC	6
	Slack	5
	LinkedIn	3
	Mailing List	3
	List of Individual Contacts	2
	Discordapp	1

This effect can be viewed as a dual of herd immunity with immunization-the more projects use vulnerable libraries, the more risk there is to the community as a whole.

Acknowledgments

We thank Snyk [26] for providing us access to their tool and data. This material is based upon work partially supported by the US Air Force Research Laboratory under Contract FA8750-15-2-0075 and US National Science Foundation under Grant Nos. CNS-1646305, CNS-1646392, CNS-1740897, and CNS-1740916.