Actually, there are name constraints that would allow you to sign for yourself if you could anchor your own CA to the trust chain. Weâ(TM)re closer than many think.
In order for that to work though, the name constraint would need to be marked critical (refuse trust chain if not supported), and itâ(TM)s mostly just Apple that doesnâ(TM)t support it.
If Apple fixes that, and Letâ(TM)s Encrypt (for example) would let you anchor from them, things could move in that direction.
Personally Iâ(TM)d have liked to see these things integrated into DNSSEC as well.
If you have two plaintext blocks, and encrypt using ECB mode with the same IV though, then the two cipher blocks would turn out identical cipher blocks. Would make it trivial to see which was the encrypted one.
So basically the answer is; it depends.
If you need to ask the question, do more research before you continue your work. This is stuff you really should understand before you embark on such a project.
No idea about pros and cons and so on, but figured it could be interesting to take a peek at these for a less expensive solution, even though different.
There are 600 students, most of which will probably bring a laptop, and want to stay in touch, just as you do.
Seems like it could be an idea to bring a satellite uplink, provide services to the students at a small upmark in your costs, and use the earnings to pay for your own bandwidth use?
Alternatively set up a proxy;
Charge the others for their used bandwidth, on their side of the connection. If two people download the same URL, you're charging them twice, leaving earnings to cover your own use.
Be honest with them about that though, so nobody feels cheated.
Another thing to consider is to go to a satellite provider and simply ask if they want to provide you with equipment and/or some bandwidth for free, or at a reduced cost. It's a great way for them to market themselves to the 600 students, which throughout their careers might need a similar service, and guess which provider they'd think of first? Surely the one that helped them out when they were students.
The three options can be combined offcourse. If you can borrow equipment for free, get slightly lower bandwidth fees, and a flexible payment plan, so you don't get stuck with a huge bill, you could be set for the duration.:)
They're great for use, and abuse. I've rolled over it several times rollerblading, with the laptop still on, and so on. Never any problems. I've had mine for 3-4 years now, and while it is showing slight wear, it seems to be good for another 3-4 years without a problem.
You should peek around their site, and pay attention to the details, like the laptop room not being all the way against your back, so it's a very comfortable fit.
Most comments seems to just reiterate over the same points, so I'd like to offer two new ones:
1) Even if the employee isn't leaving due to bad blood, his view of the company could still deteriorate on the way out. Even if he's intending to be professional during the last two weeks, things change. It's hard to predict if the awkwardness will raise bad blood.
2) Most people are good (both employers, and employees).
3) Once root; always root. If it's a sysadmin that's leaving, things usually boild down to two things (assuming he's skilled at his job):
3a) He's intending to behave himself, in which case he doesn't pose a threat, and things are fine. 3b) He's not intendig to behave himself, in which case he's got enough access that kicking him out without reinstalling pretty much everything, is next to impossible.
Either way, kicking him out on the way will always have a drawback (stops information handover) and won't actually help any.
It's not all about getting the developers to use the same code formatting and indenting. Often it's in the simple things you can think up to solve spesific problems.
Good things to consider could be small, easy and quick things, like creating a small text document detailing the structure of the source directories.
And if you're not already doing it, by all means use a source revision control system. Not only do you get the revision controls, the advantage of more easily being able to have multiple developers working on the same source set, but you get the advantage of making it easier to keep an eye on what's going on with a project.
Both of these things will lead to quicker returns, for a lot less work, than changing the developers coding habits.
If root is such a big deal to him, he should have root on a development system.
Developing on a separate system would give him the freedom he feels he needs, and he'd be able to map out a set of requirements for the production system.
Developing on a production system is just bad practice anyway. By running two systems, screwups on the development system shouldn't cause downtime, and in the event of a total disaster with the production box, having a development machine around almost always leads to quicker recovery of services.
I've spent some time looking at this idea. What it mostly boils down to is risk. There are a lot of factors involved that are hard to predict:
* Your type of customers
* How frequently and how long they use it (how many ads)
* Add prices
and so on.
On the bright side, it does offer some unique potential, such as localized ads. Server out ads for the stores around your location.
For most people who have looked at this I think it's usually boiled down to the revenue stream (if any) being too hard to predict to justify a major rollout, while there are some minor pilots on the way.
I have no idea why you replied to my post, as it's obvious that we agree.
One interesting point though. I don't see how you can easily proove a OTP based solution to be correct. Random numbers are not easy.
What I'm merely trying to do is point out that OTP-based solutions are not the holy grail to perfect privacy. It's tempting to draw a parallel between regular symmetric cryptogaphy and OTP. You're still basing your security on components which you don't know how hard it will be to break. What if a new discovery is made which will help in statistically predicting the output of whatever you use for a random number source?
Another issue entirely is that you seem to claim that there's no need to worry about things like quantum cryptography because "we can just use OTP". While I'm not one of the "Quantum Cryptography will ruin our privacy"-crowd, I don't agree with your claim. OTP does quite simply not solve all the problems we use cryptography to solve today.
For one thing it'll only help you out when you have some way of distributing the PAD securely. You can't easily replace a public key cryptography system with a OTP based one.
You can do some of the same things with OTP-based solutions by having every user agree on a PAD with a certificate authority, thus having a channel they can use to negotiate keys with 3rd parties which also have an agreement with that CA, but there's a lot of isses involved there, and the easiest solutions would normally result in the CA having copies of the keys.
OTP is unbreakable, and so "the golden age of privacy" will not end because of quantum computers.
OTP is not unbreakable.
While the algorithm itself isn't breakable, the strenght of a OTP based solution will still depend on several weak points, like the random number source.
There's plenty of room for trying to attack it, using statistical analysis and estimates to try to be able to break it.
As always, there are several posts which seems to think the author of the post is unable to use google, and seems to imply that the author doesn't have the skills or intelligence to use google because he's posting here.
To be honest I find it sad that these people are posting seemingly without taking the time to understand the question, much less find out if google really offers the answers.
For this spesific question, I read it as the author needing access to a gateway allowing him to send/recieve SMS messages, not that he's looking for the software.
And quite simply, Google does not offer a simple solution for a production grade free gateway which will solve the problems he needs to solve.
At least to me that makes the question not only relevant for posting here, but it's also a interesting question which I'm sure sparks the interest of other/. readers.
I've been working with SMS solutions for some time now, and might be able to offer some help.
I'm not entirely sure what you want to do here, but I don't think you're likely to find anyone offering free lunches.
If you're looking for something that's *only* sms->internet, not the other way around, you *might* be able to find a gateway offering free service. You will however probably end up paying for the MT (Mobile Terminated) SMS messages.
If you want two way communications your best bet is probably to look at getting sponsored by a SMS Service Provider, or a local teleco. Keep in mind that you can look at most of the providers worldwide for your services, you don't have to limit yourself to the providers of your own country.
There's also the question of how you want things set up. There seems to be two types of serice providers offering 2-way SMS. Some are providing a simple interface in which you use various dataformats (XML is popular) over HTTP to deliver a outgoing SMS message, and their server will connect to yours to deliver an incomming one. The other option is to use a native SMS delivery protocol, such as SMPP. That'll either require custom development, or you can use kannel.
I know of one SMS gateway of the first type who allows you to register keywords on their SMS number, on which you can recieve messages for free. Outgoing still costs though.
Let me know if I can offer any advice on the issue, I'm available at terje(at)elde.org.
If you encrypt the content of the email, the two issues which are left both relate to traffic analysis:
1) You're still leaking information on who you're mailing and 2) You're still leaking information that you're active and using email
Add statistical analysis with those two sources and you're actually leaking quite a bit of information.
I do however think the problem can be solved without a strict need for a freenet like solution. If you use an anoymous remailer you're hiding who you're communicating with, thus solving problem number one.
If you set up your system to send a email at regular intervals, such as once every 10 minutes, then you solve problem number two. I won't be possible to track the difference between a legitimate and a fake email, if you simply replace one of the fake with a real email.
Let me note that my full view on this is more complex than this, just pointing out a few obvious things.
By reviewing how you work with the actual code, you can avoid making a lot of the bugs in the first place. When making solutions where more than one module/frontend depend on various backend functions I find that I usually avoid most problems with the API changing if I simply carefully map out whats needed of the API and deciding on how I want to access it once and for all. Once that's decided upon you can change the code as much as you want as long as you leave the actual API alone.
One of the things made easier by OOP for example:)
I know I might be pointing out the obvious here, but experiece have shown me that thinking about how you design your actual development cycle is a topic which is too often overlooked, with painful results.
Not really an objection, just pointing it out because it's nice to have in the back of our minds when doing work on this...
When it comes to speed and HashCash I think we can divide the problems in two. Those of interactive use, and non-interactive use.
It's clear that it's when the user actually have to wait that speeds makes the biggest difference (with the possible exception of servers doing a lot of work). If you design the workload to take a comfortable amount of time on an average machine, and the minting is then run on a machine which runs at half average speed, with software that runs at 1/4 the performance of what's expected, the user will have to wait about 8 times what would be normally considered comfortable.
Any marketing suit will tell you that you risk the user growing impatient and possibly loose interest.... just a thought.
UML works by starting another kernel, the jail() system of FreeBSD is more like a improved chroot(). You don't start a new kernel, just just make a syscall to tell the kernel to limit what you can access.
From the way I understand things the main differentce is that FreeBSDs jail() is implemented mostly like chroot(). A set of checks within the kernel, while UML is a linux kernel running inside linux.
It could be argued that if both ways are done right, the latter might offer a cleaner separation.
Another difference is that of how you work with the two. With UML I presume you start a new kernel and boot it, while FreeBSDs jail() allows for a much more lightweight model. On my systems I usually rewrite the applications which communicate over networks to jail themselves, to minimize the impact of an exploit against the application. You can't really do the same with UML.
It would however be very interesting to see a detailed comparison, including focus on performance.
With a decent C version, creating a PERL wrapper should not be hard work.
I would not recommend writing HashCash software in pure Perl, as you want the clients to be as optimized as possible. Keep in mind that the time used to process a workload goes up as your codes efficiency goes down. Writing in pure Perl will thus make slow clients.:(
I think the bigger issue with HashCash is how you introcue it's use, rather than if it should be done.
I don't think it's feasible to simply have all email servers, relays and clients adopt the use of HashCash over a short timeframe, but that's not the only place to start.
When introcuing a new technology such as this, one of the main points is availability of software. If the use of HashCash is taken up by other protocols, software developement will pick up, and introductions into legacy protocols will be easier.
Also, you don't need direct support in every protocol in order for HashCash to be useful. One example is email. If you're sick and tired of spam and wish to reject all email not on a whitelist, you could bounce the rejected email with a link to a URL, from which the sender could simply do the required workload to get the email accepted and sent using a Java applet. The server could store a copy of the email, which would then be released into the customers email.
If you want HashCash to work, I think it's much more important to look at where and how you want to use it, rather than to focus on using it to solve every problem out there which it might or might not be able to do.
HashCash can be used to solve a lot of problems with publicly available resources and services, but in order to get the full gain from such techniques there needs to be software and libraries available which allows easy integration of HashCash techniques.
Does anyone have any good resources on HashCash source code or other things to aid development?
There are commercial alternatives available which you can use. Some are based on using fibre-optic cables which will be broken if the pressurized oild surrounding gets broken. If you shut down the link until it's manually re-activated if the link evers gets marked as down, then you should have your solution.
Also, I would not entirely rule out cryptography. If you start by sending as much garbage as you can, then sending encrypted data with no headers only when there's data to be send, instead of the noice, then you should be able to avoid the problems of traffic analysis.
Personally I'd go with the following method:
Make two queues, one virtual and one "real". If there's real data to be sent, encrypt it and store it in a buffer. If there's no real data to be sent, grab something from the virtual queue, which gives you either all NULLs, or random data, and encrypt that, then place it in the buffer. Then run another deamon or task which grabs data from the buffer at a constant rate and sends it. That way you'll have a constant stream of encrypted data. All the attacker will see is the encrypted data, and he should not be able to pick out any information usable for traffic analysis.
This explanation is a nutshell one, you'd need to take care of re-keying etc. You also need a way for the recipient to know if the package is real data or random data. That can be done by prepending a checksum to each package, inside the encryption. If you're using a keyed sha1 checksum then you get authentication as well.
Keeping in mind that nothing (neither physical nor electronic protection) is 100% secure, I'd combine both cable protection and encryption.
I'm currently doing work on this encrypted approch, and can be contacted if you're interested.
FreeBSD has a feature called dummynet. It allows you to configure network pipes which allows you to limit bandwith, add latency and even packet loss. It's quite a nicely designed feature. You use the ipfw tool to configure it, and you use firewall rules to send traffic into the pipes, so you can controll which content you want to limit.
You can use it on the host you want to use, or you can easily build a FreeBSD gateway/router box and set things up there. More in formation is available at www.freebsd.org.
Before deciding we should throw esound away lets take a look at what it's done for us, what it's good and bad sides are.
One of the things newbies don't like about UNIX is the thing the get under windows. Typical examples of this include inconsistent user interfaces, lack of completed good GUI software, and problems using audio from more than one source at a time. OSS has done some to fix this, with it's virtual mixers, but it has shown itself to be less than stable for a lot of users, and it's also not a free package.
Esound has done a lot to improve on this, but allowing users to easily configure their UNIX systems to play audio from more than one source at a time. It migth not convert every windows user, but it's one of those things that make everyday life a little better.
If you're thinking "so what? that's not the issue here" then you're entirely right. The issue isn't if esound is a bad product, it's more a question of can we do better?
Esound has had it's problem over the years, including some rather scary security issues. The audio bits themselves seems fine, and esound has helped a lot in providing the UNIX world with a generalized interface for audio playback and recording.
For this reason I think a possible good solution would be to keep the interface to esound, while revising the entire package. The audio bit seems fine, but the rest of the package could use a workover. A good place to start would be to throw away all the interface code, go back to the design level, look at how to design the internal parts of the system. Good separation from the rest of the system is vital to make it a secure package. One place to start would be make the daemon run under a highly limited user id, with access to the audio device.
The rewrite of the interface code should be done with the clear knowledge that users are potential evil people who might send bogus data in attempts at exploiting flaws in the system.
The API which programs will call could with clear benefit be kept backwards compatible if the developers don't see any problems or limitations with that. As a alternative there's always the wrapper approach.
Please don't take this the wrong way, but I think there is a bit of a misunderstanding here. The problem the site is faced with is authenticating that you, the unknown entity in front of a computer, is the owner of the credit card. They already trust the credit card itself, or could run a check if they felt like it. Checking the relationship between the card and other web sites would really get you nowhere, as it would only serve to validate the customer quality of the owner of the credit card, and would not help a bit in validating that you (the entity in front of the computer) is the owner of the card.
One way to fix such a problem is to roll out a public key infrastructure, which would cryptographically link you to your credit card, and/or to your customer profile with another site.
Getting the banks to roll out such a system will take time, and it will be hard. Getting shopping sites to cooperate might be easier. This is something that will be mutually benefitial to all online shopping sites, so I can see no reason why even competing sites would not want to share information.
If a bigger site feel it doesn't gain anything by sharing with smaller sites, one could always set up a system where the smaller sites buy the information from the bigger sites.
There are obviously a whole bunch of privacy issues with such a setup, but this can be solved in a number of ways. The solution I think I'd prefer will only work if profiles are freely available, and the bigger sites doesn't want to make money from the profiles. The idea is that sites such as amazon.com can give me a certificate stating that I've been a good customer, they've never had credit problems with me, and I've never made much problems. This certificate would then be encrypted to my public key, and emailed to me. I could then forward it to new sites should they need to validate me as a good customer, and link me to any credit cards.
Such a system will have good side effects as well. Big sites will get new customers because the customers will then get certificates they know are trusted all over the web, and smaller sites will benefit because they can validate new customers much more effectively.
Also, there is reason not to implement this the other way around as well, by allowing customers to write certificates about the online shops. It will take time before this will work, because you need to build a web of trust, with which you'll in time be able to map a trust path to someone who has shopped at the web page you want to buy stuff from, and validated that he got the stuff he ordered.
With this model, you will be able to go to a really small, highly specialised shop on the web, and read good and bad reviews of the site, that people are putting their reputations on the line for provind the validity of the review.
Another possibel way of implementing such a trust system is for the big provider (amazon in our example) to hang on to the profile, and when a smaller shop (the fictional store "Gothic Music Inc") need to validate that you're a good customer, and possibly also that you really do controll a VISA card, it will send a request to amazon, after looking up your info in a public database of who had information about you, or searching the databases of sites directly. At this time Gothic Music Inc only know where one can gain information about you. Amazon now sends a request for information release to you, and you either ignore it, because you're not the one that contacted Goth Inc, or you sign it, return it to amazon, and they sell the profile, because your approved the sale.
I don't like the latter method, because it provides less protection to the end user from abuse from bad providers, but it's more likely to be implemented. In face, how do we know that doesn't happen today without the user authorisation step? It probably does.
Anyways, enough mumbling for now, and back to sleep.
Slashdot Mirror
Actually, there are name constraints that would allow you to sign for yourself if you could anchor your own CA to the trust chain. Weâ(TM)re closer than many think.
In order for that to work though, the name constraint would need to be marked critical (refuse trust chain if not supported), and itâ(TM)s mostly just Apple that doesnâ(TM)t support it.
If Apple fixes that, and Letâ(TM)s Encrypt (for example) would let you anchor from them, things could move in that direction.
Personally Iâ(TM)d have liked to see these things integrated into DNSSEC as well.
If everything is perfect? No.
If you have two plaintext blocks, and encrypt using ECB mode with the same IV though, then the two cipher blocks would turn out identical cipher blocks. Would make it trivial to see which was the encrypted one.
So basically the answer is; it depends.
If you need to ask the question, do more research before you continue your work. This is stuff you really should understand before you embark on such a project.
Hi,
No idea about pros and cons and so on, but figured it could be interesting to take a peek at these for a less expensive solution, even though different.
http://www.etymotic.com/ephp/compmic.aspx
There are 600 students, most of which will probably bring a laptop, and want to stay in touch, just as you do.
Seems like it could be an idea to bring a satellite uplink, provide services to the students at a small upmark in your costs, and use the earnings to pay for your own bandwidth use?
Alternatively set up a proxy;
Charge the others for their used bandwidth, on their side of the connection. If two people download the same URL, you're charging them twice, leaving earnings to cover your own use.
Be honest with them about that though, so nobody feels cheated.
Another thing to consider is to go to a satellite provider and simply ask if they want to provide you with equipment and/or some bandwidth for free, or at a reduced cost. It's a great way for them to market themselves to the 600 students, which throughout their careers might need a similar service, and guess which provider they'd think of first? Surely the one that helped them out when they were students.
The three options can be combined offcourse. If you can borrow equipment for free, get slightly lower bandwidth fees, and a flexible payment plan, so you don't get stuck with a huge bill, you could be set for the duration. :)
I'm *very* pleased with the Spire products:
http://www.spireusa.com/
They're great for use, and abuse. I've rolled over it several times rollerblading, with the laptop still on, and so on. Never any problems. I've had mine for 3-4 years now, and while it is showing slight wear, it seems to be good for another 3-4 years without a problem.
You should peek around their site, and pay attention to the details, like the laptop room not being all the way against your back, so it's a very comfortable fit.
Most comments seems to just reiterate over the same points, so I'd like to offer two new ones:
1) Even if the employee isn't leaving due to bad blood, his view of the company could still deteriorate on the way out. Even if he's intending to be professional during the last two weeks, things change. It's hard to predict if the awkwardness will raise bad blood.
2) Most people are good (both employers, and employees).
3) Once root; always root. If it's a sysadmin that's leaving, things usually boild down to two things (assuming he's skilled at his job):
3a) He's intending to behave himself, in which case he doesn't pose a threat, and things are fine.
3b) He's not intendig to behave himself, in which case he's got enough access that kicking him out without reinstalling pretty much everything, is next to impossible.
Either way, kicking him out on the way will always have a drawback (stops information handover) and won't actually help any.
Just some thoughts.
It's not all about getting the developers to use the same code formatting and indenting. Often it's in the simple things you can think up to solve spesific problems.
Good things to consider could be small, easy and quick things, like creating a small text document detailing the structure of the source directories.
And if you're not already doing it, by all means use a source revision control system. Not only do you get the revision controls, the advantage of more easily being able to have multiple developers working on the same source set, but you get the advantage of making it easier to keep an eye on what's going on with a project.
Both of these things will lead to quicker returns, for a lot less work, than changing the developers coding habits.
If root is such a big deal to him, he should have root on a development system.
Developing on a separate system would give him the freedom he feels he needs, and he'd be able to map out a set of requirements for the production system.
Developing on a production system is just bad practice anyway. By running two systems, screwups on the development system shouldn't cause downtime, and in the event of a total disaster with the production box, having a development machine around almost always leads to quicker recovery of services.
I've spent some time looking at this idea. What it mostly boils down to is risk. There are a lot of factors involved that are hard to predict:
* Your type of customers
* How frequently and how long they use it (how many ads)
* Add prices
and so on.
On the bright side, it does offer some unique potential, such as localized ads. Server out ads for the stores around your location.
For most people who have looked at this I think it's usually boiled down to the revenue stream (if any) being too hard to predict to justify a major rollout, while there are some minor pilots on the way.
I have no idea why you replied to my post, as it's obvious that we agree.
One interesting point though. I don't see how you can easily proove a OTP based solution to be correct. Random numbers are not easy.
What I'm merely trying to do is point out that OTP-based solutions are not the holy grail to perfect privacy. It's tempting to draw a parallel between regular symmetric cryptogaphy and OTP. You're still basing your security on components which you don't know how hard it will be to break. What if a new discovery is made which will help in statistically predicting the output of whatever you use for a random number source?
Another issue entirely is that you seem to claim that there's no need to worry about things like quantum cryptography because "we can just use OTP". While I'm not one of the "Quantum Cryptography will ruin our privacy"-crowd, I don't agree with your claim. OTP does quite simply not solve all the problems we use cryptography to solve today.
For one thing it'll only help you out when you have some way of distributing the PAD securely. You can't easily replace a public key cryptography system with a OTP based one.
You can do some of the same things with OTP-based solutions by having every user agree on a PAD with a certificate authority, thus having a channel they can use to negotiate keys with 3rd parties which also have an agreement with that CA, but there's a lot of isses involved there, and the easiest solutions would normally result in the CA having copies of the keys.
Just some thoughts.
OTP is unbreakable, and so "the golden age of privacy" will not end because of quantum computers.
OTP is not unbreakable.
While the algorithm itself isn't breakable, the strenght of a OTP based solution will still depend on several weak points, like the random number source.
There's plenty of room for trying to attack it, using statistical analysis and estimates to try to be able to break it.
As always, there are several posts which seems to think the author of the post is unable to use google, and seems to imply that the author doesn't have the skills or intelligence to use google because he's posting here.
/. readers.
To be honest I find it sad that these people are posting seemingly without taking the time to understand the question, much less find out if google really offers the answers.
For this spesific question, I read it as the author needing access to a gateway allowing him to send/recieve SMS messages, not that he's looking for the software.
And quite simply, Google does not offer a simple solution for a production grade free gateway which will solve the problems he needs to solve.
At least to me that makes the question not only relevant for posting here, but it's also a interesting question which I'm sure sparks the interest of other
Just my $0.02
Hi,
I've been working with SMS solutions for some time now, and might be able to offer some help.
I'm not entirely sure what you want to do here, but I don't think you're likely to find anyone offering free lunches.
If you're looking for something that's *only* sms->internet, not the other way around, you *might* be able to find a gateway offering free service. You will however probably end up paying for the MT (Mobile Terminated) SMS messages.
If you want two way communications your best bet is probably to look at getting sponsored by a SMS Service Provider, or a local teleco. Keep in mind that you can look at most of the providers worldwide for your services, you don't have to limit yourself to the providers of your own country.
There's also the question of how you want things set up. There seems to be two types of serice providers offering 2-way SMS. Some are providing a simple interface in which you use various dataformats (XML is popular) over HTTP to deliver a outgoing SMS message, and their server will connect to yours to deliver an incomming one. The other option is to use a native SMS delivery protocol, such as SMPP. That'll either require custom development, or you can use kannel.
I know of one SMS gateway of the first type who allows you to register keywords on their SMS number, on which you can recieve messages for free. Outgoing still costs though.
Let me know if I can offer any advice on the issue, I'm available at terje(at)elde.org.
If you encrypt the content of the email, the two issues which are left both relate to traffic analysis:
1) You're still leaking information on who you're mailing and
2) You're still leaking information that you're active and using email
Add statistical analysis with those two sources and you're actually leaking quite a bit of information.
I do however think the problem can be solved without a strict need for a freenet like solution. If you use an anoymous remailer you're hiding who you're communicating with, thus solving problem number one.
If you set up your system to send a email at regular intervals, such as once every 10 minutes, then you solve problem number two. I won't be possible to track the difference between a legitimate and a fake email, if you simply replace one of the fake with a real email.
Let me note that my full view on this is more complex than this, just pointing out a few obvious things.
Just thought I'd note the obvious...
:)
By reviewing how you work with the actual code, you can avoid making a lot of the bugs in the first place. When making solutions where more than one module/frontend depend on various backend functions I find that I usually avoid most problems with the API changing if I simply carefully map out whats needed of the API and deciding on how I want to access it once and for all. Once that's decided upon you can change the code as much as you want as long as you leave the actual API alone.
One of the things made easier by OOP for example
I know I might be pointing out the obvious here, but experiece have shown me that thinking about how you design your actual development cycle is a topic which is too often overlooked, with painful results.
Not really an objection, just pointing it out because it's nice to have in the back of our minds when doing work on this...
... just a thought.
When it comes to speed and HashCash I think we can divide the problems in two. Those of interactive use, and non-interactive use.
It's clear that it's when the user actually have to wait that speeds makes the biggest difference (with the possible exception of servers doing a lot of work). If you design the workload to take a comfortable amount of time on an average machine, and the minting is then run on a machine which runs at half average speed, with software that runs at 1/4 the performance of what's expected, the user will have to wait about 8 times what would be normally considered comfortable.
Any marketing suit will tell you that you risk the user growing impatient and possibly loose interest.
Quite simply, no.
UML works by starting another kernel, the jail() system of FreeBSD is more like a improved chroot(). You don't start a new kernel, just just make a syscall to tell the kernel to limit what you can access.
From the way I understand things the main differentce is that FreeBSDs jail() is implemented mostly like chroot(). A set of checks within the kernel, while UML is a linux kernel running inside linux.
It could be argued that if both ways are done right, the latter might offer a cleaner separation.
Another difference is that of how you work with the two. With UML I presume you start a new kernel and boot it, while FreeBSDs jail() allows for a much more lightweight model. On my systems I usually rewrite the applications which communicate over networks to jail themselves, to minimize the impact of an exploit against the application. You can't really do the same with UML.
It would however be very interesting to see a detailed comparison, including focus on performance.
With a decent C version, creating a PERL wrapper should not be hard work.
:(
I would not recommend writing HashCash software in pure Perl, as you want the clients to be as optimized as possible. Keep in mind that the time used to process a workload goes up as your codes efficiency goes down. Writing in pure Perl will thus make slow clients.
I think the bigger issue with HashCash is how you introcue it's use, rather than if it should be done.
I don't think it's feasible to simply have all email servers, relays and clients adopt the use of HashCash over a short timeframe, but that's not the only place to start.
When introcuing a new technology such as this, one of the main points is availability of software. If the use of HashCash is taken up by other protocols, software developement will pick up, and introductions into legacy protocols will be easier.
Also, you don't need direct support in every protocol in order for HashCash to be useful. One example is email. If you're sick and tired of spam and wish to reject all email not on a whitelist, you could bounce the rejected email with a link to a URL, from which the sender could simply do the required workload to get the email accepted and sent using a Java applet. The server could store a copy of the email, which would then be released into the customers email.
If you want HashCash to work, I think it's much more important to look at where and how you want to use it, rather than to focus on using it to solve every problem out there which it might or might not be able to do.
Right tool for the right job, simple as that.
HashCash can be used to solve a lot of problems with publicly available resources and services, but in order to get the full gain from such techniques there needs to be software and libraries available which allows easy integration of HashCash techniques.
Does anyone have any good resources on HashCash source code or other things to aid development?
There are commercial alternatives available which you can use. Some are based on using fibre-optic cables which will be broken if the pressurized oild surrounding gets broken. If you shut down the link until it's manually re-activated if the link evers gets marked as down, then you should have your solution.
Also, I would not entirely rule out cryptography. If you start by sending as much garbage as you can, then sending encrypted data with no headers only when there's data to be send, instead of the noice, then you should be able to avoid the problems of traffic analysis.
Personally I'd go with the following method:
Make two queues, one virtual and one "real". If there's real data to be sent, encrypt it and store it in a buffer. If there's no real data to be sent, grab something from the virtual queue, which gives you either all NULLs, or random data, and encrypt that, then place it in the buffer. Then run another deamon or task which grabs data from the buffer at a constant rate and sends it. That way you'll have a constant stream of encrypted data. All the attacker will see is the encrypted data, and he should not be able to pick out any information usable for traffic analysis.
This explanation is a nutshell one, you'd need to take care of re-keying etc. You also need a way for the recipient to know if the package is real data or random data. That can be done by prepending a checksum to each package, inside the encryption. If you're using a keyed sha1 checksum then you get authentication as well.
Keeping in mind that nothing (neither physical nor electronic protection) is 100% secure, I'd combine both cable protection and encryption.
I'm currently doing work on this encrypted approch, and can be contacted if you're interested.
FreeBSD has a feature called dummynet. It allows you to configure network pipes which allows you to limit bandwith, add latency and even packet loss. It's quite a nicely designed feature. You use the ipfw tool to configure it, and you use firewall rules to send traffic into the pipes, so you can controll which content you want to limit.
You can use it on the host you want to use, or you can easily build a FreeBSD gateway/router box and set things up there. More in formation is available at www.freebsd.org.
Before deciding we should throw esound away lets take a look at what it's done for us, what it's good and bad sides are.
One of the things newbies don't like about UNIX is the thing the get under windows. Typical examples of this include inconsistent user interfaces, lack of completed good GUI software, and problems using audio from more than one source at a time. OSS has done some to fix this, with it's virtual mixers, but it has shown itself to be less than stable for a lot of users, and it's also not a free package.
Esound has done a lot to improve on this, but allowing users to easily configure their UNIX systems to play audio from more than one source at a time. It migth not convert every windows user, but it's one of those things that make everyday life a little better.
If you're thinking "so what? that's not the issue here" then you're entirely right. The issue isn't if esound is a bad product, it's more a question of can we do better?
Esound has had it's problem over the years, including some rather scary security issues. The audio bits themselves seems fine, and esound has helped a lot in providing the UNIX world with a generalized interface for audio playback and recording.
For this reason I think a possible good solution would be to keep the interface to esound, while revising the entire package. The audio bit seems fine, but the rest of the package could use a workover. A good place to start would be to throw away all the interface code, go back to the design level, look at how to design the internal parts of the system. Good separation from the rest of the system is vital to make it a secure package. One place to start would be make the daemon run under a highly limited user id, with access to the audio device.
The rewrite of the interface code should be done with the clear knowledge that users are potential evil people who might send bogus data in attempts at exploiting flaws in the system.
The API which programs will call could with clear benefit be kept backwards compatible if the developers don't see any problems or limitations with that. As a alternative there's always the wrapper approach.
Please don't take this the wrong way, but I think there is a bit of a misunderstanding here. The problem the site is faced with is authenticating that you, the unknown entity in front of a computer, is the owner of the credit card. They already trust the credit card itself, or could run a check if they felt like it.
Checking the relationship between the card and other web sites would really get you nowhere, as it would only serve to validate the customer quality of the owner of the credit card, and would not help a bit in validating that you (the entity in front of the computer) is the owner of the card.
One way to fix such a problem is to roll out a public key infrastructure, which would cryptographically link you to your credit card, and/or to your customer profile with another site.
Getting the banks to roll out such a system will take time, and it will be hard. Getting shopping sites to cooperate might be easier. This is something that will be mutually benefitial to all online shopping sites, so I can see no reason why even competing sites would not want to share information.
If a bigger site feel it doesn't gain anything by sharing with smaller sites, one could always set up a system where the smaller sites buy the information from the bigger sites.
There are obviously a whole bunch of privacy issues with such a setup, but this can be solved in a number of ways. The solution I think I'd prefer will only work if profiles are freely available, and the bigger sites doesn't want to make money from the profiles. The idea is that sites such as amazon.com can give me a certificate stating that I've been a good customer, they've never had credit problems with me, and I've never made much problems. This certificate would then be encrypted to my public key, and emailed to me. I could then forward it to new sites should they need to validate me as a good customer, and link me to any credit cards.
Such a system will have good side effects as well. Big sites will get new customers because the customers will then get certificates they know are trusted all over the web, and smaller sites will benefit because they can validate new customers much more effectively.
Also, there is reason not to implement this the other way around as well, by allowing customers to write certificates about the online shops. It will take time before this will work, because you need to build a web of trust, with which you'll in time be able to map a trust path to someone who has shopped at the web page you want to buy stuff from, and validated that he got the stuff he ordered.
With this model, you will be able to go to a really small, highly specialised shop on the web, and read good and bad reviews of the site, that people are putting their reputations on the line for provind the validity of the review.
Another possibel way of implementing such a trust system is for the big provider (amazon in our example) to hang on to the profile, and when a smaller shop (the fictional store "Gothic Music Inc") need to validate that you're a good customer, and possibly also that you really do controll a VISA card, it will send a request to amazon, after looking up your info in a public database of who had information about you, or searching the databases of sites directly. At this time Gothic Music Inc only know where one can gain information about you. Amazon now sends a request for information release to you, and you either ignore it, because you're not the one that contacted Goth Inc, or you sign it, return it to amazon, and they sell the profile, because your approved the sale.
I don't like the latter method, because it provides less protection to the end user from abuse from bad providers, but it's more likely to be implemented. In face, how do we know that doesn't happen today without the user authorisation step? It probably does.
Anyways, enough mumbling for now, and back to sleep.