Hacker News Reader

Comment by xyst | Hacker News Reader

very interesting project, but one of the downstream dependencies used here is insecure by default:

https://github.com/biemster/FindMy/blob/113ebf4017729b92a381...

Seems to be auth lib for iCloud.

Also seems to hard code a MacBook device agent in order to associate the generated keys with a device.

As with anything in the centralized world, I wouldn’t use this on an account with a high number of services/digital assets tied to it. I wouldn’t be surprised if Apple bans accounts that use this.

Wouldn’t be difficult to find out either given the unique “adsid” code that is required to login.

View on HN

> Also seems to hard code a MacBook device agent in order to associate the generated keys with a device.

Hold short, so you don't need an iOS device technically to onboard AirTags, any Apple device is sufficient? Why in the name of everything that is holy does Apple not support this officially, just to push sales for iOS devices or what?

(Angry rant of someone who bought an extra used iPhone despite owning like 5k in Apple desktop/mobile gear, just to be able to onboard some AirTags)

> why in the name of everything that is holy does Apple not support this officially, just to push sales for iOS devices or what?

You answered your own question ;).

My best guess (assuming it wasn’t malice/greed): not many people have access to an NFC/RFID reader and it’s Apple. So it has to be soft locked somehow behind the Apple Wall. So, in order to provide that “just works” experience. It’s better to advertise iPhone method as a way to get the tags registered.

Other methods exist, but your mileage varies. Also, Apple may change the APIs at any time and break that process. Thus, no support provided.

I think Apple just doesn't think about use cases outside their ecosystem as a general rule, in the same way that SF engineers don't think about uses outside the Bay. It's not malicious when things stop breaking because they lose mobile connectivity, or when your rideshare app demands you wait outside in the middle of winter in Minnesota, these issues just aren't thought of as an organization.

> I think Apple just doesn't think about use cases outside their ecosystem as a general rule

No. They deliberately do this for gatekeeping. That's what I'd expect from a company forcing you to own a Mac in order to develop for iOS, by license terms.

If it's just technical issues Apple usually do have more helpful alternatives, for example you can only request password reset for your Apple ID on an Apple device (because they can throttle and potentially ban a threat actor trying to stuffing, I guess?), but they invite you to go to an Apple Store and use iPad in the store to do it if you happen to not have one.

duh, its localhost:

https://github.com/biemster/FindMy/blob/113ebf4017729b92a381...

The auth lib for iCloud is inherently insecure, for you, and obviously not for Apple, Inc. I would fork this project into two separate products, which is abhorrent to do, but it must be done.

I would never consciously integrate a library from a third party. I am in the middle of scanning every single release of 'VenToy' into virus scanners, awaiting for the moment when an NZ-type vulnerability proves true.

Its not that Apples payment stream depends on this, its their subscription model.

Beware of offering a feature free that Apple thinks is interesting, they will lock you out, and start charging people for it.

Doubly beware of p*ssing off geeks, the will go to bed on Friday, in an angry state, and fervently work all weekend both to black box your product, but to trivialize the implementation of it. Now those are the really scary people.

Reply on news.ycombinator.com