Hacker News Reader

Comment by walthamstow | Hacker News Reader

The thing about Tesla having more cars on the road is obviously true, but Google Street View captures my house in London at a decent frequency, about twice a year, so those cars are driving around capturing data all the time in major cities.

I assume they're capturing more than just images, does anyone know for a fact?

View on HN

> I assume they're capturing more than just images, does anyone know for a fact?

I'm not sure what they're doing now, but I assume that they're fingerprinting everything by MAC addresses and SSIDs and other identifiers, but for their sake I hope they have stopped intercepting unencrypted wifi traffic, which is apparently a thing that was proven at court that Google Street View cars did do.

https://en.wikipedia.org/wiki/Joffe_v._Google,_Inc%2E

> Joffe v. Google, Inc. is a federal lawsuit between Ben Joffe and Google, Inc. Joffe claimed that Google broke one of the Wiretap Act segments when they intruded on the seemingly "public" wireless networks of private homes through their Street View application. Although Google tried to appeal their case multiple times, the courts favored Joffe's argument. Ultimately the Supreme Court declined to take the case, affirming the decision by the United States Court of Appeals for the Ninth Circuit that the Wiretap Act covers the interception of unencrypted Wi-Fi communications.

Scooped by ~2 min by users xnx and prepend, but I like to think my flavor text was worth the wait. I'm likely biased on that point.

Lidar was added in 2017 https://en.m.wikipedia.org/wiki/Google_Street_View#:~:text=L...

Thanks! I thought the 3D models in Google Maps were just Extremely Clever Math. Lidar and Extremely Clever Math makes more sense.

It's actually photogrammetry, not LiDAR (or at least, the LiDAR scans aren't done by Street View cars), which is why it's limited only to certain pre-scanned cities instead of everywhere with modern Street View.

They were sued, and lost, for capturing and analyzing data off all the WiFi networks they drove by. [0] I assume they are recording all the metadata and data that they can to stay compliant with this.

My guess is they have a list of every MAC address of every device they can find, geolocated. And then they match that to data from all those apps that ask to discover devices on my local network. Now they know how old my tv and lightbulbs are, etc etc

[0] https://en.wikipedia.org/wiki/Joffe_v._Google,_Inc.

> [0] https://en.wikipedia.org/wiki/Joffe_v._Google,_Inc.

Wikipedia urls ending in punctuation are unreliably broken or not depending on caching and the platform, so if you put a # on the end to escape it, it fixes it, without having to worry about percent encoding.

That's a very useful tip, thank you!

The problem here is that the HN URL encoding interpreted the period as the end-of-sentence rather than as part of the URL. It would be simply bizarre for any browser or web server to choke on a perfectly legal dot to end a URL.

Per the HN formatting documentation: https://news.ycombinator.com/formatdoc

<https://en.wikipedia.org/wiki/Joffe_v._Google,_Inc.>

https://en.wikipedia.org/wiki/Man_or_Astro-man%3F is another story -- since "?" is a reserved character in URLs for CGI queries. Enter the question mark anyway, and the article comes up! Why? There's a redirect without it!

For Wikipedia's gory details on technical restrictions for article titles: (note that HN properly parses this article title ending in a right-paren)

https://en.wikipedia.org/wiki/Wikipedia:Naming_conventions_(...

> The problem here is that the HN URL encoding interpreted the period as the end-of-sentence rather than as part of the URL.

That’s the first problem.

> It would be simply bizarre for any browser or web server to choke on a perfectly legal dot to end a URL.

I agree? I never said anything like this. My original comment was:

> Wikipedia urls ending in punctuation are unreliably broken or not depending on caching and the platform, so if you put a # on the end to escape it, it fixes it, without having to worry about percent encoding.

I mentioned the platform specifically, which in this context could be either the server context or client context. You mentioned server/client context, as in what HN serves the user or vice versa. I mentioned that and client context inclusively. If you’re correcting me, assume I need you to show my error.

> Enter the question mark anyway, and the article comes up! Why? There's a redirect without it!

That’s the second problem - the site in question as typed - there is no redirect from https://en.wikipedia.org/wiki/Joffe_v._Google,_Inc to the version of the article that has a period, which is https://en.wikipedia.org/wiki/Joffe_v._Google,_Inc%2E if you use percent encoding.

I’m not sure what the point of your comment is.

It seemed that the issue was incorrectly diagnosed, and MediaWiki or Wikipedia was being blamed for the error, and that you had also proposed a rather strange workaround for it. The issue could be solved completely within the context of Hacker News post markup, as linked.

If you put a hashtag at the end of a Wikipedia URL, then I suppose it works, until the URL already has a hashtag in it, because these are used for section headings. It's not called "escaping" anything, it's just... an empty URI fragment: a link to the top of the article?

There is also nothing preventing a Wikipedia editor from creating a redirect from the title y'all linked. In fact it's a perfectly fine idea for a redirect. The fact is that the canonical title is in US English, and in US English, "Inc." takes a period as an abbreviation.

There's nothing wrong with your workaround or your percent-encodings to escape some dubious glyph, but I hoped to clarify things and derail the thread further on pedantic technicalities. Thank you for coming to my TED talk.

> It's not called "escaping" anything, it's just... an empty URI fragment: a link to the top of the article?

It’s an escape from pedantry.

I appreciate your gentle needling, as imprecision in my words reflects an imprecision in my rhetoric, making it vulnerable to nitpicking. It’s okay to be wrong if it allows me to make a larger point in favor of my position, but at a cost to readers’ time and patience.

Thanks for your close reading and feedback, it helps.

Reply on news.ycombinator.com