Jean-Marc Boussard

The future of the European sugar market : A case for quotas

Keywords: quotas, cobweb, market

The advertised EC policy toward sugar is clearly to let market drive supply and demand. But there exist reasons to think that the setting up of the traditional quota policy was not a consequence of chance, or of an efficient lobbying system by farmers, but of practical necessity and of efficiency, in face of market failures. In view of this reasoning, it is not impossible that a large crisis in the more or less remote future leads to reinstall a sugar quota system which probably should had to be reformed, but should never have been suppressed.

I. INTRODUCTION

A European sugar market stands as a very new idea, after so many years of quotas, administered prices and other deviations from market law. Yet, it is indeed a very old idea, so old that, after such a long time of oblivion, it looks now as being new. In most European countries, sugar production has been more or less isolated from market since at least 1931 (the first international sugar agreement, already defining production quotas among stakeholders), and even earlier (remember the Napoleonic "continental blockade", at the origin of the development of sugar beet in Europe). Especially since the Common market inception, the European sugar industry has been characterized by a government fixed domestic price, and a system of production quotas.

In face of this situation, it is generally agreed upon that we should come back to the good old time when free market was matching supply and demand without causing headaches to EC executives. Actually, common elementary economic theory shows that market in this respect is normally very efficient, equating marginal cost with price, thus maximizing the global surplus of consumer and producer together. In addition, at international level, by exploiting the benefits from comparative advantage, the market guarantees the minimal price compatible with demand, thus benefiting to consumer, while benefiting also the poor, the only workers capable of producing at that price. Who could resist such a set of advantages? Yet, before answering this question, we must perhaps ask ourselves why is it that, while the advantages were also present at the origin, our forerunners decided to leave them out, and judged preferable disconnecting sugar from market. Indeed, a market is a fairly "natural" institution, which normally emerges spontaneously, as soon as the benefits of specialisation and of comparative advantage become apparent. A sugar market existed in Europe before 1931. On the contrary, the decision of twisting markets in order to substitute another mode of regulation for production and consumption requires political decisions which, at least in principle, should not be taken lightly. What was the motivation, at that time, for isolating European sugar national productions from market? And have these reasons disappeared, thus justifying the new course of government action, coming back to the old idea of market?

I -WHY HAVE OLD PRACTITIONNEERS CUT THE LINK BETWEEN AGRICULTURE AND MARKET?

Actually, these motives were expressed in the debates regarding the 1931 sugar agreement, and can be summarized in five words: the market was not functioning properly (despite efforts in 1903, see: [START_REF] Taussig | The end of the sugar bounties[END_REF]). Indeed, at that time as now, the free international market resulted in prices sometime much too high and sometimes much too low to reflect the actual long run cost of production. In such situations, producers benefit and consumers suffer (or the contrary), but in any case, losses are greater than benefits. A large body of literature was devoted to this issue in the aftermath of the Second World War. Let us only remember Waugh [START_REF] Waught | Does the consumer benefits from price instability?[END_REF], Oi [START_REF] Oi | The desirability of price instability under perfect competition[END_REF], Massell [START_REF] Massell | Price stabilisation and welfare[END_REF] and many others. They do not congregate on the ultimate beneficiary of instability: for instance, Oi consider instability is good for the consumer, while others assert that consumer pay the cost at the end. But all agree upon at least one thing: instability is bad for society. In this context, any institutional innovation capable of making price closer from cost brings a social benefit.

