Tag: Google

May 14

SoundCloud Rolls Out Auto-Sharing To Google+

Soundcloud iosYesterday SoundCloud released a new version 2.6 of their iOS app that for the first time allows sharing to Google+. This is rather intriguing because right now very few applications are able to share directly into Google+. Google has very tightly controlled access to their Google+ APIs to the dismay of many of us who want to more easily share the content we create into our Google+ accounts.

The new SoundCloud app for iOS provides the following new features related to Google+:

  1. The ability to login to SoundCloud with your Google+ credentials. This is only really useful to people who are new to SoundCloud as it simplifies the account creation process by letting you login with your Google+ ID.

  2. The ability to share sounds out to Google+ from within the iOS app.

  3. Automatic sharing of new sounds you create to your Google+ account.

The last one is the most interesting to me and the focus of what I'll write about here. I'll note, too, that according to multiple reports, including an article in TheNextWeb, the ability to login to SoundCloud via Google+ is also available in the Android SoundCloud app, although apparently the sharing is not there. The automatic sharing is centrally configured in SoundCloud's web interface and so may not have a dependence on the mobile app.

Automatic Sharing From SoundCloud To Google+

This is again the most important feature of the update to me. SoundCloud has for quite some time had the ability to automatically share any new sound you upload out to Twitter, Facebook (including Facebook Pages) and Tumblr. This new release adds Google+ to the mix.

You need to login to your SoundCloud account and go to Settings -> Connections. Once there you will see a new Google+ button: Sc connections

Selecting the button allows you to go through the standard Google+ process to authorize this application to connect to your Google+ account. Once you do that, you will see a new connection at the bottom of your list of connections: Sc googleplus

Somewhat bizarrely it doesn't use a Google+ icon but rather something that reminds me more of MySpace.

Similarly, over in the iOS app, after you save a recording and are getting ready to post the sound to SoundCloud, the "Sharing Options" now have a Google+ option at the top - but without any icon: Ios app sc 1 In theory, this should all allow the auto-publishing of links to new sounds out to your Google+.

Sounds Great... But Didn't Work :-(

So, after configuring all of this, I recorded a new episode 5 of my The Dan York Report on this topic... and it did NOT auto-post to Google+. When I was in Google+ there was a yellow message that appeared several times at the top of my screen that said something like:

"Oops... there was a problem posting "TYDR #005 ..." Retrying.

Unfortunately it appeared and disappeared too quickly to get a screenshot.

Manually Sharing From SoundCloud Web or iOS App

The good news is that the SoundCloud web also provides a mechanism to manually share a sound out to Google+. If you click on the Share icon on the page for a sound, you can select the Google+ tab: Soundcloud sharing and then write a message about the sound and choose who to share it with: Share on googleplus

Similarly, you can now do this sharing from within the iOS app itself: Ios app sharing

I'm showing these windows for sharing the sound I created, but this could be for ANY sound that you listen to within the SoundCloud app or web interface.

So What About That Auto-Sharing?

Why didn't my first episode after configuring Google+ integration auto-publish out to Google+? I don't know. I'm going to assume this was perhaps a "teething pain" as the folks at SoundCloud get this integration working.

Regardless, it's good to see this integration with Google+ happening (assuming it starts working) and more apps being able to connect into Google+.

An audio commentary about part of this announcement can be found at:

If you found this post interesting or useful, please consider either:

May 01

Confirmed – Google’s Public DNS Now Performs DNSSEC Validation For ALL Queries By Default

Google logoIt’s official… Google’s Public DNS service is now performing DNSSEC validation for all DNS queries by default!

When news broke back on March 19 that Google had enabled DNSSEC validation on its Public DNS service, there was some initial concern after people noticed that Google was only performing the DNSSEC validation when requested. This led to a clarification a few days later from Google that their initial rollout required a client to request DNSSEC validation so that they could test out the service – and that full validation was coming soon.

The Official Word

Yesterday, Google’s Warren Kumari posted in the dnssec-deployment mailing list that full validation IS now happening:

We have recently enabled validation by default globally, and you should now get SERVFAIL for validation failures.  Apologies again for the original, unclear announcement.

The blog / documentation has not been updated yet (that will probably happen in the next few days) but we wanted to give you the good news as soon as possible.

