TeDomum Write


Read the latest posts from TeDomum Write.

from Musings by @rg

Start Me Up!

It's January 2020, and in a few days Microsoft will end support for Windows 7 users. No more security fixes, no more bug fixes.

While this might be causing some anxiety to anyone still running a Windows 7 computer, here is a Good News item for you.

Microsoft is still allowing Windows 7 and 8.x users to upgrade their systems (which must be activated) for FREE to a Windows 10 of the same family or variant.

Someone running Windows 7 Home, Home Premium or Ultimate can go thru the process (it's simple and worked well in my personal experience), and have a legal and Activated Windows 10 Home digital license at the end.

If you start with a Windows 7 or 8.x Professional, you will end up with Windows 10 Professional, again fully licensed and activated. No gimmicks!

I was really surprised when RYen, a friend at Hackers.Town mentioned this when he saw my earlier Blog post about how to get OEM Windows 10 Pro license keys cheaply. I followed a link he provided, and read the article.

Why is Microsoft still doing this ?

A good quote from the article clarifies:

The answer to that first question is easy. Remember, Microsoft's Windows business is predicated on its partnership with PC makers, who pay a license fee for every copy of Windows they install on a new PC. Those OEMs are none too happy about the idea of extending the life of an older PC; they would much rather have you buy a brand new PC instead.

So, to mollify its OEM partners, Microsoft put a time limit on the free upgrade offer, and they simply don't speak of it now. The Windows marketing team continues to promote new models of Windows PCs, and the enterprise sales staff continues to sell volume licenses of Windows 10 Enterprise and Microsoft 365 subscriptions. Nobody talks about upgrades.

Frankly, at this point the only people who are still interested in a free upgrade are enthusiasts, home users, and very small businesses running hardware that's at least four years old.

Makes complete sense, and thank you Ed Bott, from ZDNet!

What are the Requirements ?

Microsoft allowed this kind of free upgrade, officially, until July, 2016, and closed the door at that time. To qualify for this undisclosed offer (again, tested successfully with 2 systems, worked in both Win 7 and 8.1), to qualify you need to have a fully activated operating system installed.

  • It will be upgraded within the same family (Home versions, or Pro versions).
  • You need to use the same type of release; 32 bit installs only upgrade to 32 bit Windows 10 versions.
  • Memory requirements, a 2 GB system would work better with a 32 bit version install, imo, as the 64 bit ones require more RAM for the system itself.

Upgrade options ?

The upgrade installation is very easy for any average user – you just need to download a small program from Microsoft, which will check your system for compatibility. Download the install program from this page.

The page has some explanations and tips, you can read those — or simply get the install tool directly from Microsoft Servers.

  • The upgrade program will list any incompatible software found, and offer to uninstall it for you.
  • This again without any user intervention besides accepting the offer to remove the program.

Once those preliminary checks are made, he upgrade program will ask you how you want to handle existing files and applications :

  • Keep all user data only. No apps will be migrated to the new install.
  • Keep all user data and apps – the easiest to keep everything as is and accessible.

Create Install Media or Not ?

On the next stage, you have two options about how the installation will proceed.

  • download and install in this system only. No extra media is needed (USB stick, external drive, etc).
  • Download the operating system package, and save it or prepare installation media (USB stick, DVD R disc, etc).

If you only have one system in the house (or office) that needs the upgrade, the simple choice is to let the installer handle it, and simply install and clean up afterwards.

If you need to upgrade more than one system, accept the option and the installer will download and later help you prepare a bootable USB drive, which can be used multiple times. Or burn the same to a DVD R disc, you will need a blank 8 GB disc.

Running the install ?

Very simply, you started it with the upgrade tool from within your working Windows 7 (or 8.x) system; make the choices, as described above. And relax and do something else while it goes to work

The installer will request and download the correct version from the Microsoft servers; this will be a large download, about 5 GB. (have more systems to upgrade? Save this and prepare the Boot media as offered in the installer, and reuse this. Saves another large download).

Once the download is completed, the Setup will start, and proceed to install, migrating your apps if you chose so, saving your files intact.

What to expect ?

Although it can take some time, the process is painless and no user intervention is needed. So I would recommend this to anyone who still runs a Windows 7 or 8.x system, as long as you have at least the 2 GB minimum system RAM as required.

I have personally followed this procedure and done two complete upgrades – both without any difficulties.

  • A Windows 7 Home Premium 64 bits laptop, now running Windows 10 Home 64 bits.
  • A Windows 8.1 Pro 32 bits desktop, now upgraded to Windows 10 Pro, 32 bits.

Good luck and enjoy you freely upgraded and more modern O.S. Happy New Year!

Thank you for reading this, please feel free to comment about this post, your input is important. This page created entirely in MarkDown language.

R.G. @design_RG@Qoto.org


from Musings by @rg

And today we start the day with a To Do clean-up; pending things that need action. Including a recent discovery I made, surprising to me, that my home and primary instance in the Mastodon network was not visible, searchable and in fact, fully Blocked at another place.

Being active and curious, I do have accounts in maybe 10 instances or so, used in varying degrees, some frequently visited, others less so.

Very recently I made a blog post with discussions on why choosing an instance is important, what factors to consider when doing so, and a partial list with descriptions and details of some of the ones I enjoy.

That post is located here.

After creating a new blog post, I prepare a release text for announcing it in the Fediverse. About 500 characters, it also includes a good image and is posted at Qoto.org, my primary account (and the one which signs off all posts here).

Once this is ready, the text and image are posted at Qoto, and I do visit some of my other accounts, search for that Status URL, and proceed to Boost it for reaching more people if possible.

While doing this, I visited one, Mastodon.Technology, where I could not find the status on that normal search. Odd. What is going on?

A search for my user profile at Qoto did not bring ANY results either. It dawned on me that something was amiss...

WTF ? Blocked possibly ?

Yes, that was the first thing that crossed my mind. M.T has some clear rules at their front door, the famous About-More pages. I looked there, and found a link to a Git instance, with a list.

And. We are on it. Last on the list, suggesting possibly a recent addition to his Disgraceful People List. (some are ghastly places, I would agree)

Why ?

Good question. I couldn't see why. Ash has provided some info :

Blocked Instances :

“Here are the instances that m.t has blocked. This list is not meant to be authoritative for other administrators. We reserve the right to silence or suspend any instance for any reason. If you are an administrator of an instance on this list, feel that you shouldn't be blocked, and have checked our Code of Conduct, you can contact Ash Furrow through email to discuss getting unblocked.”


This happened a few days ago. What then?

How to Proceed :

Since it was now clear that an Instance Ban was in place, the next step was communicating with our Admin. We discussed it, and I offered to try and deal with Mr. Furrow and request a review of their decision. Dr. Freeman, our admin and domain owner, agreed, and I went about preparing a case.

  • First step, read his provided link to Code of Conduct (the About-More page).
  • Upon reading it, find what we could have done to be black listed.

And it seems it's the final paragraphs, shown in this snapshot.

So, Guilty by Association, I gather? Ah, yes, to protect the Free Speech of some users, I see.

Had this in my notes and on a admin Forum thread, and now took time and wrote a full, formal letter to Mr. Furrow.

Which, being a writer and a budding citizen journalist, I chose to publish here, in full as well. Text of letter follows, it is only being altered here for formatting enhancements that MarkDown and Write Freely provide.

Full Letter Text :

January 6, 2020.

To : Ash Furrow, administrator, Mastodon.Technology via email – ash@ashfurrow.com

From : RG, staff member, Moderator at Qoto.org domain

CC : @freemo@qoto.org, Admin, Qoto.org

Re : Blocked status of Qoto.org on your instance, Mastodon.technology.

Dear Mr. Furrow,

I am a member of Qoto.org, where I am part of the domain Staff, and moderator at both the Mastodon instance and our Discourse Forums. Being an active user and a curious human being, I do have accounts in various other instances, including yours, where my handle is @rgx.

Thank you for hosting that service, it seems a nice and active community, and themed on Technology which is one of my personal interests. Being so busy with my Qoto participation, user support, starting to write my own personal Blog, I haven't had the opportunity of participating as much at M.T.

Was however surprised to discover I could not find one of my own Blog announcement posts, from the search function at M.T, where I intended to Boost it for wider audience viewing possibilities.

The Search turned out Blank, no results. A search for my own account at Qoto, @design_RG@qoto.org, also turned out blank.

My hunch that this was possibly due to an Instance Block was confirmed by viewing your Blocked instances list .

Honestly, I was appalled. I feel that we are doing a good job and providing valuable services, an active community and an instance theme that is unique, as far as I know.

As mentioned in the page above :

“If you are an administrator of an instance on this list, feel that you shouldn't be blocked, and have checked our Code of Conduct, you can contact Ash Furrow through email to discuss getting unblocked.”

I did read the referenced page for CofC, and discussed my findings in our Admin forum at Qoto with Dr. Jeff Freeman, our domain owner and Admin. Mr. Freeman agreed to my proposal of contacting you via email to discuss this, and any remediation possibilities.

From reading your CofC, and considering that we are an instance and community in good standing, preeminently listed at the head of Suggested Instances at JoinMastodon.org , I am contacting you to request your consideration of a lift on this instance ban.

I imagine your reason for such is :

“To protect the free speech of users belonging to marginalized groups, mastodon.technology does not federate with overtly fascist instances. Additionally, we will refuse to federate with instances that themselves choose to federate with fascist instances.”

Is that correct? I can't think of any other possible reason.

I would like to add that I personally dislike some of the communities which are part of the Fediverse; and exercise my user rights on blocking Gab and their peripheral instances in my own personal account. I also intend on writing, shortly, a new blog post documenting all kinds of Filtering and Content blocking that users can utilize to their own satisfaction and better enjoyment of their Fedi accounts.

But as an active user and content provider at Qoto, which is also the channel for my personal blog writing announcements, I am dismayed by our instance being blocked by M.T., specially considering it's a large community and themed in Tech, one of my main personal interests.

On behalf of myself and many other Qoto users, who daily provide good content and valuable interactions with many other instances, I am hereby, with authorization from Dr. Freeman, requesting that you please consider lifting your instance blocking of Qoto.org.

I am also happy to discuss this matter and accept any comments and suggestions on this matter, on behalf of Qoto administration staff and our user community.

I can be reached via this email, which is my Fedi accounts mainline, or via DM to my @design_RG@qoto.org account. In your own instance, my account is @rgx@mastodon.technology .

Thank you for your time, attention and considering this request.


RG, for the Qoto.org administration team.

cc: QOTO@syncleus.com

Final Thoughts :

I have sent this letter, the Image at the head of today's blog is a snapshot of my email client just after sending it. Will be waiting for a response, which I hope Mr. Furrow will provide to a courteous and carefully written inquiry.

Thank you, Mr Furrow. I will update this with any news as it develops.

Thank you for reading this, please feel free to comment about this post, your input is important. This page created entirely in MarkDown language.

R.G. @design_RG@Qoto.org


from Musings by @rg

Casual Conversation, Interesting Tips.

Once again I had an enjoyable conversation, earlier today. From my laptop, logged into my Qoto acount via Web client, I also browsed Mastodon.social via Pinafore, and we started a chat.

Achso was there(@achso@mastodon.social), and we kind of continued a conversation from a day or two before. I enjoyed it, said a lot, and thought it would make for a nice blog post.

The full thread is online, and can be seen here. I was posting via Pinafore, and limited to 500 characters, unfortunately – which led to some choppy posts (instance there limited to 500 chars max).

We really should petition Eugen R. @gargron@mastodon.social and beg for a larger limit for the MaximumTootSize variable. Currently, it's 500 characters, larger in some instances that customized their own limits.

Conversation Follows.

( Achso's Toots are shown in quoted form, mine are in plain text form. )

@achso : Otherwise this will stay a niche thing. And it deserves better than that. I think it is sad that many of my old contacts from abroad – US and other places – refuse to leave their old biotope.

Some people will come and see what is going on here if it keeps growing and getting media reports.

I only joined here in November — close to 2 months now, but in that short time I went from total newbie to having 3,400 posts or so, Staff position at my main instance, and being part of maybe 10 instances of Mastodon alone.

Plus the wonderful integrated services – love Write.freely!

Insta, I stayed away, always. Dumb people, hashtag binging, bothers me, they are clueless.

Curiously — I found my curiosity and interest in this Fediverse due to a BBC News report about the Indian Diaspora, from TW to mastodon instances.

Saw it on my rarely visited TW timeline, read the article. Uhm, what is mastodon?

LOL, the rest is #history.... :-P

Having lots of fun, it's keeping me happy and busy thru Winter, depressive in general in our Northern latitudes.

This very article :

@achso : Twitter classified the famous Landmesser-photo as “hateful imagery”? Wow... I think there is no lack of antifascist people on Twitter now, but many of them act like – cough... – fascists. Intolerant, stubborn, uptight... Anyway, Mastodon is different, which is good. ;)

Yes, I like it here, it's very refreshing!

With politics and all, but like on Fidonet, we can make waves, run our own things, and have a voice.

On the algorithm driven major soc media sites, not a chance, they silence you simply by not showing your content.

Hey, if you even want to try a smaller instance, come and visit Qoto.org, it's a nice place, if I may say so.

But does Choosing an Instance Matter ?

@achso: Is it really important which instance some is on? Isn't it the core of the fediverse that it does not? Just asking...

I think that is an excellent question! And I am part of various ones, although lift the flag and sign my blog with my main one.

How does it differ, being in one or another?

  • a very small instance will likely have a very quiet local Feed. This is sad, as the Local feed is where I find most social interaction happens; camaraderie, we see each other, all posts. And sometimes we provide support just to encourage a friend to keep going.

  • at the opposite end, a very large instance will have an extremely busy Local feed; no lack of things to look at, but like Twitter, many will fly by without any reaction, as people don't have the time to relate, read, respond before another barrage of posts land.

I visit and post somethings here in ms.soc, it's the Flagship and sometimes good for exposure. But it wouldn't work for me as a home. I find the Local feed overwhelming indeed.

  • So size is important. Theme also – there are generalist instances, and posts from all kinds; might be good to discover new things, interesting. Less good for more focused posts or interests, which sometimes a more focused instance can better take care of.

  • Language, one's native one is ideal, even if we do fluent English, thankfully, bridging the divide; I still love to write and converse in other languages.

  • Culture : like travel, seeing the instances in other countries, is fun.

I love this discussion and will likely collate all of my posts above and build an article for a blog post on it. I have been enjoying doing that.

Wanted to ask you, remember our chat from yesterday, regarding Fidonet, Front Door? wanted to request if you allow me to quote you on a possible article for the blog?

If you prefer not to, I understand, but I am a learning journalist and respect my sources. Thank you for the nice conversations!

@achso: Sure, no problem.Nothing wrong with a little bit of sentimentality. :)

