Please explain the legitimate uses. Not once I have ever encountered a website that does something useful by modifying the behavior of my browsing history.
Youtube doesn't implement a back function. A real back function would take you back to the same page you came from. If you click a video from the Youtube home page, then click the back button, Youtube will regenerate a different home page with different recommendations, losing the potentially interesting set of recommendations you saw before. You are forced to open every link in a new tab if you want true back functionality.
Well, if I wanted to return to the parent screen in a single page application, I'd click on the back button in the app itself. No need to prevent me from back tracking in the exact order of my browsing should I need it.
I especially hate YouTube's implementation, I can never know the true state on my older PC during whatever it's trying to accomplish, often playing audio from a previous video when I backspace out. I resort to opening every link in a new tab.
The spec kind of goes into it, but aside from the whole SPAs needing to behave like individual static documents, the big thing is that it's a place to store state. Some of this can be preserved through form actions and anchor tags but some cannot.
Let's say you are on an ecommerce website. It has a page for a shirt you're interested in. That shirt has different variations - color, size, sleeve length, etc.
If you use input elements and a form action, you can save the state that way, and the server redirects the user to the same page but with additional form attributes in the url. You now have a link to that specific variation for you to copy and send to your friend.
Would anyone really ever do that? probably not. More than likely there'd just be an add to cart button. This is serviceable but it's not necessarily great UX.
With the History API you can replace the url with one that will embed the state of the shirt so that when you link it to your friend it is exactly the one you want. Or if you bookmark it to come back to later you can. Or you can bookmark multiple variations without having to interact with the server at all.
Similarly on that web page, you have an image gallery for the shirt. Without History API, maybe You click on a thumbnail and it opens a preview which is a round trip to the server and a hard reload. Then you click next. same thing. new image. then again. and again. and each time you are adding a new item to the history stack. that might be fine or even preferred, but not always! If I want to get back to my shirt, I now have to navigate back several pages because each image has been added to the stack.
If you use the History API, you can add a new url to the stack when you open the image viewer. then as you navigate it, it updates it to point to the specific image, which gives the user the ability to link to that specific image in the gallery. when you're done. If you want to go back you only have to press back once because we weren't polluting the stack with history state with each image change.
Thanks for the detailed and thoughtful reply! I agree that in both of the scenarios you mentioned, this API does provide better usability.
I guess what feels wrong to me is the implicitness of this feature, I'm not sure whether clicking on something is going to add to history or not (until the back button breaks, then I really know).
The Affinity suite was made free to use, with optional paid "AI" features behind a subscription. The betrayal was probably against the promise of a perpetual license sustained not by subscription.
Trigger warnings are not there for some scientific effect. I view them as courtesy for consumers to have an chance to opt out of possibly unwanted experiences beforehand.
A whole lot of people do make the argument that they are beneficial from a mental health perspective, though, and that's what isn't backed by the science. You can see discussion of it in-thread, even.
All they'd learn that way is that that phone number has a Signal account, when it was registered, and when it was last active. In other words, it doesn't tell them whether it's part of a given Signal group. (See https://signal.org/bigbrother/.)
They publicly publish these requests. You can see how little information is provided — just a phone number and two unix timestamps IIRC.
https://signal.org/bigbrother/
I might be misremembering or mixing memories but i remember something about them only storing the hash of the number.
So the FBI cant ask what phone number is tied to an account, but if a specific phone number was tied to the specific account? (As in, Signal gets the number, runs it through their hash algorythm and compares that hash to the saved one)
But my memory is very very bad, so like i said, i might be wrong
It would be absolutely trivial for the FBI to hash every single assigned phone number and check which one matches. Hashing only provides any anonymity if the source domain is too large to be enumerable.
You don't even need to think about how the hashing scheme and salt is set up. If Signal can check if a phone number matches the hash in any reasonable amount of time (which is the whole point of keeping a hash in the first place) then the FBI can just do that for all phone numbers with very realistic compute resources once they get Signal to cough up the details of the algorithm and magic numbers used.
I know that before, Unicode and locale aware systems were supposed to use unicode tags (U+E0000..U+E007F) to invisibly and "for all plaintext purposes" mark text for such han unification handling but that use is now deprecated.
What I am supposed to use those days? HTML-encoded in utf-8, with lang attributes, so <span lang="ja-JA"> and <bdi lang="zh-Hans"> infested text?
reply