The problems with "Wi-Fi" are numerous. The end result is that generally speaking, Wi-Fi is a hot mess of broken tech that doesn't work. In the rare case that it DOES work, even the most trivial of changes in the environment or in the client can completely break it.

1. Early versions of the spec were too loosely worded, and allowed for too many "interpretations".

2. Vendor extensions are still a major problem. Many vendor extensions are not compatible with one another, and a device that has a vendor extension enabled
may work very poorly (or not at all) with a device lacking said extension.

3. Actual implementations of Wi-Fi are all over the map in terms of quality, with ridiculous things like: advertising support for an extension that it doesn't actually support; criminally severe bugs in a production implementation; vendors that try to work around bugs that other vendors introduced but in turn create yet more bugs, causing a vicious cycle of workarounds to workarounds; "hide and go seek" with extensions and spec interpretations; ridiculous driver implementations that hold exclusive access over very coarse-grained locks in the OS kernel for long periods of time, causing freezes and/or panics; poorly designed antennas; buggy firmware that never gets updated; etc.

4. The spectrum WiFi uses is open to be used by literally anything else that complies with a few simple rules, such as the maximum Tx power on that frequency band. As a consequence, random electric devices can freely leak a certain amount of random interference (noise) in the 2.4 GHz and 5 GHz WiFi bands, which destroys the ability for WiFi to operate. Ever lose your WiFi when you turn on your vacuum cleaner, or microwave? That's what's happening.

