Autoblog de sebsauvage.net

Ce site n'est pas le site officiel de sebsauvage.net
C'est un blog automatisé qui réplique les articles de sebsauvage.net

Le W3C entérine les DRM

jeudi 3 octobre 2013 à 12:09

Voilà. Le W3C continue sa poussée en intégrant officiellement le draft de norme sur les DRM dans le groupe de travail HTML. Le draft s'appelle EME (Encrypted Media Extensions): http://www.w3.org/TR/encrypted-media/. C'est une API permettant de standardiser l'interfaçage des navigateurs et des systèmes de DRM. Dans la pratique, vous ne pourrez pas enregistrer les vidéos. Le navigateur passera le contenu chiffré au module DRM qui se chargera de décoder les trames.

Histoire de bien foutre le bordel: Notez que ce standard n'impose pas un système de DRM particulier, mais juste une API. Ce qui veut dire que chacun va se fendre de son petit système de DRM, qui sera différent d'un vendeur à l'autre, d'un système d’exploitation à l'autre, d'un site à l'autre, d'un navigateur à l'autre. De quoi - en plus d'être emmerdé par les DRM - morceler un peu plus le web. Vous trouviez que c'était déjà le bordel entre MPEG4, WebM/VP8, OGG/Theora, MP3 et Vorbis ? Vous n'avez encore rien vu. Le plus beau, c'est que ça n'empêchera même pas le piratage des œuvres. (C'est pas comme si la TOTALITÉ des DRM existants avaient été cassés, hein ?).


Certes, cette norme est uniquement orientée vidéo, mais après la vidéo, que croyez-vous qu'il va se passer ? Il y a plein de monde qui attend à la porte pour avoir sa petite couette confortable de DRM: Les photographes pour empêcher la "copie" de leurs photos, les maisons de disque pour restreindre l'écoute, les agences de presse et maisons d'édition pour empêcher le vilain copier-coller, les webmasters neuneus pour "protéger" leur code HTML/javascript.

Vous croyez que je plaisante concernant le code HTML et javascript ? Pas du tout: Il y a déjà un groupe de travail au W3C sur le sujet. Imaginez un monde où votre navigateur ne va plus exclusivement vous obéir, mais va - sur certaines de ses fonctions - obéir à des tiers. Imaginez le jour où vous ne pourrez même plus enregistrer une image ou voir le code source d'une page HTML. (Si ça se réalise, je présume que ces restrictions concerneront également les extensions pour navigateurs, ce qui les empêcherait d'accéder au contenu de la page... oh regardez, POUF, plus de vilain AdBlockPlus qui vient nous arracher le pain de la bouche, la vie est bêêêêêllle !). Les membres du W3C sont déjà en train d'y réfléchir.

