If I own a store and there's a civil emergency, I won't even open my store. I would use the products for the safety/survival of my family.
On the other hand if there aren't any silly laws in place preventing your from selling your goods at 10X the normal price, maybe you will only keep aside what your family really needs and sell the rest, thus making important goods available to the public when they're really needed. But if that's illegal, yeah, might as well keep them for yourself. When things get back to normal you can continue selling whatever you didn't use at the normal price -- same as you were able to sell it for during the emergency, but without taking the risk of selling something you might need.
Restrictions on scarcity pricing are a bad idea and serve only to create even more scarcity.
Sure, but it's the partnership that justifies requiring the homeowner to install a smart meter. You're not generally obligated to do anything to help your competitors.
I don't think it's so much about the homeowner becoming a competitor, but about the homeowner asking to interoperate, becoming a partner rather than just a customer.
It seems that the bigger problem here is that modern copyright is so unreasonably long, historical documents are still under copyright. Anything over the original 28 year copyright term is really robbing the next generation of history.
While I know al copyright issues are sensitive on/. and hate going against the stream here, note that the next generation is not really robbed from history. They just have to pay for it.
Assuming the copyright owner can be found, and is willing to sell.
The basis for Eldred v Ashcroft was that the celluloid of many old films is rapidly degrading but because the copyright ownership is muddled it's impossible to find anyone from which the right to republish the films can be purchased, so the films are being lost forever.
The power companies are all moving towards "smart meter" technologies anyway. Why not make sure they've put one in that can monitor the output of a PV solar (or even a wind turbine) installation while they're at it?
For that matter, it seems perfectly reasonable to require the homeowner to install such a meter as part of a solar installation, as a condition of being able to sell power to the utility -- or even to push power into the grid at all.
Good, there is no reason to bind encryption to transport layer except to improve reliability of the channel in the face of active denial (e.g. TCP RST attack).
I disagree. To me there's at least one really compelling reason: To push universal encryption. One of my favorite features of QUIC is that encryption is baked so deeply into it that it cannot really be removed. Google tried to eliminate unencrypted connections with SPDY, but the IETF insisted on allowing unencrypted operation for HTTP2. I don't think that will happen with QUIC.
But there are other reasons as well, quite well-described in the documentation. The most significant one is performance. QUIC achieves new connection setup with less than one round trip on average, and restart with none... just send data.
Improvements to TCP helps everything layered on top of it.
True, but TCP is very hard to change. Even with wholehearted support from all of the major OS vendors, we'd have lots of TCP stacks without the new features for a decade, at least. That would not only slow adoption, it would also mean a whole lot of additional design complexity forced by backward compatibility requirements. QUIC, on the other hand, will be rolled out in applications, and it doesn't have to be backward compatible with anything other than previous versions of itself. It will make its way into the OS stacks, but systems that don't have it built in will continue using it as an app library.
Not having stupid unnecessary dependencies means I can benefit from TLS improvements even if I elect to use something other than IP to provide an ordered stream or I can use TCP without encryption and not have to pay for something I don't need.
So improve and use those protocols. You may even want to look to QUIC's design for inspiration. Then you can figure out how to integrate your new ideas carefully into the old protocols without breaking compatibility, and then you can fight your way through the standards bodies, closely scrutinized by every player that has an existing TLS or TCP implementation. To make this possible, you'll need to keep your changes small and incremental, and well-justified at every increment. Oh, but they'll also have to be compelling enough to get implementers to bother. With hard work you can succeed at this, but your timescale will be measured in decades.
In the meantime, QUIC will be widely deployed, making your work irrelevant.
As for using TCP without encryption so you don't have to pay for something you don't need, I think you're both overestimating the cost of encryption and underestimating its value. A decision that a particular data stream doesn't have enough value to warrant encryption it is guaranteed to be wrong if your application/protocol is successful. Stuff always gets repurposed and sufficient re-evaluation of security requirements is rare (even assuming the initial evaluation wasn't just wrong).
TCP+TFO + TLS extensions provide the same zero RTT opportunity as QUIC without reinventing wheels.
Only for restarts. For new connections you still have all the TCP three-way handshake overhead, followed by all of the TLS session establishment. QUIC does it in one round trip, in the worst case, and zero in most cases.
There was much valid (IMO) criticism of SPDY, that it really only helped really well-optimized sites -- like Google's -- to perform significantly better. Typical sites aren't any slower with SPDY, but aren't much faster, either, because they are so inefficient in other areas that request bottlenecks aren't their problem, so fixing those bottlenecks doesn't help. But QUIC will generally cut between two and four RTTs out of every web browser connection. And, of course, it also includes all of the improvements SPDY brought, plus new congestion management mechanisms which are significantly bette
False analogy. There's a huge difference between a personal assistant, who by definition *I* know personally, and a faceless business entity who I know not at all (read adversarial entity) scraping 'enough' information about me to presume it knows me sufficiently to second guess what I want and give me that instead of what I requested.
Not really.
I'd say there's a good argument that all of the information I give Google actually exceeds what a personal assistant would know about me. The real difference (thus far) lies in the assistant's ability to understand human context which Google's systems lack. But that's merely a problem to be solved.
Note, BTW, that I'm not saying everyone should want what I want, or be comfortable giving any search engine enough information to be such an ideal assistant. That's a personal decision. I'm comfortable with it... but I'm not yet getting the search results I want.
Why would I want crappy results? I want it to give me what I want, which by definition isn't "crappy".
And you think a system built by man can divine what you and everyone else wants at the moment you type it in? That'll be the day. Until then, assume I know what I want and not your system.
I think systems built by man that knows a sufficient amount about me, my interests and my needs can. We're not there yet, certainly, but the question was what I want... and that's it.
Put it this way: Suppose you had a really bright personal assistant who knew pretty much everything about you and could see what you are doing at any given time, and suppose this assistant also had the ability to instantly find any data on the web. I want a search engine that can give me the answers that assistant could.
Sure, but that requires only very coarse -- city-level, at most -- geolocation. If I were reviewing this product for launch, I'd tell them that they can use location as a risk signal, but must coarsen it to avoid making it possible to use it for people-tracking.
If local ISPs are involved, then what the fuck is the point of this?
Not really ISPs, at least as we traditionally think of them. Mobile network operators.
Why the fuck is there still this useless ISP middleman?
The MNO in question isn't the middleman, it's the service provider. It provides service to the balloons, which relay it to regions that are too remote to service now.
For crying out loud, this whole problem exists in the first place because the local ISPs weren't able or willing to invest in the infrastructure needed to provide Internet access to these regions.
No, most of these regions aren't served because it's uneconomical. It's not that no one is willing to invest, it's that it's not an "investment" if you know up front that the ROI will be negative. Putting up a bunch of cell towers to serve remote African farmers, for example, doesn't pan out economically because there's no way the farmers can afford to pay high enough fees to cover the costs of all the infrastructure. Project Loon aims to fix this by radically lowering the cost of serving those regions, to a point where it is economical, so the fees the people in the region can afford to pay are sufficient to make serving them profitable.
As for why Google is partnering with MNOs rather than deploying their own connectivity? I don't know but I'd guess a couple of reasons. First, I expect it will be feasible to scale faster by partnering with entities who already have a lot of the infrastructure in place, particularly when you consider all of the legal and regulatory hurdles (which in many areas means knowing who to bribe, and how -- Google, like most American companies, would not be very good at that). Second, by working through local companies Google will avoid getting into power struggles with the local governments. Google is helping their local businesses to grow, not replacing them.
(Disclaimer: I work for Google, but I don't know anything more about this than what I see/read in the public press.)
There really aren't any good ways to measure those other effects. If you knew how your experiment was biased, you'd try and fix it.
Randomized sampling goes a long way, but only if you have a large enough population. This is one of the problems of social sciences. A randomized 10% subsample from 100 subjects ain't gonna cut it. A randomized subsample from 10,000,000 people isn't going to get funded.
Why wouldn't a randomized subsample from 10M people get funded? The required sample size doesn't grow as the population does.
Actually, p-values are about CORRELATION.
Maybe *you* aren't well-positioned to be denigrating others as not statistical experts.
I may be responding to a troll here, but, no, the GP is correct. P-values are about probability. They're often used in the context of evaluating a correlation, but they needn't be. Specifically, p-values specify the probability that the observed statistical result (which may be a correlation) could be a result of random selection of a particularly bad sample. Good sampling techniques can't eliminate the possibility that your random sample just happens to be non-representative, and the p value measures the probability that this has happened. A p value of 0.05 means that there's a 5% chance that your results are bogus in this particular way.
The problem with p values is that they only describe one way that the experiment could have gone wrong, but people interpret them to mean overall confidence -- or, even worse -- significance of the result, when they really only describe confidence that the sample wasn't biased due to bad luck in random sampling. It could have been biased because the sampling methodology wasn't good. I could have been meaningless because it finds an effect which is real, but negligibly small. It be meaningless because the experiment was just badly constructed and didn't measure what it thought it was measuring. There could be lots and lots of other problems.
There's nothing inherently wrong with p values, but people tend to believe they mean far more than they do.
The phone then reports this seller's ID to some central server. Does it also report geolocation data?
I seriously doubt it. I don't see how location reporting for a payment transaction in which location data is irrelevant could possibly pass Google's privacy policy review process. Collection of data not relevant to the transaction is not generally allowed[*], and if the data in question is personally identifiable (mappable to some specific individual), then a really compelling reason for collection is required, as well as tight internal controls on how the data is managed and who has access. I don't see what could possibly justify it in this case, and I can see a lot of risk in collecting it.
FYI, Google product teams have to develop privacy design docs for all new products, and the designs have to be reviewed by the privacy team (or their delegates) and pass the privacy review before they can be launched. Although Google set these processes up before the FTC settlement, I believe they became part of the consent decree and are now mandated by the FTC and validated in regular audits, so Google can't skip or violate them without potentially-significant consequences.
Disclaimer: I'm not a Google spokesperson and this is not an official statement. It is my personal perspective on the process and requirements. However, I'm a Google engineer who's been involved in launching privacy-sensitive products, so I think my perspective is accurate. I also do security reviews of Google projects, which sometimes touches on privacy issues (though privacy review is separate from security review, as it should be).
[*] Just to head off a likely riposte: No, StreetView Wifi collection and the Safari do-not-track workaround are not counterexamples. They predated the privacy review processes and, as I understand it, were part of the motivation for establishing the processes.
In fact, by decapitating this girl and digging her brain out of her skull, they've guaranteed she is forever dead.
As opposed to what? Cremation? Burial in a box at temperatures well above freezing? You can't seriously argue that this approach makes it less likely that she could be repaired and restarted at some point in the future than typical corpse disposal methods.
There is ZERO reason to have this on desktop PC's even for things like IM programs.
Why? Do you like having to keep browser tabs open for your IM, e-mail, calendar, etc? Or to use some extension or plugin? I always keep gmail (actually, inbox) and calendar tabs pinned, but with push notifications I might not have to bother with that any more.
Thats not really the debt though. The debt is when you get a giant wad of funding and dont take the time to greenfield your cludge app.
No, that is debt, and in many cases it is the biggest single source of debt, as Darinbob said. Failing to rewrite your kludge app is just failing to pay down your debt. Whether or not the moment you get a giant wad of funding is the right time to do that depends on the context.
Encryption algorithms are constantly being tested and broken
Bah.
Oh, there's no doubt that cryptographers are continually creating and breaking new ciphers. But there are well-proven ciphers that have stood unbroken for decades. DES, for example, although the key size is now too small, has stood strong for 40 years, and in fact if you don't mind applying it three times is still proof against anyone in the world, as long as you keep the keys safe.
I have little doubt that AES will do just as well, and its much larger key size means that we won't face brute force becoming tractable, not unless actual breaks in the algorithm are discovered.
From the NSA and other governmental entities deliberately weakening the tools we use to encrypt
The fundamental algorithms, like AES, are relied upon by governmental entities, which the NSA is tasked with securing. We do have evidence that the NSA has been working in various ways to compromise implementations, but they can't really do that with ciphers, because if you modify a cipher, it won't pass the standard test vectors. The NSA can try to introduce things like side channel attacks, but if the NSA is actively monitoring your machine while you encrypt and decrypt (which is needed to exploit a side channel), you should just give up and flee to Russia now.
Really, if you use standard, widely-trusted cryptographic algorithms and are careful with how you generate and manage your keys, no one is going to get your data. Not even the NSA. Generation can be a little tricky to get right, but there are lots of good solutions. Probably the best is to randomly (e.g. with diceware) select a string of a dozen or so dictionary words, then use them with a standard key derivation function to produce a key, then use that to encrypt your data.
If that sounds complicated... it's really not. "gnupg -c" does a fine job. Run that on your files and upload them to the cloud. Since you're apparently happy with the security of your home machines (ha!), you can store a copy of the passphrase on the machine that does the backups, so you can automate everything. So that you can recover your data in the event of a fire, write down the passphrase on a piece of paper and store it somewhere offsite and secure. Give it to a friend or family member that you trust, or put it in a bank safe deposit box.
Encryption, cloud storage and an offsite copy of the decryption key are the way to go here.
If you want a nicely-automated version of all of that, you might want to look into the services provided by leastauthority.com.
Once you verify there are no tabs in your source code (which is trivial, e.g. grep -l '\t'), then any indentation or alignment problems are visible and the needed fix obvious (insert or remove spaces). The problem with mixed tabs and spaces is that since both are non-printable characters, you can't easily see which is which, which makes finding lines with improper mixtures difficult. You can write a regexp to identify lines with tabs that follow non-tab characters, then go fix them up, and you can even do things like create commit hooks to find such problems and deny commit, but its much less effort to simply disallow tabs from the outset. In theory it seems like it's roughly the same problem (identifying files with tabs vs identifying files with tabs that follow non-tabs), but in practice if you simply ban tabs you almost never end up with files that contain them. Trying to enforce the "correct" ordering of tab and non-tab characters always results in work.
In addition to that, the point of mixing tabs and spaces is to provide variable indentation size, to match developer preference... but even when that works it creates yet another problem: disagreements about line wrapping. Developers who use larger tab sizes naturally need to wrap lines earlier (shorter lines), and those who use smaller tab sizes want to wrap them later (longer lines). This pretty much guarantees inconsistent line wrapping.
This, of course, all assumes that you're doing manual formatting. The best way to handle formatting is to use a tool (e.g. clang-format) and ban all manual formatting. If you do that, then you can actually have the tool do the tabs-and-spaces mixture thing (e.g. for clang-format "UseTab: ForIndentation"), and, assuming the tool works, your tabs and spaces will always be applied correctly. But if you're using a tool like that, then there's really no point in mixing tabs and spaces, because any developer who wants a different tab size can simply run the tool with their preferred settings (including line wrapping), work on the code, then before submitting run the tool with the project settings. Ideally, the preferred settings should be applied by an editor load hook, and the project settings applied by a commit hook.
In short, with proper tool support, mixing tabs and spaces provides no value. Without proper tool support, it creates more hassle than its worth. Particularly since it really doesn't take long for a developer to get used to any given indent size.
Finally, among the whole space of developer code formatting preferences, indentation level is a trivial thing. If you want your team's code to have a consistent look (and you do... it really matters for maintainability), then you're going to have to specify a LOT of other things that different developers will disagree on, and which their editors can't paper over. So they're going to have to suck it up and accept some team style guidelines anyway. May as well include indentation level.
Slashdot Mirror
If I own a store and there's a civil emergency, I won't even open my store. I would use the products for the safety/survival of my family.
On the other hand if there aren't any silly laws in place preventing your from selling your goods at 10X the normal price, maybe you will only keep aside what your family really needs and sell the rest, thus making important goods available to the public when they're really needed. But if that's illegal, yeah, might as well keep them for yourself. When things get back to normal you can continue selling whatever you didn't use at the normal price -- same as you were able to sell it for during the emergency, but without taking the risk of selling something you might need.
Restrictions on scarcity pricing are a bad idea and serve only to create even more scarcity.
Sure, but it's the partnership that justifies requiring the homeowner to install a smart meter. You're not generally obligated to do anything to help your competitors.
I don't think it's so much about the homeowner becoming a competitor, but about the homeowner asking to interoperate, becoming a partner rather than just a customer.
It seems that the bigger problem here is that modern copyright is so unreasonably long, historical documents are still under copyright. Anything over the original 28 year copyright term is really robbing the next generation of history.
While I know al copyright issues are sensitive on /. and hate going against the stream here, note that the next generation is not really robbed from history. They just have to pay for it.
Assuming the copyright owner can be found, and is willing to sell.
The basis for Eldred v Ashcroft was that the celluloid of many old films is rapidly degrading but because the copyright ownership is muddled it's impossible to find anyone from which the right to republish the films can be purchased, so the films are being lost forever.
Interesting. I've studied the evolution of copyright law in some detail and never seen this claim. Cite?
The power companies are all moving towards "smart meter" technologies anyway. Why not make sure they've put one in that can monitor the output of a PV solar (or even a wind turbine) installation while they're at it?
For that matter, it seems perfectly reasonable to require the homeowner to install such a meter as part of a solar installation, as a condition of being able to sell power to the utility -- or even to push power into the grid at all.
SCTP, for one, doesn't have any encryption.
Good, there is no reason to bind encryption to transport layer except to improve reliability of the channel in the face of active denial (e.g. TCP RST attack).
I disagree. To me there's at least one really compelling reason: To push universal encryption. One of my favorite features of QUIC is that encryption is baked so deeply into it that it cannot really be removed. Google tried to eliminate unencrypted connections with SPDY, but the IETF insisted on allowing unencrypted operation for HTTP2. I don't think that will happen with QUIC.
But there are other reasons as well, quite well-described in the documentation. The most significant one is performance. QUIC achieves new connection setup with less than one round trip on average, and restart with none... just send data.
Improvements to TCP helps everything layered on top of it.
True, but TCP is very hard to change. Even with wholehearted support from all of the major OS vendors, we'd have lots of TCP stacks without the new features for a decade, at least. That would not only slow adoption, it would also mean a whole lot of additional design complexity forced by backward compatibility requirements. QUIC, on the other hand, will be rolled out in applications, and it doesn't have to be backward compatible with anything other than previous versions of itself. It will make its way into the OS stacks, but systems that don't have it built in will continue using it as an app library.
Not having stupid unnecessary dependencies means I can benefit from TLS improvements even if I elect to use something other than IP to provide an ordered stream or I can use TCP without encryption and not have to pay for something I don't need.
So improve and use those protocols. You may even want to look to QUIC's design for inspiration. Then you can figure out how to integrate your new ideas carefully into the old protocols without breaking compatibility, and then you can fight your way through the standards bodies, closely scrutinized by every player that has an existing TLS or TCP implementation. To make this possible, you'll need to keep your changes small and incremental, and well-justified at every increment. Oh, but they'll also have to be compelling enough to get implementers to bother. With hard work you can succeed at this, but your timescale will be measured in decades.
In the meantime, QUIC will be widely deployed, making your work irrelevant.
As for using TCP without encryption so you don't have to pay for something you don't need, I think you're both overestimating the cost of encryption and underestimating its value. A decision that a particular data stream doesn't have enough value to warrant encryption it is guaranteed to be wrong if your application/protocol is successful. Stuff always gets repurposed and sufficient re-evaluation of security requirements is rare (even assuming the initial evaluation wasn't just wrong).
TCP+TFO + TLS extensions provide the same zero RTT opportunity as QUIC without reinventing wheels.
Only for restarts. For new connections you still have all the TCP three-way handshake overhead, followed by all of the TLS session establishment. QUIC does it in one round trip, in the worst case, and zero in most cases.
There was much valid (IMO) criticism of SPDY, that it really only helped really well-optimized sites -- like Google's -- to perform significantly better. Typical sites aren't any slower with SPDY, but aren't much faster, either, because they are so inefficient in other areas that request bottlenecks aren't their problem, so fixing those bottlenecks doesn't help. But QUIC will generally cut between two and four RTTs out of every web browser connection. And, of course, it also includes all of the improvements SPDY brought, plus new congestion management mechanisms which are significantly bette
False analogy. There's a huge difference between a personal assistant, who by definition *I* know personally, and a faceless business entity who I know not at all (read adversarial entity) scraping 'enough' information about me to presume it knows me sufficiently to second guess what I want and give me that instead of what I requested.
Not really.
I'd say there's a good argument that all of the information I give Google actually exceeds what a personal assistant would know about me. The real difference (thus far) lies in the assistant's ability to understand human context which Google's systems lack. But that's merely a problem to be solved.
Note, BTW, that I'm not saying everyone should want what I want, or be comfortable giving any search engine enough information to be such an ideal assistant. That's a personal decision. I'm comfortable with it... but I'm not yet getting the search results I want.
Why would I want crappy results? I want it to give me what I want, which by definition isn't "crappy".
And you think a system built by man can divine what you and everyone else wants at the moment you type it in? That'll be the day. Until then, assume I know what I want and not your system.
I think systems built by man that knows a sufficient amount about me, my interests and my needs can. We're not there yet, certainly, but the question was what I want... and that's it.
Put it this way: Suppose you had a really bright personal assistant who knew pretty much everything about you and could see what you are doing at any given time, and suppose this assistant also had the ability to instantly find any data on the web. I want a search engine that can give me the answers that assistant could.
Why would I want crappy results? I want it to give me what I want, which by definition isn't "crappy".
Search for what I type in, not what you think I want
I want a search engine that searches for what I want, not what I type, and not even what I think I want.
Sure, but that requires only very coarse -- city-level, at most -- geolocation. If I were reviewing this product for launch, I'd tell them that they can use location as a risk signal, but must coarsen it to avoid making it possible to use it for people-tracking.
If local ISPs are involved, then what the fuck is the point of this?
Not really ISPs, at least as we traditionally think of them. Mobile network operators.
Why the fuck is there still this useless ISP middleman?
The MNO in question isn't the middleman, it's the service provider. It provides service to the balloons, which relay it to regions that are too remote to service now.
For crying out loud, this whole problem exists in the first place because the local ISPs weren't able or willing to invest in the infrastructure needed to provide Internet access to these regions.
No, most of these regions aren't served because it's uneconomical. It's not that no one is willing to invest, it's that it's not an "investment" if you know up front that the ROI will be negative. Putting up a bunch of cell towers to serve remote African farmers, for example, doesn't pan out economically because there's no way the farmers can afford to pay high enough fees to cover the costs of all the infrastructure. Project Loon aims to fix this by radically lowering the cost of serving those regions, to a point where it is economical, so the fees the people in the region can afford to pay are sufficient to make serving them profitable.
As for why Google is partnering with MNOs rather than deploying their own connectivity? I don't know but I'd guess a couple of reasons. First, I expect it will be feasible to scale faster by partnering with entities who already have a lot of the infrastructure in place, particularly when you consider all of the legal and regulatory hurdles (which in many areas means knowing who to bribe, and how -- Google, like most American companies, would not be very good at that). Second, by working through local companies Google will avoid getting into power struggles with the local governments. Google is helping their local businesses to grow, not replacing them.
(Disclaimer: I work for Google, but I don't know anything more about this than what I see/read in the public press.)
There really aren't any good ways to measure those other effects. If you knew how your experiment was biased, you'd try and fix it.
Randomized sampling goes a long way, but only if you have a large enough population. This is one of the problems of social sciences. A randomized 10% subsample from 100 subjects ain't gonna cut it. A randomized subsample from 10,000,000 people isn't going to get funded.
Why wouldn't a randomized subsample from 10M people get funded? The required sample size doesn't grow as the population does.
Actually, p-values are about CORRELATION. Maybe *you* aren't well-positioned to be denigrating others as not statistical experts.
I may be responding to a troll here, but, no, the GP is correct. P-values are about probability. They're often used in the context of evaluating a correlation, but they needn't be. Specifically, p-values specify the probability that the observed statistical result (which may be a correlation) could be a result of random selection of a particularly bad sample. Good sampling techniques can't eliminate the possibility that your random sample just happens to be non-representative, and the p value measures the probability that this has happened. A p value of 0.05 means that there's a 5% chance that your results are bogus in this particular way.
The problem with p values is that they only describe one way that the experiment could have gone wrong, but people interpret them to mean overall confidence -- or, even worse -- significance of the result, when they really only describe confidence that the sample wasn't biased due to bad luck in random sampling. It could have been biased because the sampling methodology wasn't good. I could have been meaningless because it finds an effect which is real, but negligibly small. It be meaningless because the experiment was just badly constructed and didn't measure what it thought it was measuring. There could be lots and lots of other problems.
There's nothing inherently wrong with p values, but people tend to believe they mean far more than they do.
The phone then reports this seller's ID to some central server. Does it also report geolocation data?
I seriously doubt it. I don't see how location reporting for a payment transaction in which location data is irrelevant could possibly pass Google's privacy policy review process. Collection of data not relevant to the transaction is not generally allowed[*], and if the data in question is personally identifiable (mappable to some specific individual), then a really compelling reason for collection is required, as well as tight internal controls on how the data is managed and who has access. I don't see what could possibly justify it in this case, and I can see a lot of risk in collecting it.
FYI, Google product teams have to develop privacy design docs for all new products, and the designs have to be reviewed by the privacy team (or their delegates) and pass the privacy review before they can be launched. Although Google set these processes up before the FTC settlement, I believe they became part of the consent decree and are now mandated by the FTC and validated in regular audits, so Google can't skip or violate them without potentially-significant consequences.
Disclaimer: I'm not a Google spokesperson and this is not an official statement. It is my personal perspective on the process and requirements. However, I'm a Google engineer who's been involved in launching privacy-sensitive products, so I think my perspective is accurate. I also do security reviews of Google projects, which sometimes touches on privacy issues (though privacy review is separate from security review, as it should be).
[*] Just to head off a likely riposte: No, StreetView Wifi collection and the Safari do-not-track workaround are not counterexamples. They predated the privacy review processes and, as I understand it, were part of the motivation for establishing the processes.
In fact, by decapitating this girl and digging her brain out of her skull, they've guaranteed she is forever dead.
As opposed to what? Cremation? Burial in a box at temperatures well above freezing? You can't seriously argue that this approach makes it less likely that she could be repaired and restarted at some point in the future than typical corpse disposal methods.
There is ZERO reason to have this on desktop PC's even for things like IM programs.
Why? Do you like having to keep browser tabs open for your IM, e-mail, calendar, etc? Or to use some extension or plugin? I always keep gmail (actually, inbox) and calendar tabs pinned, but with push notifications I might not have to bother with that any more.
Thats not really the debt though. The debt is when you get a giant wad of funding and dont take the time to greenfield your cludge app.
No, that is debt, and in many cases it is the biggest single source of debt, as Darinbob said. Failing to rewrite your kludge app is just failing to pay down your debt. Whether or not the moment you get a giant wad of funding is the right time to do that depends on the context.
I just read "select a string of a dozen or so dirty words" It is early.
Passphrases composed entirely of dirty words need to be much longer than a dozen entries. The dirty word space is low-entropy.
Encryption algorithms are constantly being tested and broken
Bah.
Oh, there's no doubt that cryptographers are continually creating and breaking new ciphers. But there are well-proven ciphers that have stood unbroken for decades. DES, for example, although the key size is now too small, has stood strong for 40 years, and in fact if you don't mind applying it three times is still proof against anyone in the world, as long as you keep the keys safe.
I have little doubt that AES will do just as well, and its much larger key size means that we won't face brute force becoming tractable, not unless actual breaks in the algorithm are discovered.
From the NSA and other governmental entities deliberately weakening the tools we use to encrypt
The fundamental algorithms, like AES, are relied upon by governmental entities, which the NSA is tasked with securing. We do have evidence that the NSA has been working in various ways to compromise implementations, but they can't really do that with ciphers, because if you modify a cipher, it won't pass the standard test vectors. The NSA can try to introduce things like side channel attacks, but if the NSA is actively monitoring your machine while you encrypt and decrypt (which is needed to exploit a side channel), you should just give up and flee to Russia now.
Really, if you use standard, widely-trusted cryptographic algorithms and are careful with how you generate and manage your keys, no one is going to get your data. Not even the NSA. Generation can be a little tricky to get right, but there are lots of good solutions. Probably the best is to randomly (e.g. with diceware) select a string of a dozen or so dictionary words, then use them with a standard key derivation function to produce a key, then use that to encrypt your data.
If that sounds complicated... it's really not. "gnupg -c" does a fine job. Run that on your files and upload them to the cloud. Since you're apparently happy with the security of your home machines (ha!), you can store a copy of the passphrase on the machine that does the backups, so you can automate everything. So that you can recover your data in the event of a fire, write down the passphrase on a piece of paper and store it somewhere offsite and secure. Give it to a friend or family member that you trust, or put it in a bank safe deposit box.
Encryption, cloud storage and an offsite copy of the decryption key are the way to go here.
If you want a nicely-automated version of all of that, you might want to look into the services provided by leastauthority.com.
Once you verify there are no tabs in your source code (which is trivial, e.g. grep -l '\t'), then any indentation or alignment problems are visible and the needed fix obvious (insert or remove spaces). The problem with mixed tabs and spaces is that since both are non-printable characters, you can't easily see which is which, which makes finding lines with improper mixtures difficult. You can write a regexp to identify lines with tabs that follow non-tab characters, then go fix them up, and you can even do things like create commit hooks to find such problems and deny commit, but its much less effort to simply disallow tabs from the outset. In theory it seems like it's roughly the same problem (identifying files with tabs vs identifying files with tabs that follow non-tabs), but in practice if you simply ban tabs you almost never end up with files that contain them. Trying to enforce the "correct" ordering of tab and non-tab characters always results in work.
In addition to that, the point of mixing tabs and spaces is to provide variable indentation size, to match developer preference... but even when that works it creates yet another problem: disagreements about line wrapping. Developers who use larger tab sizes naturally need to wrap lines earlier (shorter lines), and those who use smaller tab sizes want to wrap them later (longer lines). This pretty much guarantees inconsistent line wrapping.
This, of course, all assumes that you're doing manual formatting. The best way to handle formatting is to use a tool (e.g. clang-format) and ban all manual formatting. If you do that, then you can actually have the tool do the tabs-and-spaces mixture thing (e.g. for clang-format "UseTab: ForIndentation"), and, assuming the tool works, your tabs and spaces will always be applied correctly. But if you're using a tool like that, then there's really no point in mixing tabs and spaces, because any developer who wants a different tab size can simply run the tool with their preferred settings (including line wrapping), work on the code, then before submitting run the tool with the project settings. Ideally, the preferred settings should be applied by an editor load hook, and the project settings applied by a commit hook.
In short, with proper tool support, mixing tabs and spaces provides no value. Without proper tool support, it creates more hassle than its worth. Particularly since it really doesn't take long for a developer to get used to any given indent size.
Finally, among the whole space of developer code formatting preferences, indentation level is a trivial thing. If you want your team's code to have a consistent look (and you do... it really matters for maintainability), then you're going to have to specify a LOT of other things that different developers will disagree on, and which their editors can't paper over. So they're going to have to suck it up and accept some team style guidelines anyway. May as well include indentation level.
As opposed to every other whitespace scheme that gets messed up somehow leading to a maintenance burden?
Nothing is free, but using only spaces is the cheapest policy.
Been there, tried that. It inevitably gets screwed up, meaning it adds yet another maintenance burden, unnecessarily.
Thanks. That article is a couple of years old, though, and I don't think the numbers for Google were correct even when it was published.