In face of such a situation, actions are requested to correct failures. But action cannot be efficient unless the reason for the failure is correctly assessed. The reasons for this situation in the case of sugar (contrasting with many other goods and services) are deep and long lasting. They were analysed by many now forgotten economists such as Galiani [START_REF] Galiani | Dialogue sur le commerce des bleds[END_REF](in 1770 !) or Ezekiel [START_REF] Ezekiel | The Cobweb Theorem[END_REF] (at the end of the 30's) : with production delays and a low price demand elasticity, the market equilibrium point is instable (in the mechanical meaning of the word : in the vicinity of equilibrium, forces which drive the system lead it further away if it is fortuitously deviated from this point, just as a ball in equilibrium at the sharp end of a pencil).

The old "cobweb theorem" actually shows that. Let the slopes of the demand and supply curves be α and a, respectively, while production decisions are based on naive expectations (producer assume the current price will last at least one season) . Then, if |α/a| > 1, any departure from equilibrium will result in a new price even more distant from the true equilibrium price than the initial one. On the contrary, with |α/a| <1, each successive price will be closer to equilibrium, in such a way that the market "converges" to optimum. For that reason, the situation of markets is quite different according to the supply and demand parameters. This is the reason for why Ezekiel considered possible to let free market operate in the case of "luxury" products, while State intervention was required for first need goodespecially, agricultural goods1 .

The weakness of the cobweb model is of course that it is not possible to imagine prices and quantities swinging between -∞ and +∞. When the system comes vary far from equilibrium, there must exist other forces tending to turn it back toward it. But price can never stay for long in the vicinity of the long run equilibrium point, resulting in chaotic motions (again, in the mathematical sense of the word) for the price and production time series. Boussard [START_REF] Boussard | When risk generates chaos[END_REF], among many others, showed that such mechanisms are possible.

In such a context, government actions aiming at regulating market, especially with production quotas, can be largely beneficial in terms of welfare. This is especially the case for sugar.

II -WHICH FUTURE FOR THE WORLD SUGAR ?

In effect, the consequences of a liberalisation of the sugar industry have been examined in this context by Boussard and Piketty [START_REF] Boussard | Can market support trade? The case of sugar[END_REF]: they build a model of the sugar food chain which give the results presented on figure 1 and 2 : as we can see, prices are much more volatile "with" than "without" liberalisation. Then, who benefit and who suffer from the change ? The surplus accruing to various agents in the chain are shown below (figures 3 to 6). It is readily shown that farmers suffer from reduced production, while consumers suffer from higher mean price. This is a classical effect of introducing risk considerations in a model. Governmentespecially developing countries government -suffer from the reduction of import taxe -it is true, at the same time, that governments of rich countries avoid a few subsidies, although not so much in the case of sugar, because subsidies are paid by consumers. Finally, the major beneficiaries are the refiners, who benefit from speculating on stocksalthough without significant effects on the price volatility.

How can such a disaster be explained? Essentially, by the bad functioning of markets, which calls for State intervention in order to correct market failure. And how can State intervene in such a situation ? Precisely, by setting up a system of production quotas, just as the sugar practitioners of 1903 did very rightly. In effect, a natural way of settling the problem just stated is to provide producers with a guaranteed price. If the price is in the vicinity of the long run equilibrium price, the system is in principle costless for the government, because what is lost when external price is low is regained in periods of high prices. This is true in a static reasoning. It is not anymore true in dynamics: in the long run, with a production function homogenous and of degree one, the production, in face of an invariant price, is either zero or infinite. In such a case, assuming the price is high enough for avoiding zero production, the government will be obliged to accept enormous disposal costs 2 . Hence the 2 As a matter of fact, this is exactly what happened in the EC for most supported commodities. This outcome had been predicted at the CAP inception by economists such as Colin Clark [START_REF] Peters | Colin Clark[END_REF], who had seen the guaranteed price system as the main vulnerability of the ongoing institutional building. necessity of providing a price guarantee for a limited quantity only. In this way, the quota system is quite similar to a futures market -except that the cost of the risk tacking is fully born by the State a no price, while, otherwise, speculators must be rewarded for having accepted carrying risks in the place of farmers. It is by no means contradictory with markets, since quantities exceeding quotas can very well be traded at the producer risks. Only, in that case, it is necessary that the total allocated quotas be less than domestic production: then, any quantity sold on the world market is produced at marginal cost plus a risk premium, in exactly the same way as in the absence of any production policy. In that respect, quotas are even less distortive than is the present system of decoupled payments (the dynamic consequences of which are in general underestimated).

CONCLUSIONS

The future of the European sugar chain is therefore gloomy in the short run. It will certainly be improved in the long run, when the necessity of reinstalling the quotas system, the efficiency of which is proven, will become apparent. Unfortunately, the occurrence of a deep crisis will be necessary for that to occur. But how could economists be taken seriously without crisis?

Figure 1 :Figure 2 :

 12 Figure 1 : World prices for raw and white sugar, present situation

Figure 3 :Figure 5 :

 35 Figure 3 : Consumer surplus

Figure 4 :Figure 6 :

 46 Figure 4 : Producers surplus

th Congress of the European Association of AgriculturalEconomists -EAAE 2008 (revised)

The argument was made use of in convincing the reluctant Supreme Court not to reject the Roosevelt Agricultural Adjustment Act. See Lindsey[START_REF] Lindsey | The Roosevelt revolution first phase[END_REF]


Pierre Parrend
email: pierre.parrend@insa-lyon.fr

Stephane Frenot
email: stephane.frenot@insa-lyon.fr

Sebastian Höhn
email: sebastian.hoehn@iig.uni-freiburg.de

Privacy-Aware Service Integration

Privacy mechanisms exist for monolithic systems. However, pervasive environments that gather user data to support advanced services provide little control over the data an individual releases. This is a strong inhibitor for the development of pervasive systems, since most users do not accept that their personal information is sent out to the wild, and potentially passed over to third party systems.

We therefore propose a framework to support user control over the data made available to service providers in the context of an OSGi based Extensible Service Systems. A formal privacy model is defined and service and policy descriptions are deduced. Technical system requirements to support these policies are identified. Since guaranteeing privacy inside the system is of little help if any malicious entity can break into it, a security architecture for OSGi based Extensible Service Systems is also defined.

Pervasive Service Systems

In order to evolve from rigid systems or research tools towards dynamic service environments suitable for commercial systems, pervasive systems need to provide security and privacy during service discovery and execution. Users do not want their private data to be passed on to third parties, or extensive profiling to be performed on the basis of the data they send to perform single requests. Such a control is extremely difficult to achieve in the case of open pervasive systems, i.e. systems where unknown providers can offer their services. Fortunately, this generic case does not match the current business models of pervasive systems. The latter can be defined as follows: one Service Provider is responsible for making services available to users and for ensuring that they are allowed to access them. The master Ser-vice Provider typically calls on subcontractors to advertise a large set of services. He is responsible for the publication of services and for the quality of service (and hence also privacy and security requirements).

Among possible use cases are automotive telematic systems [START_REF] Merk | Security for downloadable automotive services[END_REF][START_REF] Raue | B2v palace -presence and location awareness in a collaborative environment[END_REF], which allow drivers to find their way using real time traffic information, to be informed of nearby restaurants or to use on-board information systems. A second example are Home Gateway systems [START_REF] Parrend | A security analysis for home gateway architectures[END_REF], which let users manage their home appliances and install new software extensions. A third is the retail store, which uses RFID chips to track supplies bought by the customers and provides additional commercial information or for instance vocal information on available products for the visually impaired.

The services in such pervasive systems are made available under two complementary forms: either remotely accessible services (e.g. Web Services ), or downloadable (OSGi) code bundles, which provide services that are locally accessible. These we call Pervasive Service Systems. Privacy can be achieved in this context by controlling the data that is collected by all (remote and local) services and the propagation of this data. Therefore, the privacy properties of each service must be published as service meta-data. Trustworthiness of meta-data can be achieved in business scenarios because one single provider is responsible for publishing the services and their meta-data. The providers have therefore a strong incentive to publish correct declarations, in order to maintain their business relationships. Furthermore, meta-data can be considered a legal contract and law suits are initiated if these contracts are not respected [START_REF] Sackmann | Personalization in privacy-aware highly dynamic systems[END_REF].

The goal of this paper is to provide a framework for monitoring the privacy properties of Pervasive Service Systems, along with the technical requirements it implies. The framework is a compound of two elements: an architecture for secure interactions between the users and the pervasive system and a meta-data language that expresses privacy prop-erties of services and user-defined policies.

This paper is set out as follows. Section 2 presents the security architecture for Pervasive Service Systems and section 3 the privacy model for such systems. Section 4 discusses the technical requirements of the end-user execution platform for privacy policy enforcement.

Secure Architecture for Pervasive Services Provisioning

The security architecture is a strong requirement for privacy-aware systems: if an attacker can gain access to personal information all other countermeasures become useless.

First, the service publication and provisioning processes are defined. Secondly, a security analysis of this architecture is performed.

Architectural Overview

Highly dynamic systems need to support runtime extension: in the case of automotive services, the change of localization often implies the modification of available services; in the case of Home Services, new devices are bought by the users and their functionalities need to be supported; in the case of the Future Supermarket, the user can go to one or another store, or specific shelves may be bound to specific services within the same store. Two complementary mechanisms can be used to support the runtime extensibility of such systems: (1) the discovery of remote services (as in SOA systems), and (2) the runtime extension feature provided by the OSGi platform, which makes it possible to install new applicative bundles without perturbating the running services (in particular without the need to reboot).

Two steps are necessary to enable the end-user take advantage of the services: the publication of those services (in the form of bundles or of remote services), and their provisioning by the user. The provisioning means the process of discovery, selection, validation and integration of the services in the user system. The end-user can either act directly to obtain new services or the system performs this operation automatically to update the services, adapt them to an evolving context or ensure the continuity in front of changing services.

Two protocols are defined: one for the discovery and provisioning of remote services and the other for bundles. The protocols are parallel: the client system gets the list of available services and automatically selects the ones that are compliant with local policies. The users can select the services/bundles they actually want to use. In the case of bundles, these latter are downloaded and installed. The applications can then be used. Figure 1 shows this protocol in the case of OSGi bundles. The monitoring of privacy in highly dynamic systems is based on two fundamental requirements. First, the architecture needs to be protected against external aggressions and malicious actors. Then, a framework for ensuring policycompliant service behavior inside the system is required.

Security Analysis

The protection of the Pervasive Service Architecture is achieved through two complementary elements: a service supplier side security control and a client side security control. The security modules on the client execution platform are also presented. The reference security properties for a distributed system are confidentiality, integrity and availability [START_REF] Müller | Multilateral Security in Communications. Informationsecurity[END_REF]. These properties must be enforced on the supplier side as well as on the client side.

The service providers must ensure that the services they propose use secure communication channels for service access and for bundle deployment. This enforces the property of confidentiality and integrity of the communication against eavesdropping and man-in-the-middle attacks. It must also guarantee that the users that access the services are allowed to do so. Next, to limit the potential reliability weaknesses that could result in security breaches on the client side, the provider must guarantee that the remote services and bundles do not introduce reliability weaknesses. This is typically achieved through extensive testing or use of fuzzing techniques, i.e. giving random data as service input to stress them. Lastly, the service provider is responsible for providing security and privacy meta-data for the services. In the considered use cases, a single service provider manages the system. It is considered as trusted with regard to metadata publication, since the commercial service provider will not provoke inconsistency in the behavior of services.

The client execution environment must supervise these properties on its own side. The communication channel must be protected to ensure confidentiality and integrity. The remote servers must be authenticated to prevent the use of malicious services or installation of malicious bundles. Moreover, the client platform must check the compliance of advertised services with local security policies. Lastly, the client platform should have satisfactory reliability properties and be robust against ill-formed bundles and services.

Privacy Model

The Privacy Model for Pervasive Service Systems supports the expression of the data available and of their manipulation. It is based on a formal representation, and implemented as two complementary data sets: the privacy related behavior of the services, and the user policies that describe the acceptable behavior of the services used.

Formal Foundation

Several formal models for describing privacy requirements and obligations have been developed. The most adequate ones [START_REF] Barth | Privacy and contextual integrity: Framework and applications[END_REF][START_REF] Hilty | On obligations[END_REF] are based on temporal logic and are very well suited to describe privacy requirements in general. An integration of two things is currently missing: (1) attributes and their association to individuals and (2) the context of the administrative domains the different service are operating in.

Attributes are at the center of privacy and hence its formal models because each data profile consists of a collection of attributes from a given individual. What becomes more important in service-oriented systems is distribution of the services and their providers. Current models focus on an e-business scenario where one provider interacts with the users and collects, stores and processes data. This bilateral relationship is no longer common to the upcoming architectures: services are provided by a plethora of providers and a plethora of services from one provider is consumed. So the underlying privacy model must be adapted to this new scenario. The different providers and their administrative domain must become part of the model. Privacy threats in general can only arise from the providers' view on the data, if we assume that it is too costly to merge databases that arise from different administrative domains or if we deploy protocols to ensure unlinkable transactions [START_REF] Wohlgemuth | Privacy with delegation of rights by identity management[END_REF].

The different entities of this privacy model is a finite set Id of users identified by a unique name. A set of local actions Act i details the way these users interact with the system. The information that is collected about a specific user is a set of attributes A. This set is allocated to the individuals in a given context. That means there exists a relation Id × A which associates these attributes to the individuals.

If we consider the consumers' point of view in this approach, we need a notion of administrative domains. Other models lack this point of view because they either take the service providers' point of view or a global one. Both of them are not very well suited to describe privacy requirements of individuals in a rather complex scenario. An administrative domain encompasses a collection of attributes that the individuals share with this domains' systems. If we consider two services that are provided by the same service provider, we realize that the attributes shared with each of the services can easily be linked and added to the profile by the provider. Although the architecture encompasses a single "master provider" that guarantees the quality of the meta-data presented to the user, this provider will certainly have subcontractors fulfill certain tasks. These subcontractors are to be modeled very closely in order to make statements on the users' privacy policies. There exists a finite set of administrative domains D. Each of these domains d ∈ D has a dataset κ d , which consists of the attributes the systems of this domain have collected over time. κ d is a subset of a × Id, the set of attributes of given users. There may also exist a membership relation between the individuals and the administrative domains: the set of members of an administrative domain M d is a subset of D × Id.

Each action Act i that is performed takes place in an administrative domain d. We denote this as @ d [Act i ]. This is important because individuals might change their membership within an administrative domain and hence can spread their knowledge.

The dataset of a given domain is not static. As the members of the different domains start interacting with each other, i.e. they share messages on different attributes of individuals, they spread these attributes throughout the different datasets. Furthermore it is possible for the providers of the datasets to derive new information from a given subset of attributes. For example, if we know the birthday of an individual, we might easily calculate its age. In real scenarios this is a lot more complex: we assume that attributes are rather complex and possibly contain unique identifiers. These complex attributes can be linked together and the evolution of these attributes over time reveals new information, i.e. additional attributes of the individuals. For deriving new attributes from the current dataset we define a set of production rules for each of the datasets. Where each of these rules intuitively consists of an "if part" and a "then part". The "if part" is P if is a subset of the attributes P i of an individual i: P if ⊆ P i . The "then part" is one of the individual's attributes a i . The set of the production rules is hence defined as R p ⊆ P if × a i .

Implementation of Meta-data and Policies

The formalization presented above brings us into a position where we can express the parts of a service-oriented system: (1) services are the actions (2) an individual user can perform. (3) data attributes and (4) administrative domains are explicitly modeled. Together with the production rules and formulae given in an adequate logical representation, we can express privacy requirements. Production rules are necessary because we must assume that the attacker will use data mining techniques to aggregate the information that is needed for a given exploit.

To efficiently establish the model, meta-data must be reduced to a smaller number of possible elements. It is not reasonable, though formally correct, to define each of the services as one action. This definition would not allow for a semantic interpretation of the model unless a detailed service description is provided with each of these services. Since the evaluation of the impact on the users' privacy cannot be inferred automatically (unless these descriptions are modeled once again and we get into a recursive situation here), we do not get one step ahead from the current situation (where we have written privacy policies and someone must read them and judge the impact on the users' privacy). To this end, it is necessary to define a subset of actions that are suited to harm the users' privacy. This is reading, writing, modification and sending of personal data. Each of the services contains in its meta-data the actions it performs with the personal data.

