4 ms·

Turns out having your short URLs too short can also be problematic: https://arxiv.org/pdf/1604.02734v1.pdf https://arxiv.org/pdf/1604.02734v1.pdf An example in

Turns out having your short URLs too short can also be problematic: https://arxiv.org/pdf/1604.02734v1.pdf https://arxiv.org/pdf/1604.02734v1.pdf An example in this paper cites the shortener used by Google Maps. The researchers were able to enumerate all the short links by brute force and join destinations from specific residential addresses. This is scary because now you've essentially created all points of interest that 1 person visits (originating from their home address). Google's response was to expand their URL tokens from 5 characters to 12. The sparseness makes it uneconomical for someone to brute-force their way through. Microsoft OneDrive's response was... interesting.

grayhatwarfare 5y ago
https://grayhatwarfare.medium.com/how-to-search-urls-exposed-by-shortener-services-f68e199cd560 https://grayhatwarfare.medium.com/how-to-search-urls-exposed...
dredmorbius 5y ago
This is giving me pause to think on when you want short and dense pattern spaces, and when you want sparse spaces. Published articles meant to be accessed publicly seem like a case for the former. The idea is for those references to be found, and a search space which is both predictable and small is preferred. Here I tend to like schemes such as: example.com/yyyy/mm/dd/nnnn.../<optional descriptive> That is, for temporal data, explicitly code in the year, month, and day (and finer gradations of time if appropriate), then an item number (possibly sequenctial). The optional descriptive text might incluce author(s) and title(s). Dates aren't always required. Some well-known cases (comparatively) are Amazon's reliance on SCU, iBiblio's reliance on ISBN, and Worldcat's reliance on OCLC. (You can omit all other index elements on the URL to obtain the desired result.) Sparse spaces tend to be for non-published / non-public entities and docucments. Google+ in particular had a 20--21 digit numeric userid (apparently used within Google as the account UUID). Even with some 3--4 billion registered profiles (the vast majority auto-created through Android device registrations), the space was sparse to a ration of trillions (and higher when interest was focused on the only the 100--300 million or so active accounts). This had a huge impact on the ability to crawl the space efficiently, as a brute-force search would have taken some time. Fortunately, Google provided sitemaps.... A related concept is James C. Scott's notion of legibility (from Seeing Like a State), and where it is and is not advantageous, and for whom.
flakiness 5y ago
For these who prefer non-PDF arxiv link: https://arxiv.org/abs/1604.02734 https://arxiv.org/abs/1604.02734

grayhatwarfare 5y ago

https://grayhatwarfare.medium.com/how-to-search-urls-exposed-by-shortener-services-f68e199cd560 https://grayhatwarfare.medium.com/how-to-search-urls-exposed...

dredmorbius 5y ago

This is giving me pause to think on when you want short and dense pattern spaces, and when you want sparse spaces. Published articles meant to be accessed publicly seem like a case for the former. The idea is for those references to be found, and a search space which is both predictable and small is preferred. Here I tend to like schemes such as: example.com/yyyy/mm/dd/nnnn.../<optional descriptive> That is, for temporal data, explicitly code in the year, month, and day (and finer gradations of time if appropriate), then an item number (possibly sequenctial). The optional descriptive text might incluce author(s) and title(s). Dates aren't always required. Some well-known cases (comparatively) are Amazon's reliance on SCU, iBiblio's reliance on ISBN, and Worldcat's reliance on OCLC. (You can omit all other index elements on the URL to obtain the desired result.) Sparse spaces tend to be for non-published / non-public entities and docucments. Google+ in particular had a 20--21 digit numeric userid (apparently used within Google as the account UUID). Even with some 3--4 billion registered profiles (the vast majority auto-created through Android device registrations), the space was sparse to a ration of trillions (and higher when interest was focused on the only the 100--300 million or so active accounts). This had a huge impact on the ability to crawl the space efficiently, as a brute-force search would have taken some time. Fortunately, Google provided sitemaps.... A related concept is James C. Scott's notion of legibility (from Seeing Like a State), and where it is and is not advantageous, and for whom.

flakiness 5y ago

For these who prefer non-PDF arxiv link: https://arxiv.org/abs/1604.02734 https://arxiv.org/abs/1604.02734