zimmie

MacPro said:

I can't see what Apple could do?  If they improved the sensitivity wouldn't that just make measurements better for light skins too, thus maintaining the differential?  It's physics not bias. 

Not necessarily. All pulse oximeters use a measurement correction curve to convert from the amount of reflected light to an oxygenation percentage. That curve needs to change based on skin tone and possibly other characteristics we don’t even know about today (since only recently did a million people start carrying an oximeter around with them everywhere). Correcting the curve for darker skin would make readings for lighter skin less accurate, so it would need to be adjustable.

genovelle said:

zimmie said:

bloggerblog said:

I haven't read the iMessage API documentation, but if it can be done 'legally' then Google would've jumped on that bandwagon ages ago. I'm skeptical

There is no iMessage API documentation, primarily because there is no iMessage API (at least not for writing iMessage clients). They probably reverse-engineered iMessage's traffic flow and found a way to write their own client. It wouldn't be hugely difficult. The techniques to do this (and to keep it legal) are very well understood. They're time-consuming, though, and the result could be fragile.

I doubt Apple could target this client and ban anybody using it. I also don't see them going out of their way to break it, but if a change eventually does break it, Apple definitely won't care.

Considering the keys to Apple’s iMessage encryption lives on the device in the Secure Enclave I’m curious how this would work. Unless it intercepts text messages that have too much data and makes them more accessible and iMessage like. 

iMessage clients just hand the servers a public key. The servers don't have any way to know where the device actually stores that key. In fact, iMessage predates the Secure Enclave. A reverse-engineered client just needs to create a suitable key pair and stick the public key in the enrollment request when the user signs in. As long as it makes the same requests as Messages on an iPhone, and as long as it handles the responses the same way, the servers have no way to tell it isn't really Messages on an iPhone.

It's functionally the Turing test, except the interrogator trying to differentiate between the computer and the person is a computer, and it only speaks the iMessage protocol. As long as the other two parties to the test speak the iMessage protocol equally well, the interrogator won't be able to tell the difference.

InspiredCode said:

bloggerblog said:

I haven't read the iMessage API documentation, but if it can be done 'legally' then Google would've jumped on that bandwagon ages ago. I'm skeptical

There is no documentation or SDK for Apple Messages. It is probably not legal or it won't be in the future. All Apple needs to do is forbid it in their Apple ID user agreement. An open source non-commercial program could probably get away with it, but a commercial entity would probably need to get Apple's permission. 

There is only an SDK for iOS apps to embed inside of a messages chat through an extension API. That obviously wouldn't be supported by any third party chat system since it would require the full iOS operating system.

Reverse engineering for interoperability is specifically protected by every copyright system I'm familiar with. It's definitely protected in the USA.

bloggerblog said:

zimmie said:

bloggerblog said:

I haven't read the iMessage API documentation, but if it can be done 'legally' then Google would've jumped on that bandwagon ages ago. I'm skeptical

There is no iMessage API documentation, primarily because there is no iMessage API (at least not for writing iMessage clients). They probably reverse-engineered iMessage's traffic flow and found a way to write their own client. It wouldn't be hugely difficult. The techniques to do this (and to keep it legal) are very well understood. They're time-consuming, though, and the result could be fragile.

I doubt Apple could target this client and ban anybody using it. I also don't see them going out of their way to break it, but if a change eventually does break it, Apple definitely won't care.

InspiredCode said:

bloggerblog said:

I haven't read the iMessage API documentation, but if it can be done 'legally' then Google would've jumped on that bandwagon ages ago. I'm skeptical

There is no documentation or SDK for Apple Messages. It is probably not legal or it won't be in the future. All Apple needs to do is forbid it in their Apple ID user agreement. An open source non-commercial program could probably get away with it, but a commercial entity would probably need to get Apple's permission. 

There is only an SDK for iOS apps to embed inside of a messages chat through an extension API. That obviously wouldn't be supported by any third party chat system since it would require the full iOS operating system.

https://developer.apple.com/documentation/messages

That's to interact with the application Messages on an iPhone, iPad, or Mac. It has absolutely nothing to do with iMessage the protocol.

bloggerblog said:

I haven't read the iMessage API documentation, but if it can be done 'legally' then Google would've jumped on that bandwagon ages ago. I'm skeptical

There is no iMessage API documentation, primarily because there is no iMessage API (at least not for writing iMessage clients). They probably reverse-engineered iMessage's traffic flow and found a way to write their own client. It wouldn't be hugely difficult. The techniques to do this (and to keep it legal) are very well understood. They're time-consuming, though, and the result could be fragile.

I doubt Apple could target this client and ban anybody using it. I also don't see them going out of their way to break it, but if a change eventually does break it, Apple definitely won't care.

tommikele said:

Interesting, in three articles I just found, Lufthansa denies they have banned AirTags despite what that tweet says.

Lufthansa's actual statement is paraphrased as "We aren't banning AirTags. ICAO is banning them, and we're just adhering to their directions." German companies and processes tend to be extremely bureaucratic, and statements like this are a natural result.

All the re-reporting on the statement has focused on the first part and left out the second.

crowley said:

The article didn't mention it, but the costs are:

25 compute hours/month 
Free (through December 2023, then US$14.99 per month if you choose to subscribe at that time.)

100 compute hours/month
US$49.99/month 

250 compute hours/month
US$99.99/month 

1000 compute hours/month 
US$399.99/month

From: https://developer.apple.com/xcode-cloud/

I'm not sure why this is particularly useful unless it is substantially faster than on a local machine, and Apple don't seem to be making any claims about that.

It's not so much that it's faster, though it is. It's more that it lets you run your tests somewhere else without tying up your local machine for 20+ minutes. It's faster because it can run many tests in parallel. An M1 MacBook Air, for example, doesn't really have the RAM to run tests in an iPhone simulator and iPad simulator and Watch simulator all at the same time, so you have to run them serially.

blastdoor said:

tht said:

blastdoor said:

How does the work completed in a “compute hour” compare to, say, an hour of M1?

It would depend on the CPUs Xcode cloud is using, which could just be servers services from Amazon, Google or Microsoft. Could be Xeons, could racks of Mac mini's, could be Epyc. Maybe they are buying from MacStadium or set it up with their own hardware. Hopefully someone will spill the beans.

25 hrs goes buy really really fast. It's basically a number to try out the service.

Yup -- it could be almost anything, which is why I asked. 

Sounds like nobody here knows, either. 

Right now, Xcode Cloud VMs are amd64. The hardware identifier of the VMs is MacVM1,1. Each VM has four cores, 16 GB of RAM, and a framebuffer connected to a virtual 1080p display. It isn't yet known which specific processors are used, but it's likely to be Xeon Ws in rackmount Mac Pros.