The same considerations hold for the data attributes. Data attributes are a lot more complicated because they are domain specific. We will certainly not be able to define a generic set of attributes that can be collected on people. To this end, it is necessary to define an application specific set of attributes. This is not a new issue as this definition has successfully been implemented in the area of identity management for several years [START_REF] Wohlgemuth | Privacy with delegation of rights by identity management[END_REF]. The predefined set of attributes then has a clear semantics to the end users (e.g their birthdays) and they can easily estimate the impact their disclosure might have.

Administrative domains are once again rather generic. There exists a set of domains (for example, named according to their providers). Each of these domains has a distinct level of trust. This trust is specific for each of the users and cannot (and need not) be part of the model. Trust depends on many factors, for example, if a contract between the user and the provider exists or a subcontract from the "main provider" only.

We can then provide the users with a realistic estimation of the data profiles saved with each of the different providers. This information must be visualized in an adequate manner because it can be rather complex. A summary can easily be prepared if we once again consider the partial identities we gathered from the identity management mechanisms we have at hand. As long as the data distribution corresponds to the partial identities provided by the user, there is no need to react. As soon as one of the providers is able to bring together different attributes from different interactions and establish a profile that is larger than the partial identities used by the client, there is possibly a need to react (or at least a need to review the situation).

For automating the analysis of privacy requirements, the question arises as to how this information can be securely integrated in current architectures. It is infeasible to manually collect all the information needed to perform the different privacy checks. Although this might be possible in static (or slowly evolving) systems, it is certainly a daunting and error-prone task. This is overly true if services are aggregated dynamically and used only once. To this end, it is necessary to provide this information as a part of the service description. Together with the syntactic description of the services (e.g. given in WSDL), we provide these meta-data in an adequate XML syntax. This allows for an automated evaluation of meta-data without manual interaction from the users.