BTW: As a journalist (desk editor, reporter) for more than 30 years I have to help my young fellow colleagues, no? ;)

Thanks, Achso!

This was a fun conversation, and helped me organize thoughts on why visiting, getting to know different instances is fun and important.

I enjoy traveling and choosing small cafés or restaurants in the streets of towns and cities abroad. Our mastodon instances are very much like Cafés, and the quality varies, the customer base is a big part of how nice they are, how active specially. Management can also make or break a community.

I am grateful to the administrators and staff team of the various instances which I belong to; with all of them I have learned, observed and thought about different ways things can be done. Fun. Thank you, friends. ;–)

Below I will outline a little about these instances I frequent. No specific recommendations, just notes, maybe help you know what's available and how they can vary?

Some instances I frequent :

In no particular order, just writing from the top of my head in my text editor...

  • Qoto.org – listed in my blog signature, Qoto is my primary instance; one where I spend most of my time, have made many posts and enjoy socializing with local friends which follow my work closely. I have volunteered and been elected as a Moderator there recently.

Instance Theme : STEM, Science, Technology, Engineering and Math are the theme here. Not strictly enforced in everyday posting, which can be relaxed (I do contribute a lot of Cat pictures!).

Users number : just over 6,500 now with a recent influx of Spanish Twitter migration. Registrations : open.

  • Todon.nl – A Leftwing instance, Todon has some nice people I had met over the Feeds and enjoyed conversations with. I am also aligned with the local political lean, so it's one of my favourites. Well connected, posts distribute quickly.

Instance Theme : there's a number of activists, and users who enjoy the place, where they won't meet any vociferous politically opposing people.

Users number : just over 5,300. Registrations : are via an application, explain how your personal views align with Todon's. [temporarily Closed atm]

  • Hackers.town – a community of people interested in computing, network and systems administration, security, privacy, and related topics. An interesting place for people interested in learning about those topics, which is my case, because it has experienced users in these various fields.

Instance Theme ; Technology, Computing, Security, CyberPunk.

Users number : about 200, although their total post count is astronomical. Registrations : are controlled, as the front door says “Speak friend and enter.”

  • Toot.Cafe – This is an instance frequented by programmers, web designers, etc, and administered by Nolan, the author of the brilliant Pinafore mastodon client. For many knowledgeable users, Pinafore is tops, for it's speed, streamlining and support of multiple instances – and ease of switching between them. See more information at the project's home. Not a general instance, but I enjoy visiting and chatting with Nolan when I have a suggestion for Pinafore.

Instance Theme : Web design, Mastodon, programming, UI design, Clients for Mastodon network. Users number : 2,772 Registrations : Open, via Request an Invite link at front door.

“All friendly creatures are welcome. Be excellent to each other, live humanism, no nazis, no hate speech. Not only for nerds, but the domain is somewhat cool. ;) No bots in general! (only with prior permission)”.

E.U. based, so European Privacy and other laws apply – an advantage for me, in any network services choice if available.

Instance Theme : A General instance, based in Germany. Posts in English and German.

Users number : 365 Registrations : Open

  • Mastodon.social – The Mothership, this instance is home to Eugene R., who is the lead developer of the Mastodon project.

For many new users, it's the only instance they know of, so it has a large influx of new people and the largest number of users in Fediverse (not counting the Gab instance and peripheral systems, as they are not widely accepted by a lot of other fediverse instances).

A very, very busy local timeline, if you get bored of waiting for some new post at any smaller instances. A good place to see what a very large Mastodon instance would feel like (and to know what kids of hardware it takes for such high numbers of users). Also a good place to boost posts from, if you want some extra spreading for a new thread.

Instance Theme : a General instance, no specific theme.

Users number : 455,000 as I write. Registrations : open.

  • Mastodon.technology – A fairly large instance, with a Tech theme and actively moderated. The administrator has clearly stated rules and isolates his instance from many others.

