Sortie de Hubzilla 2.6

Posté par . Édité par ZeroHeure, Pierre Jarillon, Davy Defaud, Benoît Sibaud et palm123. Modéré par ZeroHeure. Licence CC by-sa
25
21
août
2017
Internet

Né en 2012 sous le nom Redmatrix, Hubzilla renaît en 2015 comme un outil pour créer et relier des petits sites communautaires dans une grande communauté globale. Mais son histoire prend sa source dans Friendica, dans le Safeweb de Symantec, dans un CMS oublié et même dans le Collabra de Netscape.
Voilà pourquoi Hubzilla est une plate‐forme décentralisée de partage de contenu et de réseau social. Elle offre des facilités d’utilisation et d’identification et un socle très robuste pour des fonctions de réseau social (interopérable avec Diaspora, GNU-Social, Mastodon et gérant le chiffrement de bout en bout), de partage de fichiers et de photos (accessibles en WebDAV, à la Nextcloud / Owncloud), d’agenda et de serveur de calendrier CDAV, de carnet d’adresses et de serveur de contacts CardDAV et de wiki. De nombreuses extensions sont disponibles, du jeu d’échecs au partage de fichiers pair à pair via Webtorrent…

Hubzilla est publié sous licence MIT et programmé en PHP/MySQL avec prise en charge de PostgreSQL. La version 2.0 avait été publiée en décembre 2016 et n’avait pas fait l’objet d’une dépêche sur LinuxFr.org. Les principales fonctionnalités de la version 2.6 sont détaillées en seconde partie.

Facilités d’utilisation et d’identification

Identité nomade

Il est possibile de synchroniser plusieurs copies de son profil et de ses fichiers sur plusieurs serveurs, ou de migrer son profil sur un nouveau serveur, de manière transparente pour tous les autres utilisateurs et indépendante des DNS. C’est la fonctionnalité la plus forte de Hubzilla, rendant les utilisateurs libres vis‐à‐vis des administrateurs de serveurs, notamment en cas de rupture de service.

 Authentification magique

L’authentification est automatique sur tous les nœuds du réseau (type Single Sign On).

Groupes d’accès et listes de contrôle d’accès

La gestion des groupes d’accès et des listes de contrôle d’accès est compatible avec les fonctionnalités précédentes, et à maille fine pour garder un contrôle aussi fin que possible sur ses données.
logo hubzilla

Les grands changements de cette version

Cette version marque une évolution décisive dans la gestion des passerelles vers les autres réseaux (principalement Diaspora et GNU-social / Mastodon). Voici un résumé des changements les plus importants.

Changements fondamentaux dans les mécanismes de fédération avec des services externes

Il n’y a à présent plus besoin d’avoir plusieurs rôles de serveur pour communiquer avec des réseaux séparés. Il n’y a plus qu’un seul rôle de serveur (« pro ») qui consolide les fonctionnalités de tous les autres. Note : en conséquence, les « niveaux techniques » sont maintenant disponibles pour tous les serveurs. Si vous trouvez l’interface et le choix de fonctionnalités trop simples à votre goût ou pour vos besoins, rendez‐vous dans vos paramètres de compte et adaptez le niveau technique jusqu’à ce qu’il vous convienne.

Révision des connecteurs pour la fédération

Les connecteurs pour la fédération ont été complètement revus. Le protocole de fédération Diaspora V2 a été implémenté et d’important nettoyage du greffon du protocole Diaspora ont été effectué. La compatibilité avec GNU-Social et Mastodon a été grandement améliorée et une fonctionnalité « récupérer les conversations » a été ajoutée pour tenter de localiser les références contextuelles manquantes et conserver les conversations pour les messages de ces réseaux. De plus, un connecteur pour le protocole ActivityPub est en cours de réalisation.

Possibilité de réorganiser les applications dans le menu des applications

De nombreux changements aussi dans le menu des applications et la barre de navigation ont été effectués pour améliorer l’ergonomie générale.

Mécanisme de partage de fichiers amélioré

Le partage de fichiers a également fait l’objet d’améliorations.

Sélection automatique de la langue

La langue est automatiquement sélectionnée pour l’aide, les pages Web et le contenu des wikis pour les usages multilingues.

Passage des tables MySQL en utf8mb4

Pour les nouvelles installations MySQL l’encodage des caractères est à présent en Unicode complet utf8mb4 afin de gérer parfaitement les émoticônes et les langues asiatiques.

 Recherche textuelle améliorée

La recherche textuelle inclut maintenant les pages Web auxquelles vous avez accès. Les recherches par étiquette (« tag ») et par catégorie acceptent les jokers (« * »).

Coloration syntaxique

Le code réalisant la coloration syntaxique des blocs de code a été déplacé dans un greffon. Sans ce greffon un bloc de code normal sera affiché.

Corrections de bogues de synchronisation

Des problèmes de synchronisations des photos et fichiers vers les clones ont été identifiés et corrigés.

Gestion du téléversement des gros fichiers

Il est désormais possible de téléverser de grands fichiers (comme des vidéos) directement dans les conversations. Il y avait des limitations liées à la mémoire disponible auparavant.

Gestion des commentaires publics

Les canaux (l’identité de base dans Hubzilla) acceptent les commentaires publics de personnes non enregistrées (comme sous Wordpress).

Transfert des greffons CalDAV/CardDAV au cœur du serveur

Le code des greffons CalDAV/CardDAV a été transféré vers le cœur du serveur afin de faciliter l’intégration avec le calendrier et le carnet d’adresses intégrés.

Mise à jour de Bootstrap

C’est la version 4 bêta de Bootstrap qui est à présent utilisée.

Installateur amélioré

Le programme d’installation a également fait l’objet de quelques améliorations.

Pour la liste complète des nouveautés voyez le journal des modifications.

Appel aux traducteurs francophones

Le projet manque de traducteurs francophones, notamment pour les pages d’aide, qui ne sont pas gérées sous Transifex (outil de traduction en ligne pour les applications basées sur gettext). La traduction française de l’interface (hors aide en ligne) a été mise à jour dans Transifex, mais au moment de la rédaction n’a pas encore été intégrée dans GitHub. Cela devrait être fait dans les heures ou jours qui viennent.

  • # Identité nomade

    Posté par (page perso) . Évalué à 4 (+2/-0).

    C'est un projet très intéressant, et un que je n'ai pas encore testé moi même bien que j'en entende parler depuis plusieurs années. Je viens de regarder la démo vite fait, c'est complet.

    Au sujet de l'identité nomade, je me pose plusieurs questions :

    • comment contacte-t-on quelqu'un qui peut être sur n'importe quel serveur ? Il y a un hash ou quelque chose compliqué, ou une astuce ?
    • je suppose que oui mais je demande par acquis de conscience : les données sont chiffrées en cas de duplication ? Si je mets une identité sur plusieurs serveurs, ça ne veut pas dire que tous les admins de ces serveurs ont accès à mon nom, ma liste de contacts, mes messages, etc ?
    • du coup si les admins n'ont pas accès (ce que je suppose), est-il possible de dire qu'on ne veut pas de quelqu'un ?
    • quid de la place aussi, est-ce que dupliquer une identité ça prend beaucoup de place ? Si j'ai des albums photos, des vidéos, etc., est-ce qu'ils me suivent ?

    D'autre part, est-ce qu'on a une idée du nombre d'utilisateurs ? Est-ce qu'il y a un modèle économique ? Comment c'est développé (prise de décisions) et par qui ?

    Bon courage, il faudra que je prenne le temps de regarder ça de plus près un jour.

    • [^] # Re: Identité nomade

      Posté par (page perso) . Évalué à 4 (+2/-0).

      Je ne suis pas utilisateur et je ne connais pas assez bien le projet pour répondre à la plupart des questions, mais sur celle-là :

      D'autre part, est-ce qu'on a une idée du nombre d'utilisateurs ?

      ce que je peux dire est que Hubzilla représente environ 6% des nœuds connus de ma propre instance Friendica (128 nœuds sur 2244, précisément). Évidemment, ce n’est pas forcément représentatif de l’ensemble de la Fédération, c’est seulement ce que voit mon serveur…

      Pour information, la Fédération vue depuis mon serveur, c’est précisément :

      • 322 instances Friendica (~14%)
      • 221 instances Dispora (~10%)
      • 21 instances Redmatrix (~1%)
      • 128 instances Hubzilla (~6%)
      • 181 instances GNU Social (~8%)
      • 14 instances StatusNet (~1%)
      • 1357 instances Mastodon (~60%)
    • [^] # Re: Identité nomade

      Posté par . Évalué à 6 (+5/-0).

      Merci aux modos pour la passe de rédaction / mise en forme complémentaire !

      Comment contacte-t-on quelqu'un qui peut être sur n'importe quel serveur ? Il y a un hash ou quelque chose compliqué, ou une astuce ?

      Un "canal" est identifié par sa clé privée. Cloner un canal revient à copier la clé privée sur un autre serveur et à ajouter la nouvelle adresse à la liste des clones du canal, qui est envoyée à chaque contact.

      Je suppose que oui mais je demande par acquis de conscience : les données sont chiffrées en cas de duplication ? Si je mets une identité sur plusieurs serveurs, ça ne veut pas dire que tous les admins de ces serveurs ont accès à mon nom, ma liste de contacts, mes messages, etc ?

      Tous les transferts entre serveurs se font de manière chiffrée. En revanche sur les serveurs les admins ont par définition accès à toutes les données, chiffrées ou non, et aux clés de déchiffrement (clés privés) qui sont stockées en base. En ce sens la distinction chiffré/non chiffré a peu de sens vis-à-vis des admins. Finalement seuls les messages chiffrés de bout en bout échappent à cette règle. Ils sont stockés chiffrés, sans la clé. La clé de chiffrement doit être rentrée à la main dans le navigateur pour déchiffrer chaque message. Avoir confiance en l'admin est globalement un postulat de Hubzilla. Mais ceci est vrai pour tous les systèmes ne généralisant pas le chiffrement de bout en bout.

      Du coup si les admins n'ont pas accès (ce que je suppose), est-il possible de dire qu'on ne veut pas de quelqu'un ?

      Chaque administrateur de hub peut choisir le mode d'inscription à son hub. Sur un de mes hubs je n'ai qu'un compte : le mien. J'ai activé l'option pour valider explicitement toute nouvelle inscription, pour le cas où je voudrais ouvrir un compte à des amis ou de la famille, ou autoriser à créer un clone sur mon hub.

      Et bien sûr j'interagis avec tous les hubs de manière transparente, comme si les autres utilisateurs étaient hébergés sur mon serveur (principe de la décentralisation). Seule nuance : le partage de fichiers entre utilisateurs. Autant mes propres fichiers sont clonés entre les serveurs sur lesquels j'ai décidé de répliquer mon canal ou mes canaux, autant le partage de fichiers tire profit du SSO et des ACL : à partir de mon canal "toto@titi.org", je peux donner accès au fichier "chaton.mp4" à "bidule@tata.be", en lecture seule, lecture/écriture… Ainsi je n'ai pas besoin de transférer mon fichier, "bidule@tata.be" se connecte directement en SSO à mon fichier. Je garde ainsi le contrôle si je veut un jour modifier les accès ou supprimer le fichier.

      Quid de la place aussi, est-ce que dupliquer une identité ça prend beaucoup de place ? Si j'ai des albums photos, des vidéos, etc., est-ce qu'ils me suivent ?

      Tout suit par défaut. Ca fait longtemps que je n'ai pas créer de clone, il faut que je vérifie si on peut choisir de ne cloner que la partie "données en base".

      • [^] # Re: Identité nomade

        Posté par . Évalué à 3 (+8/-2). Dernière modification le 21/08/17 à 19:21.

        [ accessibilité de la clé privée d'un utilisateur final aux administrateurs des serveurs Hubzilla sur lesquels son identité est dupliquée ]

        Je n'ai aucune pratique de Hubzilla. J'ai lu attentivement la dépêche et les commentaires.

        Dans le cadre de la question de la duplication d'identité sur plusieurs serveur Hubzilla, tu décris le principe du stockage en base de données, sur ces serveurs, des clés de chiffrement privées [des utilisateurs finaux], rendues ainsi accessibles à leurs administrateurs.

        /* Pour référence, je te cite :

        Tous les transferts entre serveurs se font de manière chiffrée. En revanche sur les serveurs les admins ont par définition accès à toutes les données, chiffrées ou non, et aux clés de déchiffrement (clés privés) qui sont stockées en base.

        */

        Or, jusqu'à maintenant, je comprenais qu'une clé privée a vocation à le rester et qu'elle permet à l'utilisateur d'une part de signer numériquement un fichier pour l'authentifier [par chiffrement asymétrique du condensat du fichier avec ladite clé privée], d'autre part de déchiffrer un message [qui est chiffré avec sa clé publique] lui étant destiné. Qu'en est-il avec Hubzilla ?


        Pour appuyer les assertions de ce dernier paragraphe et à titre pédagogique pour les lecteurs, je renvoie à ces explications didactiques de mon cru :

        • la dépêche GPG - les concepts en clair et pédagogiquement qui décrit les bases du fonctionnement de GPG, du chiffrement asymétrique et de l'authentification avec un couple de clé privée/publique ;
        • un organigramme détaillant plus profondément le fonctionnement de GPG pour le chiffrement et l'authentification ;
        • un commentaire donnant des explications détaillées de cet organigramme (cliquer sur le # dans l'en-tête de ce commentaire pour retrouver le contexte et accéder aux commentaires imbriqués donnant des informations supplémentaires).

        Le premier des trois liens suffit à comprendre l'essentiel. Les deux derniers contenus sont nécessaires pour comprendre en quoi la signature numérique est un chiffrement asymétrique du condensat du fichier [par la] clé privée.

        • [^] # Re: Identité nomade

          Posté par . Évalué à 2 (+1/-0).

          La clé privée du canal est utilisée principalement pour l'authentifier auprès des autres canaux indépendamment des DNS. C'est la clé de voûte de l'identité nomade. Elle n'est utilisée pour chiffrer que dans le cas des messages privés de canal à canal (une des applications de Hubzilla). Il ne s'agit pas dans ce cas de chiffrement de bout en bout, la clé étant stockée sur les serveurs. Les autres types de messages quant à eux sont chiffrés en SSL avec les clés des serveurs uniquement. Si la charge utile est un message chiffré côté client, on a un chiffrement de bout en bout.

          • [^] # Re: Identité nomade

            Posté par . Évalué à 1 (+6/-2).

            De mon point de vue, si la clé de voute de l'identité nomade est la clé privée d'un canal (un canal étant attaché à une identité d'utilisateur, tel que je le comprends), qui est en la possession de tous les serveurs Hubzilla sur lesquels les informations identifiant ledit canal sont répliquées, alors le risque apparaît d'une usurpation d'identité par au moins un de ces serveurs qui serait malveillant.

            L'usurpation n'est plus possible par malveillance d'un quelconque serveur Hubzilla si l'authentification est produite par une clé privée que seul l'utilisateur final possède.

            Le principe que tu décris permet :

            • d'éviter de faire porter la moindre parcelle de confiance sur les DNS pour identifier un serveur Hubzilla et donc authentifier un canal (annulation du risque lié aux DNS menteurs) ;
            • de favoriser l'authenticité, sans la garantir, dans le cas des messages non authentifiés intrinsèquement des utilisateurs finaux.

            Pour limiter le biais lié à la possible malveillance d'un serveur Hubzilla, il me semble opportun que la clé de voute de l'identité nomade soit, au choix :

            • la nécessaire authentification cryptographique intrinsèque à chaque message transitant, liée à la clé privée de l'utilisateur final (contraignant pour l'utilisateur qui doit disposer de sa clé privée et en faire usage) ;
            • la combinaison de l'authentification systématique d'un canal (limitant le risque d'usurpation) et l'incitation des utilisateurs à signer numériquement chacun de leurs messages importants.
            • [^] # Re: Identité nomade

              Posté par . Évalué à 2 (+1/-0).

              La clé privée n'est répliquée que dans le cas du clonage, qui est un mécanisme de redondance global des informations d'un canal entre les serveurs choisis par le propriétaire dudit canal. On peut très bien n'héberger son canal que sur un ou des serveurs à soi, sans divulguer la clé privée à qui que ce soit. Seule la clé publique est diffusée aux contacts/amis. La clé privée est utilisée pour signer tous les envois mais pas systématiquement pour le chiffrement.

              • [^] # Re: Identité nomade

                Posté par . Évalué à 2 (+7/-2).

                Ok.

                Ainsi, celui qui administre son propre serveur Hubzilla et y créer son propre canal — s'abstenant de cloner ledit canal sur un quelconque autre serveur Hubzilla — se garantit une authentification systématique et sous son contrôle.

                Celui, par contre, qui crée son canal sur un serveur Hubzilla administré par un tiers, obtient une authentification systématique de ses messages via ce tiers — où via d'autres serveurs Hubzilla sur lesquels il aurait cloné son canal — authentification qui n'est pas sous son contrôle et peut faire l'objet d'un détournement par un serveur Hubzilla malveillant. Celui-là, s'il veut une garantie accrue que les messages qui lui sont attribués soient authentiquement de son fait, a intérêt à signer systématiquement chacun de ses messages avec une clé privée qui lui est propre.

                A partir de cette dernière considération, je formule l'idée que Hubzilla promeuve l'authentification de bout en bout pour les utilisateurs qui ont un besoin accru de confiance. Cette promotion d'un usage approprié pourrait être implémentée directement dans l'interface utilisateur, activée par défaut et désactivable dans l'écran de configuration par celui qui maitrise son propre serveur ou qui n'exige pas le plus haut niveau de confiance.

                • [^] # Re: Identité nomade

                  Posté par . Évalué à 4 (+3/-0).

                  Pour ce cas d'usage il y a les réseaux P2P comme retroshare. Hubzilla fait le choix de tourner sur un serveur afin de rendre les données disponibles et synchronisables même quand le poste client de l'utilisateur est éteint. Le projet postule raisonnablement que l'on peut avoir confiance en l'administrateur du serveur, au besoin en administrant son propre serveur. Le cas d'usage est de partager des messages et plus généralement des données avec sa famille, ses amis, ses communautés, sans être soumis à la surveillance de masse des états et des multinationales d'internet et à la pub.

                  Cela exclut le cas d'une surveillance ciblée, où les attaquants bien financés auront plus vite fait d'exploiter un zero day ou une backdoor de chipset intel indétectable par l'OS pour installer un keylogger et contourner ainsi tout chiffrement, voire de poser des mouchards physiques au domicile de la personne surveillée.

                  Bref, pour les problématiques de vie ou de mort type dissidence politique ou militantisme radical au sein d'un pays soumis à la censure et à la dictature, Hubzilla n'est pas recommandé et ne cherche pas à pouvoir l'être.

                  Hubzilla reste plus sûr et plus polyvalent que Diaspora ou Mastodon du fait de l'identité nomade : si on ne veut pas cloner son canal on peut en faire un export json local, et en cas de rupture de service du serveur qui hébergeait le canal charger cet export sur un autre serveur. Les cas de serveurs "tombant" pendant des semaines ou des mois ou fermant définitivement ne sont pas anecdotiques, sur n'importe quel réseau social décentralisé. Hubzilla permet une résilience complète vis-à-vis de ce problème, et offre des fonctionnalités supplémentaires de CMS, de CDAV, CardDAV, WebDAV que les autres ne proposent pas.

                  • [^] # Re: Identité nomade

                    Posté par . Évalué à 0 (+5/-2). Dernière modification le 22/08/17 à 19:25.

                    Hubzilla fait le choix de tourner sur un serveur afin de rendre les données disponibles et synchronisables même quand le poste client de l'utilisateur est éteint.

                    Soit, mais le principe de rendre les données disponibles et synchronisables — avec le poste client de l'utilisateur éteint — est compatible avec une authentification de bout en bout…

                    Le cas d'usage est de partager des messages et plus généralement des données avec sa famille, ses amis, ses communautés, sans être soumis à la surveillance de masse des états et des multinationales d'internet et à la pub.

                    Si l'objectif est de se soustraire à la surveillance de masse, il me semble qu'il serait profitable de systématiser le chiffrement de bout en bout, non pas de le proposer comme une option. Disons qu'actuellement, l'objectif est de permettre de se soustraire à la surveillance de masse (et en attirant l'attention si le chiffrement est minoritairement utilisé pour les échanges entre utilisateurs).

                    En promouvant l'authentification de bout en bout, tu permettrais aux gens de se soustraire plus sérieusement à l'usurpation d'identité (du moins l'usurpation réalisée à bas coût, car exploiter des portes dérobées matérielles sur les postes clients des utilisateurs finaux reste là aussi possible, voir plus bas) et ainsi, pourquoi pas, à des phénomènes de manipulation de masse qui pourraient au moins se manifester à des occasions exceptionnelles (déclenchement de manipulations psychologiques de masse à l'occasion de "révolutions colorées", par exemple). Dans de tels cas, les attaquants sont typiquement indifférents aux conséquences de la prise de conscience de la manipulation, en terme de changement de code par les développeurs et/ou d'usage par les utilisateurs, car l'effet recherché est de toute façon obtenu, par exemple le changement politique réalisé.

                    Cela exclut le cas d'une surveillance ciblée, où les attaquants bien financés auront plus vite fait d'exploiter un zero day ou une backdoor de chipset intel indétectable par l'OS pour installer un keylogger et contourner ainsi tout chiffrement, voire de poser des mouchards physiques au domicile de la personne surveillée.

                    Bien vu… De l'intérêt du matériel authentiquement libre (selon mon choix de dénomination), c'est à dire jusque dans le schéma de gravure des puces, audité, faisant idéalement l'objet de preuves formelles et fabriqué et distribué sous supervision communautaire (1).

                    Hubzilla reste plus sûr et plus polyvalent que Diaspora ou Mastodon du fait de l'identité nomade : si on ne veut pas cloner son canal on peut en faire un export json local, et en cas de rupture de service du serveur qui hébergeait le canal charger cet export sur un autre serveur. Les cas de serveurs "tombant" pendant des semaines ou des mois ou fermant définitivement ne sont pas anecdotiques, sur n'importe quel réseau social décentralisé. Hubzilla permet une résilience complète vis-à-vis de ce problème […]

                    Je connais mal la problématique pour les autres projets mais je la découvre sous ta plume. Il me semble qu'il serait opportun pour ces autres projets d'implémenter le concept d'identité nomade, ou au moins de promouvoir et faciliter la sauvegarde chiffrée des informations afférentes à l'identité sur d'autres instances que sa propre machine client pour l'utilisateur final, de manière à pouvoir continuer à fonctionner (au moins en environnement dégradé) moyennant l'usage d'une clé privée pour déchiffrer et remettre en oeuvre l'identité restaurée.

                    Merci pour ces échanges, Papey<.

                    (1) cf. cette dépêche en cours de rédaction (lien non pérenne accessible aux utilisateurs ayant un compte et connectés), titrée « Malveillances matérielles furtives et stratégies pour du matériel libre de confiance », entamée fin 2016 (et pour l'instant laissée en plan depuis février 2017 après de gros efforts).

                    • [^] # Re: Identité nomade

                      Posté par . Évalué à 4 (+3/-0).

                      Toujours un plaisir d'échanger :-)

                      Le chiffrement de bout en bout empêche toute fonctionnalité de recherche et d'indexation par mots-clés, qui permettent de retrouver/regrouper des messages dispersés parlant d'un même sujet. Au final cela nuit quand même au partage et à la collaboration, même si cela apporte un gain (jamais absolu) en termes de sécurité. C'est une question de position de curseur au final.

      • [^] # Re: Identité nomade

        Posté par . Évalué à 2 (+1/-0).

        En complément, un canal est identifié par son ZID (identifiant Zot) de la forme bli@blo.xx. Ceci permet d'utiliser une sorte de webfinger sur le serveur blo.xx afin d'obtenir la clé publique associée au canal et la liste des clones éventuels.

    • [^] # Re: Identité nomade

      Posté par . Évalué à 0 (+0/-0).

      Je donne quelques réponses pour la confidentialité des données. Evidement l'admin du serveur peut tout voir sur nos données. Il faut faire confiance à l'admin ou bien s'autohéberger.
      En cas de synchronisation, beaucoup de données sont synchronisées et certaines sont en clair dans la base de donnée.

      A part cela, c'est quand même un outil qui va trés loin dans le sécurité, la confidentialité et l'anonymat.

      Ce que je note sur les derniers changements c'est

      • l'implémentation de ActivityPub : c'est le premier a le faire. Je fais confiance au dev qui le dit car je n'ai pas testé. Mastodon est en train de l'implémenté, gnusocial aussi et d'autres vont suivre. C'est le futur standard.

      • On peut partager avec un simple lien un peu à la manière de nextcloud pour nos contacts qui n'ont pas de compte. Trés utile car qui a un compte hubzilla ou même mastodon ? Trop peu de monde. Moi je l'utilise pour partager des photos avec ma famille. De façon publique ces photos ne sont pas visibles mais avec un lien spécial oui. C'est un bon compromis entre facilité et hyper sécurité.

  • # Noms des fichiers avec des caractères spéciaux

    Posté par (page perso) . Évalué à 6 (+4/-0).

    J'apprécie que le nom des fichiers avec des caractères spéciaux ne soient pas tronqués. Si j'envoie un fichier avec des caractères chinois dans le nom, il est renvoyé tel quel dans l'url quand on voudra y accéder plus tard.

    C'est assez rare pour être souligné.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.