155 karma · joined October 23, 2012
You talk to a master agent (Sidekick) describing the app you want, and it creates it for you, batteries included (a lot of tools, which are vetted MCP servers and skills, a database, cron-jobs, and a hosting environment where your apps live). The tools connect to many things such as email, slack, weather, sports, news, web, and your agents can do all sorts of things.
Being a library is a pretty interesting feature! Correct, Durable Functions allows you to write task-parallel orchestrations of task-parallel 'activities' (which are stateless functions), and these orchestrations are fully persistent and resilient, like DBOS executions. It also has the concept of 'Entities', which are named objects (of a type you define) that "live forever", and serialize all method invocations, which are the only way to change their private state. These are also persistent. The Netherite paper [1], section 2, describes this model well.
So, there seems to be a pretty close correspondence between DBOS steps and DF activities, and between workflows and orchestrations. I don't know what the correspondence is to DF entities is in the DBOS model.
[1] https://www.microsoft.com/en-us/research/wp-content/uploads/...
In the default mode, the app will interpose on the communication between, say, Claude, and a local MCP server. It will send the contents of the message (which may include the very sensitive information it is trying to protect) to a remote LLM, which you have to trust. The "scans" will be stored on a log on the server. Not to mention the potential extra delay for every MCP exchange?
This may be more secure, but is it really?
They wouldn't be able to see you are using X in particular. There may be very specific timing patterns that the X app or the X web app use when fetching related images, new posts, etc, but this also depends on how you scroll the site, and this seems infeasible to prove beyond any reasonable doubt, and also that any ISP would have logs with that granularity. As the parent said, you should make sure no DNS queries go outside of the VPN, for example.
Now, if you post to X, then it would be clear that you used it, which would be a problem according to the resolution, as long as you were in the country.
After the course ended, one student going home did manage to use his assignment to get Internet access from the airport, as we had forgotten to turn off the DNS server nodes.
Over the years we had a lot of fun with creative final projects in the course besides IP-over-DNS, including web-based phone tethering, DNS spoofing, openflow-based SDN routing, LT (Erasure) Coding, a BitTorrent client, and a DNS-redirection-based CDN with leaderboard.
[1] https://cs.brown.edu/courses/cs168/s11/handouts/dtun.pdf
Her PhD work went on to really understand the performance of complex distributed programs, like large Spark jobs, and a lot of at least earlier performance instrumentation in Spark is due to her.[2]
[1] https://brooker.co.za/blog/2012/01/17/two-random.html [2] http://kayousterhout.org/
One big problem with the electoral court in Brazil is that it is the only public branch that concentrates the three powers in one entity: they legislate about elections, they execute the rules, and they judge any matters related to the election. As a result, they have chosen these arguments to shoot down any criticism or improvement suggestions to the election system.
The country deserves a non-politicized discussion on the ground of true technical and security merits of what the election system should be. Paper records with Risk-limiting audits would solve most of the problems. I agree with your [comments] above. The costs of implementing this pale in comparison to the benefits of having a more reliable voting process which is the basis of a strong democracy.
First one is [1], by Chiu and Jain (page 7, figure 5), showing that Additive Increase / Multiplicative decrease is the only simple policy that converges among 2 senders (with rates x and y) to a rate that is fair (along the y=x diagonal) and efficient (along the x+y=Bandwidth). This is the basis of the algorithm that made TCP (and the Internet as we know it today) possible.
The other one is this diagram from BBR [2] (from the paper in [3]), that shows how BBR sets the window ("amount in flight") to the bandwidth-delay product (BDP) of the bottleneck link (the "volume" of the pipe in a water analogy). The cool thing is that you can only measure the delay of the link if you window is <= the BDP, and you can only measure the bandwidth if your window is >= the BDP, so the algorithm has to hover around this point to make sure it can determine both.
[1] Chiu and Jain, Analysis of the Increase and Decrease Algorithms for Congestion Avoidance in Computer Networks, 1989, https://www.cse.wustl.edu/~jain/papers/ftp/cong_av.pdf
[2] https://dl.acm.org/cms/attachment/9cf72499-b32d-4426-914b-cd...
[3] BBR: Congestion-Based Congestion Control https://queue.acm.org/detail.cfm?id=3022184
Which brings us to a potential problem: there has been a tremendous amount of fraud in this system (Brazil's Boletos), with all sorts of malware changing the barcode when it is downloaded in an infected computer to issue a boleto with a different destination account.
Back in 2014 this was well documented by Krebs[1], and at amazing detail by @assolini from Kaspersky[2]. I also documented a specific case that happened to a friend[3]. While it should be possible to mount similar attacks on the Amazon system, having people deposit money into others' accounts, it should be straightforward for Amazon to detect this, since it is a single issuer system...
[1] https://krebsonsecurity.com/2014/07/brazilian-boleto-bandits... [2] https://securelist.com/analysis/publications/66591/attacks-a... [3] http://cs.brown.edu/~rfonseca/notes/net-bb-dns-poison.html