German Lawyers Call For Their Profession's Bug-Ridden, Soon-To-Be Mandatory, Email System To Be Open Sourced

from the public-trust,-public-code dept

Given the sensitive nature of their work, lawyers need to take particular care when communicating online. One way to address this -- quite reasonable, in theory -- is to create a dedicated system with strong security built in. That's the route being taken by Germany's Federal Bar Association (Bundesrechtsanwaltskammer -- BRAK) with its "besondere elektronisches Anwaltspostfach" (special electronic mailbox for lawyers, or beA). However, the reality has not matched the theory, and beA has been plagued with serious security problems. As a post on the Free Software Foundation Europe (FSFE) site explains (original in German)

Numerous scandals and a questionable understanding of security characterize the project, which has been in development for several years. Lawyers should have been reachable through this software since January 1, 2018, but numerous known vulnerabilities have prevented the planned start of the service.

...

Although a security audit was commissioned and carried out in 2015, its scope and results have not been published to date; the full extent of the faulty programming became known only at the end of 2017. Thus the project, which has cost lawyers so far about 38 million euros, has already lost people's trust. In view of the numerous errors, the confidentiality of the sent messages can no longer be guaranteed -- and this is for software whose use from 2022 onwards becomes mandatory for all court documentation traffic.

Because of the continuing lack of transparency about the evident problems with the project, a number of German lawyers are supporting a petition that asks for an alternative approach, reported here by the Open Source Observatory:

The petition calls on Germany's Bundesrechtsanwaltskammer (Federal Bar Association, or BRAK) to publish the beA software under a free and open source software licence and open the software development process. "Only in this way can it slowly restore the trust of the users -- all lawyers, authorities and courts," the petition says.

As the petition notes (original in German):

Disclosure of the program code allows independent IT professionals to report potential security vulnerabilities early on so that they can be fixed; it has been shown once more that keeping the source code secret, and carrying out the audits as agreed in the contract [for creating the beA system] does not lead to the desired result. Free software also guarantees much-needed manufacturer independence.

Over and above the increased transparency that open-sourcing the beA code would bring, and the hope that this would allow security issues to be caught earlier, there is another good reason why the German system for lawyers should be released as free software. Since it will perform a key service for the public, it is only right for representatives of the German public to be able to confirm its trustworthiness. This is part of a larger campaign by the FSFE called "Public Money, Public Code", which Techdirt wrote about last year. Unfortunately, what ought to be a pretty uncontroversial idea still has a long way to go, as the painful beA saga demonstrates.

Follow me @glynmoody on Twitter or identi.ca, and +glynmoody on Google+

Filed Under: germany, lawyers, open source

Oracle Tells The White House: Stop Hiring Silicon Valley People & Ditch Open Source

from the well,-that's-one-way-to-think-about-things... dept

Even though Oracle is based in the heart of Silicon Valley (I can see its offices from my own office window as I type this), the company has become sort of anti-Silicon Valley. It tends to represent the opposite of nearly everything that is accepted wisdom around here. And its latest crusade is against open source technology being used by the federal government -- and against the government hiring people out of Silicon Valley to help create more modern systems. Instead, Oracle would apparently prefer the government just give it lots of money.

First, some background: over the past few years, one of the most positive things involving the federal government and technology has been the success of two similar (but also very different) organizations in the US government: US Digital Service (USDS) and 18F. If you're completely unfamiliar with them there are plenty of articles describing both projects, but this one is a good overview. But the really short version is that both projects were an attempt to convince internet savvy engineers to help out in the federal government, and to bring a better understanding of modern technology into government. And it's been a huge success in a variety of ways -- such as creating federal government websites that are modern, secure and actually work. And even though both programs are associated with President Obama, the Trump administration has been adamant that it supports both organizations as well, and they're important to continuing to modernize the federal government. The offices are not politicized, and they have been some of the best proof we've got that government done right involves smart, dedicated technologists.

Of course, not everyone is thrilled with these organizations. Old school federal contractors, for one, have been grumbling loudly about 18F daring to do things like making government procurement open to small businesses. After all, these contractors have spent decades charging the government billions for crappy products, in part, because they know how to work the system. Bringing in actual engineers who realize that it's crazy to spend so much money on crappy solutions -- especially when there are much better solutions that are often open, seems to really piss off some folks who grew fat and happy overcharging the government. And they've found some front groups who argue that these programs are a waste of government money, which would be better spent giving billions to private contractors.