Some of the excluded instances (as listed in his git page here) are black balled simply for federating with other instances that Ash Furrow, the local admin, does not want connections with. Sadly this blocks a lot of info from other, more open minded instances (and I mean the ones that are not fascist dominated, but get tarred here in his extensive blocked list).

Instance Theme : Tecnnology. But selectively disconnected, see note above.

Users number : 19,500 Registrations : Open, fill in form (“Why do you want to Join us?”) to request an invite.

Mastodon Instances in the World :

Bonus, if you read this far in the page, lol... A nice world Map showing the local concentration of Instances. Click on Image for Large Version. Map of Mastodon instances from Mastodon Network Monitoring Project, August 17, 2017.

From an interesting article At Medium.com.

Thank you for reading this, please feel free to comment about this post, your input is important. This page created entirely in MarkDown language.

R.G. @design_RG@Qoto.org


from Musings by @rg

Received an interesting suggestion via Direct Message, it said :

What do you think about: Starting a hashtag like : “qotoarticle” and all qoto-users who publish journalism-like or good pieces from the internet shall use this # to make it possible to find an interesting collection of qoto-news, without all the fun-stuff burying it?

This is a nice idea — and I am opening a Discourse Forum thread to chat about it.

Why there, not in the normal Mastodon Local timeline? A few reasons:

  • we won't be posting all kinds of tag ideas with hashes that will go live, and maybe never used again.
  • it's open to anyone who wants to read it, as I will add thread URL here, and it's publicly readable to all.
  • it's open to replies, all you need is a quick registration, confirm the email, and presto, you are in.

So all good, isn't it?

Consider it done;

Done, my friend, and here are some of my hash suggestions.

  • They need to be easy, short if possible.
  • easy to spell so both posters and searchers can use the tag for their own means.
  • unique, so they will collect the intended posts and no strain content.

Which do I think could work? Uhmmm... Brainstorming, put ideas out and don't judge them. Add more ideas. Decide later, at evaluation time.

Maybe : qoto-news . qoto-journal . qoto-daily . qoto-top . qoto-stem . qoto-hq .

or : stem-news . stem-hq . stem-daily . stem-mvp .

Do they have to include the “qoto” word and brand ID? not necessarily, we are just considering ideas here.

  • If including, they might get people to pay attention to our instance in general.
  • It could be used by others, in fact any hash tag can be overwhelmed and spammed, unfortunately;
  • not much defense from that other than blocking the twits who did it.

There, the ball is at play, let's hear what you all think?

Thank you for considering and participating.

#STEM #science #math #Engineering #Math news are of interest to people all over the #Fediverse

Follow-Up :

All of my long posts are not written in the Toot Editor box — too small for serious writing. I use a simple Text Editor, EditPad Lite, free and powerful. Love to get into it and away from the zillion Tabs open in my browsers (2 to 3 sets, in separate windows. I know, busy guy here.)

  • So, I wrote all of the above in the text editor.
  • Then copied it to Clipboard, pasted into the Discourse Forum, new Thread.
  • Copied the URL (address) of that new thread, to use in Mastodon announcement.
  • Switched tab to Qoto Mastodon; pasted the Clipboard contents, first the full text, then the URL, also stored in it.
  • I had searched on Bing for a good image, sized it for my normal Blog post header at 640 pixels width.
  • Opened and added it to post via Toot Editor insert Image (paper clip icon).

Hit Enter and now that was complete! Ah, sent my friend a link to the Forum with the URL too.

Some replies followed, and considering their content (showing interest, support and some extra suggestions), I made one more longer post, next.

Additional Contents Requirements ?

I found it was a wonderful idea and suggestion — was glad to receive it, can see the use, for sure.

We need a good hash word, as outlined above, so it will get used.

I like the suggestions of *some content standards for people using the tag*. These not only liven each post, but can lead the way to everyone following the model and producing richer posts all the time.

