HackerTrans
TopNewTrendsCommentsPastAskShowJobs

dkoston

no profile record

comments

dkoston
·há 7 anos·discuss
If the gateway used to receive these requests cannot decrypt them and they pass through other connections before decryption, why wouldn’t this be possible? At the point of decryption you’d have the connecting IP of the last hop but if the origin IP isn’t forwarded, and there’s no request correlation ID or other identifying information, the machine processing the request wouldn’t know where the original request came from.

Of course any of the intermediate machines could be tracking this data for correlation purposes but it should be possible to strip it along the way.

If the request data containing the 424242 is encrypted and only the machine without origin info has access to that identifier, how would you know the request is for 424242?
dkoston
·há 7 anos·discuss
They aren’t using your social graph, they are using location proximity and transmitting the data inside existing packets sent to cell towers for connectivity purposes. There’s already a ton of information passing to cell towers to identify and negotiate connections with phones that could be used to infer your social graph. You’d have to correlate that with a geo location database that knows about what type of locations you visit as there would be tremendous amounts of false signals at public places like restaurants and malls.

Long story short, Apple, cell tower operators, and mobile providers already have all the data they’d need to make these graphs. If this functions as designed, it will contain much less information and wouldn’t be useful for this purpose (I.e. encrypt requests and don’t pass IP info with them to any systems that have the ability to decrypt them. If you make a few hops to the systems which have the ability to decrypt them and don’t share correlation IDs or the origin IP, there’s no way to correlate these requests back to which device sent them or what IP or cell tower it had).