Either way, the Trump Administration, following a Trump executive order, requested feedback on how best to modernize government IT. The request for comments and all the submitted comments are on Github (which is nice to see). Many are quite interesting, but the one that really caught my eye, was Oracle's submission, which I can only describe as... curmudgeonly.

A little more background: if it weren't for Oracle's failures, there might not even be a USDS. USDS really grew out of the emergency hiring of some top notch internet engineers in response to the Healthcare.gov rollout debacle. And if you don't recall, a big part of that debacle was blamed on Oracle's technology. So, perhaps it's not surprising that Oracle might hold a bit of a grudge against USDS. Similarly, while Oracle likes to claim that it's supportive of open source technologies, most recognize that open source has been eating Oracle's lunch for a while now.

Even with all that background, the sheer contempt found in Oracle's submission on IT modernization is pretty stunning. The letter complains about three "false narratives" that "have taken the [US government] off track":

False Narrative: Government should attempt to emulate the fast-paced innovation of Silicon Valley. Silicon Valley is comprised of IT vendors most of which fail. The USG is not a technology vendor nor is it a start-up. Under no circumstance should the USG attempt to become a technology vendor. The USG can never develop, support or secure products economically or at scale. Government developed products are not subject to the extensive testing in the commercial market. Instead, the Government should attempt to emulate the best-practices of large private-sector Fortune 50 customers, which have competed, evaluated, procured and secured commercial technology successfully.

Now, this is kind of funny if you follow anything having to do with government and IT projects over the past few decades, as compared to what's happened on projects where USDS and 18F have been involved. For example, remember the big new $600 million (only $220 million over budget) computer system the FBI paid for that was useless for catching terrorists and had to be completely written off? This was the system, built by giant government contractor SAIC, that a computer science professor who was asked to review the system said he was planning to go on a crime spree the day the system launched, knowing the FBI wouldn't be functional. The same system that was so bad that a contractor who was trying to do something so simple as add a printer to the network had to hack the system, accessing the usernames and passwords of 38,000 FBI employees (including then director Robert Mueller) just to do his job.

Is that really the kind of world we want to go back to? And that's just one example, but there are many others like this. Yet, whenever you look at the systems that USDS and 18F are working on, they seem to actually work. They also seem secure. So, sure, it's easy to attack having the government put together these systems, but real world experience seems to show that these groups, staffed with experienced internet engineers does things a lot better.

False Narrative: In-house government IT development know-how is critical for IT modernization. In-house government procurement and program management expertise is central to successful modernization efforts. Significant IT development expertise is not. Substantial custom software development efforts were the norm at large commercial enterprises, until it became obvious that the cost and complexity of developing technology was prohibitive, with the end-products inherently insecure and too costly to maintain long-term. The most important skill set of CIO’s today is to critically compete and evaluate commercial alternatives to capture the benefits of innovation conducted at scale, and then to manage the implementation of those technologies efficiently. Then, as evidenced by both OPM and Equifax, there needs to be a singular focus on updating, patching, and securing these systems over time.

There's at least some truth to the idea that developing things from scratch is not ideal in many cases, but claiming that those making decisions on federal IT shouldn't have development knowledge is ludicrous. When you don't have that kind of knowledge, that's when you get the big federal contractors coming in and selling you $600 million FBI computer systems that are useless at catching terrorists. I'd be curious if any software developers out there actually think they get better requirements docs from those with dev experience, or those without? Because over and over and over again, I've seen that when the management side actually understands software development, then the process tends to go much more smoothly, because people are much more realistic. Having non-technically inclined managers making these decisions tends to go poorly. Remember the massive computer system that the Copyright Office wasted millions on? That involved a failure of the Copyright Office to set requirements with the outside vendor who never could actually build a working system.

False Narrative: The mandate to use open source technology is required because technology developed at taxpayer expense must be available to the taxpayer. Here there is an inexplicable conflation between “open data,” which has a long legacy in the USG and stems from decades old principles that the USG should not hold copyrights, and “open source” technology preferences, which have been long debated and rejected. There is no such principle that technology developed or procured by the USG should be available free for all citizens, in fact that would present a significant dis-incentive to conducting business with the USG.

