Forgot your password?

Comment: PCI TL;DR (Score 1) 348

If credit cards are involved, then PCI-DSS guidelines are almost certianly mandated by merchant agreements.

PCI-DSS guidelines say, among other things that firewals are required, and that they have to be in their most restrictive ("DENY ALL") configuration, with only the specific connectivity required being permitted.

Therefore, by extension, if this is a point of sale system, and credit card processing is happening on the same network, then by extension, the firewall is required by the merchant agreement, and not only required to be present, but also required to be locked down.

Comment: Community support is usually better support (Score 5, Insightful) 253

by caitriona81 (#47083275) Attached to: Ask Slashdot: Tech Customers Forced Into Supporting Each Other?

The quality of support you get from forums. mailing lists, and IRC channels is almost always far better than that directly provided by the company. Support teams that are competent enough to not just be warm bodies reading from a script simply don't scale well, because support employees at that level of competency expect (and deserve) to be paid as much as developers.

The vast majority of support queries on the other hand are repeats of the same questions, over and over again from customers who can't be bothered to use Google to search for their problem which means companies have to have a filter in place. That filter can be a forum, a web form that forces you to view every single article in the knowledge base, or a team of barely trained monkeys who are underpaid, and will burn out within 3-6 months from being asked the same questions over again by customers who are, on average, so dense that they don't mention the device in question isn't even turned on until they have already nodded along and gone through 30 minutes of "troubleshooting".

The use of community based support shouldn't itself be a concern, but how that support is implemented, how it's managed, and how the company uses that community based support to triage and escalate issues should be. In the most effective, and customer friendly cases, community support basically is used to to weed out the people who can't bother to help themselves from the people who have real problems, and the latter will get real support from "power users" or even actual developers.

The key to making that work in favor of the customers that actually need help is good moderators. They need to be jaded, vicious bastards who will stamp out any hint of noise amidst the signal, who aren't afraid to humiliate someone who posts the exact same question without reading the post directly below it where someone else asked the same thing.

All of this, should of course be accompanied by the best paid support you can find, at whatever rate allows you to pay your support staff a good (at least $25 USD/HR) wage plus medical, mental health, sick days, vacation and other benefits, and generally keep them happy. This should be a "tierless" support team if at all possible - the people you put there should be able to handle anything that comes their way, or act as a liason between customer and developer when necessary. The rate for this level of support should be high enough that your support team shrugs off people asking "dunb" questions as suckers who wasted their money rather than banging their head in frustration.

Chances are, the same support people can be providing paid phone support and "escalating" cases from the forums for free support when it's needed & deserved. Everybody wins in this case - lazy people can pay to be lazy, people with no time to wait for a solution can pay for one, and people who are willing to work to find a solution can get the help they need free of charge.

Comment: Re:What about devices with no RTC? (Score 1) 187

by caitriona81 (#46997661) Attached to: Do Embedded Systems Need a Time To Die?

Simple enough. Skip the clock entirely, and let the battery itself be the "clock". The battery dies, and the device no longer operates. It's not particularly difficult to design a system with an embedded, non-rechargable battery that lasts for a specified lifespan. There may be some variability in that time, but you can get close enough this way to kill off neglected devices by a certian point.

Comment: Real problem but wrong solution (Score 1) 187

by caitriona81 (#46997639) Attached to: Do Embedded Systems Need a Time To Die?

1. From a security standpoint, in a highly controlled environment, remote update capability is also a security risk, no matter how supposedly "secure" that capability is. The ability to configure the hardware so that hands on thr device are required to apply updates is important. Physical security is easier to verify than logical security - it's much easier to inspect seals, padlocks, and security tags than it is to inspect the device firmware.,
2. Flash memory is relatively cheap, especially in the small sizes needed for firmware. The hardware required to read formware from a removable memory card is relatively inexpensive compared to the total retail price of most embedded hardware, even consumer-grade embedded hardware. Thus, firmware replacement through replacement of a compactflash/sd/microsd card is a viable option that can be easily designed in to these systems. The ability to remotely update that firmware could then either be omitted, or able to be disabled through jumpers, switches, etc.
3. Manufactuers need to recognize that hardware will last longer than it's designed, and will remain in service with someone for far longer than originally intended, and plan accordingly. Releasing the firmware and documentation under suitable free software / open source licenses from day one would be ideal, but if this isn't compatable with their business model, some form of code/documentation escrow process that gurantees eventual release of the code at "end of life" would be a viable alternative which would not significantly weaken their buisness model.

Comment: This is your password deal with it. (Score 1) 162

by caitriona81 (#46457157) Attached to: Top E-commerce Sites Fail To Protect Users From Stupid Passwords

I think the right strategy for websites which have to do user registration is to just provide the user with a random password of sufficient length as to be near impossible to type correctly, much less remember, and don't even provide the functionality for users to select their own. This almost insures that the password won't be used elsewhere, it enforces password quality, and it encourages the use of a good password manager.


Porn Will Be Bitcoin's Killer App 216

Posted by timothy
from the we-call-this-the-duh-factor dept.
An anonymous reader writes "In December, started accepting Bitcoin for its premium services, and the virtual currency quickly came to account for 10 percent of sales. At the start of January, a post on Reddit's Bitcoin subforum boosted the figure to 50 percent, before settling down to about 25 percent. The tremendous interest has led David Kay, the marketing director at's parent company Sagan, to talk very positively about the virtual currency: 'I definitely believe that porn will be Bitcoin's killer app,' he told The Guardian. 'Fast, private and confidential payments.'"

Comment: Re:Yes. (Score 1) 631

by caitriona81 (#44945975) Attached to: Ask Slashdot: Are We Witnessing the Decline of Ubuntu?

Nobody is forced to use Unity *yet*, but the alternatives are clearly treated as second class citizens that do not get the same level of attention to detail or integration, and makes for a substandard experience that's increasingly a throwback to the days where Linux on the desktop was *only* for geeks. With Mir on the horizon, and with many developers targeting Ubuntu specifically rather than Linux in general, that situation threatens to get worse, as we could conceivably have a large pool of software with Mir+Unity as hard dependencies very soon.

Comment: Sparkleshare, git, and git-annex (Score 1) 238

Sparkleshare ( is a "transparent" front end for Git which turns it into a simple file sharing tool. This would probably be appropriate for most of the actual "file sharing" applications the OP mentions (gaining many of the advantages of Git while keeping the complexity hidden until its needed), while obviously any source code fprojects should find their way into some kind of version control repository, probably Git as well, with TortoiseGit ( being a fairly compelling solution for a Windows shop.

The learning curve isn't particularly steep here, an hour or less should bring someone up to a functional level with Git, and even though it does have a little trouble working with binaries effectively, particularly large ones, but that's a problem common to most version control systems. git-annex ( might provide a serviceable workaround for large binary "assets", depending on your workflow, but I haven't used it myself.

Comment: Warrant canary. (Score 5, Informative) 397

A more robust version of's "warrant canary" ( might help, if it were to become more commonplace, people would start to assume any provider not providing one to already be under gag order.

IANAL, but the legal theory is that while a gag order can make it illegal to speak out, it can't force someone to make falsified or fraudulent statements - any entity that has not already received a secret order is free to testify to that fact, and simply stop making that assertion at such time that they are compromised.

If this were made more robust, for example, key employees being videotaped undergoing a polygraph regularly where they are asked questions about the integrity of their service, it might just work. (I realize a polygraph isn't secure. For this purpose, however, it doesn't matter, because it provides a means to deliberately fail a test while having deniability of your intent to do so.

I'm sure similar creative ideas could be used :)


How To Monitor Leaky Radioactive Water Tanks 111

Posted by timothy
from the for-fun-and-profit dept.
freaklabs writes "The radioactive water leaks are getting worse at Fukushima Dai-Ichi. In a recent New York Times article, it was mentioned that TEPCO didn't have a reliable way to monitor the water storage tanks for leaks. I decided to write a tutorial on how to wirelessly monitor water levels in storage tanks."

Comment: Re:Forcing strong passwords in the first place. (Score 2) 211

by caitriona81 (#43575883) Attached to: Mitigating Password Re-Use From the Other End

1. Lastpass works across all the platforms you've named, and has it's own sync. Keepass works across all of them, and only needs some form of file sync (eg Dropbox). Firefox sync will get you 4 of the 5 (all except iOS).
2. Virtually all of the circumstances that allow someone to attack the keychain program also tend to permit the undetected installation of a physical or software keylogger. The attacker may not compromise your less frequently used accounts as quickly, but they will have everything you use on a daily basis. (Further, accounts you don't use on a daily basis may be forgotten about, a side benefit of a password manager is a checklist of what needs changed in the event of compromise.)
3. Backup processes apply to password managers, as do password reset processes, and use of a password manager does not preclude use of memorable passphrases for particular accounts, particularly for things like email accounts. Right now, I use passphrases + token codes for email, banking, and my password manager itself, passphrases stored in a password manager for accounts that I have to be able to retype the password (facebook, etc), and completely random passwords at the complexity limit of whatever site I'm registering for if I'm not having to sign on to them from any of my devices (random web forums, etc)., and a shorter, more "traditional" 8 character password for my desktop, where a brute force attack is more likely to be carried out by hand than against the password hash., and ease of typing (muscle memory) is desired.

Comment: Re:Forcing strong passwords in the first place. (Score 1) 211

by caitriona81 (#43575755) Attached to: Mitigating Password Re-Use From the Other End

This idea has strong potential, and a way that it can be refined is to offer the user a choice between a random set of password requirements that apply only to them, and change once every few days, and a random passphrase of the xkcd sort. So, you'd have the static rules (at least 16 characters, can't be similar to username, etc), and then you'd add 4 random requirements like:
- The 4th character must be a number.
- The 7th character must by a symbol
- The 2nd character must be an upper case letter.
- The 11th character must be a lower case letter followed by the letter 3 letters before it in the alphabet.
- Enter a password twice below that meets these requirements, or click here to choose the random password the system has chosen for you [fireball yelling slashed baseballs]

Password reuse impossible. Use of a password manager encouraged, and an option is still open for someone who feels the need to memorize. Because the ruleset is random, but can only be switched every few days, the user can't refresh until they find a set that their password is compatible with, and most users will take the easy way out and accept the random passphrase that suddenly looks a lot less scary, but is reasonably secure.

Of course, this is assuming that you actually have a compelling need to even have logins and passwords - if you aren't a financial (banks, credit unions, credit cards, brokerages, etc), healthcare or an email provider, or dealing with accounts for use inside your company, then you probably don't, and should encourage the user of persona or openid instead, rather than furthering the proliferation of accounts that users have to keep up with...

Comment: Webconverger (Score 1) 572

by caitriona81 (#43365655) Attached to: Ask Slashdot: Protecting Home Computers From Guests?

Webconverger ( is a livecd and USB stick bootable linux distribution for kiosk applications, which also puts it in the same territory as ChromeOS for guest access, only it will work out of the box on a wider range of hardware.

By design, it gives the user a tightly locked down, full screen Firefox browser, and nothing else, but it's somewhat configurable and even supports printing ( Out of the box, it supports the Flash and Google Talk Voice/Video plugins, so most if not all websites will work out of the box, and the user can even do voice calling and Google+ hangouts.

The with the exception of the couple of proprietary browser plugins mentioned above, the software appears to be entirely open source, and they offer a free version, subscription service to customize and manage it for you, or source code if you are comfortable getting your hands dirty. Overall, this looks like one of the easiest ways to provide a safe, controlled environment for your guests, locking them into a browser window where they can do what they want, but nothing will be saved. Given the plethora of cloud apps out there to serve as as substitutes for local apps, with a little creativity, this should be all anyone who doesn't bring their own computer will need.


Supreme Court Rules Warrants Needed for GPS Monitoring 354

Posted by samzenpus
from the get-your-paperwork-in-order dept.
gambit3 writes "The Supreme Court has issued its ruling in the case of Washington, D.C. nightclub owner Antoine Jones, saying police must get a search warrant before using GPS technology to track criminal suspects. A federal appeals court in Washington overturned his drug conspiracy conviction because police did not have a warrant when they installed a GPS device on his vehicle and then tracked his movements for a month."

Comment: Re:increasing signal to noise with business triage (Score 2) 360

This is great, and exactly what one organization I once worked for did. We had "business liaison" positions within every department, and "application owners", which were dual roles - these people were generally business users, with extra training so that they could work effectively to bridge between IT and the userbase. As part of these dual roles, they were included in the IT decisionmaking and change control process, so that they knew what was up before it happened, rather than finding out afterwards, and so that they could advocate for their department's needs ("You can't change payroll the day before we run it!" "Tuesday doesn't work because that's year end closing!")

We also filtered everything IT through the helpdesk, from change controls, to access requests, to outage notification & paging, to trouble tickets and support requests. Problems which weren't reproducible were stopped there. Things that seemed to be user education would either be handled by the helpdesk, or assigned to the appropriate business liaison to see if there really was a problem and gather more details. Remote control sessions were utilized by the helpdesk to gather screenshots. Intermittent problems were weeded out unless they recurred, in which case the previous calls were referenced to verify that this really was recurring. We leveraged our engineering and operations teams for troubleshooting when appropriate to gather logs. Only after we had concrete, conclusive details of a problem did something get passed to developers - and when we did, it was handled quickly, because we'd gathered all the information efficiently and correctly.

As a result, the developer teams were able to focus on fixing bugs, not triaging problems. The helpdesk always had ready access to all the relevant teams via phone, email, and instant messaging, and was well respected within them, because we were their filter, firewall, and front line, as well as their secretaries. (And we had the decisionmaking power as far as who got paged at 3am and who didn't!)

"Pascal is Pascal is Pascal is dog meat." -- M. Devine and P. Larson, Computer Science 340