There is some interesting Q&A at the end of Pascal's talk. My schoolboy French is not fast enough to do a proper translation unfortunately. He was asked about parallel (software) decoding and I think the gist was he thought it would be a bit difficult because of the dependencies between region images.

https://parisvideotech.com/pvt-4-les-formats-et-codecs-du-fu...

Oblique to the predictable Slack XMPP decision, but relevant to federation: Mastondon is a facinating federated social network. It addresses the identity/reputation issues without embracing fb-fascism or one-site-to-rule-them-all nonsense.

https://joinmastodon.org/

How it works Anyone can run a server of Mastodon. Each server hosts individual user accounts, the content they produce, and the content they subscribe to.

Each user account has a globally unique name (e.g. @user@example.com), consisting of the local username (@user), and the domain name of the server it is on (example.com).

Users can follow each other, regardless of where they’re hosted — when a local user follows a user from a different server, the server subscribes to that user’s updates for the first time.

There is also GNU social; which is what Mastodon is based off of. I have been thinking about hosting a server for awhile. Pretty cool stuff.

I do host my own mastodon server with a small community, the initial setup is a bit complicated but once you get it going upgrades are nice and easy (each update contains all shell commands necessary outside `git fetch` and `git checkout v{VERSION}`)

Only downside of course is that if you selfhost alone, your federated timeline will be a bit empty, I do recommend either finding a community or starting one to get a bit more activity (Mastodon is essentially geared towards a sort of "community neighborhood" decentralization, where only one in a few hundred or thousand users needs to run a server, on average)

Unfortunately ActivityPub (that powers Mastodon) has a lot of incidental complexity (including RSA signatures, JSON-LD, RDF normalizations to quads etc.)

But this is a very simple alternative, distributed "Twitter" for hackers: https://github.com/buckket/twtxt#twtxt

It seems rather easy to impersonate other users, though. Similar to how one can impersonate domains by being one letter off or something like that.

I'm not sure how battle hardened Mastodon is, obviously they don't have the resources of Twitter or Facebook. Probably easy to DDOS an individual server. However, it might be possible for other nodes to transparently cache updates.

As to spoofing, we've got to move beyond humans memorizing unicode strings or profile pictures as a means of identity validation. Its shambolic enough that twitter users constanly change their display string, obscuring the twitter handle, but even without that problem, how many people send bitcoin/ethereum to @eloon_musk?

People do the same on other platforms. I've been impersonated on a social media platform via a two letter swap.

I don't think it needs a solution, administrators of instances have to solve this, first by asking to offending instance to ban the user, mute the user and if the instance doesn't do anything about repeated abuse, mute the instance.

This will be a problem on any platform that allows users to choose their own names.

IIRC, for quite a while Slack even allowed two people in the same channel to have identical display names.

Unlikely to be extradited for an extra-territorial claim. But the members of the executive and the board might not want to strike Germany from their list of travel destinations forever.

Certificate pinning is going away: http://www.zdnet.com/article/google-chrome-is-backing-away-f...

I think we can be confident that sites that don't even use CSP won't be implementing Expect-CT any time.

HPKP is what the article you posted to is referring to, and probably will go away completely.

However, profiling the public key of the site a mobile app connects to and erroring out if it is compromised to prevent MitM attacks is called 'certificate pinning' for mobile apps but is not related to the HPKP pinning of browsers. A reference for certificate pinning: https://blog.netspi.com/certificate-pinning-in-a-mobile-appl...

It seems grandiose to call that 'certificate pinning' when it is just hard coding, e.g. a self-signed CA cert or (worse) a particular server cert.

Makes me suspect that a lot of client side validation is happening with mobile apps.

Presumably GP was talking about in-app certificate pinning, not Google’s opinion of the day...

If you look at https://track.emirates.email you will see that it isn't emirates either, but a service provided by Mandrill, an add-on for MailChimp, and the cert is valid for https://mandrillapp.com. Surely they could have figured out how to use SNI.

The fact that your mail client / embedded browser takes you happily to sites with broken certs, giving them a tracking token (and in this case, total access to your booking) is also quite a problem.

Exactly, the fact that the url does not have any expiry (apart from the end of booking), the email providers in this case Mailchimp would also have access to the same.

For the case why browser did not redirect the broken cert, that is because the link sent in the email was over http.

I tested going to a https link via gmail. On desktop chrome, it immediately opens the link (and hence passes the link parameters). On mobile it pops up a privacy error, "Attackers might be trying to steal your information" (NET::ERR_CERT_COMMON_NAME_INVALID), which is certainly the right thing to do. Still have to try it on Office365 and Outlook.

Strange, I always encounter `NET::ERR_CERT_COMMON_NAME_INVALID` even on Gmail with Chrome. What's your test setup?

Doh, you're right. I looked at the site earlier and forgot to click on the red triangle and click "re-enable warnings". Mea culpa.

I checked firefox and it works correctly too.

@minimaxir for your list: - Not possible to downvote some posters, as the authors have extreme karma (e.g. >10,000, though I don't know the exact number), even if you have >>500 karma.

It is notable that HN does not support blocking particular users, or indeed annotating that you like them. Though plenty of fans will upvote well known authors, it is not possible for you to keep a list of people who you think have written well in the past. I'd love it if I could, e.g., mark favourite author names in green.

HN is also notable from my perspective for having some people with good technical sense and clear writing, but very extreme views on other matters, to the extent that they would be pariahs in RL situations.

I've wanted a feature to "follow" certain users as well. Presumably it could be built as a separate app or into a browser extension.

You know you can get a support contract right? Where you pay the experts at Qt and they help you?

Maybe this was the case with Qt4, but Qt5 (that is, QML) is a dream.

I disagree. QML is a nice idea but incomplete:

* There still isn't a way to have any text in your custom widgets (e.g. labels on a graph) - last time I checked anyway.

* The built in text editor widgets have an anorexic API. I wrote a serial port monitoring program and to remove the first line of text from the output window I had to record the lengths of all the lines in a JavaScript array and then remove that number of characters. And it was very slow. And selection was buggy.

* The ID scope rules are weird. Honestly I never fully worked them out. It seems like every ID is accessible from anywhere - even child components can directly access IDs in their parents. You can imagine the kind of spaghetti code that leads to.

You really think the memo was "starting a meaningful conversation"? Did you even read it?

That memo was never intended to remain private correspondance. And I'd hope that Google would have terminated his employment in any case.