Je suis très fier de vous annoncer que Cozy est officiellement lancé.
Qu’est‐ce que Cozy ? Eh bien, c’est tout d’abord un domicile numérique, un espace où vous êtes chez vous avec vos données (fichiers, photos, bancaires, vacances). Cozy vous permet également de récupérer vos données depuis des services tiers pour mieux les utiliser. Comment ? Avec les connecteurs qui vous les rangent automatiquement pour ne plus perdre de temps à les chercher. Enfin, on peut faire confiance à son Cozy : le code est libre, il est possible de s’auto‐héberger, Cozy Cloud (la société) ne fait pas dans la publicité ciblée, l’exploitation ou la revente de vos données. Grâce à tout ça, Cozy peut vous simplifier votre vie numérique.
La suite de la dépêche permet de découvrir les différentes applications de Cozy et de revenir sur les échanges qui avaient eu lieu lors de la précédente dépêche qui annonçait les premiers travaux sur la nouvelle version de Cozy.
Sommaire
- Préambule
- À quoi ça ressemble ?
- Et la suite ?
-
Retour sur la nouvelle architecture
- Améliorer l’installation pour les auto‐hébergés
- Avoir plusieurs instances sur un seul serveur (pour une famille par exemple)
- Ne plus stocker les fichiers dans CouchBD (pour simplifier les sauvegardes et savoir retrouver les fichiers en cas de corruption de la base CouchDB)
- Partager des documents avec d’autres utilisateurs
- Garder le code Libre
- Chiffrement des données
- Pourquoi redévelopper des applications ?
- Passage de Node.js à Go
- Comment passer de Cozy v2 à Cozy v3 ?
- Notion de groupe ?
- Remerciements
Préambule
J’utilise parfois « nous » pour décrire le travail de l’équipe Cozy Cloud. Je suis salarié de Cozy Cloud, mais cette dépêche a été rédigée par mes soins, spécialement pour LinuxFr.org, et ne reflète que mon opinion personnelle (pas celle de mon employeur).
À quoi ça ressemble ?
Voici quelques captures d’écran qui permettent de montrer le chemin accompli depuis Cozy v2 en termes d’expérience utilisateur et d’interface utilisateur. Les applications sont moins nombreuses, mais beaucoup mieux pensées et léchées.
Les photos prises depuis votre appareil mobile sont sauvegardées sur votre Cozy. Vous pouvez les afficher, créer des albums et partager ces albums avec vos proches :
Le Drive est l’application qui sert à gérer vos fichiers. Il se décline en version Web, mobile et bureau :
L’application Collect sert à configurer la récupération de contrats, de factures et de remboursements de santé depuis différents services tiers. Nous vous encourageons à nous dire quels seraient les collecteurs qui vous seraient les plus utiles, voire à développer des collecteurs :
L’application Banks permet de suivre ses comptes bancaires et de recevoir des alertes sur le solde ou des opérations dépassant un certain montant. Actuellement, l’importation des données se fait via un service commercial, Linxo. Pour le futur, nous sommes en train de mettre en place un moteur de catégorisation bancaire dont le modèle serait construit grâce aux catégorisations manuelles des utilisateurs de Cozy (les retours se feront de manière anonyme et uniquement pour ceux qui se portent volontaires). Et nous surveillons ce que les banques vont proposer pour se mettre en conformité avec les réglementations européennes qui vont s’appliquer dans les mois qui viennent (RGPD et DSP 2).
Les interfaces Web des applications Cozy sont bien évidemment adaptatives (responsive en anglais). Nous proposons également des applications Cordova sur Android et iOS, ce qui permet l’accès à des données du mobile (photos, contacts) pour les sauvegarder sur le Cozy.
Et la suite ?
On devait avoir l’authentification à deux facteurs juste à temps pour le lancement, mais ça a pris un petit peu de retard. Ça va arriver bientôt !
Le prochain objectif est d’ouvrir la plate‐forme pour installer d’autres applications. Pour le moment, l’installation et la mise à jour des applications se fait via la ligne de commande. On va ajouter une app’ « Magasin d’applications » pour faire ça quand on n’est pas administrateur de son propre serveur.
Et comme ça serait dommage d’avoir un magasin d’applications un peu vide, on va aussi travailler à le remplir. On va commencer par une application de gestion de ses contacts. Elle existait dans la précédente version de Cozy et elle manque dans la version actuelle.
On va bien sûr ajouter de nouveaux collecteurs pour importer des données depuis plus de services tiers, prendre en compte les nombreux retours des utilisateurs qui découvrent la plate‐forme, travailler pour faciliter l’auto‐hébergement, etc. Le lancement officiel est une étape importante pour nous, et à titre personnel, je suis très fier d’avoir construit cette plate‐forme. Mais on ne va pas se reposer sur nos lauriers, on va continuer nos efforts de manière plus visible au‐dessus de la plate‐forme technique.
Retour sur la nouvelle architecture
J’avais écrit ici une dépêche intitulée Donnez votre avis sur la nouvelle architecture de Cozy. Vous, lecteurs du site, aviez joué le jeu et les nombreux commentaires avaient permis de mieux comprendre les envies de chacun et d’affiner nos choix techniques. Voici quelques points pris dans ces commentaires, avec l’état d’avancement aujourd’hui :
Améliorer l’installation pour les auto‐hébergés
Il y a du mieux (plus besoin d’avoir un démon cozy qui tourne en root par exemple) et des choses qui sont plus compliquées qu’avant (DNS et certificats TLS principalement, car on isole maintenant chaque application sur un sous‐domaine pour des raisons de sécurité). C’est un chantier sur lequel on a encore pas mal de boulot !
Avoir plusieurs instances sur un seul serveur (pour une famille par exemple)
Là, je pense que l’on est bon. On peut maintenant installer une seule fois Cozy sur un serveur et l’utiliser pour plusieurs instances.
Ne plus stocker les fichiers dans CouchBD (pour simplifier les sauvegardes et savoir retrouver les fichiers en cas de corruption de la base CouchDB)
Les fichiers ne sont plus stockés dans CouchDB. Sur notre infrastructure, ils sont stockés dans Swift. Pour les auto‐hébergés, ils sont stockés dans un répertoire du disque dur local. Attention, il ne faut pas modifier directement ce répertoire. On aimerait ajouter d’autres modes de stockage, minio en particulier.
Partager des documents avec d’autres utilisateurs
On permet le partage par lien : quand vous êtes dans l’interface Web de votre Cozy, il est possible de sélectionner un répertoire ou un album photo et de générer un lien avec un secret que vous pourrez transmettre aux personnes à qui vous voulez permettre d’afficher ce répertoire ou album photo.
Et je planche actuellement sur le partage dit de Cozy à Cozy. Par exemple, on voudrait permettre de partager un répertoire avec d’autres personnes : le répertoire serait présent sur chacune des instances Cozy des personnes qui sont dans le partage et quand une personne modifie un fichier, les modifications sont propagées chez les autres membres du partage (ça ressemble à ce que propose Dropbox ou Google Drive, mais en décentralisé, je me prends bien la tête pour trouver comment faire ;-)). Autre exemple : pouvoir « partager » les écritures d’un compte bancaire (en lecture seule) avec une personne de confiance. Cette autre personne pourrait voir dans son Cozy son compte bancaire et pourrait également consulter le compte de l’autre. C’est particulièrement utile en famille entre les comptes joints, les comptes pour les enfants ou les personnes âgées qui conservent leur autonomie financière, mais dont on pourrait surveiller le compte pour vérifier qu’elles ne se sont pas faites escroquer. Ce type de partage va sûrement beaucoup m’occuper dans les mois qui viennent.
Garder le code Libre
Il est toujours possible de s’auto‐héberger et tout le code pour le faire est sous licence libre (licences AGPL et MIT selon les composants). On a un peu de code propriétaire, la glu côté admin/sys pour pouvoir héberger beaucoup d’instances Cozy sur notre infrastructure, les formulaires de création de Cozy, mais ça représente moins de 10 % du code écrit par Cozy Cloud. Le logiciel libre fait partie de notre ADN et ça ne va pas changer.
Chiffrement des données
Actuellement, on conseille de chiffrer les disques durs. Les seules données que l’on chiffre dans le Cozy sont les identifiants pour se connecter aux sites externes. Nous avons besoin d’accéder aux données en clair sur le serveur pour fournir les services. Si vous n’avez pas confiance dans nos administrateurs système (et ça peut être tout à fait légitime), je vous conseille soit de vous auto‐héberger, soit de vous tourner vers des administrateurs système en qui vous avez confiance et qui seraient prêts à héberger pour vous des instances Cozy (ça pourrait être des acteurs associatifs comme les CHATONS ou des acteurs commerciaux).
Pourquoi redévelopper des applications ?
Pour s’auto‐héberger et utiliser des applications existantes, il existe déjà des solutions comme YunoHost. Nous ne voyons pas trop quelle valeur nous pourrions apporter en plus sur ce modèle. Cozy vise autre chose : être un domicile numérique, et cela impose de développer des applications qui travaillent sur des données communes et peuvent créer des ponts entre elles. Par exemple, on peut consulter son compte bancaire et cliquer sur une écriture bancaire concernant Trainline pour afficher le PDF de la facture, stocké dans son Drive.
Passage de Node.js à Go
Le code côté serveur a été entièrement réécrit pour cette nouvelle version. Il est maintenant en Go, les versions précédentes étaient en Node.js. De manière très synthétique, nous sommes satisfaits de Go, cela nous aide sur la stabilité et les performances.
Comment passer de Cozy v2 à Cozy v3 ?
En rapide, on exporte les données du Cozy v2 avec la dernière version de cozy-monitor (cozy-monitor export cozy.tar.gz), on recopie l’archive TAR sur le nouveau serveur, on crée son instance puis on importe les données (cozy-stack import). N’hésitez pas à venir sur le canal IRC #cozycloud sur freenode si vous avez besoin d’un coup de main.
Notion de groupe ?
Cozy est un domicile numérique et nous ne pouvons pas tout faire. Nous ne cherchons pas à concurrencer les groupwares. Nextcloud, par exemple, est mieux adapté pour les groupes. Ceci dit, nous essayons quand même d’éviter de trop cloisonner et nous souhaitons offrir des fonctionnalités de partage dont j’ai parlé ci‐dessus.
Je vous encourage à donner à nouveau votre avis : posez vos questions et remarques en commentaire, je tâcherais de répondre aux questions. En plus, nous sommes plusieurs de l’équipe à lire le site et à tenir compte des avis qui y sont écrits.
Remerciements
Je vais finir avec une note plus personnelle. J’ai la chance de travailler avec une équipe fantastique chez Cozy Cloud. Ça serait sûrement un peu long de remercier chaque personne de l’équipe une par une (même si le cœur y est), mais je tiens à remercier tout particulièrement Zoé, Joseph et Romain. Ils sont tous les trois dans l’aventure Cozy depuis bien plus longtemps que moi, souvent dans l’ombre, et leur implication n’a pas faibli lorsque l’on s’est lancé dans cette nouvelle version de Cozy. Merci à vous !
Aller plus loin
- Le site officiel de Cozy (2744 clics)
- Créer son instance Cozy sur l’infrastructure Cozy Cloud (515 clics)
- Installer Cozy sur son serveur (debian et dérivés) (801 clics)
- Jour 1 : Cozy Cloud lance Cozy (158 clics)
- Next INpact a testé Cozy Cloud, la plate‐forme de stockage et de reprise en main des données (451 clics)
- [TechCrunch] Cozy is building a personal cloud service that respects your privacy (90 clics)
- [LinuxFr.org] Donnez votre avis sur la nouvelle architecture de Cozy (132 clics)
- [LinuxFr.org] Cozy Cloud lève 4 millions d’euros (pour faire du Libre) (116 clics)
- [Framasoft] Le nuage de Cozy monte au troisième étage (274 clics)
# patience
Posté par insert_coincoin . Évalué à 10.
J'attends la réapparition du calendrier et des contacts pour migrer de la v2 à la v3 :|
# et le multi-utilisateurs ?
Posté par ledufakademy . Évalué à 1. Dernière modification le 29 janvier 2018 à 11:21.
Hello, super de voir cette plate-forme évoluer.
Je l'avais un peu testé sur la demo on-line.
Mais le gros gros blocage pour moi fût l’absence de mode multi-utilisateurs (comme dans Nextcloud), est-ce que cette fonctionnalité est intégrée ? (le point 10 est assez flou)
[^] # Re: et le multi-utilisateurs ?
Posté par Aeris (site web personnel) . Évalué à 4.
Une seule stack peut gérer plusieurs instances différentes dorénavant oui.
# Utilisation comme degoogleisateur ?
Posté par Wawet76 . Évalué à 6.
J'aimerais synchroniser les données de mon téléphone (fichiers, contact, calendrier) avec un serveur dans lequel j'ai confiance. Histoire de ne pas tout perdre en cas de casse ou vol principalement.
Aujourd'hui j'utilise mon compte Google pour les contacts, mais j'ai toujours refusé de synchroniser les fichiers avec eux. L'été dernier ça ma valu la perte de pas mal de photo avec un vol de mon téléphone…
Vu le commentaire juste au dessus (absence de calendrier et contact dans la v3) ce n'est pas encore possible, mais c'est bien une chose pour laquelle Cozy est conçu ?
[^] # Re: Utilisation comme degoogleisateur ?
Posté par Bruno Michel (site web personnel) . Évalué à 8.
Oui, Cozy est conçu pour ça. Pour les fichiers, c'est en place. Pour les contacts, ça va arriver bientôt. Pour les calendriers, on va le faire mais c'est moins clair sur le quand : l'effort à fournir est bien plus important et ce n'est pas facile de savoir quelle est sa priorité par rapport à d'autres demandes. Les retours d'utilisateurs, comme ton commentaire, vont d'ailleurs nous aider à mieux comprendre les attentes et à mieux définir les priorités.
[^] # Re: Utilisation comme degoogleisateur ?
Posté par insert_coincoin . Évalué à 10.
Je suis dans le même cas : pour moi, la dégooglisation passe avant tout par la libération de l'agenda en ligne et de la gestion des contacts. J'ai été très surpris de constater que la v3 passait totalement à côté.
[^] # Re: Utilisation comme degoogleisateur ?
Posté par Psychofox (Mastodon) . Évalué à -1. Dernière modification le 29 janvier 2018 à 15:56.
J'sais pas. Pour moi les contacts/agenda en ligne ça se fait via des outils comme Sabre, Radicale, Kolab, Sogo, Citadel et j'en passe. La question est réglée depuis belle lurette et t'as pas vraiment besoin d'interface web de gestion de tes contacts et de ton agenda si de toute manière c'est synchronisé avec tes appareils mobiles et environnements de bureaux. Alors que des fichiers multimedias, ça a plus d'intérêt, notemment pour le partage avec l'extérieur. Rien n'empêche de faire tourner Cozy et un serveur Sabre sur le même serveur/hébergement.
[^] # Re: Utilisation comme degoogleisateur ?
Posté par Sak . Évalué à 5.
Cozy, c'est aussi et surtout pour madame & monsieur toutLeMonde, qui ne fera pas de l'auto-hébergement. Il me semble aussi qu'il faut absolument cette gestion des calendriers/contacts, et une appli qui configure tout aussi simplement que les trucs de Google.
[^] # Re: Utilisation comme degoogleisateur ?
Posté par Psychofox (Mastodon) . Évalué à -4.
Monsieur et Madame toutlemonde peut avoir ça sans Cozy encore plus simplement. Le partage de calendrier/contacts est proposé par une tripotée de fournisseurs mail.
[^] # Re: Utilisation comme degoogleisateur ?
Posté par Sak . Évalué à 8.
Monsieur et Madame toutLeMonde peut avoir de la synchro et du stockage de fichier sans Cozy, c'est proposé par plein de fournisseurs.
Monsieur et Madame toutLeMonde peut stocker des photos sans Cozy, c'est proposé par plein de fournisseurs.
Bref.
[^] # Re: Utilisation comme degoogleisateur ?
Posté par Psychofox (Mastodon) . Évalué à -10.
Purée je t'explique juste que la synchro de calendrier/contacts utilise ses technologies propres (usuellement caldav/cardav) et qu'on a déjà des propositions très facile à mettre en place pour auto-héberger ou pas ces fonctionnalités.
Est-ce si dur à comprendre ? Où es-tu tout simplement partisan de la grosse usine à gaz qui fait tout moyennement bien ? Perso je préfère que les développeurs d'un projet comme Cozy se concentrent sur une solutions qui permette à tout un chacun de se passer d'un dropbox/google drive avec des fonctionnalités au moins aussi bonnes et laisser les solutions libres existantes de serveurs caldav/cardav répondre à la question synchro de contacts/calendriers. On a déjà assez de choix sur ce dernier point.
[^] # Re: Utilisation comme degoogleisateur ?
Posté par Philip Marlowe . Évalué à 9.
Non, ce qu'il t'explique, c'est que les services de synchro de calendrier ne sont pas très répandus et que ceux de contacts très rares à être accessibles à Monsieur tout le monde. C'est également ce que j'ai constaté.
[^] # Re: Utilisation comme degoogleisateur ?
Posté par Psychofox (Mastodon) . Évalué à -2.
Foutaises.
En dehors des solutions d'autohébergements que j'ai mentionné plus haut, et qui sont disponibles via une tripotée d'hébergeurs cloud, voici quelques exemples sortis vite du chapeau :
Google (évidemment)
Microsoft Office365 et Live
Gandi (avec un nom de domaine, t'as 5 mailbox avec accès caldav/cardav)
Workspace (infomaniak)
zimbra.free.fr
apple icloud
fruux
[^] # Re: Utilisation comme degoogleisateur ?
Posté par Bruno Michel (site web personnel) . Évalué à 4.
Par curiosité, tu aurais des informations sur l'accès caldav ? La recherche sur le wiki de Gandi ne donne rien et en passant par un moteur de recherche, je tombe sur un article de Next INpact disant que Gandi réfléchit à ajouter caldav.
[^] # Re: Utilisation comme degoogleisateur ?
Posté par Cyril Brulebois (site web personnel) . Évalué à 3.
Ça semble disponible dans leur webmail SOGo, avec des URL de ce genre :
https://sogo3.gandi.net/SOGo/dav/you@example.com/Calendar/personal/: CalDAV ;https://sogo3.gandi.net/SOGo/dav/you@example.com/Calendar/personal.ics: représentation ICS via WebDAV ;https://sogo3.gandi.net/SOGo/dav/you@example.com/Calendar/personal.xml: représentation XML via WebDAV.Disclaimer : Jamais utilisé, j'utilise NextCloud pour calendriers & contacts.
Debian Consultant @ DEBAMAX
[^] # Re: Utilisation comme degoogleisateur ?
Posté par Victor . Évalué à 2.
Pour confirmer, j'utilise SOGo (pas chez gandi, mais bon) et je synchro agenda et contacts sur mon tel sans problème comme tu viens de le décrire.
[^] # Re: Utilisation comme degoogleisateur ?
Posté par Philip Marlowe . Évalué à 3.
Oui en effet je ne suis pas assez précis. Je pense aux services de ce genre dont on peut espérer qu'ils respectent ta vie privée. Tu peux déjà en rayer quelques uns dans ta liste.
[^] # Re: Utilisation comme degoogleisateur ?
Posté par Psychofox (Mastodon) . Évalué à -3.
Il y'a une tripotée de services d'hébergement mails/groupwares qui utilisent sogo et offrent le partage de contacts/calendrier à la manière de Gandi que j'ai cité plus haut.
Maintenant moi je parlais à la base du logiciel Cozy, leur offre d'hébergement on s'en cogne un peu amha. L'initiateur de ce fil de discussion, Wawet76, parlais de " synchroniser les données de mon téléphone (fichiers, contact, calendrier) avec un serveur dans lequel j'ai confiance."
Ben je répond juste que ça il peut le faire depuis belle lurette sans Cozy en utilisant des logiciels libres qui existent déjà et que perso je trouve que c'est plus utile de bosser sur les fonctionnalités clés de Cozy pour les améliorer plutôt que de se disperser avec ce genre de truc qui sont un peu hors-sujet.
À moins que la volonté de Cozy soit d'être un truc pour concurrencer des trucs comme sandstorm.io, nethserver ou yunohost mais je ne crois pas que ce soit le cas.
[^] # Re: Utilisation comme degoogleisateur ?
Posté par Sak . Évalué à 7.
C'est vrai que c'est super facile pour le quidam, d'aller chez Gandi, s'acheter un compte, se taper une synchro *dav tout à la main avec des urls compliquées à rentrer dans Davdroid.
On parle pas de groupware, on parle d'un service personnel de synchro hyper simple à mettre en place, comme celui de Google par exemple. Cozy semble tout indiqué pour ça ("domicile numérique"). Je vois pas où est le hors sujet.
Rien n'indique que Wawet76 parlait d'auto-hébergement. Et quand bien même, on peut ouvrir la discussion, comme le prouve le commentaire de Bruno "Les retours d'utilisateurs, comme ton commentaire, vont d'ailleurs nous aider à mieux comprendre les attentes et à mieux définir les priorités"
Sinon, à titre d'exemple, le client android de Nextcloud a pas mal simplifié le truc ses derniers temps (il propose l'install de davdroid si non présent, et préconfigure la connexion).
[^] # Re: Utilisation comme degoogleisateur ?
Posté par Psychofox (Mastodon) . Évalué à -3. Dernière modification le 01 février 2018 à 07:32.
Là tu relève un manque du côté des clients dav sous android qui selon toi ne seraient pas assez simple à utiliser ou ne bénéficieraient pas d'autoconfiguration, c'est un peu hors-sujet.
Mais sinon, non accessoirement ce n'est pas plus compliqué d'acheter un domaine chez Gandi ou créer une boite mail chez infomaniak workspace (pour ne citer que deux exemples que je connais) que d'ouvrir une boite gmail. Si madame Michu arrive à acheter sa nouvelle paire de chaussures chez Zalando, elle est capable de faire ça. Faut arrêter de prendre les gens pour des idiots aussi.
[^] # Re: Utilisation comme degoogleisateur ?
Posté par Sak . Évalué à 8.
Bonjour Mme Michu : merci de créer votre adresse mail, je vous propose :
- https://www.google.com/intl/fr/gmail/about/
- https://www.infomaniak.com/fr
N'oubliez pas de mettre en place la synchronisation de vos données avec votre mobile après :)
3, 2, 1, c'est parti !
Mais je vais te laisser le dernier mot. Tout ça n'est pas très grave. Néanmoins, je te conseille de sortir de ta bulle de Geek.
[^] # Re: Utilisation comme degoogleisateur ?
Posté par Psychofox (Mastodon) . Évalué à 0. Dernière modification le 01 février 2018 à 11:59.
Expliques-moi concrètement en quoi utiliser un serveur Cozy à la place rendrait la chose plus facile pour la fameuse Madame Michu ?
[^] # Re: Utilisation comme degoogleisateur ?
Posté par Bruno Michel (site web personnel) . Évalué à 4.
Par rapport à Google, on pourrait amener le respect de la vie privée, parce que, oui, clairement, on ne pourra pas faire plus facile.
Par rapport à Workspace, il y a plusieurs points :
- la question de la notoriété (bon, pour le moment, Cozy n'est pas connu du grand public, si ce n'est un petit peu via Tristan Nitot, donc ça ne changerait pas fondamentalement les choses)
- ensuite la question du positionnement : Workspace est présentée comme une solution pour PME, la plupart des gens ne vont pas aller voir ce qu'il y a derrière, alors que Cozy n'a pas cette barrière
- et après, la question de la facilité (je n'ai pas d'avis sur la question, je n'ai pas testé Workspace).
[^] # Re: Utilisation comme degoogleisateur ?
Posté par Sak . Évalué à 4.
Je profite du fil pour dire que je viens de tester, très rapidement (en branchant les la banque et le fai). C'est vraiment de la bebon. J'ai eu la v2 un temps en auto-hébergement, et même si on a perdu l'agenda et les contact (pour l'instant) ça a vraiment évolué dans le bon sens. (J'avais abandonné parce que je voulais vraiment de la synchro de fichiers.)
J'ai maintenant un nextcloud@home et j'en suis très satisfait, mais d'un point de vue utilisateur basique, Cozy est vraiment d'une radicale simplicité, ça se passe d'explication, c'est très enthousiasmant. En tous cas, je vais dire de ce pas à ma femme que si demain je suis 6 pieds sous terre, elle passe à Cozy, et elle peut couper le serveur l'esprit tranquille :)
Chapeau.
Les tarifs sont vraiment sympathiques aussi, j'espère que ça tiendra la charge si vous avez une invasion (je pense à la catastrophe qu'est devenu Hubic).
[^] # Re: Utilisation comme degoogleisateur ?
Posté par Bruno Michel (site web personnel) . Évalué à 2.
Merci beaucoup pour ces encouragements !
[^] # Re: Utilisation comme degoogleisateur ?
Posté par Anonyme . Évalué à 5.
Je reste sidéré à chaque fois que j'entends ou lis une personne dire qu'elle confie ses identifiants bancaires à un tiers.
Cozy se positionne sur le marché de la protection des données personnelles, mais ça ne gêne pas ses utilisateurs de voir leurs identifiants stockés en clair dans la base de données d'une entité tierce.
Je n'ai aucune raison de faire plus confiance à Cozy qu'à d'autres fournisseurs de services en ce qui concerne la gestion de mes données: dans ce domaine, seuls les éléments techniques mis en œuvre devraient être pris en compte. Dans ce cas précis, à moins que les gens de Cozy ne viennent me contredire, ces données sont stockées sans mesure de protection particulière dans la base, de manière à garantir leur utilisation pour la bonne fonctionnalité du service.
On va me répondre que de toute façon, l'exploitation du site bancaire via ces identifiants est limitée par une double authentification nécessitant un accès au téléphone du propriétaire, et par tout un tas d'autres limitations qui minimiseront les dégâts possibles. Quand on voit la manière dont les banques gèrent leur sécurité informatique, ça ne me rassure nullement…
La seule méthode qui me satisferait, en supposant que j'accepte de partager mes données bancaires avec un tiers, ce serait de faire comme l'application boobank de weboob qui peut se coupler avec le service en ligne Budgéa: les données sont récupérées sur la machine personnelle de l'utilisateur, puis transférées au service de traitement de données. Seules les informations nécessaires au service proposé sont transmises, sans risque de débordement.
[^] # Re: Utilisation comme degoogleisateur ?
Posté par Bruno Michel (site web personnel) . Évalué à 8.
Je te contredis : on chiffre ces identifiants avant de les mettre en base de données.
Ceci dit, plus généralement, oui, il faut faire confiance à Cozy : les identifiants vont forcément être déchiffrés avant d'être utilisés pour se connecter au site de la banque, donc un admin/sys peut y avoir accès. Si tu n'as pas confiance dans Cozy, il y a la possibilité de s'auto-héberger.
Et sur le plus long terme, la méthode d'avoir un outil tiers (nous avions pensé à une extension navigateur) qui aliment le cozy sans que celui-ci n'ait accès aux identifiants est effectivement une approche plus séduisante. Mais il y a beaucoup de boulot pour y arriver, donc ça ne sera pas pour tout de suite.
[^] # Re: Utilisation comme degoogleisateur ?
Posté par Anonyme . Évalué à 6.
et j'en suis ravi :)
A Cozy aujourd'hui, ou plutôt à Cozy qui fait confiance au prestataire Linxo (d'ailleurs, qui comment se gère le stockage et , si besoin, la communication des identifiants entre vos deux entités ?), mais demain si Cozy ou/et Linxo changent de propriétaire, d'équipe dirigeante, ou d'équipe technique quelle qu'en soit la raison, cette confiance sera mise à mal et les utilisateurs seront en droit de se poser des questions sur l'utilisation qui serait faite de leur données.
Je suis conscient que mon discours se cantonne au "et si…" et reste dans le domaine de la masturbation intellectuelle à ce jour.
Néanmoins, la solution à long terme que tu évoques, sous forme d'extension ou autre, me parait aller au delà de la complémentarité avec votre offre actuelle: elle viendrait techniquement asseoir la confiance que vos utilisateurs ont aujourd'hui l'obligation « de mettre à l'intérieur de vous ». Même si dans une approche pragmatique, cela ne toucherait que les quelques paranos de mon acabit.
Dans tous les cas, Cozy est aujourd'hui un plus indéniable pour convaincre Madame Michu de l'importance de bien gérer ses données personnelles en présentant une alternative viable aux grands silos, donc bravo et bonne continuation !
[^] # Re: Utilisation comme degoogleisateur ?
Posté par Sak . Évalué à 3.
Très bonne remarque, ça fait pas plaisir de passer pour un con, mais t'as visé juste. D'ailleurs, quand j'ai testé, j'ai eu la flemme de me renseigner ou de monter un conteneur à la maison.
Ceci étant dit, on fait pas tout, toujours en autonomie dans son coin. Y'a quand même un paquet d'actions et de de décisions, parfois quotidiennes, qu'on soumet à la confiance., y compris pour des trucs potentiellement dangereux (médicaments, additifs alimentaires, etc.)
Dans mon cas perso (on s'en fout, mais c'est pour illustrer), ce service aurait été proposé par un GAFAM, j'aurai pas testé. J'ai confiance en Cozy (techniquement et éthiquement), mais en effet j'ai pas les preuves, et peut-être que je me fais avoir par un discours marketing après tout. Tant pis, y'a pas de risque zéro, c'est une question de curseur.
[^] # Re: Utilisation comme degoogleisateur ?
Posté par Anonyme . Évalué à 6.
Dans le doute, je ne relèverai pas: je n'ai pas bien saisi qui passait pour un con ;)
Connais-tu Linxo à qui Cozy fais confiance pour sa fonctionnalité bancaire ?
C'est là tout le problème: la cascade de responsabilité qui, au final, ne permet plus de savoir à quel niveau cette confiance est susceptible d’être rompue.
Du coup le curseur de risque dont tu parles est difficilement positionnable.
[^] # Re: Utilisation comme degoogleisateur ?
Posté par Sak . Évalué à 4.
https://cozy.io/fr/ : gros bouton (comme Google), et pas 15 000 rubriques qui te donne la nette impression que t'es pas la cible.
Si derrière, l'appli mobile est aussi simple, c'est gagné.
[^] # Re: Utilisation comme degoogleisateur ?
Posté par Faya . Évalué à 10.
Quand tu arrives sur infomaniak.com, la 1ère chose qu'on te demande c'est "Saisir un nom de domaine". Madame Michu ne sait pas ce qu'est un nom de domaine. Game over.
Si elle accepte quand même de regarder autour, on y lit "Serveurs, Housing, NAS, SSL" … Là elle flippe carrément.
Madame Michu n'est pas idiote, c'est juste qu'elle ne s'y connait pas dans ce domaine. Chacun son métier/hobby. Donc ouais elle va préférer https://cozy.io/fr parce qu'il y a des mots intuitifs (données personnelles, "domicile numérique"), un gros bouton "Créer" , et on lui demande son adresse e-mail. Ça elle comprend.
[^] # Re: Utilisation comme degoogleisateur ?
Posté par barmic . Évalué à 3.
Tu as déjà une pile de services pour avoir un partage de fichier entre seafile, syncthing, pydio, SparkleShare, SpiderOak, Syncany, git-annex,… qui vont avoir des particularités sur le chiffrement, le partage, l'UI,…
En quoi est-ce que le monde du partage de fichier te semble avoir un manque ?
Personnellement je vois cozy (comme owncloud), il est là pour avoir quelque chose de clef en main.
[^] # Re: Utilisation comme degoogleisateur ?
Posté par Psychofox (Mastodon) . Évalué à 3.
On a parlé plus haut de la fonctionnalités de certains services clouds comme drive qui permettent à deux comptes de synchroniser les mêmes jeux de donnée. Ce serait un beau challenge de voir Cozy permettre d'implémenter ça entre deux instances cozy séparées et gérées par deux admins différents.
[^] # Re: Utilisation comme degoogleisateur ?
Posté par Tonton Th (Mastodon) . Évalué à 5.
Au lieu de raler, tu devrais plutôt nous faire une présentation de chacune de ces solutions, avec le résultat de tes tests, par exemple sur la facilité de mise en oeuvre.
# "Le Logiciel Libre fait partie de notre ADN"
Posté par Zenitram (site web personnel) . Évalué à 6.
Le problème avec l'AGPL (le copyleft en général) mélangé avec du proprio, c'est qu'à partir du moment où on empêche d'autres personnes de faire ce qu'on fait (si il y a un peu d'AGPL, impossible pour les autres non détenteurs des droits de faire du code propriétaire pareil sur quelque chose de "lié" à ce code), le libre fait penser à une publicité (du marketing libre-washing, genre MySQL qui se fait de l'argent en empêchant les autres d'avoir le même business model, le libre n'est la que pour que les libristes fassent de la pub sur un truc pas bankable) pour vendre (directement, ou indirectement par l'hébergement) la partie proprio que seuls détenteurs des droits pourrait faire (avec ce business model), et ce quelque soit le pourcentage de proprio (il suffit de 0.1%, tant que ce 0.1 est la chose bankable).
Est-ce que vous faites bien attention à ce que votre code proprio soit codable en proprio (bref : que d'autres puisse vous remplacer avec le même effort à faire) par une autre personne afin d'être bien clair que la liberté est importante pour vous et que votre objectif avec l'AGPL n'est pas de garder pour vous seuls des droits que vous utilisez afin que personne ne puisse vous remplacer facilement si vous passez pas sympas, pour éviter cet écueil?
Et pourquoi pas, si le Logiciel Libre fait partie de votre ADN, changer la licence du proprio pour du libre pour montrer que le libre est viable sans en fait devoir faire son business sur du non libre (qui serait bizarre pour des gens qui ont le Logiciel Libre dans leur ADN)?
Bref, c'est pas mal d'être transparent dessus, mais ça fait quand même penser à une communication marketing sur le libre comme quoi le libre c'est sympa pour le non rentable mais dès qu'on parle thune faut pas déconner on laisse les gamineries/hobby libristes de côté et on fait du proprio, pas très positif pour le libre (voir par exemple cette présentation "Why Open Core Licensing Sucks").
PS : aucun reproche sur le fait de faire du proprio, j'en fais et utilise moi-même, juste en sentiment mitigé quand je vois de l'affichage sur le libre trop bien c'est notre ADN et en même temps faire du proprio avec du code distribué en copyleft.
[^] # Re: "Le Logiciel Libre fait partie de notre ADN"
Posté par Aeris (site web personnel) . Évalué à 10.
Quand on dit qu’on fait du proprio, c’est plus un abus de langage qu’autre chose.
Les bouts non libérés sont uniquement des bouts de gestion interne de notre infra, nos outils de gestion de notre parc, etc.
N’importe qui souhaitant proposer le même service que nous est en mesure de le faire, il faudra juste qu’il réfléchisse à sa propre infrastructure pour faire tourner tout ça et écrive le code ad-hoc pour sa gestion.
À l’exception de l’aggrégateur bancaire (dont on espère bien donner un équivalent libre pour les auto-hébergés), toutes les fonctionnalités proposées par Cozy sont libres et accessibles à tous.
[^] # Re: "Le Logiciel Libre fait partie de notre ADN"
Posté par Zenitram (site web personnel) . Évalué à 1.
Ca, en général ce n'est pas en "contact" avec du code AGPL, donc le copyleft ne dérange pas pour faire la même chose.
Je comprend bien le soucis quand c'est plus rapide d'acheter un truc déjà fait, et la des fois il est préférable de faire une entorse temporaire aux principes. Mais ça reste une entorse au principe de laisser celui qui reçoit avoir le contrôle du code, car un tiers ne pourrait pas faire pareil.
Autoriseriez-vous un tiers qui aurait la même urgence que vous à faire pareil, par le biais d'une licence temporaire le temps que vous vous débarrassiez du ce code proprio que vous pouvez utilisez que parce que vous avez les droits sur la partie AGPL, pour être à égalité? (si je comprend bien, il y a ici un mélange AGPL / proprio, si ce n'est pas le cas ma question n'a pas lieu d'être)
[^] # Re: "Le Logiciel Libre fait partie de notre ADN"
Posté par Bruno Michel (site web personnel) . Évalué à 7.
Il n'y a pas de mélange AGPL / proprio, ce sont des appels à un service distant.
[^] # Re: "Le Logiciel Libre fait partie de notre ADN"
Posté par Aeris (site web personnel) . Évalué à 4.
C’est en fait bien plus un problème de faisabilité qu’un problème de rapidité.
Cozy n’a pas vocation à redévelopper un aggrégateur bancaire (comme on n’en a pas à redévelopper un webmail).
C’est extrêmement chronophage, en particulier la maintenance permanente à assurer pour conserver la compatibilité avec toutes les banques qui changent leurs « API » tous les 4 matins.
On doit donc forcément passer par un aggrégateur existant. Pour des raisons techniques (scallabilité, intégration…), Kresus n’est pas utilisable de notre côté pour nos offres. On envisage weboob pour les auto-hébergés, mais il y aura aussi un gros boulot d’intégration à faire.
[^] # Re: "Le Logiciel Libre fait partie de notre ADN"
Posté par Glandos . Évalué à 7.
Actuellement, boobank a une commande d'export vers Budgea.
C'est pratique, parce que ça permet d'avoir boobank sur un autre ordinateur, de confiance. Peut-être est-il possible de faire pareil pour Cozy ? C'est une simple suggestion, je ne connais pas les plans en interne :)
[^] # Re: "Le Logiciel Libre fait partie de notre ADN"
Posté par Anthony Jaguenaud . Évalué à 5. Dernière modification le 29 janvier 2018 à 12:47.
Et utiliser weboob pour la partie bancaire ?
Edit: Grillé… :'(
[^] # Re: "Le Logiciel Libre fait partie de notre ADN"
Posté par Florent Fourcot . Évalué à 8.
J'ai un peu la même question mais pour la partie « collecte de documents ». Si je comprends bien, vous codez actuellement un « connecteur » pour chaque site que vous souhaitez ajouter. N'est-ce pas contradictoire avec le principe de ne pas re-développer ce qui existe déjà (l'exemple des banques étant pertinent) ? J'imagine que les connecteurs devront aussi être mis à jour régulièrement.
Weboob notamment permet déjà de récupérer des factures (EDF, GDF, Lampiris (Total spring désormais), freemobile, etc) voir des documents comme des fiches de paie (module ensap, utilisé par la fonction publique d'état). Je suis d'ailleurs curieux de savoir comment vous avez fait pour une intégration aussi poussée avec EDF.
[^] # Re: "Le Logiciel Libre fait partie de notre ADN"
Posté par Bruno Michel (site web personnel) . Évalué à 8.
Oui, nous faisons très attention à cela. Pour le code sous licence AGPL, nous ne demandons pas à nos contributeurs de CLA, donc on est légalement tenu de jouer avec les mêmes règles que les autres.
[^] # Re: "Le Logiciel Libre fait partie de notre ADN"
Posté par Zenitram (site web personnel) . Évalué à 10.
Pff, vous tuez tous les trolls…
Me voilà rassuré.
Mais je pense qu'il vaut mieux être plus clair dans votre transparence dessus, car le libre devient "cool", et pas mal de monde se met à faire du libre-washing en faisant leur business sur la vente de droits qu'ils ne filent pas en libre, et donc où le libre n'est là que pour attirer le chalant sans aucune volonté de laisser des libertés à celui qui reçoit (au contraire, l'idée est de laisser le minimum de libertés tout en étant estampillé libre, donc avec l'idée de ne pas aider celui qui reçoit, juste de prendre le hype), bref de préciser que vous n'utilisez pas de droits que vous ne fournissez pas.
[^] # Re: "Le Logiciel Libre fait partie de notre ADN"
Posté par Anonyme . Évalué à -4.
Tu te rends compte de la taille de ton premier paragraphe (je me suis arrêté là, j’en pouvais plus) ?
Tu as parfois de bonnes réflexions, mais franchement, c’est une plaie de te lire.
[^] # Re: "Le Logiciel Libre fait partie de notre ADN"
Posté par ZeroHeure . Évalué à 4.
Tu te rends compte de la petitesse de ta pensée ? :-)
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: "Le Logiciel Libre fait partie de notre ADN"
Posté par Tanouky . Évalué à 1.
https://lecturerapideblog.com/outils/test-vitesse-lecture/
[^] # Re: "Le Logiciel Libre fait partie de notre ADN"
Posté par Anonyme . Évalué à 1.
Tu vois pas comme une légère différence entre le texte de Zenitram, non structuré et sans aucune ponctuation, et « La folle » de Guy de Maupassant ?
[^] # Re: "Le Logiciel Libre fait partie de notre ADN"
Posté par Tanouky . Évalué à 2.
J'imagine qu'on a tous des excuses et tous des progrès à faire.
Je partageais simplement l'idée qu'une lecture entraînée pourrait t'aider. À défaut de changer les autres, il est possible de s'améliorer, non ?
Mais si tu veux mon avis, le message de Zenitram manque un peu de clarté, c'est vrai.
[^] # Re: "Le Logiciel Libre fait partie de notre ADN"
Posté par BAud (site web personnel) . Évalué à 4.
Je n'ai pas eu de souci à le lire, mais ça doit être parce que je suis habitué au style de notre Zenitram< :-) ou parce que — tout comme lui — je suis sujet à la synchyse malgré mes tentatives de réécrire des phrases courtes avec en tête sujet/verbe/complément et de ne pas oublier de tourner mon clavier 7 fois avant d'appuyer sur la touche Entrée pour me donner le temps de relire.
[^] # Re: "Le Logiciel Libre fait partie de notre ADN"
Posté par Letho . Évalué à 2.
Hors-sujet, mais je viens grâce à toi de découvrir un superbe texte, et je t'en remercie :)
# Accès aux fichiers locaux
Posté par Glandos . Évalué à 4.
J'aimerais partager mon expérience avec Nextcloud sur ce point. J'ai mes fichiers photos, films, et musique sur mon NAS, accessibles en NFS sur mon ordinateur à la maison. Donc performant. Nextcloud, installer sur le même serveur me permet d'accéder aux fichiers locaux en créant des « points de montage », façon UNIX. C'est très efficace, et ça évite la redondance d'informations. Évidemment, ça demande à Nextcloud d'avoir une routine un peu complexe de scan de nouveaux fichiers et de mise en cache des index.
Cela a-t-il été envisagé pour Cozy ?
Sinon, c'est un beau logiciel. Pour l'instant, il en fait peut-être moins que les autres, mais il a l'air de le faire bien. C'est chouette.
[^] # Re: Accès aux fichiers locaux
Posté par Albert_ . Évalué à 3.
Tu fais ca comment? Tu pointes sur le repertoire data de ton nextcloud? Peux tu juste copier des fichiers dedans et nextcloud met a jour sa BD tout seul?
[^] # Re: Accès aux fichiers locaux
Posté par voxdemonix . Évalué à 2. Dernière modification le 29 janvier 2018 à 12:08.
A utiliser avec un cron.
Pour scanner tout les utilisateurs
Pour ne scanner qu'un seul utilisateur spécifié
Cette commande peut prendre du temps suivant la taille des installations, la puissance CPU et le type de disque utilisé.
[^] # Re: Accès aux fichiers locaux
Posté par Albert_ . Évalué à 2.
Cool merci
[^] # Re: Accès aux fichiers locaux
Posté par Glandos . Évalué à 2.
https://docs.nextcloud.com/server/12/admin_manual/configuration_files/external_storage_configuration_gui.html
Mon répertoire data est plutôt vide. Il ne contient que quelques documents synchronisés pour des raisons pratiques.
[^] # Re: Accès aux fichiers locaux
Posté par Bruno Michel (site web personnel) . Évalué à 7.
Oui, cela a été envisagé pour Cozy. Mais ça demande beaucoup d'efforts pour n'intéresser finalement que peu de personnes. Personnellement, j'aimerais bien faire ça, mais je préfère quand même voir d'autres choses arriver avant : la gestion des calendriers ou pouvoir partager un dossier avec une autre instance Cozy. Après, si quelqu'un se sent d'aller coder ça, je veux bien donner un coup de main pour montrer le code concerné et expliquer ce qu'il y aurait à faire.
Merci, ça fait plaisir :)
# raspberrypi ?
Posté par montuno . Évalué à 4.
Bonjour,
Une partie qui m'intéresserait, c'est de pouvoir gérer beaucoup de photos depuis un RPI2.
J'ai donc deux questions: 1) quid des performances globales sur Raspberry ? 2) est-il possible de pré-générer les vignettes ?
Merci
[^] # Re: raspberrypi ?
Posté par Bruno Michel (site web personnel) . Évalué à 4.
1) Je n'ai pas testé personnellement. Il me semble avoir entendu dire que ça marchait correctement, mais si d'autres personnes peuvent confirmer, ça serait pas mal.
2) La partie serveur de Cozy génère des vignettes pour les photos/images de grande taille avec Image Magick. Tu voudrais pouvoir générer ces vignettes ailleurs et les déposer sur le RPI pour que le RPI n'ait pas besoin de les générer, c'est bien ça ?
[^] # Re: raspberrypi ?
Posté par ZeroHeure . Évalué à 1.
Pourquoi ImageMagick ? il me semble avoir vu des outils moins gourmands (Ram, cpu) pour générer les vignettes. J'imagine que tu as déjà fait des comparaisons sur linuxfr ?
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: raspberrypi ?
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 4.
C'est l'outil "standard" pour qui veut faire de la manipulation d'images… en tout cas celui que tout le monde connait, je pense.
Est-ce que tu aurais des noms ?
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: raspberrypi ?
Posté par Bruno Michel (site web personnel) . Évalué à 10.
Il y a pas mal de contraintes en jeu : les performances, mais aussi la qualité des vignettes, le poids des fichiers générés, la prise en charge des différents formats d'image et cas particulier (l'orientation EXIF par exemple), la facilité de déploiement, etc. Image Magick reste le meilleur compromis sur tout ça.
Si on prend en compte juste l'aspect performances, un même outil comme Image Magick peut se comporter de façon très différente selon les options passées. Voici un petit benchmark, à ne pas prendre trop sérieux, c'est juste pour illustrer ces propos : https://github.com/fawick/speedtest-resize/commit/afea1a69f1791d779001f572d39ce5651f12e2e6.
Un des "mensonges" de ce genre de benchmark est la parallélisation. Certains outils n'utilisent pas de parallélisation (un seul cœur), tandis que d'autres profitent de tous les cœurs disponibles sur un même traitement. En pratique, quand on déploie sur un serveur, on désactive systématiquement la parallélisation, on préfère traiter plusieurs images en parallèle pour occuper les cœurs. Pour donner quelques ordres de grandeur, si on prend un CPU avec 8 cœurs, un outil capable de faire un traitement en parallèle sur une même image va utiliser 100% du CPU sur les 8 cœurs pendant disons 100ms. Le même outil sans parallélisation (un seul cœur) va mettre plus de temps, de l'ordre de deux fois plus, 200ms. Mais comme il laisse les autres cœurs libres, on peut traiter 8 images comme ça en même temps. Du coup, en utilisant du multi-thread, on va traiter 2 images sur une période de 200ms, alors qu'avec 8 images traitées chacune par un processus/thread, on peut traiter 8 images sur cette même période, soit 4 fois plus.
En gros, de ce que j'ai vu voir, on a :
[^] # Re: raspberrypi ?
Posté par ZeroHeure . Évalué à 2.
Merci pour ces très utiles infos, ça m'évitera de faire les tests :-) !
Dans mes marque-pages, il y avait un fork d'image-magick très très rapide (qu'y disait…), mais je ne retrouve plus. C'était une boite française.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: raspberrypi ?
Posté par Bruno Michel (site web personnel) . Évalué à 3.
Peut-être G'Mic ? Je le voyais plus comme une version avancée d'Image Magick pour faire des traitements plus compliqués et je l'avais écarté de mes tests, mais peut-être que je me trompe.
[^] # Re: raspberrypi ?
Posté par ZeroHeure . Évalué à 2.
Non non c'est pas ça. C'est fait par une entreprise, pour ses besoins internes. Je vais fouiller. Ils annonçaient des performances très très bonnes il y 4-5 ans. Mais je n'ai jamais testé.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: raspberrypi ?
Posté par Frank-N-Furter . Évalué à 2.
GraphicsMagick?
Depending on the time of day, the French go either way.
[^] # Re: raspberrypi ?
Posté par ZeroHeure . Évalué à 2.
Non ce n'est pas dans la liste cité par Bruno. Et c'est beaucoup moins connu.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: raspberrypi ?
Posté par Frank-N-Furter . Évalué à 2.
J'l'avais zappé dans la liste, désolé pour le bruit!
Depending on the time of day, the French go either way.
[^] # Re: raspberrypi ?
Posté par ZeroHeure . Évalué à 3. Dernière modification le 06 février 2018 à 19:54.
Je ne retrouve pas le logiciel en question (il me semble qu'il a été un moment dans Debian), mais en farfouillant je suis tombé sur cet article intéressant : The fastest production-ready image resize, à propos de Pillow-SIMD, un fork optimisé de Pillow :
Et il y aussi Mozjpeg de Mozilla et surtout ImageOptim par le développeur de Mozjpeg.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: raspberrypi ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
g'mic peut être rapide. Il utilise openMP et il me semble que l'autovectorisation de gcc marche dessus.
"La première sécurité est la liberté"
[^] # Re: raspberrypi ?
Posté par Jehan (site web personnel, Mastodon) . Évalué à 7.
Si on veut faire des choses puissantes, y a GEGL qui est vraiment pas mal aussi.
Ce n'est pas que le moteur graphique de GIMP (librairie C), on peut aussi créer des transformations simplement en ligne de commande, et côté web par exemple, un contributeur a créé imgflo au dessus de GEGL, qui est utilisé par une entreprise (The Grid) pour du traitement d'image sur le web.
Le README dépôt de imgflo-server notamment donne une bonne idée du système, avec une API HTTP pour traiter des images par graphe, etc.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: raspberrypi ?
Posté par Babelouest (site web personnel) . Évalué à 3.
Par curiosité, j'ai fait un petit programme qui utilise libav pour redimensionner des images:
https://gist.github.com/babelouest/30e29d45dfba6173f0e74d2c848dc60f
J'ai pas à ma disposition des machines pour tester pleinement mais dans la plupart des cas les résultats sont du même ordre, exemple pour une image jpg qui fait 500*497:
[^] # Re: raspberrypi ?
Posté par Tonton Th (Mastodon) . Évalué à 4.
Il manque http://gmic.eu/ à ta liste.
# Chiffrement des données
Posté par bre75 . Évalué à 1.
Bonjour,
Ce n'est valable que pour une installation en self-hosting
Si je comprend bien celà signifie qu'il n'y a pas de chiffrage "At rest".
Est-ce prévu dans un court/moyen terme ?
[^] # Re: Chiffrement des données
Posté par Bruno Michel (site web personnel) . Évalué à 10.
Nous aussi, on chiffre les disques durs. Par contre, un attaquant qui réussirait à avoir un accès direct à CouchDB ou à une sauvegarde pourrait lire les données, exceptés les identifiants des sites externes (qui sont chiffrés/déchiffrés la partie applicative avant d'être envoyé à CouchDB).
Techniquement, vouloir chiffrer toutes les données dans CouchDB nous limiterait très très fortement. En gros, on ne peut plus avoir d'index sur le serveur, on ne peut plus faire tourner de connecteurs sur les serveurs pour importer les dernières factures, ça complique fortement les mécanismes de réplication qui nous servent pour les modes hors-ligne, etc. En gros, ça tue toutes les fonctionnalités de Cozy Cloud qui intéressent la plupart de nos utilisateurs. Peut-être que, dans quelques années, des avancées sur le chiffrement homomorphique ou les réseaux pair à pair nous offriront de nouvelles possibilités dans ce domaine, mais interdire tout accès aux données en clair sur nos serveurs (chiffrement en zero knowledge) n'est pas à l'ordre du jour sur le court/moyen terme.
[^] # Re: Chiffrement des données
Posté par bre75 . Évalué à 3.
Bonjour Bruno et merci pour votre réponse.
Juste pour être sure de bien saisir (je comprend vite mais il faut m'expliquer longtemps :) )
On peut donc assimilier ce chiffrage de disque à de l'encryption "at rest" ?
Quid si j'utilise un outil comme Cryptomator avant l'upload de mes fichiers sur Cozy ? Est-ce que du coup ça "perturbe" le service ?
[^] # Re: Chiffrement des données
Posté par Bruno Michel (site web personnel) . Évalué à 8.
Oui, on peut parler de chiffrement des données "at rest". Je n'aime pas trop cette notion car elle est assez floue, cf https://en.wikipedia.org/wiki/Data_at_Rest notamment. Si on prend la définition la plus commune, à savoir que les données "at rest" sont celles qui sont stockées physiquement sur un stockage persistant, le chiffrement des disques (y compris pour les serveurs qui servent aux sauvegardes) est bien un chiffrement des données "at rest".
Oui, ça va perturber certaines fonctionnalités. Par exemple, il ne sera pas possible d'afficher les fichiers chiffrés par Cryptomator dans l'interface web ou d'en faire des albums photos. Et dans l'autre sens, les fichiers importés par le cozy (connecteurs pour récupérer les factures, sauvegarde automatique des photos prises sur son smartphone) vont perturber le fonctionnement de Cryptomator. Je conseillerais de ne chiffrer avec Cryptomator qu'un sous-répertoire de Cozy, en faisant attention de mettre les fichiers sensibles dans ce sous-répertoire et de ne pas utiliser ce sous-répertoire pour les fichiers importés par les outils Cozy.
[^] # Re: Chiffrement des données
Posté par bre75 . Évalué à 1.
Promis ce sera ma dernière question sur le sujet :)
Peut-on rapprocher l'encryption du Cozy Drive à ce que Nextcloud fait avec son "Encryption App" ?
[^] # Re: Chiffrement des données
Posté par Bruno Michel (site web personnel) . Évalué à 3.
Désolé, je ne connais pas l'Encryption App de Nextcloud.
# A propos des accès aux banques
Posté par Eloi COUTANT . Évalué à 4.
Bonjour et bravo pour Cozy. Je n'ai pas encore testé car utilisant Nextcloud, mais c'est le genre d'outils très intéressants, notamment par son aspect gestion des comptes bancaires.
Par rapport à l'idée de se séparer de Linxo, connaissez-vous Weboob qui propose un outil en ligne de commande pour se connecter à des tas de sites dont ceux des banques ?
Je n'ai rien à voir avec ce projet et ne connais donc pas du tout la qualité du code fourni ou si c'est même intégrable dans Cozy, mais au moins les API ou les accès sont créés et ça peut être une bonne source d'inspiration pour les sites qui pourraient être supportés.
[^] # Re: A propos des accès aux banques
Posté par ComputingFroggy (site web personnel) . Évalué à 6.
Pour info, je pense que Linxo utilise weboob en tout cas ils sont contributeurs (de même que leur principal concurrent -ApiBudget- qui est le principal contributeur de boobank). De plus, weboob peut s'utiliser avec l'API.
[^] # Re: A propos des accès aux banques
Posté par Eloi COUTANT . Évalué à 3.
J'ignorais totalement cela, merci des précisions ! Du coup si les API sont disponibles, je me demande pourquoi Cozy est encore obligé de s'appuyer sur Linxo au lieu d'aller "à la source" (à part les ressources importantes qu'il faudrait déployer pour tout réimplémenter ;) ).
[^] # Re: A propos des accès aux banques
Posté par Bruno Michel (site web personnel) . Évalué à 10.
Nous avons passé pas mal de temps à évaluer les différentes approches possibles pour nous. En gros, il y en a quatre principales :
Et le choix est difficile. Linxo et Budget Insight offre pas mal de choses qui ne sont pas dans weboob :
Dans ce contexte, Weboob paraît être le pire choix pour les cozys hébergés chez sur notre infrastructure. Par contre, c'est une piste intéressante pour les auto-hébergés.
La piste que je trouve la plus intéressante est la dernière : développer nos propres connecteurs en JS. Ça permettrait notamment de les faire tourner ailleurs que sur nos serveurs : par exemple, dans le client desktop de cozy, dans une extension d'un navigateur web, etc. Et ça a pas mal de bonnes propriétés :
Ceci dit, il doit y avoir quelque chose comme 200 banques en France (moins si on regroupe les versions régionales d'un même groupe) et donc beaucoup de boulot pour en arriver là.
Pour commencer, on travaille actuellement sur la catégorisation bancaire. Et en attendant, on voulait quand même proposer l'application Banks et on passe par Linxo. C'est peut-être du temporaire ou c'est peut-être pour du long terme, ça va dépendre de nos réflexions et de la manière dont les banques vont s'adapter aux nouvelles réglementations (DSP 2 et GDPR). Si elles proposent des API propres avec de l'OAuth et sans délai, c'est sûr que ça va pas mal nous faciliter la vie.
[^] # Re: A propos des accès aux banques
Posté par Zenitram (site web personnel) . Évalué à 7.
Sympa… Donc weboob est inutilisable en pratique pour la partie banque du moins, sans devoir refaire le boulot (et si Budget Insight patche en retard alors qu'ils sont pote avec la majorité des dév, est-ce que nos patches seraient acceptés dans l'upstream si ils cassent les patches de Budget Insight à venir?), bon à savoir car ça rend le projet bien moins intéressant (perso je me disais que puisque Budget Insight l'utilisait, ça donnait une confiance sur le fait que ce soit à jour, bon non donc, pas incompatible avec l'open source mais le projet est moins intéressant par rapport à utiliser ou faire un autre logiciel), merci pour l'info, très utile pour se décider à utiliser puis contribuer, ou pas.
Business business…
+1, mais c'est beaucoup de taf à prévoir…
Alors la, vu leur réaction sur DSP 2, j'ai un doute qu'elles vous/nous aident à lâcher leur "monopole" sur les données qu'elles ont, du moins sans faire banquer un max…
[^] # Re: A propos des accès aux banques
Posté par Zenitram (site web personnel) . Évalué à 7.
Je m'auto-tempère, bien que un peu caché, le site weboob sous-entend que c'est un service achetable "We maintain the infrastructure and ensure that modules will always work within 2 days if there is a broken bank website.", et ça peut bien être un business model intéressant si on peut bien acheter cette partie (à un prix adéquat) à côté de tout le reste proposé.
http://weboob.com/bi
[^] # Re: A propos des accès aux banques
Posté par laurentb (site web personnel) . Évalué à 5.
Les quelques fois où c'est arrivé, le module BI a été publié à jour.
Ce qui est le plus dommageable à mon avis c'est qu'il y a très peu de contributeurs externes sur la partie banque. Mais ça se comprend car c'est un travail assez ingrat.
Note : je ne suis pas employé par BI et je trouve la situation actuelle loin d'être idéale.
[^] # Re: A propos des accès aux banques
Posté par laurentb (site web personnel) . Évalué à 5.
J'ajoute qu'il existe une association dont le but premier est de conserver l'indépendance de Weboob.
[^] # Re: A propos des accès aux banques
Posté par moules . Évalué à 10.
Il ne faut pas exagérer.
Budget Insight est un contributeur de weboob, et backport ses améliorations et correctifs. Le fait qu'il y ait un délai s'explique effectivement par le fait qu'une des valeurs ajoutée de Budget Insight est la réactivité, le fait que ses clients soient assurés d'avoir des connecteurs qui marchent. Nous avons une équipe de cinq personnes à plein temps qui bosse sur weboob, ça a un coût non négligeable.
Donc oui, on a pas intérêt à backporter trop vite. Néanmoins, il est arrivé à plusieurs reprises que je backporte immédiatement des correctifs ou des fonctionnalités à la demande d'utilisateurs sur IRC. Cela marche même encore mieux lorsque je rentre du bistro.
Maintenant, weboob compte d'autres contributeurs, incluant Linxo, et pour la plupart des gens, sur un usage domestique, les modules bancaires sont assez stables.
Je rajoute enfin que l'Association Weboob a été créée justement dans l'objectif de garantir une indépendance au projet. Budget Insight n'a pas le contrôle de weboob.
La DSP2 impose l'obtention d'un agrément auprès de l'ACPR ou d'une autre autorité bancaire nationale de l'Union Européenne, pour le statut d'AISP (Account Information Service Provider) ou PISP (Payment Initiation Service Provider), pour l'utilisation de ces APIs. Le législateur a complètement zappé le logiciel libre et de manière générale les logiciels desktops pour l'accès aux comptes.
La STET, un consortium bancaire français, a publié une spécification d'API qui sera implémentée par les banques d'ici juin 2019 :
https://www.stet.eu/assets/files/PSD2/API-DSP2-STET_V1.2.3_final.pdf
L'utilisation de ces APIs nécessitera l'utilisation d'un certificat client délivré par une autorité validée par le régulateur, et la présence sur un registre national de TPP.
[^] # Re: A propos des accès aux banques
Posté par Zenitram (site web personnel) . Évalué à 5. Dernière modification le 31 janvier 2018 à 13:31.
Ou est le bouton "Payer un coup à moules"? :)
Sinon, je comprend le business model, et vu que ensuite la partie indiquée sur le site weboob à ce sujet, j'y suis allé trop fort sur le premier message (je me suis corrigé pas longtemps après), je dirai juste que ça manque un peu de transparence à ce sujet sur le site weboob ("par ommission" sur la réactivité différente entre BI et le build public), mais c'est du détail.
[^] # Re: A propos des accès aux banques
Posté par BAud (site web personnel) . Évalué à 3.
tu peux le croiser de temps en temps au Hall's Beer (vers les Halles à Paris) et, si tu le fais un jeudi soir, tu pourrais faire un combo avec notre BB< national (Benjamin Bayart) autour de quelques bonnes Guinness.
Note : viens avec ton pote modération et évite de suivre sur chaque pinte1 bue ou alors assume le retour :-)
(1) unité de base :D
oui, publier ses développements n'est pas forcément immédiat quand il faut faire toute la non régression et l'adapter plus largement dans un logiciel libre…
Une discussion entre toi et moules< sur vos business models respectifs serait très intéressante àmha :D Entre les industriels à la râche alors que très standardisé (mais pas complètement…) et les banques qui pensent qu'Internet c'est comme un conseiller au téléphone (je caricature à peine…), ça devrait envoyer du lourd :p
[^] # Re: A propos des accès aux banques
Posté par Goffi (site web personnel, Mastodon) . Évalué à 4.
Et ils l'utilisent en production pendant ce temps donc ? Ça ne me semble pas très compatible avec l'AGPL cette histoire.
[^] # Re: A propos des accès aux banques
Posté par laurentb (site web personnel) . Évalué à 5. Dernière modification le 31 janvier 2018 à 15:03.
La (A)GPL n'oblige qu'à redistribuer le code aux utilisateurs, donc ici uniquement leur clients.
À ma connaissance il n'y a pas de licence qui oblige à distribuer son code au grand public.
[^] # Re: A propos des accès aux banques
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 31 janvier 2018 à 15:04.
le copyleft est souvent bidouillable, barrière artificielle contournable pour la plupart des besoins, c'est juste chiant.
J'imagine que la ils appellent une API weboob en web (oups :) ) donc séparation, donc l'AGPL ne s'applique pas à BI lui-même (qui consomme l'API donc lui peut demander le code, alors que les utilisateurs consomment que BI donc ne peuvent pas demander le code). Au pire un process intermédiaire qui stocke le résultat dans un fichier et BI ne fait que consommer le fichier, bref 36 solutions imaginables pour que ce soit compatible avec l'AGPL. Et au pire du pire tant que tu n'es pas client, ben tu consomme rien donc pas pour toi, et ça doit leur suffire comme délai de rétention possible.
Je ne crois pas un instant que tu puisses attaquer sur ce terrain.
[^] # Re: A propos des accès aux banques
Posté par moules . Évalué à 8.
L'AGPL force à redistribuer le code, mais n'impose pas à ce que ce soit immédiat ni que ce soit upstream. BI pourrait se contenter de ne rien redistribuer, et attendre qu'un utilisateur fasse la demande, pour envoyer un CD par la poste à l'utilisateur avec l'ensemble du code, pas de diff. Ça prendrait plus de temps que le délai que s'accorde BI pour reverser de jolis patches upstream.
[^] # Re: A propos des accès aux banques
Posté par El Titi . Évalué à 5.
Et pourquoi ne pas pousser vers une vraie API en promouvant les banques qui le supportent.
https://openbankproject.com
Une grande banque française s'y est mise, il me semble.
https://openbankproject.com/faq/#licenses
# Premier (petit) retour d'expérience
Posté par jclerc . Évalué à 10.
J'ai été très emballé de voir que Cozy avait sorti son produit pour le grand public, j'ai donc créé une instance cozy sur le site dédié et installé l'appli android. J'ai trouvé quelques petits problèmes de jeunesse (certains ont déjà été cités).
Cependant, je sais que vous avez tout refait et que ça va s'améliorer dans le temps.
Depuis sa sortie grand public, j'en parle autour de moi et j'en fais la promotion, mais pour mes amis ou collègues qui sont habitués à Dropbox, google drive et autres ou qui n'ont pas d'espace de type cloud, j'ai peur que cela soit difficile pour eux de venir sur Cozy et surtout d'y rester (dans un premier temps en tout cas).
N'avez vous pas lancé la sortie grand public quelques semaines trop tôt ?
Cette nouvelle mouture est plus agréable à utiliser, l'interface est simple et c'est très bien. Je vais tester les connecteurs, mais pour ça j'ai un cap psychologique à franchir je dois bien l'avouer.
Je suis content que les fichiers ne soit plus en BDD. C'est plus facile et plus rassurant lorsqu'on ne maîtrise pas une BDD de faire des sauvegardes et de la récupération de fichier.
Si j'ai bien compris seul les fichiers textes sont dans CouchDB ?
Est ce que vous recevez les messages que l'on envoie par le petit bouton "cozy cloud" en bas à droite ?
Je suis assez critique mais sache que je fais ce commentaire sans malveillance et je souhaite à Cozy le meilleur !
Dans tous les cas félicitation pour le travail accompli. Une petite startup française qui s'attaque à un gros morceau comme ça, ça fait plaisir ! C'est super de voir que ce projet avance.
[^] # Re: Premier (petit) retour d'expérience
Posté par Bruno Michel (site web personnel) . Évalué à 10.
C'est un choix assumé. Dans cozy v2, on avait pas mal d'applications, mais c'était surtout des démos, avec peu de fonctionnalité, pas mal de bugs et une interface pas toujours très réussie. Pour Cozy v3, on a préféré mettre l'accent sur la qualité et n'avoir que quelques applications, mais avec une expérience utilisateur aboutie et que l'on peut mettre dans les mains de personnes qui ne soient pas des spécialistes de l'informatique.
Je ne sais pas, c'est très subjectif. Pour certains, Cozy Cloud était déjà utilisable il y a quelques mois. Pour d'autres, l'absence des applications de gestion des contacts et calendriers est rédhibitoire. J'ai entendu plusieurs fois dans l'univers des start-ups que si on est à l'aise avec notre produit au moment du lancement, c'est que l'on a probablement trop attendu.
Par contre, il y a une certaine vérité derrière cela. La date était définie depuis quelques semaines et lors des derniers jours avant le lancement, on a voulu bien faire et mettre les bouchées doubles pour vraiment offrir le meilleur, mais ça s'est retourné contre nous. On a aussi introduit quelques régressions dans l'urgence. Le problème des miniatures pour les photos fait typiquement parti de cette dernière catégorie.
Oui, dans CouchDB, il n'y a que des données textuelles (du JSON pour être précis). Tous les fichiers que l'on peut voir dans son drive sont stockés en dehors de CouchDB. On conserve toutefois les meta-données des fichiers dans CouchDB, qui sert juste d'index.
Merci beaucoup !
# Dispo or not dispo ?
Posté par El Titi . Évalué à 2.
Sur votre site les screenshots sont encore taggués avec "Bientôt disponible"
https://cozy.io/fr/features/#bank
Alors dispo ou pas dispo ?
[^] # Re: Dispo or not dispo ?
Posté par Bruno Michel (site web personnel) . Évalué à 3.
C'est dispo.
Par contre, bizarre, normalement il n'y a des "Bientôt disponible" que pour les captures d'écran sur les remboursements de santé. Peut-être un problème de cache.
# Partage de fichiers entre clouds ☁
Posté par amdg . Évalué à 3.
La sortie de Cozy Cloud est une super nouvelle, je vais enfin pouvoir le recommander autour de moi !
Concernant le partage de fichiers et dossiers entre Cozy, pourquoi ne pas réutiliser le protocole de ownCloud/Nextcloud ? Ça permettrait plus d'interopérabilité entre les clouds open-source et vous n'auriez pas à développer un autre protocole.
De plus ça évite que Cozy soit un environnement fermé ! Je ne sais pas quels standard vous comptez utiliser pour la synchronisation des contacts et agenda, mais j'espère que ça sera dav, ça permettra de simplifier l'intégration de Cozy dans plein d'environnement !
Plus d'informations sur la fédération Nextcloud :
https://nextcloud.com/federation/
https://github.com/nextcloud/cloud_federation_api
[^] # Re: Partage de fichiers entre clouds ☁
Posté par Bruno Michel (site web personnel) . Évalué à 5.
Cool !
Sous la notion de partage, on peut retrouver beaucoup de choses : ça va de donner un accès en lecture à de la synchronisation bidirectionnelle.
Le protocole de partage d'ownCloud/NextCloud consiste à donner un accès en lecture/écriture sur certains répertoires/fichiers sur son cloud (via WebDAV, je crois) : si Alice partage un répertoire avec Bob, les fichiers de ce répertoire sont sur le cloud d'Alice mais pas sur cloud de Bob. Si Bob veut lire ou écrire dans un fichier de ce partage depuis une de ces applications, ça va aller faire une requête sur le cloud d'Alice. Ça veut dire que le jour où le cloud d'Alice est indisponible ou qu'Alice est révoqué le partage, Bob n'a plus accès à rien.
Une autre approche possible (et qui me semble mieux correspondre à Cozy) serait que Bob ait en permanence une copie des fichiers/données sur son cloud et que le répertoire partagé chez Alice et chez Bob soit synchronisé en tâche de fond.
Nous allons très certainement proposer du dav, mais ce n'est pas forcément par là que l'on va commencer. Les utilisateurs de smartphone sous android n'ont pas l'air très à l'aide avec ça : il faut installer une app tierce (DAVdroid par exemple) et ça demande une configuration pas évidente. Une idée serait que l'app mobile Cozy fasse la synchro et on irait plus rapidement en nous reposant sur le protocole de réplication de CouchBD/PouchDB. Rien n'est décidé à ce stade, ce sont des pistes de réflexion.
Dommage que le dépôt ne contient d'un fichier README de 3 lignes et une fichier LICENCE. Attendons la suite pour voir si c'est intéressant. J'ai peur que ce soit comme Open Cloud Mesh, une coquille vide avec quelques trucs très génériques mais qui ne sont pas suffisants en pratique pour faire du partage ou, au contraire, que ce soit très spécifique à NextCloud. Mais je ne demande qu'à être agréablement surpris !
[^] # Re: Partage de fichiers entre clouds ☁
Posté par voxdemonix . Évalué à 4.
Rien n'empêche l'utilisateur de le recopier.
L'avantage de ne pas importer les fichiers par défaut c'est d'éviter qu'un dossier partagé de 100Go se retrouve importé sur une petite installation de 10Go.
Ça permet aussi de créer un nœud uniquement pour les utilisateur (avec contactes, calendriers etc) tenant sur un nano-pc tout en permettant l'accès aux fichiers sur d'autres machines.
Il y a aussi la question de quid en cas de modification d'un fichier durant le transfert.
De plus certains mettent déjà en place des RAIDs locaux ou réseaux pour se protéger des pannes :)
Après en option cochable se serait une très bonne feature, mais en comportement par défaut ça peut vite s'avérer gourmand/capricieux.
Pour le moment la fédération couvre owncloud, nextcloud et pydio.
Perso je la trouve super prometteuse alors qu'on voit débarquer des extensions comme Talk et Mood qui permettent de s'attaquer au marché des réseaux sociaux sans nécessiter une application dédié et compliquée côté serveur.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.