3 ms·

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 th

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 https://en.wikipedia.org/wiki/Joffe_v._Google,_Inc.

aspenmayer 1y ago
> [0] https://en.wikipedia.org/wiki/Joffe_v._Google,_Inc 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.
- Timon3 1y ago
  That's a very useful tip, thank you!
- AStonesThrow 1y ago
  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://news.ycombinator.com/formatdoc <https://en.wikipedia.org/wiki/Joffe_v._Google,_Inc. https://en.wikipedia.org/wiki/Joffe_v._Google,_Inc.> https://en.wikipedia.org/wiki/Man_or_Astro-man%3F 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_(technical_restrictions) https://en.wikipedia.org/wiki/Wikipedia:Naming_conventions_(...
  - aspenmayer 1y ago
    > 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 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 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.
    - AStonesThrow 1y ago
      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.

aspenmayer 1y ago

> [0] https://en.wikipedia.org/wiki/Joffe_v._Google,_Inc 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.

Timon3 1y ago
That's a very useful tip, thank you!
AStonesThrow 1y ago
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://news.ycombinator.com/formatdoc <https://en.wikipedia.org/wiki/Joffe_v._Google,_Inc. https://en.wikipedia.org/wiki/Joffe_v._Google,_Inc.> https://en.wikipedia.org/wiki/Man_or_Astro-man%3F 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_(technical_restrictions) https://en.wikipedia.org/wiki/Wikipedia:Naming_conventions_(...
- aspenmayer 1y ago
  > 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 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 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.
  - AStonesThrow 1y ago
    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.