And indeed a quick test to see if I could get the DNS records for a test domain known to have a bad DNSSEC signature did produce the expected “SERVFAIL” message and correctly did not return any DNS records:

$ dig @8.8.8.8 www.dnssec-failed.org

; <<>> DiG 9.8.3-P1 <<>> @8.8.8.8 www.dnssec-failed.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60286
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.dnssec-failed.org.        IN    A

This is great news for those of us who are advocates of DNSSEC and means that anyone using Google’s Public DNS servers for DNS name resolution are now automatically receiving the greater security of DNSSEC. Anyone using those servers will know that (for signed domains) the information they are getting out of DNS is the same information that the domain operator put into DNS – and not that of an attacker seeking to have you go to some other site.

If you, too, want to gain access to the increased security of DNSSEC, all you have to do is configure your computer or home router to have as its DNS servers the Google Public DNS servers:

8.8.8.8
8.8.4.4

2001:4860:4860::8888
2001:4860:4860::8844

That’s it!

Moving DNSSEC Validation Even Closer

As awesome as this move by Google is (and it is awesome), you could still increase the security provided by DNSSEC a bit more.  Because Google’s Public DNS servers are not on your local network and are rather somewhere out across the Internet, there is still a chance that an attacker could insert himself or herself between you and Google’s DNS servers.  The attacker could then pretend to be sending you back the correct information and masquerading as Google’s Public DNS servers.

To get the highest level of DNSSEC security, you ideally want to be performing the DNSSEC validation on at least your local network and potentially even your local computer. There’s a great whitepaper out from the folks at SURFnet called “Deploying DNSSEC: Validation on recursive caching name servers” that explains how you can simply enable DNSSEC validation for three of the common DNS servers used by enterprises and networks today.

Hey, if Google can enable DNSSEC validation, why can’t you?

If you can’t do DNSSEC validation locally (for example, if you only have a home WiFi router that doesn’t perform validation) then getting the validation performed at your ISP may be the next step… and if your ISP won’t do DNSSEC validation then you really have no other choice but to use a service like Google’s Public DNS services. Their DNSSEC validation is definitely far better protection than none at all!

Again, kudos to Google’s Public DNS team for taking this step and we look forward to the day when all DNS resolvers just perform DNSSEC validation automatically.

 

May 01

Confirmed – Google’s Public DNS Now Performs DNSSEC Validation For ALL Queries By Default

Google logoIt’s official… Google’s Public DNS service is now performing DNSSEC validation for all DNS queries by default!

When news broke back on March 19 that Google had enabled DNSSEC validation on its Public DNS service, there was some initial concern after people noticed that Google was only performing the DNSSEC validation when requested. This led to a clarification a few days later from Google that their initial rollout required a client to request DNSSEC validation so that they could test out the service – and that full validation was coming soon.

The Official Word

Yesterday, Google’s Warren Kumari posted in the dnssec-deployment mailing list that full validation IS now happening:

We have recently enabled validation by default globally, and you should now get SERVFAIL for validation failures.  Apologies again for the original, unclear announcement.

The blog / documentation has not been updated yet (that will probably happen in the next few days) but we wanted to give you the good news as soon as possible.

And indeed a quick test to see if I could get the DNS records for a test domain known to have a bad DNSSEC signature did produce the expected “SERVFAIL” message and correctly did not return any DNS records:

$ dig @8.8.8.8 www.dnssec-failed.org

; <<>> DiG 9.8.3-P1 <<>> @8.8.8.8 www.dnssec-failed.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60286
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.dnssec-failed.org.        IN    A

This is great news for those of us who are advocates of DNSSEC and means that anyone using Google’s Public DNS servers for DNS name resolution are now automatically receiving the greater security of DNSSEC. Anyone using those servers will know that (for signed domains) the information they are getting out of DNS is the same information that the domain operator put into DNS – and not that of an attacker seeking to have you go to some other site.

If you, too, want to gain access to the increased security of DNSSEC, all you have to do is configure your computer or home router to have as its DNS servers the Google Public DNS servers:

8.8.8.8
8.8.4.4

2001:4860:4860::8888
2001:4860:4860::8844

That’s it!

Moving DNSSEC Validation Even Closer

As awesome as this move by Google is (and it is awesome), you could still increase the security provided by DNSSEC a bit more.  Because Google’s Public DNS servers are not on your local network and are rather somewhere out across the Internet, there is still a chance that an attacker could insert himself or herself between you and Google’s DNS servers.  The attacker could then pretend to be sending you back the correct information and masquerading as Google’s Public DNS servers.

