Home entertainment implementations are pretty appalling
mjg59.dreamwidth.org
mjg59.dreamwidth.org
It's like these companies spend a year getting the hardware ready, then at the last minute realize it needs software. So they find some monkey to barely manage to get ARM Linux slapped on to it so they can ship something.
It's gotten to the point where I really appreciate the attitude from some of the new up-and-coming set-top box manufacturers who basically say on their web site, "Screw it, we're a hardware company, here's how to get root and do it properly.", e.g. [2]
1: https://news.ycombinator.com/item?id=7616420 2: http://www.pivosgroup.com/
Personally, I'm perfectly happy with a "dumb" TV with lots of HDMI inputs and a Raspberry Pi with XMBC installed.
Apple TV is one of the better set-tops, but still far short of its potential. I attribute this to a "first we build the locks, then if there's anything left, we'll build the house" mentality forced on them by media companies. I wouldn't be surprised if every manufacturer more or less suffered from this and leaving in easy rootability is a form of subtle rebellion.
Good luck unlocking/hacking an Apple device.
Full-blown iOS devices get jailbroken pretty quickly. I assume the difference here is that no one cares about the Apple TV, so there's little incentive to hack it (exaggeration, but the difference in Apple TV owners vs. iPhone owners is probably several orders of magnitude). Even if you did hack it, what's the point? There's no hard drive to store your pirated videos, and IIRC these things can stream videos from your PC out of the box anyway. If you're gonna install XBMC and bypass the Apple TV interface completely, why get an Apple TV in the first place?
This is because there are already many TIVO/DVR/HTPC/Console Media software applications that do a pretty good job at this. Apple is having a hard time breaking into an existing market with something that is already fairly polished by the community.
It is impossible for Panasonic to find out about this or do anything about it, because like many companies they value interaction with their customers so little that it is outsourced to the lowest bidder. Those companies business model is to give out the same answers to the same questions over and over again. They cannot cope with an answer they don't already have. The one Panasonic uses in the US is even worse, refusing to tell Panasonic about the issue. They also have a cunning system where links to surveys after chats don't work, and the phone survey won't recognise giving them low scores!
If anyone is curious I wrote about the whole saga at http://www.rogerbinns.com/blog/support-tale.html
Bottom line is that when a support system like Panasonic's isn't working for you, quickly to abandon it and resort to a proper business letter sent through the mail. Format it properly, keep it very short and clearly state what you want, and include at least one complement as this works wonders. It takes less time than all the bullshit on the phone, plus I have seen a 100% success rate after resorting to this myself. I do 3-4 a year, easy.
Look up the company's address and CEO, or head of that particular product division. Spend a tiny bit more than normal postage and get signature proof of delivery, it really is worth it.
Include your email address on the printed letter and you will hear back from someone at the company who can actually help you. And be quicker to abandon the traditional support channels when they frustrate you. I'll set a hard limit of 10 minutes to get a human on the phone who sounds competent before I hang up and send a letter. I'll hang up right in the middle of their script, I just don't care anymore. The letters work.
And I'm almost willing to bet that not letting you enter spaces might be the result of a "security fix" because they pass the contents of that field, unescaped, directly through to a wifi configuration shell script, and someone doing some testing discovered that spaces would "cause things to break", so the solution was to disallow spaces instead of performing escaping on the password string.
Also related: http://thedailywtf.com/Articles/Securing-Secure-Security.asp...
Edit: while Googling around for some other devices that might have this interesting issue, I found... https://github.com/xbianonpi/xbian-package-config-xbmc/issue...
Why is escaping input such a difficult concept to comprehend?
It's a sign to me that they're extremely lazy, or their code is so bad that making small exceptions are very difficult/brittle.
"Now that we're translating this UI to English, what do we do with all these buttons that aren't needed?" "Too much work trapping into the UI drawing code to hide them, let's just remap them to something else... how about space! That's harmless!"
Good point about the punctuation.
Compounding things by keeping customers as far away as possible ensures that lessons are not learned.
no-break space U+00A0; zero width space U+200B; word joiner U+2060; ideographic space U+3000; zero width no-break space U+FEFF;
They all look the same tho.
From: http://www.fileformat.info/info/unicode/char/0020/index.htm
kalleboo posted a Japanese screenshot below https://news.ycombinator.com/item?id=7620577
Do the 5 space keys not work in all of those options? Do you get a working space key if you're in symbols for example?
Consider: You've got a slew of products for which rapid iteration and obsolescence is a key attribute, profit margins are slim, cost pressures are immense, talent is limited (and not attracted by time and cost pressures), parts availability is arbitrary, capricious, and liable to change with little notice or reason (we've seen in the GM ignition switch recall what the implications of even a minor parts change can be, in a slightly different space).
A few years back I had the distinct pleasure of attempting to configure and deploy a major enterprise vendor's storage product on what the sales team promised, but the support team denied at pain of abuse to my firm, was supported under our OS. The company shall remain nameless, but rhymes with "hell".
What I eventually established was:
• The vendor itself had little or no real understanding of the equipment or its configuration.
• The documentation for the underlying technologies (all, as it happens, open source free software), ranged from quite good to abysmal. One README file consisted entirely of the text "Good things to read here.". We were less than gruntled.
• True support was actually a pass-through to the OS vendor, who, it turned out, wasn't in fact the source of our OS. We'd been sold something which didn't in fact exist (real support).
And that was for high-end enterprise-grade hardware.
The situation for the consumer-grade stuff, especially the cheap consumer-grade stuff, is far, far worse.
Which is why I want the products I buy to have the absolute minimal amount of technology in them as possible or necessary. It's fewer opportunities to foul up.
The complexity problem extends to the legal side as well. Much as I think liability could help, it's going to be hard to apply, particularly with lay attorneys, judges, and juries.
You probably need a router that runs OpenWRT, Linux or BSD like caramobola2[1], to configure manually in order to monitor incoming and outgoing connections, blocking suspicious traffic.
Then you probably need something that can run XBMC[2] as a home entertainment system (atom HTPC works like a charm, I have one). Then a flashed dreambox PVR which runs linux too and you can do a lot of things but most importantly monitor everything.
So basically, anything that runs proprietary software is a security concern. Strangely, the more corporations try to build walled gardens the bigger the security risk is.
[1] http://8devices.com/carambola-2
[2] http://xbmc.org/
This dawned on me when I intended to switch over to FIOS due to problems with my cable internet connection. I moved all of my media and gaming devices first, then abruptly stopped, wondering why I would want to share a network with a bunch of devices I had no reason to trust. I know I can isolate them on my home network, and may eventually get around to it, but in the meantime, I'm using separate connections to different ISPs (which provides other benefits, as well).
Unfortunately, it's actually quite difficult to do that properly with a typical broadband/WiFi box as supplied by most ISPs (at least here in the UK) by default. You need to step up to business-grade gear in most cases, which is both more expensive and beyond the technical knowledge of most consumers, and even then some otherwise respectable devices are regrettably lacking in flexibility when it comes to VLAN configuration and the like. I'm looking forward to the day when standard home user boxes allow you to do things like isolating certain physical ports or wireless networks by default, so hopefully running untrusted devices on independent networks becomes routine.
Even then, there's still the problem that if you want to watch some sort of streaming content off the Internet, whichever device(s) have that external connectivity could also pose a privacy risk if they have access to whichever devices are acting as home media servers. DLNA seems like a step in the right direction for connecting up home media devices, but I haven't seen much evidence of a robust security model being implemented so far.
Most of your time is spent around finding libraries that can be compiled for your board or fixing device drivers because of that slight board modification the hardware guys did. You also have to figure out how the proprietary hardware encoders work and make them work properly. If the documentation doesn't fit the implementation? Well you have this contact under nda agreement that will eventually say "I don't know either, have you asked in the forums?" after 2 weeks of back and forth. Also sometimes your device would just reboot and you'll spend time arguing with the hardware guys that linux don't just reboot for no reason. Did I mention having to worry about how your 64mb of ram get allocated and in which DSP pool?
Eventually, you'll find time to write code that will cause your device to do something meaningful.
Writing software for hardware is much harder than it seems, because you have to worry about all those things you take for granted when working with a x86 desktop. You can't upgrade often after shipping, so testing focuses on critical bugs instead of usability. I do agree than spending more resources would make sense, but consider this : Hiring a DSP specialist to get an H264 encoder to work would cost 80k$ in Montreal in 2007. This is something that is now free with newer chips, but just getting the hardware to work used to drain a lot of resources. Larger companies could have more money for that, but I do not know how they work internally so I can't speak for them.
They want to send it for repair because to be honest they are fucking morons and however much explaining I do they don't realise that the manufacturer doesn't support any kind of firmware update. I want my money back so am having to take them to small claims court in the UK to force a refund under the sale of goods act because the item is not fit for purpose.
Between this and a Bravia EX which is buggy as hell I'm tempted to just buy something that will run a Linux based media center with a PC TFT and say fuck it to consumer appliances.
All converged appliances suck, and probably always will, and the consumers are figuring it out, which will be the doom of the "convergence" meme.
Non-converged appliances usually work pretty well. My dumb TV displays whatever the HDMI flings at it, the separate optically connected surround sound system works beautifully, the computer hooked up to them just does its thing.
Indeed, source code availability (much weaker than FLOSS) is very useful in software analysis. Nonetheless, while in most cases this is just tedious and boring work, one can still validate proprietary binary blobs. Obviously, that only applies to countries where reverse engineering is legal.
In my opinion, validation/analysis is a necessary but insufficient condition for control.
So while I agree that "secure, full control" > "insecure, full control" > "secure, no control", since the first option is highly unlikely and efforts toward more security are probably going to result in the last one, I think the middle option isn't that bad after all...
I'm not arguing that open source isn't a better system, just that it's not a guarantee of safety when compared to closed source in this regard - both systems have to have competent people actually caring enough to pore over the code and provide fixes. Consumers cannot be expected to manually review and audit every line of code in their networked devices, nor (apparently) can they reliably depend on someone else to do it for them.
http://www.zdnet.com/coverity-finds-open-source-software-qua...
If you seriously think that all bugs in open source are found and magically fixed immediately, I suspect you should try working as a community member / contributor of an open source software project.
I don't think that at all. But, the heartbleed bug is an example of one which should have been, by all rights. It wasn't due to some complex crypto implementation, or an arcane syntactical edge case in C. It was a pointer bug. It was a simple, critical fault in a bit of software which had a lot of very qualified eyes on it, which a lot of people here would ridicule as a matter of course.
Now why, if something like that can happen with code most hackers and open source proponents care passionately about, should it be taken for granted that enough people are going to be validating dvd player and smart tv firmware for the end result to be better for the average end user than expecting whoever the manufacturer hires to do it?
Do we know this particular bit had had a lot of very qualified eyes on it? This is the problem with the eyeball theory. That a piece of code is open for anyone to read does not mean people who care actually read it. Everyone: it's open source, there are many of eyeballs on it, therefore I don't need to read it!
I'm trying to think of ways to make people wake up and routinely review the code and changes they use. You really don't need to be an expert programmer to spot a duplicated goto fail or the total lack of bounds checking.
http://www.theguardian.com/technology/2014/apr/11/heartbleed...
From Robin Segglelman, the maintainer who "accidentally" added the heartbleed bug:
""" ... OpenSSL is definitely under-resourced for its wide distribution. It has millions of users but only very few actually contribute to the project." """
I really think you should try joining and open source community and contributing some code. Then I suspect you'll understand that it is just as hard as any proprietary code (like that which I work on for $day_job). The difference is that Open Source code, even critical stuff that runs the internet, is often woefully understaffed and over expected to be perfect.
>I really think you should try joining and open source community and contributing some code.
I have, not often though. Certainly not to anything critical.
Now try the same with open-source software. There will be far fewer problems to find, because all of the obvious ones have been fixed already, and most of the difficult ones too. Even if you do find a problem, as soon as you put some information out there about it it'll be fixed. Upgrades invariably happen more quickly with open-source software, even in firmware roles, so the population is covered more quickly as well.
That's what is meant by 'given enough eyes'; not that all bugs are found and fixed immediately, but that all bugs are found and fixed eventually. OpenSSL simply didn't have enough eyes, for a variety of reasons. Developers in the US were discouraged from contributing, since our legal system has in the past been a risk to that kind of project. Many developers avoided it because they didn't know anything about old systems like VMS, or about cryptography. Most of the rest of us avoided it because it wasn't obviously broken.
Edit: We also generally assume that the NSA has 'enough eyes'. If they decide that they have to attack product X, then they get a bunch of people to look at product X and find its bugs. It doesn't matter whether it's open source or not, it's just a question of the number of eyes you apply to the problem.
No, open source is not, in and of itself, sufficient.
I do believe increasingly, however, that it is necessary.
But so are other attributes: a healthy development culture, an approach which preemptively seeks out and eliminates security threats and holes, and most importantly, operates with the end-user as a primary focus. Projects with a strong record of this include OpenBSD (which is now conducting a focused effort to clean up the OpenSSL code: http://opensslrampage.org/) and the Debian project (with formal social contract, constitution, and policy all of which put the interests of the end-user front and center). While Debian's had its security snafus, particularly relative to OpenBSD, among Linux distros it's tended to be among the more secure and security-conscious distros, in my experience.
But projects with a long track record of disdain also tend to show themselves for want of strong security: PHP, awstats, GNOME, and more recently, systemd, all come to mind. I have grave concerns over the damage the latter is now in a position to do, and the fact that one dev has already been denied privileges to submit kernel patches by Linus Torvalds doesn't do much to increase my confidence.