SoylentNews is people
SoylentNews
dalek (15489)
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: 2) by RS3 on Tuesday May 30, @03:23PM (22 children)
Thank you for doing this. I'm looking forward to many great ideas. I haven't given it much thought yet but I will in the near future.
Privacy overlaps tech in that if underlying code has security holes, someone could break in and retrieve private data, as we're seeing constantly happening elsewhere. So I have a tech question:
You mentioned "mod_perl" in a somewhat negative tenor. I want to understand, in case I'm missing something: what are the drawbacks of mod_perl? Other languages aside, what might be better?
(Score: 2) by owl on Tuesday May 30, @09:08PM (12 children)
I'm sure someone will add actual drawbacks, but all in all the general feeling I have from the comments that have been made by SN 'insiders' has the feel of:
We have a site that is written in Perl, we no longer have a Perl programmer available, and we can't seem to find anyone who knows enough Perl and who is willing to volunteer the effort to 'modernize' the codebase.
I.e., that there is nothing wrong, per. se., with Perl or mod_perl or having a site that is written in Perl. But the problem SN faces is: no SN 'insider' knows Perl, so no one can fix anything that might appear.
That, and the general feeling that the Perl code for SN is somewhat convoluted and hard to understand in the first place, creating a situation where it is even harder to find a "Perl programmer" willing and capable of taking on the needed tasks.
Unfortunately, switching to something written in a newer language where more programmers are easily found involves either:
Finding an already written replacement, which means it won't be traditional SN but some new variant that likely will not act in any similar way; or
Rewriting SN in $language_of_the_day -- which will likely be a huge undertaking for whomever takes this on, and still has the danger of: "in 10 or 20 years, when current $language_of_the_day is as out of favor as Perl is today, we end up back in the same boat we are in now".
(Score: 2) by RS3 on Tuesday May 30, @11:12PM (11 children)
Thanks. I appreciate your reply, but I did write "other languages aside" because I'm curious what dalek meant by:
There's enough general programming knowledge here among Soylenters to maintain the code, and getting it to run on different and newer OSes is being tried / worked on. I even bought some perl programming books recently, and I've modded some perl code over the years, not afraid of it. I'm just asking if mod_perl or fastCGI is the better way to go (both are maintained, kind of ...)
(Score: 2, Informative) by dalek on Tuesday May 30, @11:54PM (10 children)
I don't have a whole lot of experience with Perl, but I did look over the Rehash code several times to try to understand how parts of it worked.
One issue I'm aware of is that Rehash requires mod_perl and that it be running on Apache 2.2. This is out of date, I believe Apache 2.2 is unsupported, and my understanding is that changes to the code would be required to make it work on Apache 2.4. I have very little experience with mod_perl, so I'm not the right person to explain what these changes would entail.
I didn't think Perl was especially difficult to understand, so I don't think the problems are necessarily inherent to the programming language, except for the mod_perl dependency. The code is divided into several modules (https://github.com/SoylentNews/rehash/tree/master/Slash [github.com]), which is a reasonable design decision. But that also means that there needs to be some documentation on what functions are provided by each module and how those functions are expected to behave.
If I write a class in C++, any code using the class doesn't really have a need to know how the class works or the details of private functions and variables. However, I do need to define the expected behavior of public and protected functions and variables. It means that I know exactly how to use the class in other code because I know what the functions and variables do, and how they're expected to work. Having a well-defined interface also means that as long as I don't modify the expected behavior of the existing interface, I can update the class without breaking other code that depends on the class. I don't believe those sorts of well-defined interfaces and relevant documentation exist for Rehash. It means that if I start modifying how one module works, I have a high risk of breaking things elsewhere in the code. Similarly, I don't think there's a whole lot of documentation on what is actually stored in the database.
I think that if you work with Rehash enough to become familiar with what various parts of the code do, it's probably something that can be maintained. But an important first step would be to go through and properly document the various modules. I suspect that doing this and updating Rehash to work with Apache 2.4 would require a significant investment of time.
I don't think there's anything inherently wrong with Perl, though I don't really use it for any of my projects. When I looked over the code, my biggest concern was understanding how all of the pieces of the code fit together, how each module is expected to behave, and what all the tables and fields in the database do. This is just my opinion, and like I said, I have very limited experience with Perl. I could also be wrong about some or all of this, so other people might be able to give better answers.
EXTERMINATE
(Score: 2) by RS3 on Wednesday May 31, @01:38AM (9 children)
Spot on, on all fronts. I would not choose perl for a new project, but that said, I'm not sure what I would use, as every "back end" scripting language has pros, cons, becomes "viral", becomes "deprecated". IE, there's no such thing as "future proof", so I'm not sure how one would decide.
I know php is both loved and hated. Most of the haters are latched on to 20 years ago. A huge percentage of the web runs on php, so it can't be all that bad. I've been admin some servers including WordPress so I know some php, certainly setting it up, "tuning" it, etc. Current WordPress runs well on a very wide range of Apache, php, and mysql versions, so it is possible to have code that isn't too terribly version picky.
Again, everything you said about rehash, and another big problem is with mysql calls and lack of compatibility over versions. I don't know who (what kind of person) gets involved in a project like mysql, and decides it's okay to break older calls in a version update. I'm okay with augmenting function (method) calls, but flat-out breaking something is stupid.
Back to the original point: I'm doing a few quick searches and I can't get a solid picture of whether fastCGI is better than mod_perl.
Just as a very general statement: I'm not fond of people saying that something is "unmaintained". It might be that it's done and ready for use. :) We're all so overly used to being the beta test for pretty much all code, and we're all paying the price for it. I'd rather a global paradigm of code being tested properly before shipping. I know that would be difficult to do, economically, because things have eroded to where they are (especially MS OSes- more and more and more frequent and bigger and bigger updates). For sure, if something is in use, has problems, and the company / author isn't developing / maintaining / even reachable, then that's a problem, and since that's always a possibility, we're all nervous to use something that seems stale. But again, it might be mature and pretty solid, and maybe check the bug list (if there is one) to see how bad it is.
(Score: 1, Insightful) by Anonymous Coward on Wednesday May 31, @07:18AM (8 children)
The main problem with mod_perl is that it is exclusive to Apache httpd. Also that apparently some amount of internal server details are leaked to scripts so you apparently can end up with programs that only work with specific versions of Apache httpd. If you're actually writing a new web service in perl, use something like PSGI so you don't need to care about the actual mechanism that connects your application to the web server.
An incomplete and mostly wrong history lesson is in order!
In the glorious days of yore, the World Wide Web is born. A bunch of people writing web servers get together and come up with CGI to enable the web to interface with other systems. Perl quickly becomes popular for writing CGI programs. Life is great and everyone is happy.
Some time later, Netcraft confirms that September 1993 indeed never ended. Web servers are buckling under weight of several hundred AOLers each getting their own perl camel to personally handle their requests. FastCGI, which despite the name is nothing at all like CGI, is developed in an effort to address this problem.
Perl CGI programmers revolt, FastCGI is too hard in mid-1990s Perl, and rewriting working programs is silly. So mod_perl is born, which can run normal CGI perl scripts but uses one camel for many requests and is therefore much less messy. Programmers being programmers, mod_perl is then extended with zillions of extra hooks and features to cater to various niche use cases.
Later, Apache httpd falls from grace and nginx rises as the new king of web servers. Religious leaders preach that mod_perl is the product of the devil, while FastCGI is given to us by God. Moreover, all remaining perl programmers have finished their grey beards and can't be bothered with the web anymore.
(Score: 2) by RS3 on Wednesday May 31, @02:33PM
I'd love to know who you are. I can't thank you enough! I started in Linux / web 1994-5 ish, including setting up some local / experimental web servers, but I tend to do many things, so I didn't specialize / immerse enough to get deeply into the subculture. I knew of perl and CGI, but just "played" to see that it works. More recently, 2008 and forward, used some Matt Mullenweg toys like "formmail", and they work. Most of what I've dealt with is php-based, WordPress, Joomla / Drupal, and several specialty market CMSes like one for real estate (I don't know what ever happened with that- I don't do sales, customer contact, etc.)
One of the servers is on one hand embarrassingly old hardware, but at the same time I'm proud of how well it runs and fast it is, because I'm a relentless preener / tuner. Anyway, I've experimented a good bit with nginx and I found it a bit strange to configure (of course one can learn and get used to almost anything) but the bottom line: no performance improvement at all. If admin was a full-time job (and I've tried) things would be different, but I'm in a "do as much as you can for as little time & cost as possible" situation, so I can't research and play like most full-timers can. And I have shrinking interest in it, as I've often invested time and effort in things that go away, like Novell and buggy whips (why would someone whip a buggy though?).
You probably know that php can get a poop-ton of info out of Apache. IIRC much of that can be disabled in Apache conf.
I hadn't heard of PSGI, off to study up. Thank you!!
(Score: 2) by RS3 on Wednesday May 31, @02:35PM (4 children)
BTW, do you have any thoughts / suggestions for a better language to run a site like this? (there is no wrong answer, just curious)
(Score: 3, Informative) by bmimatt on Wednesday May 31, @10:29PM (3 children)
I am not the AC ^^, but I'm in consulting business and have been recommending/deciding on language choices for a couple decades and your question cuts to the root of the Perl issue, hence my response.
Whenever trying to decide on/recommend a language for a new project, one of the key questions is: how big does the potential maintainer pool is today, will be in 5, 10 years; how easy will it be for you to hire/train new developers down the road.
Languages like Python, ruby or (the dreaded) javascript have large enough young developer pools. I'd seriously consider Rust and Go if a more industrial grade language is preferred.
(Score: 2) by RS3 on Thursday June 01, @12:29AM
So COBOL then? :)
Seriously, that's really good wisdom and almost sounds obvious now that you've stated it. I wasn't even thinking of Go or Rust for back-end, but pretty much anything can be back-end these days.
Sometimes I cast javascript in a negative light, but really it's what the browser and OS allow javascript to do that I see as a potential problem. At some point it's best to run a browser in its own sandbox / VM, with only data pertinent to that usage contained in that VM.
(Score: 0) by Anonymous Coward on Monday June 05, @08:05PM
> seriously consider Rust
At the risk of coming over crabby, nobody should be seriously considering Rust™.
(Score: 2) by replic8tor on Saturday June 17, @02:04AM
Javascript ( TS ) - probably the fastest way to add code to something - tons of libs - a bit of a mess to code with and easy to shoot in the foot. great for prototyping
Python - not the worst choice - cleaner than JS but perf wise probably worse
Ruby - other languages better in every way
Go - ehh a mess - pretty stagnant in terms of growth - smaller community than the above
Rust - Fixes a lot of goes problems - fast as f - great eco system - coding is slower but less debugging - growing community and adoption
(Score: 0) by Anonymous Coward on Wednesday May 31, @10:52PM (1 child)
Nice fanfic but FastCGI was released publicly after mod_perl.
(Score: 0) by Anonymous Coward on Tuesday June 06, @07:30PM
As it comes from a proprietary software product, the very early history of FastCGI seems a bit lost to time, but I don't believe it is accurate to state that mod_perl predates FastCGI in any meaningful way.
This whitepaper[1] is dated April 1996 and mentions that FastCGI support is available in Open Market WebServer V2.0. We can also find the "Open Market FastCGI 1.0 Programmer's Guide[2], dated April 15, 1996, which describes a C library to adapt your existing C programs and a modified perl interpreter needed to use their new FCGI perl module. I'm was unable to find an exact date when Open Market WebServer V2.0 released but it is presumably around the same time as all this documentation. It is almost certain that Open Market's customers had some early access well before this date, and probably there was some hype around it in advance of the release, but hard to know for sure. Could probably dig through usenet archives to find more.
On the other hand, Apache has a pretty detailed history article for mod_perl[3] which says that the first ever code published was in March 25, 1996. Yes, that is 3 weeks earlier than April 15, 1996, but according to that same article it wasn't really usable at all until August of that year, and it wasn't until March 1997 (a full year after the first postings) that it was even possible to use CGI.pm with mod_perl, which basically the point when people could actually consider switching existing perl-based CGI systems to mod_perl.
So yes, while people might have started working on mod_perl a few weeks before FastCGI support was shipping in a widely-available commercial web server, mod_perl was not really useful until a full year later when it could actually run people's perl CGI programs.
[1] https://web.archive.org/web/20000816193415/http://fastcgi.com/devkit/doc/fastcgi-whitepaper/fastcgi.htm [archive.org]
[2] https://web.archive.org/web/20001018200938/http://fastcgi.com/devkit/doc/fastcgi-prog-guide/cover.htm [archive.org]
[3] https://perl.apache.org/about/history.html [apache.org]
(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.
(Score: 5, Interesting) by carguy on Tuesday May 30, @04:27PM (25 children)
"Those who cannot remember the past are condemned to repeat it.” – George Santayana.
Turns out that the past I remember was only three years ago, and might be a good place to start from?
My first question: Whatever happened to the previous Privacy Policy that used to be at the bottom of every page? Anyone??
Reference & further details can be found here: https://soylentnews.org/meta/comments.pl?noupdate=1&sid=36203&page=1#commentwrap [soylentnews.org]
Has enough changed in three years that the statement quoted above needs revision? Or just reinstatement?
(Score: 3, Insightful) by quietus on Tuesday May 30, @04:59PM (1 child)
I follow carguy in this -- the quoted section in his post is all we need for [a concise and clear] privacy policy.
(Score: 2) by bmimatt on Wednesday May 31, @10:31PM
+1
(Score: 0) by Anonymous Coward on Tuesday May 30, @06:56PM
Slash logs a hash of the users IP address [nortonrosefulbright.com] with comments, that could (potentially) be decoded using a rainbow table. The old policy, May not pass muster [iapp.org]
My position was always the business (web site) sets jurisdiction. Once you get legislatures deciding a resident visiting a second state is somehow governed by the laws of the first, we've descended into farce. IANAL
(Score: 0) by Anonymous Coward on Tuesday May 30, @09:42PM (11 children)
The site should be clear AC comments are linked to the logged in user account, and user accounts have their IPs stored forever. Staff should be prohibited from sharing hashed IP information, and even hashed IP info should be expired. AC should be removed entirely, make it easier to close down problematic accounts.
(Score: 2) by janrinok on Wednesday May 31, @06:22AM (10 children)
They are not linked. That does not mean that they cannot be determined.
Technically it is expired. It lasts on the server for about 2 weeks but I am told this is not a hard limit but one that is dependent upon usage. So knowing that somebody used an IP address several weeks, months or even years ago is nothing that we could use to identify them. Perhaps LE can - but we cannot.
(Score: -1, Troll) by Anonymous Coward on Wednesday May 31, @10:04PM (9 children)
You already admitted that logged in users have their IP stored indefinitelu, and that any AC comments they make are tied to their account. You should stop misleading people, and you should stop abusing your privilege. Seeing the weird mind games you staffers play is a real education on levels of trust and transparency. You fail pretty hard on both counts, and khallow and runaway appear happy, so you've got that going for you.
(Score: 2) by janrinok on Thursday June 01, @08:02AM (8 children)
No, they have a hash stored indefinitely. The site has no software for reversing the hash - there are no rainbow tables etc. In any case, VPNs, TOR and IPv6 have negated their effectiveness. There are discussions on the web about it.
Wrong again - nowhere have I stated that we can do that in all cases. We cannot link some AC accounts to the actual user. Under certain conditions we can. I am not going to discuss a potential security vulnerability here.
(Score: 0) by Anonymous Coward on Thursday June 01, @09:36PM (7 children)
"Under certain conditions we can. I am not going to discuss a potential security vulnerability here."
Certain conditions: the user is logged in and selects Post as AC when making a comment, or the user is not logged in but using a unique IP. The unique IP bit you have a real problem with since you make incorrect assumptions
Potential security vulnerability: bullshit, you don't want registered users to realize their AC comments are anything but anonymous to site staff
(Score: 1) by dalek on Thursday June 01, @10:07PM (6 children)
Directing antagonistic comments toward staff members isn't furthering the discussion. What specific concerns do you want me to raise in further discussions? Here are a few that come to mind:
1) Should hashed IP addresses be used to distinguish users from each other? Are there better identifiers than hashed IP addresses?
2) How long are identifiers stored in the database? Should they be purged after a certain amount of time? If so, how long?
3) Who can see this information? Is it automatically displayed, or does the person viewing it have to click through to see it? If it's only displayed upon specifically requesting it, is that request logged? If the user is logged in, does the user get a notification that this information was accessed by a staff member?
4) If the identifier is the same between an AC comment and a logged-in comment, it suggests but does not guarantee the same person may have posted both comments. If staff are aware of which logged-in user posted an AC comment, what information are they allowed to post publicly about this? Are they allowed to say that they know who posted a comment, or would that intimidate the person who posted said comment? Are the allowed to initiate private communication (e.g., email) with the person they believe posted the comment? Are they allowed to discuss any details of the comment history, such as suggesting that a comment may have been posted in bad faith?
5) How are staff held accountable if they improperly share information? How are these policies enforced?
These are all things I'm willing to discuss in a forward looking context. There's nothing we can do to change what's happened in the past, so dwelling on that doesn't help anything. Antagonizing staff, regardless of your opinions of specific staff members, does not help either. What topics do you want discussed with respect to the new privacy policy? Are the questions I listed things that you want to discuss? Do you have different questions that you want discussed?
I certainly support asking the tough questions and discussing all of these issues with respect to a future privacy policy. Let's not argue with staff members and instead focus on what issues need to be raised to better respect privacy going forward. I want to continue the discussion but in a way that's productive rather than dwelling on the past.
As Mike Ditka once said, "The past is for cowards... you live in the past, you die in the past." Let's focus on the future.
EXTERMINATE
(Score: -1, Troll) by Anonymous Coward on Thursday June 01, @11:27PM (1 child)
Since when is antagonism opposed to robust privacy? It appears that you are a janrinok sockpuppet, dalek. Prove us wrong.
(Score: 1) by dalek on Friday June 02, @03:39AM
I didn't say it's in opposition. It's tangential. I'm trying to keep the discussion on track.
I replied to an AC's comment and said that we should focus on the privacy issues instead of discussing issues with staff. I have no doubt that the AC is very sincere in having concerns about user privacy on SN. I'm just trying to keep the discussion focused on those privacy issues and away from getting distracted on tangents about staff. That's why I suggested many potential privacy issues that might arise, asked if they were concerns the AC had, and asked if they had anything else I should add to my list. I'm trying to get a list of privacy concerns that we can address later.
Do you have any concerns that you'd like to add to my list? This is not about specific people. It's about future policy for the site.
For example, let's say that I set up my home router to use a VPN for all outgoing connections. If I post a comment to SN, the hash that's recorded will be that of one of the VPN's servers. If I post from an account, that hash is linked to my account. The account might also have an email address that identifies exactly who I am. Let's say that the comment I post is completely legal and absolutely harmless. But if someone else posts an AC comment using the same VPN and server, the same hash will also be recorded. Let's say the other user posts instructions for decrypting content that uses Microsoft's PlayReady DRM and how to download videos from some sites that use PlayReady DRM. That could cause some issues for me if the lawyers for that site decide they want to sue the person who posted those instructions. The situation I'm describing is fairly similar to lawsuits about DeCSS around 20 years ago. If you were around Slashdot in that era, you probably remember that DeCSS was a frequent topic of discussion. Even if staff consider hashes unreliable for linking AC comments to accounts, it doesn't mean that lawyers, courts, or juries would reach the same conclusion.
I support discussing things like hashed IP addresses or other identifiers and how long that information is retained. I just want to keep the discussion focused on privacy concerns and not on the staff.
EXTERMINATE
(Score: 0) by Anonymous Coward on Friday June 02, @02:46AM (3 children)
> 2) How long are identifiers stored in the database? Should they be purged after a certain amount of time? If so, how long?
I'll chime in on this. I'm assuming there is some utility in keeping the identifiers around when a story & comments are live--for example something must be used to block adding more than one mod point (per user) to a post?
However, after an article ages, at some point the comments & mod points are locked, which seems like a good thing, prevents future meddling. Anyone wanting to continue that topic can submit a new story or start a journal.
When the article is locked, then delete the identifiers from the database. What possible future use could they have?
(Score: 2) by janrinok on Friday June 02, @05:15AM
The IPs are not saved any longer than approximately 2 weeks, depending on memory availability in the server I think. In many cases they will point to a VPN, TOR exit node or some other system of privacy/security redirection. However, IP addresses are essential. They are the key to the whole internet, and are vital when blocking some types of attack on the site. They will still exist and be used by this site.
A design decision made over 25 years ago initially linked comments, submissions etc directly with the IP address. Cmdr Taco did not want to work with IP addresses - they were cumbersome in software terms and used more computer processing. The state of computing 25 years ago was very different from today. He decided to use hashes derived from the IP addresses which could then be used directly in the database. He writes about this in the code which you can download and access freely. It was not intended to be a security measure. It is not a tracking measure. It is a form of indexing within the database itself.
Relational databases thrive on hashes. Data that is in the database is linked using those hashes. This cannot be undone simply. Much of the Perl code is written around those hashes, as far as I can tell.
Undoing this design decision would require, I imagine, a complete rewrite of all the Perl code (and we can't even do bug fixes!) along with a reformatting of the data in the database, or scrapping it altogether. If the code is to be rewritten it will NOT be in Perl.
(Score: -1, Troll) by Anonymous Coward on Friday June 02, @08:05PM (1 child)
Janrinok lies or at least attempts to deceive once again!
So either the hashes are tossed after a few weeks or they are kept forever because the relational database needs them. Which is it?
Previous statements were that the IP is always hashed, never stored fully as implied in the first sentences, and true not logged in AC comments were the only ones where the hashed IP gets dropped after two weeks. Every action by a registered user is tracked. Janrinok's intentions do not matter as they could shift, like they did many months ago when he started calling every critical AC aristarchus.
He is still downaying the tracking done by the site, though I accept it was not added maliciously. Why not be up front about these technical details? Only by piecing together the info, then repeatedly pointing out the problems finally dragged enough details from frustrated staff. One staffer admitted there were some strange database flags causing moderation bans, some admissions about how hadhed IPs are stored, including that the hash hadn't changed so IP hadhes since site launch are available for every registered user.
Why does janrinok try and downplay that fact?
(Score: 0) by Anonymous Coward on Monday June 05, @02:07AM
They are playing word games with IP and hashed IP. HONEYPOT?
(Score: 3, Insightful) by dalek on Tuesday May 30, @10:42PM (1 child)
I'll speak up to answer your questions.
What happened to the previous policy? When the site was rebuilt in November, quite a few things were lost during that process, including the privacy policy that had been at the bottom of every page. While I don't know the technical details of rebuilding the site, that's when the privacy policy ceased to be displayed on every page. Its removal doesn't reflect a change to how SN handles user data.
Why do we need a new privacy policy? The privacy policy that you remember was written to address specific requirements in California law, which I believe requires a "conspicuous privacy policy" be displayed. A new privacy policy can cover additional issues that go beyond just what California requires of websites. There's been quite a bit of discussion about migrating SN away from Perl code that's almost 25 years old. A lot of the decisions on how data is handled by the site were baked into the Perl code when it was originally written for Slashdot, and they may not have been particularly easy to change after a large code base had been written. If SN moves to a new code base, there's an opportunity to make design and implement the site's code with different and stronger privacy considerations. A couple of ACs replied to you, and they discuss hashed IP and subnet addresses in SN's database. That wasn't really covered in the previous privacy policy, but their comments are very welcome here, and issues like that are absolutely open for discussion.
EXTERMINATE
(Score: 2) by RS3 on Tuesday May 30, @11:22PM
I'm sure most of you know that most webpages are an assemblage of stuff from many sources, very often including database. As again most know, this site is written in perl which stores and retrieves data (content) from a mysql database. When the site crashed last fall, (and NCommander did some restoring, rebuilding, and updating) one of the biggest problems was database crash, and loss of some data. I don't know for sure, but I'll speculate that the privacy policy text was a database entry that got trashed, and one of many things to manually fix (once many other more fundamental issues are resolved).
(Score: 0) by Anonymous Coward on Wednesday May 31, @04:10AM
The two problems with that policy, which a number of people pointed out, are that it doesn't comply with California law nor is it accurate. Which I suppose is to be expected when it is written by a reactionary contrarian.
(Score: 3, Informative) by janrinok on Wednesday May 31, @06:02AM (6 children)
It disappeared in Nov 2022 when there was a crash and the code was recovered to a different version. For what it is worth, Im guessing that the privacy policy statement - which has NOT changed - was not fully integrated into the previous version template .i.e. it was an undocumented change.
We have always been entirely open about that. We track usernames and user ids all the time, and the whole package uses hashes (in exactly the same way as every other database indexing mechanism). Cmdr Taco writes about it in the code - they used to display raw IP addresses. The hashes were NEVER a privacy feature - they simply made processing and indexing the data easier.
(Score: -1, Troll) by Anonymous Coward on Thursday June 01, @05:23PM (5 children)
Sounds like you are referring to sock puppeting, there are no AC accounts??
Does not matter, previous discussions were clear that a logged in user's ID is tied to any AC comments they make while logged in. So either you are being /tired again or you have some reason to try and reassure users that you don't frequently see their AC comments.
The biggest failing of SN is saying it cares about privacy, then failing to educate users. The implication is clear that the site does not track you and worst case an email address is exposed. While mostly true you still collect IPs, a needed ability for some site functions, but you fail to disclose how the IP is tracked. With basic location services you could easily track a regular visitor that is not using TOR or a VPN to general physical locations.
Not to mention all the fuss about rainbow tables rebuilding the real IP, so many denials then finally admitting yes it is possible and likely since the hash mever changed. Why would you actively hide this type of information? Now you pretend that explaining how you can track people in some situations would reveal a security vulnerability?
Astounding
Right now I think you are building tables of IPs to narrow down the range used by certain users and you're still getting false positives. Regardless, the fact you are spending so much effort and allowing spam abuse for critics says everything we need to know. Doubly so since any complaints about other shit posters was met with "that is what community moderation is for" while removing any spam mods. Now they are allowed because you don't like criticism, but last I checked that would fall under offtopic.
Not sure you can regain trust at this point.
(Score: 2) by janrinok on Thursday June 01, @07:09PM (3 children)
You are referring to a discussion in another story. If you are going to do that 1. your comment is Off-Topic here, and 2. you should also have the decency to quote the replies.
But I expect such thing from you.
(Score: -1, Troll) by Anonymous Coward on Thursday June 01, @07:26PM (2 children)
Decency got tossed when you allowed rampant mod abuse, sock puppeting, and stochastic terrorism while happily targeting users that sound like aristarchus. It is just sad to see such normalized fascism hiding behind the concept of community. It is only a "free" community az long as members abide by a subjective set of social rules, on top of which those rules are selectively applied! Deny and downmod is all you have, except removing AC comments entirely, but then you'd lose a useful foil and users probably would not feel safe using the "post as AC" option. Which they should not since you admitted such AC comments are linked to the username #Facepalm
(Score: 2) by janrinok on Thursday June 01, @07:53PM
(Score: 1) by dalek on Thursday June 01, @08:03PM
I am posting this as a reminder of the ground rules for this discussion:
If you have concerns about whether site policies are applied evenly, I can respect that as a relevant privacy concern. If you said that people can let their personal matters cloud their judgment, and that you would want enforcement to be done by someone who is more dispassionate, I can respect that as well. If you believe that AC comments should be removed entirely, that is also a privacy issue that can be put up for discussion. If you're concerned that AC comments aren't sufficiently anonymous, that is also a valid concern that can be addressed. All of these matters are certainly valid concerns, and I am more than willing to entertain discussion of them.
However, those points can be made without referring to specific individuals, dwelling on past decisions made by the site management, posting personal attacks, or bringing politics into the discussion. I have noted your privacy concerns and will ensure that all of the actual privacy concerns are brought up for discussion in subsequent journals about this topic. Now please follow the ground rules I have posted.
EXTERMINATE
(Score: 2) by janrinok on Thursday June 01, @07:11PM
(Score: 0) by Anonymous Coward on Tuesday May 30, @07:47PM (1 child)
The old privacy policy said:
My questions are
1. When someone pays for a subscription using Paypal or Stripe, what personally identifiable information is passed to the organization. How much of that data is retained and for how long?
2. I'm not sure if it's mentioned on the main pages anymore but there's a SoylentNews swag store on zazzle. If someone buys items on there, again, what personally identifiable information is passed to the organization. How much of that data is retained and for how long?
Whatever the answers are or if they change in future, they need to be considered. If someone requests what data is stored, these things might need to be included. It's also best to look at whether any of the above data are being held unnecessarily and stop it.
(Score: 0) by Anonymous Coward on Monday June 05, @08:40PM
This is why I have never given money to SN, couldn't trust that my identity would not be compromised. Thanks to some other soylentils who made contributions in my name, as that only put them at risk.
Janrinok's plan to have phone #/credit card based identification, along with the biometric multi-factor discombuberation, is a non-starter, for a site concerned with free speech, and the anonymity that free speech requires. #FreeAnonymousCowards!!!!!
(Score: 2) by Tork on Tuesday May 30, @08:17PM (8 children)
Btw my enthusiasm for this suggestion isn't very high, again I've been pretty happy with how AC comments have generally been handled. I'm not bringing it up because it's a show-stopping issue or anything like that. I am curious if there are other approaches sites have used.
🏳️🌈 Proud Ally 🏳️🌈
(Score: 2, Interesting) by Anonymous Coward on Tuesday May 30, @08:54PM (7 children)
That has been done on anonymous imageboards before. You could add the story ID before hashing to make it unique to only 1 discussion. Doesn't slow down ACs who can switch VPNs and TOR nodes. The DICK NIGGERS will inevitably follow. It's a matter of scale. SN was spared the worst of the worst because it was smaller.
(Score: 1) by dalek on Wednesday May 31, @12:18AM (6 children)
I know that sometimes comments containing slurs have been moderated as spam. I don't know the exact reasoning that the parent picked up a spam mod, but I think that's a good possibility. The comment is actually referring to a crapflood that took place in 2017 [soylentnews.org], where that text was repetitively posted in a large number of comments. I believe the parent is suggesting that many anti-spam measures designed to distinguish various anonymous commenters from each other can and will be circumvented just by changing the IP that posts the comment. I believe that the parent comment was posted in good faith. For that matter, I believe the person who issued the spam mod acted in good faith, and they might not be aware of the relevant context. In the interest of transparency, I want to acknowledge that I've emailed the admins to ask that the spam mod on this comment be reviewed.
EXTERMINATE
(Score: 0) by Anonymous Coward on Wednesday May 31, @01:17AM (3 children)
It was modded appropriately because it was used as an opportunity to repeat the slur. Interesting comment you made dalek.
(Score: -1, Redundant) by Anonymous Coward on Thursday June 01, @03:09AM (2 children)
Shut the fuck up, bitch.
(Score: 0) by Anonymous Coward on Thursday June 01, @05:14PM (1 child)
Haha if ever there was more proof needed we've got Limpdick McGee here with Andrew Tate levels of cringe.
(Score: 1) by dalek on Thursday June 01, @07:47PM
There are ground rules in this discussion, specifically:
This is a reminder to everyone in this thread to keep the discussion civil and welcoming.
EXTERMINATE
(Score: 2) by janrinok on Wednesday May 31, @06:09AM (1 child)
(Score: -1, Redundant) by Anonymous Coward on Thursday June 01, @07:11PM
Performative bs at its finest!
(Score: -1, Offtopic) by Anonymous Coward on Wednesday May 31, @01:08AM (6 children)
I find your transactional approach amusing. Do you apply the same thinking towards sexual intercourse? Staff are not a stakeholders, they are servants, albeit voluntary ones. Having an Editor who doxxes ACs is not acceptable. Having a system that allows such abuse is even less acceptable.
(Score: 0) by Anonymous Coward on Thursday June 01, @11:36PM (5 children)
How is this offtopic? Editors violating privacy of ACs is the main issue in this discussion, regardless of what you think.
(Score: 2) by janrinok on Friday June 02, @06:19AM (4 children)
(Score: 0) by Anonymous Coward on Friday June 02, @07:47PM (3 children)
It would be more helpful for you to add ideas on how to give the community transparency on site operations, or some level of trust. Here are two.
1. Make moderations public. Not great because it would add to community drama and maybe discourage downmodding, but then mod abuse would be easier to see. Run polls to get community feedback on whether someone's mod history is abusive.
2. Make the spam moderation report page public, spam mods cause real IP bans and karma hits, make someone stand behind their decisions and make it easier for anyone that cares to monitor for abuse.
Got anything useful besides victim blaming?
(Score: 3, Touché) by janrinok on Saturday June 03, @06:06AM (2 children)
It would also encourage retaliation by those who have been moderated adversely, and by their friends and/or alternative accounts.
In the last few weeks I have been contacted by several community members who have had to change their account nickname and uid because of 'account stalking'.
Some community members in the recent past have left quoting the harrassment that they are receiving as being the cause.
(Score: -1, Troll) by Anonymous Coward on Saturday June 03, @07:04AM
You say this as if it was not what is already occuring, or as if it would be a bad thing. I am going to spam mod this post, because it seems like something aristarchus would post, to sew disruption and malarky on SoylnetNews.
(Score: -1, Spam) by Anonymous Coward on Monday June 05, @09:14AM
Take a look at aristarchus' pentultimate journal entries, when janrinok initiated the mod-bombing upon him. Cowards always want to work in the shadows. Assignable moderations is a good idea. Then we will know when it is janrinok downmodding, and claiming it is the nebulous "community".
(Score: 3, Informative) by pTamok on Wednesday May 31, @07:19AM (3 children)
You legally need to comply with the privacy requirements of the state and/or State you are incorporated in, and anywhere you have infrastructure controlled by you.
Once you have the legal requirements covered, you can fill in the details. But it is important that you know what the legal requirements are. And be ready for the fact that they can (and do) change.
Little things like: how to process a subpoena. How to process a National Security Letter. And so on. Lavabit shut down over privacy issues [wikipedia.org]. You may not even have the option of triggering a Warrant Canary.
Mullvad VPN famously have a 'log nothing' policy [mullvad.net]. That's a bit difficult to do when running a forum, rather than a VPN, as people like to identify with 'handles', and some way of managing the troublemakers is needed.
You also need to think about the privacy policies/regulations of places you wish to provide your services to. If you intend to provide services to people residing in Europe, you must comply with the GDPR*. That is not difficult, as the main idea in the GDPR is to minimize the processing and storage of Personal Data to the least necessary, which is in line with what you want to do. Advertisers wanting tracking info are not so happy.
Personally, I'm happy with logging with data retention for a limited period for the intended purpose of managing the site and dealing with troublemakers. The data would be available to law enforcement/national security with a properly served legal request (judge authorised warrant, NSL etc, not just an 'official' fishing with no good cause that stands up in court (I'm aware of after-the-fact parallel construction [wikipedia.org])). Minimising data collection and storage while keeping the site manageable is the main thing. How anonymous should 'anonymous' users be? Do you want people to be able to start posting base64 encoded images of child abuse, or threats to the life of the U.S. president while remaining untrackable? If not, where do you draw the line, and how do you intend to enforce it?
My recommendations are:
Privacy/anonymity ends when you hit the limits of free speech. And despite any personal feelings, society has a pretty good way of telling you where 'it' thinks those limits are.
*If you have no economic presence in the EU/EEA it's a bit difficult to sanction you, but it doesn't stop the requirement. You can choose to not provide services to European residents, but it is a large market.
(Score: 3, Informative) by janrinok on Wednesday May 31, @11:56AM (1 child)
The responsibility for those and similar issues rests with the board - the legal entity managing the site. They are not something with which the people maintaining the site should be concerned. There is a post for a board secretary for this purpose. The previous incumbent had to step down many years ago. The board never replaced him. I think that we have a volunteer for this role (separatrix) if we are not talking at cross purposes. But that is something for the new owner to decide.
If Intel, GMC or Meta are served with a subpoena or NSL I can guarantee that they don't pass it to a sysadmin, programmer or an editor to resolve the matter. The managers should manage - the remainder of the volunteers have specific jobs to do.
(Score: 2, Informative) by separatrix on Wednesday June 07, @04:13AM
I can't volunteer for a position whose definition I don't know yet. In addition to not being a coder, also IANAL, so I'm not sure what that role might entail.
We're not talking at cross purposes. I'm definitely here to help. But, yeah, I want to see the ownership issues settled, and a governance model with checks and balances implemented before I volunteer for a role like that.
(Score: 1) by pTamok on Sunday June 04, @07:40PM
I'll just add that if you choose to comply with the European GDPR then the definition of 'Personal Data' is a little different than the American definition of 'Personal Information (PI)'
European Commission: What is Personal Data? [europa.eu]
...
If you follow the GDPR's requirements, you will probably be in good shape for the rules covering the processing of personal data worldwide, possibly with a few tweaks.
(Score: 3, Informative) by NotSanguine on Wednesday May 31, @07:12PM (1 child)
I adapted the below policy from one I created for a non-profit website I created and managed for some time. Since I adapted it from a site with different needs/requirements, the policy is incomplete and will require additional modifications in order to represent the ideals and interests of SN. But it's a (and, a good one IMNSHO) start.
dalek and SN management/staff/assignees: Please feel free to use the policy below, in part or in full as you feel appropriate.
New SoylentNews Privacy Policy v0.01
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 1, Insightful) by Anonymous Coward on Thursday June 01, @04:43AM
That is a good start but isn't really up to muster. You should align it more with how the big boys do it. Make sure you only have one subject of your policy: privacy (Why are you even mentioning copyright/removal policies, warranties, hold-harmless, using other "contract-sounding" phrases, or forcing them to "agree" to anything, in what is supposed to be a statement of policy not an agreement?). One thing to keep in mind is that if there is room for interpretation of the privacy policy, it will be used against you. Instead of numerous footnotes, put a definition section right up front; if there is any wiggle room in the connotation of a word or phrase, then lock down the denotation in a definition section. Add "reasonable" everywhere so that way you aren't on the hook (e.g. are you REALLY going to take EVERY effort to protect information?) Same with the use of other universal statements because a number of them are flatly wrong because there are applicable exceptions to them. Also, decide on whether personal information is or is not stored, two paragraphs literally state the opposite. Finally, the policy itself doesn't comply with a number of applicable laws, including CCPA, GDPR, and COPPA.
(Score: 4, Insightful) by Mykl on Thursday June 01, @01:10AM (37 children)
I appreciate that many users of this site are strongly privacy-focused. I need to disclose that I am probably on the lower end of the scale when it comes to privacy concerns on this site, as I live in a stable democracy (i.e. not the USA) where it is legal to post opinions that disagree with the government. I feel I am in no danger of being disappeared or persecuted based on anything I say online.
IMHO, privacy concerns on this site were much more relevant when the conversation was a lot more political. These days, most articles are tech-focused and unlikely to offend powers-that-be. Having said that, there is always the possibility that conversation of a sensitive nature will occasionally turn up in articles or journals.
I am OK with the admins having short-term access to IPs being used by logged in users and ACs for the purposes of avoiding spam / bots / sock puppets / griefers. I would also extend that to identifying characteristics (browser type, OS, CPU type etc) - again stored for a short time only.
I would expect that this information would not be used for any other purpose, and that the admins would agree to a code-of-conduct reflecting that. Obviously this means that we need to place a certain level of trust in our admins. If a user is not comfortable with that then I would argue that this is not the place for them.
Having a truly 100% anonymous site is not practical - it's far too easy for griefers to grief, and we can all remember some of the less savory characters that have abused our goodwill over the years. I'm tired of griefers constantly crying persecution, and frankly don't care what their opinions are - all I'm interested in are the opinions of genuine users of this site (whether logged in or AC). As mentioned above, some of those users may hold strong opinions about privacy, which I welcome to the debate.
I doubt that this site will ever be big enough to draw the attention of a three-letter-agency, but those who are worried about this may benefit from a 'canary' statement put out each month (e.g. If no TLA requests were made, publish a statement to that effect. If the statement is ever missed, then a TLA has by definition made a request).
In terms of email addresses, anyone who is security-sensitive is unlikely to have used their real email address to register for the site, so I don't really have any issues with admins being able to see email addresses of logged in users.
(Score: 0) by Anonymous Coward on Thursday June 01, @02:50AM (36 children)
As someone that has been targeted by hate groups even your IP can be a big deal. I have been DDoSd, hacking attempts, and followed for harrassment until changing accounts. Not the end of the world, but what if someone truly unhinged got my IP and enough informatiin to find me? Runaway's alleged doxxing was taken very seriously, but it seems like true privacy and security is not a concern for those managing SN. Staff have shared hashed IPs freely, and the hash is not only weak but has not changed since the site launched they say.
In the US we have conservatives committing terrorist violence, and one suppised US user here is on record saying he'd like to murder liberals. They have suffered no punishment from the site, and in fact seem to be friends with some staffers. Hope you used a throwaway email to sign up!
(Score: 2) by janrinok on Thursday June 01, @08:32AM (31 children)
I disagree. It has usually been the recipient of the email who has compromised his own hash by publishing it in a comment on this site. In fact, if you look closely, they have usually added invalid characters into the hash while maintaining the correct hash length to prevent any reverse hashing.
I have occasionally pointed out that 2 alleged different ACs are in fact the same person but not the information that we needed to make that link (which need not be the IP hash). This is to prevent abuse by appearing to have more support for a particular viewpoint than is in fact the case.
(Score: -1, Offtopic) by Anonymous Coward on Thursday June 01, @10:20AM (3 children)
Janrinok the Accuser! Preventing privacy abuse on SN, by committing it first! The best defense is offensive! We had to destroy SoylentNews in order to save it. Isn't that the way they say it goes. But forget all that, and give me the number, if you can find it.
(Score: 1, Offtopic) by janrinok on Thursday June 01, @10:42AM (2 children)
The number to what?
(Score: 1, Offtopic) by janrinok on Thursday June 01, @11:02AM
I have moderated them all as Off-Topic, including my responses - because that is what dalek originally ask for when introducing this discussion.
(Score: 0) by Anonymous Coward on Friday June 02, @02:52AM
Operator?
Jim Croce
(Score: -1, Troll) by Anonymous Coward on Thursday June 01, @05:21PM (8 children)
Hahahahahaha
Ok, now unmask all of the sock puppets you've found and the users' main account. No personal info needed so by your standards no reason not to. What a load, and blaming your bad actions on some AC unmasking themselves is an obvious deflection.
(Score: 1) by dalek on Thursday June 01, @08:32PM (7 children)
I would like to remind you of the ground rules for this discussion:
Please follow the rules I have specified.
If you have concerns about transparency and accountability for actions taken by people who have privileged access to user data, that is a valid privacy concern that certainly can be discussed. If you believe these actions should be reviewed by a third party such as a panel of community members who don't have privileged access, that could be put up for discussion. It might not be practical to do so, and one would have to ensure that those community members are trustworthy, but it is a valid privacy concern that certainly could be discussed. If you believe there need to be clear policies for revoking privileged access for anyone who does not follow the privacy guidelines, that is also forward looking, and is a reasonable topic for discussion. I am more than willing to discuss all of these topics in subsequent journals.
However, the purpose of this journal is not to criticize staff members for past actions. It is about developing better privacy policies for the future. Please follow the ground rules I have posted for this discussion.
EXTERMINATE
(Score: -1, Offtopic) by Anonymous Coward on Thursday June 01, @10:09PM (6 children)
Those who ignore history are bound to repeat it.
"However, those points can be made without referring to specific individuals, dwelling on past decisions made by the site management, posting personal attacks, or bringing politics into the discussion."
Only aristarchus was mentioned which is not a personal attack and is fair to mention since I am falsely accused of being aristarchus. If you want civility then it starts with staff and must be maintained. There are many spam mods I have received for making these complaints, which the entire community should see and are not spammed or frequently brought up outside already offtopic threads. No apologies or fixes for bad moderators makes me care even less about being more civil, so since you are requesting you (now staff) civilize first. Being in power and declaring rules based on personal bias is exactly what person B accuses person A of wanting.
As for politics, the bias has been clear for years of story selections. When staff stop allowing rightwing politics while banning leftwing topics with "that is what journals are for" then we can try ignoring politics. Your rules mean nothing when you feel self righteous in handing out spam mods for site criticism, so if person A is being targeted for spam mods then restore their accounts so you can stop making mistakes.
Yes all my points are valid, which is why they get repeated. Staff could shut me up by posting clear rules and honest technical privacy information like logged in user's ac comments tied to the username forever. Editor B is busy muddying the water with not-exactly-lies. Dalek you've been trying to remain civil, it is a hard task and I wish you the best of luck, but playing hardline authoritarian is not how to build a successful community of nerds.
- hopefully this was only posted once, so many similar posts by dalek I think this is the one that had a form error preventing submission
(Score: 1) by dalek on Thursday June 01, @10:26PM
I do appreciate your concerns and your frustrations. I'm trying to get actionable items that can be addressed going forward. Thank you for your kind words; they are much appreciated!
It seems like there's a trust issue between some community members and some members of the staff. One of the ideas I've been thinking over is community governance.
What if the community elected members to serve in various capacities, but those community members wouldn't have privileged access to the site? It could be a community advisory board to help define policy, whether that's editorial issues, amending the privacy policy, or any other matters that arise. They might help with conflict resolution, when there are concerns that a staff member might not have followed site policy. In that case, they would get access to the specific privileged information to determine the facts of the situation, but wouldn't have access to anything else. Community members might also be able to act as an appeals panel, if there's a dispute over something like a moderation ban. They wouldn't see any information except what's strictly necessary to determine the facts of the situation. We'll want to make sure there isn't an excessive workload for any individual, because these would also be volunteers.
I'm suggesting this in the hopes that community members might see this committee as their peers instead of staff members with privileged access. I don't know if this is something the community would even be willing to do, but I'll post it as a possible way to address these issues in the future.
I know this technically isn't within the scope of this journal, but I welcome feedback for this idea.
EXTERMINATE
(Score: 2) by janrinok on Friday June 02, @04:37AM (4 children)
dalek was asked if he would be prepared to undertake this role because he is not staff. He does not have access to any more information than you do. He is entirely independent. You couldn't be more wrong.
Why was he asked? We have received many emails from dalek over an extented period of time raising privacy issues and complaining about specific problems, all supported by well written arguments. He has strong views on the subject and he is keen to have privacy issues covered by some form of agreed document that we can all work to. He often holds our feet to the fire, but he does it correctly and we have intelligent discussions. dalek has done more to shape our views than all of the random complaints by ACs that litter otherwise intelligent discussions. We have made changes based on our earlier discussions, and you are referring to some events that happened in the past but not more recently.
As a result of these discussions, I believe that dalek can also appreciate the difficulties that we face in managing a discussion forum that is sometimes being abused to target specific individuals. That is not the purpose of this site.
You are missing the entire point of this journal entry. Lets get this sorted out now, before we end up writing any more software that makes the same mistakes that were made 25 years or more ago. We are prepared to consider dalek's findings and to try to produce an agreement that will clearly state what is acceptable and what is not.
This is the staff getting feedback from, and listening to, the community again - but a handful of you are failing to understand that. You are, in effect, silencing yourselves and the community.
(Score: -1, Spam) by Anonymous Coward on Friday June 02, @07:40PM (3 children)
Those discussions happened after years of these complaints being posted, glad someone finally took them seriously. We shall see if you can do better.
Your constant gaslighting where you merge the behavior of at least three separate people is your own act of witless evil. I get it, hard to deal with when they are AC. Too bad, registered user accounts aren't that much better since creation can be automated. That is the site's decision, you don't get to abuse people because your system is faulty.
I refuse to email you because these discussions should be done in the open, and there is no technical security vulnerability you would have to disclose to discuss these things. The clear fact at this point is you do not wish to let the community know just how much they are tracked and how easily admins can tell who made an "AC" comment, and you pat yourselves on the back saying users should already know everything about protecting their privacy on your site. That is usually fine, except when you champion freedom and privacy while allowing white supremacists cUz FrEE sPeEcH!@!#!$%%@!!
(Score: 1, Offtopic) by janrinok on Saturday June 03, @05:34AM (2 children)
We have been changing policy almost continuously to improve the site. We do it through consultation with the community (The Big Discussion [soylentnews.org]) which resulted in AC comments from people not logged in being removed from front page stories because the actions of a handfull of them were preventing the majority of the community being able to discuss topics intelligently. That policy change has been entirely successful.
This is another community consultation process, independent of staff control, to enable everyone to express an opinion.
Your comment is directed at an individual. Again you want to shout down those you disagree with to prevent them from expressing their views. You have made your statement. Repeating it will achieve nothing in this discussion.
Email me from a secure email account and if you want to discuss your problems like an adult. Your comment is Off-Topic in this journal entry. Hubie stated such in his introduction to the discussion.
(Score: -1, Spam) by Anonymous Coward on Sunday June 04, @08:03AM (1 child)
Well, thanks to Hubie for starting this forum! Except, it was dalek? Janrinok, are you alright?
(Score: 0) by Anonymous Coward on Sunday June 04, @08:46AM
Senior moment acknowledgement gets a Spam mod? OK, if there are no family members present, I will just back away from the hole situation.
(Score: -1, Troll) by Anonymous Coward on Thursday June 01, @07:16PM (16 children)
If you are comfortable pointing out which AC comments came from the same person why should anyone trust that you will not do worse in more private conversations?
(Score: 1, Offtopic) by janrinok on Thursday June 01, @08:02PM (6 children)
Because part of my job is controlling site abuse.
So you have nothing to substantiate that claim. FUD.
(Score: -1, Troll) by Anonymous Coward on Thursday June 01, @10:03PM (5 children)
You've made multiple false accusations, some lointless ones, and saying comments shared IP hashes does nothing to stop the spammer. It is not FUD to say we should worry about public abuses being worse behind closed doors. Interesting how you never provide details for your accusations and pointing out your false accusations gets spam modded. Totally above board, some say the most above board, you wouldn't believe the honesty folks! TMB was right, and the way I see you attacking NCommander is pretty shitty after all the whinging you do about being a volunteer getting harsh criticisms.
(Score: -1, Troll) by Anonymous Coward on Friday June 02, @10:23AM (4 children)
I think what everyone is trying to say, is that we need a privacy policy that is robust enough to withstand a rogue admin like janrinok. His witchhunt should not even be possible.
(Score: 2) by janrinok on Friday June 02, @12:32PM (3 children)
If you want to discuss me personally - send me an email. It works fine for dalek and other people. I welcome the opportunity to explain why things are the way they are. I have no objection of anyone criticising me - but stop disrupting other discussions. Personal attacks are Off-Topic.
(Score: -1, Troll) by Anonymous Coward on Friday June 02, @07:00PM
Disrupting? Curious comment from a privacy violator!
(Score: -1, Troll) by Anonymous Coward on Friday June 02, @07:18PM
It does not work for me, transparency is what is needed. The fact that you previously let slip that hashed IPs are forever stored for registered users, but now you're playing word games to not exactly lie but oush "hashed IPs are dropped after two weeks" when previously that was only for the general AC account. Anyone that pays attention would see these patterns, but most users only see a few if these offtopic discussions since you're so keen to downmod every single one but mever your offtopic replies.
Quite simply SN is run by admin abusing authoritarians that smear others for questioning authority and pointing out inconvenient facts. With human hive mentality it will take personal experience for each user to give these criticisms consideration. The lesson seems to be the same, anyone that appeals to authority and conceals problems should be treated as untrustworthy authoritarians.
The real eye opener was seeing you authorize targeted abuse which obviously did not prevent the spamming account creator, so why? Any future community should be built on trust and transparency. Seems to be the last thing paranoid libertarian techies want to do, gotta keep the tight fist of control!
(Score: -1, Spam) by Anonymous Coward on Sunday June 04, @08:07AM
Explain why things are they way they are, janrinok. Locked down, aristarchus banned, Runaway running away, khallow not being able to shut the up fuck. You think any of this is good for SoylentNews? You killed it, janrinok! SoylentNews has died under your watch. Time to just own up, and ride off into the singularity.
(Score: 1) by dalek on Thursday June 01, @08:22PM (8 children)
This is not a discussion about whether you have confidence in the staff. The ground rules say:
I do respect the concerns about 1) what information is stored, 2) who has access to that information, and 3) how that information can be shared. If you are concerned about the ability of staff in some circumstances to determine which users posted AC comments, and how they use that information, those are also valid concerns, and I appreciate them. I will ensure that these are brought up for discussion in subsequent journals.
Please limit the discussion to the actual privacy issues instead of criticisms of current staff members for past actions.
EXTERMINATE
(Score: 0) by Anonymous Coward on Monday June 05, @02:11AM (7 children)
Umm, no? Is that why you made a new journal, to bury the criticisms again? Personally all that is needed is honesty and apologies for bad community management. Sadly it seems SN is doubling down on tyranny by committee. Very musky.
(Score: 1) by dalek on Monday June 05, @07:09AM (5 children)
The new journal directly links to this journal twice in its first paragraph, and the first three words of the title are "Privacy policy updates." The new journal explicitly and conspicuously addresses this one, and it also explicitly encourages people to continue discussing the topics of this journal here. This journal had started to slip down the recent journals Slashbox, and the rate of comments had waned significantly. If anything, the new journal draws more attention to this one than it had been receiving. Moreover, I indicated that I would continue to review this journal and create a complete list of all the privacy concerns that have been raised. You have a very unusual and unique definition of what it means to bury criticisms. Also, the fact that I posted this journal does not prohibit me from also posting other journals to discuss other topics that are of interest to me.
Now, I fully support honesty and transparency. I think there are some misunderstandings of how Rehash works, but this can be addressed by properly documenting how the code works, especially in regard to user privacy. And I support summarizing that in the privacy policy in a way that's easily understood. There could even be an FAQ with questions about how the code works, with accurate answers. As I recall, there was an infamous thread on Slashdot investigating troll comments, and it picked up a vast amount of off-topic mods. Moreover, people who modded up comments in that thread discovered that they no longer had the ability to moderate. At least some of these criticisms were addressed in Slashdot's FAQ, with questions such as if editors can moderate. I should also point out that Slashdot had scripts to make users automatically post at -1 and to silently revoke their moderator privileges, the later of which was done at a large scale to people who modded up comments in the aforementioned thread. The editors also spent hundreds of their unlimited mod points in that thread. I support transparency and honesty, and that's a topic that will be up for discussion in a future journal.
As I stated, the criticisms of staff that you're referencing are off-topic in this journal:
The good news is that I have a solution to offer to you that will meet your needs. From your description, it seems that you'd like to have a journal with a topic that's outside the scope of this one. If your goal is to have a discussion about criticizing SN staff for past mistakes and to criticize the existing code, you have a way to do this, and to have it be completely on-topic. All you have to do is create your own journal that's dedicated to those specific topics. Because that journal would be posted from your own account, you could ensure that the only topics that are discussed are the ones that you want to discuss. If you want a journal to discuss topics that are outside the scope of this journal, why not create your own? If my journal isn't satisfactory for your purposes, what's getting in the way of you creating your own?
I wholeheartedly encourage you to create your own journal, express your criticisms of the staff and the existing code, and post it with comments enabled for everyone. Your criticisms will be displayed far more prominently than any of your comments in this journal. Your criticisms will get far more visibility, and the community can discuss those topics without any distractions like the code base or proposed drafts of the privacy policy. Why not post your own journal to make sure that your criticisms are as visible as possible, with no distractions at all? What's stopping you?
EXTERMINATE
(Score: -1, Spam) by Anonymous Coward on Monday June 05, @09:23AM (4 children)
Dalek's attempt to bury the "town hall" mysteriously coincides with a magical disappearing janrinok post to NCommander's journal, where he complained about SN's faults all being laid at the feet of "staff", or, him. I suspect puppetry of socks.
(Score: 1) by dalek on Monday June 05, @11:11AM (3 children)
I'm under no obligation to tolerate your behavior.
The current effort to develop a privacy policy is a genuine attempt to listen to the community's concerns and to be more respectful about privacy in the future. I am a volunteer, not even an actual member of the staff, trying to oversee this process. I fully intend to bring any actual privacy concern up for discussion, whether it involves transparency, logging and data retention, anonymous posting, the right to be forgotten, how to ensure that privacy is actually being respected, and anything that's remotely relevant to the topic of user privacy. I'm here to support privacy and to do right by the community.
None of this means that I'm required to stand by while you refuse to respect the ground rules of my journal or accuse me of things that are factually untrue. If I said I've had enough and walked away from this effort because of your abuse, it's very possible that you'll be stuck with the privacy status quo. I'd just like to point out that the status quo is something you've repeatedly said you strongly oppose. This is a great opportunity to do something about it and to have real and enforceable policies to protect privacy. But it means you have to play by the ground rules, and you haven't been doing so.
I'm not your property, and you don't get to make demands of me. I think it's important to have these discussions, but my volunteer effort to work on a better privacy policy does not mean that I can't talk about other topics just because they're inconvenient for you. Once again, you don't own me.
I fully intend to do right by the community, which encompasses everyone who visits and participates at SN. The community is not one or two people. It is everyone, regardless of whether or not I agree with their political views, share their interests, or get along with them personally. Everyone who wants to speak up on the topic of privacy deserves to express their opinions without being drowned out by your off-topic attempts to antagonize people. You're fortunate that this town hall doesn't involve everyone gathering in a meeting room to discuss their opinions. If it were, someone who behaved like you and tried to disrupt the discussion would probably be escorted out in handcuffs by the local police for disorderly conduct and would spend the night in jail.
If you have real suggestions about what the privacy policy should include or how it should be developed, I'm happy to hear you out. If you don't wish to discuss those things, then kindly go away. The next journal about developing a privacy policy will be posted about a week from today. There will be at least one more after that, and quite possibly more. If I see fit to discuss other topics in my journal during this process, topics such as motorsports, that's my right, and you have zero grounds to complain about it. Even if you don't care about the privacy policy, at least have the decency to stop trying to disrupt a process that will benefit many other community members.
EXTERMINATE
(Score: 0) by Anonymous Coward on Monday June 05, @08:46PM (2 children)
Dalek, just listen to yourself! Behave! Your story about the troll mod discussion is complete fabrication, a lie, in other words. You can demand compliance with janrinok's rules all you want, but you have no power here. (*Dalek turns into a large Snowy Owl*)
(Score: 1) by dalek on Tuesday June 06, @12:42AM (1 child)
Not a fabrication at all. Here's the thread: https://slashdot.org/comments.pl?sid=26315&cid=2850660 [slashdot.org].
And four years later, the thread was discussed in https://slashdot.org/comments.pl?sid=183628&cid=15166303 [slashdot.org], and at least one user reported that they were still banned for moderating in the first thread.
EXTERMINATE
(Score: 0) by Anonymous Coward on Wednesday June 07, @09:39AM
That would be aristarchus, then.
(Score: -1, Spam) by Anonymous Coward on Monday June 05, @09:20AM
In the past, it was common practice to displace journals where the alt-right was having its ass handed to it. Most of the time, a Runaway1956 journal would be immediately followed by a boring and technically inane entry by takyon. Did not really work, though, other than to telegraph their fear and desperation.
(Score: -1, Spam) by Anonymous Coward on Saturday June 03, @07:06AM
Janrinok disagrees, he does not deny. Obviously, the staff have done this. Oh, the Modulating Morphates!
(Score: 4, Interesting) by Tork on Friday June 02, @01:15AM (3 children)
If we're talking about the same post then the reason is that he wasn't serious about it, at least not in the sense that he was going to... for example, rise out of his chair and do anything at all. He's also claimed to have been a liberal that switched sides cos of severe meanie'ism, nobody's taking that seriously, either. I can't speak to the amount of friends he has here but I really don't think he's being shielded.
Bringing this back on topic- I do think the threshold for internet bullshit needs to be pretty high. Things have to get pretty extreme before stuff starts happening outside of the text you're reading, and boot-stomping from the staff can really perturb things. I was an admin for a small VBulletin site a few years ago and I often saw spats between users ending in attempting to weaponize the staff following policy. Besides, you'll have a high turnover rate if volunteer moderators/admins have to start babysitting.
🏳️🌈 Proud Ally 🏳️🌈
(Score: -1, Offtopic) by Anonymous Coward on Friday June 02, @07:31PM (2 children)
True, but then doxxing, a fully legal activityin the US, should have the same punishment. Was there a credible threat? Even staff didn't think so, so why does that get to weaponize staff?
I don't condone either posts, but the history of the site has many staff abuses. A few users left citing abuse from admins including journal deletion that included IRC drama, sock puppeters getting free reign, comments de-anonymized, and less obvious abuses like politically biased story submission approvals.
Soylent News's unique draw was the 99.9% free speech rule, with illegal activity being the limit. Some of the most heinous white supremacy and lengthy spamming of anti-semitism was proof enough, with staff saying the community moderation would handle it. Now site criticisms are allowed spam mods.
The lesson is that SN leadership is OK with white supremacy but not criticism of site policy. If you're fine tolerating racist filth and political terrorism I would think you could ignore repeating criticism, or at least demand staff update site policy to actually reflect what is allowed on the site and technically what information is stored.
Repeating because it is important, SN leadership is OK with white supremacy but not site criticism or personal mentions of anonymous usernames. There is 100% a code of conduct, it is just held in the heads of those with power.
(Score: 2) by janrinok on Saturday June 03, @05:52AM (1 child)
Well, in that statement you are simply wrong [soylentnews.org]:
(Score: -1, Troll) by Anonymous Coward on Saturday June 03, @07:09AM
Get better lawyers, janrinok! Preferably ones licensed to practice before the Bar in the jurisdictions you are controlled by. And spending SN funds on bad legal advice is ground for charges of malfeasance. Have you, or anyone associated with you, paid for substandard legal advice, knowingly?