The summary here is about as deceptive as I could possibly imagine. What Uber is attempting to do isn't to initiate a lot of bogus trips and then cancel. They're attempting to recruit drivers from other companies and have them become drivers for Uber. The use of burner phones and credit cards are to prevent the easy detection of recruiters. Not to make fake trip requests.
Personally, I believe that such tactics are legal, but morally suspect (if the tactics were illegal, it would also be illegal for a company to attempt to recruit employees from other companies. See http://en.wikipedia.org/wiki/H... )
Agreed, the path that was taken for that attempt wouldn't have worked. However, if someone had been able to compromise the credentials that would authorize a check in to the main repository, it most definitely would have worked. Adding in two factor authentication just makes it that much harder.
Well, you could have answered your own question by simply using google to look up Yubikey and reading a bit. But to give you a partial answer, the token generates an AES encrypted value and passes that value to the server for authentication. During authentication, the server decrypts the value. (the shared secret between the token and the server is the AES encryption key). The decrypted value includes a counter. And if the counter isn't greater than the previously used counter, the authentication attempt is invalid. So if you were to hit the button 100 times and record those codes, you could authenticate using any of those codes, but as soon as I hit the button and authenticated using the resulting code, all of the codes you recorded would become instantly invalid.
I believe that we can get things smaller. I'll agree that we're approaching the limits as regards what is basically a 2 dimensional layout that we're currently using for chips, but that leaves the 3rd dimension. Of course there is a lot of technical issues to overcome, but I believe that they will be overcome.
In a nutshell, they simply had any computer that contacted the web site send back the computer's real IP address and its MAC address. The actual security of the Tor wasn't affected. Just that compromising information was sent through the Tor network. Just as any other data would be sent through the Tor network.
Now I suspect the MAC address was sent so that they could identify the actual computer when they seized it via a warrant. That way the suspect couldn't claim that it wasn't their computer since the IP address was on the other side of a NAT and there were multiple computers using NAT. And the IP address was simply to make identifying the physical location easier.
Which raises an interesting question.... What if someone alters their MAC address and then enters the Tor network via a public wifi hotspot? The connection is encrypted so the fact that the hotspot is publicly accessible shouldn't be a problem. And when the computer is turned off, the MAC spoofing goes away so even if the computer is seized, they don't have a matching MAC address to prove it's the computer they hacked. And of course, since access was via an open hot spot, there's plenty of computers that could have been connected. Proving which one would be rather... difficult... without that MAC address.
Look at the article. And examine the photo in the article closely. The backpack portion of the exoskeleton has attachments. Including 2 "mini-cranes" going over the user's shoulder. And in the photo, those mini-cranes are linked via some rigging to the plate the worker is handling. So the majority of the weight of the object is handled by the exoskeleton while his hands are merely providing fine control.
So the ONLY statement anyone picking "GPLv2 only" is making, is that they don't want their code mixed with GPLv3 which honestly... is pretty silly.
If "GPLv2 only" is silly, then you might want to alert all the Linux kernel developers. After all, the code in the Linux kernel is GPLv2, not GPLv2+.....
It's not a two factor authentication, it's actually a means of generating one time passwords. In a nutshell, you can have a local device calculate the password based upon a challenge sent from the system you wish to log onto, or you can preprint a list of passwords that you can use to log onto the system. See http://en.wikipedia.org/wiki/O... for a general description of the method. You ought to be able to find out more using that page as a starting point.
I was a LM employee a few years back. Brought in on a project that was failing. And the main issue with the failure was their process. For instance, LM was using Common Criteria and they were trying to get the system to EAL4. And frankly, getting there is quite doable. Unfortunately, management and the customers for the project didn't bother to actually understand anything about requirements.
For instance, in Common Criteria, your need to tailor the documents. An example would be this template being tailored to the system requirement: FPT_FLS.1.1 The TSF shall preserve a secure state when the following types of failures occur: [assignment: list of types of failures in the TSF].
The above template is obviously intended to be tailored to include a list of possible or predictable failures upon which the system will still remain secure. But this is how LM tailored that little beauty: FPT_FLS.1.1 The TSF shall preserve a secure state upon a partial system failure.
Notice how the tailoring totally removed anything concrete about the requirement? What kind of partial failure? How do you test it? When is it violated? etc, etc, etc, ad nasium.
And that kind of bullshit "tailoring" was done EVERYWHERE. There would be multi-hour meetings just change, tailor, and interpret specifications tailored that way. And any suggestion by anyone working in the trenches stating that the requirements were badly done and needed to be redone properly in order to actually get a functional system was met by "We can't do that, it would be too costly."
If the above paradigm was used on the Social Security project, I can definitely see why progress has been snail slow and over budget. They're most likely still attempting to get their specifications correct.
The 240V 60Hz is so that it can handle both North American and UK voltage levels. If you look at the technical specifications document, you'll see that there are 2 different grounding configurations that the contestants may specify. In both configurations the inverter output is fed into an isolation transformer. One specification has the input of the isolation transformer center tapped and grounded which makes the AC outputs from the inverter swing +/- 120V from ground like you would expect in the USA. The other configuration doesn't have a center tapped transformer, but one leg of the input is grounded making one of the AC outputs swing +/- 240 V in referenced to ground and the other output is tied to ground. I suspect the 60Hz specification is due to the way transformers work. A transformer designed to operate at 50Hz using minimal materials will operate fine at 60Hz. However a transformer designed to operate at 60Hz using minimal materials will saturate magnetically at 50Hz causing it to overheat and eventually fail.
Number of lines of code? As mentioned earlier, one can easily inflate LOC with trash. Also how do you evaluate a programmer who actually reduces the lines of code in a program? By the LOC metric, said programmer is counter productive. Then again you get the beautiful quote by Ken Thompson... "One of my most productive days was throwing away 1000 lines of code."
This same article was recently posted on Techdirt. The call wasn't 8 minutes. The RECORDING was 8 minutes. There was 10 minutes of call prior to the recording even starting.
The real issue at hand is the difference between a warrent and a subpoena. The legal requirements to obtain a warrent are rather trivial and obtaining a warrent is rather easy. But a warrent doesn't extend past the boundaries on the United States. A subpoena on the other hand has far stricter oversight and requirements to obtain. But a subpoena requires the one served to provide the information requested regardless of where in the world that information resides.
What's happening is the government is attempting to get the best of both worlds. The trivial requirements of obtaining a warrent, combined with the expanse of a subpoena. And that frankly is wrong and needs to be stopped.
What astronomers mean for the word "metal" isn't what the rest of us mean.
As mentioned in the link to Metallicity, the all metal stars could be composed of carbon, nitrogen, oxygen, etc. Basically anything other than hydrogen and helium.
Ah, but by definition, the email that the unmentioned gmail.com user has is addressed to him or her. GS may have made a mistake in the address they sent it to, but it IS addressed to that gmail.com user.
Unfortunately, it needs to be anhydrous ammonia. Looking at the paper, what they're doing is
1. Convert sodium amide into metallic sodium, hydrogen, and nitrogen. 2. Convert ammonia and metallic sodium into sodium amide and hydrogen.
They can easily balance those two reactions. However, if there's any water in the system, there will be a 3rd reaction going on as well. 3. Convert water and metallic sodium into sodium hydroxide and hydrogen. That 3rd reaction would effectively consume the sodium prevent it from making more sodium amide.
Given how nasty anhydrous ammonia is, I definitely know I wouldn't want to be anywhere near an accident involving it.
As all the other posters have already mentioned, your plan won't work. But way back when anon.penet.fi was finally forced to reveal through the legal system, the real email address of a user, I did a bit of a mental exercise.
How could someone create a pseudonymous remailer that would be extremely hard if not impossible to break through the legal system?
The scheme I thought up was as follows.
1. Maintain an encrypted database of email addresses and pseudonyms.
2. Have the key to the above mentioned database stored only in RAM and never written to any persistent storage.
The above scheme would work, but power failures and reboots would effectively destroy the database so it's not a complete solution. But to work around the power issues, add the following.
3. A UPS to minimize power issues (not really required, but will reduce the down time)
4. Have the key split into multiple parts and have those parts sent to multiple trusted parties in multiple legal jurisdictions. There's plenty of secret splitting techniques out there to do this. And if your escrow parties happen to be in the USA, Finland, Italy, Switzerland, etc., it would be rather difficult to have enough of them divulge the key portion that they've been entrusted with. And of course, have those parties instructed to destroy their key portion if they ever discover that legal proceedings have been engaged against you. And of course, have your lawyer instructed to inform those parties as well.
So in the above situation if you lose power, or need to reboot, the system will be in an unusable state, but will contact the escrow parties to retrieve the key parts and reconstruct the encryption key. Once this happens, it resumes normal operation. But most other governmental attacks would have a very slight chance of success.
Of course, other refinements could be added such as a periodic "ping" to the escrows informing them that things are still OK. If a sufficiently long time elapses without such a keep alive ping being received, the escrow would delete the key portion entrusted to it.
To break such a system would be extremely difficult.
It's standard forensic practice to make bit level copies of media and examine the copies, not the original material. Your software can do anything it wants to with the USB stick and an overwrite simply means that a new copy is made from the original (using software and hardware under the investigators control) and they get to try again.
You just might want to take a look at the comment on the edit made to Yank Barry's wikipedia entry at 9:21 25 Jun 2014... The URL is http://en.wikipedia.org/w/inde... and to save you time, here's the comment
(Court cases: I expect we'll have better sources than TechEye sooner rather than later. And shortly after that, we can update Streisand effect.)
Unless you're willing to claim that all the editors of Wikipedia are geeks, then it looks like the Streisand effect is gonna have another edit in the near future.
Slashdot Mirror
The summary here is about as deceptive as I could possibly imagine. What Uber is attempting to do isn't to initiate a lot of bogus trips and then cancel. They're attempting to recruit drivers from other companies and have them become drivers for Uber. The use of burner phones and credit cards are to prevent the easy detection of recruiters. Not to make fake trip requests.
Personally, I believe that such tactics are legal, but morally suspect (if the tactics were illegal, it would also be illegal for a company to attempt to recruit employees from other companies. See http://en.wikipedia.org/wiki/H... )
If bricking a phone would also result in any stored photographs going "bye bye".... I can think of quite a few police who would like that feature.
Agreed, the path that was taken for that attempt wouldn't have worked. However, if someone had been able to compromise the credentials that would authorize a check in to the main repository, it most definitely would have worked. Adding in two factor authentication just makes it that much harder.
Well, you could have answered your own question by simply using google to look up Yubikey and reading a bit. But to give you a partial answer, the token generates an AES encrypted value and passes that value to the server for authentication. During authentication, the server decrypts the value. (the shared secret between the token and the server is the AES encryption key). The decrypted value includes a counter. And if the counter isn't greater than the previously used counter, the authentication attempt is invalid. So if you were to hit the button 100 times and record those codes, you could authenticate using any of those codes, but as soon as I hit the button and authenticated using the resulting code, all of the codes you recorded would become instantly invalid.
Well, malware injection to the linux kernel isn't a mere possibility. The incident that happened back in late 2003 comes to mind.
I believe that we can get things smaller. I'll agree that we're approaching the limits as regards what is basically a 2 dimensional layout that we're currently using for chips, but that leaves the 3rd dimension. Of course there is a lot of technical issues to overcome, but I believe that they will be overcome.
In a nutshell, they simply had any computer that contacted the web site send back the computer's real IP address and its MAC address. The actual security of the Tor wasn't affected. Just that compromising information was sent through the Tor network. Just as any other data would be sent through the Tor network.
Now I suspect the MAC address was sent so that they could identify the actual computer when they seized it via a warrant. That way the suspect couldn't claim that it wasn't their computer since the IP address was on the other side of a NAT and there were multiple computers using NAT. And the IP address was simply to make identifying the physical location easier.
Which raises an interesting question.... ... difficult ... without that MAC address.
What if someone alters their MAC address and then enters the Tor network via a public wifi hotspot?
The connection is encrypted so the fact that the hotspot is publicly accessible shouldn't be a problem.
And when the computer is turned off, the MAC spoofing goes away so even if the computer is seized, they don't have a matching MAC address to prove it's the computer they hacked. And of course, since access was via an open hot spot, there's plenty of computers that could have been connected. Proving which one would be rather
Look at the article. And examine the photo in the article closely.
The backpack portion of the exoskeleton has attachments. Including 2 "mini-cranes" going over the user's shoulder. And in the photo, those mini-cranes are linked via some rigging to the plate the worker is handling. So the majority of the weight of the object is handled by the exoskeleton while his hands are merely providing fine control.
So the ONLY statement anyone picking "GPLv2 only" is making, is that they don't want their code mixed with GPLv3 which honestly... is pretty silly.
If "GPLv2 only" is silly, then you might want to alert all the Linux kernel developers. After all, the code in the Linux kernel is GPLv2, not GPLv2+.....
It's not a two factor authentication, it's actually a means of generating one time passwords. In a nutshell, you can have a local device calculate the password based upon a challenge sent from the system you wish to log onto, or you can preprint a list of passwords that you can use to log onto the system.
See http://en.wikipedia.org/wiki/O... for a general description of the method. You ought to be able to find out more using that page as a starting point.
Oh good god...
I was a LM employee a few years back. Brought in on a project that was failing. And the main issue with the failure was their process.
For instance, LM was using Common Criteria and they were trying to get the system to EAL4. And frankly, getting there is quite doable. Unfortunately, management and the customers for the project didn't bother to actually understand anything about requirements.
For instance, in Common Criteria, your need to tailor the documents. An example would be this template being tailored to the system requirement:
FPT_FLS.1.1 The TSF shall preserve a secure state when the following types of
failures occur: [assignment: list of types of failures in the TSF].
The above template is obviously intended to be tailored to include a list of possible or predictable failures upon which the system will still remain secure. But this is how LM tailored that little beauty:
FPT_FLS.1.1 The TSF shall preserve a secure state upon a partial system failure.
Notice how the tailoring totally removed anything concrete about the requirement? What kind of partial failure? How do you test it? When is it violated? etc, etc, etc, ad nasium.
And that kind of bullshit "tailoring" was done EVERYWHERE. There would be multi-hour meetings just change, tailor, and interpret specifications tailored that way. And any suggestion by anyone working in the trenches stating that the requirements were badly done and needed to be redone properly in order to actually get a functional system was met by "We can't do that, it would be too costly."
If the above paradigm was used on the Social Security project, I can definitely see why progress has been snail slow and over budget. They're most likely still attempting to get their specifications correct.
The 240V 60Hz is so that it can handle both North American and UK voltage levels. If you look at the technical specifications document, you'll see that there are 2 different grounding configurations that the contestants may specify. In both configurations the inverter output is fed into an isolation transformer. One specification has the input of the isolation transformer center tapped and grounded which makes the AC outputs from the inverter swing +/- 120V from ground like you would expect in the USA. The other configuration doesn't have a center tapped transformer, but one leg of the input is grounded making one of the AC outputs swing +/- 240 V in referenced to ground and the other output is tied to ground. I suspect the 60Hz specification is due to the way transformers work. A transformer designed to operate at 50Hz using minimal materials will operate fine at 60Hz. However a transformer designed to operate at 60Hz using minimal materials will saturate magnetically at 50Hz causing it to overheat and eventually fail.
And you've still avoided naming any metrics....
Number of lines of code? As mentioned earlier, one can easily inflate LOC with trash.
Also how do you evaluate a programmer who actually reduces the lines of code in a program? By the LOC metric, said programmer is counter productive. Then again you get the beautiful quote by Ken Thompson... "One of my most productive days was throwing away 1000 lines of code."
Code quality? Once again, how do you judge it?
And what stats do you apply to code development?
Because quite frankly, that is the gist of the problem.
This same article was recently posted on Techdirt. The call wasn't 8 minutes. The RECORDING was 8 minutes. There was 10 minutes of call prior to the recording even starting.
The real issue at hand is the difference between a warrent and a subpoena.
The legal requirements to obtain a warrent are rather trivial and obtaining a warrent is rather easy. But a warrent doesn't extend past the boundaries on the United States. A subpoena on the other hand has far stricter oversight and requirements to obtain. But a subpoena requires the one served to provide the information requested regardless of where in the world that information resides.
What's happening is the government is attempting to get the best of both worlds. The trivial requirements of obtaining a warrent, combined with the expanse of a subpoena. And that frankly is wrong and needs to be stopped.
Obvious link....
http://www.ovff.org/pegasus/so...
What astronomers mean for the word "metal" isn't what the rest of us mean.
As mentioned in the link to Metallicity, the all metal stars could be composed of carbon, nitrogen, oxygen, etc. Basically anything other than hydrogen and helium.
Just download tails yourself and start using it. Increase the amount of encrypted traffic that they don't know the contents of.
Ah, but by definition, the email that the unmentioned gmail.com user has is addressed to him or her. GS may have made a mistake in the address they sent it to, but it IS addressed to that gmail.com user.
Unfortunately, it needs to be anhydrous ammonia.
Looking at the paper, what they're doing is
1. Convert sodium amide into metallic sodium, hydrogen, and nitrogen.
2. Convert ammonia and metallic sodium into sodium amide and hydrogen.
They can easily balance those two reactions.
However, if there's any water in the system, there will be a 3rd reaction going on as well.
3. Convert water and metallic sodium into sodium hydroxide and hydrogen.
That 3rd reaction would effectively consume the sodium prevent it from making more sodium amide.
Given how nasty anhydrous ammonia is, I definitely know I wouldn't want to be anywhere near an accident involving it.
As all the other posters have already mentioned, your plan won't work. But way back when anon.penet.fi was finally forced to reveal through the legal system, the real email address of a user, I did a bit of a mental exercise.
How could someone create a pseudonymous remailer that would be extremely hard if not impossible to break through the legal system?
The scheme I thought up was as follows.
1. Maintain an encrypted database of email addresses and pseudonyms.
2. Have the key to the above mentioned database stored only in RAM and never written to any persistent storage.
The above scheme would work, but power failures and reboots would effectively destroy the database so it's not a complete solution. But to work around the power issues, add the following.
3. A UPS to minimize power issues (not really required, but will reduce the down time)
4. Have the key split into multiple parts and have those parts sent to multiple trusted parties in multiple legal jurisdictions. There's plenty of secret splitting techniques out there to do this. And if your escrow parties happen to be in the USA, Finland, Italy, Switzerland, etc., it would be rather difficult to have enough of them divulge the key portion that they've been entrusted with. And of course, have those parties instructed to destroy their key portion if they ever discover that legal proceedings have been engaged against you. And of course, have your lawyer instructed to inform those parties as well.
So in the above situation if you lose power, or need to reboot, the system will be in an unusable state, but will contact the escrow parties to retrieve the key parts and reconstruct the encryption key. Once this happens, it resumes normal operation. But most other governmental attacks would have a very slight chance of success.
Of course, other refinements could be added such as a periodic "ping" to the escrows informing them that things are still OK. If a sufficiently long time elapses without such a keep alive ping being received, the escrow would delete the key portion entrusted to it.
To break such a system would be extremely difficult.
Or perhaps go one further....
Have your password be "I admit guilt to all crimes and charges" and then use the 5th Amendment against self incrimination.
Wouldn't work.
Reason?
It's standard forensic practice to make bit level copies of media and examine the copies, not the original material. Your software can do anything it wants to with the USB stick and an overwrite simply means that a new copy is made from the original (using software and hardware under the investigators control) and they get to try again.
You just might want to take a look at the comment on the edit made to Yank Barry's wikipedia entry at 9:21 25 Jun 2014... The URL is http://en.wikipedia.org/w/inde... and to save you time, here's the comment
(Court cases: I expect we'll have better sources than TechEye sooner rather than later. And shortly after that, we can update Streisand effect.)
Unless you're willing to claim that all the editors of Wikipedia are geeks, then it looks like the Streisand effect is gonna have another edit in the near future.