Well, people tried to go around the licensing back in the day, too (and succeeded, as they still do). So I still fail to see how this relates to your earlier comments.
Of course people succeeded. The relation is that some is not all. It is a valid point that it stops some people. It is the distinction between possibility and accessibility. But I see that you provide an argument against that:
Obfuscation slows some people down, a little. For others, it merely creates an incentive to crack. Software which, otherwise, they'd have had no interest in, becomes their target, just for the challenge of it. And it ends up being circulated more widely than if there were no obfuscation in the first place.
That is a pretty good argument against a lot of cases, but there is a big difference between trusting encoded code given to them by us, and cracked code. Sure, for a photoshop desktop, one can just wipe their install and start fresh if the cracked version causes problems. But for software that runs your business, and handles your billing, no one in their right mind would use cracked software.
The point was _not_ that it _is_ any _more_ useful. The point was that it _is not_ any _less_ useful because of your argument. Personally, I would prefer the source to be available, but there are very valid reasons, like the fact that we know that many people actively try to go around the licensing, but are not competent enough to figure out how, like the people who try to work around the system by using a 1 month for 50 cents coupon over and over again, even though the license does not allow it. Because of the obfuscation, we can catch people like that.
No. I am not. It is an obfuscation feature. I was just pointing out the speciousness of your argument. And indeed, it is no surprise that your next argument was a straw-man.
Of course you take application security seriously, would you have any customers if you didn't? I think the article submitter was implying that you obfuscated your PHP code, which doesn't enhance security in any way. The only gain for obfuscation in a commercial web app is to make it enough of a pain for average users to install the system on multiple hosts without licensing that they bite the proprietry bullet. You know it, I know it and your customers know it.
I think you give the submitter too much credit. Why then would they single out billing software, using the word "rely", and not mention licensing at all? To the submitter, it was all about advocating open source by showing the weekness in encoding, appealing to the security sense of the _users_. That implies that their legitimate use of the software is harmed by the decoding, which implies, just as they said, that we "rely" on it for application security. Otherwise, the argument wouldn't make sense.
The alternative interpretation that you provide is counter to the submitter's argument. If the encoder prevents illegitimate uses, like someone using it to run their multi-million-dollar business for nothing, then it is obviously not useless. We never claim that the encoding is for anything other than preventing illegitimate uses, and is for _our_ benefit. That is the whole point.
BTW: Software is covered by copyright, the authors or there employers hold the copyright on their work. Anybody who talks about protecting 'IP' is obfuscating the issue as 'Intellectual Property' implies ownership and you don't 'own' a copyright, you 'hold' or are assigned a copyright.
All forms of property are imaginary, legal constructs, anyway. Informal language is defined by usage. One could argue the same thing about any form of property, saying that ownership is merely holding the object, and many people actually make that argument, which is actually wrong. The use of the word "hold" also has misleading connotations, but just in a different way. It omits the legal assignment aspect, which you mentioned yourself. At any rate, any of those uses are perfectly valid common usages unless you are in a philosophical debate over the semantics, which we are not.
Anyway, the only clients who say anything about the encoded source issue are the ones who are technically competent enough that they have NDAs with us, and we work with them directly on any issues they have, so they often see the source anyway. We are very open to working with and trusting our legit clients.
We are not some megacorp looking for any way we can screw over our clients. We are a very ethically-minded small business, and we all work hard for reasonable compensation, even the owners. I am a Green Party member who boycotts Wal-Mart, and I can still say that, so it must be true.;)
I am one of the developers who works on ModernBill. We are very proactive about security.
We do not rely on security by obscurity on anything but the licensing. There is a difference between _using_ something and _relying upon_ it. We _rely upon_ proven, peer-reviewed, open source libraries to handle credit card encryption. We _use_ obscurity to help protect our "IP" for the same reason people use locks to protect other types of "property". To not make that distinction is polarizing the dichotomy.
Another important dichotomy is the distinction between what is possible and what is accessible. This same distinction needs to be made when arguing for the usefulness of open source. It is of course easier to have the source when you want to understand a program. What the encoder does is make the code less easy to understand. Even in decoded form, it is less easy than having the documented code. It also makes it easier to prove that we were the original author of the code.
That is also why we have unencoded source for most of the code, especially all of the business-specific and display logic that people will likely want to change. We rewrote all of ModernBill over the last year and a half for version 5, which has a front-end for the business-specific and display logic, and a back-end for the business-independent logic. The back-end is encoded to protect our copyright. There is no licensing code in the front-end.
We are active in protecting our clients' and their clients' security. We encourage the gateways we deal with to allow us to use cross-reference IDs to refer to billing account information for recurring charges, so that the billing account information does not need to be retained. We encourage our clients to use all of the security features we make available to them. We have a fraud prevention add-on (that is only an add-on because of the per-lookup charge we incur on our end), and we make it a point to explain why having lower fraud rates is better for everyone because they get better merchant account rates, and avoid chargeback fees. We rewrote the entire application for version 5.0, making many architectural changes to improve security.
For example, we don't use cookies or PHP sessions, avoiding well-known security issues involving those. We lock sessions to IPs. We use an IP whitelist, secret key, and SSL for API access. At the interface level, every hit requires a session ID to be either posted or in the URL, and an action ID determined by an unencoded file, which allows an admin to do whatever they like with the action ID lookups. I will be adding an option to have that be randomized per-session. That is all to make remote exploits more difficult just in case the worst happens and a vulnerability is found. We are not foolishly optimistic.
We have privilege separation by making it possible to separate ModernBill into 4 pieces: the back-end, and the 3 interfaces (admin, client, and order). We don't allow anything encrypted to leave the API, only enter it. All processing of encrypted data must be done by the back-end.
We deal with security issues ethically and promptly. We take security very seriously. We understand that we write billing software in PHP, and that immediately brings concern. ModernBill is not a typical PHP application. It is written in PHP due to its proliferation and portability, not because we are beginnnig programmers who don't know anything else. BTW, you can watch us at http://www.iseedevpeople.com/ when we are at the office.
Slashdot Mirror
Well, there is kqueue(), but it can watch changes per fd, not per inode. So if you are okay with having to open an fd for it, then that will work.
DragonFly BSD has operation-level journaling already implemented at the VFS layer.
Well, people tried to go around the licensing back in the day, too (and succeeded, as they still do). So I still fail to see how this relates to your earlier comments.
Of course people succeeded. The relation is that some is not all. It is a valid point that it stops some people. It is the distinction between possibility and accessibility. But I see that you provide an argument against that:
Obfuscation slows some people down, a little. For others, it merely creates an incentive to crack. Software which, otherwise, they'd have had no interest in, becomes their target, just for the challenge of it. And it ends up being circulated more widely than if there were no obfuscation in the first place.
That is a pretty good argument against a lot of cases, but there is a big difference between trusting encoded code given to them by us, and cracked code. Sure, for a photoshop desktop, one can just wipe their install and start fresh if the cracked version causes problems. But for software that runs your business, and handles your billing, no one in their right mind would use cracked software.
The point was _not_ that it _is_ any _more_ useful. The point was that it _is not_ any _less_ useful because of your argument. Personally, I would prefer the source to be available, but there are very valid reasons, like the fact that we know that many people actively try to go around the licensing, but are not competent enough to figure out how, like the people who try to work around the system by using a 1 month for 50 cents coupon over and over again, even though the license does not allow it. Because of the obfuscation, we can catch people like that.
No. I am not. It is an obfuscation feature. I was just pointing out the speciousness of your argument. And indeed, it is no surprise that your next argument was a straw-man.
There was a time, you know, when most programs came with source, but were under commercial licenses.
Was that the same time barely any businesses had Internet access, let alone p2p, and security on the Internet wasn't a major concern?
Of course you take application security seriously, would you have any customers if you didn't? I think the article submitter was implying that you obfuscated your PHP code, which doesn't enhance security in any way. The only gain for obfuscation in a commercial web app is to make it enough of a pain for average users to install the system on multiple hosts without licensing that they bite the proprietry bullet. You know it, I know it and your customers know it.
I think you give the submitter too much credit. Why then would they single out billing software, using the word "rely", and not mention licensing at all? To the submitter, it was all about advocating open source by showing the weekness in encoding, appealing to the security sense of the _users_. That implies that their legitimate use of the software is harmed by the decoding, which implies, just as they said, that we "rely" on it for application security. Otherwise, the argument wouldn't make sense.
The alternative interpretation that you provide is counter to the submitter's argument. If the encoder prevents illegitimate uses, like someone using it to run their multi-million-dollar business for nothing, then it is obviously not useless. We never claim that the encoding is for anything other than preventing illegitimate uses, and is for _our_ benefit. That is the whole point.
BTW: Software is covered by copyright, the authors or there employers hold the copyright on their work. Anybody who talks about protecting 'IP' is obfuscating the issue as 'Intellectual Property' implies ownership and you don't 'own' a copyright, you 'hold' or are assigned a copyright.
All forms of property are imaginary, legal constructs, anyway. Informal language is defined by usage. One could argue the same thing about any form of property, saying that ownership is merely holding the object, and many people actually make that argument, which is actually wrong. The use of the word "hold" also has misleading connotations, but just in a different way. It omits the legal assignment aspect, which you mentioned yourself. At any rate, any of those uses are perfectly valid common usages unless you are in a philosophical debate over the semantics, which we are not.
Anyway, the only clients who say anything about the encoded source issue are the ones who are technically competent enough that they have NDAs with us, and we work with them directly on any issues they have, so they often see the source anyway. We are very open to working with and trusting our legit clients.
We are not some megacorp looking for any way we can screw over our clients. We are a very ethically-minded small business, and we all work hard for reasonable compensation, even the owners. I am a Green Party member who boycotts Wal-Mart, and I can still say that, so it must be true. ;)
I am one of the developers who works on ModernBill. We are very proactive about security.
We do not rely on security by obscurity on anything but the licensing. There is a difference between _using_ something and _relying upon_ it. We _rely upon_ proven, peer-reviewed, open source libraries to handle credit card encryption. We _use_ obscurity to help protect our "IP" for the same reason people use locks to protect other types of "property". To not make that distinction is polarizing the dichotomy.
Another important dichotomy is the distinction between what is possible and what is accessible. This same distinction needs to be made when arguing for the usefulness of open source. It is of course easier to have the source when you want to understand a program. What the encoder does is make the code less easy to understand. Even in decoded form, it is less easy than having the documented code. It also makes it easier to prove that we were the original author of the code.
That is also why we have unencoded source for most of the code, especially all of the business-specific and display logic that people will likely want to change. We rewrote all of ModernBill over the last year and a half for version 5, which has a front-end for the business-specific and display logic, and a back-end for the business-independent logic. The back-end is encoded to protect our copyright. There is no licensing code in the front-end.
We are active in protecting our clients' and their clients' security. We encourage the gateways we deal with to allow us to use cross-reference IDs to refer to billing account information for recurring charges, so that the billing account information does not need to be retained. We encourage our clients to use all of the security features we make available to them. We have a fraud prevention add-on (that is only an add-on because of the per-lookup charge we incur on our end), and we make it a point to explain why having lower fraud rates is better for everyone because they get better merchant account rates, and avoid chargeback fees. We rewrote the entire application for version 5.0, making many architectural changes to improve security.
For example, we don't use cookies or PHP sessions, avoiding well-known security issues involving those. We lock sessions to IPs. We use an IP whitelist, secret key, and SSL for API access. At the interface level, every hit requires a session ID to be either posted or in the URL, and an action ID determined by an unencoded file, which allows an admin to do whatever they like with the action ID lookups. I will be adding an option to have that be randomized per-session. That is all to make remote exploits more difficult just in case the worst happens and a vulnerability is found. We are not foolishly optimistic.
We have privilege separation by making it possible to separate ModernBill into 4 pieces: the back-end, and the 3 interfaces (admin, client, and order). We don't allow anything encrypted to leave the API, only enter it. All processing of encrypted data must be done by the back-end.
We deal with security issues ethically and promptly. We take security very seriously. We understand that we write billing software in PHP, and that immediately brings concern. ModernBill is not a typical PHP application. It is written in PHP due to its proliferation and portability, not because we are beginnnig programmers who don't know anything else. BTW, you can watch us at http://www.iseedevpeople.com/ when we are at the office.