Latest posts.

FB’s unethical behavior

via James G:

Basically: FB researchers, along with researchers from UCSF, manipulated users feeds to make them sad or happy (or neither, the control group). They were indeed able (and did) make people sad because of their manipulation.

When I was a grad student at UMich School of Information, a PhD student there was doing research at FB and did similarly unethical research on FB users. Also without real IRB oversight. They later received their PhD in part because of that research (wasn’t their only research). They now work at FB full time.

This is just par for course for FB. They’re completely unethical; even the people in their corporation who were taught to care about people (researchers trained at legitimate universities) are without ethics.

Sorry old friend, if you’re reading this. I didn’t agree with what you did then and I still don’t agree with it.

flattr this!

h264 and Wikimedia – clout

This is the fourth of a few specific sub-topic posts on the h264 and Wikimedia RFC.

[19:47:54] <lvillaWMF> we have no clout
[19:47:57] <lvillaWMF> because we have no content
[19:48:12] <lvillaWMF> when it comes time to choose the next winning codec
[19:48:12] <lvillaWMF> we can sit at the table and say "we are wikipedia, we like format X" and be ignored
[19:48:13] <lvillaWMF> or we can sit at the table and say "we are wikipedia, and we have a million videos that 1/2B people look at a month, we like format X" and not be ignored
[19:49:11] <lvillaWMF> twkozlowski: because the next time a codec is chosen, it will be between an open codec and a closed codec

I’m going to charitably assume that Luis is referring to the decision of what standard will be “h265″, not “where and when the current h264 standard is implemented”. As stated before, the current IETF webRTC process on decision which codecs are MTI is HAPPENING NOW. And our decision will influence that negatively (if you’re anti-patent-encumbered codecs) or not at all.

[19:58:02] <lvillaWMF> kim_bruning: and the best way we can influence them in the next round, as I said earlier, is to *have content

This next point needs to be stated pretty specifically as Luis’s statement can be read one of a couple ways, and I don’t want to put words into his mouth.

1) Luis’s statement could be read to say that “without h264 support, both for ingest and for viewing, we won’t be able to garner enough videos to have eg 1,000,000 in time for the ”next round”.”

2) Luis’s statement could also be interpreted as “without the ability to ingest h264 video, we won’t be able to garner enough videos to have eg 1,000,000 in time for the ”next round”.”

I think 1 is mostly wrong and I think 2 is only potentially right. We have no numbers, at least on this RFC, to back those statements up.

2 would need only the number of people and/or times that someone tried to upload an h264 video and were either stopped themselves or had their content deleted (and not replaced with a converted version). We might be able to get the part of that with some fancy foot work, but maybe only in order of magnitude precision. The first number is pretty much impossible to get without a rigorous survey of both current users and non-users (which is going to be costly and difficult).

1 would need the above number(s) in addition to a statement on the percentage of devices viewing (and contributing, would be good to have it broken down like that) Wikipedia that ONLY support h264. This needs to include/be aware of users that have plugins installed. I can’t imagine this is the case, but if by some magic, a non-insignificant number of *viewers* are using devices that either natively or with plugins already installed can view WP videos, that says something.

(As always, this is my blog. I may work for WMF, but I don’t speak for them on this blog.)

flattr this!

h264 and Wikimedia – webRTC influence

This is the third of a few specific sub-topic posts on the h264 and Wikimedia RFC.

This is going on RIGHT NOW. The WMF decision on our RFC *will* have an effect on it, but it will only be a choice of “bad” or “no effect”, unfortunately. We’re already known as the place that won’t accept patent-encumbered codecs so if we stay with the status quo (not allow h264) then there won’t be much of a change in the process; no big new flame war on the IETF mailing list.

However, if we do start accepting h264, you can be sure as anything that the h264 proponents (and in this context, that means people who believe implementors of webRTC should only have to implement h264) will tout it as a big win for them, and an obvious reason that anyone else holding out against patent-encumbered formats is either delusional or stupid or both.

We may already be thought of by the Apple’s and MPEG-LA’s as being delusional, but that’s not reason for us to back down now, cave to their rhetoric, and make their point for them. If we cave, who’s left? The FSF? The only people in this conversation who seem to have a consistent message, it seems. Mozilla no longer has a consistent message. “OPEN WEB! Oh, well, only parts of it…” Creative Commons is ignoring the issue because they think they aren’t implicated by it (enough to comment), which I think they’re wrong about. I’m not alone in that and it seems to only be consistent-sympathizers that are defending Mozilla. The consistently-Free individuals don’t.

