This is exactly what I would proclaim if I was able to decrypt the traffic and want users to think that I couldn't. Maybe not all whatever terrorists would fall for this but some would.
But then again, maybe they're smarter than this. Maybe they really can't break it. But they want you to think they can break it, so they tell you they can't, because they know terrorists (and slashdotters) always expect the government to try and mislead them. Great way to undermine confidence in Skype in circles of suspicious users, without causing problems for the regular users. You obviously fell for it:-)
With a gasoline-powered car, how much worse does your fuel consumption get when you turn on the A/C? Well, an electric car requires a similar amount of energy to move it to a gas-powered car. So, to a first approximation, your electric car range will be reduced by a similar fraction to the reduction in range you get with a gas-powered car when you switch on the A/C.
Heating is perhaps more of an issue, because waste heat on a gas-powered car is similar to the usable power output, so you've got a lot of heat spare. But assuming you use a heat-pump to do the heating, and pump waste heat from the electric motors and battery packs, then likely it won't be much different from the A/C problem. We're talking about vehicles in the 40KW continuous power output range (peak of 100KW). Assume you get 90% efficiency (which would be pretty good), then you've still got 4KW of waste heat in the motors and batteries. If you can capture say half of that using a heat-pump, you can still be toasty-warm.
Summary: not completely negligible, but probably only a few percent difference to the range.
Sure the conspiracy theorists will have a field day, but there is a basic conflict between providing localized services and privacy of location. I don't know what Apple really use this information for, but I'm sure that (like just about everyone else) Apple would like to provide locally-relevant information to you as you travel. Weather is an obvious one - the nicest simplest to use UI would obviously want to be able to tell you what the weather will be tomorrow wherever you happen to be today.
Of course the phone company already knows where you are, and can provide this sort of service, but then you have to use the phone company's UI. Apple can provide you with a nice elegant unified user interface, and that's what most users want.
Now, once they've got this information, they can misuse it for all sorts of purposes. It needs consumer pressure (or in Europe, there's data protection legislation) to keep such companies honest. But expecting them not to need to have this information is rather strange - they do have a need if they want to present the best localized UI possible.
And no, I don't have an iPhone. I do have a Blackberry, and I know Research in Motion know where I am all the time, because most of my traffic traverses one of their proxies. Most other smart phones do something similar. Apple really doesn't seem half as bad in comparison.
What about if your job calls for you to take a laptop that you don't necessarily "want", but it's now part of your job (as a travelling salesman, a consultant, or whatever)? And what if the lunkheads who image that laptop don't bother to put any encryption or other data protection software on it? And you're not allowed to add any "unauthorized software" to help protect yourself?
Then my understanding is that the data protection law would not place the blame on the person carrying the laptop, but on the person in the organization who dictated that sensitive data is stored insecurely. In your hypothetical case, likely the pointy-haired boss would be the one facing criminal charges.
For symmetric key encryption, why not modify the encryption/decryption software so the first thing it does is do a SHA-256 hash of the key and then uses this internally as the key. The advantage is that the key can now be REALLY big. Say, 50MB of random data, encrypted with another passphrase, and stored on a friends machine offshore out of their jurisdiction.
You're obliged to hand over the key? No problem, phone your friend, give him the passphrase, and get him to print out the contents, and mail the printout to them.
I've never used satellite myself, but it seems pretty unlikely Satellite really isn't an option if you really want it. These satellites are in an geostationary orbit 22000 miles above the equator. Assuming you're about 40 degrees North (typical US latitude) then doing the trig, the satellite should be about 40 degrees above the horizontal. To a rough approximation, anywhere that gets reasonable sunlight around 1pm this time of year should have line of sight to the satellite (ignoring that the satellite is probably not due south). The sun will be 50 degrees above the horizontal, so as long as the sun clears the hill by 10 degrees or more you should be OK. Your hill would have to be very steep for satellite to be completely impossible. You may however have to build a tower so get line of sight above the trees if it's really heavily forested.
If it's really the case that nowhere on your property gets any sunlight this time of year, then I really would suggest moving!
Yes, I agree with you. In particular, people often get confused by what MUST means in documents like this.
The MUST/SHOULD/MAY terminology in RFCs is to indicate levels of compliance with a specification. If this were a specification, or even a BCP (Best Current Practice) RFC document, then this might make sense. But it is intended to be an Informational RFC, which has no weight as a standard whatsover. So MUST/SHOULD/MAY terminology is completely inappropriate (in case you're wondering, yes I have written quite a few RFCs).
This document is an individual submission at the moment. Anyone can submit such a document; this does not indicate any level of support by the wider IETF, let alone anyone else. If the IETF were to take this on, and make it a BCP, then the terminology would indicate levels of support, and you could legitimately claim that an organization that did not comply was not providing standards-compliant service. It's possible this could embarrass an organization, but somehow I doubt it. However, if there were such a document, it might be possible for national governments to legislate compliance. Only then would it have any significant impact, but I think legislation here is unlikely and probably inappropriate.
Likely what will happen is that the regional registries will run out of address space to allocate in approximately three years from now (this is the current best estimate from Geoff Huston, who probably knows more about this than anyone else). ISPs will find it hard to get addresses after that, and a market will naturally emerge. Basically address space will become expensive. Also, there will be incentive to disaggregate currently aggregated address space, so more organizations can multihome. This will cause increasing routing table explosion in routers, and cause ISPs to need to either filter route advertisements (breaking multihoming) or upgrade routers (requiring them to spend money). And increasingly larger organizations will start to use NATs, making all sorts of applications harder to set up than they need to be. When your home NAT is behind your ISP's NAT, I suspect lots of things will break really badly. Maybe eventually the pain will get great enough that the switchover starts to reach critical mass, and only then will organizations actually allocate budget to make it happen.
There is a lot to be said in favour of moving forward in a less chaotic way that this, but I'm skeptical about the likelihood of that actually happening.
It seems like this avoids the build-up of an insulating layer of zinc oxide. So, what happens when you put a current through something with higher resistance? It gets warm. Presumably then, if you have a relatively high-drain device, you're wasting a fair amount of the chemical energy from the battery in heating up the battery. Avoid this, and the battery should last longer.
Maybe we'll finally see functional languages come to the forefront. They make it a whole lot easier for the compiler to extract parallelism automatically. For example,see Parallel Haskell. I think this is the closest I've seen to a "magical threading language".
And if you're really paranoid, the.login script from the fake account can run a setuid program that deletes your regular home directory (you do have backups don't you?), overwrites the files with random data multiple times, and then deletes itself. Likely they'll take long enough probing the fake directory that the real data will be gone without a trace by the time they even start to think they should be looking elsewhere.
You charge the spare 100KWh supercapacitor you have at home over 24 hours. That takes about 4KW. Then when you want to charge your car, you discharge the spare capacitor. Better use a pretty high voltage for the interconnect though. Also even at 95% efficiency, things are going to get pretty warm. But probably not impossible.
The RIP Act forces suspects to reveal encryption keys on pain of imprisonment, whether charged with a crime or not.
So, just hand over the keys.
I'm going to get flamed for this, but perhaps this actually hits the right balance of power between the law enforcement agencies and the public. They can't easedrop on you without you knowing it, and they can't mass eavesdrop on everyone. But if they have good reason to suspect you, and you actually did do something wrong, then they can get evidence they need to put you away.
The point is that encryption in this case is still very useful - it protects against large scale abuse of eavesdropping without the public being aware what is going on. That's a huge improvement over the current situation, where few people use encryption for voice calls, and no-one knows who is listening.
Not much yet - there's a bit of a chicken-and-egg issue. You need stable implementations of a transport protocol before anyone will use it, but there's not much demand for the implementations before applications are asking for it.
So, these sort of changes deploy rather slowly. We'll get there though - the Linux DCCP code is just starting to get stable now.
Lets of information about DCCP is here if you're interested.
In Britain the commercials are often quite creative. I used to watch them. Often they were better than the programmes. But some time back, they started upping the volume on the commercials. That's just annoying, so now I mute them (too much trouble to adjust the volume). Stupid really - half decent commercials, but not watched anymore. Or alternatively, it provokes me into channel-skipping. When will they realise that subtle ads work best among the high-earning audience they want to reach?
As I've got busier over the years, I've become bi-modal in my communications media - mostly email for exchanging information, and then (but more rarely) the phone or (better) face-to-face for interactive discussion when I really need an answer now, or when I know the discussion is too difficult for email.
Even with email, I've now turned off all mail alerting after twenty years of using various descendants of biff. Just too many alerts to pay attention to. Better to have none, and process email in batches so I can concentrate and get some work done in bursts that are longer than the 20 seconds between messages arriving. My productivity increased significantly when I turned off mail alerts. Took a while for me to get over the feeling of "disconnectedness" though.
Most really productive people I know are the same. Interrupt livelock can really hurt your ability to actually get anything done. But then I'm posting on slashdot, so what do I know...
A worst case scenario would be a filesystem similar to Reiser4 with consolidation turned off, and lots of files growing by small amounts frequently.
This is pretty easy to deal with in the SSD itself. You just need to front the drive with a large DRAM disk buffer to decouple reads and writes, and then make sure the drive firmware reads each block before writing it. There's no need to write any bytes that haven't changed. Given that reads are a lot quicker than writes this may even improve performance too.
I don't think that the supermarket has your PIN, more like the one way encrypted PIn information is passed from the point of sale terminal to the PIN pad. The PIN pad checks that the PIN entered is valid then the till will request authorisation from the acquirer.
The card stripe is read as the card is inserted, then at the bottom of the swipe slot the card lodges in the chip reader. You then enter your PIN into the remote keypad. The keypad encrypts the PIN using triple-DES (keyed using a shared key) to transfer the PIN to the terminal. So, it's hard to eavesdrop the PIN in transit, but the PIN does end up in the same system as the swiped card data. Which means that (in principle at least) it's exactly as secure or insecure as the systems in the US that have been compromised.
Basically chip and pin is not there to protect the customers - it's there to protect the stores. But as no signature is involved, it's now harder for you to claim it wasn't you. And before, you couldn't give away your ATM PIN in UK stores, now you can.
Sure, but the point is that the store then has the entire contents of the mag stripe, and they have to transfer the PIN from the keypad to the card via the terminal that has the mag stripe data. So the contents of the magstrip and the PIN are in the same device. That's all you need to clone the ATM card. You don't need to clone the chip to produce a workable ATM card - just the stripe and the PIN.
Now, I've no clue if they store that information, but the point is they don't need the contents of the stripe in the first place.
Unfortunately, increasingly we're seeing supermarkets
insist on swiping your chip'n'pin card, rather than relying on you
entering the card into the terminal yourself. Tesco and Sainsburys do this, perhaps others do. From the customer's
point of view, this completely defeats the security provided by
chip'n'pin. The supermarket now has all the information from the mag
stripe, and also has your PIN. Anyone obtaining this information can
reproduce your ATM card, and drain your account.
In contrast, if you insert the card yourself, the system seems
somewhat harder to defeat, although I don't actually know what
information the store then has access to. Presumably less information,
or they wouldn't want to swipe the card in the first place.
So what's to do? I think the only sensible thing is to refuse point
blank to ever hand over a chip'n'pin debit card. If they don't like
this, don't pay, and tell them why. And tell others. The stores
don't need to swipe your card, but they'll only learn this if enough
people object.
The problem is that there's a grey area in the law as what constitutes a computer program and what constitutes a piece of hardware that includes some software. The latter is patentable, the former isn't.
In this case the patent claims to be on the proxy server itself (ie the box), but if you read it closely there's nothing special about the box - the patent is really about the software. But this is a grey area, and there isn't enough legal precidence to rule this sort of patent out quickly on these grounds. In the end we shot it down on prior art (see my other post for details), and obviousness over the prior art.
The problem with finding prior art is that you need to find one piece of prior art that covers all the aspects of a claim. You can't mosaic them. The prior art we used in trial was the following:
A. Fox, E. Brewer, "GloMop: Global Mobile Computing By Proxy", Position paper, (Sep 1995), Used to be available from: http://www.cs.berkeley.edu/~fox/glomop.
Stefan Gessler and Andreas Kotulla. PDAs as mobile WWW browsers. Computer Networks and ISDN Systems, Vol. 28, No. 1-2, 1995, pp. 53-59.
Joshi, Anupam, Weerasinghe, R., Mcdemott, S., Tan, B., Bernhardt, G. and Weerawarana, S., "Mowser: Mobile Platforms and Web Browsers'', Bulletin of the TCOS, IEEE Computer Society.
The general concept was clearly obvious back then. But the patent had some specific details that Inpro claimed were not obvious. I believe they were obvious to someone in the field in 1996. Clearly the judge agreed.
Slashdot Mirror
But then again, maybe they're smarter than this. Maybe they really can't break it. But they want you to think they can break it, so they tell you they can't, because they know terrorists (and slashdotters) always expect the government to try and mislead them. Great way to undermine confidence in Skype in circles of suspicious users, without causing problems for the regular users. You obviously fell for it :-)
Heating is perhaps more of an issue, because waste heat on a gas-powered car is similar to the usable power output, so you've got a lot of heat spare. But assuming you use a heat-pump to do the heating, and pump waste heat from the electric motors and battery packs, then likely it won't be much different from the A/C problem. We're talking about vehicles in the 40KW continuous power output range (peak of 100KW). Assume you get 90% efficiency (which would be pretty good), then you've still got 4KW of waste heat in the motors and batteries. If you can capture say half of that using a heat-pump, you can still be toasty-warm.
Summary: not completely negligible, but probably only a few percent difference to the range.
Of course the phone company already knows where you are, and can provide this sort of service, but then you have to use the phone company's UI. Apple can provide you with a nice elegant unified user interface, and that's what most users want.
Now, once they've got this information, they can misuse it for all sorts of purposes. It needs consumer pressure (or in Europe, there's data protection legislation) to keep such companies honest. But expecting them not to need to have this information is rather strange - they do have a need if they want to present the best localized UI possible.
And no, I don't have an iPhone. I do have a Blackberry, and I know Research in Motion know where I am all the time, because most of my traffic traverses one of their proxies. Most other smart phones do something similar. Apple really doesn't seem half as bad in comparison.
Then my understanding is that the data protection law would not place the blame on the person carrying the laptop, but on the person in the organization who dictated that sensitive data is stored insecurely. In your hypothetical case, likely the pointy-haired boss would be the one facing criminal charges.
You're obliged to hand over the key? No problem, phone your friend, give him the passphrase, and get him to print out the contents, and mail the printout to them.
If it's really the case that nowhere on your property gets any sunlight this time of year, then I really would suggest moving!
The MUST/SHOULD/MAY terminology in RFCs is to indicate levels of compliance with a specification. If this were a specification, or even a BCP (Best Current Practice) RFC document, then this might make sense. But it is intended to be an Informational RFC, which has no weight as a standard whatsover. So MUST/SHOULD/MAY terminology is completely inappropriate (in case you're wondering, yes I have written quite a few RFCs).
This document is an individual submission at the moment. Anyone can submit such a document; this does not indicate any level of support by the wider IETF, let alone anyone else. If the IETF were to take this on, and make it a BCP, then the terminology would indicate levels of support, and you could legitimately claim that an organization that did not comply was not providing standards-compliant service. It's possible this could embarrass an organization, but somehow I doubt it. However, if there were such a document, it might be possible for national governments to legislate compliance. Only then would it have any significant impact, but I think legislation here is unlikely and probably inappropriate.
Likely what will happen is that the regional registries will run out of address space to allocate in approximately three years from now (this is the current best estimate from Geoff Huston, who probably knows more about this than anyone else). ISPs will find it hard to get addresses after that, and a market will naturally emerge. Basically address space will become expensive. Also, there will be incentive to disaggregate currently aggregated address space, so more organizations can multihome. This will cause increasing routing table explosion in routers, and cause ISPs to need to either filter route advertisements (breaking multihoming) or upgrade routers (requiring them to spend money). And increasingly larger organizations will start to use NATs, making all sorts of applications harder to set up than they need to be. When your home NAT is behind your ISP's NAT, I suspect lots of things will break really badly. Maybe eventually the pain will get great enough that the switchover starts to reach critical mass, and only then will organizations actually allocate budget to make it happen.
There is a lot to be said in favour of moving forward in a less chaotic way that this, but I'm skeptical about the likelihood of that actually happening.
It seems like this avoids the build-up of an insulating layer of zinc oxide. So, what happens when you put a current through something with higher resistance? It gets warm. Presumably then, if you have a relatively high-drain device, you're wasting a fair amount of the chemical energy from the battery in heating up the battery. Avoid this, and the battery should last longer.
Plan 9, surely?
Maybe we'll finally see functional languages come to the forefront. They make it a whole lot easier for the compiler to extract parallelism automatically. For example,see Parallel Haskell. I think this is the closest I've seen to a "magical threading language".
Are you sure?
And if you're really paranoid, the .login script from the fake account can run a setuid program that deletes your regular home directory (you do have backups don't you?), overwrites the files with random data multiple times, and then deletes itself. Likely they'll take long enough probing the fake directory that the real data will be gone without a trace by the time they even start to think they should be looking elsewhere.
You charge the spare 100KWh supercapacitor you have at home over 24 hours. That takes about 4KW. Then when you want to charge your car, you discharge the spare capacitor. Better use a pretty high voltage for the interconnect though. Also even at 95% efficiency, things are going to get pretty warm. But probably not impossible.
So, just hand over the keys.
I'm going to get flamed for this, but perhaps this actually hits the right balance of power between the law enforcement agencies and the public. They can't easedrop on you without you knowing it, and they can't mass eavesdrop on everyone. But if they have good reason to suspect you, and you actually did do something wrong, then they can get evidence they need to put you away.
The point is that encryption in this case is still very useful - it protects against large scale abuse of eavesdropping without the public being aware what is going on. That's a huge improvement over the current situation, where few people use encryption for voice calls, and no-one knows who is listening.
- Fzz
- Fzz
Not much yet - there's a bit of a chicken-and-egg issue. You need stable implementations of a transport protocol before anyone will use it, but there's not much demand for the implementations before applications are asking for it. So, these sort of changes deploy rather slowly. We'll get there though - the Linux DCCP code is just starting to get stable now.
Lets of information about DCCP is here if you're interested.
- Mark (one of the author of DCCP)
In Britain the commercials are often quite creative. I used to watch them. Often they were better than the programmes. But some time back, they started upping the volume on the commercials. That's just annoying, so now I mute them (too much trouble to adjust the volume). Stupid really - half decent commercials, but not watched anymore. Or alternatively, it provokes me into channel-skipping. When will they realise that subtle ads work best among the high-earning audience they want to reach?
As I've got busier over the years, I've become bi-modal in my communications media - mostly email for exchanging information, and then (but more rarely) the phone or (better) face-to-face for interactive discussion when I really need an answer now, or when I know the discussion is too difficult for email.
Even with email, I've now turned off all mail alerting after twenty years of using various descendants of biff. Just too many alerts to pay attention to. Better to have none, and process email in batches so I can concentrate and get some work done in bursts that are longer than the 20 seconds between messages arriving. My productivity increased significantly when I turned off mail alerts. Took a while for me to get over the feeling of "disconnectedness" though.
Most really productive people I know are the same. Interrupt livelock can really hurt your ability to actually get anything done. But then I'm posting on slashdot, so what do I know...
This is pretty easy to deal with in the SSD itself. You just need to front the drive with a large DRAM disk buffer to decouple reads and writes, and then make sure the drive firmware reads each block before writing it. There's no need to write any bytes that haven't changed. Given that reads are a lot quicker than writes this may even improve performance too.
The card stripe is read as the card is inserted, then at the bottom of the swipe slot the card lodges in the chip reader. You then enter your PIN into the remote keypad. The keypad encrypts the PIN using triple-DES (keyed using a shared key) to transfer the PIN to the terminal. So, it's hard to eavesdrop the PIN in transit, but the PIN does end up in the same system as the swiped card data. Which means that (in principle at least) it's exactly as secure or insecure as the systems in the US that have been compromised.
Basically chip and pin is not there to protect the customers - it's there to protect the stores. But as no signature is involved, it's now harder for you to claim it wasn't you. And before, you couldn't give away your ATM PIN in UK stores, now you can.
Sure, but the point is that the store then has the entire contents of the mag stripe, and they have to transfer the PIN from the keypad to the card via the terminal that has the mag stripe data. So the contents of the magstrip and the PIN are in the same device. That's all you need to clone the ATM card. You don't need to clone the chip to produce a workable ATM card - just the stripe and the PIN. Now, I've no clue if they store that information, but the point is they don't need the contents of the stripe in the first place.
In contrast, if you insert the card yourself, the system seems somewhat harder to defeat, although I don't actually know what information the store then has access to. Presumably less information, or they wouldn't want to swipe the card in the first place.
So what's to do? I think the only sensible thing is to refuse point blank to ever hand over a chip'n'pin debit card. If they don't like this, don't pay, and tell them why. And tell others. The stores don't need to swipe your card, but they'll only learn this if enough people object.
For the record, here's the patent in question.
The problem is that there's a grey area in the law as what constitutes a computer program and what constitutes a piece of hardware that includes some software. The latter is patentable, the former isn't.
In this case the patent claims to be on the proxy server itself (ie the box), but if you read it closely there's nothing special about the box - the patent is really about the software. But this is a grey area, and there isn't enough legal precidence to rule this sort of patent out quickly on these grounds. In the end we shot it down on prior art (see my other post for details), and obviousness over the prior art.
- Fzz
The problem with finding prior art is that you need to find one piece of prior art that covers all the aspects of a claim. You can't mosaic them. The prior art we used in trial was the following:
The general concept was clearly obvious back then. But the patent had some specific details that Inpro claimed were not obvious. I believe they were obvious to someone in the field in 1996. Clearly the judge agreed.
Don't forget to do it next month on the 3rd too. And the next. And the next....