5. The spectrum WiFi uses is used by other communications protocols that are not Wi-Fi. While some effort is made to interoperate between a few of them, such as cooperation between Bluetooth nodes and WiFi nodes (such that they don't "trample over" one another if they use the same frequency), the interoperation protocols, specifications, and implementations have the same problems as the Wi-Fi specs themselves, as stated above.

6. Recent increased focus on power saving has caused some rather extreme power saving techniques to be employed in Wi-Fi firmware and drivers, which sacrifices performance, range and reliability for a few microwatts or milliwatts of energy. Paradoxically, some of the proponents of these techniques actually think that's OK, and are still trying to make the problem worse.

7. There are a large number of complex physical parameters that affect whether two WiFi transceivers will be able to communicate, which 99% of users don't understand at all. The power saving techniques mentioned above reduce the variety of possible configurations (that is, device orientations and distances, mainly) under which the signal will be reliable and high-performance.

8. Vendors that produce Wi-Fi transceivers, or products that integrate them, usually perform inadequate testing to certify the device as interoperable with a very large array of existing and upcoming other products that use Wi-Fi. Especially in the case of smartphones, the possible number of clients and basestations that may be interacted with is tremendous: Smart TVs; DSL modem/routers; cable modem/routers; other smartphones; enterprise APs and repeaters; laptops; tablets; cars; IoT devices -- all these things need to be tested. With a LOT of work -- and I mean a LOT -- eventually a Wi-Fi stack can be designed in such a way that it operates at least decently well with all modern incarnations of the above, but that says nothing about older implementations, which people love to keep around for a decade or more, and expect them to work. A sufficiently general Wi-Fi stack that works okay with all of the above will probably have so many heuristics for bug detection, compromises, polling tests, etc. that they won't work especially well even in an "ideal" scenario, and may even try to implement contradictory rules depending on the specific model of the device being communicated with... basically, it's nearly an effort in futility to develop such a thing, let alone have it work *WELL* with everything.

If USB and its "device class" specifications (Mass Storage, Battery charging spec, RNDIS, audio class, etc.) is a ringing success story of how standardization can promote interoperability, Wi-Fi is a textbook case study of how faux "standardization" can go so, SO horribly wrong that the only way I can see to fix the problem is to abandon the 2.4 GHz and 5 GHz spectra entirely, and come up with a new, non-WiFi communication protocol that is much more tightly specified, open standard, general purpose, and functions on some other band that does not overlap with the WiFi bands (since those bands will be eternally trashed by millions of WiFi devices for at least 20-25 years after the last WiFi device is manufactured).

This is a little story about four people named Everybody, Somebody, Anybody, and Nobody.
There was an important job to be done and Everybody was sure that Somebody would do it.
Anybody could have done it, but Nobody did it.
Somebody got angry about that because it was Everybody's job.
Everybody thought that Anybody could do it, but Nobody realized that Everybody wouldn't do it.
It ended up that Everybody blamed Somebody when Nobody did what Anybody could have done.

Basically, there needs to be a team of people (whether volunteers, paid employees, or a mix) who are dedicated to spending a specific number of hours explicitly assigned to working on security testing of a piece of software, and then have those hours held accountable. Meaning, if they have no results over a long period of time, or aren't putting in the hours, even if they're just volunteering, then their position on the team should be vacated for someone else willing to do the work.

Features are completely different, and most types of non-security bugs are also different. In general, people implement features because they find it genuinely fun to do so. Also, as long as the software has users, the absence of a feature will not normally cause millions of dollars in damage, loss of reputation, or identity theft. The consequence of the absence of a feature is usually annoyance or inconvenience, but is upper bounded by what that feature would provide if available, rather than being upper bounded by the limits of human cruelty and deviousness, which are MUCH higher bounds than even the most major features.

This is why it's OK to let features develop "organically" in a bazaar fashion. Even bugs can be developed this way: if nobody is encountering the bug, who cares if it's there? And bugs that are encountered frequently will get complained about and/or fixed directly by the core devs or a drive-by patch. Security, on the other hand, almost requires a deliberate, cathedral model to provide any guarantees.

Bringing small aspects of cathedral development philosophy -- the best parts of the cathedral only -- into projects that were once purely "bazaar-only" projects like OpenSSL, can only be a good thing.

That's no problem. They'll just get their buddies in Congress to write them up a law that says that whatever they do is fine. Or, if that causes too much of a ruckus, they'll just provide Congress with a long laundry list of the things they do, then get Congress to copy and paste that into the law.

Same as it ever was....

EXACTLY. As long as the tax code is ridiculously complicated, we're going to need ridiculously complicated bureaucracy and IT systems to manage and enforce that complexity. Let's see how well our new GOP overlords in Congress manage to legislate an actual reduction in tax code complexity, now that they have the gavel all to themselves in both the house and the senate.

Let's not bring the cart before the horse. If you want an IRS that can run on a shoestring budget, make a shoestring tax code that I can print on my home inkjet printer -- THE WHOLE CODE -- in under 5 minutes.

Otherwise, shut the fuck up and fund the IRS so they can do what they are required to do by law.

Most root exploits I've seen have two components to them: the attack vector, and the payload.

The attack vector is usually a series of commands that have to be run to get the payload onto the device. This part is fully auditable and usually "open source" in the sense that you can perform these commands yourself. If someone sends you a .bat script with a bunch of adb commands, you can always open up the script and read it and make sure nothing is malicious in there.

The real problem is that 99% of the root exploits out there have to upload some kind of a binary file to the device, which is then executed. In MOST cases, the source code to this binary is not disclosed, perhaps to make it harder for the manufacturers to fix the exploit, or to keep their attack methods secret, in case the code might expose some more general pattern of attack that would enable the manufacturers to close a whole series of root exploits.

So basically you are trusting someone who compiled a Linux binary *whose job is to obtain escalated privileges on your device* to then not use those privileges to install some kind of tracking malware, data siphon, or cookie exfiltrating software, or even just a rootkit providing them a backdoor, which initially does nothing but can be activated at any time when the author feels they need something from your device (like participating in a botnet, perhaps?).

I'm a little surprised that the comments so far haven't really tackled the crux of your question, which was NOT "how do I find root exploits", but "are they trustworthy". Remember, folks, just because it's posted on XDA, doesn't mean it's trustworthy. Anyone can register an account on XDA; absolutely anyone.

I've read statements from root exploit authors who've said in plain language that they have no motivation to bundle malware in their root exploits and thus don't ever do so, but that's like the NSA saying they don't spy on Americans. We have no way of verifying the statement, and several reasons to suspect the contrary.

If you are in doubt, I would suggest that you forego root exploits altogether. Instead, you should simply refuse to buy any Android device where the manufacturer does not provide you a means to unlock the bootloader. Once you have a (legit) unlocked bootloader using official tools from the manufacturer, you can then proceed to install any ROM you want -- even an open source ROM that you could audit yourself -- which then gives you root access. Remember, on an Android device, root is far less powerful than an unlocked bootloader, so that's really what you should be aiming for anyway, to have a truly "open" device as an enthusiast.

"...within 125 miles (200 kilometers) of the lunar surface at its closest point, and out to a range of 3,293 miles (5,300 km) at its highest point..."

Thanks to Kerbal Space Program, I know what those are called! The first one is the periapsis and the second one is the apoapsis. :D (Yes, I know, common knowledge, but it's cool that a game taught me a thing or two about spaceflight...)

Too bad real life has the Ferram Aerospace mod enabled; this craft very likely would be unable to reenter the atmosphere and land (or splash down) without breaking up, because it's not designed to withstand the heat and drag forces.

Circa 1990, I had a 486 DX PC running DOS with two floppy drives: the standard 3.5", and the older 5.25". This was during the transition from the larger and lower density 5.25" to the more modern "High Density" 1.44MB disks. The BIOS would check to see if there was a disk in each drive in their initialization order: first "A:", the 3.5"; then "B:", the 5.25". We had a 180 MB HDD, so we didn't ordinarily boot up the computer to a boot disk except for recovery or for specific legacy software that required it; instead you'd boot DOS from the HDD, then insert a disk to install the software to the HDD, or (for older programs) run them directly off the disk.

Anyway, the disk drives were almost comical in the audible noise they made when the BIOS asked them to determine if there was a disk inserted. I distinctly remember that the sound of the two drives was in harmony, like music: two "BOOOOO-doop!" noises, one about two octaves higher than the other, in sequence, each lasting about 1.5 seconds, with a 0.5 second pause in between.

I was 5 at the time, but that was my intro to computers. It was the first PC our family owned.

Many devices containing software are intentionally designed to be hard to fix/repair. With the exception of open source applications running on a PC, or open source operating systems on said PCs, an increasing number of appliances and "gadgets" have software that is completely locked down. If the software out of the factory is not 100% perfect and there is some kind of a defect, the consumer's only option in most cases is to buy a different device.

Worse, since the software is the same between each unit produced, the consumer could go through the RMA process dozens of times and still have the problem. If the manufacturer does not acknowledge and fix the problem, the user is SOL.

This is largely a consequence of consumers not truly owning the devices they buy anymore, due to companies valuing their "IP" over (digitally-infused) consumer appliance serviceability. Try fixing a shoddy driver on an Android smartphone from a major US carrier (90% of them are locked down) and let me know how you make out, with "brief" engineering knowledge. Ditto for the faulty ECU in your car, or the faulty temperature regulator in your fridge, or...

The only situations where the OP may have a valid point are with things that have not yet been designed, in mainstream models at least, with significant digital components. For example, if your toilet starts leaking, the knowledge and technique to repair this low-tech item probably hasn't changed in at least 40 or 50 years. But these examples are quickly vanishing, as even toilets are starting to have digital components. Usually, you are *lucky* if your manufacturer provides you with some kind of instructions on how to buy and replace the complete electronics package in something like a dishwasher or a washing machine. If you are attempting to repair it without actually chucking the whole component and installing a new one, good luck -- provided you're not an Electrical or Computer Engineer.

One of the coolest client-side features of most SSH clients (at least OpenSSH and PuTTY support it) is the ability to turn any SSH connection into a SOCKS5 proxy, provided the server will let you. If your Internet connection has a restrictive stateful firewall on it that blocks your access to many useful legitimate sites, you can just stunnel out over TLS and then have the ability to go outbound on any port (including SSH's default port of 22) using your SOCKS5 proxy. I've used RDP over SSH over TLS before to get around restrictive filters.

There's an entire episode of ST: Enterprise devoted to depicting the life of freighter crews on early warp ships. If I recall correctly, they're only capable of warp 1 or 2, and this is first-generation warp, so it's much slower than the "Warp 2" you might hear Picard give the order for in TNG, or even the "Warp 5" that the NX-01 Enterprise is capable of. These crews spent a lot of time in deep space doing absolutely nothing except reproducing like bunnies.

The neat thing about the freighter crews as they were depicted in the shows, was that the crews were often families that would live and reproduce on the ship, spending their entire lives in space on a fairly small and poorly-armed vessel. They would occasionally take on new blood from outside their family unit (this helps combat the immediate idea of gene pool degeneration), but the majority of the crew would be biological relatives.

These crews were much less idealistic than Starfleet personnel, and were very much loyal to their families above and beyond any set of ideals. No doubt they'd encounter all kinds of sticky situations in space with pirates, Klingons, and even Starfleet, and have to defend their family, defend their ship, make ends meet, and survive.

A show like that would necessarily have to involve a lot less space combat (and fewer explosions therefore), because even a small warship like a frigate or a destroyer can *easily* overwhelm and destroy a freighter in the Star Trek universe (all time periods), as well as outrun them and probably have better-trained military crew for boarding parties as well. The freighter crew would have to get by on wit, cunning, deception, and probably a whole hell of a lot of sacrifice. Not much you can do with a small pulse cannon against a military vessel, when nobody in your family is trained in the kind of specialization that, say, Data would have, when he'd save the day every other episode with technobabble trick after technobabble trick.

What I said above is NOT in any way a knock against TNG, just saying that you're asking for a very, VERY different side of Trek, but I think it's doable, and there's a lot of established lore in this area that could easily be drawn from to create a series.

However, I don't think it would stick. The majority of the hardcore Trek crowd wants to see a crew on a Federation flagship, or at least a Federation-operated space station. The non-Trekkies would get bored by the lack of explosions. So it's unlikely that such a thing would make an appearance on TV or in the movies.

Indeed. Aside from that, "intellectual" threats to the characters (figuring something out with science and creativity; outsmarting an opponent; devising a diplomatic solution to a problem) create far more tension and build-up to the crescendo. The threat of massive loss of life could be the end result of whatever dreadful thing they're up against, but if their solution is to shoot the hell out of it, it's boring, because you KNOW there's no way the movie could proceed except for them to win. Sure, somebody you're attached to might tragically die, but even that trope is pretty old by now, even within the Star Trek film canon (Spock and Data).

What I've been wanting -- and not receiving -- from modern incarnations of 'Trek are basically the scenes that directors like Justin Lin and JJ Abrams would cut, if they even allowed the scenes to be filmed.

Like the drawn-out philosophical conversations between Wesley and Picard in TNG.

Like the near-total audio silence between lines of dialogue during Spock's death scene in the Wrath of Khan.

Like the many times that a character would *tell* a story through words rather than the viewer being *shown* the story through whizzy graphics.

Like when the activities of the Federation personnel vaguely represent the moral code and rules of engagement that they apparently seek to uphold.

It's not going to get better. The cognitive dissonance behind producing movies these days is stunning. If you don't meet quotas for number of CG-rendered frames and explosions per minute, they won't let you run it in theaters.

Step 1: Pray that the foundational assumptions of state-of-the-art crypto remain true (no P=NP or quantum computer cracking nonsense, please).

Step 2: Rent/buy/lease/colo a VPS or dedicated server in a country that respects users' freedom and doesn't tamper with their network connection.

Step 3: Set up a VPN on said server.

Step 4: Use the latest crypto algs you can get your hands on; apply security patches aggressively; and watch out for notices of weaknesses.

Step 5: Use the VPN on absolutely every device you own: at work, on your phone, on your home router, etc.

Step 6: ???

Step 7: Eat My Bitstream! No more ISP interference.

IMO Step 1 is the shakiest, but it's all we've got for now.

I have the Vue system. This is apparently an ugly redheaded stepchild (like Windows ME, or Windows XP x64 Edition) that came between the "original" Keurig, and Keurig "2.0". It lacks any form of DRM, and there are $10 plastic adapters on eBay that allow you to brew any original K-Cup pack using the Vue. I tried it and it works fine.

The features of the machine are much better than the original Keurig: larger water tank, touchscreen with customizable temperature and water amount, it heats up and brews faster, doesn't make a horrible noise when brewing, and it accepts both K-Cup Vue and original K-Cup packs. Oh, and it has a water filter in the water tank (you still have to replace it of course), so I don't have to wait for water to trickle out of my fridge's filtered water dispenser to fill up the Vue: I just fill up a glass or pitcher from the kitchen sink, unfiltered, and dump it in the Vue's water tank. The filter takes care of the rest.

Sometimes the red-headed stepchild is the sweet spot. Like how Windows 2000 was a suitable substitute for Windows XP for many years for folks who didn't like the whole Internet-based Windows Product Activation. Obtain a single valid Win2K license and you could technically activate an infinite number of systems.

Will be hanging on to my Vue for a long time...

So far, the rise of locked mobile devices is not preventing the sale or use of computing devices which are not restricted in such a way. And at least on Android, even "locked" devices still allow you to install third-party apps, like Firefox, which can be used to block ads.

Locking down all possible systems that can be purchased by consumers and enterprises (including modems/routers, desktops, laptops, etc.) with NO way to purchase, anywhere, a compatible, functional system that can have arbitrary software code executed on it, is a very tall order. If such a system is ever even threatened to be put into place, there will be a social rebellion the likes of which will make the American Revolutionary War look like a playground arm wrestle.

However, to attempt to prevent systems like this from being placed into effect gradually and slowly over time, I believe we should do all we can to reject systems of this nature, and continue to use, promote and purchase open platforms. Even (desktop) Windows, proprietary as it is, is -- relatively speaking -- very "open" compared to the locked-down environment you speak of. By refusing to economically support walled gardens, we can prevent them from gaining a foothold, or worse, becoming such a "de facto" standard that the majority of the web stops supporting open platforms.

I definitely see the danger, but I am optimistic that people will care enough that they will fight it. As usual, with matters like these, technologists such as the ones who often visit /. should be expected to lead the charge. Join the EFF and throw away your iPhones, folks.