I think the key message here is that knowing when to use a given technology (e.g: Kubernetes) is good - but it's more important to recognize when not to use it.
Don't get me wrong, I love Kubernetes, but I agree w/ Kelsey here - if you're running Kuberenetes on top of an orchestrated hypervisor and not using it to the fullest, you're just losing on performance.
Yes, with a strong emphasis on the proprietary part. Apple and Google both have their own networks.
All the Apple devices (and now, rolling out, all the Google Play Services enabled devices) scan for nearby Bluetooth LE beacons (that use their protocol) and upload (with some cryptographic operation) the location of the device who found the beacon, together with the accuracy (signal strength) to a proprietary server (Google or Apple).
Then, with the respective apps, the key holder can retrieve the reports for a given key hash and decrypt them to get the previous location.
Technically speaking, anyone with the key hash can fetch the encrypted location reports from Apple / Google servers, but they can't decrypt them.
On top of that, the key is rotating every 15 minutes (AirTag in paired mode) and there is no way to know that two keys are connected... unless you own the main key that is used to derive the rolling keys (see "update" and "diversify" in the linked paper).
Now, all of this is fantastic, until you think of this as a monopoly. Apple and Google get an interesting tax on every device that gets built and joins this network (IIRC it's 4$ for partner devices in the Apple network).
My problem with this is that no-one else other than Google and Apple can build an "open" network - you'd have to find a way to push your code to everyone's devices.
I'm surprised no-one is investigating this unfair practice.
> My problem with this is that no-one else other than Google and Apple can build an "open" network - you'd have to find a way to push your code to everyone's devices.
If you want a non-Apple, non-Google solution, you go to the OG tracker tag -- Tile. You have to install their app, so the reach won't be nearly as extensive, but that is fine by me -- the last thing I want is a third party developer able to push code to my device without me explicitly installing it.
Yes - but my point for that wasn't about allowing anyone to push anything on random devices. It was about the market penetration of those two companies.
Tile, as you mentioned, will never get any reach since users have to opt-in to start contributing to the location data, making their network incredibly smaller compared to Apple's or Google's own networks.
If you're Tile - you have no way to start such a network because you'd have to convince every single iPhone user (or Android user) to install your app, while Google / Apple can just do it with the push of a button (kind of!)
My point was about starting your own network with a similar coverage - it's nearly impossible. Thus competing with Apple or Google here is extremely difficult.
A protocol that allows the beacon to define which endpoint is used to forward the encrypted location data.
Alternatively (since the adv data is limited), a "routing" endpoint that allows custom endpoints to be defined depending on the network ID.
There are plenty of possible implementations that would allow for a fair market in this regard, but I don't think Apple or Google would ever introduce them, unless forced to
If anything this honestly looks like a great ad for this feature.
I think this shouldn't be newsworthy - the tool is just doing what you asked. It's the same as complaining with $pencil_producer that their pencils allowed you to draw disturbing images.
I think it would be more "newsworthy" if it would produce racist outcomes (e.g: asking it to draw a criminal and the tool produces always the same minority / output), but we're also probably past that - we've already seen those news articles.
+1, it’s great PR for the product. I don’t understand what the editors/writers intended with this article, it feels like something out of the onion. Are they intentionally giving good PR that’s worded as if it’s criticism?
> But if it's a mesh, how do you know whether the transmitter generated the message or it is just relying it?
I didn't check the protocol in detail so I don't know for sure, but I assume it's possibly impossible to know if you observe a single message. But if relayed messages are retransmitted immediately you can probably figure it out if there's not too much traffic.
