Alerting you to login attempts from new locations or devices, and offer two-factor authentication, will slow down the hackers for a time.

But the answer, for most service providers, is to tell the user that it's their problem now.

Consider yourself lucky, then - SMS spam seems to be pretty common here in the UK. Even my parents occasionally get hit.

I've been fortunate so far - I don't have any fellow iPhone users that I regularly communicate with via said device. I've now turned off iMessage, so hopefully all texts should go out as SMS.

My personal bugbear with my iPhone is the number of steps required to block a number from Messages. As I use my mobile number as a contact for business, my number is public, and as a result I've started getting SMS spam and telemarketer calls. You would think that Apple, of all people, would make it easier to tell the iPhone "block this number from calling me again."

But, but... That doesn't make any sense!
Using HTTP, the connection isn't encrypted in either direction. If they can see the original request, they can also see the original response, so why not just cache that?

It's an absolutely crazy implementation, I agree (particularly speaking as someone implementing something which analyzes HTTP downloads right now). It's not caching, but some sort content analysis; my guess, and it is only a guess, is that it's intended as a workaround to copyright. Genuine caching is OK, for cacheable content, but I don't think this use would be covered by that copyright exemption: by fetching their own copy from the server like a regular web spider, they're no longer "making a copy". The other possibility is bandwidth: being a major ISP, it might be easier to intercept only the requests in-line, then queue them up for spidering by a separate system; intercepting the downloaded content as well would mean forcing all traffic through the analysis system in realtime.

Mine just hashes and logs the objects as they get fetched. Of course, I'm doing it in the firewall, with the user's knowledge and consent. I just remembered, though, a friend who works for an anti-malware vendor company mentioned to me that their security proxy does the same bizarre duplication rather than scanning in transit, which IIRC screwed up music streaming services, so presumably there's a good reason for that. (Weird, because if I were shipping malware, I'd find that all too trivial to circumvent by serving different content to the client and the scanner.)

Conversely, I seem to find (in the UK at least) that cheaper ones and shops are more likely to have free WiFi, while pricier hotels and bigger chains seem to be more likely to charge for it. The poshest one I've spent any time in - part of the same chain as the Savoy in London - charges crazy prices (and has lousy mobile reception), though it's a rock-solid signal throughout the large building; a much cheaper hotel nearby just had a Wifi access point on ADSL somewhere, with no password, for anyone to use.

A question of attitude I suppose: a small hotel thinks £20 or so a month is a trivial investment to make guests happier, like having newspapers in reception; a bigger chain sees it as spending millions across the chain to roll out a service which should generate revenue.

Still, HTTPS would at least prevent your ISP from monitoring your browsing activity.

That's part of it - a valuable enough part in itself, IMO; at least one UK ISP, TalkTalk, has started duplicating HTTP requests made by their customers: so, if you request http://example.com/stuff on one of their lines, 30 seconds later they'll go and request the same URL themselves for monitoring purposes. Obviously, enabling SSL prevents this kind of gratuitous stupidity - and the previous incarnation of such snooping, Phorm. If enough websites enable SSL, ISPs will no longer have the ability to monitor customer behavior that closely, all they will see are SSL flows to and from IP addresses, and whatever DNS queries you make to their servers, if any. (Use encrypted connections to OpenDNS or similar, and your ISP will only ever see IP addresses and traffic volume - exactly as it should be IMO!)

So, I agree with you that simply predicting reverse/affirm at 70% accuracy may be easy, but predicting 68000 individual justice votes with similar accuracy might be a significantly greater challenge.

