Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Get HideMyAss! VPN, PC Mag's Top 10 VPNs of 2016 for 55% off for a Limited Time ×

Comment Re:Google's reasoning makes no sense. (Score 1) 170

Anyone from Europe who goes to www.google.com will be redirected to their own site like www.google.fr and be given search results that comply with the local laws.

Now why should that same law apply to someone who gets redirected to www.google.com.au?

To play the devil's advocate:

A child walks into a bar somewhere in the U.S.A. The bartender refuses to sell her alcohol, because she's clearly underage. The child walks to the other end of the bar, which has an Australian flag and promotes Fosters. The bartender there is happy to serve her, because clearly she's no longer subject to the local laws? The kid is still in the same country. Everybody knows it, nobody is fooled because she's standing under a different flag.

So it is with internet traffic, unless you're going through a VPN or similar. Something so trivial as accessing the site through a different domain name should not be considered sufficient grounds to excuse ignoring the local law.

If the user was actually located in Australia at the time, fair enough. But that doesn't appear to be what's going on here.

Comment Re:Michael Jace was several years ago. (Score 1) 47

Are you saying Apple's programmers are now able to create a computer program as complex as an operating system with no bugs and no flaws whatsoever?

This is a good point in general, however the kind of security we're talking about here is restricted to the "login screen", not the general purpose OS. That's a much smaller attack surface. Once you've logged in, and are running third-party code on the device, you're much more likely to be able to break something.

It's reasonable to say that GP's claim of them "getting reasonably close to having an airtight phone, assuming you have it locked" is accurate. There will always be workarounds (decapping the chips, forcing the owner to reveal the passcode, etc.) but short of a screw-up on Apple's side, the practical options for bypassing the lock screen via a hack are getting more and more limited.

Comment Re:To bad the screens burn in... (Score 1) 157

LCD panels don't age in a way that makes the colors change, so they don't get burn in (the closest thing they get to burn in is image persistence, which is only temporary.)

I keep hearing this repeated, but it isn't really accurate. We have some iPad 2 devices which were used with their screen permanently active for a few weeks, frequently showing the same image. They're still burned in with the same image several years later, despite us changing the usage pattern to avoid displaying a static image.

Comment Re:my-pntbtr-add(list_eria) (Score 2) 118

I'd disagree, for the most part-

* Consumers are asking for something like this. Not everywhere, and often because they know it's generally not up to them, but platform lock-in is a pain for many people. "I have to buy a PS4 for this game." "This product isn't going to support Mac." "Only on iOS." "Requires Flash."

* Devs are definitely asking for something like this. "Can we afford to port to platform X? Can we afford not to?"

How things are now, we're talking about a lowest-common-denominator problem, so only a small subset of problems are solved. Hopefully this will improve over time, until the majority of problems are solved and only edge-case problems require specific platforms.

Comment Re:Mixed backend languages is recipe for subtle bu (Score 2) 255

From up-close-and-personal experience with Objective C and C++ (also Smalltalk), these languages have substantially different semantics regarding class identity (primarily: what version of overridden member functions you get) during construction and destruction. I wouldn't be surprised if Objectivce-C++ had yet another semantics, pulling "features" from both, and I have no clue about LVMM.)

Objective-C++ mixes the syntax of the two languages, and allows you to use either a C++ object or an Objective-C object at will, however it does not make C++ objects into Objective-C objects or vice versa. Any semantics relating to C++ objects still applies to C++ objects, and no additional semantics are implied.

In short: things work as you'd expect, and there are no hidden gotchas.

The only real complexities are what happens when you embed a C++ object as a member inside an Objective-C object (this doesn't change the semantics of the C++ object itself, but obviously may change the point at which the whole thing is destroyed) and what happens when you reference an Objective-C object from within a C++ object (some of the automatic refcounting syntactic sugar goes away and you have to actually understand what you're doing.) These don't introduce difficulties for the compiler, but could potentially be confusing for the programmer.

I'm sure clang has its fair share of bugs, and I'm sure that GCC does also, that's just the nature of any complex codebase. The shared backend isn't really a contributing factor, any more so than them both emitting x86 machine code is a contributing factor.

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

Anecdote:

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.

Slashdot Top Deals

Never trust a computer you can't repair yourself.

Working...