Some of the possibilities for suggested requirements:

  • a relevant image in each post. Size should be manageable, too large a file uses disk space everywhere, we can including an image at about 700x700 pixels comfortably. And include a link in the post if you think a higher resolution version is important; then it's available if people want to see it.

  • A clear and relevant Title in the first line. Before starting the post, put a blank line after it. So the title will stand out on it's own in people's Feedlines. A better change to snag a reader is important!

  • Always provide any relevant links with the post. If something is a more extensive post, maybe it can benefit from a Blog placement; Like the posts I write and post at WriteFreely. Still, these longer articles can be Announced in Mastodon, with the same format as other, shorter ones; a Clear Title; some text Body; link to full article elsewhere; Always a Good Image! (we are fighting for people's attention, everyday)

  • You can post longer pieces in Mastodon as well; Qoto is very special in allowing a HUGE 65,000 characters max per Toot. But even elsewhere, it's feasible to make a Thread, successive posts in reply to the previous one; Best done as a Thread with the 2nd and later replies all set to Unlisted privacy setting (to avoid clogging Local timelines)

  • if doing multipart posts, you need to work careful and quickly — to try and avoid anyone jumping in with a comment or reply while you are still mid-stream in the posts. It's possible, but a bit tense (I did this before). Best done with a machine supporting an enhanced Clipboard, capable of storing multiple pieces of information.

  • I have and use this daily — Windows 10 now supports it, all you need is to press WinKey-V, and it will show all current clipboard contents, in time order; you can select any of them, text, URL, image, to insert at this point. So a multi-part post can ALL be copied to Clipboard, piece by piece, then inserted into Toot Editor in quick succession. Insert, Toot. Click Reply, insert next, Toot. and so on, until complete. You will overwhelm any humans looking at the post, less likely to have a stray response.

I made a nice and long thread with the story of a visit to a Museum, posted here. Later it became a Full Blog post, which took more work but all the story was written already. I used a plain text editor in my laptop, and tuned away all the distractions.

At the end of a post, it would be nice to find some References — links, see also, anything related to your article. This can be done in a simple way, as a list of words and links to further info, as seen in the very last Toot in my Museum thread.

Stopping at this point, as it's getting long, but I already see this thread as my topic of the day for a blog post. ;–)


We now have the Forum thread, and it allows for easier reading to anyone using a laptop or Desktop computer. Posts there can also be edited, enhanced with in-line images, and use all of the formatting power and beauty of the MarkDown language. A lot of this was formatted there.

Later, I copied all of the text into Clipboard, and into my own WriteFreely instance — my editing platform for Blog work is running in my own laptop here, so I can use it even if Internet goes down, and the responses are lightning fast.

Once I am happy with the text and layout, imagery, I can copy and paste the full MarkDown source into my blog hosts.

Hopefully we get good response in the Forum thread, where everyone can respond fast and easily with their comments, ideas. Again, the Discourse Forum Thread is Here. Please visit there or respond to our Mastodon Thread about this idea here.

Thank you for reading this, please feel free to comment about this post, your input is important. This page created entirely in MarkDown language.

R.G. @design_RG@Qoto.org


from Musings by @rg

New Year's day, and all is quiet in the land. :–)

Time to catch up, and I remembered an idea for a blog post a few days ago. We were having some discussions (which turned a bit heated), but later things calmed down.

Chatting in a Mastodon network thread, I mentioned the situation reminded me a lot of my days in the BBS world; where I started in computers, dial-up modems, and the network I was soon participating in – called FidoNet. The conversation went as follows:

Brings memories of sysops battling it out on our local FidoNet network!!

Time goes on, humanity continues.

Fediverse is indeed quite similar to the wonderful pioneer that Fidonet was. Way before internet was accessible to the masses.

@anarchiv : as a part of the unthinking masses, I don't know what that is.

Fidonet? it was a network formed by independant system operators (sysops for short) in the days of BBSes (Bulletin Board Systems) being the only computers you could reach and connect to from home.

We only had dial up lines, but it was amazing to dial up and connect to a place with information, software for download, online games. All of this for free in most cases.

People operated those as a hobby, all of them loved computing. It attracted similar people, which is how I joined. 1992.

I will write a blog post or more about it soon, there's so many good stories and similarities to the Fediverse. It felt immediately similar when I joined here.

Even the brawling with other sysops, who sometimes we didn't like, we did that as well, lol.

Great fun to be had, lots of coffee was consumed, talks went late into the night.

The network was worldwide, and sent international mail via phone calls. Data lines? not available at the time.


Another conversation mentioned Fidonet on our Local instance chats.

I have been seeing and feeling many similarities between the fediverse and my first experience with networking, way back in the early 90s.

Back then, all we had were BBSes, phone lines and 2400 bps modems, but there was an international network linking many of them already – FidoNet.

FidoNet had as one of its core principles something similar to your approach here:

  • Thou Shall not be Annoying. immediately followed by :
  • Thou Shall not be Easily Annoyed.
    Words of wisdom to live by!

@freemo : I started on the BBS dialup days as well. The connected network between them was just coming around at the time.

Did you play the Doors games like LOTRD?

Yes, I did play some of the games. Sometimes you had to be waiting to be able to connect, as in most cases there was only one phone line. People had fun running a BBS in a spare computer, and we could get software galore, when there was no Internet access to the public, which only came later (about 1995 or so here in Canada).

Watching the dialing, the link negotiation between the modems, seeing the ASCII art load, it was so much fun.

@freemo : The good ol' days :)

From those pioneer days, fast forward 25 years — And now we have online, free streaming video of the nice “BBS – The Documentary” series, by Jason Scott.

The full series is on Qoto Peertube; see a playlist with all 8 episodes here. If you want to see the FidoNet episode, part 4, it's here.

Synopsis from DVD version :

From the DocuWiki page for this series, we have the full synopsis :

Long before the Internet escaped from the lab, connected the planet and redefined what it meant to use a computer there was a brave and pioneering band of computer users who spent their time, money and sanity setting up their home computers and phone lines to welcome anyone who called. By using a modem, anyone else who knew the phone number of these computers could connect to them, leave messages, send and recieve files.... and millions did.

They called these places “Bulletin Board Systems”, or BBSes. And their collections of messages, rants, thoughts and dreams became the way that an entire generation learned about being online. When the Internet grew in popularity in the early 1990s, the world of the BBS faded, changed, and became a part of the present networked world.. but it wasn't the same.

Get your own copies :

Jason Scott has released the original DVDs to the Internet Archive, and anyone interested can watch online, download individual episodes — or the 3 DVD ISO images here.

Our PeerTube videos are better quality, a DVD rip by MVGroup.org and released in Bit Torrent and eMule networks (free user registration, login required).

References :

a. BBS systems :

A Bulletin Board System or BBS (once called Computer Bulletin Board Service, CBBS[1]) is a computer server running software that allows users to connect to the system using a terminal program. Once logged in, the user can perform functions such as uploading and downloading software and data, reading news and bulletins, and exchanging messages with other users through public message boards and sometimes via direct chatting. In the early 1980s, message networks such as FidoNet sprung up to provide services such as NetMail, which is similar to email. Wikipedia page

b. FidoNet computer network :

FidoNet is a worldwide computer network that is used for communication between bulletin board systems (BBSes). It uses a store-and-forward system to exchange private (email) and public (forum) messages between the BBSes in the network, as well as other files and protocols in some cases. Wikipedia page

c. Dial-Up Networking :

Dial-up Internet access is a form of Internet access that uses the facilities of the public switched telephone network (PSTN) to establish a connection to an Internet service provider (ISP) by dialing a telephone number on a conventional telephone line. Dial-up connections use modems to decode audio signals into data to send to a router or computer, and to encode signals from the latter two devices to send to another modem. Wikipedia page Dial up modem sounds Dial up video (26 secs)

#modem #DialUp #networking #Retro #Computing

Thank you for reading this, please feel free to comment about this post, your input is important. This page created entirely in MarkDown language.

R.G. @design_RG@Qoto.org


from Erin Carson

Posted by Erin Carson October 20, 2019 at WordPress.com Posted in News

An incomplete list of places I go for news.
(Note: This list changes)

General News

U.S. News

News Aggregators & Wire Services

Internet News

Video Games



from TeDomum

... sans en avoir trop honte !

Ces derniers mois l'idée a mûri et il est grand temps que ce blog s'en fasse le relais puisque nous expérimenterons dès ce week-end sur de premiers services en production : Hiboo, notre nouvelle usine à gaz.

Si Hiboo est tout ce qui vous intéresse plutôt que l'historique, vous pouvez avancer directement à la section « Que s'apeleriá Hiboo »

Un problème avec l'authentification

L'authentification d'utilisateurs sur un service distant n'est pas un sujet neuf, et une successions de philosophies, chacune accompagnée de sa pile de protocoles et d'outils, fournit aujourd'hui un beau panel de possibles. Résumons chronologiquement.

Au commencement était la base d'utilisateurs, locale sur chaque machine. Cette base, que certains ont matérialisée dans un /etc/passwd, d'autres dans les tables SQL de leur application Web, détenait la vérité sur les utilisateurs, leur mot de passe et leur profil.

Le problème est rapidement devenu évident : chaque administrateur connaissait les mots de passe de tous ses utilisateurs. Pour peu – suivez mon regard – que les utilisateurs ré-employassent leur mot de passe sur plusieurs systèmes, chaque administrateur détenait en réalité les clés de leur vie numérique.

Bien entendu et même si les paragraphes sont rédigés au passé (y compris du subjonctif !) : cette époque n'est pas révolue. Quelques mécanismes ont été mis en place pour limiter les dégâts lorque les informations fuitaient : utilisation de hachage cryptographique à l'état de l'art pour rendre plus difficile la récupération du mot de passe réel de l'utilisateur par exemple. Ceci n'empêche que la majorité des applications emploie toujours ce modèle en 2019 ; et que la majorité des administrateurs ont, sur chaque service, une copie de nos mots de passe.

Plus tard on a suggéré que centraliser ce stockage le rendrait plus difficilement accessible à un attaquant, mais aussi plus facilement maintenable. L'IT d'entreprise a ainsi adoubé LDAP et ses concurrents, pour que chaque application interroge le stockage central des authentifiants. Malheureusement dans ce modèle, les applications connaissent toujours le mot de passe de chaque utilisateur qui se connecte.

Les années 80, 90, enfin les années 2000 et plus récentes ont vu fleurir la notion de tiers authentifiant. D'abord Kerberos, puis SAML, SAML2, OAuth, enfin OAuth2 et son cousin OpenID Connect offrent la possibilité de centraliser l'authentification sans que l'application ait accès au mot de passe. Comment ? grâce à la magie de la cryptographie essentiellement ; nous vous renvoyons à la documentation de chacun de ces standards pour les détails plus ou moins gores.

TeDomum dans tout ça

Où en est-on chez TeDomum aujourd'hui ? Au triste niveau de la base d'authentifiants gérée par chaque service. C'est un choix que nous avons fait il y a plusieurs années selon le raisonnement suivant.

La plupart des applications que l'on déployait à l'époque supportait soit LDAP, soit un stockage local. L'alternative LDAP posait un risque supplémentaire : non seulement les applications continueraient d'accéder au mot de passe utilisateur, mais en prime l'utilisateur n'aurait plus le choix que d'utiliser le même pour tous nos services. On n'aurait rien apporté à un utilisateur peu consciencieux, et on aurait pénalisé les internautes motivés qui configuraient déjà un mot de passe différent par application. Nous avions donc opté pour le moindre mal : ne rien changer.

Notre objectif dorénavant : fournir enfin une authentification unique pour nos services, mais sans révéler le mot de passe à chaque application, et en proposant des mécanismes modernes, multi-facteurs, adaptés.

Que s'apeleriá Hiboo

Le bon sens voulut que nous options pour une solution du marché (Gluu et Keycloak ne sont que deux exemples de qualité dans un écosystème assez bien fourni), mais la lourdeur et le manque de souplesse de ces implémentations nous ont freinés. Aussi, contre toute raison, et comme nous l'avions fait en 2014 en débutant le développement de Mailu, nous nous sommes lancés from scratch.

L'objectif d'authentification centralisée a guidé la réflexion, mais il est loin d'être le seul besoin : plusieurs se sont par exemple présentés en réfléchissant aux manières d'implémenter SAML2 et OpenID Connect, les protocoles retenus pour migrer notre authentification.

C'est ainsi qu'est né le projet Hiboo, où nous souhaitons développer notre capacité à gérer sur le plan technique la communauté d'utilisateurs et de services de l'association de façon unifiée et sécurisée.

Page principale de Hiboo

Métadonnées des utilisateurs

La gestion des métadonnées nous pose conceptuellement problème dans les solutions standard d'authentification : en général, le fournisseur d'identité détient le profil de l'utilisateur et autorise les applications à y accéder. Hors, nous ne souhaitons pas que chaque application stocke à sa guise des copies des informations privées de nos utilisateurs, à commencer par leur adresse e-mail.

En attaquant le problème par l'e-mail (nous avons bien d'autres fronts à couvrir), nous proposons une solution où l'utilisateur peut recevoir des notifications sans communiquer ses coordonnées directement à l'application.

Mon profile Grafana avec une adresse e-mail pseudonymisée

Hiboo pseudonymise ainsi l'adresse de contact et joue le rôle de relai. A terme, nous devrions même pouvoir relayer ces messages, après filtrage par l'utilisateur, sur une messagerie au choix. Qui n'a jamais rêvé de recevoir ses notifications applicatives sur Matrix ?

Gestion multi-profils

Au sein de l'équipe TeDomum, nous avons chacun plusieurs profils sur nos services, pour tester, pour administrer, pour notre usage personnel quotidien. Devoir gérer les mots de passe de tous ces profils est coûteux et sujet à erreurs. Nous souhaitions faciliter ces manipulations.

Aussi, nous avons été témoins de quelques cas de harcèlement où malheureusement, malgré les mesures prises pour désarmer l'agresseur et les moyens à disposition pour bloquer ou ignorer ses messages, la victime n'avait plus d'autre choix que de créer de nouveaux comptes pour changer de visage numérique et y échapper. Il nous paraissait primordial d'accompagner ces changements, voire de les rendre faciles et autonomes.

Ainsi, Hiboo décorrèle le compte utilisé pour s'authentifier des profils exposés aux applications. Je peux m'authentifier sur mon unique compte « john » et me connecter à Mastodon en tant que « alice » le matin et « bob » l'après-midi, de même que je peux me connecter à Pixelfed en tant que « john » ou « charlie » quand je le souhaite.

Interface de sélection de profil pour une authentification

