[guardian-dev] forcing HTTPS when using goo.gl shortlinks
Jonas Smedegaard
dr at jones.dk
Fri Jan 9 16:42:45 EST 2015
Hi HC,
Quoting Hans-Christoph Steiner (2015-01-09 20:18:23)
> Jonas Smedegaard:
>> Quoting Hans-Christoph Steiner (2015-01-09 16:01:55)
>>> I'm digging through the guts of how apps are sharing location
>>> information. For the most part, its not a great situation, but there
>>> is a lot of hope with the geo: URI (http://geouri.org). Anyway,
>>> lots of Google apps share location using a http://goo.gl shortlink
>>> (e.g. http://goo.gl/maps/V9dIV), which is even worse for a number of
>>> reasons:
>>>
>>> * it uses http: to connect to goo.gl
>>>
>>> * the link that the goo.gl redirects to is also http://, so even if
>>> you do https://goo.gl/maps/V9dIV, then the next step is http://.
>>>
>>> * the link that goo.gl redirects do obfuscates the latlong, so it
>>> can't be parsed out of it by other apps, even though the final link
>>> when you get to the page includes the latlong (very lame, Google).
>>
>> I wouldn't call it lame but a deliberate design to not expose
>> semantics (gold to them) but replace that with tracking URLs (more
>> gold to them).
>>
>>
>>> Any ideas on how an app can get the latlong securely? One simple
>>> way to improve this situation would be to pass something in the
>>> query string to https://goo.gl/maps/V9dIV to make it only use HTTPS.
>>> Anyone know if anything like that exists? Or is that ftid thing
>>> parseable?
>>>
>>> Otherwise, I think an app will have to actually connect to
>>> https://goo.gl/maps/V9dIV, then get the redirect URL and convert it
>>> to HTTPS.
>>
>> I expect it is by design not possible to resolve the underlying
>> geodata securely. If my suspicion is correct, then I guess the only
>> possibility is if someone hosts a proxy to expand those tracking URLs
>> on behalf of privacy-concerned users (who then would need to trust
>> that proxy to not log anything).
>
> I think you're a bit more paranoid than warranted ;-). Google doesn't
> need to make special URLs to track people, they track everything that
> hits their servers. But it does look like they are trying to prevent
> people from parsing the location out of their shared URLs.
For the record, my remark here was not about paranoia, but business
logic: I do not expect Google to implement redirection schemes with an
aim of _monitoring_ but to conduct their core business: harvest¹
statistics for use in analyzing and selling knowledge on behavoural
patterns on the internet.
Yes, they do need to serve obfuscated extra-roundtrip URLs if they want
to avoid URLs being cached - i.e. if they want most possible uses of a
URL to be registered by them.
Do you think they are simply sloppy in their systems design, or...?
> As for using HTTPS, it is fully possible to force the whole thing over
> HTTPS, you just have to do it manually. And if you use Chrome, then
> it would be automatically forced to HTTPS anyway.
Right - if your concern here is not tracking URLs but 3rd party
monitoring of necessary roundtrips to Google to resolve those obfuscated
geodata URLs, then you are right, custom s/\bhttp:/https:/ is possible.
> The upside is that Google has done a good job making geo: URIs
> standard in Android. All the map apps accept them, and they are part
> of their developer documentation.
And Bill Gates sponsors money to developing countries. I don't see the
how appraisal of Google's involvement in inventing the geo: protocol is
any relevant for discussing cases where they do not embrace that very
same standard.
- Jonas
¹ When Google argue that metadata is not as harmful to harvest as data,
I can follow their logic - even if I disagree that metadata harvesting
is outright harmless.
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: signature
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20150109/55fc85f2/attachment.sig>
More information about the Guardian-dev
mailing list