Yes. It would. However if the device is allowed to roam on other networks (such as a laptop an employee can take home) this can cause issues with various key pinning solutions, and possibly also with HSTS.

Unfortunately the days that it was easy to intercept TLS traffic by simply trusting your own CA are slowly going the way to the dodo because of CA abuse that has happened in the past.

This mindset of "we just need to protect at the borders; this protects endpoints" is wrong. While it provides some protection, there are so many other avenues of infection or acquiring malware that trying to equate TLS with making things simpler to hide just seems incredible of an assertion to make. These days you absolutely need to make sure that endpoint protection is just as strong, if not stronger than what you deploy on the borders of your network.

As more corporations allow bring your own device to save costs, and give employees laptops, you can no longer trust in just filtering at the border, because the devices can move, people bring in thumb drives, and other avenues for getting malware. TLS or no TLS, I have a feeling that most HTTP intercepting proxies would not have caught newer malware in ads even if configured to do so, simply by the nature that by the time there is a signature available for it, it is generally already too late and people will have been infected.

IllumOS is the base operating system, much like Linux, except that it comes with a full user land too.

Those are all distributions of Illumos. All of them contribute to Illumos and build on top of it by providing their own packages/packaging systems and system that run on top of Illumos. Think of them like Ubuntu/CentOS/Debian to Linux.

Illumos is the "leader", and the base operating system that all of those products use (AFAIK). Each of them have different options/features. NexentaStor for example is built to be a ZFS based storage appliance solution, SmartOS is for datacenters/virtualisation and things of that nature. They each bring something unique to the table. Each of them is built by a different company that offers different types of support.

OpenSolaris is still around, just with the name changed to OpenIndiana. OpenSolaris after a pkg mirror location upgrade was readily renamed to OpenIndiana, and this was the upgrade path that I took personally.

Hope this helps clarify things a little.

but I as a developer sure do notice. The biggest issue I keep running into (developing backend software for my companies frontend software) is that testing on a mix of devices means learning the quirks for every single manufacturers user interface that they have bolted on top of Android. We've also had some weird issues based upon the Android version installed, across two devices with the same Android version number (4.0 for example) with the carrier/device manufacturers changes we have a bug on one but not the other.

This is highly annoying.

One issue that Android users hail as the greatest thing since sliced bread (alternate keyboards) actually meant having to write work-arounds because some keyboard implementations were simply broken, or actually caused issues with entering text in certain situations. An alternate keyboard shouldn't be able to have that sort of an effect!

Fragmentation is real, and it is an issue. Consumers don't notice because they only use a single device, developers and power users that may switch more often than the average user will notice and it is an issue.

You seem to have lost the ability to read. No, I was specifically stating 100 mA, that is the max any USB device is allowed to pull from any charger or device it is plugged into, UNLESS it asks the host for more OR the D+/D- lines have specific voltages/are shorted.

Apple requires specific voltages precisely because the standard of just shorting the D+/D- lines don't provide enough information. Just how much current should an iPad attempt to pull from a charger that has the D+/D- lines tied together? It can be unsafe for a device to pull more amps than a power supply can provide for a variety of different reasons, especially with switch mode power supplies.

---

As for your last point, while you and I may agree on one thing, that it is is a vulnerability and it should get fixed, it isn't a classic vulnerability. It doesn't take advantage of bad coding practices, there is no buffer overrun, or null terminated string vulnerability which is what you were referring to in your original post.

The biggest problem I have with my Touchpad (I own one too) is that when inductively charging it won't charge nearly as fast, and I've had plenty of times where it has been sitting on the inductive charger for a day or so, and I pick it up and 20 minutes later the battery is dead. Whereas charging it over USB seems to always charge it fully and properly.

Why does this guy keep getting modded up to informative? There is no Apple DRM, there is no blocking of 3rd party chargers. Apple devices while charging look for certain voltages on the D+/D- lines, there is absolutely no communication between the device and the charger. The only reason there is a requirement for certain voltages on the D+/D- lines is so that the Apple device knows it is safe to pull a certain amount of amperage from the charger...

This is so completely wrong that I don't even know where to begin.

1. Apple hasn't put DRM in their chargers
2. Apple devices look for a certain voltage on the D+/D- traces to know whether they can charge at 100 mA, 500 mA, or more, specifically the iPad can draw more power
3. Apple devices are also USB devices, when they connect to a USB host (such as the BeagleBone) they communicate using standard USB, that is the only ID string that gets sent back, along with a request for at least 500 mA of power to be provided by the host.
4. This doesn't actually use any specific vulnerability, rather it uses the fact that when you connect an iOS device you can using a provisioning profile side-load apps onto the phone. This is generally done during development or for example in corporate settings. These same provisioning profiles can be used to disable certain features, or set up emails accounts, wifi passwords, and all that fun stuff, you know to provision a device in a corporate scenario.

It's a shame that your comment got voted up as informative when it contains so much mis-information.

I am wondering how this stacks up to a project like WebKit/Blink, as well as seeing that project against the original KHTML. Sure it is a renderer/HTML layout/JavaScript engine only, and won't contain the browser chrome like Firefox, but I think it would be interesting to look at.

Many people have also suggested that WebKit is easier to embed into various different environments (more so than Gecko) and that it has been able to evolve faster mainly due to the code base being cleaner, and I wonder if this holds true when looking at it from a complexity standpoint, or is it more complex but simply laid out better and in a way that is easier to understand?

You have clients ... charge a little more and absorb the cost of new hardware. What's so hard about that?

Even if Windows were running on bare hardware I could play tricks with the clock, I could hide memory from any program that Blizzard could come up with to attempt to scan regions of memory, I still could pull all of the tricks you just mentioned. How? Using good ol' virtualisation extensions that exist within processors.

Not only that but I own the hardware, I have physical access to the hardware, there is no good way for any program to insert itself at a higher level. I control the boot process so I get to choose where the OS is loaded, I get to change the way it works and interacts. Writing kernel level modules that tamper with time like you are suggesting that would be simple with Wine are entirely possible using straight Windows as well.

Thats the biggest problem, Blizzard doesn't own, they don't manufacture and they can't guarantee that no-one has tampered with the hardware. There comes a point where the software is running on top of the hardware and it has to trust that the hardware is not being malicious. This is how cable box hacks, and satellite box hacks used to work.

Blizzard can write a root kit all they want, if people want to cheat and if there is enough incentive to do so people will find ways to defeat the rootkits behaviour and cheat. Until everything is sent over an RDP like protocol and no code executes client side this is a problem that is going to exist for the foreseeable future.

This issue has been going on for a long time, and each time a BSD developer asks to see solid docs so that he/she can port the API to be used on FreeBSD they get a bunch of incomplete specs that are absolute shit.

http://gezeiten.org/post/2011/01/Xfce-4.8-on-BSD-flavors#c14587

Warner Losh asking for good specs to implement udev on top of devd which has done the things that udev now does for years.

If the device/board already has 120v coming in on it, then having a device keep its time from AC is rather simple. One zener diode, a resistor and an open pin on a microcontroller are all that are required.

Take a look at some zero cross detection circuits, they are extremely simple, and the parts for them are cheaper than for a crystal that is accurate at time keeping when the power companies keep the 60 Hz in sync.

I've got a MacBook Pro. It's going on year 5 at the moment. No issues with the hard drive.

Whisper Systems is an US based company that has never provided user data to Egypts government, nor has it allowed them to send messages through their system. You are thinking about Vodafone which was forced to do so by the government.