Discussion: System Requirements

No full control can realistically be performed to verify that the advertised privacy behavior of the services is enforced. However, to provide no control at all is not really a deterrent for dishonest service providers. Technical measures are necessary to increase the degree of trust a user can put in the system and to make unfair data handling more difficult.

The following assertions are made: two technical implementations of services exist: code bundles and Remote (Web) Services. Firstly, no control is possible on remote services. Service Providers have to be trusted to behave as they claim to. External code audit and legal obligations are the main incentives for correct behavior. Secondly, the locally executed bundles can be checked and controlled, as far as suitable technologies are available and compatible with the resources of the users' terminals.

Requirements of the Remote Service Implementation

The reliability of remote service implementations is a very complex task to tackle. Although different approaches to express the requirements a service complies with exist (such as EPAL 1 or P3P 2 ), it is still an open question as to how this compliance can be enforced or at least be observed. To this end, we propose a transparency approach implemented with the formalization: the users are able to realize what profiles the different service providers might aggregate over time. This will help them understand where privacy issues might arise and which transactions they perform only with providers they really trust or which transactions do not pose large privacy issues.

It is obvious that meta-data provided with the services must be correct. The compliance of the meta-data with the actual data transfered can be observed by technically interested users. This means that ways to observe the correctness exist. Although they might not be accessible for everyone, due to a lack of technical knowledge, this can be seen as a trust building mechanism. On the one hand, users can trust that someone with a better technical background will find the flaws, on the other hand, caring users might ask a trusted third party to check the meta-data for compliance. So the requirements for remote service implementations are rather low, if we are to implement the observability of privacy issues only. If we also wish to take into account the enforcement part, this is still an open research question. For an overview of the issues that arise, see the excellent classification and discussion in [START_REF] Hilty | On obligations[END_REF].

Requirements of the User Platform

The requirements of the OSGi user platform are as follows. First, the platform must prevent actions that are not compatible with the defined policy. Secondly, services need to be isolated from each other. Thirdly, local sniffers should not be able to interact with trusted services, even when they are installed on the user platform.

Unauthorized action prevention can be performed through Java Permissions. For instance, network access or file system access can be forbidden to specific bundles. The limitation of Java Permissions is that they must be set at launch time of the virtual machine and cannot be dynamically modified. Since the OSGi platform support the addition and removal of code bundles without system restart, occasional reboot cannot be an option of updating the permission configuration. Permissions can be set according to the code location or according to the signer of the code. Since code location is dynamic in OSGi based systems, digital code signature should be used to bind bundles with suitable permissions. This means that permission profiles must be defined beforehand and that the Service Provider signs each bundle with the signature for this permission profile. A risk exist that a given bundle does not exactly match a defined profile and must thus be granted more permissions than it actually needs.

The second privacy requirement is that services cannot access each other without control. Controlling whether a given bundle can provide or look up services is a default behavior of the OSGi Platform [START_REF]Osgi service platform, core specification release 4[END_REF]. However, no mechanism currently exist to control the services a bundle (or the services it provides) can access. This clearly makes the enforcement of the policies defined in section 3.2 currently not possible. A radical solution is to provide strong namespace isolation between the services, as proposed in the Virtual OSGi approach [START_REF] Royon | Virtualization of service gateways in multi-provider environment[END_REF]. However, no fine-grained control is possible, since all interactions between services are prevented. Therefore, the approach is used to support multi-provider environments. For fine grained isolation, additional mechanisms are required. They are defined in section 4.3.

The last privacy requirement is the protection against local sniffers: Unidentified code should not be able to access services that are regularly installed. Such alien code should be rejected at install time through the security mechanisms (see section 2). If they are not, fine-grained service isolation mechanisms should prevent them from accessing other resources.

Isolation between Bundles