This is the most ridiculous of all. Copyright law is pretty clear on this: works of the US government shouldn't be subject to copyright -- and many in the government have embraced variations on open source to live up to that requirement. The idea that open source somehow creates disincentive to working with the US government is hilarious. Maybe for a company like Oracle, but tons of others are happy to work with the US government and lots of open source technologies have made government IT faster, cheaper and more secure.

But Oracle really wants to dig in on this point, with some complete bullshit about how open source is somehow less secure... because the Equifax hack came via a vulnerability in open source:

Developing custom software and then releasing that code under an open source license puts the government at unnecessary security risk as that code is not “maintained by a community,” but is rather assessed and exploited by adversaries. Further, this practice puts the government – most likely in violation of the law – in direct competition with U.S. technology companies, who are now forced to compete against the unlimited resources of the U.S. taxpayer. The Equifax breach stemmed from an exploit in the open source Apache Struts framework.

The Equifax breach stemmed from Equifax failing to patch a widely discussed bug that competent administrators should have patched. The bug was found and patched because it was open source.

Speaking of "false narratives," Oracle also claims that open source technology is being used less and less in the corporate world:

Open source software has many appropriate uses and should be competed against proprietary software for the best fit and functionality for any given workload, but the fact is that the use of open source software has been declining rapidly in the private sector. There is no math that can justify open source from a cost perspective as the cost of support plus the opportunity cost of forgoing features, functions, automation and security overwhelm any presumed cost savings. The actions of 18F and USDS plainly promote open source solutions and then propagate those mandates across government with the implicit endorsement of the White House. The USG’s enthusiasm for open source software is wholly inconsistent with the use of OSS in the private sector.

If you actually follow the open source software market, Oracle's claim here is laughable. Open source is now commonplace in the enterprise and that's only increasing, not decreasing.

Also, somewhat hilariously, Oracle tries to argue that letting USDS and 18F develop things means that there will be extra costs, compared to letting private companies develop stuff:

The largest contributor to cost and complexity is customization, yet actions of the USG and the Report seem to embrace both government developed bespoke technology and customization. Custom code needs to be maintained, patched, upgraded and secured over the long-term. The cost of technology comes almost entirely from labor, not from component parts, whether software, hardware, or networking. The goal should be to seek leverage and scale by engineering out labor costs, including process engineering. Government developed technology solutions must be maintained by the government. Every line of code written by 18F, USDS or another government agency creates a support tail that results in long term unbudgeted costs.

But, again, looking at historical IT implementations pre-USDS and 18F and you see example after example of it being the outsourced, private, large government contractor companies whose work results in massive unplanned maintenance costs.

Seriously, this entire filing by Oracle is one giant false narrative of people living in denial about how the world works these days.

There's even more nuttiness in the filing, but you can go through it yourself and count how frequently you gasp at just how wrong it is. This is an old, legacy company trying to cling desperately to old, obsolete, legacy ways. Oracle's entire business was originally created to serve the US government as a customer, and it clearly doesn't want to give that up. But, once again, things like this just make it clear why the top engineers coming out of school today don't have much interest in going to work for a company with views like Oracle's.

Filed Under: 18f, it modernization, open source, usds
Companies: oracle

Consumer Reports Proposes Open Source Security Standard To Keep The Internet Of Things From Sucking

from the Russians-hacked-my-toaster.-Again. dept

Thanks to a laundry list of lazy companies, everything from your Barbie doll to your tea kettle is now hackable. Worse, these devices are now being quickly incorporated into some of the largest botnets ever built, resulting in some of the most devastating DDoS attacks the internet has ever seen. In short: thanks to "internet of things" companies that prioritized profits over consumer privacy and the safety of the internet, we're now facing a security and privacy dumpster fire that many experts believe will, sooner or later, result in mass human fatalities.

Hoping to, you know, help prevent that, the folks at Consumer Reports this week unveiled a new open source digital consumer-protection standard that safeguards consumers’ security and privacy in the internet-of-broken things era. According to the non-profit's explanation of the new standard, it's working with privacy software firm Disconnect, non-profit privacy research firm Ranking Digital Rights (RDR), and nonprofit software security-testing organization Cyber Independent Testing Lab (CITL) on the new effort, which it acknowledges is early and requires public and expert assistance.

As it stands, most of the proposals are common sense and take aim at most of the common issues in the IOT space. For example, encouraging companies to spend a few minutes engaged in "penetration testing" of their products before shipping (a novel idea!). The standard also hopes to ensure companies notify consumers of what's being collected and who it's being shared with, and that devices aren't using default login credentials. But Consumer Reports also notes that it hopes to develop these standards with an eye on more broadly incorporating them into product reviews:

