Yeah, the Midwest is cursed for this reason. Humid summers with incredibly high RH for being inland while temperatures push 100° F followed by bone-chillingly dry winters with temperatures falling to -20° F (and relatively little relative/absolute moisture). But all our homes are built of wood and the consequences are pretty drastic.
The (compromised) Linux decides whether to load the “compromised mode” code or the mp1 secure system? Sounds like an avenue to explore. It says the bootloader itself is secure, but that doesn’t mean much if it’s being loaded into a compromised environment, depending on where it is actually being executed. I guess the coprocessor could be considered a Secure Enclave of
Sorts, but the fact that Linux could load a separate bootloader and run that (somehow) is of concern.
No, it cannot load a separate bootloader. I tried to tamper with the loadercode (the "secure" bootloader), but it wouldn't boot. So I am guessing there is some third party (boot ROM) that verifies it.
Also, I think Linux always loads loadercode + mp1.img, regardless of the tamper state. The different code paths depending on tamper state are taken within the (integrity protected) loadercode.
Keep in mind that no tamper mode will be set if you use the external debug interface. If Linux is used for networking then maybe you could MITM payments.
The card details and payment are encrypted and then signed by the firmware running in the secure/trusted zone, using public keys provided by the acquirer.
Seems somewhat niche due to physics. When you are ten feet away from a screen (or even three), you can scarcely distinguish between audio emanating from the upper-left “pixel/voxel” (to give a new meaning to an old word) and from the bottom-right, let alone from two adjacent locations.
I think you're trying to make an argument similar to those arguing against "retina" displays, i.e. there is some minimum perceptual angular resolution for sound, so information finer than that is pointless? I think you're either underestimating the perceptual resolution or assuming a very small screen at a large distance.
I think that kind of resolution is good enough to overlap a lot of task focused screen fields of view. I have experienced a pretty clear "central" sound stage within 30-45 degrees or so with regular stereo speakers. That field can imply a lot of subtle positioning within it, not even considering wild panning mixes. I'm talking about the kind of realistic recording where it feels like a band in front of you with different instruments near each other but not colocated, like an acoustic ensemble. Obviously you cannot shrink this down to a phone at arm's length or a small embedded control screen and still have the same amount of spatial resolution crammed into a very narrow field.
When I sit with a 14" laptop at a normal distance for typing, it is also easy to distinguish tapping sounds along the screen. I just did a blind test by closing my eyes and having my wife tap the screen with a plastic pen. The interesting question to me, though, is whether that is just perception via the binaural sense, or really incorporating some intuition about the screen's structure. It's response to a tap does clearly vary by distance from bezels and hinges...
Impressed that you took the time to run a quick test. Spatial compression is a hard problem though, the most expensive sound bars are easily beat by a cheap 2.1 setup. Phones are (mostly) still mono output even though a speaker out the top and bottom (perpendicular to the viewing angle) would be a win for watching videos in landscape, probably because the improvement wouldn’t be noticeably appreciated (enough to be economically feasible, anyway).
Not niche at all. You could have a phone for example that plays sounds from areas of the screen where they originate. Key presses, buttons, notification pop ups, etc.
You missed (or didn't address, at any rate) my point. For a phone where all audio channels are in between both ears (or even worse, held off to the right/left of both ears) with only a minute difference in the angle of the arc to each of the binaural inputs, convince me that you can reasonably distinguish between sounds emanating from different locations (facing the same direction - not at all like a speaker pointing out the side of each phone!!) at a rate statistically distinguishable from chance.
With enough speakers coupled on the order of the wavelength of the sound (and for most frequencies, these seem like they will be), you can use beamforming to aim different sounds in different directions from a single source, with speakers facing in only one direction.
For an extreme example of this, refer to the Sphere, where they can target sounds at individual audience members from any arbitrary direction using speakers in the surround display.
OP, since you're here in the comments can you talk about the binary and memory size and sandboxing support? Ability to import and export functions/variables across runtime boundaries? Is this a feasible replacement for Lua scripting in a rust application?
The engine is written with a fair bit of feature flags to disable more complicated or annoying JS features if the embedder so wants: it is my aim that this would go quite deep and enable building a very slim, simple, and easily self-optimising JS engine through this.
That could then perhaps truly serve as an easy and fast scripting engine for embedding use cases.
I see you use Cargo feature for this. One thing to be aware of is Cargo's feature unification (https://doc.rust-lang.org/cargo/reference/features.html#feat...), ie. if an application embeds crate A that depends on nova_vm with all features and crate B that depends on nova_vm without any security-sensitive features like shared-array-buffer (eg. because it runs highly untrusted Javascript), then interpreters spawned by crate B will still have all features enabled.
Is there an other way crate B can tell the interpreter not to enable these features for the interpreters it spawns itself?
Nice catch, thanks for pointing that out! This also might be less than ideal if it’s the only option (rather than in addition to a runtime startup flag or a per-entrypoint/execution flag) because one could feasibly want to bundle the engine with the app with features x, y, and z enabled but only allow some scripts to execute with a subset thereof while running different scripts with a different subset.
Thank you for pointing this out, I'll have to look into this at some point.
There is currently no other way to disable features, and at least for the foreseeable future I don't plan on adding runtime flags for these things. I'm hoping to use the feature flags for optimisations (eg. no need to check for holes, getters, prototype chain in Array indexed operations if those are turned off) and I'm a bit leery of making those kinds of optimisations if the feature flags are runtime-controllable. It sounds like a possible safety hole.
For now I'll probably have to just warn (potential) users about this.
That answers half my question (eg disable networking), thank you. The other part was about the overhead of adding this to an app (startup memory usage and increase in binary size) and how much work has been done on interop so that you can execute a static rust function Foo() passing in a rust singleton Bar, or accessing properties or methods on a rust singleton Baz, i.e. calling whitelisted rust code from within the JS env (vice-versa is important but that’s possible by default simply by hard-coding a JS snippet to execute, though marshaling the return value of a JS function without (manually) using JSON at the boundary is also a nice QOL uplift).
So for executing static Rust functions we do have "full" support via the `Value::BuiltinFunction` type. We have an internal "BuiltinFunctionBuilder" type for creating these conveniently (mostly) at compile time, and we have some external helper functions for creating them at runtime.
As for calling methods on a Rust singleton / struct, that is not yet really supported. We do have a `Value::EmbedderObject` type that will be the place for these, but its implementation is so far entirely empty / todo!() only. The first step for those will be just a very plain and simple `Box<dyn ObjectMethods>` type of thing, but eventually I'm thinking that our EmbedderObjects would actually become backed by an ECS data storage in the engine heap. So eg. your Bar type would be registered to the engine via some call together with its fields, and those would form an ECS "archetype". Then these items would be created by another call and would then become visible to JS code as objects, with some of their fields possibly being pointers to foreign heap data etc.
&& in a shebang isn't portable, having more than one argument in a shebang isn't portable, subshell in a shebang isn't portable, semicolon in a shebang isn't portable, basename usage isn't portable, not littering the current working directory is important (it might not even be RW, or you might not have permissions to write to it), your usage won't work with symlinks or with the script added to $PATH, caching the compiled output is a nice speedup and reduces startup costs, correct (and optimal) cache invalidation is one of the known tricky problems in CS.
Shell scripts are ugly :)
(If you didn't mean to use them in a shebang but rather as the script body, that's fine but that wouldn't be possible without the polyglot syntax and #allow abuse I posted.)
I don’t understand the value proposition of TeleMessage. Uses Signal but defeats the point of using Signal. Why not use a proper centralized chat with actual retention and encryption?
If you need your partners/bankers/salespeople/cabinet-level officials etc. to be able to converse with their clients on the E2E encrypted systems those clients already use, like WhatsApp and Signal, but maintain retention for legal or internal data-mining reasons, the only way to do that is to have a modified client, perhaps cracked or forked from an official client, that speaks the same wire protocol, but copies messages to separate storage.
Now, such a system could be set up to route those copied messages in a separately E2E-encrypted way to the client's in-house/on-prem archival systems, and have the client be responsible for implementing decryption and secure storage at rest. But it's far easier to just sell a centralized cloud-based archival/retrieval system - which must necessarily be able to decrypt messages, and thus makes for an incredibly juicy target.
Given the supply-chain risks of the provider offering the customized clients anyways, one would expect them to have a strong security focus... but it certainly seems this was not the case.
One has to wonder what type of legal requirement this satisfies.
It certainly wouldn’t hold up to the “beyond a reasonable doubt” standard for US criminal prosecution.
I’ve been exposed to “lit holds” for various document management system before and usually a third party such as Box or Microsoft can attest to the immutability of files placed under lit hold, and/or there is an audit trail to make sure the chain of custody is intact.
I wonder if it is just organizations that don't really care about anything other than brand name (signal is known as pretty good, right) and CYA.
Like it might legitimately be the case that you personally have expended more brainpower trying to understand the decision than they put into making it.
Or there might be an issue with trusting their own IT departments. With Signal they don't even have to trust Signal (haha, but they might think that you know).
There's another possibility: NSA told them to use Signal w/ TeleMessage so that NSA could see everything because they have an agreement with TeleMessage or because NSA knows about all these vulns in TeleMessage.
For example DC Police may have confidential informants who would be best to use Signal because that isn't unusual. But the people there are communicating need to retain the communication.
This is the fundamental problem that end-to-end encryption doesn’t solve, right? If the person on the other end is malicious or really dumb they can still leak your messages.
E2EE’s biggest use case is preventing the government from reading your messages. If you are messaging the government (or are in the government) then this isn’t relevant.
Most people don’t care about anonymous communication. The agendas of those who do vary.
Signal is essentially iMessage that works in Android for all intents. Supporting it lets you communicate with outside entities. Otherwise the only mechanism to do so is email, which is problematic at best.
Government and finance are required by law to archive and audit communications. Some companies do anyway to keep tabs on staff.
> Why not use a proper centralized chat with actual retention and encryption?
This is the right question to ask. It might be that such a thing doesn't quite exist in the way that the customers want (doubtful; Slack should work just fine), or more likely it might be a cultural issue (that Signal is ingrained in some of these executives' minds as _the_ secure system to use, and/or that they don't want Slack/Whatever to be the service provider for IM _and_ the service provider for retention, or that they don't want Slack/Whatever with on-prem services because they don't trust their own IT, etc.).
Obviously TeleMessage's value add is to add retention to Signal, which defeats the point of Signal. That leads me to think that the motivation is cultural.
Considering they accidentally included a journalist, compatibility with the existing user network. If you need logged chat with normal Signal users, TeleMessage would probably be the way to do this.
Only one person in the groupchat needs to be using Telemessage, ie. a CIA agent can use a government device with Telemessage to talk to sources on Signal. Signal has a great protocol & robust clients, and getting caught with Signal on your phone is probably a bit better than being caught with CIAChat on your phone.
The actual implementation here is atrocious though.
Citation needed? I remember running into no issues with VMware Workstation when I was preserving historical content from legacy OSes well over a decade ago.
This is the AirBnb format, right? They ditched it for a newer alternative; I’m not sure if this was relying on them for maintenance and development or not, but if so I’d say start looking elsewhere.
Wait, Airbnb itself stopped using (and presumably maintaining) Lottie? What are they using now?
I’m trying to find any kind of news or blog post about this and I’m coming up empty-handed.
Edit: it looks like you were referring to Lava, which is a video format, not a vector animation format. Airbnb is using Lava micro-videos now in some places where they previously used Lottie animations, but Lava appears to be more a modern approach to animated GIFs rather than Lottie’s modern approach to Flash.
reply