1,389 karma · joined February 13, 2011
The question about women asking for raises happens around 01:34:04.
Google+ Sign-In is an implementation of OpenID Connect, with some nice features built on top:
"Google+ Sign-In is built on the OAuth 2.0 and OpenID Connect protocols. It supports over-the-air installs, social features, and a sign-in widget on top of standardized OpenID Connect sign-in flows. Google+ Sign-In works for all users with a Google account, whether or not they have upgraded to Google+." [2]
[0]: http://openid.net/connect/
[1]: https://developers.google.com/+/api/auth-migration
[2]: https://developers.google.com/accounts/docs/OAuth2Login
As soon as rights-holders can be convinced that DRM is unnecessary, then we'll see the internet streamers like Netflix drop it. I'd bet that by the time we see A-List movies on GOG, we'll be seeing them on Netflix too.
I say, wouldn't it be amazing if everyone's medical records were available anonymously to research doctors? And when someone accesses your medical record, a research doctor, they could see, you could see which doctor accessed it and why, and you could maybe learn about what conditions you have. I think if we just did that, we'd save 100,000 lives this year.
So I guess I'm just very worried that with Internet privacy, we're doing the same thing we're doing with medical records, is we're throwing out the baby with the bathwater, and we're not really thinking about the tremendous good that can come from people sharing information with the right people in the right ways.
Source: https://www.youtube.com/watch?v=mArrNRWQEso&t=839 at 14:00.
Where are you seeing which device you are using shared on Google+? The only place I've seen something like that is if you have someone you've accepted as a Hangouts chat buddy and you've opted into the "share which device I'm on" in the Hangouts settings (all that shows though is if you're on a tablet, phone, or desktop computer though, not specifically which device).
[0]: http://googleplusplatform.blogspot.co.uk/2013/02/google-plus...
If the market share increased significantly, I'd be surprised if they chose to continue not to support it. But for the time being, their decision makes sense to me.
[0]: http://techcrunch.com/2014/07/03/windows-phones-market-share...
tl;dr: Some misconfigured switches meant that rendezvous radar jobs kept being erroneously scheduled, which used up available memory. Whenever there was no more memory available, the alarm would fire and the computer was rebooted. It would immediately restart (resuming from near where they left off) all the high priority jobs (while not restarting the radar jobs), meaning that it could still land safely.
Everyone (including Google[0]) agrees that they made privacy mistakes with Google Buzz. And I think that they've worked hard to improve privacy in their products since then. That's why Google+ has used circles from the beginning: the Google+ experience emphasizes choosing the right people to share you content with (as opposed to the standard "share with the public" or "share with all my friends" which was standard at the time). At the time when Google+ launched, it had one of the strongest sets of privacy settings on the market[1]. Other competitors have since beefed up their privacy settings to match Google.
Regarding the "Real Names" policy, I think that their goal there was to make it a community of Real People, instead of a completely anonymous community of people using cryptic usernames. And I think that they thought that people would be more likely to make connections if people saw each other's real names instead of some username they came up with. When they realized that some people only go by a username and that most of their friends don't even know their real name, they started allowing people to add their nickname to their profile so that they could be findable with both their real name and their username. I think that these decisions were good ones and I like the community that now exists because of those policies.
I agree that "Real Names" has privacy concerns, but before the policy change yesterday, Google+ had been saying that you didn't have to use your actual name if you were concerned about your privacy - you could just use any name that resembled an real name (i.e., John Smith). I agree that this is a bit wonky, but I think it was one of those hard tradeoffs. I think without such a policy, growth on Google+ would have been a lot slower, and the community would look very different.
[0]: http://gmailblog.blogspot.ca/2010/02/new-buzz-start-up-exper...
[1]: http://bits.blogs.nytimes.com/2011/07/18/privacy-isnt-dead-j...
Some people spread rumours in the early days of Google+ that your Gmail would be shut down if your Google+ was suspended, but that was never the case.
If you look at the screenshot from the click study they did in the presentation [0], for the search "gary danko yelp", Google is (or was) serving up the Gary Danko website itself first, instead of the Yelp page. Honestly, I think the website of the business itself is an appropriate first search result, even if the query included the word "Yelp". To the bottom of this result, Google has attached links to see the Google Local Reviews and shows the rating, which is either done automatically by Google (though I'm not sure if they add it automatically) or through the Google Business Tools [1] at the request of Gary Danko themselves. According to their click study though, barely anyone is clicking those additional links.
[0]: Page 12 of http://online.wsj.com/public/resources/documents/yelp.pdf
I was just making the case that "Anyone with the link" still provides some security. Just like you don't know if the people accessing the document are the ones that you shared the link with, you don't know that the people you shared the document contents themselves with aren't showing others without your knowledge.
If I shared a document with only you (directly, not using the "anyone with the link" permission), I couldn't stop you from taking a screenshot and sending that to whomever you pleased (or printing them out and leaving them in a conference room, like you suggested). Sharing documents online in general can be troubling if you don't trust the people you send them to. It's easier to share a link than share a screenshot, though, and a link would provide continued access going forward, and could remove deniability that the screenshot was faked.
The bug has been patched so that any document with the "anyone with the link" permission will no longer leak its location in the referrer when someone clicks an HTTPS link in it. But it's possible that that happened in the past and the link was already leaked (and unfortunately, they can't exactly fix that). So if you have an old document, it's not vulnerable anymore, but it may at one time have been vulnerable so you might want to update it to have a new link (following the instructions in the Google blog post).
As far as I can tell from this article [2], attacks on RC4 are only theoretical at this point, but it seems reasonable that they should upgrade the video serving domain to be consistent with the page itself (though maybe it's done for performance reasons - either encrypting a large video stream costs a lot of CPU time or decrypting it on the client is too slow or CPU intensive for watching video smoothly, so perhaps they are sticking with RC4 for a good reason). Still, as my old crypto prof said, "Attacks only get better over time. They never get worse."
[0]: http://i.imgur.com/OcpziFa.png
[1]: http://i.imgur.com/57T8bay.png
[2]: https://community.qualys.com/blogs/securitylabs/2013/03/19/r...
What I will say is that we should remember that Web Components is where the web platform is going. This isn't some one-off library by Google; both Chrome and Firefox are getting all of the web component primitives built into the browser, and it looks promising that we'll see them arrive in IE and Safari as well. Polymer is some sugar on top of those primitives to make them easier to work with, but in any case, the next generation of web apps will start using web components and probably some library like Polymer or XTags. The time to start learning and playing around with web components is now, even if it's not time to build massive applications in them quite yet.
That's a great way of looking at it. There is definitely some overlap, but I think it's nice to have the mindset that they are on the external developers' side rather than just the company's side. And it works well I think - by helping out those developers, they can work towards better products and platforms, and increase adoption at the same time. Everyone wins.
While they may just be titles, my experience has been consistent with their titles. Apple representatives you see once a year at WWDC, while Google representatives you see at Google I/O and also at a number of Google-hosted events year-round, including the regular videos they put out (and the "office-hours" type Hangouts they have so that you can actually talk to them and get your problems resolved) - just look at all of the events they have scheduled on the Google Developer Events page[0] or all of the videos they have on their YouTube channel[1]. I've also seen a lot of them give talks at tech conferences, while Apple employees are rarely seen at conferences. And you can see that Google's Developer Advocates really do talk directly to the actual teams directly and file bugs against them when necessary on behalf of developers everywhere. It's a system that has worked pretty well in my experience.
I will also agree that Google's Developer Advocates don't care too much about what platform you're using and just want to help you. I've been to a number of Google-run technical workshops and codelabs, and the people there are willing to help you with whatever problems you run into, no matter what it is.
The last time period that I played around with it was when iOS 3 was out, and it was horribly buggy (if you failed to download all of the things listed in the cache in the first go, then it would break and would refuse to ever try again). By iOS 4 it was less broken, but still weird.
Since it's been out there for a while it would probably be difficult to remove. Because of its brokenness I doubt that it ever got much usage, but there is probably some people out there that rely on it.
What I hope is that after ServiceWorker is better supported, someone can build out the old AppCache behaviour in JavaScript using the ServiceWorker APIs, and then we can use that for compatibility and remove AppCache from the browser itself.
There was a short video about ServiceWorker at the recent Google I/O that you can check out for an overview[2].
[0]: http://alistapart.com/article/application-cache-is-a-doucheb...
[1]: https://github.com/slightlyoff/ServiceWorker/blob/master/exp...