To support privacy policies, a fine-grained isolation mechanism must be defined. Two possible approaches exist. First, the OSGi platform is to be modified to control the service resolution and to check its compatibility with the defined policy. Secondly, it is possible to adapt the existing Service Binding mechanisms to provide this isolation without modifying the framework itself.

The mechanism that supports service publication and resolution in the OSGi framework is the Bundle Context. This context must therefore be modified so as to support isolation between the advertised services. The Bundle Context is accessed through an inversion of control mechanism, i.e. each bundle has a reference to the Context and uses this reference to perform service management operations. Consequently, when the Context performs a service lookup, it cannot easily identify the bundle (or the service) on behalf of which the lookup is performed. The Context itself needs to be modified: a bundle should be able only to look up services it is allowed to access. This can be achieved through a RestrictedContext, which is generated at the installation of the bundle and contains a list of the services that can be resolved at lookup. When the bundle is started through its Activator class, it gets a RestrictedContext, instead of a BundleContext instance. Inheritance is exploited to preserve transparency for the bundle code. The regis-terService, getServiceReference and getServiceReferences methods are overwritten to enforce the policy. Since a specific RestrictedContext instance exist for each bundle, policy runtime update is possible. For the same reason, all services provided by a given bundle must share the same privacy profile.

An alternative to BundleContext modification is the definition of a Secure Service Binding, which would be based on the OSGi service binder [START_REF] Cervantes | Automating service dependency management. in a service-oriented component model[END_REF]. A third party bundle is used to perform the linking between the client service and the 'servant', i.e. the service that is advertised. The privacy policy could easily be enforced in the Service Binder. Moreover, different implementations of the Service Binder could provide different types of access control policies: Role Based Access Control, Mandatory Access Control, Discretionary Access Control, and so on. However, there is an important limitation to this approach: the service binder is an optional layer to OSGi and making it mandatory would prevent all bundles that are not specifically developed for it to be used (at least without modification).

Conclusion and Perspectives

We have presented a security architecture, formalization and classification of meta-data for hybrid service systems. We could furthermore show that different requirements for remote services and downloadable bundles exist. To this end, it is necessary to find integrated approaches that can cope with the issues related to remote services as well as with those related to downloadable bundles.

These results form the basis for a closer investigation of the complex interplay of static security requirements and dynamic ones arising from the dynamic aggregation of code from different sources and the usage of remote services.

Figure 1 .

 1 Figure 1. Bundle Discovery and Provisioning

http://www.zurich.ibm.com/security/enterprise-privacy/epal/

http://www.w3.org/P3P/


Pierre Parrend
email: pierre.parrend@insa-lyon.fr

Stephane Frenot
email: stephane.frenot@insa-lyon.fr

Supporting the Secure Deployment of OSGi Bundles

The OSGi platform is a lightweight management layer over a Java virtual machine that makes runtime extensibility and multi-application support possible in mobile and constraint environments. This powerfull capability opens a particular attack vector against mobile platforms: the installation of malicious OSGi bundles. The first countermeasure is the digital signature of the bundles. We developed a tool suite that supports the signature, the publication and the validation of the bundles in an OSGi framework. Our tools support the publication of bundles onto a remote bundle repository as well as the validation of the signature according to the OSGi R4 specifications. A comparison of existing validation mechanisms shows that our security layer is the only one that is compliant with the specification.

Introduction

The OSGi platform is on the way of becoming the de facto standard componentization middleware for supporting extensible software, through the management layer it provides to control the life-cycle of the so-called 'bundles', i.e. the OSGi components. However, the security characteristics of this life-cycle are hardly identified, in particular during the deployment of the bundles which is usually realized over insecure networks. We present here the tools we developed to support the secure deployment of bundles. The first tool, SF-Jarsigner 1 , covers the early life-cycle phases of the deployment, namely the signature of the bundles by their issuer and their publication. The second tool, SFelix 2 , is actually an implementation of the digital signature validation layer of OSGi Release 4 specifications, and is based on the Felix 3 OSGi implementation. Both are compliant with OSGi Release 4 [START_REF]Osgi service platform, core specification release 4[END_REF]. The publication process is not defined by these specifications, but relies on the Open Bundle Repository (OBR) format [START_REF] Alliance | OSGi Alliance RFC 112[END_REF], which is supported by several Open Source OSGi implementations: the OBR1 format is supported by Oscar and Knopflerfish, and the OBR2 format is supported by Felix.

The OSGi platform is a lightweight overlay to the Java virtual machine, which supports the runtime installation of Java components, the management of their life-cycle, as well as the proper expression of the dependencies between them. This facility typically allows a user to discover software packages that are available on the Internet or in its near environment, to install them together with their dependencies, and to un-install them when they are no longer required. The runtime extensibility which is thus provided opens a new attack vector, which to the best of our knowledge has been overlooked in the literature: the possibility of seamlessly executing malicious code from the environment. Figure 1 shows the attack tree for executing malicious code on a client system [START_REF] Parrend | A security analysis for home gateway architectures[END_REF]. Two main strategies exists: to install a malicious platform, and to install malicious bundles. The first strategy is prevented by the control of the integrity of the framework when it is installed. The second strategy can be realized through three different approaches: inserting malicious code during the development, inserting malicious bundles onto the bundle repositories, or installing bundles from unauthorized repositories. The bundle issuer is responsible for guaranteeing that the code he provides is sound, which can be achieved through code analysis. The insertion of malicious bundles in the repositories or the installation from unvalid repositories can be prevented by the digital signature of bundles. This paper presents the tools we developed to perform this digital signature. Further information is provided in the related technical report [START_REF] Parrend | Secure component deployment in the osgi(tm) release 4 platform[END_REF].

The main current use cases of the OSGi platform is the deployment of Open Source software. In such environments, security problems are often neglected due to the open structure of the projects. However, the broadening of the applications of the OSGi framework and the ben-

Figure 1. The Attack Tree for malicious Code Execution

efits it may provide to adaptable and extensible businesscritical systems are highly likely to require a firm understanding of its security implications, and the availability of effective tools. The security infrastructure, which relies in a great part on the digital signature of bundles, is common to all application domains, such as mobile commerce, wireless remote control, health-care monitoring, and videosurveillance. This infrastructure must be completed with context-and application-specific security policies, which are out of the scope of this paper.

The following of the paper is organized as follows. Section 2 presents the related works. Section 3 gives the detail relative to our tool suite. Section 4 provides a comparison of the various available tools and frameworks dedicated to signing and validating the digital signature of bundles. Lastly, we conclude this work and give further perspectives.

