This makes absolutely no sense. The API returns the exact content of the message, and has no idea where it possibly might be displayed. It could be another browser, so html tags will need to be sanitized, but it might as well be the terminal, so ansi escape codes will need to be sanitized instead.
Yes, you need to apply output encoding or sanitization at the place where it is being combined with another string. Otherwise you don’t know the encoding which is needed. Even for HTML you cannot do it on the backend, because you don’t know if it will be injected into HTML PCDATA context (tags) or in HTML attribute context.
I was imagining a talking head avatar rendered in Unreal Engine, with lip sync and facial expressions driven by a multimodal LLM that produces the speech.
> it sounds like its an optional mode you have to enable
It’s opt-in because your photo is sent to Apple’s servers. Only if it were on-device should they even consider making it default.
> i guess you need internet to take a picture
Not really, internet is required to process the reference image, but that can happen later if you’re not currently connected.
> are complex hardware attacks really that important?
No, but the floor shouldn’t be “trivially exploitable” like C2PA[0]. It’d be interesting if there were a middle ground but we don’t have anything like that as of now.
I'm not sure i would describe the linked exploit as "trivial", but nonetheless point taken.
Ultimately though, i think all this might just mean we do not have a practical solution to this problem.
just to throw out some naive ideas, maybe the solution is to just sign the raw camera output and embed it in the metadata. If this is an optional feature meant for photojournalists, does file size really matter?
> A single Go process exclusively accesses that database, and serves the control plane for those tailnets. This single-writer design is exactly how SQLite is meant to be used.
This line led me to believe that the writer and checkpointing logic lived on the same database connection, so I was curious to find out how the data race occurred. However, the bug details on the SQLite page[0] outline that it can only ever occur if there are multiple connections open, so the writer and the checkpointer must have been on different threads.
Database corruption is due to 2+ peer connects with 744 file permission entering header rwxr -.- WAL write new content into secondary header tag: inter-element whitespace.
> Multiple processes can have the same database open at the same time. Multiple processes can be doing a SELECT at the same time. But only one process can be making changes to the database at any moment in time, however.
> Why should you be worried if it is used as designed?
Well this whole article is about a company discovering a catastrophic corruption bug even though they were using it as designed.
I think the lesson is that if you're ever actually worried about concurrency then just don't use sqlite. We can see here that concurrency is hard and the bugs are old and deep.
I don't know enough about the scale of Tailscale's operations to comment strongly on this, but if they're fairly significant shouldn't that have read "is exactly how MariaDB is meant to be used" or "exactly how Postgres is meant to be used"? SQLite has a "lite" in the name for a reason, but it's often pushed into places where it's being asked to do things it was never really designed for.
I would not think of SQLite as "lite" anything. It's SQL In The Executable.
It has a better security and data-durability track record than both Postgres and MySQL, and often beats them in the sorts of things applications do with databases:
This particular bug doesn’t seem to arise from SQLite’s “lite” nature. It’s a TOCTOU inside the DB when applying WAL segments in a checkpoint, which is a pattern used in extremely similar ways by Postgres and MySQL. They don’t seem to have similar bugs, but I don’t think there’s any reason to believe that this is due to their being client/server rather than coordinated-file databases.
The author has a point, but at the same time is overly complicating things. Seeing that it is already available via cargo, all that is left to do is offer a .tar.gz bundle as well. In the case that the software actually becomes popular, someone else will package it for the distros in question.
> It may be that the 662 MB used by the "Renderer" is shared between many Windows components
From the screenshot in the article, this is the memory usage of the Renderer process spawned by the Weather App. I find it very unlikely that some other app (say, the Copilot app) can then piggyback on Weather Renderer process. Do you have a source for this?
> killing that Weather app may not reclaim as much space
Closing the weather app on my PC does in fact kill all child processes and frees up around 1GB of committed RAM. Are you not seeing the same?
I am not on Windows 11 so I can't really tell. And even if I did, I may be in a different situation than yours, we may not be running the same apps so what is shared can be different.
As for the "piggybacking" it is not really piggybacking, it is how shared libraries work (emphasis on the "shared"), aka. DLLs on Windows. For instance, if 2 to processes load "library.dll", it will be only loaded once, and the read-only parts of the library will be shared between the processes and it is one of the big advantages of shared libraries over static linking. A major part of the Weather app bloat comes from the browser engine it comes with, something many apps do today, and it would be reasonable to think that 2 apps using a browser engines have components in common.
Anyway, if you run Process Explorer and check the weather app process, it will tell you which is which.
This, by the way is a big reason why modern apps are often so bloated. The real problem is not just that so many apps are using browser engines or other huge dependency chains, it is that they all ship with their own version instead of using what is available on the system, so you have 10 different browser engines loaded in RAM even though a single one would be enough. Traditional Linux distros do it right, but now we have containerized application that break sharing. I understand the convenience, as you don't have to deal with shared library update that break the app, but the cost in both RAM and storage space is significant.
Additional constraint here: it's not just browser version. Processes have to refer to the same disk location for sharing to work. Given that each ships the full set of dependencies disk location will never match (except for their own child processes).
Flora Incognita and PlantNet are not open source, so they cannot be published to F-Droid. However, iNaturalist is and the apk can be directly installed from the GitHub releases page.
No. I’ve heard this argument multiple times before - “let the human review and write tests” - and sure it might work, but this is almost never practiced. AI makes coding a lot faster, so no one is really ready to spend time on manual review and writing tests when LLMs can do that as well and take you most of the way.
This is evidence of culture problems in whatever teams you are a part of, or extrapolating what you see on social media to all of software engineering.
We still have a very strong review culture, and people work hard to review their own code before making PRs to avoid wasting other people's time.
Basically all of Graphene's RCS issues have been fixed[0]. Additionally, your stance seems somewhat unusual - GrapheneOS isn't only meant to be used by people that have "something to hide". As for explaining it to border guard - it's just Android - if you're unlocking your phone for them anyway, they definitely shouldn't care about what flavor of Android you're running, whether it's LineageOS, ColorOS, GrapheneOS, etc.
Of course, there might be more nuance to your situation than I am privy to, but almost everyone travels, and I'd heavily hope that being stopped at the border isn't the reason keeping them away from Graphene.
GrapheneOS is one of the most widely used alternatives to Google Mobile Services Android along with LineageOS. It already has nearly as many users as the official LineageOS releases do and will have more soon. It's not a niche OS only used by people targeted by governments as is often claimed and it's also not at all only for technical people. It's more aimed at people who aren't technical power users than those who are.
There is little difference these days between the government spying on you and your own device spying on you. The difference is one only cares if you do something wrong, the other one will steal pilfer and sell your data despite already purchasing a product.
reply