THP Semifinalist: Secure Your Internets With Web Security Everywhere

[Arcadia Labs] has created a great little device in Web Security Everywhere, a semifinalist in The Hackaday Prize. At the center of it all is UnJailPi, a Raspberry Pi device which can act as a secure router between a protected network and the unprotected internet. UnJailPi can create OpenVPN and Tor connections on the fly from its touch screen interface. The full details are right up on [Arcadia’s] Hackaday.io project page.

One of the most amazing things about the project is its creator, [Arcadia Labs]. [Arcadia] started from square one learning python just 1 year ago. Since then he’s become a proficient python coder, and created UnJailPi’s  entire user interface with pygame.

[Arcadia] is also working with simple hand tools. He has no access to the CNC routers, 3D printers, or milling machines used in many of the projects we see here on Hackaday. All the work on UnJailPi’s acrylic case was done with a handsaw, a file, and a heck of a lot of patience.

Currently [Arcadia’s] biggest hurdle is finding a good power supply for his project. UnJailPi is designed to work both on AC or an internal battery. His current power circuit throws off enough heat that the Raspberry Pi resets while the battery is charging.

We’re sure [Arcadia] will figure out his power issues, but if you have any suggestions, leave a comment here, or head over to the project page and let him know!


SpaceWrencherThe project featured in this post is a semifinalist in The Hackaday Prize.