flattr this!

h264 and WMF – Free Software Implementation

This is the second of a few specific sub-topic posts on the h264 and Wikimedia RFC.

During the first IRC Office Hours on January 16th (log here) robla (my manager) said something that caught my eye:
[19:19:10] <robla> brion: I don't think we can say for sure we'll be using free software for this.

Speaking with my Release Manager hat on, this scares the crap out of me. I don’t want us to be in a situation where we hit weird bugs in the software and are unable to correct them. We hit weird bugs in pretty much every level of software we use, from the “lowest” to the “highest”. Bugs exist in all software. I don’t want us to be unable to fix our own infrastructure. If a non Free Software implementation is required for h264 support at our size, then it’s a non-starter for me. And I’ll make that pretty clear with my WMF hat on. I can be overridden, of course, and maybe would be. But I will make my opinions and concerns known.

If you’re curious, I brought this up on the RFC page.

This post requires a little bigger disclaimer than normal. I share my feelings in using non Free Software in a production environment at the WMF. This is the exact same reaction I would have regardless of RFC/nonRFC, proposed by a WMF team or not, dealing with software patents or not, or any other aspect of this current RFC that’s interesting. This is a pure “wtf non Free Software?!” post. I, as always, do not speak for the WMF on this blog.

flattr this!

h264 and Wikimedia – downstream users

This is the first of a few specific sub-topic posts on the h264 and Wikimedia RFC. Overall theme post.

The spirit of the license. The spirit of the community.

When individuals contribute to Wikipedia/media Commons, they are given a pretty explicit explanation that the content they are contributing will be available for use not only on Wikipedia/media, but also anywhere else assuming compliance with the terms of CC BY-SA (at most).

All of the licenses/copyright statuses of content on Commons allows AT LEAST the ability for down stream users (ie: users) to make derivatives and redistribute those derivatives to others even for commercial purposes without paying anyone royalties (with attribution and under the same license, if needed). That is the spirit of the license. That is the summary of the most restrictive license we allow (BY-SA) by the license steward itself (CC). Not until one reads the fine print do they realize that not all rights are included. Things like personality and moral rights and patent rights. Notably, even for those relatively well versed in the topic, one would not imagine that a photo of video would have patent rights associated with it that you would need to care about.

This RFC is proposing that we make our users now care about something they didn’t have to care about before. Something that is both insidious and opaque.

At a minimum, we (the Commons community) will need to implement yet-another-warning-box telling users that are viewing h264 files that “Oh whoa whoa, you might not have all the rights you need to make use of this video under the terms of the license we provided it under. You might have to go pay some unethical organization to redistribute it. Or not. Unclear. Consult a lawyer.”

Yes, every lawyer loves to tell you that everything is an “it depends” decision and that if you want to be safe, yes, you should consult a lawyer for every decision you make as each one is different and will be interpreted by a judge on a case by case basis.

But our community is different. We want to make things as clear as possible for our users (and downstream users, where there’s a meaningful distinction).

I feel making this change would be going back on our word. We have promised, in effect, that Wikipedia will always be free and Free. That users, whoever they are, will always be able to use and remix the content (and we never carved out file format exceptions) and distribute that content, even commercially.

See the discussion on the RFC about this topic.

(As always, this is my blog. I may work for WMF, but I don’t speak for them on this blog.)

This post was translated into Spanish by Jacobo Nájera.

flattr this!

h264 and Wikimedia

The Wikimedia Foundation (multimedia team) just opened a “Request for Comments” on adding the use of MP4/h264 to WMF-hosted wikis. It closes on February 14th, 2014.

This basically is asking the community if the WMF should support the use of a patent-encumbered video encoding format so that we can provide video to users on devices (mostly phones, which are growing in percentage of page views) that don’t support webm/ogg theora.

I see parallels with the Firefox h264 decision. And also implications for the current IETF webRTC codec decision (which standard(s) will be “Mandatory to Implement”).

My initial personal thoughts:
The Wikimedia Foundation, because of the Wikipedia et al community, is firmly in the Free and Open Source world. Everything we create that is user facing is Free Software. The bits of non-free software we use are internal (eg: Google Hangouts, finance/hr-related, that type of thing). I’m employed by the WMF because of its stance on Free Software. It has a more principled (and consistent) view on freedom than my previous employer (and the one before that).

