Posts Tagged ‘douchebags’

iPhone to still not allow unsigned code execution

Friday, April 9th, 2010

When asked about whether or not the iPhone would allow execution of unsigned apps, like, you know, every other smartphone out there, Steve Jobs had this extremely amusing thing to say:

“You know, there’s a porn store for Android. Anyone can download them. You can, your kids can. That’s just not a place we want to go.”

Two points: firstly, for someone who claims to be adamantly against DRM, Apple sure loves locking down it’s devices.  Secondly, I’m not sure if Steve is aware, but you can browse porn sites in the iPhone’s browser.  Infact, I’d be willing to bet that the iPad would be an excellent porn viewer… oh right, no Flash, that’s right.

I also love how Steve completely avoids the question.  Then again, Apple is an extremely developer-hostile company, with no real good reason to be that way, which is disappointing.  But hey, at least the iSheep now have multitasking.  On the other hand, the GSheep have had that since day 1.

It would behoove me to say that the world would be much better off if Nokia grew a pair and started pushing the N900 aggressively.  Unfortunately, I don’t see it happening.

Sony “Software Assurance Signing Keys” to be released April 1

Monday, March 29th, 2010

Since Sony is an enemy of freedom now, it’s time to release the hypervisor security keys.  Since Sony cannot change these as they are burned into the IPL ROM which starts the supervisor SPE up, PS3 security is about to be non-existent.  Can we say custom firmware?  We sure can.

I can’t wait for the DMCA on this.

hpHosts is bullshit

Tuesday, March 23rd, 2010

No, really. So, apparently my website was listed in hpHosts because I had an archived copy of PSYB0T on my server so that people could analyze it.  To get it removed, I was forced to remove that content.  What a joke.

What makes it worse is that the guy who runs hpHosts is involved as a contributor to DroneBL, which linked to the malware and specifically said it was an archived version.

He had the gaul to call himself a member of the security community, even though a quick google of him only reveals a bunch of posts on spyware forums and dnsbl mailing lists.  People like him are the reason why the security community needs to stop doing crystal meth.

Also, fun fact: hpHosts is hosted on a bespoke SOHO ADSL line.  Haha.

Why Atheme no longer works with InspIRCd when m_invisible is loaded

Monday, March 22nd, 2010

As of a couple of days ago, we put some checks in designed to block casual usage of the m_invisible module in InspIRCd on Atheme-running networks.  As certain InspIRCd contributors view this is a troll, I would like to explain why we are in fact quite serious about this.  The remainder of this post will be split up into two sections, explaining why m_invisible is morally unacceptable, and why m_invisible is impossible to enforce in Atheme anyway without complicating the code base extensively.  The remainder of the post after that will include a point-by-point rebuttal of some of the more amusing things that contributor has said in the last day.

The moral argument for removing m_invisible from InspIRCd

The module in InspIRCd named m_invisible.so allows you to join channels invisibly and spy on the users.  Granted, there are plenty of other methods that allow this, however m_invisible makes it accessible to the average user who is unaware of the other options.  In other words, this means that it makes this wholesale spying capability available to at least 80 percent of InspIRCd’s userbase.

Consider for a moment, a situation where users trust their network staff, but the network staff have recently done something to make them upset, so the owner of the network joins the channel and starts watching people vent.  Since he is watching them vent about whatever it is that he has done, he gets angry and starts placing autokills against his users.  While it is the administrator’s service, and he has every legal right to do so, it is not an ethical or moral thing to allow happen.

Another scenario, which has recently happened, is that an IRC server was infiltrated by the Chinese secret police.  Many users on this IRC server were monitored without consent using m_invisible, resulting in at least two people being apprehended due to participating in dissent activities.  If you don’t know how the Chinese secret police operate, I’ll summarize it: those people are most likely dead now.  While this scenario is not directly the fault of m_invisible and the surveillance could have been implemented in other ways, m_invisible was the simplest way to implement it, which brings me to another point, if you have to enable this module on your network, make sure you trust your staff entirely.

I brought this last point up with Brain, the project leader of InspIRCd after he flamed me on MSN due to the changes I implemented.  He did not seem to be affected by the fact that there are now two people most likely dead over events that happened during IRC surveillance, and accused me of being the “moral police”.

Moral police or not, those people died because of the fact that InspIRCd made it possible to easily spy on them.  While it is possible that they would have died anyway, the method that was used to intercept their communications was provided as a module in InspIRCd.

Ultimately, to us, we view this as a moral question.  Because Atheme is a middleware used on many InspIRCd networks, we felt that we had the need to stand up and say “we don’t want our software used in this specific configuration.”   Regardless of whether or not you agree with our position, it is our right to politely ask our users to comply with that.  There is nothing in the license forbidding the usage of Atheme in this specific configuration, so if you want to remove the checks, then that is your own business, but at least make sure the staff you have on your network are respectable.

Why m_invisible will never work correctly with Atheme

Now on to the technical reasons of why Atheme no longer works in this configuration: it is impossible to support the configuration properly without changes that the developers are unwilling to make due to code correctness and the moral issues outlined above.  As an example, if you place the *!*@* mask on +V in the channel ACL, it will auto-voice the invisible user when they join.  If you feel the network you are on is spying on you, but you cannot leave, we recommend that you place *!*@* on autovoice, which will expose the invisible users.  You can also kick the users if you can guess their nickname.

The technical reason is grounds enough to disable support for m_invisible in Atheme.

Counterpoints

13:34 <~Brain> hes doing it the same reason hes always stirred up trouble, to get publicity for atheme and charybdis.

The IRC community generally knows that I don’t actively market Atheme or Charybdis, and allow them to stand on their own merits without the necessity of spamming, doing SEO or anything else.  Atheme’s popularity stems from our reputation of code correctness and realistic feature support.

13:32 <~Brain> Taros: then i say that your view of irc is very closed minded and restricted only to the public-network views that youve seen, havent you ever seen a closed support network? they log *everything* for accountability.

Professional support desks typically use Kayako LiveResponse, which is not built on top of IRC at all.  InspIRCd plus an IRC client does not come anywhere near the capabilities of Kayako, period, so it seems unlikely that anyone would use it for this purpose.

11:14 <~Brain> hmm, i could fork it.

There are plenty of other Atheme forks out there, so good luck!