Message-ID: <5478939E.5080806@ac-versailles.fr>
Date: Fri, 28 Nov 2014 16:24:14 +0100
From: Pascal Fautrero <pascal.fautrero@ac-versailles.fr>
Organization: DANE Versailles
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.2.0
MIME-Version: 1.0
To: educ@april.org
References: <2083239142.240477165.1417120886418.JavaMail.root@zimbra18-e3.priv.proxad.net> <5478620F.2090208@ac-reims.fr> <2295945.JAv6gMOAvJ@boulle-sh61r> <54787B03.4050802@ac-versailles.fr> <54788226.1050404@pi-et-ro.net>
In-Reply-To: <54788226.1050404@pi-et-ro.net>
Subject: Re: [EDUC] SaaD (was : Nouvelle version de Framadate)
Reply-To: Pascal Fautrero <pascal.fautrero@ac-versailles.fr>
Errors-to: educ-owner@april.org
Precedence: list
Precedence: bulk
Sender: educ-request@april.org
Content-type: multipart/mixed; boundary="----------=_1417188257-7498-63"

This is a multi-part message in MIME format...

------------=_1417188257-7498-63
Content-Type: multipart/alternative;
 boundary="------------030307050502000007080509"

This is a multi-part message in MIME format.
--------------030307050502000007080509
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit


On 28/11/2014 15:09, Louis-Maurice De Sousa wrote:
> Le 28/11/2014 14:39, Pascal Fautrero a écrit :
>> Bonjour,
>>
>> Je me greffe sur ce fil même si le SaaS est traité en parallèle sur au
>> moins deux autres fils de discussion.
>>
>> Voici un petite réflexion personnelle (orientée technique) sur le SaaS
>> issue de ce texte (merci à Charlie Nestel pour la référence) :
>>
>> https://www.gnu.org/philosophy/who-does-that-server-really-serve.html
>>
>> Le SaaSS
>> ---
>>
>> Stallman crée un nouveau terme "SaaSS" pour pointer du doigt le vrai
>> problème de cette technologie : transmettre ses données personnelles à
>> un serveur tiers pour réaliser un traitement spécifique (qui aurait pu
>> être fait localement)
>> S'il n'y a pas de traitement de données (j'entends par là, s'il n'y a
>> pas de modification de la donnée), ce n'est pas du SaaSS. Tous les
>> systèmes de publication centralisés ne sont donc pas considérés comme du
>> SaaSS.
>>
>> Framapad n'est par exemple pas du SaaSS. C'est un outil collaboratif de
>> publication. Le texte saisi n'est pas traité par un service (situé sur
>> le serveur de framasoft)
>> Framadate peut ne pas en être non plus. Il faut savoir si les données
>> sont traitées côté serveur.
> Si tu remplaces Framasoft par Google® ça devient du SaaSS. De la même 
> façon qu'un blog sur la plateforme académique, ce n'est pas pareil que 
> chez Blogger®.

ce n'est pas ce que je lis :

"[...]Même aujourd'hui c'est ce que font la majorité des sites web, et
cela ne pose pas le problème du SaaSS, parce qu'accéder aux informations
publiées par quelqu'un n'a rien à voir avec votre propre informatique.
Publier votre propre contenu par l'intermédiaire d'un blog ou d'un
service de microblogging comme Twitter ou StatusNet, non plus".