51 thoughts on “THP Semifinalist: Secure Your Internets With Web Security Everywhere

  1. I’m a big fan of people doing innovative security work, but why would anybody conclude this was secure on the basis of the description? There’s a ton of hard-to-harden stuff on there, and if it handles the VPN for you it gets to see all your traffic. If an attacker pops this box, all your traffic are belong to them.

    Net result is a strict increase in risk versus just using openvpn on your endpoint, which you still have to trust in either security model.

    1. Well, I don’t think you read the description carefully : the OpenVPN part is not different than having it installed on your computer : it does it for you, with your own setup, your own certificate, etc… It is just autonomously transparent, and allows you to have every computer connected to the access point, also connected to the VPN.
      If it is not secure, so it means the OpenVPN computer software is not secure either. But OpenVPN is the most secure VPN protocol/software up to date…

      1. Except that it is different from having it installed on the computer, since you need to trust this box in addition to the endpoint. If you install and run openvpn from the endpoint directly you don’t need to trust this box. Ergo, you have strictly increased your risk by using this box.

          1. Writing a *secured* implementation isn’t exactly a easy job. If it were easy that even out sourced coder do it, then we wouldn’t have to worry about 0 day hacks. The code being open source can be both a blessing or a curse. Open source doesn’t automatically guaranteed the code quality or support. What is important is the code used have to be well tested and actively updated for attacks or bugs.

            I would stick with the open source router communities as they take these issues very seriously.

          2. I posted this on the project page, but for those following along here:

            Ok, I’ve had a few minutes to read your reply. It has some issues.

            Just Add Insecurity
            ————————–
            Your assertion that the endpoint device might be compromised is a red herring. Let’s examine the possibilities.

            1/ The endpoint is uncompromised and this box is uncompromised.
            2/ The endpoint is compromised and this box is uncompromised.
            3/ The endpoint is compromised and this box is compromised.
            4/ The endpoint is uncompromised and this box is compromised.

            In the first case, user data is obviously uncompromised- there is no successful attack at play.

            In the second case, user data is compromised before it reaches the UnJailPi. The fact that UnJailPi is on the network is therefore irrelevant: user data is still compromised.

            In the third case, user data is again compromised, per the above.

            In the fourth case user data is still compromised, since it can be seen in the clear by the UnJailPi.

            So, user data is compromised in cases 2, 3, and 4. This is consistent with an at-face-value security assessment: to find the total amount of risk in the system, you *add* the amount of risk introduced by the endpoint to the amount of risk introduced by the UnJailPi.

            Open Source != Fully Secure
            —————————————
            There’s another, related claim on the project page: that since the UnJailPi is fully open source it is auditable, and therefore more trustworthy than the endpoint machine.

            Per the previous argument, this is irrelevant. If I assume the endpoint machine is compromised then I can put any number of well-intentioned boxes on my network and they won’t improve the security of the user because the data was compromised before it ever left the endpoint.

            Of course, you might argue that since the UnJailPi is open source it will not have vulnerabilities, that the risk of compromise is therefore 0, and that while that risk is added (per the previous argument) to the risk that the endpoint is compromised, it doesn’t change the total risk in the system.

            This is patently false. While I’m as big a fan of open source as you are likely to find, the reality is that vulnerabilities happen even in the best audited code. We’ve seen several nasty ones in open source projects this year alone, ranging from the futex bug in the linux kernel (CVE-2014-3153) to the heartbleed bug in openssl (CVE-2014-0160). You mention the security of OpenVPN: it has had two severe vulnerabilities this year (CVE-2014-5455 and CVE-2013-2692) and one additional one in the last 12 months (CVE-2013-2061) besides being vulnerable to heartbleed and early CCS (CVE-2014-0224).

            This obviously doesn’t mean that you shouldn’t use open source code, or that you shouldn’t use the projects in question! It does mean that you should limit the total amount of code which, if compromised, leads to the compromise of your security. By adding unnecessary and *very risky* components like PHP, not to mention the effectively unaudited code unique to this project, you are increasing the total amount of code which exposes you to risk, and therefore increasing the risk you are exposed to. In my view this risk is entirely avoidable.

            Keys and Consequences
            ———————————–
            Your project page says you generate RSA-1024 keys. I hope that’s a typo.

            RSA-1024 is hilariously weak today. NIST (that bastion of trust and security…) has officially recommended that all 1024-bit RSA keys be end-of-lifed as of last December, meaning that they are no longer considered “good enough” for use in any product, even for legacy or compatibility reasons, and even in the absence of implementation errors. So when you advertise on your project page that you use RSA-1024, well, let’s just say it doesn’t fill one with confidence that all the other security decisions have been made appropriately.

            Of course, the fact that your chosen algorithm is insecure in the absence of implementation errors does not imply that it lacks implementation errors. Happy to talk more about that if you’re interested.

            Bottom Line
            —————–
            Honestly, there are a bunch of other issues I’d like to talk about here- the increased risk of physical attacks vis a vis devices like mobiles and chromebooks, the questionable utility of TOR, and the still very much closed source nature of critical parts of the raspberry pi- but I suspect I’m talking to a wall. I understand why this seems like a cool thing to build, but it doesn’t improve anybody’s security, and potentially does quite the opposite. I don’t really expect you to agree with that at this point, but if you have any questions or interest in pursuing any of the things I’ve mentioned feel free to reach out to me- I’m happy to help.

          3. The majority of attack vectors/vulnerabilities are going for low hanging fruit. Lots of exploits are software and/or hardware specific. One of the benefits of using such an obscure device is that it is highly unlikely that someone will intentionally develop exploits specifically for the one-off device that is the UnJailPi. Most hardware that exploits are run on is i86 architecture, this is ARM. The software stack definitely needs some work, however this is a fairly decent idea and i hope it gets implemented correctly.

          4. cockli: That’s called security through obscurity, and while it seems attractive initially it usually doesn’t work out. There are a few reasons why.

            The first (and most common) is that your project and some larger project share a common vulnerable piece of code. Recent examples would include OpenSSL and the heartbleed issue, or the myriad (23 this year alone!) vulnerabilities in PHP. If it were just a handful of large projects that were impacted the fix would roll out and the long-term risk to users would be low- but because so many smaller, slower to patch projects depend on them the issue remains exploitable for years. This means that attackers get a lot of experience with those issues, and learn to apply them quickly to new projects. This leads me to the second problem.

            People outside of the security community often underestimate the degree to which common attack patterns can be reused. In truth, most security researchers have only a handful of well-practiced tricks, and even the best attackers only come up with a few really novel techniques a year. The rest is just pattern matching: see the addition->find the overflow, see the double quote->find the escape. In this respect the public perception of hackers as dark wizards hurts the community at large, since you don’t really have to be nearly as smart as people think to get the job done.

            The third reason is that it can be hard to understand when your project will suddenly attract significant scrutiny. Sometimes a really talented attacker will just decide that you make good target practice or a fun weekend project. Sometimes a high profile user will start getting you attention from intelligence services. Sometimes you get some press and attract the wrong kind of interest.

            Regarding x86 vs ARM, this doesn’t matter much today. There are still more skilled attackers poking at x86, but the security community has known for a couple of years that ARM was something that you needed to be able to work over if you wanted to be on top of the game.

          5. So, what exactly do you propose ? Throw our electronics into a river and live under a rock ? Just do nothing and let the internet gurus do whatever they want ? What is your solution to harden people privacy ?

          6. Captainstouf: The easy solution is exactly what I said previously- cut out the middleman and access the VPN directly from the endpoint. That cuts everything that isn’t running on the endpoint out of the TCB.

            The longer term solution is more interesting. I’ll talk about it in a few parts.

            First, endpoint hardening. Devices like chromebooks and the various mobile OSes have made huge strides in security over the last few years, but desktop operating systems have been slow to catch up. Additional hardening work there will help lower the total risk pool more quickly than almost anything that could be done on the network side.

            Second, minimizing link-layer trust. When I talk with a server, that conversation should be between me and that server and no one else. That’s the ideal of TLS, and while the implementation doesn’t quite match the reality it is much closer than anything else we have at hand. Other initiatives like DNSSEC also help, and need lots of help from skilled and security-interested developers (maybe you?) to drive adoption.

            Third, transparency. Tools like the EFF SSL Observatory, HTTPS Everywhere, and the various transparency reports are awesome ways to push back on bad behavior by parties that often have the technical means to punch through more direct security barriers. Donating developer time to those projects can be a huge win for users everywhere, even when they don’t directly use the product.

            Finally, white/grey hat hacking. If you want to improve the security of something, often times the best way to do so is to find the vulnerability before someone else does. Too few people do it, and it isn’t as hard as it looks. It’s certainly among the most exciting ways to improve security, and with the project you already have you have a great opportunity to start with something you already understand well, which is one of the major barriers to entry. If you’re interested I can point you at some resources that might get you going, but regardless I’d encourage you to give it a shot.

          7. About the short term solution, I still don’t agree with you. I work on hundreds computers a year, from companies and end users, and 99% of them are left unsecure. Even bankers laptops are full flawed because of bad softwares, bad hardware or bad uses (I recently had a banker laptop to clean up, with VPN software and thousands of malwares coming from porn). From my experience, one couldn’t trust the endpoint in 99% of the cases. And without a major paradygm change, end users will continue to not take care about their electronics. They consider Facebook is more important than their privacy/online security, I verify this each day. Your electronics and mine may be safe from the software side (I still have high doubts about it), but we couldn’t trust the hardware part (I already talked about BIOS, but there are more).

            About your second point, you seem well versed into this, so I won’t argue. But I will look carefully into it.

            About transparency : believe it or not, I already contacted EFF about this device, their technologists know about it. I plan to include HTTPS everywhere proxy in it, but I didn’t have the time to do it yet. Same with OpenSSL that should be replaced with PolarSSL or similar.
            I also have an opportunity to have Kaspersky Labs look into it, and I plan to ask them when the device is ready.

            About your final point, I would be very interested to see your ressources. This is definitely something I have a strong interest in. You say finding vulnerabilities is not so hard, I would like to agree with you. I have some strong expertise in computer systems, but I lack this part. I wish to learn this part sooner than later.

        1. How could you trust your own computer, with its many proprietary hardware / software components ? Did you inspect your UEFI BIOS ? How could you be sure one software/hardware component (malware or not) doesn’t spy on you, or transmits your RSA key pair to some third party ?

          I agree that every software/hardware has security risks. But the more you do with a single machine, and the more doors you open.

          At least, you could inspect EVERY component of my project, and improve its security if it is not up to what you expect. This is exactly what open source is about, isn’t it ?

          1. Exactly. The way I see it, is that a computer that’s designed to do many things, with many bits of software installed is much harder to harden than a little box with only one function.

          2. Actually, that’s part of what has me concerned about this. Its running basically a full web stack plus a pile of other stuff, including php. Not an easy attack surface to harden, and definitely the kind of thing that shouldn’t get trusted without an audit.

        2. You are making a big assumption that the end users have the proper knowledge, training, experience etc of inspecting the security of your design. We all like to earn the six figures (or higher) salary of the security experts, but sadly few of us can earn that money.
          Being able to have access to the source code etc does not imply being able to find out the *hidden* flaws of the source code.

          1. “You are making a big assumption that the end users have the proper knowledge, training, experience etc of inspecting the security of your design.”

            Really ? I don’t think I said that. I said the RSA key pair is generated on installation, and there’s some little setup to be done by the user : finding your IP address and putting it in a box is not something really difficult ?

            The OpenVPN / TOR softwares present in the box and the one you use in your own computer are the same, I changed nothing. So if my box OpenVPN is flawed, so are the thousands of other OpenVPN clients around the world. I didn’t brake the softwares update functions either.

            About the real security audit part, if this project goes into the light, there will be hundreds of very competent people who will inspect it, I’m sure about it. I already asked some real (big) telecom companies, and in 4 days I have a meeting with swiss telecoms about my box. Do you think they will use it without their security teams inspecting it from all sides ?

            Sure, I’m no master in security. But some people are, and I bet they will help improve this part if it has to be done. I’m not alone on earth, and this is another thing Open Source is about.

          2. Honestly, the security teams at today’s telcos don’t seem to be all that good, so the amount of confidence I get from them greenlighting this is very small assuming they even go that far.

            As for generating an RSA key, key generation on embedded devices like this has a long and sordid history. Check out the “mining your Ps and Qs” paper and the recent WPS vulnerabilities to see how even just getting reasonable entropy on these devices is surprisingly hard.

        3. I just so happen to be a bona fide paper carrying expert on information security (atleast one uni thinks so anyway) and the short version of my professional opinion is that geremycondra is right, everyone else is wrong. Going into extreme detail about it would be fun, but is entirely pointless within the hackaday readership consisting of makers, tinkerers, and EE types (as opposed to IA).

          1. I don’t see the difference here to a lot of ways things are done in the real world even the “security conscious” world.

            Even if the “local side” endpoint -I.e you set up the VPN from your machine that you trust. The “remote side” likely is not a box that you can implicitly “trust” or it is shared (I.e a VPN concentrator, or a RAS server) it is unlikely to be the actual resource you are connecting to, and if it was files that you wanted to access securely and those files (or whatever resource you are trying to access.) are on that box with a public facing address accepting connections from the outside then security is unlikely to be your first thought anyway.

            It’s perfectly acceptable to have a VPN setup from a secondary device, this is how a lot of businesses will connect their satalite offices to main data centres. It’s not insecure at all. (I’m sure you’d have covered VPNs initiated and terminated on firewalls on your course?)

            I think that the point here is if it was closed source and had CISCO or Watchdog/Juniper/Checkpoint or any other “enterprise” level equipment (that may also run http servers as well as a host if ither functions.) you’d trust it.

            In fact not only would you trust it, but you’d pay someone possibly thousands to set it up for you.

            It’s not that this is insecure, it’s that most HaD readers just want something to whine about.

            No, I don’t have a degree in information security. but I work in IT. Implementing solutions for various companies, sometimes government ones, sometimes financial ones. Including PCI-DSS payment solutions.

            Long story short, no this isn’t “enterprise” level security. But it’s not a bad starting point. The fact that it is open source means nothing. The fact that it’s an endpoint on a network rather than a software client on a machine does not make this implicitly insecure. -that is in fact how lots of “secure connections” are established.

          2. Thinking that something is secure because you’ve seen a corporate IT department do it is like thinking that something will be fun because you saw a girl do it on pornhub- you’re about to get fucked and it’s all going to end in tears.

            Regarding ‘enterprise’ security, no, I don’t trust Cisco not to hand over my data to the NSA. But I do trust Cisco to run a reasonably tight incident response program, and to do regular security audits, and to have a long track record of successfully operating in hostile environments. None of that is true here, and even if it were I would still be right that using an intermediate box instead of going directly from the endpoint would have worse security properties.

          3. “Thinking that something is secure because you’ve seen a corporate IT department do it is like thinking that something will be fun because you saw a girl do it on pornhub- you’re about to get fucked and it’s all going to end in tears.”

            I never said I saw it, I said I set it up and then had it externally audited, and it’s “proven to be secure enough” for government, proven to be secure enough for financial institutes, proven to be secure enough for police forces etc. -it’s what I actually get paid to do (I work specifically in outsourced IT, so I don’t just see A corporate IT environment I see lots of them, all with different sizes, budgets and security requirements. which is why I’m not still sitting in my parents basement watching porn hub and rubbishing other people’s ideas.

            “Regarding ‘enterprise’ security, no, I don’t trust Cisco not to hand over my data to the NSA.”
            that is something completely different, and not within the scope of this box, -the intent of which is simply to setup secure connections, (In the same way that Cisco boxes do!) the only details that Cisco have on you is your name/address details that you use to purchase equipment and licenses, so, realistically you’re actually better off buying a Raspberry Pi and “rolling your own” as then there is no third party company to “hand over your details.”

            “But I do trust Cisco to run a reasonably tight incident response program,”
            As said above, plenty of OSS has very good security response a track record of having things fixed within hour, days or weeks of exploits being found, better than Microsoft, better than Apple whom often take weeks/months/years or just never bother. The heart bleed bug that you mentioned above (as though it was some world crippling bug as opposed to a specific bug, applicable only to specific environments.) was fixed I believe BEFORE the exploit was noticed or exploited, it was only people running older code who were affected.
            What you should be more upset about is the way in which various version of ADSM software force older versions of Java (JRE of which there are many many security risks addressed in each patch release.) -and won’t run without it. and different Catos/Ios/NX-os versions require different ADSM releases.
            Essentially, when you start supporting multiple environments it pays to learn to configure via the CLI -at least it is standard!

            “and to do regular security audits,”
            Which is the benefit of OSS, there is no security through obscurity, the code is essentially vetted on a daily basis, by anyone and everyone.

            “and to have a long track record of successfully operating in hostile environments. None of that is true here,”

            Funnily enough Cisco started as an unknown, unheard of company, with no track record, everything starts somewhere! your point that because someone/something is small it can’t be trusted is pretty stupid.
            most if not everyone know 3par’s story, they start out of a tech incubator, release a novel SAN product and soon become the hottest thing since sliced bread, are bought for billions by HP within the first few years of the company starting up. -i.e the newest players can sometimes be the hottest tickets, proven track records count for nothing when someone new comes in beating everything you have with some new USP.

            But so you actually pretty much sum it up there.
            You essentially responded that you are fine with a intermediate boxes actually setting up the VPN’s the methodology is fine, and you would trust it if it was a big company brand instead of a startup OSS project.

            So there is nothing wrong with the project, and the only problem, that you can find is that it’s OSS, it’s small and it’s on hackaday so people respond to your bitching whining and rubbishing of other peoples work.

            “and even if it were I would still be right that using an intermediate box instead of going directly from the endpoint would have worse security properties.”

            Undoubtedly with every extra box or indeed hop there is increased risk of compromised equipment. but it’s a low risk, and you are being sensationalist.

            I think that my point still stands, this idea of an intermediate box securing connections for a while site is good enough, it’s good enough for governments, it’s good enough for financial institutes, it passes inspections and audits. I know this as fact given that it’s my actual job.

            I also believe that it is good enough for national banks, military, and indeed the “good ole” NSA.

            however, I do completely agree it is a good idea to limit the stack of software available to the device. (e.g. take out android sync, take out camera software take out Apache, take out Samba, take out PHP, take out MySQL start with a better security minded release than Rasbian (something like Tails, or KaliLinux) -essentially you need to think that the more bells and whistles that you add, the more “attack vectors” you add…
            to a certain extent you’d very almost do better to take away the touch screen and GUI components as well, just have a kernel running in it’s most minimal form.
            reducing this software count would also reduce the amount of licenses you need to ship as well!

            Add IPS/IPS functions such that you can actually get some ideas and reports about the “bad traffic” on your network -can give clues of boxes with malware etc.

          4. Dan-

            Besides the claim about basement dwelling (you’re a picklebrain and have cooties, by the way) I think you’re headed in the right direction.

            I obviously don’t agree with the claim that this represents a small risk or I wouldn’t have raised it, and no offense but your argument by authority doesn’t impress me much. OTOH you seem to understand the basic point that this does increase risk, and the steps you talk about later in your post regarding tcb reduction make sense. Hopefully captainstouf will follow that advice.

            So, if I wind up with one of these in my hands I’ll be happy to pop it just to make the point, but otherwise youre right that arguing over unprovable differences in risk assessment seems like a waste of time.

          5. I’m a little disappointed that so many ostensibly intelligent security minded people (not being facetious) are missing the point. All of the above (defense-in-depth) is the most advisable (trying to avoid words like proper/best/right) way.

            This device seems cool, keep up the great work. And by that, I do mean keep up; one of the biggest Achilles’ heels of otherwise great devices is that the don’t stay up-to-date. Building a security device is an agreement with your customers for service in perpetuity. The second you are no longer willing to constantly check that each bit and bob is secure, close it all down and advise everyone to stay away (à la TrueCrypt project).

            Of course the endpoints should be as secure as possible, as geremycondra suggests. No device, no certification, no configuration will ever be enough for me to put down my guard and simply trust. Eternal vigilance is the cost access, and the only secure data system is one turned off with no power going to it, encased in cement, and buried 6′ deep. And even that is only true for some definition of ‘secure’.

            So, you’re all correct.

        4. This box cannot prevent a data compromise which occurs on the client, so assuming that a large percentage of clients is compromised actually means this is useful in fewer cases rather than more. Not sure why that seems to be hard to express clearly, but the statement is easy to verify logically as demonstrated previously.

          Regarding openssl and polarssl, I would wait for things to shake out better before jumping. Openssl has made some terrible mistakes to be sure, but it isn’t clear what will hit critical mass moving forward. Just my two bits there.

          Regarding getting started with vuln hunting, the easiest way is to jump into things like back this site.org and similar.

          1. Oops, hit post early.

            You might also want to check out damn vulnerable web app and damn vulnerable linux, both of which are fun, and of course watch MITRE for bulletins as the come out- when there’s a link to the patch just pull down the relevant project and see if you can trigger the condition under which the vuln happens.

            Depending on where your interests lay, here’s some more resources:

            – I got my start doing cryptanalysis and was fortunate to have access to some good books. The most useful to someone new to crypto will me “introduction to modern cryptography” by Katz and Lindell IIRC. If you know your way around but are looking for something more attack focused, try “cryptanalysis of RSA and its variants”.

            – If you’re into web security, I can recommend the tangled web”. Full disclosure: the author is a coworker, though not a close one.

            – there’s a great book called “a guide to kernel exploitation” that I keep on my shelf for new hires. Really clearly written.

  2. if you need some help with laser cutting acrylic, email me and I might be able to hook you up; depending on where you are located. I’m in the sf bay area, if that helps (but could mail you some cut plastic if you create the drawing properly; local techshop prefers coreldraw 5 files but I could import almost anything that is vector based). snmp_4u at that wahoo (change 1 letter) site. cheers.

        1. Problem is : without the tools, I don’t really know the softwares. I’m a trial & error guy and I usually learn this kind of things through prototyping. The first hackespace around here is at more than 40 kilometers, and is not open really often. This is the main reason I’m kinda alone on this (well, until now).
          I’m currently trying to learn sketchup, but that’s pretty hard in this little time window. I really have no experience in this, and I really don’t want to ask someone to do it for me from scratch ^^

          Believe it or not, this is the reason why I’m actually trying to build a fablab in my area. I desperatly want to build a local makers community, but this philosophy is far from being common in France, so this is very difficult.

          However, many thanks for your advices, it is very appreciated.

          1. There are vendors on ebay who will cut acrylic or lexan to any size you want. The price is not bad at all, you just buy the piece you want and then you pay for each cut they make. The cut edges are very smooth, you can polish them up and it looks very professional.

    1. I own some of these modules, but they are not powerfull enough in my case and end up overheating. Plus, they don’t solve the battery/charging part. I may add they are not very reliable : one of them litteraly exploded in my face (without damage) on first try. The second one was ok.

      This part is now solved thanks to PiModules UPiS advanced (and soon the B+ version), but many thanks for your comment :)

      1. You REALLY need to watch for ripple into these modules!
        I had the same “magic smoke” pop out of one!
        I got Ross to use one of these after he said a 7805 was “getting hot” when putting 12V into it!

    1. Hi, if you read across the project logs, you will see it’s already in the works. The Raspi is very well supported, and many people own one, so it was a good starting point.
      Actually, it is being ported to a A20 board, but I want it to remain 100% compatible with Raspberry, because there are more than 2 millions of these boards already…

  3. For the power circuit…

    Fundamentally you made the same mistake I did in my project. -you chose the raspberry pi.

    A better choice is the olimex A20 lime. For that you get full open source dual core @1GHz SATA, faster Ethernet. Pre built LCD touch screen modules at a good price. As well as a built in battery charger for ups. (Just add lipo battery).

    Your software will run better (encrypting traffic is CPU intensive so with more than double the processing power things happen faster.
    You don’t need to worry about battery. It’s figured out for you.

    And the cost is 33euro from the supplier. (Plus shopping and taxes). I just bought one for £35 including shipping from eBay, so that’s basically the same price as the pi too.

    If you’re more bothered about open source than speed, you could also check out their mx233 boards, fully open sourced hardware and designed to be created on a double sided board, using surface mount components such that you can create it entierly at home with no “specialist” equipment.

  4. There are so great debates around here…. It is very difficult to answer to each one, discussion is mixed between posts. So I posted a new project log. Feel free to comment it, here or there. Your opinions are really important to me.

    Thanks for the great discussion :)

  5. Safety: Likely safe. Supporting the beneficial role of carnitine supplements, however, are studies in kidney dialysis patients showing that low carnitine levels in the dialysate can lead to elevated levels of blood
    lipids. So take a step further and generally improve your physical condition through the effective and reliable Nutrilean dietary supplements.

  6. Bottom line, breaches will continue to happen so long as companies are lax about information security, and that’s unfortunate. What’s needed for helping ensure the safety and security of one’s I.T. environment are the following three (3) mandates: (1). Well-written information security policies and procedures – those that are actually followed! (2). Annual security awareness training for employees – structured training protocol that effectively discussed leading I.T. security threats and challenges, along with best practices. (3). Proper provisioning and hardening of information systems – such as removing default accounts an insecure and unnecessary services and protocols. The very best defense any company can have for ensuring the safety and security of organizational assets are employees who actually care about the organization and are highly trained in regards to identifying threats or concerns to the company as a whole.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.