Actually this tablet is expected to be officially announced -and available- within weeks.

Interesting, that. I've heard a lot of people make similar claims, but the three units I have myself (development purposes) work fine. However, some guys I work with recently started using the N7 2013 as base for a university automation project, and have gotten hundreds of them. Apparently, dozens of their units were dead on arrival, and of those that work out-of-the-box a significant number of them randomly just die. Less than a year after the start of the project, near to a third of the units is dead.

I had also expected the N7 to stay available alongside the N9, but according to these same guys it is very difficult to still get units in significant amounts. Shops are starting to delist them, which to me indicates that they are end-of-life and the soon to be released N9 will replace the N7, rather than augment it. I sincerely hope I am wrong here.

... for quite some time now. WSJ posting it doesn't suddenly make it news.

PNO is implemented in the Wi-Fi firmware, and generally only active if the main device CPU is asleep.

wpa_supplicant tells the Wi-Fi firmware which networks it is interested in, then when the main CPU sleeps, the Wi-Fi chip keeps scanning for those networks periodically, which takes less power than waking the main CPU periodically to do this. In PNO's scanning process, it broadcasts all the names. There's no technical reason this is needed aside from hidden SSIDs (and indeed non-PNO wpa_supplicant scans don't do this either). The PNO feature however doesn't make that distinction and broadcasts all the names instead of the hidden ones. From the sources I've read, it seems there's no way to tell the firmware to make a distinction between active (for hidden) and passive (for non-hidden) SSIDs.

So yes, in effect, anything based on wpa_supplicant and PNO may do this. However, this is not wpa_supplicant's fault per se, rather PNO's. I don't think my laptop bothers scanning for Wi-Fi networks when it's sleeping at all, or even supports PNO, but your mileage may vary on that. There's no rule saying PNO can only be used when the main CPU is asleep either, though that is what's built for. Your software could be using it all the time (unlikely, but possible).

Irrelevant - the issue on Android is not limited to hidden networks.

Unfortunately, that just isn't true. The affected Android devices leak all known networks, not just the manually configured ones. Go ahead and test it.

Good job intentionally not seeing the point just to be able to make a trollish/sarcastic remark. You must do great at parties.

Of course. I'm not even advocating the need for change - I'm just trying to point out that cameras like these not being very secure appears to be the rule, not the exception, though not everyone appears to be aware of this. I could see an article like this leading to talk that you shouldn't buy Samsung because it isn't secure, advising other brands instead - but those aren't necessarily any better.

While this camera should of course be more secure - what exactly are we comparing it to ?

Do you think your Canons and Nikons are safe? Lots of models allow remote control using either USB or Wi-Fi. USB requires a cable from your smartphone running the malicious software, while Wi-Fi obviously does not. For Wi-Fi you need to get past the encryption, but the joke is, lots of people actually run their camera's Wi-Fi without encryption (surprisingly, some photo blogs advise it for ease of use). You're still not home free though as there's a pairing process when Wi-Fi is used, but if the camera owner's smartphone is active on Wi-Fi (not necessarily even the same network - just turned on), this is not hard to beat either.

If you can get connected to these cameras either via USB (completely unprotected) or Wi-Fi, it is not just possible to manipulate, retrieve, replace, wipe, etc all images present, you can fully control the camera's settings and even send malformed commands to completely disable the camera, only to be (potentially - it depends on the model) revived by a Canon/Nikon repair center. This while most users think the worst that can happen is someone copying their pictures ...

You think the NX300 is bad? Consider that pretty much nobody owns an NX300, while virtually all photojournalists active in countries with questionable rights to free speech have one of these affected Canons and Nikons ...

As usual with a Slashdot article title ending with a question mark, the answer is no?

These are not the same class of vehicle. Around these parts there are quite a number of Tesla Model S's - in fact I would have gotten one myself if it had been possible to get it delivered before January 1 (long story, tax breaks) - and all the owners I know of are small to medium business owners with money to spare. Had they not gone for the Model S, they would have gotten one of the bigger models Audi, BMW, or Mercedes - electric or not. I can't see a single one of these folks getting a Leaf instead, not even at half the price.

Then again, maybe the target demographic for the Model S is different on your side of the pond ...

Did you actually test this ?

Immediately after reading the summary, I suspected this would just use "getLastKnownLocation" and correlate that with the foreground app. From searching through TFA, that is indeed the case. Technically, not very interesting at all.

I have a few years old Samsung TV and it plays near anything over DLNA (stream over TCP/IP from your PC), though you have to do some searching to find the right DLNA server and setup. Serviio works best for me. Buffering at movie start may be one or two seconds but certainly not more if you're on a wired (!) connection. Over Wi-Fi it's crap, of course.

Last year I connected Samsung Blu-Ray player which supported even more formats and worked even better (faster). Now, DLNA is about as shitty a protocol as possible (really, if you get down to the tech nitty gritty, "frackin' terrible" would be a compliment) so not everything always works and codec support has some limits, but some brands (including Samsung) support some non-standard stuff like additional codecs and even SRT subtitle support. Ultimately, I hacked my BR player with "SamyGO" which allows you to use network shares directly instead of DLNA which made it even better.

I've used laptops for this purpose and have even built HTPCs, but if you take a little care about what you download, by far most things will play on a DLNA setup on modern TVs and BR players (support differs per brand). My PC is usually turned on in my office room, I download my shows and movies (usually x264 720p or 1080p in mkv format with optional srt) and play them back in the living room without any additional gadgets at all.

Then again, maybe none of your TV room playback devices support DLNA or your computer isn't always-on, both will ruin this setup :)

I'm not sure if this is still true, but I do know that last week the Play store was still using HTTP downloads for the actual APK files instead of HTTPS (even though the API calls do use HTTPS). As such, even downloads from Play may be susceptible to man-in-the-middle attacks. I can't possibly explain it better than this group of comments:

http://it.slashdot.org/comments.pl?sid=3950207&cid=44220885

I'm not saying it's likely - but it doesn't seem impossible either. Seeing as it will be a long time before the average Android user will be running a phone with this patch, I would call "crisis averted" too soon. Of course, we don't know if the complete HTTP download is still verified with checksum gotten from the HTTPS API, but somethow I doubt it.