>
>> Les tendances du web (anti-SaaS ?)
>> ---
>>
>> Vous le savez, html5 est devenu une recommandation du W3C (depuis
>> octobre de cette année).
>> Cette technologie vise à faciliter ce qui est communément appelé les
>> "webapps". C'était une idée lancée par Opera en 2004 mais refusée à
>> cette époque par le W3C :
>> http://www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html
>> Ceci aboutit alors à la création du WhatWG et cette fameuse présentation
>> proposée par le jeune Ian Hickson en 2005 :
>> http://www.hixie.ch/advocacy/whatwg-presentation/#0
>>
>> Il se trouve que cette idée amène à changer de posture sur le
>> développement d'applications web. Le traditionnel serveur apache/tomcat
>> + traitement en php/java avec un côté client juste prévu pour
>> l'affichage est tombé au profit d'une application cliente plus lourde,
>> capable de faire les traitements auparavant réservés côté serveur.
>> Le javascript est un langage puissant qui, depuis la naissance de html5,
>> s'est vu équipé d'une API non moins puissante.
>>
>> Ceci a donc engendré un très gros mouvement dans le monde des
>> développeurs pour s'orienter vers des développements "frontend" (et ce
>> que certains appellent les SPA). Le serveur n'est alors quasiment plus
>> sollicité si ce n'est pour stocker les résultats obtenus localement.
>> Ceci allège les charges serveurs, c'est une forme de délocalisation. En
>> fait, on revient à la case départ avec un client lourd qui fait le travail.
>>
> On retombe ici sur les problématiques classiques du logiciel privateur. 
> La transmission sur le poste client d'un code JavaScript dont 
> l'utilisateur n'a pas le contrôle pose problème.
> https://www.gnu.org/philosophy/javascript-trap.html
que tu obtiennes l'application javascript par un navigateur ou une
application compilée depuis un site est fondamentalement la même chose.
A moins de prôner l'utilisation exclusive des dépôts.

Est-ce que télécharger une application compilée sous licence libre sur
un site est considéré comme une démarche incompatible avec la
philosophie du libre ?

Quoiqu'il en soit, si l'utilisateur ne souhaite pas télécharger
l'application web, il peut très bien demander à utiliser un client lourd
qui utilisera les webservices de la plateforme en question.


