SoylentNews is people
SoylentNews
I've been approached about working on a new privacy policy for SoylentNews and have agreed to do so. This journal is the first step in that process.
SN currently runs on Rehash, which is written in Perl and dates back to Slash 2.0. Many privacy-related considerations in Rehash are dictated by decisions made by the Slashdot admins nearly 25 years ago when they wrote the original code. The age of this code and its dependencies on tools like mod_perl make it nearly unmaintainable, meaning that SN may implement a new code base sooner rather than later. This is a pivotal time to discuss a new privacy policy for SN, an the decisions made now will likely influence the implementation of whichever new code base powers SN in the future.
SN has three primary stakeholders, which are 1) the ownership, 2) the staff, and 3) the community. To be successful, any site policy needs the support of all three of these stakeholders. That means the community needs to be actively engaged in the process.
My first steps will be to solicit input from the SN community and to spend most of my time listening. There are three important questions to discuss:
1) Problems: What privacy-related considerations are important to you, the members of the SN community? What are your concerns? As long as the issues are reasonably relevant to privacy, anything should be on the table here. This includes things like what user data gets stored, how long it is retained, who has access to it, the right to be forgotten, anonymous commenting, and anything that can reasonably be construed as a privacy issue.
2) Process: All three stakeholders must be supportive of any privacy policy for it to be effective. Therefore, once a privacy policy is drafted, we need a process for all three stakeholders to approve this. I anticipate the biggest questions here will be how you, the members of the SN community, get to voice your support or to request amendments to the policy. What process would the community like us to follow for enacting policy? Do all logged-in users get to vote? Does the community elect representatives?
3) Potential Solutions: Once you, the members of the SN community, make your privacy concerns heard, we need potential solutions for those concerns. These solutions will be limited by a few constraints. To allow for robust discussions and make SN a welcoming community, we need the ability to track abuse of the site (e.g., spam comments, sock puppet account creation, gaming the moderation system, etc...) to prevent disruption of the discussions. SN is required to comply with the laws in relevant jurisdictions such as the United States and the state of Delaware. Any solutions have to be practical, given the limited financial and human resources. Working within those constraints, SN policy should go above and beyond what is merely required by law, and to maximize the privacy of the members of the community.
I'll start by posting three journals at least 7-10 days apart to discuss each of these issues. For this journal, I want to focus on the first point, which is what privacy concerns you have, What is important to you, as members of the SN community, and what do we need to address in the new privacy policy? While any discussion of privacy matters is on-topic in this journal, I'd like to try to keep the discussion focused as much as possible on privacy-related problems that we need to address.
There are a few ground rules in this discussion:
1) If you're giving examples of specific privacy concerns, please don't include actual user names or people. Please use hypothetical terms, or use generic names like "person A" and "person B."
2) The new privacy policy is forward looking, meaning that the discussion should focus on how we can be better in the future, and not on holding people responsible for past mistakes or how the existing code is written.
3) Please keep the discussion civil and welcoming. Everyone deserves a chance to participate in this discussion and to be heard. Please keep the discussion constructive and refrain from posting personal attacks. Privacy is for everyone, and that means everyone deserves to be heard. I ask that you please don't try to dominate the discussion or shout other people down, and instead let everyone make their opinions known.
4) Please keep the discussion on-topic. Any privacy-related matters are on-topic, but issues like story selection are beyond the scope of this policy. Let's keep issues like politics out of this discussion, too.
5) Please don't moderate people down unless they're off-topic, trying to dominate the discussion, shouting people down, or posting personal attacks. Even if you disagree with someone else, please don't moderate them down unless they're violating the ground rules for this discussion. I want everyone to be heard.
I pledge that I'll read every comment that you post. My direct input to this discussion will be minimal, and I probably won't post at all except maybe to answer questions or ask for more detail if appropriate. I'm not here to debate with people. I just want to listen to your concerns. Anonymous Cowards are welcome in this discussion, but all comments that I post will be from the dalek account. I have unchecked the "willing to moderate" box in my user preferences, which means that I am not moderating any comments in this discussion. I am just here to listen.
I want to make these discussions as inclusive as possible. That means I intend to allow Anonymous Coward input to all of these journals. In exchange for keeping these discussions open, I ask that you please keep these discussions on track. I will post future journals, but for now, I want to know what your privacy concerns are, and what topics we need to address in the new privacy policy.
(Score: 1, Informative) by Anonymous Coward on Wednesday May 31, @04:45AM (8 children)
There are two problems with mod_perl from the point of view of SN. The first is that mod_perl provides a large and deep connection between Apache and perl. This provides some benefits to perl but also comes with a gigantic attack surface for exploits and escalation of privileges. FastCGI and other alternatives are more limited in their risk profile but they trade off by being completely unable to do some of what mod_perl does. This has the additional effect of making mod_perl an Apache-only implementation vs FastCGI presenting other web server options. If rehash were to move away from mod_perl, the outdated Apache issues go with it automatically. All that said, I think a bit of the mod_perl hate on here is hyperbole and moving from 1.x to 2.x (and moving Apache from 2.2 to 2.4) is much easier than some alternative plans thrown around the site lately, but there are some real pros/cons like the above to keep in mind.
(Score: 2) by RS3 on Wednesday May 31, @02:12PM (7 children)
Exactly the answer I was hoping for, and even better, thanks! That all fits with what I'm (and others are) thinking. We'll have to see what, if any mod_perl-specific API calls are being done in rehash. I'm hoping to try it in a few days, and others are working on it too. I've been intending to do this for many months, but I wasn't sure of some things that you have now clarified, and several specific tech tidbits have surfaced which will make the job easier, and your wisdom totally clarifies the path.
As I mentioned above, there are some mysql calls that don't work with newer mysql, so those have to be sorted out, and I'm not sure why mysql would break an API, making mysql upgrades a big pain (maybe giving SQL programmers work and jobs? :)
Thank you again!
(Score: 1, Insightful) by Anonymous Coward on Wednesday May 31, @11:05PM (5 children)
I'm not sure which MySQL calls you are talking about in specific but sometimes you have to break backwards compatibility. Otherwise, you end up in the situation of PHP where you have known vulnerabilities in use decades after the patched version is released or increasing layers of hard-to-maintain indirection or you are stuck with ever increasing technical debt that make it impossible to move forward or other problems. MySQL has to be especially careful of their old MySQL-isms because they are no longer the de facto free SQL implementation.
(Score: 2) by RS3 on Thursday June 01, @06:08AM (4 children)
I'm not sure if you're saying this, or your post triggered the thought, but the concept is: it is okay to break an API where it's been determined that the thing in question was dangerous, or at least could encourage / allow bad code practices that result in a vulnerability. I'm on board with that consideration. I just wish we (the world) didn't accept and live with so much broken code (hidden flaws / vulnerabilities due to bad coding practices).
(Score: 0) by Anonymous Coward on Thursday June 01, @09:42AM (3 children)
I think it is okay to break APIs for whatever reason you (as the developer) want as long as you give adequate warning. What is "adequate" depends on a lot of factors but actively dangerous code has a much lower bar than most other motivations. Personally, I am more of the "don't break userspace" camp, but that is because my professional work and the projects I tend to help out for recreation fall more on the engineering side of the continuum than the coding side. Both have their places one of the considerations for proper engineering is how widely used it will be and the consequences of getting it wrong. That leads to less situations where changes are needed at all, especially without a proper transition plan in place first.
(Score: 2) by RS3 on Friday June 02, @03:02AM
You and I are like-minded, including that I'm both hw and sw engineer (and other things that might be more fun at this point, like working on antique / classic cars). I'm torn over the developer subculture vs. userland. I'm thinking of the wide range of users who are trying to update an OS, for example, and suddenly their application (rehash for example) stops working. Now what? Sucks to be you? It creates a ripple of problems, some of which could be as big as stopping airlines, major commerce, medical treatment systems, military, govt., etc. Which means users and developers need better connections. But what do you do if the developers' company goes belly up? Again, sucks to be you? I have been, and am, caught in that trap, and my solution has been to not update the OS. Am I a danger to society? Not so far, but there are those who would label me as such. (absurdly speculative I say).
Maybe a law that says if a company goes belly up, and/or abandons a software product, they _must_ fully publish source code including documenting all development tools. Which leads me to: always use open-source software in the first place, at least you have a running chance (again, like rehash).
(Score: 0) by Anonymous Coward on Tuesday June 06, @08:43PM (1 child)
It doesn't matter how much warning you give or how "good" you think your reason is. If you tell your users to switch to a new version of something, and this makes something change from "working" to "not working", and you refuse to fix it, instead telling your users to deal with the problem on their end... this is basically telling your users "my time is more valuable than your time". Your users will disagree with that assessment, their time is obviously the most valuable thing to them, they won't care what the reason is, and they will interpret your words approximately as "fuck you".
Now you can usually get away with saying "fuck you" to your users some number of times before they start hating you, and maybe you don't even care if they hate you, but it doesn't make it "okay" to do so.
Giving advance notice might soften the blow but "do this extra work now or things will break later" is still just going to be interpreted as approximately "fuck you", still not "okay" but maybe they won't hate you quite as easily.
(Score: 0) by Anonymous Coward on Wednesday June 07, @08:26AM
Cool. Meanwhile unpatched vulnerabilities run rampant. Code turns to pasta as kludge is layered on kludge. Bugs creep in as complexity rises. You end up with an unmaintainable mess without the satisfaction of psychological flow. And then congrats, you end up with software that never changes because no one works on it. And your users can use it forever just as it is. Happy and content because they never had to change in a changing world.
(Score: 1, Interesting) by Anonymous Coward on Thursday June 01, @05:00AM
I don't know if this really has to be said or not because the colloquial use of API is different from the technical definition. However if you are going to look at how deeply SN uses mod_perl, you'll need to look at the entire mod_perl interface not just the API.