Related Works

So as to define a secure process for deploying OSGi bundles, it is necessary both to control the overall deployment process, as well as the security mechanisms that can be used to protect it. We therefore present other research works related to the deployment process, and to the security aspects of deployment.

Deployment of Components

The various steps of the life-cycle of software components and of OSGi bundles in particular are the following [START_REF] Carzaniga | Characterization framework for software deployment technologies[END_REF]: the publication of the components, the discovery of the components, the resolution of dependencies between the components, the download, and the configuration at the initialization step.

The publication step requires that both the components and the information necessary for the client to execute them properly are made available: the component meta-data, dependencies between components, the source location and the scope of the component release are published in 'release databases' [START_REF] Van Der Hoek | Software release management for component-based software[END_REF]. The binding between the publishers and the clients is done either through the publication of static metadata [START_REF] Alliance | OSGi Alliance RFC 112[END_REF], or through a publish/subscribe mechanism [START_REF] Wang | Security issues and requirements for internet-scale publish-subscribe systems[END_REF]. In both cases, a third party broker is required. The discovery phase is made of the identification of the available bundles by the clients, and the resolution of the dependencies. The Eureka framework is an example of such a discovery mechanism over the OSGi platform [START_REF] Pauls | Eureka -a resource discovery service for component deployment[END_REF]. Specific languages are defined to support this process of dependency resolution [START_REF] Heimbigner | A framework for analyzing configurations of deployable software systems[END_REF]. The download phase is typically done from a centralized repository [START_REF] Alliance | OSGi Alliance RFC 112[END_REF]. However, the distribution of the resources over peer-to-peer overlay networks can be used with benefit, so as to increase the robustness of the infrastructure, the availability of the components [START_REF] Frenot | Component deployment using a peer-to-peer overlay[END_REF].The last phase of the deployment is the configuration of the components on the client. It builds the finalization phase of the deployment of complex distributed systems, and is often overlooked when deploying single applications [START_REF] Hall | An architecture for post-development configuration management in a wide-area network[END_REF].

The tools we propose are based on the Bundle Repository Metadata to support the extraction of metadata during the publication, and their resolution by the clients. The download is handled by the 'bundle repository' bundle at the client's, which is part of the Felix framework. We integrate these existing facilities together with a publication management tool we developed. This latter deals with the update of the meta-data of the bundle repository and the upload of the bundles. To the best of our knowledge, such a tool is available neither in the frame of the Felix project, nor in the Equinox platform.

Secure Deployment

The cardinal security properties are the integrity of the data, the authentication of their emitter, the confidentiality of the communications and the non-repudiation of the actions. Diverse approaches have been defined so as to enforce these properties on the context of component deployment.

The current specification for securing the deployment of bundles is based on the Java Archive specification [START_REF]Jar file specification[END_REF], and defined with precision in the OSGi Release 4 specifications [START_REF]Osgi service platform, core specification release 4[END_REF]. It consists in the integration of the integrity control for each resource through a hash value and a digital signature in the bundle itself. The algorithms used are SHA-1 for hashing and DSA for the signature. The necessary meta-data is encapsulated in a file compliant with the 'Cryptographic Message Syntax' [START_REF] Housley | Cryptographic message syntax (cms)[END_REF]. This approach provides the authentication of the bundle issuer and the guarantee of the integrity of the code.

An alternative to signature based on asymmetric cryptography is the use of Message Authentication Code (MAC) based on symmetric key [START_REF] Kim | A macbased service bundle authentication mechanism in the osgi service platform[END_REF]. This provides a more lightweight cryptographic mechanism, but is often considered as being less secure than asymmetric cryptography, be-cause the secret key is shared among several entities. Moreover, no performance indication is given, which means that no factual comparison can be done with current specifications. The MAC signature process can take benefit of the XML signature encapsulation for easier management [START_REF] Kim | A macbased service bundle authentication mechanism in the osgi service platform[END_REF].

A more robust mechanism for guaranteeing the deployment of component is the S-CODEP (SECure COmponent DEPloyment) protocol [START_REF] Grechanik | Secure deployment of components[END_REF]. It is based on Kerberos, and provides an anti-replay mechanism. It assumes that the underlying platform can not be compromised. The use of Kerberos make this approach a heavyweight one. It is adapted for sensitive systems such as enterprise information systems or telecommunication environments.

Several security infrastructures for specific component platforms have been defined. For instance, the Cingal model is a component model very similar to the OSGi one, and provides digital signature using the same principle of digital signature of the bundles [START_REF] Dearle | A flexible and secure deployment framework for distributed applications[END_REF]. A similar mechanism has been defined to support the deployment of Web Services [START_REF] Gaedke | Supporting secure deployment of portal components[END_REF]. The .Net framework also proposes a similar mechanism to sign assemblies. Its main limitation is that the installed assemblies can not be removed, contrary to OSGi bundles, which makes it unproper for mobile and resource-constraint platforms.

These research works related to the problem of securely deploying OSGi bundles and other software components suffer from one obvious drawback. There is currently to the best of our knowledge no tools that supports the deployment process as it is specified by the OSGi Alliance. This matter of fact makes any comparison impossible -and greatly limits the use of the OSGi platform in environments where security is required. We therefore developed those tools, and present them in the subsequent sections.

The SFelix Tools suite

So as to support the process of secure deployment of OSGi bundles, we developed two complementary tools. The first is the SF-Jarsigner that performs the signature and the publication of the bundles by their issuer. The second is SFelix, which is an extension of the Felix implementation of OSGi. Our main contribution in SFelix is the implementation of the OSGi R4 security layer, which is the sole project we know that supports bundle signature according to the OSGi Specifications [START_REF]Osgi service platform, core specification release 4[END_REF]. For more precision, please refer to our technical report [START_REF] Parrend | Secure component deployment in the osgi(tm) release 4 platform[END_REF].

Secure Deployment

The process of secure deployment is shown in figure 2. The deployment of OSGi bundles is compound of issuance phase, and a client-side phase.

Figure 2. Secure Deployment of OSGi Bundles

The issuance phase is performed by the bundle issuer. The first step is to sign the bundles, or to check that the existing signature is valid. The second step is the extraction of the meta-data of the signed bundles, and the publication onto a third party repository. The format of the meta-data is defined by the OBR2 Request for Comments of the OSGi Alliance [START_REF] Alliance | OSGi Alliance RFC 112[END_REF].

