[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