Luckily, the decision will be made with community input, and our community is made up of contributors to the Wikimedia projects, not paying members like W3C (hi there, MPAA!). We also don’t have a single big overlord in terms of money in-flow aka Mozilla with 85% of it coming from Google.

I hope we can continue to take a principled stance on this and not start down the path of big compromises.

I also hope readers of my blog would take the time to read up, think, and contribute their thoughts on the RFC. Many voices are appreciated here.

I plan to post at least once more on this topic, with a more full explanation of my feelings/reasonings.

flattr this!

anti-spying VPS options?

Are there any VPS options that are any better on privacy wrt NSA man in the middle attacks or similar? My guess is “no” but I’d love to be proven wrong.

I’m also thinking of stuff like the dead-man’s-switch that eg does with their canary text.

flattr this!


Treat everyone as though they make your shoes.

h/t: Zeph

flattr this!

blog stats transparency

I’m re-transitioning to a maiki-hosted piwik installation for blog stats.

See all the sites hosted (including maiki’s (of course), mike’s, susan’s, judy’s, maira’s, etc) on the list of sites page. This is me.

My nee “JetPack” stats over the past 30 days, for greater transparency’s sake: stats - Dec '13 - Jan '14

(related: anyone know how to import nee “JetPack” stats into piwik?)

From the Piwik FAQ:

Piwik uses a javascript based tracker, and keeps count of unique visitors using a first party uuid cookie, as well as a visitor recognition heuristics algorithm (based on IP address and user settings).

Just FYI.

Also, there’s if you want.

flattr this!

SFFCU is the best

The San Francisco Fire Credit Union is the best financial institution.

Wow, pretty big assertion there, eh? Yeah, and I mean it.

Not only do they have decently competitive interest rates, are a credit union, help the community, but they also send their members OpenPGP encrypted documents.

Let that sink in.

Yep, my credit union sends me documents encrypted to my GPG key. Well, they did once so far. This alone makes them the best financial institution around.

Let me rephrase: as they are already on the good end of the spectrum for most if not all things that financial institutions do, the GPG thing just puts them past the goal post. That’s more than other professions that care about authenticity do.

The story:

I sent a check to a previous landlord to cover some cleaning expenses (loooooong story there), and when they cash that check my stress level would go a TON down (again, long story). It was a long time until the check cleared on my bank account; about a month after I sent it. I wasn’t too worried about that part. I did, however, want to see/have a record of the fully executed check, ie: the scans of your cleared checks. I went to look for them but they weren’t there, though it was listed in the transactions for my checking account.

I fired up the 24 hour web chat help (which is AWESOME) and spoke with a nice person who told me that apparently my previous landlord’s bank had typo’d the account number and the check first posted against the wrong account at SFFCU. They noticed it and moved it over to my account. Hence the not normal representation of the transaction in their banking portal.

I asked if I could get the scans of the check and they said sure, they can send them to me via email or snail mail. I told her email. And then she asked:

“Do you use a PC or a Mac? That determines how send the encrypted file.”

Well shoot, I thought. I replied:

“Unless it is simply a password protected PDF it probably won’t work on my Linux(sic) computer. It’s ok, you can just send them via the postal mail. But if it was something like GPG, then it would be fine.” (paraphrased from memory, I don’t have the log)

She said she’d see about GPG but she’ll send it via the postal mail either way. This was on Thursday.

On Friday afternoon I received an email with the subject: “SF Fire Credit Union documents you requested”

The body:

Here are the GPG encrypted files you requested.

These were encrypted with the “public” key that you have posted on your website, so no password is necessary. Please call us if you need further information to access these files.

Thank you!
Member Elations Consultant
SF Fire Credit Union

Attached were two files with the names DocumentFront.pdf.gpg and DocumentBack.pdf.gpg.

“This can’t be” I thought. A quick gpg -d later and, what the…. yes. Yes they did.

This amazing person at SFFCU took the time to A) look at my email address B) notice it uses my last name as the domain C) go to the domain D) go to my about page E) find the link to my gpg public key and F) encrypt the file to my key.

Yeah, all things that probably anyone reading my blog could do without thinking. But when was the last time your bank did this?

The response I got when I told my friends via IRC was pretty universal:

flattr this!