September 1, 2016 archive
Sep 01
TDYR 310 – Initial Thoughts on Facebook Messenger “Instant Video”
Sep 01
Facebook Messenger’s "Instant Video" Lets You Simultaneously Use Video and Chat
The messaging wars continue! Today Facebook Messenger added "Instant Video" to it's iOS and Android app, allowing you to easily share live video while still in a text chat. Facebook has had "video calling" since back in May 2015, but that requires both parties to answer the video call in the same way that Facetime, Wire and every other video app does it.
"Instant Video" is different:
VIDEO STARTS OUT ONE-WAY - Only the video of the person initiating "Instant Video" is shown. The recipient sees the video of the sender, but their video connection is NOT enabled. Now, the recipient can start sending video, but they don't have to.
AUDIO IS OFF INITIALLY - When the sender starts their video, the recipient receives the video without any sound. They can easily start getting sound by tapping on the speaker icon on the video, but this is great because often you are having a text conversation precisely because you don't want to use audio.
YOU CAN STILL SEE THE CHAT - The video overlays the upper right corner of the chat window, but that's it. You can still see the chat messages and continue having your chat.
This last point is quite important and useful. This "Instant Video" lets you add video to a chat, while still allowing chat to be the primary communication medium.
Predictably, there was a great amount of media coverage of this launch today. Some noted that this was yet-another-way Facebook was cloning Snapchat. Others called this an answer to Google Duo.
Regardless, I immediately saw a personal use case. Occasionally I will go to a local coffee shop to pick up muffins for my wife and I. The flavors are always changing. If I don't see one I think she'll like, I often wind up calling - or texting her with the flavors. But it would be actually a bit easier and faster if I texted her "which one do you want?" and then sent her a live video stream where I panned back and forth across the choices. Sure, that may seem a silly use case... but it immediately sprang to my mind.
For "Instant Video" to work, a couple of conditions need to be true:
YOU BOTH NEED THE LATEST MESSENGER APP - You need to have the latest version for either iOS or Android.
YOU BOTH NEED TO BE *IN* THE CHAT - This is key. You can't just open up Messenger and start sending video to someone who is listed in your contacts. You need to actually be in communication with the other person.
Once this second item is true the video icon on the top of the screen starts pulsating - at which point you can start sending "Instant Video".
I'd note that this is the same icon used to initiate a "regular" video call. However, when you are in a chat with someone else the pulsating icon means you can do this new "Instant Video" style of chat.
I found I really liked the overlay aspect. Here's the view I saw on my end:
It worked very well to continue the text conversation while having the video right there, too.
It's an interesting addition as Facebook continues to try to make Messenger be THE tool that people use for messaging. Facebook has this advantage of having an absolutely massive "directory" of users (see "the Directory Dilemma") and so we may see this helping with keep people inside of Facebook's shiny walls.
What do you think? Do you see yourself using this "Instant Video"?
Sep 01
New RFC 7958 – DNSSEC Trust Anchor Publication for the Root Zone
How can you trust the root of the “global chain of trust” that is used in DNSSEC? How can you be sure as you are validating DNSSEC signatures that this global chain works?
To provide this chain of validation, DNSSEC relies on what is called a “trust anchor”. When you check the signature for DNS records for “internetsociety.org”, for instance, you go through a process along the lines of this (a simplified version):
- Your validating recursive resolver gets the DNS records (such as “A” or “AAAA”) for “INTERNETSOCIETY.ORG” along with the DNSSEC signature in a RRSIG record and the public key used for the signing in a DNSKEY record.
- It then retrieves the DS record for “INTERNETSOCIETY.ORG” from .ORG to verify that this is the correct DNSKEY. It also retrieves a RRSIG record for the DS record and the DNSKEY record from .ORG.
- Next it retrieves the DS record for “.ORG” from the root of DNS, along with the associated RRSIG for the DS record and the DNSKEY for the root.
- HERE IS THE CHALLENGE – How does your recursive resolver know that the DNSKEY it retrieved for the root of DNS is the correct one?
This is where there is a need for a “trust anchor” that the recursive resolver can trust to know that this is indeed the correct DNSKEY it should be using.
The DNSSEC protocol can be used with any trust anchor, but in practice we all use the DNSSEC trust anchors published by IANA (with ICANN doing the actual publishing as part of their contract to perform the IANA functions).
A new informational (non-standard) RFC 7958 out this week explains the formats IANA uses to publish the root key trust anchors and how those trust anchors can be retrieved. It also outlines additional steps that can be taken during the retrieval to ensure the trust anchors aren’t modified during the retrieval.
In 2017 we will see a change in the Root Key Signing Key (KSK) in 2017, which will mean a change in the root trust anchor. This RFC 7958 is a good reference to have out there so that everyone can understand exactly how to retrieve and use the trust anchors at the heart of DNSSEC.
Please do read this new RFC and share it widely with anyone involved in developing applications or services that perform DNS resolution and validation.
And if you know very little about DNSSEC but want to learn more, please visit our Start Here page to find resources to help you get started!
