Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Slashdot Deals: Deal of the Day - 6 month subscription of Pandora One at 46% off. ×

Comment Re: Swarm, not sphere. (Score 1) 339

This problem is what inspired Larry Niven to publish his idea for a "ring world" - a more practical, lower tech approach.

Larry Niven got this right in the later books, but only because a lot of his fans called him out on it.

Halo installations don't actually ring a star, so don't have this problem.

Comment Re:Can anyone explain in actual meaningful terms? (Score 2) 143


My previous phone was 16GB. I was coming up against the limits of that device and wanted to upgrade for my next purchase.

I bought my current phone when it was newly released. My carrier had messed up my preorder and I was in a hurry, so I walked into an Apple Store with the intent to purchase. I didn't want the 16GB. I would have been happy with 32GB but of course they don't make them. They didn't have a 64GB in stock of the model I wanted. I walked out with a 128GB.

That's at least one person where the existence (and/or availability) of a 32GB model would have affected 128GB sales.

Comment Re:And that's why you don't trust apps initially (Score 1) 246

None of it is trivial given the moving target that is Xcode, and all the possible ways an app might be developed and Xcode project settings changed, not to mention the mixture of Swift and ObjC...

Remember that in the course of an application development it's likely there will be at least one Xcode update, which you also have to infect in the same way before they download it...

Yeah, that's exactly what I mean. That's somewhat hard, and yet they've still succeeded. I guess there are enough people using this approach that some were stung, even though others were not for the very reasons you state.

Do they really need one beyond "download Xcode updates from Apple"?

Apparently so? :)

Will be interesting to see if this problem recurs, either directly or in some secondary manner (eg. an exploit for the dev machine which modifies Xcode and disables gatekeeper, or whatever.)

Comment Re:And that's why you don't trust apps initially (Score 1) 246

I would have said that getting Xcode exploited in the wild was the tricky bit. Most of the rest of it seems pretty trivial.

Attacking the API server is certainly an option, but you'd need a separate exploit for that, plus you're working in an area where an exploit attempt is expected and hopefully being monitored for. So far, this kind of attack has been pretty much under the radar, at least on iOS. Maybe that will change now.

Apple can obviously check for the signature of this specific exploit easily enough, but it will be interesting to see whether they have a quick answer to the general problem.

Comment Re:And that's why you don't trust apps initially (Score 1) 246

This kind of possible attack is mitigated because after you download an app, it still has no permissions to do anything interesting - access to background location, contacts, camera, audio, etc. all require permissions that prompt the user for access.

So even if someone uses an Xcode that is compromised, there's not very much gain you are going to get by having malicious code in the app except for what that app is working with.

Unless they can trick the user into giving up their iTunes account details by showing a system-prompt-lookalike. The system already prompts for passwords at some pretty random times, so that might not be hard.

Or they could customise the exploit behaviour depending on the host application. Wait until some relevant app has been successfully exploited and is reporting in, then tailor an approach to steal whatever app-specific data is relevant (login details, etc) or even override the app's networking classes and MITM the outgoing connections.

On a side note, I would think it would be hard for an attack like this to succeed because as a developer builds an app, they are often monitoring network traffic or otherwise examining app activity... even in release mode at times.

Even if this were true (I don't really agree that it is, although I do agree that somebody will spot it sooner or later) then it would be easy enough to work around. Just have the exploit not phone home until after a certain fixed date, or a certain amount of time after the app was built, or not while a debugger is attached, or etc. In fact, since you've compromised the Xcode tools, just hide any reporting of your exploit's activity.

Just because you can't necessarily gain control over the whole device this way (it's one step towards that, but you'd need a secondary exploit) doesn't mean that it isn't a problem.

Comment Re:Keyboard (Score 1) 216

Fairly average (for a male) hand span, and slim fingers/thumbs. The iPhone keyboard simply isn't built for precise key hits. There are lots of smarts to allow you to type reasonably well regardless, but this assumes that you're typing normal English sentences (and statistically common phrases) and the more you vary from that pattern, the more likely it is to take your typing and produce something garbled or (worse) exactly negate your meaning. I eventually found that retyping any actual mistakes was less frustrating than retyping something that was entered correctly but that the iPhone "corrected" to something else.

Your comment about supporting dozens of languages is way off; the keyboard only supports a single language at a time, and you need to explicitly swap languages (which also swaps the dictionary / auto-correct mechanism.)

Comment Re:Keyboard (Score 1) 216

For me, it's crappy because the autocorrect commonly changes what I intend into something that I don't intend. After several years, I gave up and turned off autocorrect, which is a partial solution- but the keyboard was really built with autocorrect in mind, and is below mediocre with autocorrect disabled.

I can't comment on the Android keyboards.

Comment Re:accurate, thorough reporting? (Score 1) 152

For example you can read the "android user on an iPhone 5S" article, and he lists all those important limitations of iOS that would definitely turn any Android user away, but says they are "temporary" and inexplicably concludes that iOS is not a worse experience.

"Temporary" because we already know that these are resolved in iOS 8 which is currently in beta. So, yes, you could rightly claim that iOS lacks these features currently- but that would make for an article with a used-by date of a few weeks or months. Like it or loathe it, it's clear that Apple is happy to steal and put their own spin on the major "distinguishing features" from Android-land.

"A worse experience" and "would definitely turn any Android user away" are rather personal judgements. iOS does some things a lot better, and clearly does some things a lot worse. Just because the author's value judgement differs from your own doesn't make him a shill.

Similarly, supposedly they would test all important smartphone releases, however they review each iphone multiple times (seriously, check it out), then some popular Androids and that's it.

This is quite true, and does speak to some bias- at least as far as what the author has a personal interest in, not necessarily a bias in the facts of the article. To be fair, quite a few of these articles were about the chip architecture, which was a rather big deviation from the run-of-the-mill hardware at the time. It was interesting from a technical perspective, regardless of where you sit on the OS fence.

Comment Re:People expecting their marketing for free (Score 1) 258

Huh? There are tons of apps with a free version and a paid version and/or paid upgrade. That's a demo / trial.

Not exactly. Apple doesn't allow actual demos, they're pretty explicit about this. "Lite" apps are the workaround and they tend to offer reduced functionality but are free- this can serve as a demo if it's easy to divide your app into "the intro stuff" and "the longer term stuff", for example by giving away the first few levels of a game- but cannot serve as a demo if your app doesn't have this distinction.

For example, I'm pretty sure that Apple will not permit a 30-day free trial, nor do they permit you to have functionality which is "disabled in this demo version." You can get around this to some extent with in-app purchases, but that's not quite the same as a demo.

At best, it's a very different way of monetising your software, and a way that some developers may not like. At worst, GP is right and it could compromise your ability to effectively market your app.

Use the Force, Luke.