RFC 3986 s 7.5 contnd: "A password appearing within the userinfo component is deprecated and should be considered an error (or simply ignored) except in those rare cases where the 'password' parameter is intended to be public."
-
It's not for no reason. It's very useful to know where a file came from and record the URL along with the file download. Safari does it, DEVONthink Pro does it, Evernote does it, etc. Which is exactly why the RFCs say not to put secret info in URLs.
Please enumerate those useful reasons. Especially reasons to attach the URI *to the file*, not just metadata in a browser database somewhere.
-
-
Use cases: I've searched for files by source URL, sorted and filed them by source URL, gone back to the source URL to check for updates, and passed the source URL on to people so they can get a verified copy of the file from the original source.
-
Most of which you can do with an out-of-band database. And if you really want this feature you can go ahead and turn it on. It just shouldn't be on *by default*.
End of conversation
New conversation -
-
-
This reminds me of people who get really angry when they find out about EXIF information. Look, I understand, you didn't know about it — but now you do, so the smart thing is to adjust your behavior accordingly.
-
At least EXIF data is inside the file, and applications display it, and it's just metadata, and pretty much every non-evil camera app has toggles for sensitive stuff like location information. Literally *nothing* advertises "hey your file has an xattr with a URI in it".
- Show replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.