The client-side phase of the deployment is made of the discovery of the bundles, the dependency resolution, the download of the code archives, the validation of the digital signature, and the start of the bundles. The discovery, the dependency resolution and the download steps are dealt with by the bundle-repository facility, which is available in the Felix distribution. The validation step is performed when the bundle is stored locally, to avoid a TOC-TOU (time-of-check, time-of-use) substitution, and before it is installed, so that not authenticated bundles can not be executed. It must be compliant with OSGi R4 specifications, but also compatible with the behavior of the virtual machine. The Sun tools are considered as the reference. When the bundle signature is valid, and the signer is identified by the platform as being a trusted one, the bundle can be started.

SF-Jarsigner: a Tool for secure Publication of Bundles

The SF-Jarsigner tool aims at providing a convenient graphical user interface for signing and publishing OSGi bundles. Since the signature generation mechanism is compatible with the Sun Jarsigner tool, other types of Jar files or data archives can also be signed.

The SF-Jarsigner tool is compound of four graphical panels. The first panel let the archive publisher select a 'keystore' file, where its private/public key pair (respectively a public key) is stored for signing (respectively checking) bundles. The second panel is the one shown on figure 3, it supports the signature or verification of bundles that are stored on the local system. The valid bundles are shown on the list on the right, and made available for publication. The third panel allows to set and store the informations relative to the remote file server where the bundles are to be published. Currently, only the FTP protocol is supported. The last panel lets the publisher choose among the available signed bundles which one are to be published. The operation can be repeated on several Bundle Repositories.

Figure 3. The Interface of the SF-Jarsigner Tool

The SF-Jarsigner tool is provided as OSGi bundles. It can be executed over the Felix, SFelix and Equinox platforms. With a minor configuration effort, it can also be executed over Knopflerfish. It uses several third party open source libraries: the Bouncycastle cryptographic libraries bcprov and bcmail, the XML libraries xml-commonsresolver and Xerxes from Apache, the FTP library Edtftp, and the OBR2 metadata extractor Bindex. The validation functionalities are provided by the 'jarvalidation' bundle, and the graphical interface by the 'Jar Signer Gui' bundle. Its total size is 3,657 kbytes. SF-Jarsigner is available through the SFelix Bundle Repository4 .

SFelix: a hardened OSGi platform

The SFelix platform is an extension of the Felix OSGi implementation, which performs a bundle signature check before the bundles are installed. If the signature of a given bundle is unvalid, the bundle is rejected and the installation is aborted.

The SFelix security layer is provided as a Java library, and therefore not seen as actual bundles in the framework. The verification is performed as a single call to the 'jarvalidation' library we provide, and which is the same that the bundle used in the SF-Jarsigner tool. The required libraries are the Bouncycastle libraries bcprov and bcmail. The total size of the Security Layer is 1.932 kbytes, because of the numerous cryptographic primitives that are embedded

W A R R Archive Unknown A A R R Signer Addition of A A A R Resource Removal of A A A R Resource Modification R R W R of Resource Unvalid Order A A A R of Resources Signature of R R W R Embedded Archive Unvalid Time Of Check Test Exec Exec Install A: Accept; R: Reject; W: Warning;
The criteria of validation of the signature of a bundle are shown in the table 4.2. All potential errors are listed according to the OSGi R4 specification [START_REF]Osgi service platform, core specification release 4[END_REF], and the behavior of the tested tools and platforms in the presence of such an error is given. The considered tools and platforms are the following: the Sun Jarsigner, the Sun Java virtual machine with a Security Manager, the Felix platform with security enabled, and the SFelix platform. All data are directly drawn from experience, but the Felix behavior. Since no minimal permission policy is made available, and can not be easily deduced from the behavior of the platform, it can be assumed that 1) the certificate control, which is done explicitly in the platform, is performed correctly, and 2) that the integrity control, which is done by the virtual machine, is done in the same way than the 'Java with Security Manager' case. The behavior of the SF-Jarsigner tool, which can also be used to check signatures, is the same as the one of SFelix, since it relies on the same 'JarValidation' library. The other open source implementations of OSGi are not considered here. Knopflerfish5 does not provide support for bundle signature. Neither does Equinox 6 . The integrity control during the deployment of Eclipse plugins, which is based on the Equinox framework, is performed during the Eclipse plugin deployment through a specific mechanism.

The results of the experiments are the following. The Sun Jarsigner tool identifies files that are not signed, that have been tampered with, or for which the public key certificate is outdated. It does not take into account the fact that the signer is trusted or not, though it has access to the 'keystore' which contains such information. The Java virtual machine has the same behavior than the Jarsigner, but does not take the warnings into accounts. Consequently, no difference is done between a signed and an unsigned archive if the valid signer are not explicitly indicated in the permission policy before the virtual machine is launched. Therefore, no modification of the list of trusted signers can be done at runtime, which can be restrictive. The Felix framework is expected to reject the unsigned archives and the archives with unvalid signers. It issues warnings when archives that have been tampered with are installed, but seems to install them anyhow. SFelix has been developed specifically to be conform to OSGi R4, so it has a proper behavior in all tested error cases. Its current limitation is that it does not handle certificates chains, used when a valid signer delegates its right to another entity.

The time of integrity control is different in each tool. The Sun Jarsigner tool, as a command line utility, prints the test results immediately. The Java virtual machine checks the integrity of the files when they are loaded to be executed, and so does the Felix platform. This is not consistent with the requirements that the whole archive is sound which is expressed by the OSGi specifications. This explains why Felix is not R4 compliant, at least what concerns the control of the integrity of the bundles. The SFelix platform performs the archive signature check at install time. This implies a slight performance overhead, but is necessary to guarantee that only valid archives are installed. This approach prevents the sudden unavailability of services that are installed, but for which some unfrequently executed classes are tampered with.

Conclusions and Perspectives

We present in this paper the tool suite we developed to support the secure deployment of OSGi bundles. Our contribution is twofold. First, we integrate the available publication mechanisms defined by the Bundle Repository format in a convenient tool that makes possible to publish a set of bundles so that they are made available to the client platforms. Secondly, we provide a library that support the generation and the validation of signature according to the OSGi R4 specifications. The signature generation functionality is integrated in the publication tool SF-Jarsigner. The signature validation functionality is integrated as an extension of the Felix OSGi implementation, name SFelix (for Secure Felix). No other tool for bundle publication is currently available, to the best of our knowledge. Moreover, all other existing validation mechanisms for OSGi bundle signature do not follow the OSGi specifications. To provide firm arguments of the benefit of our tools, we performed a comparison between the various archive signature validation mechanisms.

