Nobody cares about DMARK? Seriously? If you're going to try and claim to be some kind of authority on anti spam, at least try and spell the names of the standards correctly! It's DMARC!
The asker of slashdot, and you, are both deeply confused about what these technologies are for.
The purpose of DKIM is not to be some kind of "anti evil bit". DKIM signing your mail does not imply it is or is not spam. The only thing DKIM does is make it easier for spam filters to identify the source of mail, so that mail stream can be more reliably classified. As it happens, many spammers don't want their email stream to be easily classified because they know their mail is not spam, so they don't sign with DKIM, but there's no inherent reason they can't and some spammers do. That's especially a problem for crappy marketing firms who genuinely believe people love their mails, but actually people don't. DKIM helps correctly classify mail in that case.
I'll repeat again. No good spam filter I'm aware of (sorry, plain old SpamAssassin doesn't count) treats the mere presence or absence of DKIM as a signal.
With one exception. That exception is when trying to fight phishing mail. If a mail claims to come from admin@yahoo.com then a good mail system will look up the yahoo.com DMARC records and see that yahoo.com claims all email from it should be signed using DKIM. If the mail isn't signed, then it can be rejected according to that DMARC policy. This means phishers can no longer forge mail that claims to be from a Yahoo address that it's not actually from. Also - mailing lists that do MITM attacks on people's mail, same thing.
If you ignore the ability to restrict personal data to particular people, news feed with intelligent ranking that tries to guess who your real friends are so you don't have to upset people who post a lot by defriending them, the ability to tag people in photos, the lack of any need for meaningless URLs and a seamless way of organising events...... then sure. Facebook is just like the web.
GSM (2G) encryption did not authenticate the cell tower, whereas UMTS (3G) and above do. Cell tower authentication should break devices like the Stingray and other forms of fake base station, unless/until governments start forcing cell carriers to hand over the signing keys for tower identities. But as devices like Stingray exist more or less exclusively to get around the warrant requirement and no carrier would assist in that way without a court order, that places the police in the awkward position of asking a judge to write an order than can only be for avoiding the same judges authority....
The problem is that some factions in the non-systemd camp are pursuing systemd "emulation" by using shims and forks. That way you just get a second rate systemd, and it will remove any motivation from upstream projects to support anything else than system. Using Ubuntu's "logind" is a short term gain, but a strategic failure for the non-systemd camp. They need their own implementation of needed infrastructure, not just copying or emulating systemd.
It sounds a lot like the non-systemd camp have no idea what they are actually for, they only know what they are against. So this kind of thing is not surprising to hear.
The "UNIX philosophy" is an empty slogan that switches people's brains off. It sounds great, until you try and build a real system with the features modern users demand, and then it turns in to an exploding nightmare of combinatorial complexity as every program tries to abstract itself from every other program in the name of political correctness. As already noted elsewhere, the programs people use serverside Linux to actually run barely resemble the UNIX command line tools and that's for good reasons...
Is there really someone so stupid that they cannot tell the difference between a cartoon drawing and a real child?
There appears to be an entire united kingdom whose legal system is populated with such people.
Just FYI, the rule against illegal cartoons exists in the USA too. The Supreme Court struck down attempts to use CP laws in this way as being obvious nonsense, so Congress just went ahead and amended the law to make it explicitly illegal as opposed to implicitly illegal.
Unfortunately a lot of crap like this ends up being brought into otherwise sane legal systems thanks to pressure from the USA to "upgrade" national laws to meet the "latest standards". Japan has been pressured for years to tighten its CP laws, being publicly named and shamed etc - the primary justification for not doing so was fear of false positives. Like this one. And like the notorious cases where two teenagers can legally have sex but not photograph themselves doing it.
Fact is, politicians love being able to say they made the law tougher on paedophiles. It's a sure popularity winner. So it's inevitable you end up with idiocy like this.
The JVM is very language specific. For example it has op codes for allocating java objects. A truly cross language virtual machine doesn't have anything anywhere near that high level or specific to a particular language.
Whuuu? The JVM does not have opcodes for allocating "java" objects unless you use a very strange definition of the term - if it worked that way then how could other languages target it? The JVM has opcodes for allocating objects and calling methods on them, including opcodes like invokedynamic that exist purely to support non-Java languages like Javascript, Python, Ruby, etc.
The JVM has a really large variety of languages that target it. It's impressive. There are static languages like Java, Scala, Kotlin, Ceylon etc, there are dynamic scripting languages like JS (using the new Nashorn engine it's only about 2-3x slower than V8), there are Lisp like languages, there are implementations of Erlang and so on. And thanks to the fairly well specified "least common denominator" type system Java provides, code written in these languages can all interop pretty nicely.
If you think the JVM is language specific then I'd suggest looking at Ruby and Kotlin, two very different languages that are not much like Java, yet nonetheless both can run on top of the JVM.
The difference is for authentication for important stuff we have to show up in person with an ID and a real human checks the identity.
For some things you can also use a SuisseID which is just a regular PKI smartcard USB dongle thingy. I have one. After installing the software, you can log in to some Swiss websites by just clicking the login button in the web page. You might have to enter a password and the dongle then signs the SSL session. It's all standards based and the certificate in the hardware is based on your legally verified identity, i.e. you show a passport at the post office and get your personalised stick through the mail a few days later.
There's no such thing as EU VAT, it varies by state. Now you have to take into account the inter-country differences and remit taxes to each EU country independently, for certain classes of goods.
Er, if you ignore things like lack of a stable driver API then sure. Lots of users would have loved one of those.
But Linus encounters fewer problems like that because he has little in the way of vision for what desktop Linux should be. His job is to make a UNIX kernel along the same lines they were being designed 30 years ago. He is largely judged by how tightly he replicates a long-dusty commercial design. Desktop Linux on the other hand has no such luxuries because old commercial UNIX was never a force on the desktop. There, it has to both forge ahead its own path, and also look to competitors like MacOS X for good ideas.
And guess what? The genesis of SystemD bears a strong resemblance to launchd, the MacOS X init system. But because that's not something you would have found in Solaris or AIX, the UNIX "community" throws a fit.
I'm not especially libertarian, but I do not believe libertarianism has anything to say against dispute mediation. Bitcoin itself has the ability to do dispute mediated transactions but it's not fully fleshed out. If it was, and had been used here, a third party could have signed off on the transaction and the money could have been released, only once the machine was delivered and working.
Of course, Robocoin may have chosen not to use such a mechanism because with pre-sales, they are often spending the purchase money to actually build the machine, but that will always be extremely risky.
Well, except, you know, running an bitcoin ATM in a shop is about a million times easier than getting a full blown banking license. Right now they often charge very high spreads because there's a lot of risk involved and the machines costs have to be paid down. But in theory there could be quite a bit of competition, given friendly governments and a long enough time horizon.
This is not about the "sales tax" (VAT in EU) which is typically assessed and paid in a defined jurisdiction where the sale occurs.
..... until January. It appears our glorious leaders in the EU have decided that they weren't getting enough VAT because people sell things out of low tax jurisdictions (how dare they), so now VAT on various types of digital products and services e.g. online software sales or e-books get to pay tax based on the jurisdiction of the buyer, not the seller. So if you sell software in the EU now you have no choice, essentially, but to hire an expensive middleman who handles the nightmare of filing VAT returns in every EU state. Plus you need to be able to track exactly where your customers are for tax purposes. Effectively people would get a discount for buying through a proxy so god knows how this will be implemented. Total nightmare. All driven by the desire for ever more tax.
By definition, if it's in the form of a 1000 CHF note then it's not in a Swiss bank. Nice try at painting an entire country as a bunch of criminals though.
If you read the TfL page about this that's exactly what they say their plan is - more track barriers, and allowing "current drivers to work for the rest of their careers". Of course I doubt the RMT will be willing to see itself slowly fade into the sunset via natural ageing, but they don't want to push it too far. London Underground engineering is incredibly efficient, they pack a lot of maintenances into the 3-4 hour engineering hours they get each night (the Tube never really shuts down per se). A lot of the upgrades require rehearsals in mockups of the stations, timing is so tight. If there was a sustained strike then a crapton of automation upgrades could be completed quite quickly.
More generally, 2-step authentication disables the risk analysis based login security. If you set up 2SV then you can use your account via Tor.
However, note that - as observed in a comment below - you cannot create a Gmail account via Tor without passing phone verification. Thus if you're logging in to a Gmail account via Tor successfully that probably means it was created outside of Tor and so has some non-Tor IPs associated with it at some point.
The key point is that email and Tor don't mix, for obvious spam reasons. It's not a Google specific thing. People may wish to look into Pond, a secure messaging service designed to be used via Tor from beginning to end.
I haven't used desktop Linux for about a year now, but before that I used it for about a decade and in the early 2000's even did development for it, so I read this post with interest.
I feel the money quote is this one:
People on the email thread have claimed we had an agenda. That's actually certainly true, everybody has one. Ours is to create a good, somewhat unified, integrated operating system. And that's pretty much all that is to our agenda. What is not on our agenda though is "destroying UNIX", "land grabbing", or "lock-in". Note that logind, kdbus or the cgroup stuff is new technology, we didn't break anything by simply writing it. Hence we are not regressing, we are just adding new components that we believe are highly interesting to people (and they apparently are, because people are making use of it now). For us having a simple design and a simple code base is a lot more important than trying to accommodate for distros that want to combine everything with everything else. I understand that that is what matters to many Debian people, but it's admittedly not a priority for us.
For what it's worth, this paragraph makes a ton of sense to me. The biggest problem with Linux, both on the desktop and to a lesser extent on the server, was the fact that you got a basically half-baked set of components that were hardly integrated at all. Basic stuff like being able to set the timezone graphically ended up being distro specific apps / hacks because there was no API to do it, and everything was held together by giant piles of shell scripts and Python which might or might not be something you could actually contribute to or work with, but was certainly never usefully documented.
Basically, the experience of using or developing on Linux gave you the impression of a man in a slightly dishevelled, ill fitting suit. All the parts of a smart suit were there, but none of them quite fitted or lined up, and there were lots of small tears everywhere. And waaaaaay too many people liked this state of affairs because they had made "I am a UNIX user" a part of their identity and had managed to convince themselves that an OS architecture that dated from the 1970's was actually totally elite, and any attempt to reform it was "ignoring the UNIX philosophy" or some shit like that.
Result: MacOS X absolutely ate Linux's lunch on the desktop, despite the fact that Linux was free and Macs.... decidedly not free. Heck Linux didn't even make much headway against Windows, even though under Ballmer the Windows team basically sat on their ass for a decade rewriting the start menu.
From a (now) outsider looking in, this whole systemd fiasco looks a lot like Linux finally being dragged into the 21st century through the sheer willpower of one man, who has an apparently infinite ability to withstand faeces-throwing by the UNIX peanut gallery. Don't like systemd? OK, stick with Debian Stable or FreeBSD and don't get the new features. Stick it to the man and keep your "I Love *Nix" t-shirt on. Me? Between reading about GNOME 3 and systemd I'm starting to wonder if it's time to revisit Linux and give it another shot. If that community can conquer its UNIX fetish and build a modern OS, it has a lot of potential.
Yes, you're right! Theo would absolutely approve of stuffing as much random hairy code into kernel space as possible - you aren't gonna find any support for this moving-things-into-userspace nonsense in OpenBSD, that's for sure!
If Infosys is in fact guilty of discriminating against American workers by refusing to hire American workers for American jobs, then such malfeasance should be punished
How do you know, though? I mean, surely any company that has an office in America and hires any non-American worker would fail your proposed test? How would international companies ever expand into the USA if hiring any non-American for an "American job" would result in their US assets being immediately liquidated?
Ultimately foreign companies have to be able to set up base and hire in other countries, and hire the people they think are best qualified. The Indian managers comment here might well be highly offensive but it doesn't actually say "don't hire American's because they're too expensive". It says "don't hire them because they suck".... a comment that I'm afraid I've read American's making about Indian developers many many times.
TrustZone-based devices also have fused per-device keys which act as the root of trust. The devices that I'm familiar with also have a hardware AES coprocessor which can load and use these per-device keys but will not reveal the actual key bits, not even to secure world code. Secure world code can request operations be performed with the keys, but not see them. Non-secure world code can't do anything except make requests of the secure world code.
I did not know this. That changes a lot - if even the TrustZone can't access the per device key directly then it would appear to give equivalent security (or actually better) to what Apple is doing.
It would be nice to know which devices implement exactly what kind of security, but it seems everything is heading in the right direction, which is very good to hear.
However, I can definitely confirm that there is a hardware-backed crypto service in most of the better Android devices. It's called keymaster. Google creates the API and the code that uses it, and device makers have to implement it, or not. To see if your device has it, go to Settings->Security->Credential Storage->Storage type and see if it says "Hardware-backed".
I think it's worth noting something here about the Android implementations. Based on the articles and other published documentation, the Android "hardware backed" key stores are in fact not hardware backed at all, but rather based on the ARM chips TrustZone technology. This creates a secure world inside the CPU which is isolated from the main operating system. The secure world can store data and do computation on the main CPU without being exposed to viruses or root level access from Android itself.
But this comes with a huge caveat. This "secure world" is in fact just the same CPU running a program written in C. Such programs can of course have exploits. And in the past this is exactly what has happened, I believe some Motorola device was rooted in this way in fact, because the TrustZone protected program had some kind of overflow bug in it and that was enough to take control of the secure space.
What's more, I think it's deeply uncertain how exposed programs running in this secure space are to side channel attacks e.g. via timing or cache line games. People keep discovering clever ways to recover secret keys when running on the same physical CPU that shouldn't be possible according to the rules of the sandbox. And where does this secure program get its entropy from? A hardware RNG? Maybe, but as far as I can tell that's entirely up to the phone manufacturer, and in a competitive environment where everyone is trying to get costs down I suspect some manufacturers would choose to save money by skipping it. After all bad randomness looks the same as good randomness.
The Apple implementation, in contrast, appears to have the per-device key blown into the chip at manufacturing time, and then hard-wired to the AES circuitry. That is, it's actually hardware based and there are no chances for a "VeriLog overflow" bug or equivalent breaking the security of the system.
Anyway, I'd like to give kudos to swillden here for taking part in the discussion and being honest about how his work on Android currently stacks up with Apple. That takes some bravery. Also, there's more to security than disk encryption. The Apple celebs drama wasn't caused by the NSA breaking disk encryption, it was a bunch of pimply 4-channers phishing or guessing account recovery details on the cloud service. Whilst Apple has historically been ahead of Android in on-device security, they have been behind Google on cloud account security and this is in many ways equally as important.
If anything, elliptic-curve cryptography is the weak-link. We're being forced onto it by being told everything else is weak. It's not as well-researched or understood as the algorithms that have been attacked for nearly 40 years. Implementations are few and based on published curves. And there's NOTHING being said about our move to it.
I want to address this statement here, because I feel it's misleading.
Elliptic curve cryptography has been researched since the 1980's. It is not at all crazy or new. It is the current state of the art, RSA is obsolete and learning-with-errors is the current best candidate for a next-gen post quantum crypto system, as far as I can tell.
Nobody is being "forced" onto ECC by being told other things are weak. To the best of anyone's knowledge, RSA is not weak given big enough key sizes. However, ECC is just as strong when used with much smaller keys and signatures, and can be much faster. Basically you halve the key size with ECC to get the security level. So a 256 bit key gives 128 bits of security, i.e. you would need to try 2^128 times to cover the entire key space, which is physically infeasible. Whereas you need perhaps a 2048 bit RSA key to get gold standard security. Additionally ECC has various other nice features that can be useful in certain contexts.
Implementations of ECC are widespread. Every OS comes with one out of the box and implementations are available for every reasonable language and platform.
Finally "based on published curves". Yes, ECC requires people standardise on some public parameters to use it. That's no different to HTML or TCP or any other standard. The one caveat that exists here is that for the secp256r1 curve (which is widely used in ECC based SSL) the curve parameters were chosen by the NSA. However, (a) nobody knows any way that this could introduce a weakness despite decades of research into ECC and (b) there are many other curves where the parameters were not chosen by the NSA, for example Curve25591 where the parameters were not only chosen by djb but every parameter has an explanation for why it's the best value that could be chosen. There's no flexibility or magic numbers in its design at all, but it's still ECC.
The good news is that the secp256r1 curve has basically no redeeming qualities at all, except that it's one of the oldest and so support is widespread. All new applications that get a free choice of curve are being based on a modern modern one like Curve25591 or secp256k1 (bitcoin), where the parameters are much more rigid and there are no ways to insert back doors.
The evaluation results from Section 4 show that work still needs to be done before program obfuscation is usable in practice. In fact, the most complex function we obfuscate with meaningful security is a 16-bit point function, which contains just 15 AND gates. Even such a simple function requires about 9 hours to obfuscate and results in an obfuscation of 31.1 GB. Perhaps more importantly (since the obfuscation time is a one-time cost), evaluating the 16-bit point obfuscation on a single input takes around 3.3 hours. However, it is important to note that the fact that we can produce any “useful” obfuscations at all is surprising. Also, both obfuscation and evaluation are embarrassingly parallel and thus would run significantly faster with more cores (the largest machine we experimented on had 32 cores).
Translated into programmer English, a "16 bit point function" is basically a mathematical function that yields either true or false depending on the input. It would correspond to the following C++ function prototype:
bool point_function(short input);
In other words you can hide a 16-bit "password" inside such a function and discover if you got a match or not. Obviously, obfuscating such a function is just a toy to experiment with. "SHA256(x) == y" is also a point function and one that can be implemented in any programming language with ease - short of brute forcing it, there is no way to break such an "obfuscated point function". Thus using this technique doesn't presently make a whole lot of sense. However, it's a great base to build on.
I should note that the reference to AND gates above doesn't mean that the program is an arbitrary circuit - it means that the "program" which is being obfuscated is in fact a boolean formula. Now you can translate boolean circuits into boolean formulas, but often only at great cost. And regular programs can only be translated into circuits at also a great cost. So you can see how far away from practicality we are. Nonetheless, just last year the entire idea that you could do this at all seemed absurd, so to call the progress so far astonishing would be an understatement. Right now the field of iO is developing so fast that the paper's authors note that whilst they were writing it, new optimisations were researched and published, so there are plenty of improvements left open for future work.
The objective of "mathematically proven security properties" via program obfuscation is definitely not achievable. After all, it's a given security principle of "security through obfuscation" is unsupportable. If an adversary is capable of obtaining the executable of a program, they can also reverse engineer that same executable. It may take a lot of effort, but it is always achievable.
That is the standard consensus view in the software industry, yes. I'm afraid to tell you though, that it's wrong.
It is important to note here a few important caveats. The first is that iO (to use the cryptographers name) is presently a theoretical technique. A new paper came out literally 5 days ago that claims to discuss an implementation of the technique but I haven't read it yet. Will do so after posting this comment. Indeed, it seems nobody is quite sure how to make it work with practical performance at this time.
The second caveat is that the most well explored version of it only applies to circuits which can be seen as a kind of pure functional program only. Actually a circuit is closer to a mathematical formula than a real program e.g. you cannot write circuits in C or any other programming language we mortals are familiar with. Researchers are now starting to look at the question of obfuscating "RAM programs" i.e. programs that look like normal imperative programs written in dialects of, say, C. But this work is still quite early.
The third caveat is that because the techniques apply to pure functions only, they cannot do input or output. This makes them somewhat less than useful for obfuscation of the sort of programs that are processed with commercial obfuscators today like video games.
Despite those caveats the technique is very exciting and promising for many reasons, none of which have to do with DRM. For example iO could provide a unifying framework for all kinds of existing cryptographic techniques, and enable cryptographic capabilities that were hereto only conjectured. For example timelock crypto can be implemented using and iO obfuscator and Bitcoin.
Slashdot Mirror
Nobody cares about DMARK? Seriously? If you're going to try and claim to be some kind of authority on anti spam, at least try and spell the names of the standards correctly! It's DMARC!
The asker of slashdot, and you, are both deeply confused about what these technologies are for.
The purpose of DKIM is not to be some kind of "anti evil bit". DKIM signing your mail does not imply it is or is not spam. The only thing DKIM does is make it easier for spam filters to identify the source of mail, so that mail stream can be more reliably classified. As it happens, many spammers don't want their email stream to be easily classified because they know their mail is not spam, so they don't sign with DKIM, but there's no inherent reason they can't and some spammers do. That's especially a problem for crappy marketing firms who genuinely believe people love their mails, but actually people don't. DKIM helps correctly classify mail in that case.
I'll repeat again. No good spam filter I'm aware of (sorry, plain old SpamAssassin doesn't count) treats the mere presence or absence of DKIM as a signal.
With one exception. That exception is when trying to fight phishing mail. If a mail claims to come from admin@yahoo.com then a good mail system will look up the yahoo.com DMARC records and see that yahoo.com claims all email from it should be signed using DKIM. If the mail isn't signed, then it can be rejected according to that DMARC policy. This means phishers can no longer forge mail that claims to be from a Yahoo address that it's not actually from. Also - mailing lists that do MITM attacks on people's mail, same thing.
If you ignore the ability to restrict personal data to particular people, news feed with intelligent ranking that tries to guess who your real friends are so you don't have to upset people who post a lot by defriending them, the ability to tag people in photos, the lack of any need for meaningless URLs and a seamless way of organising events ...... then sure. Facebook is just like the web.
GSM (2G) encryption did not authenticate the cell tower, whereas UMTS (3G) and above do. Cell tower authentication should break devices like the Stingray and other forms of fake base station, unless/until governments start forcing cell carriers to hand over the signing keys for tower identities. But as devices like Stingray exist more or less exclusively to get around the warrant requirement and no carrier would assist in that way without a court order, that places the police in the awkward position of asking a judge to write an order than can only be for avoiding the same judges authority....
So Clojure is not an interesting Lisp-like language? BTW there is a smalltalk for the JVM: http://www.redline.st/discover...
It sounds a lot like the non-systemd camp have no idea what they are actually for, they only know what they are against. So this kind of thing is not surprising to hear.
The "UNIX philosophy" is an empty slogan that switches people's brains off. It sounds great, until you try and build a real system with the features modern users demand, and then it turns in to an exploding nightmare of combinatorial complexity as every program tries to abstract itself from every other program in the name of political correctness. As already noted elsewhere, the programs people use serverside Linux to actually run barely resemble the UNIX command line tools and that's for good reasons ...
Just FYI, the rule against illegal cartoons exists in the USA too. The Supreme Court struck down attempts to use CP laws in this way as being obvious nonsense, so Congress just went ahead and amended the law to make it explicitly illegal as opposed to implicitly illegal.
Unfortunately a lot of crap like this ends up being brought into otherwise sane legal systems thanks to pressure from the USA to "upgrade" national laws to meet the "latest standards". Japan has been pressured for years to tighten its CP laws, being publicly named and shamed etc - the primary justification for not doing so was fear of false positives. Like this one. And like the notorious cases where two teenagers can legally have sex but not photograph themselves doing it.
Fact is, politicians love being able to say they made the law tougher on paedophiles. It's a sure popularity winner. So it's inevitable you end up with idiocy like this.
South Korea is hardly the third world. If Danish shipyards can't beat them on price, why not?
Whuuu? The JVM does not have opcodes for allocating "java" objects unless you use a very strange definition of the term - if it worked that way then how could other languages target it? The JVM has opcodes for allocating objects and calling methods on them, including opcodes like invokedynamic that exist purely to support non-Java languages like Javascript, Python, Ruby, etc.
The JVM has a really large variety of languages that target it. It's impressive. There are static languages like Java, Scala, Kotlin, Ceylon etc, there are dynamic scripting languages like JS (using the new Nashorn engine it's only about 2-3x slower than V8), there are Lisp like languages, there are implementations of Erlang and so on. And thanks to the fairly well specified "least common denominator" type system Java provides, code written in these languages can all interop pretty nicely.
If you think the JVM is language specific then I'd suggest looking at Ruby and Kotlin, two very different languages that are not much like Java, yet nonetheless both can run on top of the JVM.
For some things you can also use a SuisseID which is just a regular PKI smartcard USB dongle thingy. I have one. After installing the software, you can log in to some Swiss websites by just clicking the login button in the web page. You might have to enter a password and the dongle then signs the SSL session. It's all standards based and the certificate in the hardware is based on your legally verified identity, i.e. you show a passport at the post office and get your personalised stick through the mail a few days later.
There's no such thing as EU VAT, it varies by state. Now you have to take into account the inter-country differences and remit taxes to each EU country independently, for certain classes of goods.
Er, if you ignore things like lack of a stable driver API then sure. Lots of users would have loved one of those.
But Linus encounters fewer problems like that because he has little in the way of vision for what desktop Linux should be. His job is to make a UNIX kernel along the same lines they were being designed 30 years ago. He is largely judged by how tightly he replicates a long-dusty commercial design. Desktop Linux on the other hand has no such luxuries because old commercial UNIX was never a force on the desktop. There, it has to both forge ahead its own path, and also look to competitors like MacOS X for good ideas.
And guess what? The genesis of SystemD bears a strong resemblance to launchd, the MacOS X init system. But because that's not something you would have found in Solaris or AIX, the UNIX "community" throws a fit.
I'm not especially libertarian, but I do not believe libertarianism has anything to say against dispute mediation. Bitcoin itself has the ability to do dispute mediated transactions but it's not fully fleshed out. If it was, and had been used here, a third party could have signed off on the transaction and the money could have been released, only once the machine was delivered and working.
Of course, Robocoin may have chosen not to use such a mechanism because with pre-sales, they are often spending the purchase money to actually build the machine, but that will always be extremely risky.
Well, except, you know, running an bitcoin ATM in a shop is about a million times easier than getting a full blown banking license. Right now they often charge very high spreads because there's a lot of risk involved and the machines costs have to be paid down. But in theory there could be quite a bit of competition, given friendly governments and a long enough time horizon.
By definition, if it's in the form of a 1000 CHF note then it's not in a Swiss bank. Nice try at painting an entire country as a bunch of criminals though.
If you read the TfL page about this that's exactly what they say their plan is - more track barriers, and allowing "current drivers to work for the rest of their careers". Of course I doubt the RMT will be willing to see itself slowly fade into the sunset via natural ageing, but they don't want to push it too far. London Underground engineering is incredibly efficient, they pack a lot of maintenances into the 3-4 hour engineering hours they get each night (the Tube never really shuts down per se). A lot of the upgrades require rehearsals in mockups of the stations, timing is so tight. If there was a sustained strike then a crapton of automation upgrades could be completed quite quickly.
More generally, 2-step authentication disables the risk analysis based login security. If you set up 2SV then you can use your account via Tor.
However, note that - as observed in a comment below - you cannot create a Gmail account via Tor without passing phone verification. Thus if you're logging in to a Gmail account via Tor successfully that probably means it was created outside of Tor and so has some non-Tor IPs associated with it at some point.
The key point is that email and Tor don't mix, for obvious spam reasons. It's not a Google specific thing. People may wish to look into Pond, a secure messaging service designed to be used via Tor from beginning to end.
I haven't used desktop Linux for about a year now, but before that I used it for about a decade and in the early 2000's even did development for it, so I read this post with interest.
I feel the money quote is this one:
For what it's worth, this paragraph makes a ton of sense to me. The biggest problem with Linux, both on the desktop and to a lesser extent on the server, was the fact that you got a basically half-baked set of components that were hardly integrated at all. Basic stuff like being able to set the timezone graphically ended up being distro specific apps / hacks because there was no API to do it, and everything was held together by giant piles of shell scripts and Python which might or might not be something you could actually contribute to or work with, but was certainly never usefully documented.
Basically, the experience of using or developing on Linux gave you the impression of a man in a slightly dishevelled, ill fitting suit. All the parts of a smart suit were there, but none of them quite fitted or lined up, and there were lots of small tears everywhere. And waaaaaay too many people liked this state of affairs because they had made "I am a UNIX user" a part of their identity and had managed to convince themselves that an OS architecture that dated from the 1970's was actually totally elite, and any attempt to reform it was "ignoring the UNIX philosophy" or some shit like that.
Result: MacOS X absolutely ate Linux's lunch on the desktop, despite the fact that Linux was free and Macs .... decidedly not free. Heck Linux didn't even make much headway against Windows, even though under Ballmer the Windows team basically sat on their ass for a decade rewriting the start menu.
From a (now) outsider looking in, this whole systemd fiasco looks a lot like Linux finally being dragged into the 21st century through the sheer willpower of one man, who has an apparently infinite ability to withstand faeces-throwing by the UNIX peanut gallery. Don't like systemd? OK, stick with Debian Stable or FreeBSD and don't get the new features. Stick it to the man and keep your "I Love *Nix" t-shirt on. Me? Between reading about GNOME 3 and systemd I'm starting to wonder if it's time to revisit Linux and give it another shot. If that community can conquer its UNIX fetish and build a modern OS, it has a lot of potential.
Yes, you're right! Theo would absolutely approve of stuffing as much random hairy code into kernel space as possible - you aren't gonna find any support for this moving-things-into-userspace nonsense in OpenBSD, that's for sure!
How do you know, though? I mean, surely any company that has an office in America and hires any non-American worker would fail your proposed test? How would international companies ever expand into the USA if hiring any non-American for an "American job" would result in their US assets being immediately liquidated?
Ultimately foreign companies have to be able to set up base and hire in other countries, and hire the people they think are best qualified. The Indian managers comment here might well be highly offensive but it doesn't actually say "don't hire American's because they're too expensive". It says "don't hire them because they suck" .... a comment that I'm afraid I've read American's making about Indian developers many many times.
I did not know this. That changes a lot - if even the TrustZone can't access the per device key directly then it would appear to give equivalent security (or actually better) to what Apple is doing.
It would be nice to know which devices implement exactly what kind of security, but it seems everything is heading in the right direction, which is very good to hear.
I think it's worth noting something here about the Android implementations. Based on the articles and other published documentation, the Android "hardware backed" key stores are in fact not hardware backed at all, but rather based on the ARM chips TrustZone technology. This creates a secure world inside the CPU which is isolated from the main operating system. The secure world can store data and do computation on the main CPU without being exposed to viruses or root level access from Android itself.
But this comes with a huge caveat. This "secure world" is in fact just the same CPU running a program written in C. Such programs can of course have exploits. And in the past this is exactly what has happened, I believe some Motorola device was rooted in this way in fact, because the TrustZone protected program had some kind of overflow bug in it and that was enough to take control of the secure space.
What's more, I think it's deeply uncertain how exposed programs running in this secure space are to side channel attacks e.g. via timing or cache line games. People keep discovering clever ways to recover secret keys when running on the same physical CPU that shouldn't be possible according to the rules of the sandbox. And where does this secure program get its entropy from? A hardware RNG? Maybe, but as far as I can tell that's entirely up to the phone manufacturer, and in a competitive environment where everyone is trying to get costs down I suspect some manufacturers would choose to save money by skipping it. After all bad randomness looks the same as good randomness.
The Apple implementation, in contrast, appears to have the per-device key blown into the chip at manufacturing time, and then hard-wired to the AES circuitry. That is, it's actually hardware based and there are no chances for a "VeriLog overflow" bug or equivalent breaking the security of the system.
Anyway, I'd like to give kudos to swillden here for taking part in the discussion and being honest about how his work on Android currently stacks up with Apple. That takes some bravery. Also, there's more to security than disk encryption. The Apple celebs drama wasn't caused by the NSA breaking disk encryption, it was a bunch of pimply 4-channers phishing or guessing account recovery details on the cloud service. Whilst Apple has historically been ahead of Android in on-device security, they have been behind Google on cloud account security and this is in many ways equally as important.
I want to address this statement here, because I feel it's misleading.
Elliptic curve cryptography has been researched since the 1980's. It is not at all crazy or new. It is the current state of the art, RSA is obsolete and learning-with-errors is the current best candidate for a next-gen post quantum crypto system, as far as I can tell.
Nobody is being "forced" onto ECC by being told other things are weak. To the best of anyone's knowledge, RSA is not weak given big enough key sizes. However, ECC is just as strong when used with much smaller keys and signatures, and can be much faster. Basically you halve the key size with ECC to get the security level. So a 256 bit key gives 128 bits of security, i.e. you would need to try 2^128 times to cover the entire key space, which is physically infeasible. Whereas you need perhaps a 2048 bit RSA key to get gold standard security. Additionally ECC has various other nice features that can be useful in certain contexts.
Implementations of ECC are widespread. Every OS comes with one out of the box and implementations are available for every reasonable language and platform.
Finally "based on published curves". Yes, ECC requires people standardise on some public parameters to use it. That's no different to HTML or TCP or any other standard. The one caveat that exists here is that for the secp256r1 curve (which is widely used in ECC based SSL) the curve parameters were chosen by the NSA. However, (a) nobody knows any way that this could introduce a weakness despite decades of research into ECC and (b) there are many other curves where the parameters were not chosen by the NSA, for example Curve25591 where the parameters were not only chosen by djb but every parameter has an explanation for why it's the best value that could be chosen. There's no flexibility or magic numbers in its design at all, but it's still ECC.
The good news is that the secp256r1 curve has basically no redeeming qualities at all, except that it's one of the oldest and so support is widespread. All new applications that get a free choice of curve are being based on a modern modern one like Curve25591 or secp256k1 (bitcoin), where the parameters are much more rigid and there are no ways to insert back doors.
OK, I read the paper.
The money quote is at the end:
Translated into programmer English, a "16 bit point function" is basically a mathematical function that yields either true or false depending on the input. It would correspond to the following C++ function prototype:
bool point_function(short input);
In other words you can hide a 16-bit "password" inside such a function and discover if you got a match or not. Obviously, obfuscating such a function is just a toy to experiment with. "SHA256(x) == y" is also a point function and one that can be implemented in any programming language with ease - short of brute forcing it, there is no way to break such an "obfuscated point function". Thus using this technique doesn't presently make a whole lot of sense. However, it's a great base to build on.
I should note that the reference to AND gates above doesn't mean that the program is an arbitrary circuit - it means that the "program" which is being obfuscated is in fact a boolean formula. Now you can translate boolean circuits into boolean formulas, but often only at great cost. And regular programs can only be translated into circuits at also a great cost. So you can see how far away from practicality we are. Nonetheless, just last year the entire idea that you could do this at all seemed absurd, so to call the progress so far astonishing would be an understatement. Right now the field of iO is developing so fast that the paper's authors note that whilst they were writing it, new optimisations were researched and published, so there are plenty of improvements left open for future work.
That is the standard consensus view in the software industry, yes. I'm afraid to tell you though, that it's wrong.
Last year there was a mathematical breakthrough in the field of what is called "indistinguishability obfuscation". This is a mathematical approach to program obfuscation which has sound theoretical foundations. This line of work could in theory yield programs whose functioning cannot be understood no matter how skilled the reverse engineer is.
It is important to note here a few important caveats. The first is that iO (to use the cryptographers name) is presently a theoretical technique. A new paper came out literally 5 days ago that claims to discuss an implementation of the technique but I haven't read it yet. Will do so after posting this comment. Indeed, it seems nobody is quite sure how to make it work with practical performance at this time.
The second caveat is that the most well explored version of it only applies to circuits which can be seen as a kind of pure functional program only. Actually a circuit is closer to a mathematical formula than a real program e.g. you cannot write circuits in C or any other programming language we mortals are familiar with. Researchers are now starting to look at the question of obfuscating "RAM programs" i.e. programs that look like normal imperative programs written in dialects of, say, C. But this work is still quite early.
The third caveat is that because the techniques apply to pure functions only, they cannot do input or output. This makes them somewhat less than useful for obfuscation of the sort of programs that are processed with commercial obfuscators today like video games.
Despite those caveats the technique is very exciting and promising for many reasons, none of which have to do with DRM. For example iO could provide a unifying framework for all kinds of existing cryptographic techniques, and enable cryptographic capabilities that were hereto only conjectured. For example timelock crypto can be implemented using and iO obfuscator and Bitcoin.