"The standard should be easy enough for consumers without a technical background to understand, yet sophisticated enough to guide testing organizations such as Consumer Reports as we develop precise testing protocols. We want to rate products on measures such as security, in much the same the way we currently assess products for physical safety and performance."

This isn't the first effort of this type. Both the Department of Homeland Security and the FCC have started pushing for some voluntary sort of consistent standards. Of course the problem is that these standards are voluntary, meaning that the kind of companies that cut corners in the first place to sell unsecured products, aren't likely to give much of a damn. It's why folks like Bruce Schneier have advocated for stronger regulations. But with government agencies already walking back even existing consumer privacy protections under Trump, that doesn't seem likely anytime soon. And even if they were open to it, does anyone actually think that federal bureaucrats would come up with reasonable, workable standards that didn't do more harm than good? Having prominent reviewers, such as Consumer Reports take this on through an open standard and reviews seems like a pretty good way of shaming companies into better behavior.

Consumer Reports is quick to acknowledge this is just the beginning of what they hope evolves into a more comprehensive standard:

"The standard as it’s now written is a first draft. We hope that everyone from engineers to industry groups to concerned parents will get involved in shaping future versions of it. We’ve placed the standards on GitHub, a website that’s widely used by software developers to share ideas and work on group projects. Because GitHub can be hard for newcomers to navigate, we’ve also built a website that has the same information."

Folks that are curious or want to lend their assistance can check out the full standard here.

Filed Under: iot, open source, security, standard
Companies: consumer reports

The Rise Of More Secure Alternatives To Everyone's Favorite Chat App, Slack

from the well-this-could-get-interesting dept

Like a ton of people and companies, we've been using Slack here. While we saw some folks claim it was revolutionary, we found it to be a nice, but somewhat marginal, upgrade to our previous use of Skype chat rooms. But, over time, it has certainly gotten comfortable, and there have been some nice feature add-ons and integrations that have made it a pretty cool service overall -- though if you really want to use it to its fullest extent and switch to the paid version, it can get pretty pricey, pretty quickly. I also am in a bunch of other group Slack chats, as it's basically become the platform of choice for group discussions.

However, in these days where hacked emails are in the headlines, I can see why some might get nervous about using a tool like Slack. Not that there have been any known breaches of Slack that I'm aware of, and I'm sure that the company takes security very seriously (it would undermine its entire business if it failed on that front...), it's been interesting to see other options start to pop up, which might be more appetizing for those who are extra security conscious.

Just as we've been encouraged to see greater use of encryption on mobile phones, email and on websites, it's good to see new entrants trying to take on Slack with a focus on security and privacy. The most recent, and perhaps most interesting, player in the space is SpiderOak, which recently launched its Semaphor Slack competitor on the market. I've been playing around with it -- and while it's early on, it certainly has potential. SpiderOak is the company you should already know of that provides an encrypted "zero knowledge" cloud backup solution. Since you keep the keys, even though it's hosted in the cloud, SpiderOak has no way to decrypt your files should anyone hack in, or should the government come calling. It's now taken that approach to Semaphor, which obviously takes its inspiration from Slack (and feels quite similar), but with the same zero knowledge encrypted setup. You get a key and that encrypts all of the data in your group messaging.

There are some limitations there -- of course -- because any team member might leak their key (though whoever gets in would just have access to whatever that team member can see). And, because of this setup, it's not as easy to do "integrations" with third-party apps and services, which is a key selling point of Slack. Semaphor is apparently trying to work its way around this limitation by creating bots that act as their own users within Semaphor (something Slack has also), but where the bots themselves become the key to integrations. It's a bit more clumsy, but if it helps keep things secure, that seems promising.

SpiderOak also, kindly, makes the Semaphor client source code available for anyone to audit, which is necessary if anyone's going to take their encryption seriously. Of course, Semaphor is, like Slack, working off a Freemium model, where additional features require per user fees, which can add up. One nice feature of Semaphor that Slack doesn't have: the ability for individuals to pay their own way. That is, there are lots of Slack groups that are general interest groups around certain topics, and not a company's own internal group. Those groups are never going to use a paid option, because there's no "company" to pay for all users. Semaphor offers an alternative, where each user can just pay their own way -- which might be appealing to some user groups.