>
>> Des idées de position vis à vis du SaaS
>> ---
>>
>> HTML5 nous incite a réaliser les traitements en local. Ceci inverse la
>> tendance SaaS. Il est donc assez aisé de pousser dans ce sens.
>> Aisé parce que les arguments à avancer peuvent être de plusieurs natures :
>>
>>   - éthique (le SaaS n'est pas compatible avec le libre)
>>   - technique (économie des serveurs, limitation des problèmes de bande
>> passante, de connexion...)
> Si l'utilisateur sait clairement ce que le navigateur va exécuter, ce 
> n'est pas un problème. S'il n'a aucun contrôle là-dessus, ça en devient 
> un. L'acceptation par tous les navigateurs des DRM est de ce point de 
> vue peu rassurante.
Les DRM ne sont pas des backdoors. Sans compter que le draft "encrypted
media extension" n'a pas été validé par le W3C :
http://www.w3.org/TR/encrypted-media/
C'est même finalement l'effet inverse. Si tu n'as pas payé le droit de
consulter une ressource, tu n'y accéderas pas. Charge à l'utilisateur de
refuser d'utiliser ce système de verrouillage.
Il est encore possible qu'il ne soit jamais standardisé. NetFlix, Google
et Microsoft poussent pour que ça le devienne mais ils n'ont pas encore
gagné.

>> Quid des données envoyées sur le serveur ?
>> ---
>> Certains l'ont déjà précisé dans d'autres fils de discussion sur cette
>> liste. Tout d'abord, ce n'est pas la problématique du "SaaSS". SaaS
>> équivaut à "traitement des données personnelles par un service".
>> Mais je crois qu'il faut prendre position sur le problème des données
>> stockées "ailleurs". Le SaaS n'est qu'une brique du cloud computing. Le
>> stockage des données en est une autre tout aussi importante.
>> Actuellement, la solution pour régler ce problème me semble à la portée
>> de tous.
>> Ce qui pose problème dans ce cas de stockage distant, c'est la "valeur"
>> intrinsèque de la donnée envoyée. Une donnée sans valeur peut très bien
>> être stockée sur un serveur quelconque. Le fournisseur de service ne
>> pourra rien en faire.
>> Pour qu'une donnée perde sa valeur, il suffit de la chiffrer. Et pour
>> partager ces données avec d'autres utilisateurs, il suffit que
>> l'application échange des clés de chiffrement/déchiffrement entre ces
>> utilisateurs.
>> Encore une fois, HTML5 le permet. De cette manière, des données "sans
>> valeur" sont stockées quelque part, partageables entre utilisateurs et
>> inexploitables par les fournisseurs de service.
> Tu ne peux pas dévaloriser une donnée. La seule dévalorisation possible 
> est que personne n'y accède. Si on y accède, même de façon chiffrée, 
> elle aura une valeur.

laquelle ? Je fais des paiements en ligne sans aucune inquiétude. C'est
un leurre de croire que tes données sont plus sécurisées si elles sont
physiquement chez toi. Le verrouillage numérique est aussi sûr (ou aussi
peu sûr) que le coffre fort dans ton salon.

>
> Le problème tient à la construction de l'économie de l'informatique. Le 
> modèle de Microsoft® est illégitime. On ne vend pas des choses dont la 
> reproduction ne coûte rien, comme si c'est c'était des objets matériels.
> Le modèle de Google® est illégitime et injuste. On n'offre pas un 
> service gratuit en transformant ses utilisateurs en produits.
>
> Ces systèmes économiques ne profitent à personne sinon aux entreprises 
> qui les portent et sont inutiles.
>
>
>
> --
> Pour vous désinscrire de cette liste : https://listes.april.org/wws/sigrequest/educ
>
> Pour gérer votre abonnement à la liste educ et vos informations personnelles :
> http://listes.april.org/wws/info/educ
>
>

--------------030307050502000007080509
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 28/11/2014 15:09, Louis-Maurice De
      Sousa wrote:<br>
    </div>
    <blockquote cite="mid:54788226.1050404@pi-et-ro.net" type="cite">
      <pre wrap="">Le 28/11/2014 14:39, Pascal Fautrero a écrit :
</pre>
      <blockquote type="cite">
        <pre wrap="">Bonjour,

Je me greffe sur ce fil même si le SaaS est traité en parallèle sur au
moins deux autres fils de discussion.

Voici un petite réflexion personnelle (orientée technique) sur le SaaS
issue de ce texte (merci à Charlie Nestel pour la référence) :

<a class="moz-txt-link-freetext" href="https://www.gnu.org/philosophy/who-does-that-server-really-serve.html">https://www.gnu.org/philosophy/who-does-that-server-really-serve.html</a>

Le SaaSS
---

Stallman crée un nouveau terme "SaaSS" pour pointer du doigt le vrai
problème de cette technologie : transmettre ses données personnelles à
un serveur tiers pour réaliser un traitement spécifique (qui aurait pu
être fait localement)
S'il n'y a pas de traitement de données (j'entends par là, s'il n'y a
pas de modification de la donnée), ce n'est pas du SaaSS. Tous les
systèmes de publication centralisés ne sont donc pas considérés comme du
SaaSS.

Framapad n'est par exemple pas du SaaSS. C'est un outil collaboratif de
publication. Le texte saisi n'est pas traité par un service (situé sur
le serveur de framasoft)
Framadate peut ne pas en être non plus. Il faut savoir si les données
sont traitées côté serveur.
</pre>
      </blockquote>
      <pre wrap="">
Si tu remplaces Framasoft par Google® ça devient du SaaSS. De la même 
façon qu'un blog sur la plateforme académique, ce n'est pas pareil que 
chez Blogger®.</pre>
    </blockquote>
    <br>
    ce n'est pas ce que je lis :<br>
    <br>
    "[...]Même aujourd'hui c'est ce que font la majorité des sites web,
    et
    cela ne pose pas le problème du SaaSS, parce qu'accéder aux
    informations
    publiées par quelqu'un n'a rien à voir avec votre propre
    informatique. Publier votre propre contenu par l'intermédiaire d'un
    blog ou
    d'un service de microblogging comme Twitter ou StatusNet, non plus".<br>
    <br>
    <br>
    <blockquote cite="mid:54788226.1050404@pi-et-ro.net" type="cite">
      <pre wrap="">

</pre>
      <blockquote type="cite">
        <pre wrap="">Les tendances du web (anti-SaaS ?)
