Unless it has a huge memory leak that isn't fixed for years and causes it to be virtually unusable for anyone it's probably not the Windows ME of Tablet OS's.
If leaking creation time is a concern, can we not just fake the timestamp?
We can do so in a way that most performance benefits remain - so like starting with a base time of 1970 and then adding base time to it intermittently, having random months and days to new records (or maybe based on the user's id - so the user's record are temporally consistent but they aren't with other user records).
I'm sure there might be a middle ground where most of the performance gains remain but the deanonymizing risk is greatly reduced.
Edit: encrypting the value in transit seems a simpler solution really
In that case, auto increments can also be bumped from time to time. And start from a billion.
They're more performant than uuidv7. Why would I still use UIID? Perhaps I would still want uuids because they can be generated in client and because they make incorrect JOINs return no rows.
Unit 8200 is the premier software development track in the Israeli military.
Every Israeli tech company likely has multiple developers from Unit 8200 in it. Whether it's building e-commerce shops or making video games.
While 8200 definitely falls under the military intelligence wing, I don't think describing people in it as Cyber Spies is anywhere near accurate. And unless that guy was very high ranking it is a stretch to imply that's an indication that IL military intelligence is involved in the company.
That is not to say that the military isn't involved with the company - that might very well be true, just that someone being from Unit 8200 isn't an indication of it.
People who don't live in countries with mandatory conscription for all don't really understand: everyone is connected to the military but it means nothing.
Judging an Israeli citizen on their IDF ties is like judging a US citizen on the fact that they went to public school.
> everyone is connected to the military but it means nothing.
No, people who live in tiny countries with mandatory conscription don't really understand that it means that their entire country is militarized. It's not surprising that fish can't see water.
> is like judging a US citizen on the fact that they went to public school.
It's exactly like that. If public school in the US trained people to kill and spy, it would be entirely safe to assume that the US was full of killer spies. For example, if you know that US public school taught a view of world history that was distorted in particular ways, and had very little emphasis in foreign languages, it would be safe to assume that Americans have a distorted view of the world, and largely don't speak foreign languages.
According to google, 87% of Americans go to a state-funded school, so yes judging an American based on the fact that they could afford to be in the top 13% and go to a public school instead is legitimate. This doesn't seem to match what you're trying to say.
You’re using the British definition of “public school” here, which is a “private school” in the US. US public schools are equivalent to UK state schools, in that both are run by the state.
It doesn't matter if it's accurate or not, such judgements are made by most people every day. Someone who was professionally formed somewhere has a higher probability of ties to them later on. Being intelligence services this might be even more true.
In today's political climate where people around the world see Israel judging (and sentencing, and carrying out the punishment) every Palestinian as terrorists, I think this wide brush of judging Israelis on their ties with the IDF is probably widely accepted as "only fair". When it comes to Unit 8200 the implications are even stronger.
But I don't get the US public school system reference. You have to start with a baseline and if you see a private Ivy League school on someone's CV and a random public school on someone else's I'm sure you'll probably make the obvious assumption about which one is better, even if sometimes the obvious is wrong.
An MCP server exposes tools that a model can call during a conversation and returns results according to the tool contracts. Those results can include extra metadata—such as inline HTML—that the Apps SDK uses to render rich UI components (widgets) alongside assistant messages.
If the connector is enabled by the prompt or via a UI interaction, it calls your MCP server. They have created some meta fields your tool can respond with, one of which is something about producing a widget along with a field for html.
In the current implementation, it makes an iframe (or webview on native) that loads a sandboxed environment which then gets another iframe with your html injected. Your html can include meta field whitelisted remote resources.
Load of bull.
Every article linked in this is either wrong or mischaracterized.
Cloudflare does not facilitate phising - it just made proxying and tunneling easier.
The breaches and bypasses mentioned are anything but - they are linking to a successful mitigation of an attack as if the attacker got away with something of value.
This entire article reeks of trying to fit the evidence to an agenda.
Considering they couldn't find actual evidence of problems and had to resort to mischaracterization this is actually a great reason to use Cloudflare.
I've reported blatant phishing attacks targeting seniors dozens of times to cloudflare (and so far it's always been cloudflare) and never once have they replied with anything except "we could not determine this was phishi g". They absolutely facilitate phishing through inaction.
Not my experience at all. We've reported hundreds if not thousands of sites and with few exceptions they have taken them down swiftly. Definitely one of the best cloud operators when it comes to this.
As recently as August 8th, I reported a phishing site targeting seniors into installing a pre-configured Atera client (who _also_ failed to respond in a reasonable time) by pretending to be an event invite. It was blatant and obvious phishing. This was the response:
---
Hello,
Cloudflare received your Phishing report regarding: ----
We are unable to process your report for the following reason(s):
We were unable to confirm phishing at the URL(s) provided.
Please be aware Cloudflare offers network service solutions including pass-through security services, a content distribution network (CDN) and registrar services. Due to the pass-through nature of our services, our IP addresses appear in WHOIS and DNS records for websites using Cloudflare. Cloudflare cannot remove material from the Internet that is hosted by others.
Please reply to this message, keeping the report identification number in the subject line intact, with the required information.
This is the typical response for me from Cloudflare - it took 2 more weeks before it was finally taken down. If I had to hazard a guess, your high volume of reports gets you into a very different support bucket than the occasional reporter.
My most recent experience was terrible for two reasons:
1. They didn't take down an obvious banking scam site that was hiding behind their service
2. They forwarded my "report phishing content" submission, including contact information, to the scammer, resulting in a roughly 100x increase in the amount of spam I receive and ensuring that I won't ever use their reporting function again
This is the comment on here that matters. Supply chain attacks happen all the time. Malicious PyPI packages being one classic example.
This is not about how stupid MCP is, it's about how stupid people can be. And anyone mucking about with agentic workflows, through contractors or not, should be responsible for the code their machines run. Period.
Reducing scope and splitting a single task into multiple PRs each small but part of a bigger picture makes it very hard to see the bigger picture.
You should try to make PRs small, but if a PR is big, then you just have to spend more time to review it.
Formatting commits as a story is a huge hurdle for the one making the changes. And unless every PR is meticulously prepared - going over the commits by the reviewer is a waste of time.
I agree you should return PRs you don't understand though. Or don't feel comfortable reviewing for whatever reason.
Seems like a good thing for founders, doesn't force them to quit school to start a funded startup. Especially for under-privileged youths who might not be able to miss a high paying job opportunity or have no income for months.
Seems like a bad signal for YC though - if you aren't committed enough to quit school or at the very least reject job offers and do your startup anyway - feels like you might not be committed enough to do what it takes?
But if anyone does, YC knows how to pick founders with the right mindset.
I think there is some risk of that. But commitment isn't static. A lot of incredible companies started with founders who were just toying with an idea and weren't committed at all, then they became more committed over time as things started to work.
What is a lead developer in this context? An engineering manager? Is it like an architect (staff engineer/whatever)? An engineer who is in charge of a specific project?
There are different dynamics at play in each role and reading the guy's bio I'm getting the sense that he is a freelancer? or has a consulting company? which would have a whole different dynamic.
The lead developer is the person assigned to the lead developer role. I know it's cheeky but it really could be anyone. It's usually at least a senior-level individual contributor (IC). It's not uncommon for it to be a manager (that hopefully used to be an IC).
The lead's authority also tends to be varied in scope. They could be the lead of the feature, project, repo, team, initiative, or org. Depending on the context, their hierarchy might not always be the same.
So really, a lead is someone that is in or uses leadership within their scope and with others in the same position. Alternatively referred to as "politics".
In this context, they're handing the politics of development issues with the goal of getting features done.
In the aerospace world, it's called a "systems engineer."
The lead:
1: Understands the whole system, but not necessarily every detail.
2: Plans the whole project.
Edit:
Sometimes in the software world, the title is "architect."
This is rarely the "manager," except in organizations that have a hard-on for hierarchy and artificial promotion for "career advancement." Managers are usually concerned with people, schedules, and resources; but don't go very deep into technical issues.
That being said, the lead/manager may fill in for each other when one is on vacation, sick, quits, ect.
The goal remains the same - AGI is what we see in sci-fi movies. An infallible human like intelligence that has access to infinite knowledge, can navigate it without fail and is capable of performing any digital action a human can.
What changed is how we measure progress. This is common in the tech world - some times your KPIs become their own goal, and you must design new KPIs.
Obviously NLP was not a good enough predictor of progress towards AGI and we must find a better metric.
Maybe the Windows Vista of Tablet OSs though.
reply