In fact, it looks like very much the same challenge: with most decisions being unanimous reversals, it seems only a small minority of those individual votes are votes to affirm the lower court decision. So, just as 'return "reverse";' is a 70+% accurate predictor of the overall court ruling in each case, the very same predictor will be somewhere around 70% accurate for each individual justice, for exactly the same reason. (For that matter, if I took a six-sided die and marked two sides "affirm" and the rest "reverse", I'd have a slightly less accurate predictor giving much less obvious predictions: it will correctly predict about two-thirds of the time, with incorrect predictions split between unexpected reversals and unexpected affirmations.)

This is the statistical problem with trying to measure/predict any unlikely (or indeed any very likely) event. I can build a "bomb detector" for screening airline luggage, for example, which is 99.99% accurate in real-world tests. How? Well, much less than 0.01% of actual airline luggage contains a bomb ... so a flashing green LED marked "no bomb present" will in fact be correct in almost every single case. It's also completely worthless, of course! (Sadly, at least two people have put exactly that business model into practice and made a considerable amount of money selling fake bomb detectors for use in places like Iraq - one of them got a seven year jail sentence for it last year in England.)

With blood transfusions, I understand there's now a two stage test used to screen for things like HIV. The first test is quick, easy, and quite often wrong: as I recall, most of the positive readings it gives turn out to be false positives. What matters, though, is that the negative results are very, very unlikely to be false negatives: you can be confident the blood is indeed clean. Then, you can use a more elaborate test to determine which of the few positives were correct - by eliminating the majority of samples, it's much easier to focus on the remainder. Much the way airport security should be done: quickly weed out the 90-99% of people/bags who definitely aren't a threat, then you have far more resources to focus on the much smaller number of possible threats.

Come to think of it, the very first CPU branch predictors used exactly this technique: they assumed that no conditional branch would ever be taken. Since most conditional branches aren't, that "prediction" was actually right most of the time. (The Pentium 4 is much more sophisticated, storing thousands of records about when branches are taken and not taken - hence "only" gets it wrong about one time in nine.)

Now, I'd like to think the predictor in question is more sophisticated than this - but to know that, we'd need a better statistical test than those quoted, which amount to "it's nearly as accurate as a static predictor based on no information about the case at all"! Did it predict the big controversial decisions more accurately than less significant ones, for example? (Unlikely, of course, otherwise they wouldn't have been so controversial.)

Usually, a terrestrial phone doesn't need to do anything much to "look" for a tower, besides keeping its receiver turned on. Towers emit beacons, and if you don't hear the beacon, there's no point in you sending anything - you won't receive a reply because you don't even hear the tower's beacon.

True - the problem AIUI is that "just" keeping the receiver turned on constantly consumes a significant amount of power in itself. Once synced with a tower, the phone can turn off the receiver, knowing that it has, say, 789ms until the next beacon it needs to check for; if it's waiting, it needs to be listening constantly. Worse, it doesn't know what frequency the tower might appear on - so until it finds one, it will be constantly sweeping all the different frequency bands a tower could be using, until it actually finds one - on a modern handset, cycling between at least three different modes (GSM, 3G and LTE), each on several different frequency bands. Also, because of the possibility of roaming, it may be hitting other networks then checking whether or not it can use those ("Hi network 4439, I'm from network 4494, can I connect? No? Kthxbye")

I can't imagine that absolutely none of the requests where verifiable facts. {like a mis-typed date}

That wouldn't come under "right to be forgotten" though, a simple edit or correction request would address that.

The whole notion of a "right" to prohibit someone else from making a factually accurate statement on one website about the content of another site seems utterly absurd to me. Removing the destination page itself could perhaps be excused in some cases ... but to accept that the owner of a page making a statement about somebody has a right to keep it, even if it's out of date, then turn round and gag the likes of Google from making current factual statements about that page? Every "judge" supporting that nonsense needs to be unemployed ASAP.

How is that any different than swinging a load around with a crane? People will just have to be careful and realize the suits can be dangerous if misused.

I think the dexterity is the key here. Yes, a crane can lift 10+ tonnes at the touch of a button/lever - once someone has attached the hook to the object. You can't just reach down and pick something up with a crane, except in very carefully controlled circumstances (like shipping containers lined up on a dockyard). Imagine a suit like this in rescue situations, though: lifting lots of chunks of rubble off trapped survivors, clearing blocked paths. A crane could lift the weight easily, but can't pick chunks of rubble up; a bulldozer or excavator could move it all, but would kill the people trapped underneath. Also, in those situations there is often a lot of dust etc around - and filter masks don't fit well with the physical exertion of lifting and moving heavy debris.

Also, like the previous comment says, I imagine they'll scale up to heavier weights and other features in future (adding power tools, for example).

I'd call cropping the image a trivial tweak. How you dealing with that?

That's a good point - unfortunately, it's not one that can easily be addressed algorithmically, because you stray into the much more abstract question of "what is porn?" (or, in this case, what is an "illegal image"). If I were to take a 1 megapixel illegal image and slice it into 100 tiles, how many of those tiles would themselves contain illegal imagery? Identifying a file as being the top-left corner of "known child abuse image #515345" isn't actually conclusive in itself, because that bit of picture may be innocuous in itself.

In the context of my work, I'd be logging that the offender in question had downloaded a 533k JPEG from a certain URL on dodgy-site.com, so the parole guys can skim through looking for anything suspicious: the domain name, or what search engine terms led to it, will probably be informative enough in itself. Hash matching is a quick and easy check to automate, but far from the only thing that will be checked: Facebook usage, for example ("Now, Mr Sex Offender, why exactly do you have a Facebook accounting claiming to be a 13 year old girl sending out friend requests...?") Fortunately, it's not a case of gathering proof for a prosecution, it's a much broader goal of assessing behaviour and compliance.

That means only the most incompetent pedos aren't already randomly tweaking their jpgs - the smart ones are doing it in the EXIF section so it won't even change the picture.

The smart implementations probably hash the image payload excluding EXIF, for exactly that reason - maybe downsample and reduce the colorspace too, so trivial tweaks won't have that effect any more.

(In fact, the implementation I'm working with right now for exactly this purpose - I have a small research project underway with the police in Scotland as part of their Offender Management work - just hashes HTTP payloads for the moment - although refining this is on the drawing board for later.)

I do find this very disturbing in principle though. Is absolutely everything in your mailbox entirely innocent? I have, for example, a list of various Microsoft product keys in mine. As it happens, those are legitimate - all issued to me by Microsoft via MSDN subscription, then I stuck them all in a spreadsheet to keep track of which key was in use for what - but would Google or the police know that just from looking at the list? They might turn up with a warrant looking for the piracy ring I'm obviously running, just because Google got nosy and went vigilante!

This isn't the first time, though; I recall a malware researcher getting rather upset after Google started eating samples from his Inbox - even when they were inside password-protected ZIP files. I can see that they mean well, but to me that crosses a line.

Since we're talking about desktop market shares here, Linux's number isn't that far off.

I wonder about that, actually: I'm quite sure Linux users are much more likely to be running the likes of NoScript and various ad-blockers than Windows users are - and anyone who blocks whatever analytics script this survey uses will be ignored completely, skewing figures away from their platform. Maybe it's not a large proportion, but I'm sure it will be a factor there.

The scary thing is that Vista actually gained users, and the interesting gap is how desktop versus mobile usage compares: how would IE/Chrome/Safari compare across all form factors look? (Bearing in mind that mobile users on the Chrome rendering engine are all on Linux kernels, probably dwarfing the Linux desktop users.)

But we are at Dice, sir:

[Querying whois.publicinterestregistry.net]
[whois.publicinterestregistry.net]
Domain Name:SLASHDOT.ORG
Domain ID: D2289308-LROR
Creation Date: 1997-10-05T04:00:00Z
Updated Date: 2014-03-14T22:12:11Z
Registry Expiry Date: 2015-10-04T04:00:00Z
Sponsoring Registrar:Tucows Inc. (R11-LROR)
Sponsoring Registrar IANA ID: 69
WHOIS Server:

Referral URL:
Domain Status: clientTransferProhibited
Domain Status: clientUpdateProhibited
Registrant ID:tuE8gFbzWFO9qSj2
Registrant Name:Host Master
Registrant Organization:Dice Holdings, Inc.
Registrant Street: 1040 Avenue of the Americas
Registrant City:New York
Registrant State/Province:NY
Registrant Postal Code:10018
Registrant Country:US
Registrant Phone:+1.8557527436
Registrant Phone Ext:
Registrant Fax:
Registrant Fax Ext:
Registrant Email:hostmaster@slashdotmedia.com

Pros: Today's article has more content than the usual Dice front page linkage. Great article if you're not a programmer but feel stymied by the wide assortment of languages out there. Although instead of hemming and hawing before making your first project you're better off listening to Winston Churchill and sticking your feet in the mud: "The maxim 'Nothing avails but perfection' may be spelt shorter -- 'Paralysis."

Cons: It barely scratches the surface of an incredibly deep topic with unlimited facets. And when one is considering investing potential technical debt into a technology, this probably wouldn't even suffice as an introduction let alone table of contents. Words spent on anecdotes ("In 2004, a coworker of mine referred to it as a 'toy language.'" like, lol no way bro!) could have been better spent on things like Lambdas in Java 8. Most interesting on the list is Erlang? Seems to be more of a random addition that could just as easily been Scala, Ruby, Groovy, Clojure, Dart -- whatever the cool hip thing it is we're playing with today but doesn't seem to quite pan out on a massive scale ...