---

Vous le savez, html5 est devenu une recommandation du W3C (depuis
octobre de cette année).
Cette technologie vise à faciliter ce qui est communément appelé les
"webapps". C'était une idée lancée par Opera en 2004 mais refusée à
cette époque par le W3C :
<a class="moz-txt-link-freetext" href="http://www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html">http://www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html</a>
Ceci aboutit alors à la création du WhatWG et cette fameuse présentation
proposée par le jeune Ian Hickson en 2005 :
<a class="moz-txt-link-freetext" href="http://www.hixie.ch/advocacy/whatwg-presentation/#0">http://www.hixie.ch/advocacy/whatwg-presentation/#0</a>

Il se trouve que cette idée amène à changer de posture sur le
développement d'applications web. Le traditionnel serveur apache/tomcat
+ traitement en php/java avec un côté client juste prévu pour
l'affichage est tombé au profit d'une application cliente plus lourde,
capable de faire les traitements auparavant réservés côté serveur.
Le javascript est un langage puissant qui, depuis la naissance de html5,
s'est vu équipé d'une API non moins puissante.

Ceci a donc engendré un très gros mouvement dans le monde des
développeurs pour s'orienter vers des développements "frontend" (et ce
que certains appellent les SPA). Le serveur n'est alors quasiment plus
sollicité si ce n'est pour stocker les résultats obtenus localement.
Ceci allège les charges serveurs, c'est une forme de délocalisation. En
fait, on revient à la case départ avec un client lourd qui fait le travail.

</pre>
      </blockquote>
      <pre wrap="">
On retombe ici sur les problématiques classiques du logiciel privateur. 
La transmission sur le poste client d'un code JavaScript dont 
l'utilisateur n'a pas le contrôle pose problème.
<a class="moz-txt-link-freetext" href="https://www.gnu.org/philosophy/javascript-trap.html">https://www.gnu.org/philosophy/javascript-trap.html</a></pre>
    </blockquote>
    que tu obtiennes l'application javascript par un navigateur ou une
    application compilée depuis un site est fondamentalement la même
    chose. A moins de prôner l'utilisation exclusive des dépôts.<br>
    <br>
    Est-ce que télécharger une application compilée sous licence libre
    sur un site est considéré comme une démarche incompatible avec la
    philosophie du libre ?<br>
    <br>
    Quoiqu'il en soit, si l'utilisateur ne souhaite pas télécharger
    l'application web, il peut très bien demander à utiliser un client
    lourd qui utilisera les webservices de la plateforme en question.<br>
    <br>
    <br>
    <blockquote cite="mid:54788226.1050404@pi-et-ro.net" type="cite">
      <pre wrap="">

</pre>
      <blockquote type="cite">
        <pre wrap="">Des idées de position vis à vis du SaaS
---