L'adresse e-mail fournie étant la seule métadonnée et comme elle est pseudonymisée, l'application ne peut pas relier mes différents profils entre eux (nos applications n'accèdent par ailleurs pas à l'adresse IP source, même s'il nous reste un peu de travail pour masquer le user agent). Mieux : nous avons prévu que le modérateur lui-même ne puisse pas nativement lier ces profils entre eux (nous réfléchissons aux outils pour aider la modération sans compromettre la vie privée des utilisateurs).

Chaque application a son quota de profils pour éviter les débordements, pour certaines les profils supplémentaires sont soumis à validation du modérateur, pour d'autres les profils ne peuvent être créés que par un administrateur, etc.

Liste de profils sur un compte Hiboo

Gestion de la migration

La part la plus difficile de ce nouveau type de composant reste classiquement la migration. Chaque utilisateur de nos services a aujourd'hui son compte sur une, deux, voire plus d'applications que nous hébergeons. Quelque fois ces comptes ont le même nom, parfois ce n'est pas le cas, voire souvent un même nom employé sur une application est en réalité détenu par un autre utilisateur sur une autre application. Comment gérer alors la reprise des milliers de comptes existant sans cafouillage et des mois de préparation ?

C'est là encore que décorréler comptes d'authentification et profils applicatifs nous a rendu service. Chacun est libre de créer le compte d'authentification qu'il souhaite sur Hiboo. Seules quelques rares applications (essentiellement les services d'administration internes à TeDomum) utilisent ce nom de compte pour authentifier l'utilisateur.

Puis, nous importons par application la liste des profils déjà réservés car appartenant historiquement à un utilisateur de l'application. Ces profils sont « récupérables » dans Hiboo en fournissant le mot de passe du compte original ; ils sont alors importés dans le compte Hiboo et utilisables directement (dans la limite du nombre de profils autorisés).

Récupération de profil sur un compte Hiboo

Où en sommes-nous ?

Hiboo n'est plus une chimère, nous le testons depuis quelques semaines et le code est public sur notre forge : https://forge.tedomum.net/acides/hiboo.

Il s'agit d'un développement Python Flask et SQLAlchemy pour le stockage. La gestion des comptes et profils est développée sur mesure, tandis que OpenID Connect et SAML2 sont respectivement implémentés par Authlib et pySAML2, deux excellentes bibliothèques.

A l'heure où nous publions cet article, nous importons les comptes de notre instance Mastodon dans notre serveur Hiboo de production, afin d'ouvrir dans les heures ou jours qui viennent le service pour l'authentification sur Mastodon. Si tout se déroule sans accroc, nous poursuivrons avec l'ensemble des applications supportant SAML2 ou OpenID Connect (soit l'essentiel de nos services).

Perspectives pour Hiboo

Nous ne plaisantons pas en décrivant Hiboo comme notre nouvelle usine à gaz : il reste une montagne de fonctionnalités à ajouter pour en faire notre premier outil de gestion technique de communauté. Mais nous prêterons attention à ce qu'il demeure simple de conception, maintenable et auditable.

D'abord, l'anti-spam. Nous avons travaillé ces derniers mois à la conception de CAPTCHA pour limiter le spam sur nos services. Nous avons espoir que le déport d'authentification calme les robots mais il n'arrêtera pas les spammeurs motivés. Pour cela nous planifions d'intégrer rapidement un système de CAPTCHA modulaire, utilisable par Hiboo lui-même mais également par les applications tierces. Les premiers modules reprendront des CAPTCHA sur étagère (dont le décrié reCAPATCHA, en limitant au maximum le tracking Google associé).

Ensuite, l'authentification forte : nous projetons d'intégrer des bibliothèques d'authentification multi-facteurs, avec en premier lieu du TOTP. Plus généralement, nous souhaitons un modèle d'authentification générique pour Hiboo, où chacun peut choisir son mode d'accès : mot-de-passe, certificat client, voire qui-sait un compte sur un service tiers ? (on pense bien entendu à Facebook et Google, mais nous imaginons plutôt une fédération d'identité « à la » Fediverse, où chacun pourrait employer son compte d'une autre instance Hiboo, comme le suggérait à sa conception le standard OpenID).

Pour terminer, nous envisageons d'y intégrer nos outils de modération assez largement : gestion des comptes, blocage temporaire, suivi des rappels à l'odre, prise en compte des requêtes externes (administratives et judiciaires principalement), blocage rapide d'URL, etc.

Une chose est certaine : nous ne manquons pas de travail. Aujourd'hui une poignée à contribuer, nous espérons que les concepts proposés dans Hiboo séduiront d'autres hébergeurs associatifs. Ce sont les retours de la communauté, et idéalement les contributions à la conception et au code, qui décideront du succès de Hiboo.


from Erin Carson

I may receive compensation for some referrals to these services.

Where You Can Find My Terrible Opinions In Other Forms
Minds (Referral Link) – TwitterSaiditMemes Page

RSS: BlogRedditYouTubeTwitch

Less Used – Give me a follow if you are already there
Micro Blog: FreeSpeachExtremistTelegramGab Social
Blog: WordPressMindsTedomum
Images: PinterestimgurInstagramFlickr
Video: BitChute (Referral) – YouTubeTwitch Forum: RedditQuoraUnsilenced Voice Other: LinkedInAbout MeFrendica op V M

Backup lists of links: LinktreeWall of Me
Suspended, Banned, Blocked, Locked: Yay!


from TeDomum

Docker et les journaux

Nous sommes en 2019 et l'on raffole de Docker. En particulier chez TeDomum, nous l'employons pour rationaliser nos travaux de déploiement et de configuration, pour faciliter le partage. Par exemple, l'ensemble de nos services, y compris les services d'infrastructure (sauvegardes, journalisation, statistiques, etc.) est déployé sous forme d'images Docker disponibles à tous et de projets Compose accessibles publiquement, ce qui assure que créer un hébergeur identique est l'affaire de quelques heures, et qu'on bénéficie de facto des mises à jour.

Les écoles varient, mais l'un des patterns usuels de gestion des journaux sous Docker consiste à employer exclusivement la sortie d'erreur et la sortie standard, puis confier à Docker le routage des messages. Cette approche est critiquable par beaucoup d'aspects, surtout son manque de souplesse, mais compense en simplicité et fait presque aujourd'hui l'unanimité. Elle a cela aussi d'avantageux que les choses fonctionnent bien, sans trop de complexité initiale, par exemple pour afficher les journaux du service app d'un projet Compose :

docker-compose logs --tail=100 app

Centraliser les journaux

Lorsqu'on commence à gérer des dizaines de projets Compose sur plusieurs serveurs, même plus généralement quand on multiplie les équipements et les services, il est de bon goût de centraliser rapidement les journaux. Cela permet non seulement de faciliter la détection de défaut avec des jeux d'alertes, mais c'est aussi bénéfique pour la gestion de la vie privée et des libertés : un point unique où les journaux peuvent être systématiquement nettoyés de leurs adresses IP, logins, autres informations personnelles ; un point unique où la rétention peut être limitée conformément à la jurisprudence européenne.

Plusieurs outils et standards pour ça : – syslog, historique mais très robuste, supporte chiffrement et signature des messages ; – Elastic, en appelant directement les endpoints d'un ElasticSearch pour y injecter des objets formattés JSON ; – Splunk, propriétaire et assimilable à une API HTTP ; – GELF, transporté en TCP, UDP ou HTTP, formalisé par Graylog et spécialisé pour le transport de journaux.

Historiquement, TeDomum utilisait Graylog pour la gestion de ses journaux, et nous avions donc favorisé GELF pour les transporter directement depuis le démon Docker. La configuration est simple (extrait de notre daemon.json de configuration Docker :

    "log-driver": "gelf",
    "log-opts": {"gelf-address":"udp://logs.server.hostname:12201"}

C'est une architecture simplissime, qu'on recommande vivement à quiconque gère une petite infrastructure à base de Docker. Attention toutefois à ce que les communications soient bien protégées (réseau privé) entre les hôtes et le serveur de journaux, de sorte que les traces ne soient pas interceptées.

Ses principaux défauts :

  • la consommation de stockage (qu'on se le dise, un index Graylog doublé de son ElasticSearch pour la recheche, cela consomme plus de 5 fois le volume des journaux ingérés ; TeDomum le payait de 50Go assignés au journaux pour une semaine de rétention environ) ;
  • la consommation en RAM (de même, pour un moteur applicatif sur OpenJDK accompagné d'un ElasticSearch, compter au minimum 3Go) ;
  • on ne collecte que Docker en l'état.

Fluentd pour plus de souplesse

S'agissant de collecter les journaux système, nous employons actuellement journald sur tous nos hôtes car déployé nativement sous notre distribution, Debian Buster.

Malheureusement, journald n'implémente pas de transmission de journaux au format GELF, un agent intermédiaire est donc nécessaire. Les principales technologies sont à ce titre :

  • rsyslog, originalement orienté syslog mais aujourd'hui très généraliste pour router des messages, sa configuration est malheureusement complexe ;
  • Logstash, très accessible et composant essentiel de ELK, gourmand en ressources toutefois ;
  • Fluentd et son petit frère FluentBit bien plus légers et toujours accessibles.

Par principe conservateur, nous avons opté pour Fluentd en attendant un support plus large de la communauté de FluentBit. Déjà franchement léger (compter quelques dizaines de Mo, au pire 200Mo pour une instance), l'agent est capable de traiter de nombreux types d'entrée et de les router vers la même variété de destinations (ElasticSearch, Mongo, fichiers plats, tout y passe, et les modules existent pour étendre). En prime, Docker supporte officiellement le format d'entrée natif, et il existe un module natif pour journald, impeccable !

Nous avons donc imaginé une infrastructure simple, reposant sur Fluentd déployé localement sur chaque hôte ; il peut même y effectuer des pré-nettoyages et pré-traitements. Chaque Fluentd rappatrie ses journaux collectés de Docker et de journald vers un serveur central assurant le processing et le stockage.

Loki, petit nouveau très complet

TeDomum emploie déjà Prometheus pour collecter l'ensemble de ses métriques. Même notre robot de supervision Anna publie des métriques Prometheus sur la supervision des services (combien de temps met un message pour être délivré de chez nous à tel ou tel fournisseur de mails, etc.) Nous consultons ces métriques collectées via Grafana, leader libre de la visualisation de métriques. Grafana est très complet et nous sert dans de nombreux cas d'investigation ; il était auparavant employé aux côtés de Graylog pour la consultation.

Il y a quelques mois, Grafana annonçait la sortie de Loki, une solution de centralisation de journaux façon Prometheus : légère, reposant sur des principes simples mais performants, et surtout complètement intégrée à Grafana. Il faut l'avouer : pouvoir afficher côte à côte les statistiques d'accès à un service et les journaux de ce service, difficile de refuser.

Nous avons donc expérimenté avec Loki, et avons abouti à une configuration plutôt simple mais solide. Nous pouvons aujourd'hui en une seule requête : {"app": "mastodon"} ou {"service": "db"} cibler les statistiques et les journaux d'un type de service, d'une application entière et les affichers sur une même fenêtre.

Loki et Prometheus

Nous avons donc orienté notre configuration Fluentd pour employer Loki en moteur de stockage, ce qui s'avère plutôt aisé avec un plugin développé officiellement par Grafana.

Un déploiement sans encombre

Après une phase de laboratoire, quelques jours d'expérimentation sur une fraction de notre production, la décision était prise jeudi 9 de profiter d'un redémarrage – mise à jour oblige – pour basculer le premier de nos serveurs entièrement sous Fluentd et Loki côté journalisation.

Pour l'occasion, nous avons déployé Fluentd dans un conteneur local, qui écoute sur un socket unix :

  @type unix
  @id in_docker
  @label docker

  path /var/log/fluentd.socket

Et Docker qui pointe ses journaux vers le socket :

    "log-driver": "fluentd",
    "log-opts": {
        "fluentd-address": "unix:///var/log/fluentd.socket",
        "fluentd-async-connect": "true",
        "fluentd-retry-wait": "30s"

Le choix de la connexion asynchrone est nécessaire, puisque Fluentd étant lui-même conteneurisé, Docker ne parvient à lancer aucun conteneur tant que le service n'est pas disponible sur le socket.

Après un premier déploiement réussi, la même configuration est appliquée partout. Rapidement l'ensemble des journaux remonte vers Loki : un bonheur.

Et les ennuis commencent...

C'est jeudi soir que les premiers ennuis se font sentir. Le symptôme est simple, plus aucun service n'est accessible sur l'un de nos serveurs : joke. Naturellement on fait le lien avec le nouveau déploiement, mais comme plusieurs mises à jour ont également été appliquées, rien n'est évident.

Un diagnostic rapide montre que les services eux-mêmes ne sont pas en défaut, mais que le frontal traefik ne répond plus aux requêtes (il n'accepte même plus de connexion TCP). Qu'à cela ne tienne, avant d'investiguer, on le redémarre pour rétablir le service :

docker-compose restart traefik                                                                                         
Restarting front_traefik_1 ...                                                                                                                                                                                                                                                                   
ERROR: for front_traefik_1  UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=70)                                
ERROR: An HTTP request took too long to complete. Retry with --verbose to obtain debug information.                                               
If you encounter this issue regularly because of slow network conditions, consider setting COMPOSE_HTTP_TIMEOUT to a higher value (current value: 60). 

Le stress grimpe un petit peu, et pour rétablir les choses assurément, on redémarre le démon Docker et l'ensemble des services. Tout rentre dans l'ordre, un « glitch » passager tente-t-on de se rassurer. Le diagnostic matériel ne donne par ailleurs aucune information, rien non plus dans les journaux système ou noyau.

Un « glitch » passager

S'il y a une chose acquise depuis qu'on administre un hébergeur, c'est qu'un « glitch » passager n'existe pas. On s'en rassure, mais il y a toujours une cause derrière chaque défaut, et souvent elle revient à la charge.

Vendredi, ce n'est pas un mais trois plantages du même serveur, joke, auxquels nous avons fait face. Très difficile à vivre pour un hébergeur habitué à quelques défauts mais rarement de panne générale. Aussi, en fin d'après midi, pas enclins à passer la nuit à surveiller les compteurs, on décide de rappatrier sur une autre machine nos services les plus délicats.

En parallèle, on investigue rapidement. Le défaut semble lié à un gros volume de journaux comme en témoigne les statistiques (en octets par seconde reçus par Loki). On distingue parfaitement les horaires des trois dénis de service :

Stats logs

Ces statistiques sont effectivement corrélées avec l'émission réseau par le conteneur Fluentd sur joke :

Stats fluentd

Malheureusement, il ne semble pas qu'un seul de ces journaux reçus apparaisse dans Loki ; on ne sait donc pas qui les génère ni pourquoi ils empêchent Fluentd ou traefik de fonctionner. Les statistiques CPU laissent tout de même entendre que PeerTube est particulièrement actif au moins sur l'un des défauts :

Stats CPU Peertube

On décide de conserver PeerTube sur joke pour ne pas risquer d'impacter les autres hôtes et on projette d'investiguer pendant le week-end.

Vers un début de solution

A notre surprise samedi, c'est l'hôte où l'on a justement migré les services qui fait défaut. Une fois, puis deux. On s'apprête à conclure que c'est l'un des services migrés qui déclenche le bug lorsque joke tombe à nouveau : nos certitudes s'effondrent.

Toutes nos hypothèses à l'eau, on profite du défaut de joke sans service critique pour investiguer plus tranquillement. D'abord, on confirme le volume de journaux importants à chaque plantage ; ils n'apparaissent toujours pas dans Loki pour une raison qu'on ignore – un défaut de parsing suppose-t-on – aussi on active une copie locale dans un fichier.

<match **>
  @type copy

    @type loki
    @type file
    path /logs/fluentd.log

Egalement, en tentant d'isoler le défaut de Docker on constate que seul le conteneur traefik est impacté. Le reste fonctionne impeccablement, et aucun autre timeout n'est constaté. Dernier pas en avant (et pas des moindres) dans notre réflexion, redémarrer le conteneur Fluentd résoud le problème.

Non seulement cela nous offre une solution meilleur marché que redémarrer l'ensemble des services si le défaut se reproduit, mais cela confirme une chose : le lien clair avec Fluentd. Notre hypothèse à ce stade : quelque chose déclenche le traitement d'un gros volume de journaux dans Fluentd ; puis soit la forme soit le seul volume de ces journaux rend Fluend inopérant, y compris sur son socket (ce qui est normalement impossible grâce au mécanismes internes de buffer de Fluentd) ; Docker, ne pouvant écrire sur le socket de logs, refuse de traiter la sortie standard et la sortie d'erreur des conteneurs ; traefik est bloquant dans son écriture de journaux et se retrouve donc inopérant.

On laisse l'infrastructure en l'état en espérérant que les traces générées par un plantage prochain offriront quelques éclairages.

Le déni de service auto-infligé

Les traces n'ont pas tardé à tomber ce dimanche, nous n'avons pu les analyser que ce matin.

-rw-r--r--   1 root  root    244M May 12 13:01 fluent.log.20190512_0.log
-rw-r--r--   1 root  root    244M May 12 21:19 fluent.log.20190512_1.log
-rw-r--r--   1 root  root    244M May 12 22:17 fluent.log.20190512_2.log
-rw-r--r--   1 root  root    244M May 12 22:17 fluent.log.20190512_3.log
-rw-r--r--   1 root  root    244M May 12 22:17 fluent.log.20190512_4.log
-rw-r--r--   1 root  root    244M May 12 22:17 fluent.log.20190512_5.log
-rw-r--r--   1 root  root    244M May 12 22:18 fluent.log.20190512_6.log
-rw-r--r--   1 root  root    244M May 12 22:18 fluent.log.20190512_7.log
-rw-r--r--   1 root  root    244M May 12 22:18 fluent.log.20190512_8.log
-rw-r--r--   1 root  root    244M May 12 22:18 fluent.log.20190512_9.log
-rw-r--r--   1 root  root    212M May 13 02:46 fluent.log.20190512_10.log
-rw-r--r--   1 root  root    244M May 13 09:36 fluent.log.20190513_0.log
-rw-r--r--   1 root  root    244M May 13 09:36 fluent.log.20190513_1.log
-rw-r--r--   1 root  root    244M May 13 09:36 fluent.log.20190513_2.log
-rw-r--r--   1 root  root    244M May 13 09:37 fluent.log.20190513_3.log
-rw-r--r--   1 root  root    244M May 13 09:37 fluent.log.20190513_4.log
-rw-r--r--   1 root  root    244M May 13 09:37 fluent.log.20190513_5.log
-rw-r--r--   1 root  root    244M May 13 09:37 fluent.log.20190513_6.log
-rw-r--r--   1 root  root    244M May 13 09:37 fluent.log.20190513_7.log
-rw-r--r--   1 root  root    244M May 13 09:37 fluent.log.20190513_8.log

À 22h18 dimanche, puis à 9h37 ce matin, les horaires des derniers sursauts du serveur correspondent parfaitement à une flanquée de journaux écrits par Fluentd, comme nous l'attendions ! Pour ne pas tomber dans le défaut de parsing on les analyse avec des moyens simples : grep, awk et sort font l'affaire.

D'abord on confirme que PeerTube est à l'origine du plantage dans chacun des cas. Clin d'œil à l'ami virtualab qui a dû faire la publicité de son blog tout récemment, et quelques visiteurs parcourent ses pages où une vidéo PeerTube est intégrée, le client PeerTube générant beaucoup de requêtes pour charger la vidéo par morceaux. Il n'empêche que ces quelques 1000 requêtes par seconde consomment un petit peu de CPU sur les frontaux et PeerTube lui-même, mais ne devraient certainement pas inquiéter Fluentd, par ailleurs habitué à traiter des millions de lignes de journaux par seconde.

On se concentre donc sur les traces de Fluentd lui-même et la réponse n'est pas bien loin :

2019-05-12T20:17:13+00:00       dad34f22107c    {"container_id":"xxx","container_name":"/agents_fluentd_1","source":"stdout","log":"2019-05-12 20:17:13 +0000 [info]: #0 sending 5714975 bytes","app":"agents","service":"fluentd","tag":"agents.fluentd","instance":"joke"}
2019-05-12T20:17:14+00:00       dad34f22107c    {"container_name":"/agents_fluentd_1","source":"stdout","log":"2019-05-12 20:17:14 +0000 [warn]: #0 failed to POST http://logs.hostname:3100/api/prom/push (500 Internal Server Error rpc error: code = ResourceExhausted desc = grpc: received message larger than max (5186961 vs. 4194304)","container_id":"xxx","app":"agents","service":"fluentd","tag":"agents.fluentd","instance":"joke"}

Suivi d'une description précise des messages qui n'ont pas pu être émis :

2019-05-12T20:17:14+00:00       xxx    {"log":"2019-05-12 20:17:14 +0000 [warn]: #0 {\"streams\":[{\"labels\":\"{app=\\\"video\\\",service=\\\"peertube\\\",tag=\\\"video.peertube\\\",instance=\\\"joke\\\"}\",\"entries\":[{\"ts\":\"2019-05-12T20:17:03.644103Z\",\"line\":\"container_id=\\\"xxx\\\" container_name=\\\"/video_peertube_1\\\" source=\\\"stdout\\\" log=\\\"[video.tedomum.net:443] 2019-05-12 20:17:03.643 \\u001B[32minfo\\u001B[39m: 2a01:: - - [12/May/2019:20:17:03 +0000] \\\"GET /static/webseed/01cd2292-e4e3-4b61-bb74-a4fbdb704f32-360.mp4 HTTP/1.1\\\" 206 16384 \\\"https://video.tedomum.net/videos/embed/01cd2292-e4e3-4b61-bb74-a4fbdb704f32\\\" \\\"Other\\\"\\\"\"},{\"ts\":\"2019-05-12T20:17:03.784652Z\",\"line\":\"container_name=\\\"/video_peertube_1\\\" source=\\\"stdout\\\" log=\\\"\\\" container_id=\\\"xxx\\\"\"},{\"ts\":\"2019-05-12T20:17:03.786381Z\",\"line\":\"log=\\\"[video.tedomum.net:443] 2019-05-12 20:17:03.644 \\u001B[32minfo\\u001B[39m: 2a01:: - - [12/May/2019:20:17:03 +0000] \\\"GET /static/webseed/01cd2292-e4e3-4b61-bb74-a4fbdb704f32-360.mp4 HTTP/1.1\\\" 206 16384 \\\"https://video.tedomum.net/videos/embed/01cd2292-e4e3-4b61-bb74-a4fbdb704f32\\\" \\\"Other\\\"\\\" container_id=\\\"xxx\\\" container_name=\\\"/video_peertube_1\\\" source=\\\"stdout\\\"\"},{\"ts\":\"2019-05-12T20:17:03.786593Z\",\"line\":\"container_id=\\\"xxx\\\" container_name=\\\"/video_peertube_1\\\" source=\\\"stdout\\\" log=\\\"\\\"\"},{\"ts\":\"2019-05-12T20:17:03.786793Z\",\[... suivi de 5Mo de logs non émis]

Fluentd, non content de n'avoir pu émettre un bloc de 5Mo de journaux (qui correspondent à 10s de trafic intense sur PeerTube) comme cette taille dépasse le maximum accepté par Loki, journalise cette erreur en incluant le contenu... des journaux qui n'ont pas été émis. Vous connaissez la suite : Fluentd lui-même est journalisé par Docker, ces quelques 5Mo, gonflés par une batterie d'anti-slash d'échappement, sont rapidement réinjectés dans la boucle, et le tout dépasse à nouveau 5Mo en générant une erreur du même accabit. Effet Larsen.

Comme tout se déroule localement, les choses vont vite. Très vite. Après quelques millisecondes, les journaux internes de Fluentd ressemblent plutôt à :

log":"\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\[... quelques Mo d'anti-slashs]

Au bout d'une seconde environ, Fluentd ne peut plus conserver ces journaux dans ses buffers et s'effondre en bon guerrier.

On trouve rapidement une solution et l'on patch, en limitant la taille des blocs envoyés à Loki d'une part pour ne plus générer cette erreur, mais également en configurant Fluentd pour ne passer par... Fluentd :

On avait pourtant testé !

Et c'est vrai. Certes pas pendant des mois, mais une petite semaine a vu les journaux de production de pas mal de conteneurs, dont traefik, pointer vers un Fluentd de test afin d'évaluer le bon fonctionnement. Comment se fait-il donc que le défaut n'ait pas été identifié avant un déploiement global ?

C'est que les conditions de tests ont consisté à rediriger spécifiquement chaque conteneur testé vers Fluentd, et jamais Fluentd lui-même. Egalement, les quelques heures de tests en production sur le premier serveur déployé n'ont pas été suffisantes pour déclencher le bug qui dépend grandement du trafic entrant (il est rare en temps normal de générer plus de 1Mo ou 2Mo de journaux toutes les 10 secondes).

Une bonne leçon pour ne pas oublier de tester et de qualifier en conditions au plus près de la production. Avec le recul, ce fut l'un des bugs les moins évidents à investiguer depuis qu'on administre TeDomum.


from ACCEL

Arizona Centers for Comprehensive Education and Life Skills

ACCEL has provided a continuum of special needs services since 1980, now serving 450 clients each year through our three major service offerings: our BISTA Applied Behavioral Analytics (ABA) therapeutic program for early intervention, our private nonprofit school system serving students from age 5-22 and our Adult Services Program that gives adults with disabilities a place to learn and grow. We specialize in providing a safe and encouraging learning environment so individuals can maximize their potential as they lead lives of dignity and self-worth.


from TeDomum

Pour protéger les données, la vie privée, et les libertés de nos utilisateurs, nous croyons en une solution par l'hébergement distribué – acentré – où ni les risques ni les pouvoirs ne sont concentrés. Aussi, TeDomum est le fruit de travaux sur ce thème débutés bien avant la déclaration de l'association. Les prémisses remontent à 2005 ; Google était surtout un moteur de recherche, Facebook n'était que l'embryon du géant que nous connaissons, l'iPhone n'existait pas et Apple était presque un acteur de niche. Pourtant déjà les vieux avaient flairé la réalité à venir. Derrière l'Internet tel qu'il avait débuté, Multimania, iFrance et quelques publicitaires élaboraient des modèles commerciaux basés sur la centralisation et l'enfermement : devenir principal hébergeur de sites Web – la principale source de contenu à l'époque – c'était s'assurer une visibilité en tant que régie, donc un revenu.

2005, c'était aussi les premiers pas de la LCEN. Le souvenir du procès Altern encore chaud, le législateur venait de déresponsabiliser largement les hébergeurs. Cela profitait évidemment aux quelques gros en devenir, mais aussi aux fournisseurs modestes proposant de publier un site Web pour pas grand chose et sans restriction à ceux qui ne disposait pas de la connexion nécessaire pour le faire chez soi. Dans le texte, un chapitre complet consacré aux prestataires techniques définit précisément le rôle et les responsabilités des intermédiaires sur l'Internet ; l'article 6 s'attaque à la position des hébergeurs de contenu, qui ne sont donc pas auteurs ou publicateurs du contenu qu'ils diffusent pourtant techniquement :

(2) Les personnes physiques ou morales qui assurent, même à titre gratuit, pour mise à disposition du public par des services de communication au public en ligne, le stockage de signaux, d'écrits, d'images, de sons ou de messages de toute nature fournis par des destinataires de ces services ne peuvent pas voir leur responsabilité civile engagée du fait des activités ou des informations stockées à la demande d'un destinataire de ces services si elles n'avaient pas effectivement connaissance de leur caractère illicite ou de faits et circonstances faisant apparaître ce caractère ou si, dès le moment où elles en ont eu cette connaissance, elles ont agi promptement pour retirer ces données ou en rendre l'accès impossible.

La voie était ouverte ; les textes, certes un peu flous mais appuyés par une jurisprudence, permettaient une plus grande latitude dans le rôle d'hébergeur. Cette latitude était balancée par l'obligation de rétention des données de connexion afin que l'auteur d'un contenu puisse être identifié et poursuivi en cas d'infraction. En particulier, les petits hébergeurs n'avaient plus à craindre de devoir contrôler tout le contenu de leurs utilisateurs : la responsabilité ne leur incombait pas tant qu'ils n'étaient pas mis au courant. Une route toute tracée vers un Internet bien acentré, le succès d'intiatives comme le RHIEN, le tout dans la neutralité et le respect des libertés individuelles, non ? Non.

Les faits sont simples : dans les années 2000, tous les passionnés et la moitié des intéressés se retroussaient les manches pour assembler une page Web, les plus aguerris administraient des services en tous genre, et l'ensemble n'était pas systématiquement hébergé chez Amen. Dans les années 2010, tous les Internautes se font guider pour créer une page Facebook et les entrepeneurs un site Wix, des services privés (et privateurs) disposent d'un monopole sur les technologies pourtant intrinsèquement ouvertes. Ce monopole s'inscrit dans la simple continuité du modèle économique d'enfermement avancé par feu-Multimania : il est nécessaire de concentrer l'audience chez quelques acteurs pour la rentabiliser en tant que régie – et nouveau marché obligeant, pour collecter et revendre un maximum de données personnelles.

Le régime plus souple a profité aux plus gros, également nourris par la nouvelle ère du commerce de la surveillance. Et c'est soudain en Europe, alors que le RGPD peine justement à responsabiliser les internautes et les fournisseurs à la protection des données personnelles, que fleurit le débat sur la « directive copyright », portant largement sur les mesures de protection du droit d'auteur sur Internet. L'objet n'est pas ici d'en commenter trop en détails le contenu, car bonne nouvelle : pour une fois, le texte est digeste, loin des 200 considérants du RGPD, le tout tien en moins de 50 pages et est disponible sur le site de l'union (la version consolidée n'est pas encore mise en forme à notre connaissance, nous mettrons le lien à jour au besoin, en attendant l'amendement 271 est disponible en PDF). Il n'est pas non plus question d'aborder la pertinence du sujet de la directive ou des moyens déployés, la Quadrature a par exemple développé le très bon argument de la soumission au marché de la surveillance de masse. Plutôt très égoïstement, nous abordons la principale nouveauté pour un acteur comme TeDomum, le fameux article 13 : contrairement à la déresponsabilisation apportée par la LCEN, l'hébergeur devient responsable sous certaines conditions et se voit attribuer une obligation de moyens pour lutter contre les infractions au droit d'auteur.

Principal moyen rendu obligatoire par le texte maintenant validé : la coopération avec les titulaires des droits pour tout ce qui concerne la mise à disposition de contenu au public. Suggérée également, la mise en place de dispositifs automatiques et systématiques pour forcer l'application des conventions que nous aurions établies en coopérant avec les titulaires. Autrement dit : petit hébergeur, nous devrions engager des moyens administratifs pour décider en accord avec les ayants droits d'une posture et d'un régime quant à la publication d'œuvres sur notre plateforme. Avant même de réflechir à mettre en place techniquement les dispositions convenues, l'idée même que nous soyons reçus pour échanger d'égal à égal avec les ayants droits est surréaliste – même en dépêchant les représentants d'un collectif de petits hébergeurs –, l'application de la directive est donc irréalisable à notre échelle.

Seulement les dernières versions du texte ont complexifié les règles, et un paquet d'analyses publiées (par exemple par Arte, ou des YouTubers) sont rassurantes quant à l'avenir des plateformes de diffusion de contenu. Il faut modérer. Ce qui a changé d'abord (pour rappel la version originale du texte, l'article 13 étant renuméroté en 17) :

  • le paragraphe 4. est découpé en trois obligations, celle d'obligation de moyens pour obtenir une autorisation des ayants droits (a priori, de tous les ayants droits), celle d'obligation de moyens pour empêcher les infractions à l'autorisation – ou en l'absence les infractions au droit d'auteur en général –, et une obligation de résultats en cas d'infraction pour oter le contenu du site ;
  • le paragraphe 5. indique que les obligations de moyens et résultats doivent être appréciées en fonction du type, de la taille et de l'audience, ainsi que des moyens de la plateforme ;
  • le paragraphe 6. crée une exception pour les entités de moins de 3 ans, moins de 10M€ de chiffre d'affaire, et une contre-expception pour le sites cumulant plus de de 5M visiteurs par an ;
  • le paragraphe 7 rappelle et confirme que les exceptions au droit d'auteur continuent de courir, en particulier concernant la citation et la caricature.

Il va sans discuter qu'une partie des précisions apportées est rassurante. Celle qui a essuyé la sueur de la plupart des critiques : le maintien de l'exception pour caricature ou critique, qui sauve le modèle des principales plateformes où bloggeurs et chroniqueurs postent leurs productions. Sauvés pour autant ? pas encore. Les précisions protègent :

  • les principales plateformes qui appliquent déjà des filtres automatiques et disposent d'une armée d'avocats, mais ne peuvent se permettre de perdre l'auditoire des chroniqueurs vidéos qui commentent sur – insérer au choix sorties cinéma, séries, livres, jeux, etc. ;
  • les startups qui chercheraient à les concurrencer mais ne seraient pas immédiatement rentables ou populaires ;
  • les plateformes touchant à l'éduction et l'enseignement, bien que pas explicitement inquiétées.

Ce qui nous tire a priori de l'embaras tient plutôt dans les modifications de l'article 2 portant définitions pour le texte et dans l'ajout du considérant 62.

(62) Certains services de la société de l’information sont, dans le cadre de leur utilisation normale, conçus pour donner au public l’accès aux contenus ou autres objets protégés par le droit d’auteur que leurs utilisateurs téléversés. La définition de fournisseur de services de partage de contenus en ligne prévue par la présente directive ne devrait cibler que les services en ligne qui jouent un rôle important sur le marché des contenus en ligne en étant en concurrence pour les mêmes publics avec d’autres services de contenus en ligne, comme les services de diffusion audio et vidéo en flux continu. Les services couverts par la présente directive sont les services dont l’objectif principal ou l’un des objectifs principaux est de stocker et de permettre aux utilisateurs de téléverser et de partager une quantité importante de contenus protégés par le droit d'auteur en vue d’en tirer un profit, directement ou indirectement, en organisant et en promouvant ces contenus afin d’attirer un public plus large, y compris en les classant et en faisant une promotion ciblée parmi ceux-ci. Ces services ne devraient pas inclure les services qui ont un objectif principal autre que celui de permettre aux utilisateurs de téléverseret de partager une grande quantité de contenus protégés par le droit d’auteur en vue de tirer profit de cette activité.


Article 2 – 5. « fournisseur de services de partage de contenus en ligne », le fournisseur d’un service de la société de l’information dont l’objectif principal ou l’un des objectifs principaux est de stocker et de donner au public l’accès à une quantité importante d’œuvres protégées par le droit d’auteur ou d’autres objets protégés qui ont été téléversés par ses utilisateurs, qu’il organise et promeut à des fins lucratives.

S'il semble à première lecture que nous ne cochions pas la case de la fin lucrative, une partie de nos services répond sans conteste au reste de la définition. La subtilité est illustrée dans la Directive par les encyclopédies en ligne ou les plateformes de partage de code, mais rien ne fait référence aux outils de l'expression libre que nous contribuons à mettre en place, tels que Mastodon, PeerTube ou Pixelfed ; c'est probablement que le cas des hébergeurs de notre taille n'était pas à l'esprit du groupe de travail qui a rédigé l'amendement. Vu la délicate question de la modération sur le Fédiverse, la position des lobbies et d'une partie de la classe politique française sur le droit d'auteur, nous craignons évidemment que la nuance soit effacée dans la traduction en droit national et que malgré l'exception pour Wikipedia et autres encyclopédies, les petits hébergeurs deviennent vulnérables légalement, annulant les dispositions protectrices de 2004.

L'idée était séduisante que d'attaquer légalement les monopoles de la diffusion de contenu sur Internet. Après tout, c'est à cela que tient aujourd'hui notre liberté d'expression. Mais en les attaquant pour de mauvaises raisons (satisfaire financièrement les quelques bénéficiaires du droit d'auteur, et non protéger les créateurs ou la liberté d'expression – tirer profit des monopoles plutôt que de limiter leur pouvoir) et avec de mauvais outils (en contraignant tout le monde – y compris la concurrence – plutôt qu'en favorisant des alternatives), le résultat nous effraie en tant que petit hébergeur. Enfin, même si elle nous concerne peu, la Directive crée de la complexité. Le démêlement du corpus légal qui entoure l'activité d'hébergement, où le régime général de responsabilité limité de 2004 cède progressivement la place à des régimes spécifiques – sur le droit d'auteur ici, la lutte anti-terroriste là- rend l'aventure plus difficile et plus risquée pour les acteurs de la décentralisation.

Plus délicat encore, si la directive copyright traite exclusivement du droit d'auteur, la question de la responsabilité quant à la mise à disposition du public de contenus illicites en général promet un débat d'autant plus guidé par l'émotion que seront abordés les cas de l'incitation à la haine, de l'apologie du terrorisme, ou de la pédo-pornographie. Mais restons positifs, car indépendamment de l'hypothétique législation que nous ne pourrions de toute façon pas appliquer, chaque nouvel utilisateur de nos services et chaque nouvel hébergeur que nous inspirons ou aidons est un progrès concret vers plus de sécurité, de libertés, et un meilleur respect de la vie privée.