This idea reminds me of my statistical genetics days. There’s an (in)famous piece of software, PLINK, which is just gobsmackingly fast. It achieves this by “compressing” genotypes into two-bits. The high school understanding of genetics as AA, Aa, aA, aa, can roughly be made to work even with modern sequencing datasets. Usually you can’t tell Aa from aA so you really just have AA, aA, aa (hom-ref, het, hom-alt). You can clearly stuff that into two bits: 00, 01, and 10. We can repurpose 11 for “no data” or N/A.
Now that you’ve got 32 genotypes per u64, you can start implementing all sorts of operations very quickly. Mean genotype? You can compute that with a couple masks and pop counts, followed by one division. Count of homozygous alternates? Masks and pop counts. Correlation between two genomic positions? I bet PLINK even has a linear least squares implementation written in terms of bitfiddles.
The trouble is PLINK is a special purpose binary tool. What I actually want is a library of tools for working with compressed arrays so I can use these ideas to build new tools. I hope Vortex becomes such a toolkit.
There is the BitArray in Julia, which is supposed to work directly with the underlying bits as bools, but abstracting that away so you can write code as if it was a normal array. I can’t vouch for how well optimized the code is in practice though.
As a warning, in C++ there’s a specialization for std::vector<bool> that does something similar but breaks many of the assumptions that you expect to be true from a generic std::vector<T>. The major one: It isn’t necessarily stored in a contiguous array, whereas the generic version is. This means that you can’t really take the address of a start and end element to a function that expects them to be contiguous, among other things. It was more than a decade ago that I ran into these kinds of issues (before I’d learned to very carefully read cppreference.com all the time) but it was definitely surprising to learn about, even just to learn that there was a specialization for it.
The addressing problem is not from a non-contiguous array, it’s from being a bitset and the obvious impossibility of addressing individual bits. As a result indexing into a vector<bool> returns a proxy object which breaks all kinds of assumptions about the interaction between vector and its T.
Having a separate dedicated bitset causes none of the issues, because people don’t expect it to behave exactly like an array, and more importantly can not use it in generic contexts.
Yeah, I wish they’d made it a separate type in C++ to make it clear that you can’t expect it to behave the same as the generic version. It’s a tricky design issue because lots of stuff does work the same, like iterating over it or accessing elements by index but then other parts… don’t.
For genetic data, the work for other kinds of packed arrays is already done by the BioJulia team here.
I think their code is flexible enough that you could define a new alphabet for a different domain and still use the optimised implementations for LongSequence.
I abandoned Apple back in 2020. It was when they did the whole csam thing. I do have a Mac at work, which is better than Windows, but I always make it a point. Never to update until the next year for any given OS. So if I were to do the new one it would be in June or July. This seems to avoid a lot of the problems. On my from theater PC. I use Debian. Even though x windows may seem old, the KDE and experience” just works “. I don’t have any raise many problems as in Windows, or OSX. Just a zoom and or web browsing machine. It’s the best machine I’ve ever had.
I didn’t like the fact that they would be scanning my pictures. Even though I don’t have any such material in my library, guilty until proven innocent simply goes against my ethos.
They were only scanning files that would be uploaded to iCloud and this was before advanced data protection was introduced so icloud could’ve scanned them anyway
I would be curious to see if someone can unredact this. This is especially obvious in the QR code: the pixels are of random size and position. Its not a simple pixilation function, and therefore the guessing process would need to be highly fault tolerant. I wouldn’t be surprised if a sufficiently motivated attacker could narrow it down and then do a dictionary attack from that, but there’s no point. The only things I censored was:
URLs, which are no secret
The username to an account I’ve transacted on. The username was a derivative of bitwarden’s username generator.
The address of a Monero wallet for said account. The Monero wallet can be rotated, and having the addresses theoretically wouldn’t give you any usable information
A portion of a spent 2FA token
If you’re up to it, I bet it would be a fun challenge. I’ll give you a hint: The censored username is an english word, followed by 4 digits.
Nice article. Thanks for sharing. It’s interesting to see the entire lack of JS in the implementation. I’ve been meaning to step up my game in that regard, so this site might be a good reference. Also funny to see the heavy use of PGP (that feels like the strongest evidence that the operator is German).
Oh, and what a banger of an opening. I can’t keep up with all the stupid shit he’s promised. I was totally unaware of this one.
Yeah, I’ve been long interested in the things that can be achieved without JavaScript, and lately I’ve been ecstatic to see the developments in HTML and CSS that should bring us closer to this reality. I wasn’t expecting the thought leaders in this area to be the markets, but in hindsight I’m not surprised! I’m sure the craft has been honed over many years out of necessity.
I highly recommend visiting Dread (wikipedia link - a reddit clone). Their anti-DDOS & CAPTCHAs are the most impressive no-JS ones I remember and are source available (no license AFAICT, no recent updates).
It’s also a good starting point to find other websites to visit.
PGP is very prevalent on the dark web, I don’t think it’s any indication of anyone’s nationality.
I also like to see what people have done without JavaScript. The trick seems to mostly be chunked transfers and good old form submissions.
Last year, I made a snake game that ran in browsers without JavaScript using these techniques (no longer online). But I was disappointed that the only browsers that supported incremental rendering for chunked transfers were Chrome, Firefox, etc. I had hoped to be able to play it in Dillo, Netsurf, or maybe even a terminal browser.
Really off-topic, but I wanted to appreciate your ascii art animation after stumbling into /locations/ expecting to see a linkedin page based on the link text.
I do have a LinkedIn, but I find little need to promote it — every time I log in I’m inundated with infinite grift and automated recruiter advertisements for mid jobs! My current job actually came from my site, I think it speaks much more to my talents than anything I could put on LinkedIn. I hope it continues to provide opportunities from the right people :)
Anyway, glad you liked the animation, I’m quite a fan myself :)
The issue this post is talking about, storing the key in plain text, is something people have been posting about for over 6 years1. Signal has just ignored the problem until this Twitter thread. On top of that, as the article is pointing out, this only plugged the hole on macOS. Windows and Linux are still vulnerable to any script running as the current user.
This isn’t some nuanced issue. This isn’t something no one noticed until now. The tldr is that if you’re concerned about security you shouldn’t use Signal on the desktop. Its security has always been extremely, comically, unserious.
I agree, Signal Desktop is best avoided. It doesn’t meet Signal Mobile’s security standards.
Just the fact that it’s an Electron app makes it much harder to secure against untrusted data and potential data exfiltration… which happened in 2018 via an XSS vulnerability allowing a received message to execute JS on your client (demo video on Twitter), and the fix didn’t catch all cases so there was a followup CVE.
Just the fact that it’s an Electron app makes it much harder to secure against untrusted data and potential data exfiltration…
You could also argue that this weren’t a cross-platform implementation they might have used the proper tools on each platform to secure the key (e.g. keychain on macOS) from the get go.
The reported issues rely on an attacker already having full access to your device — either physically, through a malware compromise, or via a malicious application running on the same device. This is not something that Signal, or any other app, can fully protect against. Nor do we ever claim to.
What definition of “full access to your device” could possibly apply here? If I installed a malicious iOS app on my iPhone and it could exfiltrate all my Signal messages, would that get the same response? If not, why?
If someone discovered a Chrome vulnerability that allowed a website to silently read your filesystem from JS and the Chrome team replied with “The reported issues rely on an attacker already having full access to your device” we would immediately laugh all the way to the download page of another browser.
Then this:
The posters who raised this issue did so without contacting us directly. Instead, they went straight to social media, in some cases using inflammatory language. And they dropped these claims over a US holiday weekend. This is the opposite of responsible disclosure.
This was reported SIX years ago1. The PR Signal committed was opened back in MARCH2. There was nothing inflammatory about the tweet3. This is some really confidence-destroying stuff.
If the malicious iOS/Android/etc app requested permissions to be an accessibility service, and then read all your messages the next time you opened your signal app or whatever, would that be signal’s issue to resolve?
Why is it signal’s issue when you give the same permissions to other applications running on your Windows/Linux desktop (since they are the default permissions granted for any installed application)?
Sorry, I don’t understand your comment. This flaw didn’t require giving the offending code/process Accessibility permissions. Any code running totally unprivileged on the machine as the current user is all it took. No extra permissions at all.
If you gave an app screen recording permission and it used that to record your Signal conversations, there’s nothing Signal can do about that. Of course.
macOS has facilities for hiding data in one app from other apps. It has facilities for secure key storage. Signal wasn’t using any of these. It can do something about that. And it eventually did. (sort of)
You give it those permissions implicitly by running the programs. Same for almost every app on Windows and Linux.
My point is, on those devices there is nearly no granularity. At most the key store can be used, it doesn’t do anything on a system that has malicious code running however (unless you never unlock those keys ever again)
The only solution is to not have the app exist at all for Linux and Windows.
I agree with that and so I think they should not have the app exist for Linux and Windows, or maybe (this only just occurred to me and currently strikes me as genius although I might change my mind in five minutes) they should call it “Signal Hobbyist Edition” or something to hint to not to use it if you’re a journalist in a country where it might get you tortured.
This is just completely false on all modern operating systems, from integrity levels on Windows to granular permissions on macOS. There’s sandboxing and credential stores. There are superusers on Linux. It is NOT all or nothing.
If what you were saying were correct Signal wouldn’t have been able to fix it.
I want to point out that both times I said that I wasn’t talking about macos.
Feel free to try and take a screenshot of the Signal app using any screenshot tool on Windows, it will work.
Further, setting aside that Signal doesn’t use integrity, and other things like, caches compiled code in a user writable AppData folder. It doesn’t matter if the malicious program asks for elevated permissions to install itself like the vast majority of programs do when installing themselves.
If you stick to Windows S mode, then yeah, you’ll be safe. Everything will be sandboxed. You also will not be able to run Signal. It doesn’t support S mode. By the time you have Signal installed, you are already past the point of opening the elevated permissions hatch for applications you think you can trust.
I already mentioned key stores.
Sandboxing on Linux doesn’t work for Signal as a security mechanism. Signal insists on having access to X11, which in turn, means that any other application that also uses X11, can control / record Signal’s GUI at any time. Further, there is only unofficial sandboxing setups for Signal, none of them are supported by Signal in any form.
Please do not run Signal as root.
If what you were saying were correct Signal wouldn’t have been able to fix it.
On Windows/Linux, they only fixed key storage while the application is unloaded. That only results in not being able to use just arbitrary file read to get the information. If the hypothetical malicious attacker can screenshot, touch GUI, read memory, arbitrary write, etc etc. So your messages are now safer from you running a very very very misconfigured web server, but that is about it.
The article itself talks about how this fix almost changes nothing for an attacker.
Windows/Linux’s per-app security is practically non-existent and in the areas that are existent, only used by Microsoft/nearly-no-one-on-linux. It can not be compared to what iOS/Android/MacOS does.
It’s Signal’s issue because Signal’s mission is security and privacy to a higher degree than most apps. Most users don’t understand the extra risk of using Signal Desktop, and that’s a flaw in the mission.
Note that I’m not a Signal detractor at all, I recommend it to everyone I can and use it myself. That’s why I would like to see the desktop app improve.
If someone discovered a Chrome vulnerability that allowed a website to silently read your filesystem from JS and the Chrome team replied with “The reported issues rely on an attacker already having full access to your device” we would immediately laugh all the way to the download page of another browser.
When it happened to Netscape, we called it “Brown Orifice” and it was in fact a hit to the browser’s popularity, as I recall. Not a big one, though, because the other options were all really bad too.
There doesn’t seem to be any way to adjust the perspective on the 3d map like there is in gmaps but maybe that’s just because it’s set to need 2 fingers to not scroll?
So all those are just some config options of MapLibre. But you don’t even need to use MapLibre, it’s compatible with Leaflet, OpenLayers, etc. The majority of the work here is supplying full planet tile infrastructure, which works with various clients. The clients can then be configured freely.
Web components aren’t the future, they’re the present. I agree they aren’t at all a replacement for React-style components, but they have their place. At $dayjob I fixed a bug in our webflow site by moving our custom code into a web component so styles wouldn’t leak in, and I have a personal project where I use them because it’s stuck on an EOL framework version (sapper/svelte v2) that I don’t want to write significant new code in. I’m writing a new framework myself and it doesn’t use web components but I made https://www.npmjs.com/package/on-connected as a nicety to use with it because there’s no other way to check if a node is connected to a document. Also, I really wish there were more unstyled ui primitives implemented as vanilla js or web components because them all being tied to a specific framework means a lot of duplicate effort is required :/
That’s still underwhelming, and the Web has lost a decade trying to find some use for a “meh” solution to minor problems that could already be solved without it.
Meantime, Chrome devs are still shaking fists at inefficiency of React and vdom, but they’ve spent a decade ignoring it and hoping it’s a fad that will go away.
I feel like when people say “the Web” they mean large heavy toolkits/frameworks like react/vue/angular. Which are certainly one part of the the web but there is also a part that enjoys and prefers more targeted bespoke solutions to problems. There should be a middle ground somwhere between use react and laboriously hand code it all from scratch.
Saying, “That’s still underwhelming” and brushing it off as if it wasn’t “real” web dev is a little dismissive. Some of us like using different tools and would prefer stuff like web components in our builds. The frameworks can and should ignore web components. They are orthogonal to the framework. That is in fact their entire point. It’s up to the user of the framework to integrate it properly in their codebase. If the framework makes that hard then tough cookies. That’s a tradeoff you made when you chose the framework.
The web didn’t “lose a decade” looking for a use for web components. You just don’t swim in the particular section of the web that uses them.
I mean the Web as a platform in general, from small static sites to huge webapps.
What really matters is not the dev experience for developers, but what it gives to end users. Web Components directly do nothing. Sites with 100% WC are not any better for end users, and without extra care taken, they can even be worse for clients without JS.
Performance of React on low-end devices is a real noticeable problem for a large number of people, but WC made people in charge dismiss React as a wrong direction, instead of providing features to improve React. React + WC does nothing useful, just shifts internal abstractions around without doing much, and the best argument for doing so is that is that it’s not impossible.
It really is lost, because so much time effort and focus has been spent on convincing people to use WC instead of existing solutions, largely failing, and it’s been taking focus away from solving real problems, not the problem that devs largely don’t care about WC.
React directly does nothing either. You aren’t actually making the argument that WC’s are bad. If anything it sounds more like you are arguing that javascript is bad.
WCs aren’t bad per se, just not useful compared to the effort and time it took to create them. What’s bad about this is that resources have been wasted on addressing problems that Dojo and YUI frameworks had, long after they became irrelevant.
React does a thing for users — adds overhead :)
But React represents a novel less stateful way of managing complex UI state, which is very attractive to developers, and evidently devs don’t want to give it up, despite the perf cost. Browser vendors should have noticed this trend and helped to make it work better, instead of just “React bad! Use WC!”, where WC isn’t even solving the same problem!
DOM is very stateful, and DOM+WC does not change that. It’s still the old mutable DOM model. So I’m lamenting that we’ve just got more of the same old mutable stateful DOM that a lot of devs have rejected as a poor model, and we’ve got nothing to make React faster or to offer a real native replacement for it.
I’m probably not hanging out in the right places to hear browser vendors saying “React bad! Use WC!”. So I can’t really comment usefully on that. I’ll have to take your word for it.
All I’m saying is that I’m glad WC exists and that I can use it because I’m in the exact camp that doesn’t want or need React or any of it’s compatriots. I also have a real problem with browser vendors catering to a framework’s way of working. That smacks a little too much of picking framework winners and losers.
But why do web components help you? I think that’s what I’m not getting here. What can you achieve with web components that you couldn’t achieve with a bit of Javascript and, say, the new scoped CSS features?
They arguably make it easier to package up a bit of UI with a custom look and custom behaviour. Could I do it with pure javascript? Yes. Would it be easier, simpler, and better? No.
But how does it do that? From the perspective of “I have written a logical block of UI, and want other people to be able to import this into their code”, what are the material advantages that I have with web components that I don’t have with, say, jQuery plugins, or just bundling it as a standard JS library?
As far as I can tell, your users can write <my-dropdown> instead of something like <div data-my-dropdown> like in the good old days, but that sort of light syntax sugar feels like a minimal advantage in comparison to the added complexity of the specification.
Web Components offer better encapsulation primitives than plain javascript. That encapsulation is enforced by the browser without javascript. No javascript can accidentally or deliberately clobber my custom element internals.
I don’t have to manage calling lifecycle hooks by myself. The browser calls them at the appropriate times. I only have to worry about handling them if necessary.
I don’t have to query the dom to find elements to run my wiring and lifting code against.
It does all the above without requiring a framework or helper library. I get to offload a bunch of glue code onto the browser instead of writing it myself. It does a much better job of separating concerns than hand coding it. It does all of this without conflicting with any javascript library or framework I might want to use now or in the future.
It’s not super obvious in the post, but python and the rest of the build dependencies are not being used in the final stage, thus they won’t contribute to the final image size.
Good article, but the actual problem is easily solvable by wrapping the <input> with <label></label>, which has long been the recommended way of representing radio buttons/checkboxes in HTML.
You wouldn’t need id/for attributes in that case (but you can leave them if you wish), and you wouldn’t need to resort to the padding “hack”. I say “hack” because the gap, that was initially used is the intended approach for this use case. The problem with padding is that it is a directional property, so if you ever need to switch writing direction (which is rare but not as uncommon as assumed by most devs) you would have issues you wouldn’t if you left gap.
What is the draw for this? The manifesto reads more like a rant, and the roadmap mainly consists of deletions. I find it really uninviting, but I’m not making a medical device…
The major downfall of Qt came with chasing the phone market. That lead to shitty products like QML and using JavaScript so kids that never went to college could write phone applications.
That last bit is unhinged, and I’m not a JS fan by any definition.
The whole thing has a reactionary “old man yells at cloud” vibes.
Oh hey I think they’re talking about me!
I wish I could write Qt apps in JS but you need a non-zero amount of c++ and I do not trust myself to do that safely lol. If only there were good bindings for any language other than python…
would they prefer that I just write electron and capacitor apps? because that’s the only realistic alternative to Qt atp
So you can set the ELF interpreter field to be a relative path, but it doesn’t really… work properly. Linux will resolve the path relative to the current working directory, not relative to the binary itself (at least, that’s what it looks like from my testing). Really unfortunate because if the path was relative to the binary itself, this whole setup would’ve been much simpler
One nice side effect of using userland exec though is that I can do whatever custom code I want to resolve the paths. For Brioche, I made it search several layers up the filesystem to find the “resource dir”, where it can then resolve the interpreter and binary paths. This makes it so you can move a wrapper binary around the filesystem and it’ll still run as long as the resource dir is somewhere up in the path (meaning you can move output/bin/curl to output/curl and it’ll still work, but move it outside of output and it won’t). Cargo was actually the biggest pain point here, because build.rs and proc macros get built, renamed, and run during a build! Getting everything to line up properly took a lot of attempts
The kernel itself doesn’t support it when resolving the dynamic interpreter path sadly. The ld-linux.so interpreter itself does support $ORIGIN for resolving relative rpaths (or more pedantically, the implementation of ld-linux.so provided by glibc supports it– and I’m pretty sure musl’s does too), but that’s all userspace
Well, illumos doesn’t support binaries that don’t link with the system provided ld.so.1 and libc.so.1 and so on. We don’t have a stable system call layer. But, we are ruthlessly backwards compatible above that, so it’s pretty trivial to produce a binary that will work on a particular illumos system, and then all illumos systems with the same or later version of those bits.
Don’t forget @executable_path on Mac! Talking about how deficient the dynamic linker is in Linux world is going to make me go on a symbol namespacing rant, so I’ll stop here.
You can do it with a little shim in the binary which locates and loads the ELF interpreter (similar to a userland exec, but loading the interpreter in userland rather loading the program in userland), which is what set_relative_interp at the end of https://www.corsix.org/content/for-want-of-a-relative-path does.
That post and the polyfill-glibc project both completely flew under my radar! (it sounds like it’s a very similar approach? the wrapper in TFA also userland-execs the interpreter which then execs the binary)
I’d be curious to hear more about how set_relative_interp works too, very neat to see that it avoids having a separate wrapper binary! What happens to the original binary, does it like override the entrypoint, or pack it then unpack it at runtime?
For set_relative_interp, the existing PT_INTERP is removed, and the space freed up by doing so allows adding a new PT_LOAD, the contents of which is this executable code and this data. Said code is set as the new entry point for the ELF file, and performs the task of locating and loading the interpreter and then jumping into the interpreter as if the kernel had loaded it.
Your glibc / ELF hacking is really cool! I kind of want to find a reason to use it, but I fear that any reason would entail a bunch of pain. What was your motivation for creating it? I can imagine a few (a fleet of heterogeneous boxes with various crusty enterprise linux distributions? closed-source software? unmanageable version skew between dev workstations and production?) but most of them are bad situations to be in!
Ahh, I think that would definitely be doable, especially if you just like included patchelf along with the binary or something. I think it’d be easier to set that up and should give the same result, although I feel that using userland exec still has less less moving parts overall (should still work on read-only filesystems, should work with suid binaries (I think?), can losslessly get the original binary back out)
The summary doesn’t give any indication what this is or why I should care. The landing page doesn’t indicate what it is and just refuses to do anything without disabling various protections in your browser. This feels like it should be a link to something that explains what it is, how it works, why we should care and THAT should include a link to whatever this is meant to be.
The landing page does indicate what it is if your browser is compatible. If your browser isn’t compatible, it gives you a button to watch a video version of the experience.
Just enable popups for lyra.horse and enjoy. It’s a 4 minute, multimedia, interactive, animated art presentation with music, animated lyrics, animated cartoon characters, popup windows flying around, a popup running an interactive “microsoft paint” program, and much more. It’s amusing and it uses the features of a web browser in creative ways you won’t see in any other web site.
This experience requires pop-ups to work properly.
Please enable pop-ups or check out the video version instead.
linking to a video version that you can watch instead, should you prefer to not allow pop-ups on the site.
To be fair, the lobsters post summary could’ve added a bit more context, on the homepage for example I link to Antonymph with “an audiovisual web experience that uses your browser as the medium”.
The landing page doesn’t indicate what it is and just refuses to do anything without disabling various protections in your browser.
For me, with JavaScript disabled, the submission is a page that has text briefly visible but then quickly covered(?) in all black. I can see that the text contains links, but the text disappears too quickly for me to read it or click the links. (I don’t know whether this is more or less than what you saw.)
On Android, we’ve had RecyclerView for almost a decade now. A simple built-in way to have virtualized lists for items of unknown size, fully accessible and even supporting scrollbars with section markers.
At the same time, the web still has no usable solution for this issue. I’ve worked on multiple messenger webapps that build a chat message timeline in react. Most libraries require you to know how tall each item is, which is obviously impossible with chat messages of unknown length. And most libraries can’t handle smooth scrolling either.
So what’s the solution? I’ll likely have to build yet another implementation of a messenger in react soon, and I seriously dread building something that’d be 10 LOC on Android.
I use either org.upscayl.Upscayl or com.github.nihui.waifu2x-ncnn-vulkan off Flathub, depending on the use-case… both with Flatseal-customized sandboxing.
(Aside from a general preference to cut down filesystem access as much as possible, I have a policy that applications may not simultaneously have access to the network and to areas of the filesystem shared with other applications.)
This idea reminds me of my statistical genetics days. There’s an (in)famous piece of software, PLINK, which is just gobsmackingly fast. It achieves this by “compressing” genotypes into two-bits. The high school understanding of genetics as AA, Aa, aA, aa, can roughly be made to work even with modern sequencing datasets. Usually you can’t tell Aa from aA so you really just have AA, aA, aa (hom-ref, het, hom-alt). You can clearly stuff that into two bits: 00, 01, and 10. We can repurpose 11 for “no data” or N/A.
Now that you’ve got 32 genotypes per u64, you can start implementing all sorts of operations very quickly. Mean genotype? You can compute that with a couple masks and pop counts, followed by one division. Count of homozygous alternates? Masks and pop counts. Correlation between two genomic positions? I bet PLINK even has a linear least squares implementation written in terms of bitfiddles.
The trouble is PLINK is a special purpose binary tool. What I actually want is a library of tools for working with compressed arrays so I can use these ideas to build new tools. I hope Vortex becomes such a toolkit.
There is the BitArray in Julia, which is supposed to work directly with the underlying bits as bools, but abstracting that away so you can write code as if it was a normal array. I can’t vouch for how well optimized the code is in practice though.
As a warning, in C++ there’s a specialization for
std::vector<bool>that does something similar but breaks many of the assumptions that you expect to be true from a genericstd::vector<T>. The major one: It isn’t necessarily stored in a contiguous array, whereas the generic version is. This means that you can’t really take the address of a start and end element to a function that expects them to be contiguous, among other things. It was more than a decade ago that I ran into these kinds of issues (before I’d learned to very carefully read cppreference.com all the time) but it was definitely surprising to learn about, even just to learn that there was a specialization for it.The addressing problem is not from a non-contiguous array, it’s from being a bitset and the obvious impossibility of addressing individual bits. As a result indexing into a
vector<bool>returns a proxy object which breaks all kinds of assumptions about the interaction between vector and its T.Having a separate dedicated bitset causes none of the issues, because people don’t expect it to behave exactly like an array, and more importantly can not use it in generic contexts.
time for fractional addresses :P
Yeah, I wish they’d made it a separate type in C++ to make it clear that you can’t expect it to behave the same as the generic version. It’s a tricky design issue because lots of stuff does work the same, like iterating over it or accessing elements by index but then other parts… don’t.
Those concerns don’t apply to the Julia implementation. It uses a contiguous array and folks don’t use vector memory addresses directly anyway.
For genetic data, the work for other kinds of packed arrays is already done by the BioJulia team here.
I think their code is flexible enough that you could define a new alphabet for a different domain and still use the optimised implementations for LongSequence.
I abandoned Apple back in 2020. It was when they did the whole csam thing. I do have a Mac at work, which is better than Windows, but I always make it a point. Never to update until the next year for any given OS. So if I were to do the new one it would be in June or July. This seems to avoid a lot of the problems. On my from theater PC. I use Debian. Even though x windows may seem old, the KDE and experience” just works “. I don’t have any raise many problems as in Windows, or OSX. Just a zoom and or web browsing machine. It’s the best machine I’ve ever had.
I’m curious about why that was a problem for you?
I didn’t like the fact that they would be scanning my pictures. Even though I don’t have any such material in my library, guilty until proven innocent simply goes against my ethos.
They were only scanning files that would be uploaded to iCloud and this was before advanced data protection was introduced so icloud could’ve scanned them anyway
Forcing a little robot in my computer making sure I’m behaving the way it wants seems like a violation of the third amendment.
Why is it not a problem for you?
This breaks with non-sRGB colors like oklch(70.15% 0.352 328.24)
Added an appendix. Good catch!
https://www.nmattia.com/posts/2025-01-29-shader-css-properties/#appendix
ohhh it does indeed!
let me see how else it breaks
As always, Hi everyone! I’m the author and I’m returning from my lobste.rs slumber to hang around this page :)
Don’t use pixelation for redaction. https://bishopfox.com/blog/unredacter-tool-never-pixelation
I would be curious to see if someone can unredact this. This is especially obvious in the QR code: the pixels are of random size and position. Its not a simple pixilation function, and therefore the guessing process would need to be highly fault tolerant. I wouldn’t be surprised if a sufficiently motivated attacker could narrow it down and then do a dictionary attack from that, but there’s no point. The only things I censored was:
If you’re up to it, I bet it would be a fun challenge. I’ll give you a hint: The censored username is an english word, followed by 4 digits.
Returning to this, I’ve just realized I wrote “The username to an account I’ve transacted on”. I meant to write “I haven’t transacted on”
Nice article. Thanks for sharing. It’s interesting to see the entire lack of JS in the implementation. I’ve been meaning to step up my game in that regard, so this site might be a good reference. Also funny to see the heavy use of PGP (that feels like the strongest evidence that the operator is German).
Oh, and what a banger of an opening. I can’t keep up with all the stupid shit he’s promised. I was totally unaware of this one.
Yeah, I’ve been long interested in the things that can be achieved without JavaScript, and lately I’ve been ecstatic to see the developments in HTML and CSS that should bring us closer to this reality. I wasn’t expecting the thought leaders in this area to be the markets, but in hindsight I’m not surprised! I’m sure the craft has been honed over many years out of necessity.
And a couple “tutorials”:
I highly recommend visiting Dread (wikipedia link - a reddit clone). Their anti-DDOS & CAPTCHAs are the most impressive no-JS ones I remember and are source available (no license AFAICT, no recent updates).
It’s also a good starting point to find other websites to visit.
PGP is very prevalent on the dark web, I don’t think it’s any indication of anyone’s nationality.
I’ve never seen a dark web marketplace that doesn’t exclusively and heavily rely on PGP!
I also like to see what people have done without JavaScript. The trick seems to mostly be chunked transfers and good old form submissions.
Last year, I made a snake game that ran in browsers without JavaScript using these techniques (no longer online). But I was disappointed that the only browsers that supported incremental rendering for chunked transfers were Chrome, Firefox, etc. I had hoped to be able to play it in Dillo, Netsurf, or maybe even a terminal browser.
You forgot to censor in https://boehs.org/assets/Pasted%20image%2020241114113418.png
You have a keen eye! I think its alright though, like I said I don’t care much for censoring URLs. We will call that one an easter egg :)
Really off-topic, but I wanted to appreciate your ascii art animation after stumbling into
/locations/expecting to see a linkedin page based on the link text.I do have a LinkedIn, but I find little need to promote it — every time I log in I’m inundated with infinite grift and automated recruiter advertisements for mid jobs! My current job actually came from my site, I think it speaks much more to my talents than anything I could put on LinkedIn. I hope it continues to provide opportunities from the right people :)
Anyway, glad you liked the animation, I’m quite a fan myself :)
The issue this post is talking about, storing the key in plain text, is something people have been posting about for over 6 years1. Signal has just ignored the problem until this Twitter thread. On top of that, as the article is pointing out, this only plugged the hole on macOS. Windows and Linux are still vulnerable to any script running as the current user.
This isn’t some nuanced issue. This isn’t something no one noticed until now. The tldr is that if you’re concerned about security you shouldn’t use Signal on the desktop. Its security has always been extremely, comically, unserious.
I agree, Signal Desktop is best avoided. It doesn’t meet Signal Mobile’s security standards.
Just the fact that it’s an Electron app makes it much harder to secure against untrusted data and potential data exfiltration… which happened in 2018 via an XSS vulnerability allowing a received message to execute JS on your client (demo video on Twitter), and the fix didn’t catch all cases so there was a followup CVE.
You could also argue that this weren’t a cross-platform implementation they might have used the proper tools on each platform to secure the key (e.g. keychain on macOS) from the get go.
Honestly, the biggest yikes here is Signal’s president still downplaying this: https://x.com/mer__edith/status/1810645893714002039
What definition of “full access to your device” could possibly apply here? If I installed a malicious iOS app on my iPhone and it could exfiltrate all my Signal messages, would that get the same response? If not, why?
If someone discovered a Chrome vulnerability that allowed a website to silently read your filesystem from JS and the Chrome team replied with “The reported issues rely on an attacker already having full access to your device” we would immediately laugh all the way to the download page of another browser.
Then this:
This was reported SIX years ago1. The PR Signal committed was opened back in MARCH2. There was nothing inflammatory about the tweet3. This is some really confidence-destroying stuff.
If the malicious iOS/Android/etc app requested permissions to be an accessibility service, and then read all your messages the next time you opened your signal app or whatever, would that be signal’s issue to resolve?
Why is it signal’s issue when you give the same permissions to other applications running on your Windows/Linux desktop (since they are the default permissions granted for any installed application)?
Sorry, I don’t understand your comment. This flaw didn’t require giving the offending code/process Accessibility permissions. Any code running totally unprivileged on the machine as the current user is all it took. No extra permissions at all.
If you gave an app screen recording permission and it used that to record your Signal conversations, there’s nothing Signal can do about that. Of course.
macOS has facilities for hiding data in one app from other apps. It has facilities for secure key storage. Signal wasn’t using any of these. It can do something about that. And it eventually did. (sort of)
You give it those permissions implicitly by running the programs. Same for almost every app on Windows and Linux.
My point is, on those devices there is nearly no granularity. At most the key store can be used, it doesn’t do anything on a system that has malicious code running however (unless you never unlock those keys ever again)
The only solution is to not have the app exist at all for Linux and Windows.
I agree with that and so I think they should not have the app exist for Linux and Windows, or maybe (this only just occurred to me and currently strikes me as genius although I might change my mind in five minutes) they should call it “Signal Hobbyist Edition” or something to hint to not to use it if you’re a journalist in a country where it might get you tortured.
This is just completely false on all modern operating systems, from integrity levels on Windows to granular permissions on macOS. There’s sandboxing and credential stores. There are superusers on Linux. It is NOT all or nothing.
If what you were saying were correct Signal wouldn’t have been able to fix it.
I want to point out that both times I said that I wasn’t talking about macos.
Feel free to try and take a screenshot of the Signal app using any screenshot tool on Windows, it will work.
Further, setting aside that Signal doesn’t use integrity, and other things like, caches compiled code in a user writable AppData folder. It doesn’t matter if the malicious program asks for elevated permissions to install itself like the vast majority of programs do when installing themselves.
If you stick to Windows S mode, then yeah, you’ll be safe. Everything will be sandboxed. You also will not be able to run Signal. It doesn’t support S mode. By the time you have Signal installed, you are already past the point of opening the elevated permissions hatch for applications you think you can trust.
I already mentioned key stores.
Sandboxing on Linux doesn’t work for Signal as a security mechanism. Signal insists on having access to X11, which in turn, means that any other application that also uses X11, can control / record Signal’s GUI at any time. Further, there is only unofficial sandboxing setups for Signal, none of them are supported by Signal in any form.
Please do not run Signal as root.
On Windows/Linux, they only fixed key storage while the application is unloaded. That only results in not being able to use just arbitrary file read to get the information. If the hypothetical malicious attacker can screenshot, touch GUI, read memory, arbitrary write, etc etc. So your messages are now safer from you running a very very very misconfigured web server, but that is about it.
The article itself talks about how this fix almost changes nothing for an attacker.
Windows/Linux’s per-app security is practically non-existent and in the areas that are existent, only used by Microsoft/nearly-no-one-on-linux. It can not be compared to what iOS/Android/MacOS does.
It’s Signal’s issue because Signal’s mission is security and privacy to a higher degree than most apps. Most users don’t understand the extra risk of using Signal Desktop, and that’s a flaw in the mission.
Note that I’m not a Signal detractor at all, I recommend it to everyone I can and use it myself. That’s why I would like to see the desktop app improve.
When it happened to Netscape, we called it “Brown Orifice” and it was in fact a hit to the browser’s popularity, as I recall. Not a big one, though, because the other options were all really bad too.
Edit: Better explanation: https://www.kb.cert.org/vuls/id/32231/
silly idea but what if they just renamed the helper symbols per object so they don’t collide
massive bloat in the size of the compiled kernel, presumably
No
There doesn’t seem to be any way to adjust the perspective on the 3d map like there is in gmaps but maybe that’s just because it’s set to need 2 fingers to not scroll?
Works in Firefox on my Android phone.
No I mean in google maps you can push up or down with 2 fingers to change how much the map is tilted
So all those are just some config options of MapLibre. But you don’t even need to use MapLibre, it’s compatible with Leaflet, OpenLayers, etc. The majority of the work here is supplying full planet tile infrastructure, which works with various clients. The clients can then be configured freely.
Web components aren’t the future, they’re the present. I agree they aren’t at all a replacement for React-style components, but they have their place. At $dayjob I fixed a bug in our webflow site by moving our custom code into a web component so styles wouldn’t leak in, and I have a personal project where I use them because it’s stuck on an EOL framework version (sapper/svelte v2) that I don’t want to write significant new code in. I’m writing a new framework myself and it doesn’t use web components but I made https://www.npmjs.com/package/on-connected as a nicety to use with it because there’s no other way to check if a node is connected to a document. Also, I really wish there were more unstyled ui primitives implemented as vanilla js or web components because them all being tied to a specific framework means a lot of duplicate effort is required :/
That’s still underwhelming, and the Web has lost a decade trying to find some use for a “meh” solution to minor problems that could already be solved without it.
Meantime, Chrome devs are still shaking fists at inefficiency of React and vdom, but they’ve spent a decade ignoring it and hoping it’s a fad that will go away.
I feel like when people say “the Web” they mean large heavy toolkits/frameworks like react/vue/angular. Which are certainly one part of the the web but there is also a part that enjoys and prefers more targeted bespoke solutions to problems. There should be a middle ground somwhere between use react and laboriously hand code it all from scratch.
Saying, “That’s still underwhelming” and brushing it off as if it wasn’t “real” web dev is a little dismissive. Some of us like using different tools and would prefer stuff like web components in our builds. The frameworks can and should ignore web components. They are orthogonal to the framework. That is in fact their entire point. It’s up to the user of the framework to integrate it properly in their codebase. If the framework makes that hard then tough cookies. That’s a tradeoff you made when you chose the framework.
The web didn’t “lose a decade” looking for a use for web components. You just don’t swim in the particular section of the web that uses them.
I mean the Web as a platform in general, from small static sites to huge webapps.
What really matters is not the dev experience for developers, but what it gives to end users. Web Components directly do nothing. Sites with 100% WC are not any better for end users, and without extra care taken, they can even be worse for clients without JS.
Performance of React on low-end devices is a real noticeable problem for a large number of people, but WC made people in charge dismiss React as a wrong direction, instead of providing features to improve React. React + WC does nothing useful, just shifts internal abstractions around without doing much, and the best argument for doing so is that is that it’s not impossible.
It really is lost, because so much time effort and focus has been spent on convincing people to use WC instead of existing solutions, largely failing, and it’s been taking focus away from solving real problems, not the problem that devs largely don’t care about WC.
React directly does nothing either. You aren’t actually making the argument that WC’s are bad. If anything it sounds more like you are arguing that javascript is bad.
WCs aren’t bad per se, just not useful compared to the effort and time it took to create them. What’s bad about this is that resources have been wasted on addressing problems that Dojo and YUI frameworks had, long after they became irrelevant.
React does a thing for users — adds overhead :) But React represents a novel less stateful way of managing complex UI state, which is very attractive to developers, and evidently devs don’t want to give it up, despite the perf cost. Browser vendors should have noticed this trend and helped to make it work better, instead of just “React bad! Use WC!”, where WC isn’t even solving the same problem!
DOM is very stateful, and DOM+WC does not change that. It’s still the old mutable DOM model. So I’m lamenting that we’ve just got more of the same old mutable stateful DOM that a lot of devs have rejected as a poor model, and we’ve got nothing to make React faster or to offer a real native replacement for it.
I’m probably not hanging out in the right places to hear browser vendors saying “React bad! Use WC!”. So I can’t really comment usefully on that. I’ll have to take your word for it.
All I’m saying is that I’m glad WC exists and that I can use it because I’m in the exact camp that doesn’t want or need React or any of it’s compatriots. I also have a real problem with browser vendors catering to a framework’s way of working. That smacks a little too much of picking framework winners and losers.
But why do web components help you? I think that’s what I’m not getting here. What can you achieve with web components that you couldn’t achieve with a bit of Javascript and, say, the new scoped CSS features?
They arguably make it easier to package up a bit of UI with a custom look and custom behaviour. Could I do it with pure javascript? Yes. Would it be easier, simpler, and better? No.
But how does it do that? From the perspective of “I have written a logical block of UI, and want other people to be able to import this into their code”, what are the material advantages that I have with web components that I don’t have with, say, jQuery plugins, or just bundling it as a standard JS library?
As far as I can tell, your users can write
<my-dropdown>instead of something like<div data-my-dropdown>like in the good old days, but that sort of light syntax sugar feels like a minimal advantage in comparison to the added complexity of the specification.It does all the above without requiring a framework or helper library. I get to offload a bunch of glue code onto the browser instead of writing it myself. It does a much better job of separating concerns than hand coding it. It does all of this without conflicting with any javascript library or framework I might want to use now or in the future.
Can you make it even smaller by not installing python3? Is python3 a requirement for npm install?
Python3 is needed for node-gyp iirc, which is needed if you’re building native libraries
Yes, but only building nor running right?
It’s not super obvious in the post, but python and the rest of the build dependencies are not being used in the final stage, thus they won’t contribute to the final image size.
You can see the final Dockerfile in the linked repo.
Yep
Good article, but the actual problem is easily solvable by wrapping the
<input>with<label></label>, which has long been the recommended way of representing radio buttons/checkboxes in HTML.You wouldn’t need
id/forattributes in that case (but you can leave them if you wish), and you wouldn’t need to resort to the padding “hack”. I say “hack” because thegap, that was initially used is the intended approach for this use case. The problem with padding is that it is a directional property, so if you ever need to switch writing direction (which is rare but not as uncommon as assumed by most devs) you would have issues you wouldn’t if you leftgap.You can use padding-inline-start to avoid directionality issues!
What is the draw for this? The manifesto reads more like a rant, and the roadmap mainly consists of deletions. I find it really uninviting, but I’m not making a medical device…
That last bit is unhinged, and I’m not a JS fan by any definition.
The whole thing has a reactionary “old man yells at cloud” vibes.
Everyone knows that only adults who want to college can write good software.
Oh hey I think they’re talking about me! I wish I could write Qt apps in JS but you need a non-zero amount of c++ and I do not trust myself to do that safely lol. If only there were good bindings for any language other than python… would they prefer that I just write electron and capacitor apps? because that’s the only realistic alternative to Qt atp
wouldn’t patching the interpreter field in the elf file be easier than userland exec?
So you can set the ELF interpreter field to be a relative path, but it doesn’t really… work properly. Linux will resolve the path relative to the current working directory, not relative to the binary itself (at least, that’s what it looks like from my testing). Really unfortunate because if the path was relative to the binary itself, this whole setup would’ve been much simpler
One nice side effect of using userland exec though is that I can do whatever custom code I want to resolve the paths. For Brioche, I made it search several layers up the filesystem to find the “resource dir”, where it can then resolve the interpreter and binary paths. This makes it so you can move a wrapper binary around the filesystem and it’ll still run as long as the resource dir is somewhere up in the path (meaning you can move
output/bin/curltooutput/curland it’ll still work, but move it outside ofoutputand it won’t). Cargo was actually the biggest pain point here, becausebuild.rsand proc macros get built, renamed, and run during a build! Getting everything to line up properly took a lot of attemptsDoes Linux not have the
$ORIGINtoken, which expands to the directory housing the binary?The kernel itself doesn’t support it when resolving the dynamic interpreter path sadly. The
ld-linux.sointerpreter itself does support$ORIGINfor resolving relative rpaths (or more pedantically, the implementation ofld-linux.soprovided by glibc supports it– and I’m pretty sure musl’s does too), but that’s all userspaceOh wait this is something Illumos supports? now I’m jealous…
Well, illumos doesn’t support binaries that don’t link with the system provided ld.so.1 and libc.so.1 and so on. We don’t have a stable system call layer. But, we are ruthlessly backwards compatible above that, so it’s pretty trivial to produce a binary that will work on a particular illumos system, and then all illumos systems with the same or later version of those bits.
Don’t forget
@executable_pathon Mac! Talking about how deficient the dynamic linker is in Linux world is going to make me go on a symbol namespacing rant, so I’ll stop here.I meant like could you have a shim that rewrites the binary relative to itself and execs it
You can do it with a little shim in the binary which locates and loads the ELF interpreter (similar to a userland exec, but loading the interpreter in userland rather loading the program in userland), which is what
set_relative_interpat the end of https://www.corsix.org/content/for-want-of-a-relative-path does.That post and the
polyfill-glibcproject both completely flew under my radar! (it sounds like it’s a very similar approach? the wrapper in TFA also userland-execs the interpreter which then execs the binary)I’d be curious to hear more about how
set_relative_interpworks too, very neat to see that it avoids having a separate wrapper binary! What happens to the original binary, does it like override the entrypoint, or pack it then unpack it at runtime?For
set_relative_interp, the existing PT_INTERP is removed, and the space freed up by doing so allows adding a new PT_LOAD, the contents of which is this executable code and this data. Said code is set as the new entry point for the ELF file, and performs the task of locating and loading the interpreter and then jumping into the interpreter as if the kernel had loaded it.Your glibc / ELF hacking is really cool! I kind of want to find a reason to use it, but I fear that any reason would entail a bunch of pain. What was your motivation for creating it? I can imagine a few (a fleet of heterogeneous boxes with various crusty enterprise linux distributions? closed-source software? unmanageable version skew between dev workstations and production?) but most of them are bad situations to be in!
It has been a pain point for me in multiple previous jobs, having hit all three of your imagined scenarios.
Ahh, I think that would definitely be doable, especially if you just like included
patchelfalong with the binary or something. I think it’d be easier to set that up and should give the same result, although I feel that using userland exec still has less less moving parts overall (should still work on read-only filesystems, should work with suid binaries (I think?), can losslessly get the original binary back out)The summary doesn’t give any indication what this is or why I should care. The landing page doesn’t indicate what it is and just refuses to do anything without disabling various protections in your browser. This feels like it should be a link to something that explains what it is, how it works, why we should care and THAT should include a link to whatever this is meant to be.
The landing page does indicate what it is if your browser is compatible. If your browser isn’t compatible, it gives you a button to watch a video version of the experience.
Just enable popups for lyra.horse and enjoy. It’s a 4 minute, multimedia, interactive, animated art presentation with music, animated lyrics, animated cartoon characters, popup windows flying around, a popup running an interactive “microsoft paint” program, and much more. It’s amusing and it uses the features of a web browser in creative ways you won’t see in any other web site.
The landing page states:
linking to a video version that you can watch instead, should you prefer to not allow pop-ups on the site.
To be fair, the lobsters post summary could’ve added a bit more context, on the homepage for example I link to Antonymph with “an audiovisual web experience that uses your browser as the medium”.
yeahhhhh I didn’t realize there was canonical text and I didn’t want to editorialize
added that to the title
The page links a video you can watch instead: https://www.youtube.com/watch?v=RGMaINyM0ek
That’s the route I chose, and I it’s still worth your time IMO.
It’s basically a music “video” that uses browser features in interesting/unconventional ways
For me, with JavaScript disabled, the submission is a page that has text briefly visible but then quickly covered(?) in all black. I can see that the text contains links, but the text disappears too quickly for me to read it or click the links. (I don’t know whether this is more or less than what you saw.)
On Android, we’ve had RecyclerView for almost a decade now. A simple built-in way to have virtualized lists for items of unknown size, fully accessible and even supporting scrollbars with section markers.
At the same time, the web still has no usable solution for this issue. I’ve worked on multiple messenger webapps that build a chat message timeline in react. Most libraries require you to know how tall each item is, which is obviously impossible with chat messages of unknown length. And most libraries can’t handle smooth scrolling either.
So what’s the solution? I’ll likely have to build yet another implementation of a messenger in react soon, and I seriously dread building something that’d be 10 LOC on Android.
yeah we really need recyclerview for the web :/
woah i’m on tv!
😅
oh, neat!!!!
I run Signal without a phone (no, this is not a supported configuration), so I don’t hit this problem, but I’m sure this will help other people
How do you do that? signal-cli or the signal in an android container/emulator or what?
the second one. initial setup was challenging and a working phone number was still required.
I would only recommend this to people who are highly confident in their ability to 1) not lose it; 2) not have it stolen.
what if the server returned a timestamp for when the db read completed so the client could ignore responses if they already had a fresher version?
You should write a TLA+ model or something and see if it affects correctness.
sorry I don’t speak formal methods 💔
I’ve been using https://unlimited.waifu2x.net/
I use either
org.upscayl.Upscaylorcom.github.nihui.waifu2x-ncnn-vulkanoff Flathub, depending on the use-case… both with Flatseal-customized sandboxing.(Aside from a general preference to cut down filesystem access as much as possible, I have a policy that applications may not simultaneously have access to the network and to areas of the filesystem shared with other applications.)