HTML5 nous incite a réaliser les traitements en local. Ceci inverse la
tendance SaaS. Il est donc assez aisé de pousser dans ce sens.
Aisé parce que les arguments à avancer peuvent être de plusieurs natures :

  - éthique (le SaaS n'est pas compatible avec le libre)
  - technique (économie des serveurs, limitation des problèmes de bande
passante, de connexion...)
</pre>
      </blockquote>
      <pre wrap="">
Si l'utilisateur sait clairement ce que le navigateur va exécuter, ce 
n'est pas un problème. S'il n'a aucun contrôle là-dessus, ça en devient 
un. L'acceptation par tous les navigateurs des DRM est de ce point de 
vue peu rassurante.
</pre>
    </blockquote>
    Les DRM ne sont pas des backdoors. Sans compter que
    <meta http-equiv="content-type" content="text/html; charset=utf-8">
    <title></title>
    <meta name="generator" content="LibreOffice 4.3.3.2 (Linux)">
    <style type="text/css">
		@page { margin: 2cm }
		td p { margin-bottom: 0cm; so-language: zxx }
		p { margin-bottom: 0.21cm; so-language: zxx }
	</style>le draft "encrypted media extension" n'a pas été validé par le
    W3C :<br>
    <a class="moz-txt-link-freetext" href="http://www.w3.org/TR/encrypted-media/">http://www.w3.org/TR/encrypted-media/</a><br>
    C'est même finalement l'effet inverse. Si tu n'as pas payé le droit
    de consulter une ressource, tu n'y accéderas pas. Charge à
    l'utilisateur de refuser d'utiliser ce système de verrouillage.<br>
    Il est encore possible qu'il ne soit jamais standardisé. NetFlix,
    Google et Microsoft poussent pour que ça le devienne mais ils n'ont
    pas encore gagné.<br>
    <br>
    <blockquote cite="mid:54788226.1050404@pi-et-ro.net" type="cite">
      <pre wrap="">
</pre>
      <blockquote type="cite">
        <pre wrap="">Quid des données envoyées sur le serveur ?
---
Certains l'ont déjà précisé dans d'autres fils de discussion sur cette
liste. Tout d'abord, ce n'est pas la problématique du "SaaSS". SaaS
équivaut à "traitement des données personnelles par un service".
Mais je crois qu'il faut prendre position sur le problème des données
stockées "ailleurs". Le SaaS n'est qu'une brique du cloud computing. Le
stockage des données en est une autre tout aussi importante.
Actuellement, la solution pour régler ce problème me semble à la portée
de tous.
Ce qui pose problème dans ce cas de stockage distant, c'est la "valeur"
intrinsèque de la donnée envoyée. Une donnée sans valeur peut très bien
être stockée sur un serveur quelconque. Le fournisseur de service ne
pourra rien en faire.
Pour qu'une donnée perde sa valeur, il suffit de la chiffrer. Et pour
partager ces données avec d'autres utilisateurs, il suffit que
l'application échange des clés de chiffrement/déchiffrement entre ces
utilisateurs.
Encore une fois, HTML5 le permet. De cette manière, des données "sans
valeur" sont stockées quelque part, partageables entre utilisateurs et
inexploitables par les fournisseurs de service.
</pre>
      </blockquote>
      <pre wrap="">
Tu ne peux pas dévaloriser une donnée. La seule dévalorisation possible 
est que personne n'y accède. Si on y accède, même de façon chiffrée, 
elle aura une valeur.</pre>
    </blockquote>
    <br>
    laquelle ? Je fais des paiements en ligne sans aucune inquiétude.
    C'est un leurre de croire que tes données sont plus sécurisées si
    elles sont physiquement chez toi. Le verrouillage numérique est
    aussi sûr (ou aussi peu sûr) que le coffre fort dans ton salon.<br>
    <br>
    <blockquote cite="mid:54788226.1050404@pi-et-ro.net" type="cite">
      <pre wrap="">

Le problème tient à la construction de l'économie de l'informatique. Le 
modèle de Microsoft® est illégitime. On ne vend pas des choses dont la 
reproduction ne coûte rien, comme si c'est c'était des objets matériels.
Le modèle de Google® est illégitime et injuste. On n'offre pas un 
service gratuit en transformant ses utilisateurs en produits.

Ces systèmes économiques ne profitent à personne sinon aux entreprises 
qui les portent et sont inutiles.

</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">--
Pour vous désinscrire de cette liste : <a class="moz-txt-link-freetext" href="https://listes.april.org/wws/sigrequest/educ">https://listes.april.org/wws/sigrequest/educ</a>

Pour gérer votre abonnement à la liste educ et vos informations personnelles :
<a class="moz-txt-link-freetext" href="http://listes.april.org/wws/info/educ">http://listes.april.org/wws/info/educ</a>


</pre>
    </blockquote>
  </body>
</html>

--------------030307050502000007080509--

------------=_1417188257-7498-63
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

--
Pour vous désinscrire de cette liste : https://listes.april.org/wws/sigrequest/educ

Pour gérer votre abonnement à la liste educ et vos informations personnelles :
http://listes.april.org/wws/info/educ


------------=_1417188257-7498-63--