1,156 karma · joined June 30, 2009
www.thelowlyprogrammer.com
Rather, I consider the _collection_ of broad data, carefully used, to be almost pre-requisite to the advancement of our species. Whenever I imagine future technologies they're all based on better use of data. "That car over there has a broken taillight - send them a message." "Pick me a movie I'll be interested in in this moment." Or data mining my personal history to make note of conversation topics I wanted to follow up on; promises I made in the moment.
To some degree, society will (and already has) reset our privacy expectations; not everything we've held as protected need always be, at least in general. What we haven't done yet though is figure out how to enable useful collection and some level of relaxed privacy constraints without opening the door to potential abuse. Which is the risk I think you're worried about - it's not that Google is abusing the data they have _right now_, but that they eventually could, and that you find that risk more compelling than all the value they're delivering now. (Which, to be fair, I cannot say is incorrect). But let's not throw the baby out with the bathwater - I want the promises of the future, and it's just a question of how we can safely get to them :).
I think I get about 50% hit rate with 'OK Google' and I'm a native English speaker :).
Having run global services myself I can tell you that the shape is usually no standard distribution. Peak/trough depends on the exact usage demographics, but the one I have on hand has a trough of ~1/2 peak, and an average of ~3/4.
The business wants to convert low-value mobile users into high-value app installers, and would happily sacrifice most to get a few installs if that's net positive on long-term value. The search engine, on the other hand, wants as many users as possible to be successful in finding what they're looking for. These perspectives are not aligned - high abandonment rates due to interstitials can be fine for the business, yet penalized as destinations from a search engine. The underlying question is who Google optimizes for in this case, the user or the destination.
This will fall apart when we get to cashing out downstream, or buying physical goods that are on-demand manufactured/shipped, or stock market trades, but a large percentage should be recoverable in $large cases and (outside of certain sophisticated patterns) the receiver of the money who spent it should be on the hook for the difference.
30m unrecoverable as yet is just silly.
If you've got the expertise to add it, sounds like it would be welcomed.
In general, the foreign debt taken on by the US is similar - e.g. bonds issued by various countries, and bought by the citizens and the government as an investment asset.
Wouldn't want to be living in the us right now, based on those numbers. That sounds like it adds up to a whole lot of corruption.
* Companies like Google and Yahoo will encrypt their internal fibre links, and more of the information crossing internet backbones, making passive information gathering more difficult.
* Funding isn't guaranteed. The NSA hasn't really been impacted yet, but it's definitely possible for their budget to be cut in the wake of the ever-increasing revelations. It'll all come down to what the politicians think will get them the most power, and they'll happily go against the NSA if it will further that cause.
* On a slightly longer timescale, a sustained negative public opinion of the NSA will impact their ability to hire the best people.
The impacts on the NSA may not be as significant as you or I might wish, but they're certainly non-zero.
Agreed trust is a problem with hidden services in general, but I think it's one we'll solve by reframing what it means to 'trust' a site in the first place.
When you talk about 'slower than a spanning tree', that's presumably for route stabilization. But that's also largely irrelevant - routes would change infrequently enough that extremely fast stabilization isn't especially important (and on a LAN, BGB would still stabilize quite quickly). In comparison, BGP lets you add all sorts of routes to your internal network, and spread load among them without hotspotting. It can handle routes of varying sizes, loops and parallel paths, etc. Spanning trees on the other hand will pick one path from point A to point B, which won't necessarily be the best general solution for a network topology. Say you want to add a 'skip list' of rack-to-rack connections, double up others, and use two parallel DC-level tree networks because you're hitting backbone throughput limits with just one. BGP will be much better able to capitalize on this crazy mesh of connections then simpler protocols like building spanning trees.
The closer we get to living "in the cloud", the more our traffic can be seen as a window into operations taking place within and between cloud services.
I don't think the claim is being made that it's better in all cases. As I understand it, Google DNS is (positioned as) a secure, ad-free resolver, and tries to be as fast as possible. In practice if there is a better resolver - say, run by your ISP - for you to use, you should use that. But often ISP resolvers fail in one dimension or another, in which case Google DNS is available as a viable alternative.
Incidentally, to your question of what data is being collected: https://developers.google.com/speed/public-dns/privacy
> Similarly, sticking a proxy between a user and their destination may add more latency than it could ever save, leading me to somewhat doubt the public reason these services exist.
Again, in the general case that might be true. I wouldn't want to use a SPDY proxy on my desktop at home, for example, as it wouldn't be able to offer me any speedup. But it's already known that similar services can provide significant benefits on mobile - look at Opera Mini. Useful feature != beneficial for everyone.
To test: try a different DNS resolver, and see if you start getting faster video loads. If you're using TWC's local resolver, try 8.8.8.8 (run by Google); if you're using Google's already try the local resolver and/or OpenDNS (208.67.222.222).
If that does work as well, I'd recommend it over the heavy-handed approach of blocking arbitrary netblocks. Especially since that second netblock listed isn't owned by Google, and so you could be collaterally blocking other content that you still want.
(Disclaimer: I work for Google, but in Ads, not anything network or YouTube related).
Monticello, Minnesota (2008): http://www.ilsr.org/monticello-fiber-network-fighting-frivol...
Lafayette, Louisiana (2010): http://arstechnica.com/tech-policy/2010/05/lousiana-fiber-ne...