So prosecute them for those other things, no? Instead of helping criminals grow their business by banning non-harmful stuff and giving them monetary growth opprotunities.
Crime benefits from network effects even more than regular businesses, you have to attack them via every opportunity.
However you are putting words in my mouth, in a typical American style of prosecution-->banning. It is quite possible to legalise and regulate marijuana. American halfway legalisation creates an industry which funds OC and can't be prosecuted. Canadian legalisation creates a revenue source for the provincial governments while providing vertical integration and control, and the volume of illegal weed has plummeted.
Advantage is user has no control/is not needed to consent about what apps they're authorizing to share their information between each other, bacause the decision to delegate access is at the IdP policy level. User many never know which apps/services were authorized to share their information. Wait, is that an advantage? ;-)
For organizations it's definitely an advandtage, as it also allows for preventing data flowing to personal accounts. Right now, any employee could knowingly or unknowingly exfiltrate data, by just connecting to e.g. the personal instead of the organization's JIRA account, and there is essentially no standard way to guard against that as an organization.
That's also blind spot in normal OAuth and I was surprised to find that this was never addressed in all the years that non-MCP OAuth found adoption.
As someone who has been creating agentic workarounds at my large employer and in a lot of conversations with security as a result, this does not seem to be a huge advantage from the company side. They are very much invested in users being aware of what they permit. The company does want the final say either with shutting down a compromised user or blocking one service from agents and allowing the other, but they 100% do still want employees to be actively engaged and applying their own consent.
Removing that from the employee also removes the employee from responsibility for any breach of information IMO, and companies definitely don't want that lol. What they do want is users to stop complaining about the annoying reauth every 8-12 hours for a dozen services which this does.
The kinds of wishlists I hear are more about users managing fine-grain service permissions for various agentic roles and managing which agents have access to which role, which leans the other direction. They want to allow users are to treat agents like cloud services and have a greater responsibility for applying least privilege, justify leak risks, etc. The onus to protect this data will always be an employee responsibility in the end.
I am with you on the challenges with fine grain authorization needs, to me that part is real hard. In a theoretical world the IDP would know all the roles and permissions available for the different authorization servers (downstream services). However centralizing something like this would require some adoption of how permissions are managed by different resource servers, that is a different battle.
What this gives your employer is the allow list of AI agents that you can use (the ones that can use your employer's IDP to access downstream MCP servers) and filters out all the MCP servers that do not implement this protocol. Essentially the threshold to use any AI agent or any MCP server would be a lot higher.
The point is that people in the US absolutely do get called racist all the time for all manner of things.
The question was asked if some US person might be called racist for having an opinion about gentrification that seemingly has little to do with race, and the answer is yes, yes they have been.
That said, there can be some "Oh yeah - well if you're insinuating that white people are displacing black people then YOU are the racist" which is just... not the same thing. One view of the world may incorporate a significant accommodation and acknowledgement of historical discrimination, enslavement, red-lining, you name it. The other is... technically correct I suppose, but complete horseshit on the merits until we start to see significant, systemic harm going the other direction as a result of race.
> A lot of times local storage is much less secure
Without XSS, local storage is actually more secure. You don't have worry 'did I set up this right' because there is nothing to set up and CSRF is impossible to execute.
If you're still paranoid about XSS, CSP is your friend. Also check isTrusted on events.
If you exclude all of the flaws of one implementation and include all of the flaws of another, then of course you can say one is better than the other. But that's not a fair comparison of implementations
CSRF has incredibly simple mitigations with cookies (SameSite=strict) and can even work across different path segments (although this tends to be uncommon) and has mitigations against XSS which local storage does not. XSS is bad in either case (CSPs aren't usually an effective mitigation for a variety of reasons[1]) but being able to outright steal the session token is worse than being able to use it in a potentially more limited context
[1]: Primarily that they're generally just not implemented and that a lot of web frameworks require incredibly loose CSPs up to and including unsafe-eval since they often need to dynamically load JS. In addition, this doesn't protect from supply chain attacks (JS that is injected as the result of it being loaded from another domain, like from a CDN for example).
It's a separate attack vector. It's easily mitigated by having a one week back-off before upgrading. (and as I have said already, also affects binary executables)
> unsafe-eval
Technically speaking, nothing prevents you from shipping a JS-in-JS runtime that proxies objects and bypasses eval, which is just eval without eval.
It's not a perfect mitigation for session stealing, isn't available in all cases, requires custom code to implement, and also can in some cases completely break sessions (unless they have another place where it's stored)
> It's a separate attack vector. It's easily mitigated by having a one week back-off before upgrading. (and as I have said already, also affects binary executables)
A separate attack vector for the same problem. Which is also not mitigated by dependency back-off. If you load a 3rd party script into your site, you're relying on that 3rd party not getting compromised.
Which ones? Websites that ship no JavaScript? All browsers support this.
> can in some cases completely break sessions
Or you can just remove local storage from window and have it just for yourself, which seems what Discord is doing as well.
Attackers cannot use local storage because there is no local storage on the window object.
> A separate attack vector for the same problem
It's not exactly the same problem. The example you mentioned is a footgun because you don't vendor your dependencies. Deliberately giving someone else access to your website is an issue in itself.
In the Discord case they can just call the `getToken()` function. It's not on `window`, but it's trivial to find.
The mitigation is rough on systems where SIGKILL happens early and often. Presumably this is why Discord doesn't do this on mobile. You switching out of the app has a much higher likelihood of that happening than on other platforms. You can't rely on onunload ever getting a chance to run
This also has barely anything to do with local storage, you could do the same for cookies. But with cookies, the browser blocks JS from getting your tokens at all if you use HttpOnly and don't leak it in responses or whatnot, so you don't need to (though you certainly can delete window.cookies if you want as well)
Not really. Difficulty of the attack matters. If your attack chain is silently doing an sql query over 20 year stable database format, vs something that may involve extraction of a master key from some hardened process, or tricking the user to reveal the master password to you, odds of you raising alarm in some anti-malware software raise significantly, because now you're not just reading a file, but you're using some deubgging APIs, etc., that common software does not use.
The only difference between the cookie scenario and localstorage scenario here is that you're reading "storage/default/<domain>/ls/data.sqlite"
It's even conveniently grouped by domain
There's no magic hardening going on with local storage (session storage is the same here), it's still SQLite
Even if so, calling ReadProcessMemory/process_vm_readv on another process really doesn't raise alarms that significantly because there are a lot of legitimate programs that do so
I'll save my admiration for the code or the results. Admiring people for skills is weird. All it takes to build a skill is time and effort and some innate characteristics.
Getting listed on popular twitter account is I guess useful, depending on how much you care about receiving attention. But otherwise I'm kinda wary of people who give admiration to a person's skills or people who like to receive it.
reply