The limitations of our tools are the following. Related to the publication phase, only the OBR2 protocol is supported. However, Knopflerfish, and Oscar (the predecessor of Felix) still use the OBR1 format, which is not compatible with it. The extension of the current facility would make our tool useful in systems that use those platforms, in particular Knopflerfish. Related to the signature process, the main current limitation is that the possibility of signature delegation through signature path is not supported at the verifier's, which must have a reference to each actual signers. Moreover, the signature generation must be done to maintain the compatibility with the Java virtual machine and Sun tools. Therefore additional meta-data are inserted in the hash files of the signed bundles that would not be necessary.

This work provides the community with convenient tools for securely publishing OSGi bundles, or other software components. It also provides an implementation of the OSGi security layer which is necessary for comparing the current specifications and a modified security architecture. The next requirement is the development of an infrastructure to manage the identity of the bundle issuers. The current proposed solution is based on Public Key Infrastructure, which proves to be difficult to put into use. We therefore plan to study the possibility of using an alternative signature scheme. The Identity-based signature mechanism, for instance, could be a valuable alternative to provide a comparable level of security, while greatly simplifying the key management process.

Table 1 . Behavior of several tools and frame- works in the presence of unvalid archives Error Sun Java with Felix SFelix Type Jarsigner Security Manager Unsigned

 1

http://www.sfelix.free.fr/repository/repository-ppd.xml in the Bouncycastle library. In an environment with restricted resources, it would be necessary to extract the required classes from these library, so as not to overwhelm the available memory with unused code.

http://www.knopflerfish.org/

http://www.eclipse.org/equinox/

 [START_REF] Carzaniga | Characterization framework for software deployment technologies[END_REF]This work is partially founded by MUSE IST FP6 Project #026442. 1 http://sf-jarsigner.gforge.inria.fr 2 http://sfelix.gforge.inria.fr/ 3 http://incubator.apache.org/felix/

Comparison with other Archive Validation Processes

So as to confirm the usefulness of the tools we propose, we compare them to the solutions that are currently available. Two aspects need to be considered: the signature step, and the validation step.

Signing Archives

Two tools are available for signing Jar files or bundles. The first is the Sun Jarsigner, with is part of the Java SDK. The second is the SF-Jarsigner tool we provide. The Sun Jarsigner is available as a command line utility. The SF-Jarsigner is provided as a set of OSGi bundles, which support both a convenient use through a graphical user interface, or a programmatic use through services published inside the OSGi framework.

The specifications of digital signature according to the Jar file specifications [START_REF]Jar file specification[END_REF] are relatively vague. They are therefore completed in the OSGi R4 specifications [START_REF]Osgi service platform, core specification release 4[END_REF]. However, if the validity criteria for archive signature are more strict in the frame of OSGi systems (see section 4.2), the default signature process by the Sun Jarsigner generates OSGi compatible archives.

The main difference between the Sun JVM and the OSGi specifications is that, in the case of the Sun signature, all entries of the manifest file must be hashed and stored in the so-called 'Signature File' (see [START_REF] Parrend | Secure component deployment in the osgi(tm) release 4 platform[END_REF] for the detailed structure of a signed bundle). This is not required by the OSGi specifications, which consider that no new resource can be added to a signed archive. However, to provide compatibility with Sun tools, the SF-Jarsigner adds these additional meta-data.

Consequently, it is possible to use any of those tools for performing the digital signature of OSGi bundles -or of other Java archives. The benefit of SF-Jarsigner lies 1) in the convenient user interface and 2) in the support for bundle publication.

Signature Validation

Whereas the actual behavior of the considered signing tools is identical, the criteria for verifying the validity of signed archive greatly varies between the various available checkers and platforms. This has the direct consequence that an OSGi bundle that has been modified will not be considered as unvalid in all tools but ours.


Thomas Régnier

Valérie Bolliet

Jacques Labonne

Philippe Gaudin

Energetic status, development and early behaviour of brown trout fry (Salmo trutta) : study of maternal effects

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

ENERGETIC STATUS, DEVELOPMENT AND EARLY BEHAVIOUR OF BROWN TROUT FRY (SALMO TRUTTA) : STUDY OF MATERNAL EFFECTS

Régnier T .(1) , Bolliet V. (1) , Labonne J. (1) & Gaudin P. (1) (1) INRA, UMR ECOBIOP, Pôle d"hydrobiologie -Quartier Ibarron 64310 St-PEE-SUR-NIVELLE (FRANCE), tregnier@st-pee.inra.fr, bolliet@st-pee.inra.fr, labonne@st-pee.inra.fr, ,gaudin@st-pee.inra.fr Key words: Metabolic rate, energetic status, Salmo trutta, emergence from gravel.

Abstract:

Energetic stores condition a number of traits linked to growth or reproduction, such as maternal investment, migration decision at the individual level. However, these stores are also linked to their rate of depletion i.e. metabolism which represents the costs of different function, as maintenance for a resting individual, synthetic processes for growth, feeding and activity. A growing body of literature, dealing with behavioural traits variability, tends to link them to physiological processes, including metabolism. For instance, metabolic rate has been linked to several personality traits such as aggressiveness and dominance in different species. So both energetic stores and metabolism, representing the Energetic status of an individual, appear of relevant interest for the understanding of life history-strategies. Yet emergence from gravel is thought to be one of the most critical phases for young salmonids due to high predation and starvation pressure combined with the acquisition of swimming behaviours and the acquisition of a feeding territory. Emergents have also to choose to reside on the emerging site or to disperse downstream. Until yolk depletion, the energetic status of an individual is only conditioned by maternal provisioning and the yolk absorption rate. Metabolic rate may be the missing link between energetic status and behavioural strategies at the onset of emergence.

To our knowledge, neither inter-individual variability of metabolic rate throughout embryonic and larval development nor the role of different metabolic rates on early behaviour has been investigated. The aim of this study is to compare the ontogeny of metabolic rate of different Salmo trutta families by means of flow through micro-respirometry. Routine metabolic rate (RMR) was monitored from fertilization to yolk sac resorption. Intra-family and also inter-family variations in RMR were investigated by means of Bayesian modelling in order to look for any maternal effect on metabolic rate ontogeny across embryonic development.

The in fine purpose is to gather clues for the understanding of emergence patterns heading towards further researches.