1,389 karma · joined February 13, 2011
[0]: http://en.wikipedia.org/wiki/Transport_Layer_Security#Certif...
This has nothing to do with uploading videos for free that can be watched for free.
It doesn't matter though, both transforms have the same effect.
And instructions for creators to set ratings is described here: https://support.google.com/youtube/answer/176714
If you go through the Chrome bug tracker, you can find several instances where Chrome engineers point out that Click-to-Play is not meant to be a security feature, and that the "Block all" setting is what is actually secure. There are several bugs which demonstrate ways around Click-to-Play which are closed as "WontFix". A quick search yields the following quotes from Chrome engineers:
"Yes, this is why click-to-play is designed as a convenience and not a security feature. If you want plugins blocked in a way that cannot be click-jacked, use "Block all," which requires a protected browser interaction (context menu, page action, etc)." [0]
"The "Click to play" setting is not a security measure. If you want to securely block plugins you must use the "Block all" option, which is a bit less convenient than "Click to play," but provides a click-jack resistant, browser mediated interface." [1]
"I'm kicking this out of the security queue because it isn't a security mechanism ... The secure method of blocking plugins is to select "Block all" and right-click to run. Whereas the "Click to play" feature is for convenience and performance." [2]
"It's not a security feature..." [3]
[0]: https://code.google.com/p/chromium/issues/detail?id=176724
[1]: https://code.google.com/p/chromium/issues/detail?id=225636
[2]: https://code.google.com/p/chromium/issues/detail?id=160707
[3]: https://code.google.com/p/chromium/issues/detail?id=414232
I'm sure there are other instances where they talk about it more, these are just the first results I found.
- University of Washington
- University of Waterloo
- University of Wisconsin
- University of Wyoming
etc.
Google+ had similar problems, if I remember right, and they ultimately solved the problem by getting rid of the real name policy entirely.
Which parts are they coding in secret? (Honestly, I don't know, please help me understand)
[0]: https://android-review.googlesource.com/#/q/status:open
Heh, I see that you edited it to add more since I originally pressed "Reply".
You imply Google is "evil" because they write "only about Google+ SignIn", but I'm not seeing that. The link that you provided has two sections, migrating to Google+ SignIn if you are already using a Sign In with Google button, and a section on how to migrate to just basic OpenID Connect. It doesn't seem hidden away like you are implying.
"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+." [0]
I don't understand where all your other conclusions came from.
[0]: https://developers.google.com/accounts/docs/OAuth2LoginV1
"You should not use the unsigned integer types such as uint32_t, unless there is a valid reason such as representing a bit pattern rather than a number, or you need defined overflow modulo 2^N. In particular, do not use unsigned types to say a number will never be negative. Instead, use assertions for this." [0]
[0]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.h...
element.addEventListener('click', function(e) {
this.foo();
}.bind(this), false);
Notice the call to "bind" which binds the click handler function to the current object, so that inside it can call this.foo().2. Weak typing is a nice feature for prototyping, but for larger projects, a stronger type system is better at catching bugs. Many JavaScript programmers (myself included) are used to using separate systems to check types for them. My team uses the Closure Compiler, which, along with compiling the JS to a more optimized version, is also happy to check all your types and fails to build if your types don't line up.
3. Again, I believe this is something that you can make sure that the compiler catches. And, of course, anyone can write bad code (in any language); if you're overwriting stuff halfway across the codebase, then that's "bad code" and you should avoid doing that (and during the code review stage, you should be making sure that your coworkers don't do that either).
4. Like for any language, have guidelines for how you write code, and enforce some of your conventions with the compiler and with linting tools. It leads to a more consistent codebase.
Direct link the the accompanying video playlist: https://www.youtube.com/watch?v=NAsM30MAHLg&list=PL0INsTTU1k...
Edit: Quote from the doc you linked: "This runtime type system is modeled after Dart’s runtime type assertion. Dart users working on large scale applications point out that optional types and runtime type assertions work well in practice."
"You retain ownership of any intellectual property rights that you hold in that content. In short, what belongs to you stays yours." [0].
The context of the quote from the court documents you referenced [1] is that Gmail inevitably needs to be able to process your emails in order to send them (and potentially filter out the spam). It is not, as you seem imply, about violating your privacy.
[0]: http://www.google.com/intl/en/policies/terms/
[1]: https://www.scribd.com/doc/160041493/Google-Motion-061313