Voilà comment je vois le web de demain: Les géants du Minitel 2.0 proposeront ça dans leurs services (par exemple une option dans YouTube pour empêcher l'enregistrement des vidéos, ou chez Flickr pour empêcher la copie des photos (spaceballs !(1)). Et je présume que si votre navigateur n'est pas EME-compliant, vous ne pourrez pas lire ces vidéos ou voir ces photos. Soit vous acceptez les DRM, soit une partie du web ne vous sera plus accessible. Et comme ça sera W3C-compliant, ils pourront vous jeter avec dédain avec la bonne conscience d'avoir respecté les normes officielles du ouèbe. En intégrant EME au sein du groupe de travail HTML, c'est la voie dans laquelle s'est engagé le W3C.


Le W3C n’œuvre plus exclusivement pour un web ouvert. C'est terminé. Je pense que l'ouverture du web, l'interopérabilité, est condamnée à moyen terme. Vous vous demandez comment, comment le W3C a pu accepter ça ? C'est simple: regardez la liste de ses membres.
Bien plus criant: Regardez qui sont les éditeurs de cette nouvelle norme du W3C: David Dorwin (Google), Adrian Bateman (Microsoft), Mark Watson (Netflix). Vous leur faites vraiment confiance pour œuvrer pour le bien de tous ?

C'est triste, mais il est temps de prendre du recul par rapport au W3C. Quand il était encore jeune, internet n'était pas un tel enjeu économique et le W3C remplissait alors bien son rôle. Maintenant qu'internet est un lieu où se brassent des sommes absolument colossales, les membres du W3C ont des intérêts commerciaux bien trop importants et ils ne se gênent plus pour pousser le W3C dans la direction qui arrange leur business. En même temps, à quoi je m'attendais, franchement ?

Vous croyez que je vois tout en noir ? L'avenir nous le dira. Si j'ai raison, alors le web du futur pue des pieds. (Voilà, ça c'était pour les petits mots grivois de circonstance.)



Mise à jour 15 janvier 2013: Complément: La MPAA rejoint le W3C. Les spécifications qui ont abouti à la norme EME sont secrètes.




(1) L'allusion n'est pas facile à comprendre si vous n'avez jamais plongé dans le code HTML des pages de Flickr.

Source : http://sebsauvage.net/rhaa/index.php?2013/10/03/10/09/24-le-w3c-enterine-les-drm


Chers sites web soit-disant «sociaux»

jeudi 8 août 2013 à 11:04

Votre slogan est «Partager», mais vous ne voulez pas vraiment qu'on partage. Vous voulez nous garder à l'intérieur de votre cage dorée. C'est pour cela que vous avez passé votre temps à retirer de vos pages les liens vers les flux RSS, les cachant au fin-fond de votre site, ou les supprimant purement et simplement, en les remplaçant par des API propriétaires rabougries ou démentielles. ET BIEN MERDE.

Vous n'êtes pas "social" quand vous entravez le partage en retirant RSS. Vous êtes heureux de voir vos utilisateurs créer du contenu pour votre écosystème, mais vous ne voulez pas voir ce contenu sortir de chez vous - un contenu qui ne vous appartient même pas. Google Takeout est juste de la poudre aux yeux. Nous voulons que les données circulent, nous voulons RSS.

Nous voulons partager avec nos amis, en utilisant des protocoles ouverts: RSS, XMPP, peu importe. Parce que personne ne veut qu'on lui fourgue de force votre service avec votre application utilisant votre API. Les amis devraient pouvoir choisir les logiciels et services qu'ils veulent.

Nous sommes en train de reconstruire les ponts que vous avez volontairement détruits.

Sortez-vous les doigts du cul: Remettez RSS en place.


(Le même article en anglais .)

Source : http://sebsauvage.net/rhaa/index.php?2013/08/08/09/04/29-chers-sites-web-soit-disant-sociaux-


Dear so-called «social» websites

jeudi 8 août 2013 à 10:51

Your catchword is «share», but you don't want us to share. You want to keep us within your walled gardens. That's why you've been removing RSS links from webpages, hiding them deep on your website, or removed RSS entirely, replacing it with crippled or demented proprietary API. FUCK YOU.

You're not social when you hamper sharing by removing RSS. You're happy to have customers create content for your ecosystem, but you don't want this content out - a content you do not even own. Google Takeout is just a gimmick. We want our data to flow, we want RSS.

We want to share with friends, using open protocols: RSS, XMPP, whatever. Because no one wants to have your service with your applications using your API forced-feeded to them. Friends must be free to choose whatever software and service they want.

We are rebuilding bridges your have wilfully destroyed.

Get your shit together: Put RSS back in.


(Same article in French here.)

Source : http://sebsauvage.net/rhaa/index.php?2013/08/08/08/51/28-dear-so-called-social-websites


Grosses images et petits débits

mardi 30 juillet 2013 à 16:35

Je suis issu d'une époque pré-ADSL où le top de la vitesse était le modem 56K. Soit environ 5 kilo-octets par seconde. Forcément, ça laisse des traces, comme cette obsession maladive d'optimiser les images. Je ne parlerai pas ici d'optimisation de la taille de vos fichiers JPEG (que ce soit en diminuant la résolution ou en jouant avec le pourcentage de qualité JPEG ; Il y a des outils pour ça). Je vais parler ici d'astuces pour donner l'impression que la page se charge plus vite.

L'astuce du pauvre

A l'époque des modems RTC, il était courant pour les pages web d'ajouter un attribut "lowsrc" aux balises images. L'attribut lowsrc est identique à src, mais pointe sur une image très basse résolution (généralement une image de moins de 10 ko). Exemple:

⋖img lowsrc="http://www.sebsauvage.net/rhaa/chaton-low.jpg" src="http://www.sebsauvage.net/rhaa/chaton.jpg" width="1024" height="768">

Le navigateur ayant chargé rapidement la petite image spécifiée dans lowsrc, il affichait immédiatement la page, même si les images pleine résolution n'avaient même pas commencé à se charger (Bien sûr, n'oubliez jamais d'indiquer en complément width et height, hein ?). Certes cela faisait au final plus de données à télécharger, mais la page s'affichait malgré tout plus vite.

C'est tout l'intérêt de la vitesse perceptive par rapport à la vitesse effective. C'est purement psychologique, et vous voulez que l'internaute ai l'impression que la page se charge vite.

De nos jours, ce n'est plus trop utilisé. D'abord parce qu'on a des débits de folie, mais aussi parce qu'on a désormais le JPEG progressif.

L'astuce du riche

La particularité du JPEG progressif est que l'image est entièrement affichable même si on a reçu que 3% du fichier. L'image s'affiche alors immédiatement en entier, et se raffine peu à peu.

Message subliminal:

CONVERTISSEZ TOUS VOS JPEG EN PROGRESSIF S'ILS DOIVENT ÊTRE PUBLIÉS DANS UNE PAGE WEB.

Non vraiment j'insiste. Le JPEG progressif c'est bon, mangez-en. Dès que votre JPEG dépasse 10 ko, convertissez-le en progressif. Il n'y a aucune perte de qualité et le fichier sera plus petit (dans la majorité des cas).


Voici ce que donne le chargement d'un JPEG standard (non-progressif):


5,2 ko chargé (3%)

16 ko chargé (9 %)

108 ko chargé (60 %)


Et la même chose en JPEG progressif:


5,2 ko chargé (3 %)

16 ko chargé (9 %)

108 ko chargé (60 %)

Du coup, avec toutes les images en JPEG progressif, le navigateur peut très rapidement calculer et afficher la page, même si votre joli JPEG de 2 Mo n'est pas encore chargé en entier. Toutes vos pages donneront l'impression de se charger plus vite, et ce, sans manipulation supplémentaire dans votre page (ni au niveau du code html, ni au niveau du javascript).

Le second effet kiss-cool, c'est que pour une même qualité JPEG, le progressif est généralement plus petit (Dans notre cas: 183 260 octets pour le standard, 176 202 octets pour le progressif, pour une qualité d'image strictement identique).

Le troisième effet kiss-cool que j'ai constaté (corrigez-moi si je me trompe), c'est que certaines LightBox javascript semblent obtenir plus rapidement la taille de l'image, et affichent donc plus rapidement les images dans les galeries (comme la mienne). C'est tout bénef.

Et là, c'est le drame...

Tout va bien ? Il y a encore un petit soucis. Rien n'est plus agréable que mettre un bon gros JPEG en fond d'une page web avec un background: url(...), n'est-ce pas ?

Mais là, mauvaise surprise: Les navigateurs se foutent royalement que votre JPEG soit progressif: Ils ne l'afficheront que lorsqu'il sera entièrement chargé (sauf Chrome). Du coup votre page va rester avec un fond noir pendant plusieurs secondes. Même si ce n'est pas sale, c'est assez laid. Mais on peut ruser.

En fait, dans background il est possible de spécifier plusieurs images. Par exemple, j'ai fait:

background: url("background.jpg") no-repeat, url("background-fast.jpg") no-repeat;

Les navigateurs chargeront en premier les images spécifiées en fin de ligne (background-fast.jpg) et chargeront ensuite vers la gauche (background.jpg).

Le résultat ? L'image de fond semble s'afficher immédiatement, ce qui visuellement est bien moins perturbant. Vous pouvez voir le résultat dans cette page (Cliquez sur le bouton rechargement de page de votre navigateur en maintenant la touche MAJ enfoncée pour forcer le re-chargement de tous les éléments de la page). C'est quand même bien plus agréable.


Pensez à ceux qui ont des débits merdiques, et n'oubliez jamais:

Faites du JPEG progressif !

Vous pouvez convertir vos JPEG existants en progressif sans perdre en qualité.

Source : http://sebsauvage.net/rhaa/index.php?2013/07/30/14/35/17-grosses-images-et-petits-debits


Une journée (chaude) à Paris

mardi 16 juillet 2013 à 12:03

Hello.

Hier j'étais à Paris. Ça a été l'occasion de rencontrer certains d'entre vous (Kevin Merigot, Hoper et sa femme, Tommy et tous les autres) . Ça a été vraiment très sympa :-) J'avoue que le petit comité d'accueil à la gare (avec les pancartes) était intimidant. Nous étions 15 au restaurant et - ah ! - je crois que Kevin aura une photo de moi à vous montrer ;o) Il a fait très chaud, et heureusement que le serveur a bien voulu nous remettre en salle parce que la terrasse était tout simplement insupportable avec les travaux juste à côté. Ça fait plaisir de pouvoir mettre un visage sur certains noms. Merci à tous. Nous avons squatté le restaurant presque jusqu'à 17 heures, à discuter de tout et de rien.

Je me suis éclipsé pour me rendre dans les locaux de Mozilla France, où j'ai été invité par FING à une discussion sur la réappropriation des données personnelles, avec des gens de chez Mozilla, de la CNIL, de CozyCloud, de Privowny et plein d'autres personnes intéressantes. J'ai enfin rencontré Stéphane Bortzmeyer (avec son T-Shirt Framasoft :).

Je ne peux pas vous rapporter la totalité de la discussion, alors voici quelques points clés:


FING a lancé une initiative afin que les internautes se ré-approprient leurs données personnelles: téléphonie, assurance, supermarchés et autres. Le but est de convaincre les acteurs de privés de donner aux internautes un accès brut à toutes les données les concernant, ce qui permettra par la suite aux internautes de les exploiter eux-même pour de nouvelles applications.

Il y a encore beaucoup de problèmes à résoudre: comment convaincre les acteurs privés et publiques ? Sous quelles conditions récupérer ces données ? (sachant que pour la plupart ce sont des opérations très manuelles lorsqu'elles sont demandées). Comment authentifier les utilisateurs ? (l'adresse email ou postale ne suffit pas). Sous quel format récupérer ces données ? (utiliser des standards existants ou utiliser le format brut fourni par l'entreprise ? Transformer les données ?). Comment les exploiter ? (quelles applications ? comment y accéder ? comment les déployer ?)


CozyCloud apporte un début de réponse: Ils proposent un cloud personnel - un silo de données personnel - où vous pourrez stocker toutes ces informations, et offre une plateforme qui permet de développer des applications pour exploiter ces données. Une sorte de Google AppEngine, mais ouvert et hébergé où vous le voulez. Il gère actuellement diverses applications: mail, contacts, agenda, notes, photos, flux RSS, ToDo, Bookmarks, nirc. (Actuellement les sources sont sur GitHub et tournent sous NodeJS. Pour simplifier l'installation, ils fourniront à terme des machines virtuelles.). Et vous pouvez développer de nouvelles applications pour CozyCloud, dans le langage de votre choix. L'intérêt de CozyCloud est que ces applications collaborent sur votre silo de données personnel qui peut être hébergé chez vous. Bien sûr cela pose aussi des questions sur le modèle de sécurité des applications. Mais l'ensemble est assez bien pensé.


Histoire d'avoir de la matière FING lancera une opération avec la poignée d'entreprises qui ont accepté de se prêter au jeu et 300 personnes volontaire au mois d'août, afin de voir un peu ce qui marche et qui ne marche pas, et comment tout le monde ressent l'expérience. Des concours seront probablement lancés pour inciter à la création d'applications innovantes.

Oui, tout cela est un peu effrayant: Voir toutes vos données, accumulées depuis tant d'années par les entreprises avec qui vous avez eu affaire doit donner le vertige. Mais c'est justement un bon moyen d'en reprendre le contrôle et de les exploiter au mieux, pour votre plus grand bénéfice (Imaginez un exemple tout simple: Surveiller l'augmentation des prix de votre supermarché habituel, et comparer avec d'autres). Mais les applications sont encore à imaginer.

Il se pourrait même que l'accès à vos données personnelles devienne un enjeu. Imaginez: Entre une entreprise qui vous donne le plein accès à toutes les données qu'elle stock sur vous et une autre qui refuse, à laquelle ferez-vous le plus confiance ? Vous avez deviné: Cela pourrait devenir un argument de vente majeur pour les entreprises, qui année après année perdent la confiance de leurs clients (malgré les trombes de cartes fidélité). (Pourquoi croyez-vous que Google a créé Google Takeout ?)

Il y a encore beaucoup de questions, beaucoup de problèmes à résoudre et d'expériences à réaliser avant de concrétiser tout cela, mais c'est prometteur.


Privowny de son côté propose une extension Firefox pour protéger votre vie privée: Non seulement il bloque les traqueurs (à l'image de Ghostery dont je vous rebat les oreilles), mais en prime il permet de tracer quelles information vous avez donnée à qui: numéro de téléphone, adresse postale, etc. Vous voulez savoir à quels sites vous avez donné votre numéro de téléphone ? Privowni vous affichera la liste (bien sûr il n'enregistrera qu'à partir du moment où il est installé).

En prime, il vous affiche les centres d'intérêt que les réseaux publicitaires ont identifié chez vous, et propose aussi un service d'email jetable permettant de ne pas avoir à donner son adresse email réelle (et prochainement aussi des numéros de téléphone jetables, pour éviter d'avoir à donner son véritable numéro de téléphone).

Toutes ces données sont chiffrées côté client avec un système clé publique/clé privée. Privowny ne peut donc pas voir le contenu des données chiffrées. Vous pouvez à tout moment choisir de chiffrer ou non une donnée, ou l'effacer. Vous pouvez également à tout moment exporter la totalité de vos données au format jSon et tout effacer chez Privowny. Côté business model, Privowny envisage des services payants supplémentaires (modèle freemium). Un exemple ? Si vous voulez effacer ou rectifier une donnée vous concernant, Privowny se chargera pour vous de faire la démarche auprès de l'entreprise. Privowny réfléchit également à l'ouverture des sources de son service.


Il sera intéressant de voir comment tout cela évolue.

Quant aux locaux de Mozilla France, c'est la grande classe.

Source : http://sebsauvage.net/rhaa/index.php?2013/07/16/10/03/25-une-journee-chaude-a-paris


Le plus stupide DRM jamais inventé

lundi 8 juillet 2013 à 14:27

Les DRM sont des techniques dont le bût est de contrôler l'utilisation des fichiers numériques. En très grande majorité, elles essaient surtout d'empêcher la copie des bits (Ce qui - il faut l'avouer - est déjà incroyablement idiot quand on sait comment fonctionne internet ou n'importe quel ordinateur: Ce ne sont rien d'autre que des machines à copier des bits).

Mais je crois avoir trouvé le plus stupide DRM de l'histoire: Une société a récemment mis en place des DRM sur les eBook consistant à modifier légèrement les exemplaires vendus à chaque client: un espace par ci, un retour à la ligne par-là. Le but étant, probablement, de vous attaquer en justice si c'est votre copie du livre qui se retrouve sur les réseaux de partage. (Cette technique n'est d'ailleurs pas nouvelle.)

C'est une idée incroyablement stupide. Il peut y avoir des tas de raisons qui font que votre copie se retrouve dans la nature: Ordinateur revendu (et disque dur non effacé), clé USB perdue, ordinateur prêté, volé, piraté... Dans tous les cas, cette entreprise met en place dans l'esprit de ses clients potentiels une équation très simple, qui est l'une des plus mauvaises décision business que j'ai pu voir, encore pire que d'essayer de bloquer techniquement la copie:

ACHETER UN EBOOK = ENCOURIR UN RISQUE LÉGAL

Il ne faut pas être devin pour savoir ce que feront les clients potentiels: Ils iront pirater le livre.

Là il ne s'agit plus juste d'être emmerdé par les DRM (impossibilité de lire parce que les serveurs sont en panne ou la connexion internet coupée, impossibilité de le transférer sur un autre système, blocage intempestifs, écrans d'avertissement...), il s'agit d'être menacé légalement dès le moment où vous êtes client. Bravo les gars.


(Hé vous avez vu ? Je fais des efforts pour sortir de Shaarli !)

Source : http://sebsauvage.net/rhaa/index.php?2013/07/08/12/27/17-le-plus-stupide-drm-jamais-invente


Le double #FAIL du site web de WinSCP

lundi 8 juillet 2013 à 12:13

Voulant télécharger WinSCP (un très bon client sftp/ftp pour Windows), je vais sur le site officiel et comme une mule je clique sur le bouton "Télécharger":

Raté: Ce n'est pas le bouton de téléchargement de WinSCP ! C'est une publicité qui me renvoie sur un site qui sent le fennec faisandé (un webplayer douteux qui vous enfourne rapidement un abonnement si vous oubliez d'annuler la période d'essai). Le bon lien était "la page de téléchargement de WinSCP" un peu au dessus.

Une fois arrivé sur la vraie page officielle de téléchargement de WinSCP, second #FAIL:

L'énorme bouton "Télécharger" ne permet pas non plus de télécharger WinSCP.

Webmasters, si vous mettez de la publicité sur votre site, par pitié CONTRÔLEZ UN MINIMUM LE NIVEAU DE PUS QUE CRACHENT CES PUSTULES PUBLICITAIRES. Gagner de l'argent, c'est ok, mais il y a quand même un minimum de respect à avoir pour vos visiteurs. (Personnellement, quand j'avais encore de la publicité sur mon site, je leur faisais une chasse implacable. Je sais, c'est terriblement chiant et fastidieux, mais c'est un choix.)

Et après il y a encore des webmasters qui se plaignent des bloqueurs de publicité ? O'RLY ? Quand on jette de la merde à la face des visiteurs, il ne faut pas leur reprocher de vouloir s'en protéger.


D'ailleurs pourquoi «ça sent le fennec», hein, d'abord ? Quelqu'un a déjà reniflé un fennec ? En plus c'est mignon tout plein un fennec.

EDIT: Un me les lecteurs me fait dire que - si si - ça pue, un fennec  :-D


Source : http://sebsauvage.net/rhaa/index.php?2013/07/08/10/13/40-le-double-fail-du-site-web-de-winscp


L'échec épique de la Xbox One

lundi 17 juin 2013 à 11:56

Je sais, ça a déjà été dit et re-dit, mais je tenais à essayer de résumer la merde dans laquelle s'est mise Microsoft avec les restrictions de la Xbox One:

Microsoft a réussit à tout faire foirer avant même la mise sur le marché de sa console. Certes Microsoft perdait déjà de l'argent avec la Xbox et la Xbox360, mais là comme plantage en beauté, c'est épique. Je ne comprend pas, vraiment. Il y a eu une fuite des cerveaux chez Microsoft, ou bien ils n'ont juste pas suivit ce qui s'est passé ces 10 dernières années sur le net ?

Entre l'échec de la Xbox One, le semi-échec de Windows 8, la grogne des utilisateurs, l'aliénation des développeurs, ses tablettes qui se vendent mal, les smartphones à base de WindowsRT qui ne se vendent pas mieux, mais que fout Microsoft ? C'est le festival des mauvaises décisions.

Microsoft ressemble à Apple quand ce dernier était sur sa pente descendante. Saura-t-il ne pas couler ?


Mise à jour 19 juin 2013: Microsoft a décidé de faire machine arrière: Une seule connexion initiale sera exigée, après quoi vous pourrez jouer sans avoir à vous connecter toute les 24 heures à internet. Il sera également possible de prêter ou revendre les jeux, sans restriction. Et Microsoft lève aussi les restrictions régionales. Tout cela c'est bien, mais il a quand même fallu que tout le monde hurle pour que Microsoft comprenne. (source)

Source : http://sebsauvage.net/rhaa/index.php?2013/06/17/09/56/07-l-echec-epique-de-la-xbox-one


Le grand méchant DMCA et les 3 petits LOLs

dimanche 28 avril 2013 à 14:23

Mitsu s'est complètement fait délister de Google. Le site entier. Moi c'est plus soft (juste une URL), mais amusant.

Plusieurs internautes m'ont en effet signalé qu'une URL de mon site avait été dé-listée de Google sur plainte DMCA. Pour ceux qui ne connaissent pas, DMCA est une loi américaine de protection du droit d'auteur qui stipule d'un hébergeur ou moteur de recherche doit supprimer l'URL incriminée sur simple déclaration sur l'honneur de l'ayant-droit présumé.

Une URL de mon site a donc été délistée de Google sur plainte DMCA d'un ayant-droit, et Google m'a transmis la plainte:


Le message contient l'URL de la lettre reçue par Google. Elle se trouve là: http://www.chillingeffects.org/notice.cgi?sID=911655.


LOL n°1: Cherchez bien. Non cherchez mieux. Oui, je sais: Mon nom de domaine n'est mentionné nulle par dans la lettre. Alors pourquoi Google m'a-t-il délisté et fait suivre cette plainte ?


LOL n°2: J'ai beau prendre l'URL en question (http://sebsauvage.net/paste/?ae60be9cec5e00b8) et la coller dans n'importe quel navigateur, non vraiment, ça ne me donne aucun document qui me semble relever du droit d'auteur. J'ai donc remplis avec plaisir un formulaire de contre-déclaration.

Oh... vous voulez dire que Google (ou l'ayant-droit) aurait omis d'ajouter la clé de déchiffrement privée ZeroBin dans l'URL ? Non, bien sûr: S'ils avaient mis cette clé de déchiffrement, cela aurait été un document privé. Les ayants-droit ne peuvent demander le délistage d'un document privé, n'est-ce pas ?


LOL n°3: Google a donc délisté juste cette URL. Ils auraient pu délister entièrement toutes les URLs en http://sebsauvage.net/paste/
En fait, c'est exactement ce que je veux, je veux que les moteurs de recherche n'indexent rien du tout de tout ce qui est dans http://sebsauvage.net/paste/


Bonne séance de LOL, non ?

Soyons clair: Je ne suis pas contre le droit d'auteur. Je suis moi-même auteur de centaines de documents, images et logiciels. Mais je suis contre cette défense débile, abrutie, automatisée et sans-tête du droit d'auteur, et je lutterai contre.

En tous cas, c'est la première plainte que je reçois concernant ZeroBin, et elle est nulle et non avenue.

Mise à jour 16 mai 2013: Google a répondu à ma contre-déclaration:
Hello,

Pursuant to the counternotice you sent to us on 28/4/2013, we have reinstated the following URL(s) in the Google index: http://sebsauvage.net/paste/?ae60be9cec5e00b8 .

Regards,
The Google Team

L'affaire est donc close.

Et pendant ce temps là, chez Google...

Source : http://sebsauvage.net/rhaa/index.php?2013/04/28/12/23/01-le-grand-mechant-dmca-et-les-3-petits-lols


Puisqu'il faut un exemple...

dimanche 17 mars 2013 à 16:28

A quel point cela pourrait-il être compliqué de s'installer un substitut de Google Reader ? Puisqu'il faut un exemple, prenons le projet de Tontof, KrISS Feed.


1) Mettez le fichier index.php dans un répertoire sur votre site web (Oui, il y a juste un fichier à installer).

2) Ouvrez l'URL et choisissez un login/mot de passe.


3) Importez le fichier OPML que vous avez récupéré de Google Reader ou autre:


4) Dans la configuration, activez la mise à jour par Javascript:



5) C'EST TERMINÉ. Vous avez un lecteur de news à vous. La mise à jour des flux se fera automatiquement en tâche de fond.



Alors, c'était compliqué ? Ça valait le coup de se faire des nœuds au cerveau ?

En prime tout peut se piloter avec des raccourcis clavier. On peut configurer pas mal de choses. Si vous préférez la vue dépliée et sans la liste des flux à gauche, c'est également possible:



Franchement, si vous cherchez encore une excuse pour vous aller vous inscrire chez un autre service fermé, c'est que vous êtes une feignasse.


EDIT: Pour KrISS Feed, il faut php 5.3 minimum.

Source : http://sebsauvage.net/rhaa/index.php?2013/03/17/15/28/17-puisqu-il-faut-un-exemple-