Wikipedia's Notability Requirements And The Slash - <AUTHOR> http://sheddingbikes.com/posts/1297662169.html <comment><USER2> _You can literally read these requirements as "some big mega corp my grandma might encounter has mentioned it."_

This is spot on. I had to engage in a _battle_ on Wikipedia to keep the page up for dream hampton. Not everyone knows who she is, but she was the editor for The Source at one time, and ghost wrote Jay-Z's autobiography, among other things.

What I ran into is that Wikipedia basically demands that you get published in these megacorp publications that are basically all run by rich white people, and mostly men. So being written about in black publications, which tend to be more magazines and online publications, and less Library of Congress kind of stuff, doesn't cut it according to Wikipedia's notability "guidelines". If the white editors don't recognize the publication names, they don't "count".

The fact is, if she had been editor of Rolling Stone, I don't think there would've been a problem.

There were other factors too... being an editor and ghostwriter means she's more behind the scenes, and less likely to get outright exposure in the press. But that, too, is a requirement that I think turns Wikipedia into an amplifier of power, rather than a distributor of one.

I'm not sure if there was some outright racism going on too. I mean, she was mentioned in the New York Times and people were still calling for her page removal. At that point things start to get a little murky for me. But the situation was fishy for sure.

<comment><USER3> If you look at wikipedia's contributor stats it's like 70% white†, college aged males. (Actually wikipedians are like 87% male. [http://feministing.com/2011/02/02/why-are-only-13-of- wikiped...](http://feministing.com/2011/02/02/why-are-only-13-of-wikipedia- contributors-women/) )

they're working on improving the gender balance, but i suspect that the format will still retain this skew simply due to societal/demographic reasons.

I don't know that that means that there was any overt or covert racism, but there is definitely a contributor bias :P

† upon further investigation i have not been able to find references to racial demographics for wikipedia. Consider this hearsay.

<comment><USER4> > If you look at wikipedia's contributor stats it's like 70% white†, college > aged males. (Actually wikipedians are like 87% male. > [http://feministing.com/2011/02/02/why-are-only-13-of- > wikiped...](http://feministing.com/2011/02/02/why-are-only-13-of-wikiped..). > )

When an all/mostly black country invents something like the Internet, and then creates a website like Wikipedia, and then most of the nerds it attracts to administrate it happen to be black male nerds, then, yes, you'll see a different demographic mix. But until that happens, you'll see demographic trends that are likely (and reasonably) going to be heavily influenced by their starting conditions.

</comment></comment></comment><comment><USER5> Thanks, Zed. A typically balanced, well-researched and well-thought-out solution to a complex problem. I especially liked the part where you blamed all of Wikipedia for the actions of a single user.

I wish you had considered the route of getting involved instead. There are just some basic, fundamental things that would help fix this. A modification to the notability rules would require a lot less effort than your other proposals. The notability rules work pretty well for kicking out useless chaff like pages about high school garage bands that have never played a show. But they do privilege old-school publishing and broadcasting, so particularly ephemeral creations like new programming languages may fare very poorly against the notability criteria. But this strikes me as fixable.

Programmers can help too. We don't even have the capability, for instance, for people to be emailed when their favorite page is up for deletion. We don't have a lot of means for casual involvement; everything depends on logging into Wikipedia regularly. This is part of why battles in Wikipedia tend to be won by the most, shall we say, persistent.

I work for the Wikimedia Foundation, as a programmer. In general our resources are stretched pretty thin, and there's really only been two years so far of a budget that's even remotely in line with the size and impact of the site (thanks to your contributions). In a lot of ways we're still playing catchup with an explosive period of growth that happened around 2006-2007, using technology that's getting a bit venerable.

But the issue of deletionism and the general community demeanor is a problem that is occupying more and more of our attention. If it matters to you then contact me. I can definitely tell you there are lots and LOTS of ways to help out.

Actually you could even get PAID to fix this problem. Want a job working here? We have lots of open technical positions. <http://bit.ly/WikimediaJobs>

The one thing I can't guarantee is that it will satisfy your need to rage. The truth is, almost everyone in the Wiki community is acting in good faith. What they need are a) your input as a knowledgeable person about how policies need to change, and b) your technical and design skills, to create systems that avoid these communication breakdowns, and guide volunteers to be more effective.

<comment><USER6> Thanks Neil, a completely inaccurate reading of what I wrote. For the record, deletionists have been a problem for many people who are members of sub- cultures and Wikipedia has ignored the problem. Writing more arbitrary rules is not the solution. The solution is to fix the software so people can create a richer organization of information.

I personally have had some idiot with a vendetta get a page about me deleted numerous times _despite_ me having been mentioned in about 10 trade and mass publications and having a book published (now two) as well as my own articles in the press. It was baffling that a single person can get a page deleted without any warning, flagging, or attempts to do some research.

But really it comes down to trust. I don't trust any organization that begs me for money then deletes the content that matters to me most and tries to hide behind some bogus "well it's not _us_ really (tee-hee)". Either Wikimedia is in charge or they silently allow this kind of crap.

Finally, the issue of deletionism is purely the result of bad usability and structure. All you need to do is make a place to put these pages rather than delete them and you'll solve tons of problems.

<comment><USER5> You might be responding to an earlier version of what I said, but I absolutely agree with you that it's got a lot to do with the software.

Do you really want the Wikimedia Foundation to set themselves up as a judge of the content in Wikipedia? I mean, apart from the fact that we have no mandate or qualifications to do this, how could you get an organization that fits around a few tables in a restaurant to judge all the edit wars in Wikipedia? _In over 250 languages?!_

If this problem is going to be solved, it's going to be solved in some distributed fashion, by the community, or by interested hackers such as yourself pitching in and giving the community new tools. There's a good chance you (by which I mean any hacker reading this) could get PAID to solve this problem.

Or, it's going to be solved by someone forking Wikipedia content or starting over, but the same problems have to be solved somehow.

<comment><USER6> No, after this and many other things I'm not interested in working for them, at all. Especially if I find out the rumors of a "nerd purge" agenda are true. If there is a call to delete "nerdy" content I'm gonna really turn up the destruction.

<comment><USER5> A "nerd purge". At Wikipedia. You just broke my brain.

What are you talking about?

<comment><USER6> I've started to notice that a lot of "nerdy" topics get deleted lately. I can't prove it, but I suspect there's some attempt to cleanse the "white male nerd" out of Wikipedia in order to attract normal people. Again, _I can't prove it_. If it's true that's about the worst way to crap on the people who donate the most money and do the most work keeping the project going.

<comment><USER5> Demographically, Wikipedia is white male nerds. You might have seen some stuff in the media lately about how it's felt that this limits the scope of the encyclopedia. But it's not so much that there's an anti-nerd sentiment, it's that we have to broaden the base.

It can be a bit crazy sometimes. You think you have problems with your page -- I heard that the #1 actor in India had his page deleted because some kid from a Western country thought he was non-notable. Wikipedia can be a great place to learn about science and technology, but let's say, the history of feminism? There are articles on every micro-neighborhood of San Francisco, but sometimes hardly anything on major cities of Africa.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> _Let's put aside the insanely weird idea that one person has the ability to derail the creation of information unilaterally, without a vote, and without any oversight to focus on the real problem..._

Jesus, does Zed Shaw live on another planet? I've never edited a Wikipedia article in my life and even I know that when an article is nominated for deletion, there's a big hullabaloo where everyone votes and argues about it before it's actually deleted.

Also:

 _It's sort of impossible to say that the Esoteric programming languages page should not have a description of every "notnotable" programming language._

I do not think "impossible" means what you think it means.

<comment><USER8> Zed Shaw's personal hell: being given a laptop with an internet connection, a browser pointed at Wikipedia, and being asked to complete the article _List of things which do not exist_.

<comment><USER9> How about "List of articles which do not mention themselves"?

<comment><USER10> List of Articles not listed in a List of Articles.

</comment></comment></comment></comment><comment><USER11> This year I donated 50€ for the worthy cause of Wikipedia. One of my arguing points was that there is a lot of obscure information I am sometimes looking for that there is no reference of - except for Wikipedia.

Jimbo put your dog on a leash, or next year, when your bambi eyed face gazes into me from my monitor, I will send a turd in a bag instead of a donation.

Does anyone know what address I could/should send my complaint to for maximum impact?

</comment><comment><USER12> The notability requirements do not exist for a technical reason. That's entirely wrong. Maintainability is the reason. The space is not limited but the time of people working on those articles. The goal is for Wikipedia to only have articles of a high quality, the more articles there are the harder that gets.

I'm not trying to defend the notability rules (I think that they are quite often pretty stupid), I'm only saying that it is completely and utterly wrong to claim that Wikipedia's notability rules exist for a technical reason.

<comment><USER3> But the argument from maintainability is stupid too.

Wikipedia already stuffers from variable quality, and all its content comes with a big huge caveat emptor. Furthermore, the existence of poor quality doesn't have any bearing on whether the well trafficked content is good or not.

Deletionists really don't have any leg to stand on, and i find it mystifying and infuriating that they are allowed to continue deleting content put up by other people (mostly in good faith), essentially without cause or justification.

They can't delete their way to good content, because no content on wikipedia starts out as good content. You can't claim that leaving up poor content is a problem, or they should just lock the whole fucking thing, and only accept well curated patches.

<comment><USER13> The point isn't to delete bad content. The point is to delete content that is known by so few people that it is unlikely to get the attention needed to become a good article.

To put it another way, even if someone writes a really, really good article about their neighbor's dog Spike - complete with genealogy down to Rover the fifth, the harrowing near-death encounter when that gallstone removal surgery went wrong, and even a detailed account of that incident last Wednesday when Spike wet the carpet, there are so few people who know anything about that dog that it's impossible to fact-check the article. For all anyone knows it's all made up. So the line has to be drawn somewhere, and there need to be clear policies for it, as otherwise, well, things like this happen.

<comment><USER3> But Spike is a straw-man (well, dog).

These programming languages aren't non-existant, and can be verified as actually existing. It's not that there are _no_ references to it.

On top of that, i'm still unclear why it would even matter? Things with little interest will generate little traffic. The potential to misinform is pretty low. And if it were to be the case that an article that was incorrect (maliciously or not) were to suddenly see an increase in traffic, presumably that can only serve to encourage people to point out inaccuracies and correct them (treating fictionalized accounts of anything as being an inaccuracy). And wikipedia already has a mechanism for resolving synonymy and name-resolution disputes.

<comment><USER14> If Wikipedia just accumulated everything it could, we'd end up with a billion articles 90% of which are vandalized, outdated, mistaken crap. The potential to misinform would be huge. They can only successfully scale the corpus at the rate at which they gain volunteer editors (who are far rarer than people who just write one article about their favorite obscure thing, and then leave).

<comment><USER15> It is frankly easier to get a fake article by the editors than a real one. The editors generally do not check articles for accuracy or quality (beyond what a high-schooler with a dictionary could do) — they just fastidiously apply a checklist of rules.

Also, I think it would be easier to get editors if being an editor were more about making the site good and less about dealing with the head cases who currently edit the site. (Nothing personal intended against any individual editors who may be reading — it's just a general reflection of how things look to people who have casually attempted to try editing.)

</comment></comment></comment></comment></comment></comment><comment><USER16> Plan A doesn't work. It is actually easier to delete things from pages than deleting pages themselves. If you edit war over it you will lose.

Plan B does not work. Wikipedia guidelines do not consider self-published sources as 'reliable' and things published by Lulu are considered self- published. Wikipedia does not consider itself a reliable source either. It is also not going to disappear in a puff of logic like God in hhgttg, no matter how witty you think it is.

Plan C has not worked in the years of people deleting things that appeal to far broader audiences than esoteric programming languages. They are still around. How well do you think this will work?

Plan D is something many people have done. In a way, Wikia is a giant example of it. In other cases they go to wikinfo or create their own wiki.

This post is exactly like 100s of others that someone writes whenever Wikipedia deletes (or even tries to delete) something that they care about. The ground is well-tread and it brings nothing new or interesting to the table. The internet does not need another blog post where someone spends an hour in isolation writing about it.

On an irrelevant note, mediawiki does support subpages (the slashes), but articles cannot have them as article titles may contain slashes. This has absolutely nothing to do with Wikipedia's notation of notability and the reasons people try to get rid of non-notable content.

<comment><USER6> Plan A is a DOS attack. It's not about getting the information there, it's about putting so much there repeatedly that they have to admit that those topics need their own page.

Plan B wouldn't be "self-published". It would be published by me as a record of the languages that came out that year. Since no language I have is in the book, it's not self-published. If what you're really saying is Wikipedia doesn't recognize Lulu.com, then they're gigantic hypocrites. My book, "Learn Python The Hard Way" is published there, and has an ISBN and Lulu is my publisher. It's just as legit as my books published by Addison/Wesley, especially given their size.

You say Plan C doesn't work, but then here you are debating the topic, and Wikipedia's primary supporters are probably all over this. As many other people say, it's all filled with white nerdy males. If Wikipedia goes around deleting the things they like in order to "de-nerdify" the content, then eventually people will stop donating and go after them. I plan on doing it, and maybe some others.

Plan D is mostly a joke, but it might be good to create a record of the "great nerd purge" that seems to be hitting Wikipedia lately.

I also find it sad that you say people write things like this when Wikipedia deletes content they care about, and yet nothing is done. In fact, you sound powerful and proud of this fact, like it gives you a sense of pride, which is really _really_ scary.

<comment><USER16> Plan A only bothers whomever tries to maintain [[List of esoteric programming languages]] or wherever you pick as a battleground. I know it sounds to you like you can really "stick it to the man" and they will swoon over your brillant tactics and relent, but you will only bother people that actually care about esolangs in the first place and Monsanto certainly isn't going to be around. The best you can hope for is some people get blocked and pages protected.

Wikipedia's policies would consider it self-published. It does not matter that you would be writing about languages that you are not affiliated with. Again, you are not going to change Wikipedia's policies by pointing out that Wikipedia itself is self-published in their eyes.

I think you are vastly overestimating the number of people that have even heard, much less care about these esoteric languages.

I do not know why you ascribe these emotions to me, but they are not in the least accurate. I do not think my personal opinion on this set of articles is at all significant. I do not care about them, either way.

Frankly, what disturbs me is how you have very strong opinions about how Wikipedia does or should work with an incredibly superficial actual understanding. For example, why do you argue over how Wikipedia sees Lulu? Have you even read Wikipedia's policy on Reliable Sources or Verifiability? It is not as if Lulu itself or other things like it are new. It has been debated a number of times and at length. You have no knowledge of the issue and provide no insight.

<comment><USER6> Well so far you've just thrown out proclamations without any references backing what you say. I mean, you're some random dude on a forum who's basically repeated what I've said and went "WRONG!". How insightful.

<comment><USER16> I'm sorry that you are incapable of taking 5 minutes to find read the specific Wikipedia policy pages that mentioned by name. Just because you know nothing about subjects and like to bullshit about them on the internet does not mean that everyone else does the same. Since you mostly seem to be interested in hearing yourself speak I will not engage you further.

<comment><USER17> I'm sorry that you're incapable of taking the 5 seconds to realize that the overabundance of specific Wikipedia policy pages are the reason why people have given up trying to fix it from within and are content to lob stones from outside without digging into the rules.

Just because you know so goddamn much about policies and the like, doesn't mean anybody else cares.

Since you mostly seem to be interested in seeing yourself further existing bureaucracy and not IAR to create the best a resource for wikipeida users, I will engage you in a futile attempt to point out the reason that people are not doing what you ask.

</comment></comment></comment></comment></comment></comment><comment><USER18> Notability requirements for an article to exist at all is the wrong approach.

Instead, wikipedia should allow most any article to be added, but have one or more groups that "certify" articles as notable. People who want to avoid all the non-notable clutter can then elect a view of wikipedia that only includes articles certified by the group (or groups) they choose, while non-notable articles can still be viewed by those who choose to view them, and can have the breathing room to in some cases evolve into notable articles.

</comment><comment><USER19> It seems the notability requirements really serve Wikipedia's own notability. It can't say "we'll take our list of topics from Encyclopedia Britannica" but it's what it would like to do.

In the beginnings it actually made sense, too, since it would never have took off if every page was about Joe Schmo's cat.

But now that Wikipedia is probably more famous and more well known than any other "real world" encyclopedia, such "respectability hacks" are unneeded and should be repelled.

</comment><comment><USER20> I think the key here is that Wikipedia's notability requirements really only apply to people, publications, and events. For some things, for example the article on esoteric programming languages, it doesn't really make sense to talk about notability.

</comment><comment><USER21> Zed writes: "I have registered notnotable.com... Just put up the same software, get some free hosting from some of the companies out there that I know, and start filling it in with anything that's not on Wikipedia."

There've been a few abortive attempts to create a repository for deleted Wikipedia content, or a more inclusionist Wikipedia with the same software... and they've all proved moribund.

The trick is not just the name or concept, but the entire community and mission. Reusing the same software – while attractive for a quick start – could present problems. Part of the reason Wikipedia has resorted to deletionism, in my mind, has been weaknesses in MediaWiki, and having the same general appearance and workflow is likely to just walk a new project down the same paths. And defining an alternative solely as "what Wikipedia isn't" puts a rather hard and low cap on its growth as an independent identity.

With these problems in mind, I've started working on a reference knowledge- base to complement Wikipedia that will loosen the 'notability' requirement in favor of 'true and useful'. Otherwise, it will share the same licensing and a wiki-centric edit model.

The project codename is 'Infinithree' ('∞³'), and I'm discussing it pre-launch at <http://infinithree.org> and (Twitter/Identica) @infinithree.

</comment><comment><USER22> _puts on conspiracy cap_

wikipedia _was_ a huge threat to traditional information sources, but now something has to come from one of those traditional sources to be considered legitimate info. problem solved.

</comment><comment><USER23> The donations thing just made me wonder if it could work to have donations per page. That is, you could kind of adopt an article (and get a banner on that article announcing you are the sponsor, perhaps).

Immediate problem would of course be advertising, which would not be desired.

It's just that if I donate now, I feel as if I am supportive of their deletionist policies, which I am not.

</comment><comment><USER24> Strange that e.g. several content farms are deemed notable by the Wikipedia editors:

      http://en.wikipedia.org/wiki/Mahalo.com
      http://en.wikipedia.org/wiki/Softpedia

Notability requirements are fine, but not if they are applied selectively.

<comment><USER25> You should probably flag them AfD.

</comment></comment><comment><USER26> That's just... wrong. Come on, Zed, at least do your homework. Chris isn't deleting the pages, nor is he acting as some sort of sole determinant of noteworthiness. He's simply proposing them for deletion through the Articles for Deletion process. Also, Wikipedia handles sub-pages just fine. Most active editors have a number of sub-pages on their userpage, and many articles have sub-pages as well where people will store drafts while working on a revision. Your information is wrong, and your tone is insulting. Cut it out, man.

<comment><USER6> I don't care what the bureaucratic process is, all I know is one guy went on a rampage electing pages for deletion and they're gone. This "plausible deniability" of page deletion so nobody is to blame really is odd.

<comment><USER26> There's a discussion at each AfD where anyone can come in and say why a page should or should not be kept. In the end, it is the adminstrator's decision as to whether or not there is a consensus to delete (default is to keep), and there are processes in place for getting the decision overturned.

Chris nominated 8 pages for deletion over a period of 3 days. While it's a spree that's likely hasty, it's by no means a rampage. I believe he was wrong to do as he did, but only a couple pages were deleted, and there's a discussion to have Nemerle restored. He's hardly a one-man wiki-wrecking crew.

<comment><USER25> _it is the adminstrator's decision as to whether or not there is a consensus to delete (default is to keep)_

The _de facto_ process is to default to delete. As this embarrassing debacle has shown, there were no votes to delete, and yet poof! the articles were deleted and a day later, with significant backlash and discussion, almost all in favor to reinstate or at least open the pages back up to be reconstituted, are not back up.

Wikipedia's editing "process" is a shameful joke.

</comment></comment></comment></comment><comment><USER27> In case anyone is still curious how this got resolved, Monsanto gave up. From his wikipedia user page (<http://en.wikipedia.org/wiki/User:Christopher_Monsanto>):

> Dear internet,

> You guys win. I will stop nominating pages for deletion.

> I wasn't doing this to troll or to slam any language community. I was just > trying to help -- I read the WP guidelines for inclusion, and whenever I > came across a language that didn't seem to meet said criteria, I nominated > it for AfD. I think, with respect to Wikipedia's established notability > guidelines, my arguments for deletion were airtight, which is probably why > the articles were eventually deleted. I'm not sure my actions warranted the > kind of internet-hatred I received as a result. If anyone thought what I was > doing was wrong, they could have just sent me a friendly message and I would > have politely discussed the issue. Few took this route, and I am sorry that > due to time constraints and an overwhelming amount of invective I could not > reply sensibly to everyone.

> Since the internet seems to care more about keeping these articles than I > care about deleting them, I'll stop. I personally think a lot of the > articles should have been deleted. I think that ALL articles I nominated for > deletion fail to meet Wikipedia's general notability guideline. Here's a > challenge, then, for the internet: instead of spamming my Wikipedia talk > page (which I don't really care about), why don't you work on fixing WP's > notability guideline for programming languages? Otherwise, some other naive > editor will eventually try to delete them. Perhaps they won't have as much > experience dealing with trolls and flamebait as I have had, and will become > very hurt and confused. Nobody wants that :(

</comment><comment><USER28> You could always create an esoteric languages wiki of your own if you were all fired up about it (I work at wikia, and that's the service we provide, we have 170,000 wikis on various subjects, using the same software! Founded by the same guy!)

But that's not really the point here. It's just because it's wikipedia that everyone gets all weird about it. The information is out there, I don't see why it's so important that every esoteric project have a wikipedia.org page. It's not supposed to be a compendium of ALL human knowledge, it's an encyclopedia of generally useful knowledge. There has to be SOME criteria for excluding stuff. There's already a problem with wikipedia containing way too many pages about nerd topics and not enough information about the rest of the world.

<comment><USER29> _It's not supposed to be a compendium of ALL human knowledge_

...:

 _Imagine a world in which every single person on the planet is given free access to the sum of all human knowledge. That's what we're doing._ —Jimmy Wales. Wikipedia Founder Jimmy Wales Responds. Slashdot, 2004. [http://interviews.slashdot.org/story/04/07/28/1351230/Wikipe...](http://interviews.slashdot.org/story/04/07/28/1351230/Wikipedia- Founder-Jimmy-Wales-Responds)

<comment><USER28> The focus is changing, 2011:

"It's about diversifying the community. At the moment we're really male, geek orientated, which is great, but there are lots of editors that we don't get who are geeks, but not tech geeks. So they may be real experts in, say, ancient Chinese poetry but if they go to try to edit Wikipedia, then they find it too intimidating and we lose them and that's just silly."

I think this whole explosion of whatever-it-is-itis is a perfect example of that.

<comment><USER29> I'm trying to figure out what that quote has to do with anything brought up in this thread.

<comment><USER28> Hm? It was just a counterpoint to your quote.

I'm just saying, wikipedia most likely can't and probably shouldn't contain an article about everything. It's just not possible, nor desirable, although it makes a good quote. It seems like deleting useless crap is one approach to that, and encouraging editors to contribute more to non-nerd-lore topics is another approach.

<comment><USER29> _It was just a counterpoint to your quote_

In what way?

 _encouraging editors to contribute more to non-nerd-lore topics_

Surprise! Deleting Star Wars articles doesn't create more content for the article about the large-tailed antshrike.

And guess what? I don't even like Star Wars, and I think the lack of information on, you know, _real stuff_ (in contrast to "nerd-lore topics") is disheartening. So lay off with the kind of presumptions you're throwing around in these comments.

<comment><USER28> I realize deleting one thing does not create a different thing.

I agree it was more of a tangential quote and not a direct counter, but I was trying to point out that some of this "deletionism" is probably due to a recognition that not everything is being covered equally, and it might be nice to prune the leaves from time to time to encourage growth in new directions. Or something like that. Also, I'm not trying to speak for anyone else but myself, everything I said was just my own musing about the topic. However, I do have a feeling that if the first 10 years of wikipedia was represented by your quote, the next 10 years might be represented by mine. The goal seems to be growing up and encouraging people, which seems like a good idea, considering all the rage generated by this topic. If it can't contain everything then what it does NOT contain is going to be a deliberate choice by the community, and this whole thread seems to be dominated by one side of the argument so I thought I'd throw in a tangent. Thanks for the thoughtful comments though, and I should probably have put more thought into my own comments, I was just commenting in the spur of the moment.

<comment><USER30> _...it might be nice to prune the leaves from time to time to encourage growth in new directions_

Could you explain the mechanism by which that would work?

Do you expect that the person contributing articles about Star Wars will, after his article on Boba Fett's brother in law is deleted, decided to write an article about critical feminist post-industrialist theory?

<comment><USER28> Looks like I really ran into a buzzsaw here. Sorry for not presenting a magical unicorn for you on demand.

Sure, maybe in 10 years after they grow up and develop some interests besides Star Wars, that person might have something more useful to contribute.

<comment><USER29> _Sorry for not presenting a magical unicorn for you on demand._

You're suggesting that this kind of deletionism is constructive in the long run. The onus is on you here.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER31> _Wikipedia has not [sic] problem paying for storage_

What do the near-constant donation drives cover then?

<comment><USER32> Bandwidth, servers and staff. Storage is most certainly not their problem; the English language Wikipedia is only about 5TBs of text. That's cheap.

<comment><USER33> Actually, it seems like a roughly even split between salaries+wages, internet hosting, in-kind expenses, operating, travel, and deprecation (in 2007, at least, because it was easiest to find)[1]. Wikimedia may not be a publicly traded company, but they do release their financials.

[1] [http://upload.wikimedia.org/wikipedia/foundation/4/49/Wikime...](http://upload.wikimedia.org/wikipedia/foundation/4/49/Wikimedia_2007_fs.pdf)

</comment></comment></comment><comment><USER34> Wikipedia deletionism has nothing to do with the lack of paths. Organization is handled by mediawiki's category feature. Name collisions are avoided and similar names collected on disambiguation pages.

"Plan A" is not a new idea, it's exactly what happens to other categories with lots of items that don't deserve their own page.

"Plan B" won't work because part of deletionist policy is to ignore sources published by self-publishing outfits, because "anybody can publish there".

"Plan C" won't solve a goddamn thing. Good luck with "Plan D".

Quit asking for features that already exist.

<comment><USER6> Oh, an name of idonthack with no comments and no karma really. Well, since you don't meet the requirements of notability in my world I'm just going to down vote you.

Thanks for playing anonymous troll.

</comment></comment><comment><USER29> _Plan B ¶Put out a yearly publication on Lulu.com … This publication is then a legit secondary source by a real publisher…_

Uh... _nope_.

Hey, I have an idea! Let's publish suggestions like this to a blog and purport for it to be sound, so then it can be picked up by quacks who have an agenda to push in a bunch of _completely unrelated_ situations. (Think vaccine scare pushers or those looking for self-promotion, who already exist in abundance on Wikipedia). Yeah! Let's _all_ eschew with stuff like a "nuanced understanding".

Whether you are for or against this instance of deletionism, Shaw's plan B here wouldn't successfully legitimize anything of any subject matter, _and that's a good thing_.

<comment><USER29> I've seen this get voted down by a non-trivial amount, then upvotes bring it back up, and now it's voted back down. Anyone care to, you know, comment about whatever you're finding in my words to be an assault on your faculties of reason?

<comment><USER6> It's hard for Wikipedia to say that other publishers are not legitimate because they're online, when Wikipedia itself had to fight for legitimacy because of it's online nature. Doing that means they're just tools of the giant corporate publishers and not even _close_ to their original purpose. Instead, they would need to recognize Lulu (like Amazon and the Library of Congress do) and accept books from there or be shown as complete hypocrites.

Another thing to note: People say that Lulu doesn't have an editorial process but they do. Once you publish a book they review it and if it meets their standards they put it into Amazon and other sellers for you. Considering that editorial standards at _all_ publishing houses is damn near zero except for copy-editing and slapping a cover on, I think it's fair to say Lulu is just fine as a source.

<comment><USER29> _Wikipedia itself had to fight for legitimacy_

Sorry, _what_? If someone told you Wikipedia succeeded in a "fight for legitimacy", you were lied to.

 _they're just tools of the giant corporate publishers_

You don't have to be published by giant corporate publishers to be cited on Wikipedia. You don't have be published by corporate publishers, giant or not. There are an immense number of citations on Wikipedia that fail to meet those criteria, and they can even be the best sources to cite (and not just because of a lack of sources).

 _Instead, they would need to recognize Lulu (like Amazon and the Library of Congress do) and accept books from there or be shown as complete hypocrites._

No, no; no need to argue here. You already had me sold. Down with nuanced understanding, I say.

<comment><USER6> > No, no; no need to argue here. You already had me sold. Down with nuanced > understanding, I say.

A "nuanced understanding" of rules just lets people enforce them arbitrarily. Either make them concrete and fair, or find a way to not need them.

<comment><USER35> Zed, there's also a site called Deletionpedia which supposedly contains all pages that have been removed from the English-language WP, usually because of notability. Their content might be a good starting point for your notnotable.com project.

<comment><USER21> Deletionpedia appears dead; the deleted pages most recently mentioned on their 'Recent Changes' (disregarding server clock issues) are from June 2008:

[http://deletionpedia.dbatley.com/w/index.php?title=Special:R...](http://deletionpedia.dbatley.com/w/index.php?title=Special:Recentchanges)</comment></comment></comment></comment></comment></comment></comment>


Tips Wanted on Journey – Learning to Program a Photo App - <AUTHOR>

I've just started to learn how to program (ruby on rails), because I wanted to create a photo app with 1 feature I had in mind.
My question is, are programming photo apps any harder to learn/code than normal apps?
Does it take more time to program photo apps than any other normal apps?
I'm new to all of this, so I try to guess how hard it will be (or guess how much time it may take) to learn all of this, to program a photo app. (I'm a heavy right brain person too, I know you guys hate me)
Anyhow, I would love to hear your thoughts, and suggestions/tips you would have on my journey to learning how to program a photo app. <comment><USER2> Photo app like an image gallery or something like Instagram that applies filters to images?

When you say app do you mean a web page/app or a phone app?

<comment><AUTHOR> I mean something like a photo sending app like Snapchat, a mobile phone app.</comment></comment>


Open Sourcing Mantis: Netflix Platform for Building Realtime Applications - <AUTHOR> https://medium.com/netflix-techblog/open-sourcing-mantis-a-platform-for-building-cost-effective-realtime-operations-focused-5b8ff387813a <comment><USER2> Remember to search for other projects before settling on a name. In this case, the name collides with the Mantis bug tracker:

[https://mantisbt.org/](https://mantisbt.org/)

</comment><comment><AUTHOR> Mantis can be thought of as a stream processing engine + a container cloud for execution.

Website -> [https://netflix.github.io/mantis/](https://netflix.github.io/mantis/)

Github repo -> [https://github.com/netflix/mantis/](https://github.com/netflix/mantis/)

Use cases cited:

1\. Realtime monitoring of Netflix streaming health

2\. Contextual Alerting

3\. Cassandra and Elastic Search Health Monitoring

4\. Alerting on Log

5\. Chaos Experimentation monitoring

6\. Realtime Personally Identifiable Information (PII) data detection</comment>


Has India lost the 21st century? - <AUTHOR> http://tehelka.com/has-india-lost-the-21st-century/?singlepage=1

<comment><USER2> Obviously is hasn't. It is way too early to tell. It would be like asking in 1913 if Japan or Korea had lost the 20th century while at the end of it, both where big winners on a relative scale.</comment>


Why You Shouldn't Freelance - <AUTHOR> http://freelancefolder.com/12-reasons-you-shouldnt-freelance/

<comment><USER2> > 1 To sleep in all day and leave work early

No, that doesn't work - all the time - but occasionally, you get to work really really hard and then you can slacken off for a bit, take it easy. If you are the kind of person that is 100% productive all the time this may not be a benefit to you, but I'm not all that regular and I definitely have my productive and less productive phases.

So the fact that I don't _have_ to get up at a set hour and report to a boss really helps. In fact, if I know I have to get up early that usually spoils my rest completely because I can't sleep.

2> freelancing will make you rich

It probably won't make you rich, but it will definitely make you more money than what you'd make doing the same job for a boss. After all the taxes are paid and you've been doing it for two to three years you can expect roughly double the amount left after paying taxes and so on compared to what you'd make working a 'regular' job.

And if you use whatever time you have left over to work on a pet project or two then you might even be able to do better.

>3 you hate working with people

That's a tricky one. If you _really_ hate working with people you have a problem regardless. If you just hate working with certain people, the kick- down lick-up type and the ones that have floated to the top through a lack of substance then as a freelancer you have more control over the situation than as an employee.

After all, you don't have to work with everybody, you can choose with which companies you do business. Four or five good customers that pay on time and that you can work with is really all you need. More is better. But you'll never be forced to sit opposite from 'joe', your jerk co-worker that always tries to find a way to get under your skin when the boss isn't looking.

>4 to spend the day with your kids

I don't understand what the writer is trying to get at here. Maybe the ability to mix a healthy amount of private life with business life is hard to come by, but in general it is doable.

You don't need to be super grouchy, and to train everybody around you to walk like ghosts, conversely your family will have to support you when you are in need of some time to work on stuff that needs doing. After all, a regular job takes you out of the house 40 hours per week + commute.

Also, there are plenty of freelance jobs where you will be out of the house. And if you're even moderately successful a simple office with a phone line and internet connection doesn't have to cost the world.

I've had two occasions in the past where a large customer suggested I have an office in their building, at their cost, or seriously discounted.

>5 you can charge whatever you want.

No, that's obviously not true, you can't charge whatever you want.

But on the other hand it's not the union determining what you can make either. If a job is high pressure, short time to deadline and you're the linchpin, then you can pretty much write your own ticket, within reason. If it's a job that anybody could be plugged in to then it's obviously a different matter. Finding out where there is room is part of the skills you will (need to) develop.

>6 freelancing is an easy job

Freelancing is definitely _not_ the hardest job out there. The hardest jobs are selected for people that have little to no education and that have very few options in life. Go work in a harbour, a slaughterhouse or a cleaning company for a couple of months.

Freelancing is a walk in the park by comparison.

It's not as easy as most office jobs, but then again, you can't be fired any more, you have a lot of control that you'd never have as a wage earner. You also don't have any of the (relative) security that comes with that.

If you need to track down 'late payments' you're doing something very wrong, late payments should be extremely rare if you have a good relationship with your customers.

You can even avoid late payments completely by being completely up front about your financial situation, setting a decent price and demanding half up front and half on delivery, or some scheme like that.

>7 to keep up with the household chores

Clean stuff up right after you use it and that problem goes away easily enough. It's not like 'household chores' are going to take you the whole day, 20 minutes per day is for a single person more than enough to keep their life in order, if you're with a family of four then it may be a bit more work, but then there are also more hands to help.

>8 work will just come to you

Not initially, no. But after a while, and if you're good that will start to happen. And at some point you may even have to raise your price just to slow down the influx of new work.

That's how you convert a reputation in to $.

>9 no boss

That's a tough one, self motivation is - for some people - really really hard. If you are not looking at the company where you are working with a continuous eye to how you could and would do better and what you would do if you were more free then freelancing is probably not for you.

10> you'll save lots of money

Actually, you will save lots of money. They're called 'deductibles', and when you play your cards right you will find that you will probably pay less taxes as a freelancer compared to being a wage earner, at the same income level.

>11 you'll have more free time

If you are smart about it, and you keep accurate hours and you get good at budgeting jobs then you will eventually have more free time. But the first 2 to 3 years, which is how long it will take you to establish a reputation you will actually be working a lot harder than before.

This is fine, as long as you like your work.

>12 your family will respect you more

If you work either as a wage earner or as a freelancer in order to earn other peoples' respect then you're on the wrong road, regardless of which of the two you choose.

You work because it gives _you_ satisfaction, food on the table and the level of security that suits you best.

If you feel undervalued as a wage earner then you can boost that satisfaction level - and your self confidence - by 'going solo'. It is also a good introduction in managing money, handling taxes, legal affairs and a whole pile of other useful skills.

Think of it as a very good preparation to running a larger business.

<comment><USER3> Re (7), I've found that freelancing has actually been really good for keeping up with housework. I can't work 8 hrs straight through in a day no matter the location or job, but when I'm at home, I can spend one of my little breaks taking 5 minutes to clean up the kitchen. Little incremental chores like that keep you from developing an intimidatingly large backlog.

</comment></comment><comment><USER4> I've freelanced for the last 10 years and I feel a lot of the points made there are scraping the barrel somewhat. You learn how to best deal with most of it in less than a year.

Strictly budgeting yourself should be on there, as it's very much a case of feast and famine when you're starting out.

However, the single most difficult thing about freelancing to this day, for me at least, is staying motivated. My best tip to avoid creative blocks is to choose your clients wisely to allow your focus to shift around as diverse an array of briefs within your field as you can manage so you remain fresh and full of good ideas.

Oh boy, did I ever learn that the hard way.

</comment><comment><USER5> It's good to point out the negatives to freelancing. I just started freelancing last month after being laid off, and there are definitely positives and negatives. While I do have a much more relaxed schedule and I do make more money, it sucks not having much work/life separation.

For instance, last week I had a few friends over for some beers and I had to work the whole time because the client had an important demo the night before. Because of the rate I was getting, I had to choose between $X/hr and hanging out with my friends. Sadly, the $X/hr won.

It is also hard to convince my Fiancee that I need to carve out 8 hours a day to do work. Yes, I'm at home all the time. Yes, I physically _can_ go visit her mother today. However, I need time to work, and if I'm running errands all day there isn't time to ever get work done. It's hard to strike this balance and to stay hard line on "When my office door is closed, pretend I'm downtown and at work."

Overall, though, I prefer freelancing. After awhile I'm sure the lack of structure, instability and lack of benefits will cause me to jump to another full-time gig. Until then, I'm happy doing what I'm doing.

<comment><USER2> If you can and this continues to be a problem find a small office nearby. Just a single room with a door that you can lock would be enough.

Clarity helps a lot too, setting a simple rule that will not be broken (Monday through Friday, from 8:30 am to 17:30 pm I'm at work, and not available, sorry), goes a long way to forestalling such push-and-pull situations.

Being unclear can be a source of great frustration, to both parties.

edit: one thing you could do that might help to greasing the wheels a bit is to make sure you lunch together on workdays.

<comment><USER6> Agreed. I don't freelance, but I work remotely a few days a week, generally from home. Where my wife homeschools our sons. We have ground rules, though, that help both of us manage:

1\. I walk to the cafe from 9:00-12:00-ish while she does the bulk of the work with the kids. The local cafe is quiet, so it's not a problem for me to work there, and get a lot done in that time. 2\. If I can't be distracted once I'm back home, I simply close the door to our office. 3\. If my wife is working with the kids, I stay out of that area of the house. 4\. On days that I spend some time with the kids, it's understood that I'll need to "make up" that time in the evening after the kids are asleep.

</comment></comment></comment><comment><USER7> I find freelancing perfect around uni, sure most of the downfalls are valid but what other job could I do that got me more experience in the field while being able to navigate around changing uni commitments.

Also depending on how demanding your clients are you can afford to have a slow week where you don't get much done if you don't really need the money, then ramp it up again when things aren't so busy in your life.

</comment><comment><USER8> I loved freelancing when I had a ton of work on, because it basically meant I could code and get paid better for it than I otherwise would.

I hated freelancing when I didn't have a ton of work on, because it meant I had to do stuff that felt "dirty" to begin with, and then boring later on, like marketing, sales etc.

I'm now moving to a completely different country (with a far lower cost of living and tax rate) so I have more time to work on my own projects without worrying about needing to do the whole sales and marketing song and dance. I'm still not entirely sure if I want to focus on being an employee or being a freelancer over there though, Even after almost ten years going it solo, the sales part still scares me.</comment>


CVE-2015-8126: Multiple buffer overflows in libpng - <AUTHOR> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-8126 <comment><USER2> Uh oh. It's time for the monthly global computer security meltdown. Again, but worse this time. Security vulnerabilities in libpng are a huge deal; they affect lots and lots of different programs, including things people don't usually think of, and many them embed their own copies of libpng which makes them hard to update. The last time there was a security vulnerability in libpng, it took _years_ before it was fixed everywhere.

Patching this properly will require not just replacing a centralized copy of libpng, but scanning all binaries for statically-linked copies. There might be some tools left over from the last time libpng got into trouble; this would be a very good time to update and link to them. Some categories of software that are at particularly high risk right now:

* Web browsers. Sandboxing likely helps, but there's a possibility that there are some usages (eg favicons) that decode outside the sandbox.

* MMS on Android (possibly remote root on phones with no user interaction)

* Any server that accepts PNG uploads and processes them (eg, user avatar thumbnail generation)

* Anything which shows people user-provided avatar images (eg, IM clients)

* Video games which download levels that can contain images

* File browsers which show image previews

* Music players which display album covers

Expect malicious images to start appearing everywhere, and soon. If you're responsible for the computer security anywhere, this is a drop-everything priority.

<comment><USER3> This is exactly why static linking/bundled libs/containerization is such a piss poor idea. We are going to be dealing with this vuln for years and years, if not decades to come. The exact same insanity has has happened with embedded copies of zlib in the past.

The solution to dependency management in way too many cases becomes "never update". And those mechanisms allow negligence like that to fester for years ignored/unnoticed.

<comment><USER4> Containerization might well be the _solution_ to this kind of problem: libpng's vulnerabilities no longer matter much if you've isolated it into its own VM with no access to resources beyond the ones it needs to decode a PNG into a pixel buffer. I've been working on a little OS project along these lines, where every process runs in its own VM, and every shared service is provided by a local server. There's no dynamic linking. Instead of dealing with the cost of constantly churning code, and all the instability and unreliability that comes along with it, the idea is to pay for security up front by isolating everything. If you want to decode a PNG you have to spin up a VM, stream the PNG data in, and stream the decoded pixels out. The PNG decoder has no access to the file system, network interfaces, user interfaces, or really anything but stdin and stdout and some memory. If it crashes, it crashes, and from the client's perspective the app just exited with a non-zero error code.

<comment><USER5> > The PNG decoder has no access to the file system, network interfaces, user > interfaces, or really anything but stdin and stdout and some memory.

So you've rediscovered what UNIX has allowed us to do for decades now.

Things like process isolation, memory isolation, file isolation, and hardware isolation aren't new. UNIX systems offered mature implementations of them in the 1980s, if not before then.

Best of all, this functionality was offered without needing to resort to resource-intensive virtual machines or anything of that sort.

Those who want the level of isolation you propose have been able to get it for a long time now. They just tend not to, because it's inconvenient and impractical for real world systems.

<comment><USER6> That's just not true. A program needs to be started root to execute setuid(2): there is no way for a program started by an unprivileged user to drop privileges. Nor can it drop network privileges. That's why tools like pledge(2) and seccomp had to be added, but they have their own problems. To get the level of isolation GP described, you need some fairly esoteric solutions.

<comment><USER7> Well seccomp() strict mode (only allows read, write, exit) has been available since linux-2.6.12 (2005). So no need to invent something new, or set up a bunch of cgroups and namespaces, to get processes that can only read stdin and write stdout and use some of their own memory.

</comment></comment></comment></comment></comment></comment><comment><USER8> A good opportunity to check how [https://github.com/PistonDevelopers/image- png](https://github.com/PistonDevelopers/image-png) is doing (a PNG decoder written in Rust). Looks like it includes bindings to use miniz.c for DEFLATE decoding as well as "inflate" (which seems to be DEFLATE in Rust). Also, it seems to have a fuzzing driver (png-afl). Good times!

<comment><USER9> There are PNG decoders written in a bunch of safe languages.

For instance the JVM uses a Java PNG decoder. So it isn't vulnerable.

<comment><USER10> What killercup might be implying is that Rust is both a "safe language" and that Rust code can expose a C-compatible ABI, which means that a library written in Rust could theoretically replace one written in C regardless of which other language is ultimately making use of it. For example, this is what Mozilla is working on doing in Firefox by replacing security-conscious components with Rust implementations ( [https://bugzilla.mozilla.org/show_bug.cgi?id=1151899](https://bugzilla.mozilla.org/show_bug.cgi?id=1151899) , [https://bugzilla.mozilla.org/show_bug.cgi?id=1161350](https://bugzilla.mozilla.org/show_bug.cgi?id=1161350) ).

However, I don't know if piston-image specifically provides such a C interface.

<comment><USER11> However, if the bug is that the library writes to a too small allocation by the application (based on a lie told it by the library) then it doesn't much matter what language the library is in.

<comment><USER10> I see there are some downvotes here, which I don't think are deserved. It's true that at some level of your stack you're going to have some code that's just poking bytes into buffers, and that generally takes some manual effort to verify.

For what it's worth, I'd expect this sort of thing to be walled up behind an `unsafe` block in Rust, which if nothing else would lend increased scrutiny in an audit.

<comment><USER12> I believe the point tedunangst is trying to make is that if the API works something like this:

      size_t sz = lib_get_buffer_size();
      char *buf = malloc(sz);
      lib_fill_buffer(buf);

and there's a bug in lib_get_buffer_size that causes it to return too small a number, but lib_fill_buffer assumes it's big enough, you've got a vulnerability regardless of what language the library is written in. This isn't a bug in the application, because it's doing what it was told to do. It will be hard to spot in an audit of the library because the bug is in lib_get_buffer_size, which probably contains no unsafe blocks, while lib_fill_buffer probably looks fine.

It's a deficiency in the API, which should require the buffer size to be passed to lib_fill_buffer so lib_fill_buffer doesn't have to make any assumptions about the size. But if you're trying to preserve compatibility with existing C APIs, you might be stuck with APIs like this.

<comment><USER10> To clarify further, the idiomatic usage of `unsafe` in Rust stipulates that if you can't guarantee that your function is memory-safe for all possible inputs, then you must mark the function itself as `unsafe` to force callers to be aware of the risk. Obviously if you're both calling this theoretical function from a language without an `unsafe` construct and if you're also striving to maintain exact API compatibility with the C function then you can't really make this aware to the caller. If you do have control of the API then the way that this would generally be presented on the Rust side would be to have two functions: a safe one named "foo" that also takes the length as an argument so that you can check at runtime and an unsafe function named "unsafe_foo" that has the same behavior as the C function.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13>
        Some applications might read the bit depth from the IHDR chunk and allocate
        memory for a 2^N entry palette, while libpng can return a palette with up
        to 256 entries even when the bit depth is less than 8.

On initial review, this will require assumptions in the client application to be exploitable. I haven't found a place where libpng itself causes the overrun. It is just an enabler by returning a smaller value for bit_depth than num_palette. If the application double-checks the result from png_get_PLTE or uses PNG_MAX_PALETTE_LENGTH instead of 1<<bit_depth, it won't have a problem except wasting memory.

Unfortunately RFC 2083 contains the requirement that a compliant PLTE will not be larger than the bit depth. So I'm sure many applications that trusted libpng to do the validation will be exploitable. I consider this a caution against promising too much in the spec, as well as not overly relying on an implementation to exactly follow the spec. Remember the robustness principle: be conservative in what you send, be liberal in what you accept.

<comment><USER14> Does anyone actually interface libpng themselves? The library is pure insanity if all you care about is getting the image out in some format.

I'd wager that there is one libpng and then only about 4 or 5 distinct pieces of code that use it that everyone else in turn is using. If that code is wrong, that would still make it widely vulnerable.

<comment><USER13> Github search: png_get_PLTE

        C    48892
        C++   2916
        Obj-C   36

Apple programmers aren't using it directly at least. Nor Android, which is not exploitable[1]. Chromium also uses SKIA I believe. The C number is obviously inflated by the number of repositories that contain a copy of libpng.

If everyone is using common glue code then I think it's more likely this won't be a problem since the middleware library probably noticed the bug and works around it. It's when developers hastily reinvent the wheel that sloppy validation bugs like this are problems. It's why the maxim "never write your own crypto" exists. Or as Mark Twain said[2], "put all your eggs in one basket and _watch_that_basket_."

But as I said, there's no actual buffer overflow in libpng. This is a validation bug. The headline and the NVD summary are misleading.

[1][https://android.googlesource.com/platform/external/skia/+/ma...](https://android.googlesource.com/platform/external/skia/+/master/src/codec/SkCodec_libpng.cpp#171)

[2]maybe

<comment><USER15> Ah, that's what I came to the comments to find out, having just heard about an Android vulnerability in Chrome. The way the news of that vuln read (that one just needs to visit a web page) I thought this vuln would certainly fit that description.

</comment></comment></comment></comment><comment><USER16> From CVE:

>and 1.6.x before 1.6.19

Unfortunately, the latest version on libpng site [0] is 1.6.18.

Why was this CVE announced before the patch and version update was released?

[0] [http://www.libpng.org/pub/png/libpng.html](http://www.libpng.org/pub/png/libpng.html)

<comment><USER17> Actually, the patch was announced before the details of the bug: I subscribe to the libpng mailing list, and got about a day's notice to ship the patch out before the CVE and associated details were widely publicised. They did a good job of notifying us quickly, before there was chance for the 'bad guys' to jump on my customers.

<comment><USER18> One day isn't really long enough. I see there is no update for Centos 6 as yet.

</comment></comment></comment><comment><USER19> Do I understand correctly that for this to be potentially exploitable, the application must allocate too little memory for the palette? In other words, could this be mitigated on the application side by always allocating at least enough memory for a 256-entry palette?

I don't mean to suggest that this is "really" an application bug or that people shouldn't upgrade libpng ASAP; I'm just wondering whether there are other options for installations/applications where that would be painful for some reason.

</comment><comment><USER20> I wonder if this was found by fuzzing or inspection, because the former seems a quite popular method recently.

<comment><USER21> The bug was found with American Fuzzy Lop from optipng ([https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=787647](https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=787647)) and later the optipng author noticed that the same bug also affects libpng ([http://sourceforge.net/p/png-mng/mailman/png- mng-implement/t...](http://sourceforge.net/p/png-mng/mailman/png-mng- implement/thread/CA%2BPdXcuhLXJ89s6qjOEcm%2B99eWLmPBFcYSwcwJkajkLrNRLTeQ%40mail.gmail.com/#msg34581085))

</comment></comment><comment><USER22> What are the practical implications of this?

<comment><USER23> No input validation in the IHDR as to the number of bits in the palette of the image. As I understand it, you just create an arbitrary image with the palette in the IHDR tweaked to a large number of bits, and watch as the process dies while trying to malloc() enough space to handle a palette that large.

[http://seclists.org/oss-sec/2015/q4/264](http://seclists.org/oss- sec/2015/q4/264)

<comment><USER19> I think it's the other way around: the malicious image specifies a _small_ bits-per-pixel value in IHDR (thus in some sense advertising that the palette will have 2^bpp entries) but then contains a palette with more than 2^bpp entries, which libpng will copy in its entirety when asked to read the palette, overflowing the destination buffer if the application only allocated enough memory for the expected number of entries.

<comment><USER24> _If_ that's the case, _and_ bpp is always 8 or less, then software where the programmers were "lazy" and always allocated 256 entries for the palette might not be vulnerable.

From a quick search in MXR ([https://mxr.mozilla.org/mozilla- central/](https://mxr.mozilla.org/mozilla-central/)) for the identifiers "png_set_PLTE" and "png_set_PLTE", it seems that at least Mozilla (Firefox) did the lazy thing and always allocated 256 entries.

Edit: I was right, from [https://bugzilla.mozilla.org/show_bug.cgi?id=1224244](https://bugzilla.mozilla.org/show_bug.cgi?id=1224244) "Mozilla is not vulnerable to the security issues that it fixes, when using either the in-tree libpng or the system libpng."

</comment></comment></comment></comment><comment><USER25> Right, so the announcement is kind of vague; let's see what's actually going on. Here are the recent commits to libpng:

[https://github.com/glennrp/libpng/commits/libpng16](https://github.com/glennrp/libpng/commits/libpng16)

The first/latest one ("avoid potential pointer overflow") sounds scary, but I believe it's just about the pathological case where the library is handed (valid) buffers that extend to only a few bytes away from the maximum possible value (i.e. 0xfffff...). If your OS does this, it probably shouldn't.

Going down the list, there are three relevant-looking commits. Listed in chronological order:

[libpng16] Reject attempt to write over-length PLTE chunk [https://github.com/glennrp/libpng/commit/81f44665cce4cb1373f...](https://github.com/glennrp/libpng/commit/81f44665cce4cb1373f049a76f3904e981b7a766)

[libpng16] Prevent reading over-length PLTE chunk (Cosmin Truta). [https://github.com/glennrp/libpng/commit/a901eb3ce6087e0afee...](https://github.com/glennrp/libpng/commit/a901eb3ce6087e0afeef988247f1a1aa208cb54d)

[libpng16] Silently truncate over-length PLTE chunk while reading. [https://github.com/glennrp/libpng/commit/1bef8e97995c3312366...](https://github.com/glennrp/libpng/commit/1bef8e97995c33123665582e57d3ed40b57d5978)

\- The first one only substantively changes png_write_PLTE, so it could only be an issue for applications that actually write out PNGs. It changes a check on the 'num_pal' argument from a hardcoded 256, aka PNG_MAX_PALETTE_LENGTH, to be based on the bit depth. The png_write_PLTE function is internal and called only from png_write_info, which passes it 'info_ptr->palette' and 'info_ptr->num_palette' as 'palette' and 'num_pal', respectively.

\- The second one confusingly changes png_write_PLTE again, but just to rename a variable. The substantive change is a similar check on an argument to png_set_PLTE, which is a _public_ function and, incidentally, the only thing that can set 'info_ptr->num_palette', unless the application accesses it directly, which is deprecated. (Thus, outside of the deprecated case, it should ensure that the behavior change in the previous patch never actually gets exercised.)

\- The third one adds yet another check, to png_handle_PLTE, which is called when reading a PLTE chunk in a PNG file - this time, the variable is called 'num'. After the check, 'num' is used to fill an array of size PNG_MAX_PALETTE_LENGTH - but there was already an earlier check for the length being too much for that, in which case it may longjmp out of the function with png_chunk_error or just return. png_handle_PLTE then calls png_set_PLTE with the same argument, so, in lieu of the added check, the previous commit's check would still trigger and fail the image load. The new check just changes an error into something the library might be able to recover from.

So the second commit is the important one, and the third demonstrates how png_set_PLTE can be called while reading a PNG with a size argument greater than appropriate for the bit depth, but still <= PNG_MAX_PALETTE_LENGTH. What happens then? The oss-security post says:

> Some applications might read the bit depth from the IHDR chunk and allocate > memory for a 2^N entry palette, while libpng can return a palette with up to > 256 entries even when the bit depth is less than 8.

So are only applications that do something odd affected? The png_get_PLTE function gives the client the actual num_palette value as an out argument, so any client that uses that to size buffers wouldn't be affected; nor would one that hardcoded 256 or PNG_MAX_PALETTE_LENGTH. For example, Skia does the latter in SkImageDecoder_libpng.cpp.

Are there any libpng-internal uses that could be affected? I grepped for '->(num_)?palette\b'. TLDR: I don't think so, but if you want the pointless detail, among other less interesting uses were:

       /* Report invalid palette index; added at libng-1.5.10 */
       if (png_ptr->color_type == PNG_COLOR_TYPE_PALETTE &&
          png_ptr->num_palette_max > png_ptr->num_palette)

num_palette being too high could only make this fail, so it doesn't matter.

png_image_read_header uses it to set image->colormap_entries, which has its own long list of uses. I think this is then used (by the application, via PNG_IMAGE_COLORMAP_SIZE) to determine the size of the colormap buffer, but there may be an issue somewhere.

png_image_read_colormap uses it to generate actual color map data, but this is not obviously dependent on the bit depth, and checked against image->colormap_entries (…in case it changed from earlier?).

png_set_quantize uses a user-specified num_palette value and in any case is not important functionality.

Some PNG_COMPOSE code uses num_palette to write to palette; not a problem…

png_do_expand_palette just looks up entries in palette (png_ptr->palette) by byte-sized indices without checking anything. The palette buffer must be at least 256 entries long, or else it will read out of bounds, which is presumably why ->palette is only set here:

       /* Changed in libpng-1.2.1 to allocate PNG_MAX_PALETTE_LENGTH instead
        * of num_palette entries, in case of an invalid PNG file or incorrect
        * call to png_set_PLTE() with too-large sample values.
        */
       png_ptr->palette = png_voidcast(png_colorp, png_calloc(png_ptr,
           PNG_MAX_PALETTE_LENGTH * (sizeof (png_color))));

(it's set differently in the dither case, which I don't think is relevant?) Anyway, it's not affected by this.

png_handle_tRNS and png_handle_hIST have separate arrays whose count is expected to be <= and ==, respectively, num_palette.

\- For trans, the 'trans_alpha' buffer itself is always PNG_MAX_PALETTE_LENGTH sized, so there can be no overflow there; it also sets info_ptr->num_trans. This can affect the application if it uses png_get_tRNS.

\- The hist buffer is also always maximum size and doesn't have a separate length field, so it's covered by me checking uses of num_palette.

png_do_check_palette_indexes checks the bit-depth invariant separately.

hIST again in pngwrite.c and pngwutil.c, nothing else interesting in those files.

I think num_trans is safe in the same way, but I haven't looked as closely.

</comment><comment><USER26> Curious if this affects PHP. AFAIKT GD is compiled with libpng for PHP (it's required) and is presumably used for functions like getimagesize() in PHP. That is used by WordPress core for uploads (although you need to be signed in). However I suspect many plugins use GD for unauthenticated image upload, so this could have a wide impact.

<comment><USER27> If I'm reading this comment [https://news.ycombinator.com/item?id=10567353](https://news.ycombinator.com/item?id=10567353) and this code [https://github.com/libgd/libgd/blob/4751b606fa38edc456d62714...](https://github.com/libgd/libgd/blob/4751b606fa38edc456d627140898a7ec679fcc24/src/gd_png.c) correctly, then it looks like GD isn't vulnerable since it uses num_palette to size the palette rather than info_ptr->palette or bit_depth

</comment></comment><comment><USER28> Unlike, for example, heartbleed, a vulnerability in libpng really requires some contemplation to come up with all the places and ways that a typical production application uses the vulnerable code.

I have web applications that probably use libpng five different ways, each from a different client application and libpng version.

</comment><comment><USER29> This vulnerability is quite ... foretold. We have had issues with image libraries before. Instead of just running about patching again for this one bug, why not use the opportunity to discuss some architecture-level approaches that may have mitigated this attack?

Knowing that image libraries may contain vulnerabilities, how would you design a secure image ingestion process?

Some reasonable strategies...

(0) Attack surface minimization: Similarly to other types of input, input is segregated and treated as toxic and dangerous until proven otherwise. (Eg. Don't store random inbound files where you store those you will re-use; never allow batch processes to touch temporary files received from external systems; delete external input as soon as possible; store input only after normalization)

(1) Attack surface minimization: only accept one file format. This provides no guarantees but helps to limit exposure to unknown vulnerabilities, though may not always be feasible.

(2) Parallelization (opposite of the above): explicitly convert all formats of input to some common format (using throwaway containers/VMs), ideally using multiple versions of multiple libraries on multiple operating systems, and compare the results. If the results of every environment do not match, raise an alarm and do not continue processing.

(3) Reverse-conversion check. Convert the file to another (non-lossy conversion possible) format, then convert it back (also in a throwaway environment). If the result matches (or the portion of the result that is non- lossy matches) continue. This could be combined with #2 for additional strength.

(4) "Application-level firewall" approach: progressively determine the various format-specific and general properties of the image in question (eg. starting with libmagic; and preferably all in relatively secured throwaway environments, using the above strategies!) then apply a neural network or basic statistical analysis to generate alerts for anomiles. For instance, the reduced pallette featured in this attack would not be normal for many types of image input (scans or photographs come to mind). Other useful checks may include "are the image dimensions sane?", "is the aspect ratio sane?", "is the image predominantly black and white?", etc.

Strategies #0 (in particular cases), #1 (with some luck), #2, #3 and #4 (with some luck) could have mitigated this attack. Executed wrongly, any of those strategies could also have triggered the vulnerability. #4 is ripe for a web2.0 Silly-Valley outsource-the-problem startup (investors?).

PS. I enjoy these types of problems; anyone looking for ideas or development get in touch.

</comment><comment><USER30> Ah memories of flashing the PSP through an exploit in libtiff and ChickHen. Perhaps people could do something similar with libpng?

</comment><comment><USER31> To assess the impact of this I would really need to know a few factors (ball park)

What fraction of applications that read png images use libpng?

How many of those applications have features that load 3rd party images (uploadable avatar etc)?

My gut feeling is that the most common usage is for loading things like UI elements, and not for external images? Are such programs safe from exploitation?

</comment><comment><USER32> Where does one get the patched libpng-1.6.19? The libpng site is broken for me right now.

<comment><USER33> [http://libpng.sourceforge.net/index.html](http://libpng.sourceforge.net/index.html)

<comment><USER13> Sourceforge also seems to be under heavy load. I found this mirror:

[https://github.com/glennrp/linpng- releases](https://github.com/glennrp/linpng-releases)

[https://github.com/glennrp/libpng](https://github.com/glennrp/libpng)

</comment></comment></comment><comment><USER34> I just compiled libpng-1.6.19, and then I read this post right after. XD

</comment><comment><USER35> how about a sample "dangerous" png image?</comment>


Ask HN: server security intro/reference? - <AUTHOR>

I'm just starting out in server land. Prior to this, everything I've built has been on top of an infrastructure that someone else secured and maintained.
Last couple days I've been perusing security related posts here, and following links.
And I have to say: gaaa!
Admin/security is a firehose.
My problem is that waiting until I know that I know enough would mean that I'll never get anything done, I'll always be waiting to be better. In development the idea of waiting to learn something until you need it makes sense. In admin/security that approach can be fatal.
What I'd like to see, if you're aware of any, is a resource or resources that allow you to approach things with a strategy of layered importance. An overview of where you're going, where the details are then arranged as:

  - If nothing else, do these few N things first and absolutely.
  - Next, certainly do these things as soon as you can.
  - Finally, for uber control and confidence, consider these.
 I guess knowing how people break things down into categories and areas of focus would be helpful too.
The question is mainly about server security, but if you want to throw something in about app security/integrity, and recovery from a server or app breach, that would be appreciated too.
Thanks. I think I'll go breath into a paper bag for awhile.
[edit: formatting] <comment><USER2> Yes, it is a very complex field of study. I am able to sleep at night by following as many of the best practices that are out there, even those I don't think apply to me.

For checklists, look at the NSA's guide to hardening computers. You should also know exactly what services are running on your server, and dig hard through their manuals to learn more about how to secure them. Mysql, for instance, has 4-5 good tips on how to secure it which are in the security section of their manual.

Finally, don't run services that aren't updated or aren't used. Reduce your potential attack vector to as few known points as possible, so that you can harden those points. Have a web server up? Turn off apache mods that you don't use. THat kind of thing.

Turn on logging. Log everything. Check that you know how to analyze your logs. Make sure to rotate them as well -- opening 2GB files b/c you didn't rotate them daily sucks.

Disaster recovery is a huge part of this. Think of it this way -- you're not a big target (I can tell b/c a big target would already have experts in this field). Chances are good that you have an exploitable part of your web app / site / server. You probably won't know of its existence until after an attack. At that point, you need to be ready to roll EVERYthing back to a known clean point. This is not an easy thing to do, so make sure you practice it.

Those are just a few off my head.

</comment><comment><USER3> "gaaa!" is an entirely legitimate response to this and the same one I had when I looked at it in the middle of last year (and I've been playing the game since 1980 (sic), but not since 2000 ... the threat environment has exponentially increased since then).

I'm afraid my only recommendation is not immediately useful, which is to start reading/skimming a 1,000 page book, _Practical Unix & Internet Security_, 3rd Edition by Simson Garfinkel et. al. ([http://www.amazon.com/Practical-Unix- Internet-Security-3rd/d...](http://www.amazon.com/Practical-Unix-Internet- Security-3rd/dp/0596003234/)).

But's that reference is only "a mile wide and an inch deep* (from the Amazon.com reviews).

How much time do you have? How much flexibility in choosing your OS (e.g. is OpenBSD or a Linux that really implements SELinux an option)?

And there are _so_ many details today, like how do you get adequate entropy for your RNG on a VPS?

Gaaa!

<comment><AUTHOR> "But's that reference is only 'a mile wide and an inch deep'"

So maybe that's an overview/jumping off point?

I've run FreeBSD at home years ago. I'm on slicehost for now, the and linode offer mainstream-ish linux.

My concern with *BSD, or a less mainstream Linux, is the difficulty it may introduce in developing and running apps based on the many ready-made tools and frameworks available. Good security vs easy development. "Gaaa!"

<comment><USER3> If I was starting fresh, that would be my jumping off point. It will orient you, it develops a good philosophy and it will allow you to build your own priority ordered lists (which you probably won't be able to find as such, since things are so unstandardized (and therefore exciting!) right now), and then you'll know what to drill down to with Google et. al.

And, yep, you've outlined one fundamental tradeoff, but in server space this should be less of a problem. But I wouldn't be personally adverse to starting out with a distribution with a serious SELinux implementation (e.g. Fedora, but that has an upgrade problem). Of course SELinux just by itself is somewhat complicated, but it's the only defense in depth solution I know of. And I want one of those in addition to making the "crusts" as hardened as possible.

One thing I'd think strongly about is getting one foundation in place ASAP: disaster and intrusion recovery.

Just like the second thing I do after "Hello, world!" in a new programming project is to set up a good logging system, being able to recover from "man caused" and other disasters will help you a lot until you're a Uber Security Guru.

Ask me if you're responsible for keeping customer information secure ... that's its own can of worms and one that's I've worked on myself.

<comment><AUTHOR> "Ask me if you're responsible for keeping customer information secure ... that's its own can of worms and one that's I've worked on myself."

I'm one guy, building a web app up from nothing. So yeah, I'm responsible. :-/

My initial approach is to never have a CC number touch my server, and to absolutely limit the amount of information I need from users. Nevertheless, I do want my users' data to be as private as they make it, and I don't want to find myself hosting inappropriate stuff from breakins or "users of convenience."

<comment><USER3> You've got the right ideas. (And I've been there WRT to the "users of convenience", not fun but one of the less harmful attacks ... unless they use you to spam.)

There's the usual set of things to do with your less sensitive user information: salt and hash passwords appropriately, make your password reset system sane (non-obvious security questions if you go that route), and then as a first step I'd just harden the data on-line. Perhaps encrypt the disk copies so that simply grabbing files won't be sufficient, raise the bar sorts of things.

Simson's book very quickly goes into policies: risk assessments, trade-offs, all that. Get minimally organized there and you can then do something like this:

      What's the threat level?

      What's the cost of compromise?

      How much effort should I put into this?

Then what you should do will be more obvious.

Oh yeah, one thing I forgot to add, in relation to Travis and my suggestions about recovery: have some minimal automated intrusion/modification checks, so you'll have a chance of knowing your system has been compromised.

<comment><AUTHOR> Thanks lots. Encouraging to know, based on responses, that I'm thinking in some of the right directions.

ocean large, boat small

<comment><USER3> You're very welcome.

A lot of this is just common sense and thinking things through ... you've already made the only step that _really_ matters, which is taking the issue seriously and proactively.

Good luck, and if you have any specific questions in the future I'm always game; my email is in my HN profile.</comment></comment></comment></comment></comment></comment></comment>


AnandTech: The Real Story on iPhone 4's Antenna - <AUTHOR> http://www.anandtech.com/show/3794/the-iphone-4-review/2

<comment><AUTHOR> This is a link to page two of the article, which talks about the antenna.

Summary:

* The bars display is _EXTREMELY_ misleading.

* Holding the phone can result in a drop of 24 dB

<comment><USER2> That's only half the story. Other important bits:

* Improved iPhone 4 baseband hardware performs significantly better than iPhone 3GS in areas with very low dBm. The 3GS dropped or failed to place calls at -113dBm, whereas iPhone 4 works fine. Quote: "There's no doubt in my mind this iPhone gets the best cellular reception yet, even though measured signal is lower than the 3GS."

* Signal quality should be measured in terms of Signal to Noise Ratio (SNR), which "is essentially a measure of how much of the signal is compromised by noise or interference" instead of dBm, which is merely a measure of power. This distinction is important because, since "the iPhone 4 works almost perfectly fine at -113 dBm, it has much better sensitivity."

* "The drop in signal from holding the phone with your left hand arguably remains a problem. Changing the bars visualization may indeed help mask it, and to be fair the phone works fine all the way down to -113 dBm, but it will persist - software updates can change physics as much as they can change hardware design. At the end of the day, Apple should add an insulative coating to the stainless steel band, or subsidize bumper cases. It's that simple."</comment></comment>


Elon Musk: Tesla Charging Locations Will Be "Virtually Everywhere" - <AUTHOR> http://www.fool.com/investing/general/2015/03/25/elon-musk-tesla-charging-locations-will-be-everywh.aspx

<comment><USER2> Seems that there's a new meaning of the phrase "miles per hour":

"these chargers can provide a charge rate of up to 58 miles per hour for Model S equipped with a second onboard charger or about 29 miles per hour for those with a single onboard charger"

Very interesting.

<comment><USER3> That's always the way Tesla has quoted charging rates -- much more meaningful than kilowatts.</comment></comment>


Very very Essential : Improved font rendering on Fedora using Infinality patches - <AUTHOR>

I was so sick and tired of the font rendering in Fedora (currently using 17).
Downloaded and used MS truetype fonts, but still, it sucked. I used to boot to Windows, just so I could read Hackers News without wanting to gouge out my eyeballs.
Today, randomly searching on setting the best terminal font, I stumbled upon the Infinality patches.
I did not expect much, judging from how little people have mentioned it, but after a restart, now the font rendering is so, so beautiful. The fonts look a thousand times better.
I would specifically like to mention that the first thing after installing Fedora should be to install these patches, and that's what I'll be telling everyone to do. I wonder how I even managed to work on Fedora 13-16 with the default font rendering. :|
Link: http://www.infinality.net/blog/infinality-freetype-patches/
Edit: removed <p> tags that automatically replaced blank lines <comment><USER2> freetype-freeworld from RPM Fusion will give you Ubuntu like fonts, which I find better than Infinality.

I think it's ridiculous how Fedora ships with such ugly fonts out of the box. It's horrid.</comment>


From the co-creator of OpenSSH: Dsniff 3000. (Now go change your password.) - <AUTHOR> http://dsniff.org

<comment><USER2> The page is content-free right now.

<comment><AUTHOR> If a description and links explaining something eg. a new network monitoring tool [1] don't constitute content, then by that measure sites like Delicious and Wikipedia are also content-free. :)

[1] <http://monkey.org/~dugsong/dsniff/></comment></comment>


Chromium's Hotword feature is being removed - <AUTHOR> https://code.google.com/p/chromium/issues/detail?id=500922#c31

<comment><USER2> Alternate useful title: Chromium is open source again.

The source code was not previously available. The portion that listened to the microphone for a phrase was closed source while the rest was open source.</comment>


Ask HN: Whom do you admire most? - <AUTHOR> <comment><USER2> People who survive hardships that I can't even imagine undergoing, yet retain a generous and optimistic outlook on life.</comment>


Physicists: Universe Almost Certainly Not a Hologram - <AUTHOR> http://www.wired.com/wiredscience/2011/07/hologram-universe/ <comment><USER2> If you want some really wacky stuff, try this: The Multiverse Interpretation of Quantum Mechanics - Leonard Susskind and Raphael Bousso

<http://arxiv.org/abs/1105.3796>

By the way, this ain't your daddy's multiverse. This is a whole new and extended multiverse theory which says that the multiple universes used to explain tuning of constants and the multiple universes used to explain quantum decoherence are THE SAME THING!

Then, for balance read this guy who thinks they're on crack:

[http://motls.blogspot.com/2011/05/bousso-susskind- hypermulti...](http://motls.blogspot.com/2011/05/bousso-susskind- hypermultiverse.html)

<comment><USER3> Motl thinks everybody is on crack.

<comment><USER4> "Even in classical physics, dice may have probabilities 1/6 for each number, but once we see "6", we update the probabilities to (0,0,0,0,0,1)."

It is obvious that he himself is on crack. I couldn't read past that gibberish.

<comment><USER5> That is a correct reasoning. In classical physics, as everything is predetermined, no real probabilities exist. We use probability theory to gauge our uncertainty about the world.

If you knew the position of every particle in the dice, there would be no distribution of side, it would always come up the same. But we don't and can't know everything, thus we use probabilities to express that. If you throw the dice, your uncertainty drops because you know the outcome of the experiment.

<comment><USER6> Yes, but is he assuming that all initial conditions are known when it hits 6 while also assuming classical theory? If he is, fine. If he isn't, he updated wrong.

</comment></comment></comment></comment></comment><comment><USER7> The title goes a bit too far. The new experiment doesn't rule out the Holographic Principle, it rules out Craig Hogan's model, which was inspired by the Principle.

</comment><comment><USER8> The title can be a little misleading to the lay reader, almost to comical effect. But this is actually a pretty significant finding w/r/t its implications for current theories in physics.

<comment><USER9> Can you clarify something? This article reads as though energy can't be quantized. Am I misreading the article, or is that an open question now? (Or was it always an open question, and I never understood Planck's Constant correctly?)

<comment><USER10> I believe that the Holographic Universe theory states that the quantization should be larger than the Plank Constant since the Plank Constant represents the quantization at the edge of the Universe. Everything inside the universe is a projection of the information on the edge and therefore is blurrier and has a higher quantization limit.

<comment><USER4> the black hole entropy

[http://en.wikipedia.org/wiki/Black_hole_thermodynamics#Black...](http://en.wikipedia.org/wiki/Black_hole_thermodynamics#Black_hole_entropy)

clearly points to some factorization of physically possible 3d volume structures to closed 2d boundary of it. The reverse relation isn't even proven to be 1:1, thus it can't even remotely be called a projection. Ok, lets suppose it is 1:1 and call the reverse a "projection". Still, any narrow/specific interpretation of that factorization relationship and its reverse, like for example the Holographic Universe's projection in any geometrical/group theory quasi-straightforward sense, just doesn't have any basis for it (ie. there is no any known reason to favor any given interpretation over any other yet). Thus it is no surprise that the experimental data doesn't support and contradict that given interpretation.

</comment></comment></comment></comment><comment><USER11> I believe they're referring to the holographic principle (<http://en.wikipedia.org/wiki/Holographic_principle>)

</comment><comment><USER12> What a terrible headline. It's indicative of the poor state of science reporting.

</comment><comment><USER13> This was an onion headline years ago, I'm sure.

</comment><comment><USER14> "Computer, end simulation!"

Just to be sure...

<comment><USER15> I believe the proper phrase is "Computer, arch."

</comment></comment><comment><USER16> Damn! My start-up idea was to sell glasses that allowed you to view the holographic structure of the world.</comment>


SQRL: Secure Quick Reliable Login - <AUTHOR> https://www.grc.com/sqrl/sqrl.htm <comment><USER2> [sigh]

Steve Gibson, the man who claimed Windows raw sockets would destroy the internet and doesn't understand how SYN cookies can stop DoS attacks has a solution for all my authentication and authorization needs? Well hot damn, let me click past his impassioned plea that the world needs hand coded x86 assembly disk utilities in 2019, and see what he has to say...

...And 2 pages into the PDF I'm out.

The sole thing keeping Steve Gibson from being this weeks Dunning-Kruger poster boy of technical security bullshit is that is someone decided to sue Blackhat after claiming numerology breaks modern crypto.

Snark and bitterness aside, Please stop giving this man a platform. It's hard enough getting organizations to make a rational cost benefit analysis based security decisions. His noise is making things worse.

</comment><comment><USER3> Good lord. That page is like something out of the late 1800s. I expect some guy with a tophat and a waxed mustache to pop up saying "What you got here is a bonafied, superfied, securitized login experience."

SQRL may be great, but presentation counts. Presenting documentation as giant PDFs with no internal linking?

But I really got turned off when I read that it only does single-factor login.

<comment><USER4> Wouldn't it be dual factor by default? You need your device with sqrl and you need a password to use sqrl.

So it's something you know and something you have.

</comment></comment><comment><USER5> So I've been listening to Security Now for years, and SQRL has been something I've followed along with. But I never see it discussed elsewhere.

Is there some fatal flaw with Steve's idea? It sounds great to me, but I'm no cryptographer.</comment>