If the tail broke off, the back of the plane would go up, causing one wing (randomly) to dive into the ground, followed shortly thereafter by the nose before coming to rest. Then, the plane came back down on its gear and/or belly. Depending on the angle the person was viewing the accident from, it's pretty easy to see how someone could describe that as a cartwheel, albeit an unsuccessful partial one where the gymnast ended up in a faceplant.
So, it's not that it can't, it's just that you don't want to. That's fine, but hardly the same.
In this case, it is my code to do with as I wish. The point I was trying to make is that it is not true for every case, particularly when you're working for a company that may have contradictory agreements with other companies.
Just curios: how does your system prevent an attacker from simply replacing/modifying your JavaScript code with a snippet that copies the user's passphrase to his/her server?
The same thing that prevents an attacker from grabbing cookies out of the browser's cookie store. Third-party JavaScript does not have access to client-side storage unless it was served from my origin, and the code running on my origin is vigilant about ensuring that third-party JavaScript cannot be injected. (For the one part of my site that allows HTML submission, I have a whitelist of HTML tags and attributes that are allowed, and anything not on that whitelist gets eaten.) Now I'll grant you that a malicious extension could modify a link somewhere that causes *my* JavaScript code to do something on behalf of the user, but even in that case, the risk is no greater than it would be with cookies.
Incidentally, the only reason it interfaces with PHPBB's code at all is because PHPBB has a specific way of sanitizing the UTF-8 data for certain fields, and there's no good way to replicate that. So for compatibility, it has to use PHPBB's function, which would put that piece under the GPL if it were distributed (which it isn't). If it were under AGPL instead of GPL, it would have to be redistributed, and would reveal details that I don't want to reveal.
Really, there are large chunks of PHPBB that would be better off under a less restrictive license like the LGPL, if only so that third-party plug-ins that call back into parts of PHPBB aren't forced to be GPL-licensed. But that's not my decision to make.
In this case, it's one line of JavaScript that queries a PHP script that fetches a database record out of a different database and inserts a cookie into the browser while simultaneously blowing a matching user record into PHPBB's database, coupled with lots of changes to rip out every place with a login/logout button, a password change button, or an account creation button. None of that is going to be all that useful to... well, anybody, really. It is entirely a site-specific hack. It's also going away because I found a different bulletin board suite that is actually based on XHR requests so it can integrate with my authentication system correctly. (By contrast, making PHPBB integrate with it properly would have required a near-complete rewrite of PHPBB.)
Actually, that's a great analogy, but not for the reasons you think. By increasing the cost of the whips, the plantation owners require more output from the slaves to cover the extra cost of the whips, so they drive the slaves even harder.
In much the same way, by making contributions back from the community an absolute demand as the AGPL does (and, to a lesser degree, the GPL does), developers who cannot or are unwilling to comply with those requirements must reinvent the wheel, thus increasing market fragmentation and reducing the number of eyes looking at any one implementation. This, in turn, reduces the quality of all of the offerings and hurts the Free Software community every bit as much as it hurts the businesses. In order to make up for the loss of developers, those community developers must work even harder if they want their software to be seen as a viable alternative to the commercial equivalent.
Come again? The word "hypocrite" doesn't just mean someone who disagrees with you or does things you don't like. It means someone who says one thing while simultaneously doing the opposite. Nothing I have said or done in this thread even remotely qualifies as hypocrisy.
In that discussions I sometime wish that there would be no GPL, AGPL or BSD or any other open source software so that people like you would not get a free ride.
Free ride? Hardly. I spent about half a decade maintaining a Linux distro on a platform that only a few thousand people ever cared about. I've released quite a bit of software as Open Source, both on my own and through my employer. I'm one of the open source advocacy people within my company, actively encouraging development teams to release software as open source.
I'm not being a hypocrite here. You are. You're insisting that I'm somehow doing evil by using software well within the terms under which it was licensed, and you're arguing that in order to use open source, I should be forced to release everything I do, no matter how distantly related, as open source. Unlike what I'm doing, your argument is hypocrisy—claiming to support the GPL while simultaneously attacking people who use GPLed software in full compliance with the license, thus giving the entire Free Software movement a bad name.
Oh how glad the developers of PHPBB must be that dgatwood is using their software.
Oh, but they are. You see, the only way to get more eyes on the code fixing bugs is to actually have other programmers using that code. When I use a piece of software, I invariably find bugs. Lots of bugs. And I fix those bugs and submit patches. Therefore, it is in PHPBB's best interest to have more people like me using their software—actual programmers, rather than mere end users with no programming skills who leech off their efforts and contribute nothing back. In exchange for me finding and fixing bugs, PHPBB's license allows me to keep private my site integration changes that would not benefit anyone and that are nobody else's business. This strikes a good balance between the needs of the admin/user and the needs of the developer.
The AGPL instead fails to strike a balance. It represents the effect of our entitlement-driven society on the Open Source movement, demanding that every change be made available even if you do not redistribute the modified software. And that changes the delicate balance between site developer and software developer in a way that makes it much less useful to me.
You can disagree with me all you want to, but disagree with me by pointing out reasons why you disagree. Name-calling ranks right up there with Godwin's law; it automatically means that the debate is over and you have lost.
Wow, so I might have reserved that word for something like "genocide" or "the holocaust", but if you want to use it for a license which you happen to have a dislike for, I guess that works.
It's a question of scale. Consider an ant attacking another ant; it's murder from an ant's perspective, but on the human scale, we don't care. Same deal for AGPL vs. the holocaust. In the context of licensing, AGPL is horribly evil. In the context of human civilization as a whole, it's below the noise floor.:-)
If the license would say that you need to share your modifications, then that is what you agreed to.
PHPBB is licensed under GPL, not under AGPL. The GPL requires you to share your source code modifications with anyone to whom you distribute the software. PHPBB being a server-side app, none of the software is distributed. At all. Therefore, its license says that I am under no obligation to make available local modifications.
But you are a hypocrite if you take a free product, and demanding that the developer is using a less restrictive license.
I'm not demanding that the developer use a less restrictive license. I'm saying that I'm glad the developer chose to use the less restrictive license because had the developer used AGPL, it would have prevented me from even considering its use.
because that authentication system cannot necessarily be made open source
What? Why not?
Because I spent a lot of time on that software, and I'm not really interested in giving it away? Look, the only reason I'm modifying the open source software at all is so that users don't have to create two login accounts. That hardly warrants giving away the source code for an existing login system that is an entirely separate piece of software in its own right, merely so that the open source software can use that login system. Any software whose license demands such a thing is going to get no more than a laugh and an eye roll from me as I search for other software whose license isn't so utterly absurd.
And this is not to say that I won't at some point choose to give away that source code. I will not, however, even consider using a piece of software whose license would force that decision and the timing thereof.
There are plenty of open source authentication systems. In fact, I'd say it's extremely reckless to use a security system that hasn't been widely vetted, and that requires available source.
None of the ones I saw met my needs. None of them even came close, actually. The token-based authentication that most websites use makes it way too easy to sniff a few packets and then impersonate someone, and regrettably, the exorbitant cost of multi-domain certificates makes SSL infeasible at this time. Therefore, my base requirement was a robust and fairly lightweight, pure-JavaScript means of signing each individual HTTP request with a shared secret key derived from the user's passphrase and an arbitrary nonce generated by the server. (Still on my to-do list is adding synchronized timestamping and/or regular nonce rotation to prevent replay attacks, but given the site design, the damage posed by such an action would be fairly minimal, so I'm in no hurry.)
Irrelevant. None of the (A)GPL licenses require you to give anything back. All you need to do is inform your users that a copy can be arranged if they ask for it, nothing more.
You missed my point entirely. The point I was trying to make was that even as a user of software whose license does not require me to give the changes back, I do at least make the attempt if those changes would potentially benefit anyone else. I'm not averse to giving back changes. However, as a site admin, I absolutely require the right to be able to make the final decision as to which changes I make publicly available and which changes I don't. It's fine if you don't agree with me, and it's fine if you decide to license your software under AGPL because of it, but if you do, I guarantee that I won't use your software. Ever. Even if I don't need to modify it initially. Why? Because it locks me into a situation where if I ever needed to modify it in the future for any reason, those changes would have to be public, no matter how sensitive those changes might be. That isn't an acceptable risk to me.
If you depend on the high-availability, replicated functionality available in recent BerkeleyDB systems, then PostgreSQL can potentially be used as an alternative where many lightweight database systems (SQLite, for example) cannot be seriously considered.
I have no idea what the NoSQL space is like these days, so there may be better choices over there. I've never used those parts of BerkeleyDB (those features didn't even exist until years after I last touched BerkeleyDB), so I can't say how they compare performance-wise.
Who is talking about a configuration file? Have you ever tied a piece of software into a different authentication system? This isn't a config file change. It's potentially thousands of lines of code changes throughout the software, depending on how the software was written and how many assumptions it makes about the nature of the authentication system. (For example, my current authentication system does not use cookies. Any software that assumes cookie-based authentication tokens requires considerable changes.)
You never know how useful those changes might be to others.
Yes, I do. Unless someone steals the closed-source authentication system in question, tying into it is not useful in the slightest.
Besides, if you're that bad at coding that knowing your table names yields a vector of attack... you should probably better leave that to others.
If you think that not knowing the table names does not make all vectors of attack more difficult, you should probably leave the advice to people who understand security.:-)
In computer security (or any security, for that matter), the best defense is a layered defense. I'm quite good at performing security audits, having spent significant amounts of time over the years doing so. However, any sufficiently large chunk of code, no matter how well analyzed, stands some small risk of containing security holes. So in the event that I missed something, using nonstandard table names provides an additional defensive layer that makes any sort of compromise considerably more difficult.
Oh, it's relevant. The principle users of web software are the admins. They configure the software, they maintain the installation, they monitor what people are doing to it, etc. The GPL does something useful for those folks; it ensures that someone won't fork these tools, create their own versions of them, and sell them without giving their changes back. So it serves a useful purpose.
The AGPL, by contrast, adds additional restrictions on the site admins, but adds nothing of value for the so-called "users". Random website guests do not have direct access to the database (and it would be disastrous to give them such access), making their ability to spin off their own copy of the site largely moot except in very limited circumstances. And even if they somehow could get their data, for the most part, what makes a site valuable is usually the community, not the data, which means it would mostly be useless anyway.
In other words, it's a solution in search of a problem—maybe if someone were writing Google Docs under the AGPL... but nobody is ever going to do that, realistically—nobody sane, anyway.
Ironically, the software that Affero builds, given that it involves payment systems, is again precisely the sort of software where private customization is most crucial to the success of the software, and where again no end user could usefully take advantage of the changes anyway.
Well, I know that a lot of folks moved away from Berkeley DB several years ago when Oracle first acquired it (and by "moved away", I mean "ran away") and embraced SQLite. Now might be a good time for the rest of the open source community to do the same.
Alternatively, for situations where SQLite is insufficient, IMO, PostgreSQL is usually a good alternative.
Better yet, adopt a middleware library like PDO so that with a small amount of effort (rewriting CREATE/ALTER TABLE queries, anything involving triggers or automatic time/date stamping, and a few other rough edges), it can be ported to arbitrary backend databases.
Lots of them, actually. Any website is likely to have an authentication system already. Any website wanting to add features using existing open source technology is going to want to tie into that system. This common use case is fundamentally incompatible with Affero, because that authentication system cannot necessarily be made open source, and the AGPL does not provide a linking exception.
Also, before I adopt any piece of software these days, I do a thorough security audit. Mind you, I prefer to give those changes back when possible, because it makes future upgrades easier, but when the changes involve many thousands of lines of code changes (e.g. rewriting every single SQL query in parameterized form), this is often not appreciated as much as one might expect.
In short, anything I touch usually experiences a major fork and a large-scale rewrite prior to deployment. And that's not even counting all the minor stuff like skins, custom icons, etc., much of which often involves minor code changes because of inadequate class and ID attributes in HTML output, the need to manipulate the order of large blocks in ways that makes CSS unhappy, etc.
PHPB is precisely the sort of situation where AGPL is unacceptable, because it infects code that has no legitimate association with the software itself. For example, on a website that I run, I currently use a heavily customized PHPBB setup that hooks into the (non-open-source) login system used for the site that it is integrated into. None of those changes would be even slightly useful to anyone but me.
Further, without the ability to migrate the actual data, being able to replicate the service itself is basically useless, which means that putting something like PHPBB under a horrible license like AGPL would buy you absolutely nothing.
Basically, AGPL is only useful for a very, very narrow range of software designed specifically for use in "software-as-a-service" situations, and even then, it is only acceptable if you don't need to tie it into existing infrastructure. In short, it is basically never acceptable, and its only sensible use is for businesses to be able to say, "Hey, look, we've open sourced our stack," while simultaneously ensuring that no legitimate business would ever even contemplate replicating that stack and competing with them.
AGPL is not good. AGPL is horribly evil. It means that I, as a sysadmin installing a piece of software, cannot make changes necessary to tailor it to my particular site configuration without releasing the source to those changes, even though those changes cannot possibly be of any use to anyone outside my server team except for attackers wishing to discover security bugs, learn the names of database tables, etc. for nefarious purposes.
I don't know about anyone else, but I personally have an absolute zero tolerance policy for Affero. It has no valid place among reasonable open source and free software licenses, as it is the antithesis of software freedom.
They can't ban everything associated with the internet.
Yeah, they can. That's why this is so scary. ISPs are VPN providers just waiting to happen. Every ISP that provides shell accounts can easily become someone's VPN provider, through no fault of their own.
Wait, so it took you two-thirds of the article before your alarm started sounding? The zombie apocalypse bit (global revenant epidemic) didn't tip you off?
You can bet that Intel would rather that THEY were manufacturing Apple's ARM chips than TSMC.
I wouldn't be so sure. You're missing two things:
Volume. Intel has a foundry business. However, from what I've read, most of its customers are small, fabless chipmakers that deal in fairly low volume. Apple is not a small, fabless chipmaker. In fact, without doing the math, I rather suspect it to be one of the world's largest fabless chipmakers. Apple sold something on the order of 300 million iOS devices last year, each of which contained a custom CPU (and might even contain other custom parts—I'm not sure). I don't have sales numbers for Intel in 2012, but as best I could determine, that's roughly as many CPUs as Intel sold in 2011. Total. Now granted, you can stamp out a lot more A6 chips per wafer than Core i7 chips (somewhere around seven times as many, by my quick-and-dirty math), but that would still be a huge order.
Priority. Intel builds their own chips, and one would assume that their chips would take priority over manufacturing for a third-party contract job. Presumably, a large-volume manufacturer like Apple would want that priority to be inverted.
Mind you, I'm not saying you're not correct, but I don't think it's as clear-cut as you're implying.
Yea, I work in the security industry and I don't really agree. I hear what you're saying about considering each application and you're not wrong, but I think the potential benefits of this easily outweigh the negatives. It will apply pressure to companies who really do need to encrypt their data and just cannot get the will from the business to do it.
No, it won't. It will cause every non-corporate-run website run by individuals within the state of California to shut down because of the inability to pay the exorbitant costs suddenly required to keep the sites open.
I run a completely zero-profit website. The only personally identifiable information my site stores is a username and password. Everything else is voluntary. It is not involved in any financial transactions. It should not be affected by laws like this in any sane universe. The problem is that legislators don't understand technology, and will say, "Yes, but users could use the same username and password on multiple sites." And yes, they could. And if my database is compromised, I would have to send out letters to all... well, currently one users... informing myself of the breach. (Have I mentioned that this site is just getting off the ground?)
The big problem is that the database uses a shared hosting plan and a shared database server run by my ISP. I have no control over whether the database is encrypted on disk or in transit between the shared hosting server and the database server. In order to add that protection, I would have to crank my hosting plan up to a dedicated server at a monthly cost that is equivalent to several years on my current hosting plan and buy a multi-subdomain SSL cert that also costs (annually) as much as several years worth of service. And then, because I cannot possibly dedicate the time to manage my own server on an ongoing basis (hence the shared hosting plan as opposed to a VPS for the web server side), I would have to hire someone to manage that on an ongoing basis.
So if this law is not very narrowly tailored to sites that contain SSNs, financial information, and medical information, I'll have no choice but to shut my site down. I can't afford to personally spend potentially many thousands of dollars each year to run a website out of the goodness of my heart.
Implementing encryption in this way is not going to be that onerous...
In my experience, any security practice that is not onerous also has little effect on security. Physical theft of spinning storage is an exceptionally rare cause of data breaches. Backup tapes are stolen occasionally. Offline copies of the database that sysadmins allowed their employees to take home with them on a laptop are also stolen occasionally. However, data theft caused by attackers remotely cracking into servers overshadows both of those loss mechanisms by orders of magnitude. Because remote data compromises are completely unaffected by encrypting the database on disk, use of encryption is very nearly worthless in the grand scheme of things. Requiring encryption on disk is a bit like trying to prevent automobile accident deaths by requiring children to wear bicycle helmets while in the car just in case the kids didn't wear their seatbelts.
Furthermore, it is completely unnecessary. There are already laws that require encryption for anything that could be considered high-risk. HIPAA has strict requirements for how health-related data can be stored. PCI DSS compliance requires encryption of credit card data. And so on. Any company that sanely should be required to use database encryption is already compelled by law to do these things. Anyone who is not already compelled to do them should not be, because it really isn't an earth-shattering event if a hashed password database gets compromised, and the odds of it being compromised through physical theft border on nonexistent anyway. My database is more likely to be destroyed by a meteor im
See, that's the thing. He is responsible for the people under him. So there are only two choices: either he knows what was going on and committed perjury or he does not know what was going on and is likely guilty of criminal negligence through willful indifference and perjury by willful blindness. I vote for the latter. More jail time that way.
Slashdot Mirror
If the tail broke off, the back of the plane would go up, causing one wing (randomly) to dive into the ground, followed shortly thereafter by the nose before coming to rest. Then, the plane came back down on its gear and/or belly. Depending on the angle the person was viewing the accident from, it's pretty easy to see how someone could describe that as a cartwheel, albeit an unsuccessful partial one where the gymnast ended up in a faceplant.
In this case, it is my code to do with as I wish. The point I was trying to make is that it is not true for every case, particularly when you're working for a company that may have contradictory agreements with other companies.
The same thing that prevents an attacker from grabbing cookies out of the browser's cookie store. Third-party JavaScript does not have access to client-side storage unless it was served from my origin, and the code running on my origin is vigilant about ensuring that third-party JavaScript cannot be injected. (For the one part of my site that allows HTML submission, I have a whitelist of HTML tags and attributes that are allowed, and anything not on that whitelist gets eaten.) Now I'll grant you that a malicious extension could modify a link somewhere that causes *my* JavaScript code to do something on behalf of the user, but even in that case, the risk is no greater than it would be with cookies.
Incidentally, the only reason it interfaces with PHPBB's code at all is because PHPBB has a specific way of sanitizing the UTF-8 data for certain fields, and there's no good way to replicate that. So for compatibility, it has to use PHPBB's function, which would put that piece under the GPL if it were distributed (which it isn't). If it were under AGPL instead of GPL, it would have to be redistributed, and would reveal details that I don't want to reveal.
Really, there are large chunks of PHPBB that would be better off under a less restrictive license like the LGPL, if only so that third-party plug-ins that call back into parts of PHPBB aren't forced to be GPL-licensed. But that's not my decision to make.
In this case, it's one line of JavaScript that queries a PHP script that fetches a database record out of a different database and inserts a cookie into the browser while simultaneously blowing a matching user record into PHPBB's database, coupled with lots of changes to rip out every place with a login/logout button, a password change button, or an account creation button. None of that is going to be all that useful to... well, anybody, really. It is entirely a site-specific hack. It's also going away because I found a different bulletin board suite that is actually based on XHR requests so it can integrate with my authentication system correctly. (By contrast, making PHPBB integrate with it properly would have required a near-complete rewrite of PHPBB.)
Actually, that's a great analogy, but not for the reasons you think. By increasing the cost of the whips, the plantation owners require more output from the slaves to cover the extra cost of the whips, so they drive the slaves even harder.
In much the same way, by making contributions back from the community an absolute demand as the AGPL does (and, to a lesser degree, the GPL does), developers who cannot or are unwilling to comply with those requirements must reinvent the wheel, thus increasing market fragmentation and reducing the number of eyes looking at any one implementation. This, in turn, reduces the quality of all of the offerings and hurts the Free Software community every bit as much as it hurts the businesses. In order to make up for the loss of developers, those community developers must work even harder if they want their software to be seen as a viable alternative to the commercial equivalent.
Come again? The word "hypocrite" doesn't just mean someone who disagrees with you or does things you don't like. It means someone who says one thing while simultaneously doing the opposite. Nothing I have said or done in this thread even remotely qualifies as hypocrisy.
Free ride? Hardly. I spent about half a decade maintaining a Linux distro on a platform that only a few thousand people ever cared about. I've released quite a bit of software as Open Source, both on my own and through my employer. I'm one of the open source advocacy people within my company, actively encouraging development teams to release software as open source.
I'm not being a hypocrite here. You are. You're insisting that I'm somehow doing evil by using software well within the terms under which it was licensed, and you're arguing that in order to use open source, I should be forced to release everything I do, no matter how distantly related, as open source. Unlike what I'm doing, your argument is hypocrisy—claiming to support the GPL while simultaneously attacking people who use GPLed software in full compliance with the license, thus giving the entire Free Software movement a bad name.
Oh, but they are. You see, the only way to get more eyes on the code fixing bugs is to actually have other programmers using that code. When I use a piece of software, I invariably find bugs. Lots of bugs. And I fix those bugs and submit patches. Therefore, it is in PHPBB's best interest to have more people like me using their software—actual programmers, rather than mere end users with no programming skills who leech off their efforts and contribute nothing back. In exchange for me finding and fixing bugs, PHPBB's license allows me to keep private my site integration changes that would not benefit anyone and that are nobody else's business. This strikes a good balance between the needs of the admin/user and the needs of the developer.
The AGPL instead fails to strike a balance. It represents the effect of our entitlement-driven society on the Open Source movement, demanding that every change be made available even if you do not redistribute the modified software. And that changes the delicate balance between site developer and software developer in a way that makes it much less useful to me.
You can disagree with me all you want to, but disagree with me by pointing out reasons why you disagree. Name-calling ranks right up there with Godwin's law; it automatically means that the debate is over and you have lost.
It's a question of scale. Consider an ant attacking another ant; it's murder from an ant's perspective, but on the human scale, we don't care. Same deal for AGPL vs. the holocaust. In the context of licensing, AGPL is horribly evil. In the context of human civilization as a whole, it's below the noise floor. :-)
PHPBB is licensed under GPL, not under AGPL. The GPL requires you to share your source code modifications with anyone to whom you distribute the software. PHPBB being a server-side app, none of the software is distributed. At all. Therefore, its license says that I am under no obligation to make available local modifications.
I'm not demanding that the developer use a less restrictive license. I'm saying that I'm glad the developer chose to use the less restrictive license because had the developer used AGPL, it would have prevented me from even considering its use.
Because I spent a lot of time on that software, and I'm not really interested in giving it away? Look, the only reason I'm modifying the open source software at all is so that users don't have to create two login accounts. That hardly warrants giving away the source code for an existing login system that is an entirely separate piece of software in its own right, merely so that the open source software can use that login system. Any software whose license demands such a thing is going to get no more than a laugh and an eye roll from me as I search for other software whose license isn't so utterly absurd.
And this is not to say that I won't at some point choose to give away that source code. I will not, however, even consider using a piece of software whose license would force that decision and the timing thereof.
None of the ones I saw met my needs. None of them even came close, actually. The token-based authentication that most websites use makes it way too easy to sniff a few packets and then impersonate someone, and regrettably, the exorbitant cost of multi-domain certificates makes SSL infeasible at this time. Therefore, my base requirement was a robust and fairly lightweight, pure-JavaScript means of signing each individual HTTP request with a shared secret key derived from the user's passphrase and an arbitrary nonce generated by the server. (Still on my to-do list is adding synchronized timestamping and/or regular nonce rotation to prevent replay attacks, but given the site design, the damage posed by such an action would be fairly minimal, so I'm in no hurry.)
You missed my point entirely. The point I was trying to make was that even as a user of software whose license does not require me to give the changes back, I do at least make the attempt if those changes would potentially benefit anyone else. I'm not averse to giving back changes. However, as a site admin, I absolutely require the right to be able to make the final decision as to which changes I make publicly available and which changes I don't. It's fine if you don't agree with me, and it's fine if you decide to license your software under AGPL because of it, but if you do, I guarantee that I won't use your software. Ever. Even if I don't need to modify it initially. Why? Because it locks me into a situation where if I ever needed to modify it in the future for any reason, those changes would have to be public, no matter how sensitive those changes might be. That isn't an acceptable risk to me.
If you depend on the high-availability, replicated functionality available in recent BerkeleyDB systems, then PostgreSQL can potentially be used as an alternative where many lightweight database systems (SQLite, for example) cannot be seriously considered.
I have no idea what the NoSQL space is like these days, so there may be better choices over there. I've never used those parts of BerkeleyDB (those features didn't even exist until years after I last touched BerkeleyDB), so I can't say how they compare performance-wise.
Who is talking about a configuration file? Have you ever tied a piece of software into a different authentication system? This isn't a config file change. It's potentially thousands of lines of code changes throughout the software, depending on how the software was written and how many assumptions it makes about the nature of the authentication system. (For example, my current authentication system does not use cookies. Any software that assumes cookie-based authentication tokens requires considerable changes.)
Yes, I do. Unless someone steals the closed-source authentication system in question, tying into it is not useful in the slightest.
If you think that not knowing the table names does not make all vectors of attack more difficult, you should probably leave the advice to people who understand security. :-)
In computer security (or any security, for that matter), the best defense is a layered defense . I'm quite good at performing security audits, having spent significant amounts of time over the years doing so. However, any sufficiently large chunk of code, no matter how well analyzed, stands some small risk of containing security holes. So in the event that I missed something, using nonstandard table names provides an additional defensive layer that makes any sort of compromise considerably more difficult.
Oh, it's relevant. The principle users of web software are the admins. They configure the software, they maintain the installation, they monitor what people are doing to it, etc. The GPL does something useful for those folks; it ensures that someone won't fork these tools, create their own versions of them, and sell them without giving their changes back. So it serves a useful purpose.
The AGPL, by contrast, adds additional restrictions on the site admins, but adds nothing of value for the so-called "users". Random website guests do not have direct access to the database (and it would be disastrous to give them such access), making their ability to spin off their own copy of the site largely moot except in very limited circumstances. And even if they somehow could get their data, for the most part, what makes a site valuable is usually the community, not the data, which means it would mostly be useless anyway.
In other words, it's a solution in search of a problem—maybe if someone were writing Google Docs under the AGPL... but nobody is ever going to do that, realistically—nobody sane, anyway.
Ironically, the software that Affero builds, given that it involves payment systems, is again precisely the sort of software where private customization is most crucial to the success of the software, and where again no end user could usefully take advantage of the changes anyway.
Well, I know that a lot of folks moved away from Berkeley DB several years ago when Oracle first acquired it (and by "moved away", I mean "ran away") and embraced SQLite. Now might be a good time for the rest of the open source community to do the same.
Alternatively, for situations where SQLite is insufficient, IMO, PostgreSQL is usually a good alternative.
Better yet, adopt a middleware library like PDO so that with a small amount of effort (rewriting CREATE/ALTER TABLE queries, anything involving triggers or automatic time/date stamping, and a few other rough edges), it can be ported to arbitrary backend databases.
Lots of them, actually. Any website is likely to have an authentication system already. Any website wanting to add features using existing open source technology is going to want to tie into that system. This common use case is fundamentally incompatible with Affero, because that authentication system cannot necessarily be made open source, and the AGPL does not provide a linking exception.
Also, before I adopt any piece of software these days, I do a thorough security audit. Mind you, I prefer to give those changes back when possible, because it makes future upgrades easier, but when the changes involve many thousands of lines of code changes (e.g. rewriting every single SQL query in parameterized form), this is often not appreciated as much as one might expect.
In short, anything I touch usually experiences a major fork and a large-scale rewrite prior to deployment. And that's not even counting all the minor stuff like skins, custom icons, etc., much of which often involves minor code changes because of inadequate class and ID attributes in HTML output, the need to manipulate the order of large blocks in ways that makes CSS unhappy, etc.
PHPB is precisely the sort of situation where AGPL is unacceptable, because it infects code that has no legitimate association with the software itself. For example, on a website that I run, I currently use a heavily customized PHPBB setup that hooks into the (non-open-source) login system used for the site that it is integrated into. None of those changes would be even slightly useful to anyone but me.
Further, without the ability to migrate the actual data, being able to replicate the service itself is basically useless, which means that putting something like PHPBB under a horrible license like AGPL would buy you absolutely nothing.
Basically, AGPL is only useful for a very, very narrow range of software designed specifically for use in "software-as-a-service" situations, and even then, it is only acceptable if you don't need to tie it into existing infrastructure. In short, it is basically never acceptable, and its only sensible use is for businesses to be able to say, "Hey, look, we've open sourced our stack," while simultaneously ensuring that no legitimate business would ever even contemplate replicating that stack and competing with them.
AGPL is not good. AGPL is horribly evil. It means that I, as a sysadmin installing a piece of software, cannot make changes necessary to tailor it to my particular site configuration without releasing the source to those changes, even though those changes cannot possibly be of any use to anyone outside my server team except for attackers wishing to discover security bugs, learn the names of database tables, etc. for nefarious purposes.
I don't know about anyone else, but I personally have an absolute zero tolerance policy for Affero. It has no valid place among reasonable open source and free software licenses, as it is the antithesis of software freedom.
Yes. That world is called academia. Just saying.
Yeah, they can. That's why this is so scary. ISPs are VPN providers just waiting to happen. Every ISP that provides shell accounts can easily become someone's VPN provider, through no fault of their own.
First, they came for the VPN providers....
Wait, so it took you two-thirds of the article before your alarm started sounding? The zombie apocalypse bit (global revenant epidemic) didn't tip you off?
And if you're in the military, it's potentially an important job—particularly if it's somebody else's navy.
Now navel gazing (omphaloskepsis), on the other hand, is rather pointless.
I wouldn't be so sure. You're missing two things:
Mind you, I'm not saying you're not correct, but I don't think it's as clear-cut as you're implying.
No, it won't. It will cause every non-corporate-run website run by individuals within the state of California to shut down because of the inability to pay the exorbitant costs suddenly required to keep the sites open.
I run a completely zero-profit website. The only personally identifiable information my site stores is a username and password. Everything else is voluntary. It is not involved in any financial transactions. It should not be affected by laws like this in any sane universe. The problem is that legislators don't understand technology, and will say, "Yes, but users could use the same username and password on multiple sites." And yes, they could. And if my database is compromised, I would have to send out letters to all... well, currently one users... informing myself of the breach. (Have I mentioned that this site is just getting off the ground?)
The big problem is that the database uses a shared hosting plan and a shared database server run by my ISP. I have no control over whether the database is encrypted on disk or in transit between the shared hosting server and the database server. In order to add that protection, I would have to crank my hosting plan up to a dedicated server at a monthly cost that is equivalent to several years on my current hosting plan and buy a multi-subdomain SSL cert that also costs (annually) as much as several years worth of service. And then, because I cannot possibly dedicate the time to manage my own server on an ongoing basis (hence the shared hosting plan as opposed to a VPS for the web server side), I would have to hire someone to manage that on an ongoing basis.
So if this law is not very narrowly tailored to sites that contain SSNs, financial information, and medical information, I'll have no choice but to shut my site down. I can't afford to personally spend potentially many thousands of dollars each year to run a website out of the goodness of my heart.
In my experience, any security practice that is not onerous also has little effect on security. Physical theft of spinning storage is an exceptionally rare cause of data breaches. Backup tapes are stolen occasionally. Offline copies of the database that sysadmins allowed their employees to take home with them on a laptop are also stolen occasionally. However, data theft caused by attackers remotely cracking into servers overshadows both of those loss mechanisms by orders of magnitude. Because remote data compromises are completely unaffected by encrypting the database on disk, use of encryption is very nearly worthless in the grand scheme of things. Requiring encryption on disk is a bit like trying to prevent automobile accident deaths by requiring children to wear bicycle helmets while in the car just in case the kids didn't wear their seatbelts.
Furthermore, it is completely unnecessary. There are already laws that require encryption for anything that could be considered high-risk. HIPAA has strict requirements for how health-related data can be stored. PCI DSS compliance requires encryption of credit card data. And so on. Any company that sanely should be required to use database encryption is already compelled by law to do these things. Anyone who is not already compelled to do them should not be, because it really isn't an earth-shattering event if a hashed password database gets compromised, and the odds of it being compromised through physical theft border on nonexistent anyway. My database is more likely to be destroyed by a meteor im
See, that's the thing. He is responsible for the people under him. So there are only two choices: either he knows what was going on and committed perjury or he does not know what was going on and is likely guilty of criminal negligence through willful indifference and perjury by willful blindness. I vote for the latter. More jail time that way.