Yes, same error, but you missed it. The fundamental problem is that truely secure non-centralized key verification is HARD. If the bank publishes their GPG key, why would you trust it?

Tools for managing one's trust network barely exist. This problem is not isolated to GPG. This problem is so difficult that the more commonly used protocols, HTTPS and S/MIME, solve it effectively by ignoring it and replacing it with a system in which individuals have little or no control over their trust network. Marlinspike has participated in efforts to improve the trust network for HTTPS, but makes the same error, as use of his tools requires one to trust him.

Exactly. The problem here is the way the SIM is being used. The SIM manufacturer stores a key on the SIM and gives a copy to the carrier. Then if the NSA can just steal the key (from the SIM manufacturer or the carrier) they can do all sorts of nasty. The right way to do this is have a private key generated on the SIM and never leaving it and the carrier only gets the corresponding public key from the SIM manufacturer. Then the information that the SIM manufacturer and the carrier has is not sensitive and cannot be used to impersonate the SIM and decrypt communications. I'm sure there are reasonable historical reasons why the "right thing" is not being done. This reminds me of wifi which took several iterations of the standard to get something that is not trivially insecure, and even still it is not too hard to just pick the wrong settings and it becomes insecure.

The first article says they are just storing a secret key on the SIM and on the network provider's systems. That is just dumb and was totally insecure even before this happened. They should be using privat/public key pairs in which the private key is generated on and never leaves the SIM.

Apparently you don't read many papers. It is very common, I daresay almost ubiquitous, for scientific papers to say "this work supported by X".

Even if they had gotten the generators, you can't just rewire things on the spur of the moment like that, especially not when a significant section of the country has also been wiped out. Of course if they had proper hardened vents like are required in the US, there wouldn't have been any explosions. Still would have been a technical loss of containment due to the necessity of venting, and probably still a meltdown, but the destruction of the outer containment and cooling systems by the explosions was the real disaster.

The case in the article seems like an example of this kind of problem with the systemd team. Instead of working with one of the prominent bootloaders to get the UEFI trust chain worked out, they just adopt an infrequently-updated nonstandard (sounds like = buggy) bootloader and run with it. This has the effect of abandoning all the work already put in by the prominent bootloaders to get corner cases working. It's a shortcut so systemd can add a bullet to their feature list, but provides the feature in such a way that it is buggy for many use cases.

I don't object so much to replacing sysv init, but the systemd team appears to have a tendency toward repeatedly reinventing the wheel badly just to get things done faster, and being kinda rude about it, and that makes one a bit uneasy. Though I'm honestly unsure if this is just the sensationalization of a few usual cases or more typical behavior.

The lock screen and the login screen are different things in X. Typically on X ctrl-alt-backspace will kill the X server and give you a fresh login screen. I always thought that the assumption is that propagating this behavior from login to unlock has too many gotchas to be worthwhile. In an environment where security is essential, you should always log out instead of locking and hit ctrl-alt-backspace before you log back in.

How about a cryptocurrency that targets an inflation rate that is known to be economically stable, say 2%, by standardizing on a openly evaluated standard basket of goods. You know, how actual currencies work but without the middlemen of the reserve banks. Most of the discussion of cryptocurrencies don't even distinguish growth of money supply from inflation, even though they are two entirely different (though related) things. The cryptocurrencies currently termed "inflationary" just grow their money supply. That's not even what is meant by "inflation" when discussing real currencies like the dollar or the euro.

The other option is that Microsoft could acknowledge reality - they are not fixing things fast enough to resist targeted attacks. MS's statement about it "not being seen in the wild" demonstrates that they don't understand the current state of exploits. Google's hypothetical attacker is one who will go to lengths to keep an exploit from being used specifically so that MS won't fix it. Also a monthly schedule for updates is a huge liability against such an attacker, as they know their window of opportunity. MS is stuck in the old model that an exploit is not important unless it has been seen in the wild. While that is all well and good for preventing worms from spreading (and therefore protecting MS's image) it is not good enough to protect your company's data from a targeted attack that can buy or discover a zero-day vulnerability. That is reality.

Another way to look at it is that people using MS stuff have chosen interoperability over security. Thus the longer patch testing cycle, and the once-a-month updates. Therefore they shouldn't be surprised when it is demonstrated that... they chose interoperability over security.

You seem to have missed the fact that even with the early google search, they used javascript tricks to send every click on a link back to google. That is pretty darn close to spying, since it was not obvious that they were doing this. You don't seem to have noticed that you were being spied on.

So the model for search as well as for gmail was the user trading their privacy for a service. Thus "built on the concept of invading privacy". I think this is a much more even trade on the search side - I'm not averse to reporting to google which of their search results I looked at for a given query before I left the page. That provides better search. But I think one can make an argument that even offering a service in which you are scanning the user's email to market things to them is inherently evil. If you found out your IT staff at a company was just trolling through email for anything you would fire them in a second. Then it just went downhill from there. Though Big Brother Facebook beat Big Brother Google in the race to the bottom.

The fact is that the vendor you purchased your device from (Verizon) actively discourages third-party updates is between you and them. In most cases you cat jailbreak your device and install cyanogenmod, which is pretty similar to what you describe. The status of vendor-supplied updates has been discussed since the inception of Android. Google has mostly made the situation better compared to before Android, since updates for many devices are now controlled by the hardware vendor instead of the network provider. When you purchased your device, you chose to get something from a vendor (Verizon) who is well-known to be hostile to its customers. Don't complain that google didn't save your bacon. You could have bought a Google nexus 7, which is still getting updates, though the latest makes the old ones too slow to use. (In fact they did save your bacon, because you could just root your device to install cyanogenmod. Except that it appears that verizon patched the hole that was being used to root it! Wow that's hostile.)

In the case of Windows, you probably purchased your machine from someone like Dell (not comcast, which would be the closest analog of Verizon in the PC world) and it at least purported to have software from a separate vendor, Microsoft. Verizon, by locking the bootloader, actively prevents you from using system software from another vendor.

And, to add to the perverse outcomes, when you move on to another place, the one you just left gets the renewal/continuation grant instead of you and the funding agency wonders why it doesn't produce anything.

Buy? What is this buy thing that you speak of? We only rent our culture at this point, it's all actually owned by corporations. Or put a more serious way: does havig something available on netfix even count as being distributed for copyright purposes? I didn't think that movie theater shows did, since they are technically private exhibitions. I think HBO does, but what about netflix?

I think typically each file would be encrypted with a separate symmetric key. Then you can choose who is able to decrypt it by sticking a header with this key encrypted for various public/private key pairs. Then all you have to do is remove one of the encrypted keys, not re-upload the whole file.

As far as I know asymmetric encryption is never used the way you say in practice. It is too slow. It is used to encrypt a key for a symmetric cipher that is then used to encrypt the actual data. And that "combining your private key and their public key" statement is nonsense. Your private key is useless for securing information originating from you, since your public key is, well, public. It is useful for authenticating that information came from you, which is independent of recipient.

This is all setting aside the fact that once a party has access to some data, "revoking" that access has a sortof squishy meaning because they can just keep a copy of what they retrieved before.

I would expect removing them would be to prevent anyone else being a victim. Rather than marking every page with him on it with a "warning this former faculty was found to have sexually harassed students," the prudent course of action is to shut it all down and sort things out later. While Lewin is no longer active in the courses, they are still active courses and a student might approach him if they didn't know about the issue. There are plenty of other physics faculty at MIT that can fill in the content.