To get the highest level of DNSSEC security, you ideally want to be performing the DNSSEC validation on at least your local network and potentially even your local computer. There’s a great whitepaper out from the folks at SURFnet called “Deploying DNSSEC: Validation on recursive caching name servers” that explains how you can simply enable DNSSEC validation for three of the common DNS servers used by enterprises and networks today.

Hey, if Google can enable DNSSEC validation, why can’t you?

If you can’t do DNSSEC validation locally (for example, if you only have a home WiFi router that doesn’t perform validation) then getting the validation performed at your ISP may be the next step… and if your ISP won’t do DNSSEC validation then you really have no other choice but to use a service like Google’s Public DNS services. Their DNSSEC validation is definitely far better protection than none at all!

Again, kudos to Google’s Public DNS team for taking this step and we look forward to the day when all DNS resolvers just perform DNSSEC validation automatically.

The post Confirmed – Google’s Public DNS Now Performs DNSSEC Validation For ALL Queries By Default appeared first on Internet Society.

Mar 22

Google Clarifies DNSSEC Support – Opt In Now, Full Validation Coming Soon

Google logoAfter Google’s announcement earlier this week of DNSSEC validation support in their Public DNS service, there was some concern and discussion in various DNSSEC mailing lists about the fact that DNSSEC validation was not being performed by default and required a client to request validation.  Folks at Google clarified that this was just part of their initial rollout and that providing full validation is in their plans.

They have now also updated their FAQ about DNSSEC support in Google Public DNS and most importantly updated these two questions (my emphasis added):

Does Google Public DNS support the DNSSEC protocol?
Yes. Google Public DNS is a validating, security-aware resolver. Currently this is an opt-in feature: for queries coming from clients requesting validation (the AD and/or DO flag is set), Google Public DNS verifies that response records are correctly authenticated. Validation by default (i.e. for all queries) will be enabled soon.

Which client resolvers currently enable DNSSEC?
Unfortunately, most standard client stub resolvers do not enable full DNSSEC checking and cannot be easily reconfigured to do so. We have decided to make our initial launch only cover resolvers that explicitly ask for DNSSEC checking so that we become aware of any problems before exposing our users to possible large-scale DNS failures due to DNSSEC misconfigurations or outages. Once we are happy that we can safely enable DNSSEC for all users except those who explicitly opt out, we will do so.

It’s great to see Google responding to questions and adding these clarifications – and from the point of view of advocacy for DNSSEC deployment, it is great to have Google out there endorsing and promoting DNSSEC as a way to increase Internet security.

(And you can easily get started with DNSSEC if you haven’t already.)

For those of you who enjoy listening to audio, I recorded some audio commentary on our SoundCloud channel about why I view this news from Google as incredibly important:

Mar 19

Google Public DNS – DNSSEC Validation

Google logoGoogle provides DNSSEC validation through the use of their “Google Public DNS” servers.  If your local DNS resolvers do not perform DNSSEC validation, you can change your operating system to point to the following DNS servers operated by Google for either (or both) IPv4 and IPv6:

8.8.8.8
8.8.4.4

2001:4860:4860::8888
2001:4860:4860::8844

Once configured, all future DNS queries will be resolved using these DNS servers and DNSSEC validation (if requested) will be performed by Google’s servers.  You will then benefit from the added protection of DNSSEC validation.

Typically this configuration is changed wherever you modify your network settings.  In Windows, this is usually in your “Control Panel” while in Mac OS X this will be in the Network part of your “System Preferences”.  For Linux and other operating systems the exact procedure will vary.

Note that there is one important caveat here - you have to request DNSSEC validation when you send the DNS query to Google’s Public DNS servers, i.e. they will only validate the DNS query if you request it.  To do that you need an application that supports DNSSEC.  For web browsers, there are add-ons and extensions for both Google Chrome and Mozilla Firefox:

If you are an application developer, there are DNS developer libraries that support DNSSEC available in a wide range of programming languages so that you can add DNSSEC support to your application.

You can test DNSSEC validation by attempting to visit one of the deliberately misconfigured sites listed on our DNSSEC Tools page.

Google provides the following information about using their Public DNS service:

The addition of DNSSEC was announced in March 2013 and noted that Google Public DNS is currently “serving more than 130 billion DNS queries on average (peaking at 150 billion) from more than 70 million unique IP addresses each day.”

Note: To get the most value out of DNSSEC, you need to use a DNSSEC-validating resolver, and also sign your domains. If you have domains registered, learn about how your can sign your domains with DNSSEC using domain name registrars.

Mar 19

Huge News For Internet Security – Google Public DNS Is Now Performing DNSSEC Validation!

Google logoIn a huge step forward for Internet security today, Google announced that Google’s “Public DNS” service is now performing DNSSEC validation. What this means is that anyone using Google’s DNS servers (and anyone can do so – see below) can now get the increased security that comes with DNSSEC.  (Learn more about the value of DNSSEC on our DNSSEC Basics page.)

It also means that if you want the added security of DNSSEC, but your Internet Service Provider and local operating system don’t validate with DNSSEC,  you can simply change your operating system to point to the following DNS servers operated by Google for either (or both) IPv4 and IPv6:

8.8.8.8
8.8.4.4

2001:4860:4860::8888
2001:4860:4860::8844

Once configured, all future DNS queries will be resolved using these DNS servers and DNSSEC validation will be performed by Google’s servers.  You will then benefit from the added protection of DNSSEC validation.  (Our resource page about Google Public DNS offers a few more pointers about configuration.)

Note that there is one important caveat here - you have to request DNSSEC validation when you send the DNS query to Google’s Public DNS servers, i.e. they will only validate the DNS query if you request it.  To do that you need an application that supports DNSSEC.  For web browsers, there are add-ons and extensions for both Google Chrome and Mozilla Firefox:

If you are an application developer, there are DNS developer libraries that support DNSSEC available in a wide range of programming languages so that you can add DNSSEC support to your application.

In the announcement, Google’s Yunhong Gu noted that Google Public DNS is currently “serving more than 130 billion DNS queries on average (peaking at 150 billion) from more than 70 million unique IP addresses each day.”  As the article further notes:

“Effective deployment of DNSSEC requires action from both DNS resolvers and authoritative name servers. Resolvers, especially those of ISPs and other public resolvers, need to start validating DNS responses. Meanwhile, domain owners have to sign their domains. Today, about 1/3 of top-level domains have been signed, but most second-level domains remain unsigned. We encourage all involved parties to push DNSSEC deployment and further protect Internet users from DNS-based network intrusions.”

To that end, if you have domains registered, we strongly encourage you to learn about how your can sign your domains with DNSSEC using domain name registrars.  You can learn more about which top-level domains support DNSSEC on our DNSSEC Statistics page.

Google provides the following information about using their Public DNS service:

This move by Google to provide this DNSSEC validation is a great addition to the support for DNSSEC validation offered by large US ISPs such as Comcast (making DNSSEC validation available to their 18 million customers) as well as ISPs in a wide range of countries including Sweden, the Czech Republic and Brazil.

We look forward to seeing more public DNS providers and more ISPs turn on DNSSEC validation in their networks.  If you want to know more about what is involved with enabling DNSSEC validation on your network, including home and enterprise networks, this SURFnet white paper provides easy instructions for common DNS servers.

And in the meantime, if you don’t want to wait for your ISP and want to start getting the value in DNSSEC validation today, you now have the option of using Google’s public DNS servers!

 

Jan 11

Join the Google+ "IP Communications & VoIP" Community

Googleplus ipcomms voipWant to connect with others interested in the bleeding edge of IP communications and VoIP? Want to exchange links or engage in discussions with people interested in these topics? If you are a Google+ user (as I am), there is now the new "Communities" feature and Randy Resnick of VUC fame has set up a new Google+ community on "IP Communications & VoIP" at:
https://plus.google.com/communities/114149566116254233716

Given that Randy is very active on Google+, this community is also very active, both through Randy's posts as well as the comments and posts of others. I've already learned a good bit from a couple of the discussions that have occurred there.

There are other Google+ communities that you might find interesting, too, such as those related to DNSSEC and IPv6, but Randy's is a great one for VoIP / IP communications / UC topics. Check it out and join in the conversations....

Plus, if you haven't checked out the VUC calls that occur each Friday at noon US Eastern, they, too, are definitely worth listening to and participating in.

If you found this post interesting or useful, please consider either:

Nov 13

The Fascinating Interest in Using Google Voice With SIP Addresses

Why are so many people interested in using Google Voice with SIP? Is this a sign that people really want to use SIP-based services for VoIP? Is this all hobbyists or people looking to play around with Google Voice? Or is it people trying to solve real interconnection issues? What are people trying to do with Google Voice and SIP?

All these questions came to my mind today when I dipped into Google Analytics and noticed that for the month to date in November 2012, my old (March 2011) post about Google Voice and SIP addresses continues to receive a large amount of traffic:

Ga googlevoiceandsip

Slightly over 3,000 pageviews in the first 13 days of November - and if I go back a bit I see over 71,000 pageviews since January 1, 2012. In fact, it's had about 232K pageviews since I wrote it over 1.5 years ago, and has accounted for almost 25% of all traffic to this site in that time.

And this particular article was just one in a series of articles I wound up writing about Google Voice and SIP as we all collectively tried to figure out what was going on.

Digging into the traffic sources to the page, almost all of it this month comes (somewhat predictably) from search. The search terms, at least the ones we can see (since Google now shows "Not Provided" for all searches done over SSL), show a range of interest in SIP:

Ga googlevoiceandsip search

And all of this for a service from Google Voice which seemed to be a temporary service and subsequently stopped working... kinda, sorta... and then did work... and then didn't work. (And I just checked... and it doesn't work for me right now.)

I find all this interest fascinating. I hope it's a good sign that people out there do want to see more usage of SIP addresses.

And I do hope that at some point Google will open up the connection again and let us connect in to Google Voice numbers using SIP URIs. It would be a great move.

Meanwhile, I'll continue to be fascinating by all the traffic still coming to those old articles...

If you found this post interesting or useful, please consider either:

Jul 26

Google Now Lets You Handwrite Search Queries On iPad, iPhone, Android

Google handwritingOkay, I admittedly find this pretty cool... you can now enter search queries into Google on a tablet or mobile phone just by writing anywhere on the screen!

As Google's blog post outlines, you need to go to www.google.com on your mobile device and then go into the Settings to configure this option. You do NOT need to sign in to Google. You just need to go there in your mobile web browser.

I've tested this on both my iPad and iPhone and found it worked quite well (per the blog post and Help Center page, it also works on Android phones and tablets - and is available in 27 languages). I find it particularly useful on the iPad where you have the larger screen to write on. On the iPhone, maybe my fingers are just too big but I found it tight to write in the regular portrait mode.

I did notice, though, that you can enter one or two letters, pause, then enter another letter or two... and as you do the search window is updated with what Google thinks the text should be as well as search query suggestions. So you may just be able to write a few letters and then tap the correct search suggestion.

Now, the question, of course, is WHY I find this interesting and the answer is that I have had some times when I'm in situations where it's not super easy to type nor do I want to be talking to my phone (i.e. using Siri). With the iPad, in particular, there are times I'm holding it while walking around at an event where typing with two hands would not be easy and voice usage isn't really possible. I could see this potentially being faster than hunt-and-peck typing a query using one hand. Will I use it all the time? No... but certainly I can see it being nice to have this option.

What's also interesting about this feature is that it requires you to go to "www.google.com". It doesn't work with the "search" box that is in the top of Mobile Safari in iOS. You need to go to Google's home page... so Google is pulling you out of using the app (Safari) and into using their web page. If you get used to doing that, Google can of course introduce other functionality - and if you are "signed in" you see your Google+ notifications and can easily access other Google services. Intriguing move by Google.

What do you think? Will you use this capability on your iPad, iPhone or Android device?

P.S. Alas, it is not as all-powerful as TechCrunch asserts with an ability to interpret cursive handwriting. I made several attempts at using cursive and found that in some cases the accuracy was "okay", but clearly not as good as block printing. In fact, Google's Tips for Handwrite very clearly state at the beginning that you should use block printing versus cursive.

And here is Google's video on the topic:

If you found this post interesting or useful, please consider either:

Apr 12

My Report into For Immediate Release (FIR) Podcast #646

In this week's For Immediate Release episode #646, my report covered:

If you are a FIR subscriber, you should have the show now in iTunes or whatever you use to get the feed. If you aren't a subscriber, you can simply listen to the episode online now.

If you found this post interesting or useful, please consider either: