Greta . (German . Trutzteutsch)

Barely avoiding a first German aus gegebenem Anlass post here.😞

Hier Kommt Alex	Klapperstrauss
Clockwork Orange	Brave New World
Random Acts of Senseless Violence	Lord of the Flies

#NetzOhneGewalt

I miss you × I know it when I see it

A short episode in the YouTube vs. users series:

1. Too much transparency, it is none of my business who claimed the copyright for a now deleted video, unless I uploaded it.
2. Not enough transparency, I need a notification if a video in one of my playlists is deleted.

Background, a triple strike on Björk in In principio (pt. 1: 1970-1999): Human Behaviour v=KDbPYoaAiyc is now v=36Srr08PN_Y, I miss you v=IKSoBJ8WirE is now v=ybDX_5hQ6So (non-adult version), and Hunter v=CyM5wow-hUk is now v=DnW77jmr-Xg.  There are lots of I miss you versions on YouTube, but I cannot tell if one of them is the wannabe-adult version for a playlist about YouTube's Community Guidelines. Or in other words, I removed I miss you from the Guidelines playlist, because there is still another "uncensored" (age-restricted) Pagan Poetry video by Björk in it, and I replaced it in the 1970-1999 playlist.

While at it, the deleted Declare Independence v=4z7NN4n8CTY in In principio (pt. 2: 2000-2019) is a major loss, I'm not going to find and fix all posts here, where I embedded this master piece. IMNSHO this is a bug, YouTube could simply redirect its URL to the still existing identical v=4P5xSntVWQE. Don't let them do that to you … Raise your flag:

Just for the records, the (apparently) deleted account issue (2) has nothing to do with the leaked copyright strike issue (1), only the platform (YouTube) and the effect (deleted video) are similar.

Chilling effects

Google whining about chilling effects of, e.g., EU privacy laws, makes no sense while their own YouTube Community Guidelines are a major part of the problem.  For 1/10 sec "male body part" in a historic (2008) 44 sec bonus scene of the 9to5 documentary I'm willing to find a compromise such as "blur" or even skip some frames.

OTOH 4 sec "woman douching" in a historic (2010) 214 sec interview by Clara Cullen are definitely not sexually gratifying, NSFW, or whatever.  Folks searching for four-letter words in video titles on YouTube—for the purpose of reporting this, anybody really interested in Pron would try PronHub—might be another part of the problem, but just accepting obviously bogus reports doesn't help to solve it.

Transparency report 2018	Transparency report 2019 (so far)
	…uploaded on March, 14 (PT)

YouTube Got Talent (pt. 2)

Next musician in need of some serious WikiLove, she's not even one of those women in red at the moment, and a registered #GirlsGotGroove hashtag does not help on YouTube, if nobody uses it. Unregistered used hashtags also don't work on YouTube, both cases yield a small error message for #foobar immediately followed by any ordinary search results for foobar without #.

After some religious debates with myself I finally kicked Sina's drum covers as not good enough from the In principio (pt. 1) + (pt. 2) playlists, and then upgraded some original tracks incl. Deep Purple's Child In Time in the Religiously Incorrect + Toxic Waste playlists to Sina's 201x versions. Maybe some purists scream, but as you could have read in this blog there was a hard timeout in February from my PoV, so (quote) fuck it (unquote), and I've posted the source of this quote in March.

Back to April, all fine, Google+ died as planned, but without its exorcist as eye-witness, and maybe one protective spell three months ago with Deep Purple's April worked. Standard question, what could possibly go wrong? Answer: (1) Spells sometimes work. (2) If they work they sometimes backfire. Putting that together, for a time-limited protective spell, back could be in time and hit the target instead of the caster. Which might be exactly what happened, if an also convoluted explanation involving an obscure toxic forum since about November doesn't suffice. Meanwhile it's May, let's forget the Deep Purple April 2019, it's history like Google+.

I collected lots of Karma-points for the possible spell-disaster on another Emma, a bad case of woman in red fixed in record time by some enthusiasts, thanks: On Wikipedia wikilinks are shown in blue if the article exists, or in red if it does not yet exist. Meanwhile somebody uploaded the 19 images extracted from one video on WikiMedia Commons, and sadly the somebody was me: I broke a three years old WikiMedia log-in strike for this business, and on the same day I found that enwiki offers an image upload request page for these cases, tested, works.

If you missed major parts of the drama, you might wonder what happened to the Topic, VEVO, and Vloggery channels, it's explained on enwiki Emma Blackery. Of course unrelated to the five years old drama, YouTube always finds the worst points in time for changes related to this musician. Admittedly losing YouTube Heros, Rewind 2018, and Google+ to one singing Slytherin and her allies must have been hard for Alphabet, and hopefully she doesn't plan to kill Blogger just because she could. Back to music, she released the studio version of Cute Without You in April is the cruellest month:

The Google+ black list

Now that's against my rules as of (roughly) 1983 to 2018, or isn't it? Sometimes enwiki manages to surprise me, and I'm not talking about the major obstacles when not logged-in users try to add a perfectly valid film title on a biography. Admittedly Fuck  is exactly what vandals would try to write, and there's an edit filter trying to forbid it. I'm not telling you how to bypass the filter, if you don't know this you might be up to no good, and I hate vandals armed with a mobile phone and social media rumours.

JFTR, the complete title is Fuck Slaves, and I needed it to explain two different awards in one year, where the second award was related to an arguably notable film, i.e., one wikilink was required for my second good article  quest, and one statement about two awards needed both titles.

Google+ also tried to surprise me with its second "sexually explicit"  strike in a "privately shared"  (unlisted) collection. The content was a perfectly harmless review of The Juliette Society, only the domain of the publisher has an X before its BIZ. Exactly the same X before a CRIT as in the first strike for a perfectly harmless 2006 interview originally posted here (on blogspot), now again posted here (by me as embedded scribd-PDF, there's certainly no X in scribd.)

Chilling effects, I dare not post it here at the moment, Blogger could also hate the X, I only know that this is not about the content. Lame excuse, after buying the first part of the trilogy I should anyway read it before linking more reviews.

After testing the title link, this playlist is as the name says toxic. I stick to the now usual layout and added two videos here.

NSFW

NSFW definitions vary wildly, YMMV. For the Penthouse July 2007 photos by Terry Richardson In The Raw 2010 NSFW makes sense. For a perfectly harmless Kobiata interview 2006 originally posted here (on Blogger) I didn't even bother to tag it as NSFW. But G+ hated the PDF or its hoster, and deleted a post with the link in my privately shared (=unlisted) Mismade Girl collection. Chilling effects, I dare not say here where I found it, for full credits see the full description in the scribd copy.

KOBIATA interview (September 2006)	"Roadside Ass-istance" from James Gunn's PG Porn
	The Juliette Society (Huffington Post, 2013-08-27)

Transparency Report 2018

Nobody is going to delete my Chilling Effects parody:

---

Background, 9 to 5: Days in Porn is a notable  (enwiki terminology) documentary, and typically available on YouTube in mutilated versions to bypass the ContentID filters. The issue is copyright, not the four-letter word in the title. The MOV trailer is of course also not free, but intended to be shared as promo for the movie. Nobody including popular browsers knows what a MOV used to be, therefore I converted it to MP4 and uploaded it to YouTube as historic clip with credits and other related info.

The movie site also offers some bonus clips as FLV, and today that's worse than MOV. Therefore I converted one of the bonus clips to MP4, uploaded it to YouTube, and tagged it as NSFW, because less than one of the 44 seconds in this clip is NSFW. Wild guess, Deleted Scene in the title Deleted Scene: Sasha & Roxy Girls Talk wasn't helpful for the appeal, or YouTube uses a bot to reject appeals.

I know it when I see it

Playlist I know it when I see it, how dare you, YouTube, censoring Björk is, broadly construed, blasphemous:

---

Playlist Viral Videos, some kind of I love it not limited to music or heroines:

---

Experimental playlist Extreme Uplifting, omitting Perfect as not enough noise:

---

AOB: My subscriptions are public at the moment, with Semper Video as oldest, oddly I never subscribed to Semper Censeo. Update: The hardwired 425×344 looks like shit on my VAIO, width="96%" failed miserably, how about 800×450, mobile untested?

Commons

At some point in time Blogger added a Google+ tracking script to this blog, and I've not yet figured out how to get rid of this spyware. If you have a browser extension blocking wannabe-social tracking sites such as ShareMeNot this won't affect you. While at it and FWIW I have replaced the CC-BY-SA 3.0 license for this blog by 4.0, removed the dead Google Reader links, and fixed some other minor blog template rot issues.
Recently Google Sites somehow managed to clobber embedded Google Docs videos with non-existing YouTube content. Just embedding the video again can fix this. Just for fun I try this also here—for the complete story see its page on my Google site:

Upgraded 2019 (almost 5y later) to <iframe allow="" sandbox="allow-scripts allow-same-origin" referrerpolicy="origin" …>. I'm not updating older iframes in this blog if there are any.
Fun observation, blogger gave up on <p>…</p> and now firmly demands <div>…<br /><br /></div> for a simple paragraph: HTML 3.2 rulez, and I know it by heart (in its XHTML 1.0 transitional incarnation), now singing nah pop, no style. I strictly roots..

Some hours later, the docs.google video doesn't play, neither here nor on sites.google, revert doesn't help, view the video on WAYBACK or Google Photos (sic-K).

YAM (Yet Another Mail)

The ways of the IETF are completely bizarre, and the Tao of IETF does not really explain why.  In a recent episode the YAM WG will be closed after moving two of four e-mail related RFCs to STDs:

• STD 72 is RFC 6409 and covers "mail submission".  That's what ordinary users like you and me do when they send e-mail using their ISP or another ESP such as Gmail, GMX, or Hotmail.
• STD 71 is RFC 6152 and covers "8BITMIME".  That's what everybody uses since about 1993 outside of pure US-ASCII 7bit e-mail.

Oddly YAM didn't finish the work on a 5321bis and a 5322bis.  That leaves us with STD 10 (SMTP) and STD 11 (message format) in limbo, unless you still consider RFCs 821 and 822 (vintage 1982) as the ultimate truth in IETF e-mail standards.

For SPF it's quite interesting to look at the "reverse path" fine print of RFC 821, e.g.:

• The first host in the <reverse-path> should be the host sending this command. (RFC 821 about MAIL FROM).
• In any case, the SMTP adds its own identifier to the reverse-path. (RFC 821 about Relaying).

Sadly RFC 4408 specifying SPF also claims that this RFC 821 feature is archaic.  Of course today nobody uses reverse and forward paths as designed about thirty years ago for e-mail routing, but for SPF the MAIL FROM address is still supposed to indicate the responsible party for technical problems with an e-mail, also known as bounce address.  And e-mails forwarded to a third party need a new envelope sender address, otherwise SPF checks at this third party will fail, because IP-addresses authorized to send e-mail from the first party won't match IPs used by the forwarding second party.  That's as simple as it can be, ignoring the minor detail that RFC 1123 broke it about twenty years ago.

By the way, the work on 4408bis is supposed to start really soon now, but my confidence in the IETF is somewhat limited.

Google ±

Google+ wants me to join Google+, because I'm on Google+.

URL fragment vs. query part

Has Google finally reached the ultimate Microsoft state, "breaking standards for fun and for profit" ? In a recent entry on the Google Operating System blog (not affiliated with Google) two screen shots show #fragments instead of ?queries. My attempt to post a comment had no visible effect, maybe comments are moderated or the blogger template is broken or whatever the problem might be, zero feedback to users is just wrong. Google Chrome lost the content of the comment form before I could reproduce it verbatim here, in essence it said:

In URLs a hash mark "#" introduces the optional fragment at the end of the URL, and a question mark "?" introduces the optional query part — also at the end of the URL, but before any fragment.

Fragments are the local business of the client (browser) and depend on the document (MIME type). Queries are the business of the server, e.g., many servers expect name=value pairs separated by ampersands "&", other severs also permit semicolons ";" as separator, and so on.

The query syntax depends on the scheme, here http:, the details depend on the server, but in both cases the overall URL syntax would require to percent-encode "#" if it is a part of the query not intended to start the fragment.

Notably fragments do not participate in redirections from one scheme or server to another scheme or server, the target location never sees the source fragment — browsers are not expected to transmit a fragment in requests such as HTTP GET.

In other words, something is wrong in the googlesystem screen shots.

Google - you get what you paid for

With a few exceptions Google services have the unacceptable feature to be associated with an account forever. So if you test say "feedburner" once, and then decide that this is yet another data kraken and never use it again (for years), it will still be listed in the Google accounts dashboard. In theory you could delete the complete account including blogs, mails, images, videos, docs, sites, etc. — in practice folks trying this often show up in the blogger help forum whining about their lost blog and images.

Episode 1: I sent a complaint about "google moderator" to Google's privacy officer. This is actually an obscure HTML form creating no confirmation mail and no ticket number. After weeks my privacy complaint still got no reply. I'll test it again when I get around to it, complete with screenshots of the HTML form, as this isssue might require an intervention by Hamburg's privacy officer.

Episode 2: My entry in "places" is associated with an off by two photo in "maps". After a considerable amount of time I figured out how to report this issue. This actually resulted in a timely mail answer, but the mail came from a noreply bounce address offering no way to answer. My report was that they swapped the photos for house X and X+2. Sh*t happens, this was incorrect, they systematically show X+2 for X for the given street. I have no way to fix my semi-erroneous report, this is stupid. Never send noreply mail if you are not a mail-bot, this infuriates customers and users. Why should they use valid and valuable mail-addresses, when the other side uses bounce-addresses?

Episode 3: The new Chrome "apps" store apparently records all installed apps, even after they were removed. I submitted a complaint about this, because I do not recall where or when I permitted this violation of my privacy, and I certainly do not know how to withdraw this permission.

WebHop DDoS

DynDNS reports a DDoS attack against their Webhop services. This also affects xyzzy.webhop.info and xn--80akhbyknj4f.boldlygoingnowhere.org. The first address used to be a HTTP redirection to my mirror site, at the moment it is a redundant redirection to xyzzy.

The second address is used in some IDNAbis experiments with IRIs; the actual content are now subpages of xyzzy/home/googlets.

Hostile to privacy

For those who don't remember it, hostile to privacy is a code word, it stands for Google since they acquired doubleclick. To get over this negative image Google recently promoted privacy to one of the 28 words on their basic search form.

As user of several Google services I have vague ideas which host names have to be blocked at the network level for privacy, and what is anyway pointless, to some degree I trust them. Sadly, visitors of my Googlet pages will get a cookie. I have no idea why, and it is not obviously mentioned in Google's privacy policy. Likely I'm violating German privacy laws with this practise, and "but it is the server, not me" is a lame excuse. Having said this, if you don't trust Google, what do you expect here on blogger, or even on my pages dedicated to googlets ?

Another issue are third parties, just because I trust Google to some degree doesn't mean that I delegated this job to them, otherwise they could start a certificate authority in their quest to achieve world dominance. After a discussion with the HTML5 editor I feared that my trust in network.cookie.cookieBehavior 1 could be wrong, and switched this to "always ask". The effects are quite interesting, e.g., a Google search for network world tries to set a www.networkworld.com cookie. I didn't click or touch anything on the search results, but this third party tries to set a cookie.

So far still okay, switching to "always ask" is one of many ways to reset network.cookie.cookieBehavior 0, and Google offers an opt out cookie. Clearly opt out is a weasel word for net abuse today, and Google prefers to be a part of the problem.

When I set network.cookie.cookieBehavior 1 again the same site still offers its third party cookie on the search results. After some tests always restarting the browser my impression is that this setting has no effect in my BBFH. But "always ask" works, and it can be limited to "ask once" for any given site.

Leader of the pack

Keeping Internet Drafts "active" with two updates per year is a subversive tactics, but apparently already in use: Version 02 and 04 of the pack URI drafts are identical. This draft cannot be published as RFC, because its proposed URI scheme syntax is in conflict with the generic syntax in STD 66 [RFC 3986]. This is not permitted in BCP 115 [RFC 4395] about the registration of URI schemes, as noted by the URI review expert.

The pack scheme has to be fixed before it can get a permanent registry entry. The current entry is provisional, and the unmodified draft could be an attempt to prevent the reclassification of this wannabe-scheme as historical. The greater picture is that the Open Packaging Convention is a part of ECMA 376, the fast track input for ISO 29500 also known as ooXML.

No plans to transition management of the root zone file to ICANN

In a letter to the ICANN Chair published 2008-07-30 the U.S. DoC notes:

First, it is important to note that the IANA functions contract was not part of the JPA mid-term review and the Department views these as two distinct instruments. As the community is aware, the IANA functions contract covers the performance of a series of currently interdependent technical functions that enable the continued efficient operation of the Internet, including processing requests to change the authoritative root zone file. Implementations of changes to the authoritative root zone file are performed by VeriSign under the terms of a separate agreement with the Department.

The Department believes that it is important to clarify that we are not in discussions with either party to change the respective roles of the Department, ICANN or VeriSign regarding the management of the authoritative root zone file, nor do we have any plans to undertake such discussions. Consistent with public statements made by the United States governement starting in 2000 and reinforced by the 2005 U.S. Principles on the Internet's Domain Name and Addressing System, the Department, while open to operational efficiency measures that address governments' legitimate public policy and sovereignty concerns with respect to the management of their ccTLD, has no plans to transition management of the authoritative root zone file to ICANN as suggested in the PSC documents.

In an article about the All important IANA the author wrote: An ICANN that is completely privatised and does not behave well afterward also might easily be stripped from the IANA contract and therefore its grip on the root zone.

Frisian frs vs. stq

Before 2006 there was only one language tag for the Frisian languages, fy. 2005-11-16 ISO 639.2 identified fy as Western Frisian, adding frr for Northern Frisian, and frs for Eastern Frisian. So far it is clear, ignoring the detail that Northern Frisian consists of several rather different dialects.
 
After the publication of RFC 4646 the IANA language subtag registry now contains fy, frr, and frs. But not fry, this is an alpha-3 alias of fy, and the RFC 4646 rules are roughly that shorter alpha-2 ISO 639 codes win.
 
It is not obvious what the Y, R, and S in these subtags stand for, one plausible theory is that S stands for Seeltersk, the Frisian language spoken in Saterland; see the S marker on the map.
 
Interestingly ISO 639-3 uses stq instead of frs for this language, this is also the code used for the stq.wikipedia. Two alpha-3 ISO 639 codes for one language are rather strange, and there is another theory to explain this situation: frs is the code of the Lower Saxon nds dialect spoken in Eastern Frisia, the territory including Aurich at the A marker on the map. In that case the S might stand for Saxon.

The ISO 639-2 rules make it fairly difficult to get codes for nonsense, there must be some evidence what they had in mind when frs was registered. OTOH with codes such as eur and tlh Occam's razor might miss the point.

HTML5: asinine + selfish

HTML5 "reuses the well-known URL moniker in the most asinine way, and blames the other standards (which he thankfully has no control over) for not supporting all of the possible crappy raw data that could be input in an HTML attribute."

"That's why this whole discussion about creating new identifiers and new protocols in HTML is a total waste of time — the rest of the world does not want it and will not allow it to be published as HTML5. Pound the sand all you like; the network standards will not change because they are designed to support everyone's needs, not just the selfish desires of a very small set of browser developers."

So far from a co-author of RFC 3986 (the Internet Standard STD 66 for URLs) and of RFC 2616 (the currently revised HTTP specification) in one of the various HTML5 flame wars.¹

Lost + found: 268,435,455 free IPs

Three Internet Standards, one of them historic, RFC 3330, an RFC 3330 erratum, and three Internet Drafts entered the battle over 6.25% of all IPv4 addresses:

RFC 3330 lists special IPv4 addresses, among others 240.0.0.0/4 also known as class E. Allegedly "reserved for future use" on page 4 of the historic RFC 1700, formerly known as STD 2. The notation 240.0.0.0/4 stands for all IPv4 addresses starting with the four bits 1111, hex. F0 is decimal 240.

Page 4 of RFC 1700 actually belongs to an introduction with basic terms copied from RFC 1122, a part of STD 3. In fact RFC 1122 specifies 0.0.0.0/8 and 127.0.0.0/8 as listed in RFC 3330, but not 240.0.0.0/4.

RFC 1122 and the RFC 1700 intro only mention class E, but it is specified in RFC 1112, a part of STD 5. Apparently RFC 3330 got this wrong, RFC 1700 by itself did not register anything at all, it was a snapshot of various IANA registries with references to registrations of all "assigned numbers".

As the future of IPv4 is now before IPv4 is replaced by IPv6 the question is what to do with these 6.25% of all IPv4 addresses "reserved for future use" minus one 255.255.255.255 specified in RFC 1122. Three Internet-Drafts fight over it:

• IANA proposes to keep class E as is, because RFC 1700 said so.
• CISCO proposes to unreserve these 268,435,455 IPs reserved in RFC 3330.
• A third draft suggested to reserve these IPs for private use updating RFC 3330.

Ignoring the expired third draft as bad idea it will be interesting how the IETF manages to free this huge pool of IPv4 addresses while the rest of the world is busy to upgrade their hard- and software to IPv6. Apparently RFC 1112 does not do anything with class E apart from reserving it, it is about class D 224.0.0.0/4 multicast addresses. Or as RFC 1812 puts it:

The Class D (IP Multicast) and Class E (Experimental) address spaces are preserved, although this is primarily an assignment policy.

Update 1, it's a bit more complex: RFC 988, a predecessor of RFC 1112, created the 224.0.0.0/4 multicast addresses as class D out of the in RFC 960 reserved 224.0.0.0/3 block, the remaining 240.0.0.0/4 block got the name class E in RFC 990 obsoleting RFC 960. After that RFC 997 updated RFC 990 and listed the "Internet numbers" including class E, while RFC 1010 obsoleted RFC 990 and listed the "assigned numbers". RFC 1010 was a predecessor of RFC 1700 over many steps, RFC 997 was the predecessor of RFC 1166. In other words, RFC 1112 specifies class D, and RFC 1166 explains the remaining class E. RFC 1166 is only "informational", that's good news from the procedural side.

Update 2, a fourth draft was published: T. Savolainen proposes to use class E for hosts indicating that they can handle this , e.g., for dial-up connections.