There's a conversation I had with Ron Buckton, the proposal champion, mainly on this specific issue. [1]
Short answer: Yes, Disposable can leak if you forget "using" it. And it will leak if the Disposable is not guarded by advanced GC mechanisms like the FinalizationRegistry.
Unlike C# where it's relatively easier to utilize its GC to dispose undisposed resources [2], properly utilizing FinalizationRegistry to do the same thing in JavaScript is not that simple. In response to our conversation, Ron is proposing adding the use of FinalizationRegistry as a best practice note [3], but only for native handles. It's mainly meant for JS engine developers.
Most JS developers wrapping anything inside a Disposable would not go through the complexity of integrating with FinalizationRegistry, thus cannot gain the same level of memory-safety, and will leak if not "using" it.
IMO this design will cause a lot of problems, misuses and abuses. But making JS to look more like C# is on Microsoft's agenda so they are probably not going to change anything.
I’m using Telegram for this. Create a channel, sends your bookmarked links there, use the hashtags to tag things. You can share the channel with others and you can write bots for integration with other apps/browsers.
A Docker solution[1] for the same thing using the official client. Performance can’t be compared with native kernel mode of course, but same technique can be used for other global proxy like OpenVPN.[2]
What we need is actually the Matrix protocol for app distribution. That is, a decentralized yet federated platform replacement for App Store. So the longevity and transparency of the platform is ensured by the distributed property.
Although the original title is a little clickbait and not exactly correct, this article written by Ania M. Piotrowska, one of Nym’s main researcher, explained in details what are the privacy properties you need against state level mass surveillance.
The importance of this article is to see a privacy project introspectively admitting its current limitation. In Nym’s case, it still doesn’t have hidden service, sender anonymity and receiver anonymity. This is the level of transparency we want to see from any privacy project.
Having flaws or limitations are okay, but not communicating them with users while advertising itself as a privacy project is just dishonest. I hope to see more articles like this from other privacy projects.
Nym explained its ambition to achieve much stronger privacy properties under much stronger threat model. Until then, they can truly claim to protect privacy against state surveillance.
Hiding the full URL will redirect a lot of traffics back to Google's search engine because people can't easily figure out the source from a screenshot anymore.
Short answer: Yes, Disposable can leak if you forget "using" it. And it will leak if the Disposable is not guarded by advanced GC mechanisms like the FinalizationRegistry.
Unlike C# where it's relatively easier to utilize its GC to dispose undisposed resources [2], properly utilizing FinalizationRegistry to do the same thing in JavaScript is not that simple. In response to our conversation, Ron is proposing adding the use of FinalizationRegistry as a best practice note [3], but only for native handles. It's mainly meant for JS engine developers.
Most JS developers wrapping anything inside a Disposable would not go through the complexity of integrating with FinalizationRegistry, thus cannot gain the same level of memory-safety, and will leak if not "using" it.
IMO this design will cause a lot of problems, misuses and abuses. But making JS to look more like C# is on Microsoft's agenda so they are probably not going to change anything.
[1]: https://github.com/tc39/proposal-explicit-resource-managemen...
[2]: https://stackoverflow.com/a/538238/1481095
[3]: https://github.com/tc39/proposal-explicit-resource-managemen...