The other alternatives that have been getting some attention lately are a couple of attempts to basically create a truly open source Slack clone that can be self-hosted. The two big players here are Mattermost and RocketChat. Both have built open source, self-hosted Slack clones (and both try to make money by offering paid hosting for those who want it). Mattermost is quite upfront that it's building a Slack alternative -- it's all over its website -- though it also points out that it's tried to improve on some things in Slack. RocketChat doesn't seem to mention Slack, and, frankly, feels a bit behind Mattermost in development (though it also announced that it's about to run a Kickstarter campaign to jumpstart more development.

Now, whether or not a self-hosted open source alternative is more secure than Slack... may depend. If you're doing the self-hosted version then you're basically relying on your own ability to keep the implementation secure. That might work. Or, whoever you have securing your installation might not be as good or as responsive as, say, the security team at Slack. But, using an open source solution that you host obviously does provide you with a lot more control and the ability to make any changes you think are necessary.

As someone who talks quite frequently about how competition drives innovation, it's great to see all of this happening. I don't think any of them will harm Slack's place in the market, which has become pretty standard in a lot of companies, but as more and more companies are realizing that they need to really think through security of their communications tools, it's a very good thing to see competition popping up. Hopefully, these competitors get stronger as well, and help drive more overall innovation -- including the focus on security and encryption -- across the entire market.

Filed Under: chat, cloud services, encryption, messaging, open source, security, work
Companies: mattermost, rocketchat, slack, spideroak

FCC Demands TP-Link Support Open Source Third-Party Firmware On Its Routers

from the freedom-to-tinker dept

Last year, we noted how the FCC updated its rules governing routers in the 5 GHz band over safety concerns, stating that some illegally modified router radios operating in the unlicensed bands were interfering with terminal doppler weather radar (TDWR) at airports. The rule changes prohibited tinkering with just the RF capabilities of the devices. But engineers, the EFF, hobbyists and custom-firmware developers feared that because many routers have systems-on-a-chip (SOC) where the radio isn't fully distinguishable from other hardware -- vendors would take the lazy route and block third-party firmware entirely.

That only partially happened.

While the FCC told us explicitly that locking down third-party firmware was not its intent, router manufacturers like TP-Link did indeed take the lazy route -- locking down its routers to prevent third-party firmware installs, then blaming the FCC for it. Fortunately other router manufacturers like Belkin/Linksys took the opposite tack, going so far as to use the new rules as a marketing opportunity, highlighting how they'd continue to support tinkerers (at least in regards to its WRT line of routers). Companies like Asus also stated they'd continue supporting the tinkering community.

Fast forward to this week, when the FCC took some interesting steps to try and force TP-Link's hand on the subject. The regulator announced that it had reached a $200,000 settlement with TP-Link (pdf) for marketing routers to consumers that operated outside of FCC parameters. The FCC's full consent decree (pdf) offers a bit more detail, noting that TP-Link effectively let some router models be modified to operate outside of accepted U.S. parameters via a toggle setting that let users pretend they lived in other countries, opening the door to potential interference.

Note that this settlement involved routers in the 2.4 GHz band, while the rule changes above governed the 5 GHz band. But in an interesting wrinkle, the FCC used the settlement to push TP-Link back toward supporting open source third-party firmware for 5 GHz devices:

"TP-Link has also agreed to take steps to support innovation in third-party router firmware by committing to investigate security solutions for certain 5 GHz band routers that would permit the use of third-party firmware while meeting the Commission’s security requirements and maintaining the integrity of critical radio parameters."

The FCC stated the move was an attempt to balance RF safety and interference policy while supporting the freedom to tinker:

"The Commission’s equipment rules strike a careful balance of spurring innovation while protecting against harmful interference,” said Travis LeBlanc, Chief of the Enforcement Bureau. “While manufacturers of Wi-Fi routers must ensure reasonable safeguards to protect radio parameters, users are otherwise free to customize their routers and we support TP-Link’s commitment to work with the opensource community and Wi-Fi chipset manufacturers to enable third-party firmware on TP-Link routers."

Note it's not entirely clear just how hard the FCC will push to ensure TP-Link compliance, and what "steps" TP-Link has to take to return to supporting third-party open source firmware remains a little murky. It's also likely that other router manufacturers will continue to take the lazy route and shut out tinkerers from installing third-party firmware. Still, it's a solid signal from the FCC that it at least realizes the value in open source modifications (or the bad PR in hindering it), an increasingly rare position in an era where you often no longer actually own the hardware and devices you buy.

Filed Under: fcc, firmware, open source, routers, third party
Companies: tp-link

Bad News: Two-Factor Authentication Pioneer YubiKey Drops Open Source PGP For Proprietary Version

from the not-good dept

If you want to be secure on the internet these days, multi-factor authentication is a must. Don't believe me? Just ask Betty White: By now, hopefully, you've turned on multi-factor authentication on various social media/email accounts, where they either text you an extra code or you have an app like Authy that supplies you with an extra code. But another super handy mutli-factor authentication system is the YubiKey setup, which is a little USB key with a finger sensor. It's basically a bit of hardware that you can keep on you, which blocks anyone else from logging into your accounts if they don't have it. We actually distributed YubiKeys at our inaugural Copia Institute summit, and I've been using YubiKeys for a while now to better protect certain accounts.

That's why it's fairly disappointing to learn that Yubico, the company that makes them, has decided to drop an open source implementation in its latest offering. After some people started asking about this on GitHub a few days ago, Yubico's Engineering Lead Dain Nilsson explained:

The implementation is not open source, that is correct. We have both internal and external review of our code to ensure that it is secure. It's important to remember that open source code is no guarantee that bugs/vulnerabilities will be detected as the bug you've linked to demonstrates quite well. The bug was inherited from the upstream project which ykneo-openpgp is based on, and was NOT detected by any audit of the source code. It was interaction with the device itself which led to its discovery.

We're all for open source, and we try to open source as much of our code as possible when and where it makes sense, but in this case it was determined not to be so. One reason is that on the YubiKey NEO, each applet runs in its own sandbox, isolated from the rest of the system and can be audited/reasoned about on its own. This is not the case on the YubiKey 4, where each part of the system interacts with several others. Another reason that ykneo-openpgp was implemented as an open source project (aside from being able to leverage an existing project) was that it was useful for others, as it can run on a variety of devices. Again, this is not the case for the implementation running on the YubiKey 4.

While I'm sure that Yubico's intentions were good here, this has raised a lot of concerns and has led to other former fans of YubiKeys withdrawing their endorsements of the devices. Encryption is tricky. There are almost always vulnerabilities and bugs -- a point we've been making a lot lately. But the best way to fix those tends to be getting as many knowledgeable eyes on the code as possible. And that's not possible when it's closed source.

Yubico, also, doesn't seem to have reacted well to people complaining. After one commenter was marginally aggressive, saying "Everyone that does not have shit for brains knows that security through obscurity doesn't work..." Nilsson closed down the thread and noted: "Further hostility against the company or our users will not be tolerated in this forum, and will be met with bans." That seems... tone deaf, at best, and it makes the company sound unwilling to listen to the concerns of its customers.

While there may be legitimate reasons that Yubico made this switch, it quite reasonably has many former supporters more worried about using its solution, and many are now looking at alternatives. Yubico had been so associated with this market for a long time that it was becoming basically "the" provider of these kinds of keys. But it may have just helped the competition quite a bit.

Filed Under: multi-factor authentication, open source, pgp, two factor authentication, yubikey
Companies: yubico

Despite New FCC Rules, Linksys, Asus Say They'll Still Support Third Party Router Firmware

from the apocalypse-averted dept

The apocalypse for those who like to tinker with their router firmware may be postponed.

Last year we noted how the FCC updated router and RF device rules for safety reasons, stating that some illegally modified router radios operating in the unlicensed bands were interfering with terminal doppler weather radar (TDWR) at airports. The rule changes prohibited tinkering with the just the RF capabilities of devices. But some sloppy FCC language worried tinker advocates and custom-firmware developers, who feared that because many routers have systems-on-a-chip (SOC) where the radio isn't fully distinguishable from other hardware -- vendors would take the lazy route and block third-party firmware entirely.

And, at least with some companies, that's exactly what happened. TP-Link for example stated that it would be preventing custom router firmware installations with gear built after June 2016, blaming the FCC for the decision while giving a half-assed statement about respecting the hobbyist community's "creativity." Again: the rules don't mandate anything of the kind; TP-Link just decided to take the laziest, most economical route.

Fortunately, not all hardware vendors are following TP-Link's lead. Linksys has announced that while it will lock down modifications on some router models, the company will continue to let enthusiasts tinker with its WRT lineup of hardware, which has been a hobbyist favorite for years. From its comments the company is well aware that while custom firmware flashers may comprise a minority of overall customers, they're a vocal minority that companies really don't want to piss off. As such, a company spokesman was quick to breathlessly praise third party custom firmware options:

"The real benefit of open source is not breaking the rules and doing something with malicious intent, the value of open source is being able to customize your router, to be able to do privacy browsing through Tor, being able to build an OpenVPN client, being able to strip down the firmware to do super lean, low-latency gaming,” La Duca said. “It's not about ‘I'm going to go get OpenWrt to go and piss off the FCC.' It's about what you can do in expanding the capabilities of what we ship with."

While it would be nice to see more models supported, it's certainly a step in the right direction. It should be noted that (now Belkin-owned) Linksys said it wasn't a very big deal to lock down the radio specifically, contrary to what some vendors have claimed:

"The hardware design of the WRT platform allows us to isolate the RF parameter data and secure it outside of the host firmware separately," Linksys said in a written statement given to Ars. La Duca declined to get more specific about Linksys's exact method. Even though this is about enabling open source, Linksys’s method is proprietary and provides a competitive advantage over other router makers that aren’t supporting open source, La Duca said."

So while one vendor used the FCC rule change as an opportunity to be lazy and cheap, others are using the news as an opportunity to embrace an important part of their community. And from the looks of thinks Linksys won't be alone in the effort; representatives from Asus have been telling some hardware enthusiasts that they plan to continue supporting third-party open source firmware as a point of pride as well:

"As you may know, FCC requires all manufactures to prevent users from changing RF parameters. Not only manufactures' firmware but 3rd party firmware need to follow this instruction. Some manufactures' strategy is blocking all 3rd party firmware, and ASUS's idea is still following GNU, opening the source code, and welcome 3rd party firmware. ASUS are co-working with developers such as Merlin and DDWRT to make sure 3rd party firmware's power are the same as ASUS firmware and obey the regulations."

None of this is to say these companies can't go back on their word down the line (concerned users should keep the pressure up), but it's refreshing to see at least a few vendors actually standing behind their communities' right to tinker.

Filed Under: fcc, firmware, open source, routers
Companies: asus, linksys, tp-link

DHS Claims Open Source Software Is Like Giving The Mafia A Copy Of FBI Code; Hastily Walks Back Statement

from the psst...-your-ignorance-is-showing dept

Late last week, the DHS's Chief Information Officer Luke McCormack (or someone from his office) posted comments to GitHub arguing against the proposed policy of making 20% of its code (whatever that means) open source in the interest of better sharing between agencies. The rationale is that shared code could save tax dollars by preventing paying developers to perform redundant work. The DHS felt strongly about this and said as much using an Excel-based parade of horrors.

Many private companies (especially security companies) do not publish their source code is because it allows attackers to (a) construct highly targeted attacks against the software, or (b) build-in malware directly into the source code, compile, then replace key software components as 'doppelgangers' of the original. How will this be prevented? Government-specific examples: citizenship anti-fraud rules that are coded into software, identification of special codes used to flag law enforcement actions, APT threat indicator scripts, Mafia having a copy of all FBI system code, terrorist with access to air traffic control software, etc. How will this be prevented?

Contrary to the CIO's statements, open source software can actually be safer than closed source options. More eyes on the source means more people finding flaws and holes and working towards fixes, rather than simply compiling internal discoveries and forwarding them to the vendor and allowing the company to determine which holes/flaws should be repaired and in which order.

The DHS has now walked back this unfortunate comment, claiming it was just one of those mysterious things that somehow materialized out of the ether.

Those comments were "incorrectly posted" and do not represent DHS' position, agency spokesman Justin Greenberg told Nextgov in an email. McCormack's new comments "serve as the department’s official stance on the policy," the spokesman said. In his new comment, McCormack said the earlier comments reflected "a variety of individual positions across DHS components."

This explains next to nothing and leaves readers with the impression that the DHS has been publicly embarrassed by the "source code sky is falling [pending proposal approval]" emailed in by its CIO.

The DHS has a history of walking back things after they've received public criticism. This is good, but the walkbacks seem to be accompanied by obfuscatory statements that give everyone involved a pass on their misguided actions. Back in 2014, DHS component ICE started soliciting bids for a national license plate database (built from the hundreds of automatic license plate readers in use around the nation). Backlash ensued and DHS Secretary Jeh Johnson quickly issued a statement claiming the posting was done without the approval of "ICE leadership." In other words, the issuance was just a governmental glitch and the hasty retreat being beaten entirely unrelated to the public outcry.

Here, the same thing seems to be happening. The DHS CIO posts comments full of alarmism, is called out for it and a spokesperson appears on scene to say that comments released by a DHS official are not the official comments of the agency he represents. To borrow the blame-shifting parlance of law enforcement, a misguided comment "discharged" and no one should have to own up to actually pulling the trigger. Yes, mistakes were made. But apparently no government official should need to acknowledge they were just flat-out wrong.

Filed Under: dhs, government, open source

Router Company Lazily Blocks Open Source Router Firmware, Still Pretends To Value 'Creativity'

from the unintended-consequences dept

Last fall, you might recall that the hardware tinkering community (and people who just like to fully use the devices they pay for) was up in arms over an FCC plan to lock down third-party custom firmware. After tinkering enthusiasts claimed the FCC was intentionally planning to prevent them from installing third-party router options like DD-WRT and Open-WRT, we asked the FCC about the new rules and were told that because modified routers had been interfering with terrestrial doppler weather radar (TDWR) at airports, the FCC wanted to ensure that just the radio portion of the router couldn't be modified.

The FCC stated at the time that locking down the full, broader use of open source router firmware entirely was absolutely not their intent:

"Our rules do permit radios to be approved as Software Defined Radios (SDRs) where the compliance is ensured based on having secure software which cannot be modified. The (FCC's) position is that versions of this open source software can be used as long as they do not add the functionality to modify the underlying operating characteristics of the RF parameters. It depends on the manufacturer to provide us the information at the time of application on how such controls are implemented.

The FCC also updated the guidance in question (pdf) and penned a blog post that tried to explain all this. But while the FCC may not have intended to block third-party firmware, many worried that because many routers have "system on chip" -- where the CPU and radio exist in a single package -- router vendors would "solve" the problem by just taking the cheapest and easiest path and locking down firmware entirely. And that's precisely what appears to be happening -- at least with one router manufacturer.

Gearmaker TP-Link recently posted a notice to the company's website announcing that as of June of this year, it would be locking down firmware installations on its routers entirely. In a statement, the company blames the FCC for the fact it's taking the lazy route and annoying its more technically-proficient customers:

"The FCC requires all manufacturers to prevent user from having any direct ability to change RF parameters (frequency limits, output power, country codes, etc.) In order to keep our products compliant with these implemented regulations, TP-LINK is distributing devices that feature country-specific firmware. Devices sold in the United States will have firmware and wireless settings that ensure compliance with local laws and regulations related to transmission power."

Again, TP-Link could work with the community and developers to ensure users can mod everything but radio parameters, but it's being cheap and lazy. The company's statement then adds insult to injury by pretending it still values the community's "creativity":

"As a result of these necessary changes, users are not able to flash the current generation of open-source, third-party firmware. We are excited to see the creative ways members of the open-source community update the new firmware to meet their needs. However, TP-LINK does not offer any guarantees or technical support for customers attempting to flash any third-party firmware to their devices."

So, hey kids, we're locking down your ability to be creative starting this June, but go be creative! In one blow, TP-Link is not only alienating a large number of potential customers, but making networks less secure (since custom firmware tends to be more secure and updated more religiously among the tinkering faithful).

I've reached out to the FCC for comment, but wasn't able to glean any more detail from the agency beyond what has already been said. And while the TP-Link lockdown may have not been the FCC's plan or its fault directly, it may very well be a very ugly, unintended consequence. It's a shame that an agency that has been a bit more consumer friendly in terms of opening up other hardware and beefing up broadband competition didn't spend more time thinking this through.

Fortunately, TP-Link isn't exactly a brand favorite for most router buyers anyway, and the company's language leaves some wiggle room to suggest that while "the current generation" of open-source third-party firmware won't work on routers made after June 1, future versions of this same firmware may. TP-Link also appears to be the only vendor doing this (so far at least, please correct me in the comments if this has changed). With any luck, a few competing router vendors will see this as an opportunity to not be lazy and alienate customers -- but to compete by providing gear that still respects a user's freedom to tinker.

Filed Under: dd-wrt, fcc, firmware, open source, open-wrt, router
Companies: tp-link