SPA legitimately insert pages into the history to hijack the back button to make it seem like the user was actually navigating through a site instead of it being a single page. If there is a bug somewhere that causes it to insert too many of these navigations or add navigations that user doesn't personally think should be navigations I could see it being considered as potentially violating this policy.
If this was about intentional abuse the article would not have had to ask all site operators in existence to audit their entire website for this. Even if some random library does this without your knowledge can violate this.
>> So that in single-page applications, it can work intuitively instead of always taking you all the way out of the app.
Just implement an additional back button on the SPA. This is actually not confusing and is done in some places. Navigation buttons within an SPA are common enough.
If the navigation simulates what would happen if we follow links to SPA#pos1, SPA#pos2, etc so that if I do two clicks within the SPA, and then hit Back three times I'm back to whatever link I followed to get to the SPA, I guess it's OK and follows user expectations. But if it is used as an excuse to trap the user in the SPA unless they kill the tab, not OK.
> From the browsers perspective those are the same thing though.
If the browser only allows adding at most one history item per click, I should be able to go back to where I entered a given site with at most that many back button clicks.
At a first glance, this doesn't seem crazy hard to implement? I'm probably missing some edge cases, though.
Some browser APIs (such as playing video) are locked behind a user interaction. Do the same for the history API: make it so you can't add any items to history until the user clicks a link, and then you can only add one.
That's not perfect, and it could still be abused, but it might prevent the most common abuses.
> People rightly criticize all of the problems around vendor-lock-in and rent-seeking with platform app stores, but this is a good example that they do indeed provide some value in terms of filtering out malware.
But browser extension marketplaces aren't a free-for-all; they're exactly like the platform app stores in all the bad ways.
> Everything to do with LLM prompts reminds me of people doing regexes to try and sanitise input against SQL injections a few decades ago, just papering over the flaw but without any guarantees.
With the key difference being that it's possible to do this correctly with SQL (e.g., switch to prepared statements, or in the days before those existed, add escapes). It's impossible to fix this vulnerability in LLM prompts.
> Tesla remotely [...] stripped FSD entirely — reverting them to basic Autopilot.
> owners who activated FSD through the hack received in-vehicle notifications that they were permanently banned from using FSD — even those who had paid for it.
Whichever human beings actually made the decision to do that should go to prison for violating the CFAA. Once I buy a car from you, it's mine and not yours anymore, so I can make whatever changes I want without getting your permission first, and you no longer have the right to go into my garage and take pieces off of it.
> Tesla mass-emailed affected owners [...] that the company “reserves the right to refuse warranty repairs regardless of whether the device actually caused the damage.”
Isn't this a violation of the Magnuson-Moss Warranty Act?
Anti-cheat drivers are just as much of rootkits, and in practice, they have vulnerabilities that get a lot more hosts pwned than cheats do. Let's get Microsoft to stop loading their drivers.
I agree. Microsoft should provide proper integrity APIs to apps so they don't need such drivers. The fact that the PC ecosystem is so far behind XBox's for platform integrity is a big failure on Microsoft's part towards the PC gaming market.
Integrity is needed for a fair playing field. Their is consumer demand for such a fair playing field so it is a good thing for an operating system to respond to customer demand.
reply