It hasnât been updated or used for some time, but libc_r was 20+ years old. Now itâs gone. You know someone younger than this code, or maybe even younger than the last time I talked about it.
It hasnât been updated or used for some time, but libc_r was 20+ years old. Now itâs gone. You know someone younger than this code, or maybe even younger than the last time I talked about it.
The NSA has released a security advisory warning of the dangers of TLS inspection:
Transport Layer Security Inspection (TLSI), also known as TLS break and inspect, is a security process that allows enterprises to decrypt traffic, inspect the decrypted content for threats, and then re-encrypt the traffic before it enters or leaves the network. Introducing this capability into an enterprise enhances visibility within boundary security products, but introduces new risks. These risks, while not inconsequential, do have mitigations.
[...]
The primary risk involved with TLSI's embedded CA is the potential abuse of the CA to issue unauthorized certificates trusted by the TLS clients. Abuse of a trusted CA can allow an adversary to sign malicious code to bypass host IDS/IPSs or to deploy malicious services that impersonate legitimate enterprise services to the hosts.
[...]
A further risk of introducing TLSI is that an adversary can focus their exploitation efforts on a single device where potential traffic of interest is decrypted, rather than try to exploit each location where the data is stored.Setting a policy to enforce that traffic is decrypted and inspected only as authorized, and ensuring that decrypted traffic is contained in an out-of-band, isolated segment of the network prevents unauthorized access to the decrypted traffic.
[...]
To minimize the risks described above, breaking and inspecting TLS traffic should only be conducted once within the enterprise network. Redundant TLSI, wherein a client-server traffic flow is decrypted, inspected, and re-encrypted by one forward proxy and is then forwarded to a second forward proxy for more of the same,should not be performed.Inspecting multiple times can greatly complicate diagnosing network issues with TLS traffic. Also, multi-inspection further obscures certificates when trying to ascertain whether a server should be trusted. In this case, the "outermost" proxy makes the decisions on what server certificates or CAs should be trusted and is the only location where certificate pinning can be performed.Finally, a single TLSI implementation is sufficient for detecting encrypted traffic threats; additional TLSI will have access to the same traffic. If the first TLSI implementation detected a threat, killed the session, and dropped the traffic, then additional TLSI implementations would be rendered useless since they would not even receive the dropped traffic for further inspection. Redundant TLSI increases the risk surface, provides additional opportunities for adversaries to gain unauthorized access to decrypted traffic, and offers no additional benefits.
Nothing surprising or novel. No operational information about who might be implementing these attacks. No classified information revealed.
News article.
âThe flight was extremely normal for the first thirty-six seconds and after that it got very interesting.â -Pete Conrad
The crew of Apollo 12 pose for the press prior to their mission, October 1969
Supercross in New Zealand, the Latin Grammy Awards in Las Vegas, a wee Canucks fan in Vancouver, Pope Francis in Thailand, protests in Bolivia and Chile, a new skyscraper in Beijing, the 30th anniversary of the Velvet Revolution, a massive dam in Turkey, a cat show in Italy, a cavalry pyramid in Mexico, and much more.
From Leslie Bean on Space Hipsters FB, the astronaut memorial grove is ready for the holidays and Peteâs tree is no longer the only colorful tree, now that Al Beanâs tree has joined
 |
The coil is wound with 28 AWG enameled wire on a 2 inch diameter pill bottle. 254μH is measured, which is 2.3% less than the target value 260μH. This result is more than adequate for most applications. |
Iâve made no secret of the fact that I traced over photographs to create the art for Basic Instructions. I thought it might be fun to explain what images I used to create the rare, more ambitious images, like the one in panels two and three of this strip.
The image is a composite of several different traced elements. Adobe Illustrator made it easy to hand-trace the part of an image I wanted and have that tracing isolated as a single element, which I could then easily combine with others in a sort of image sandwich.
Working from the back forward, this image consists of: a black rectangle, a tracing of NASAâs âEarthriseâ photo, a crude drawing of rolling, gray hills, the screen of an antique Philco Predicta television which I stretched at the middle to make the screen and the base pedestal wider, The Emperor of the moon cut to fit the screen, and on top, a rough tracing of Fremen warriors taken from a screengrab of a single frame from the film DUNE.
Itâs my understanding that this constitutes a âtransformative work,â and is perfectly legal. Â Luckily, even if thatâs not the case, my limited art skills renders all of the elements unrecognizable enough to not infringe copyrights.
As always, thanks for using my Amazon Affiliate links (US, UK, Canada).
âListen, Iâve got this small Pelican 1120 case with an LNR Mountain Topper rig in it. I have everything in the case to make a fast emergency contact. Letâs test it today.â This plan was hatched early in the morning ⦠Continue reading
The post A QRP Test at New Hampton Meeting House appeared first on W3ATB.
An artistic rendering of Blue Originâs future New Glenn rocket. | Image: Blue Origin
The Air Force is going to change the criteria for selecting its next round of rocket launch providers after one company competing for the gig protested the procurement process, Space News first reported. Private spaceflight company Blue Origin argued that the selection benchmarks were unfair â an argument that was upheld this week by the Government Accountability Office (GAO).
Currently, the Air Force is on the hunt for two companies to launch the USâs national security satellites from 2022 to 2026 as part of its Launch Service Procurement program. For rocket companies, being selected is a huge opportunity, as it could result in hundreds of millions to billions of dollars in launch contracts. The Air Force put out a call for proposals in...
Another BK is in the log. This year I worked ten other '29 stations. K0SM/W2ICE was worked outside of the party hours so Andy does not show up in my official BK log.
BSD New 325 has a bunch of release news this week, including FreeBSD 12.1, and as you can guess from the title, rainbow tables.
Our fascination with Alpha Centauri doubtless propels at least some of the recent interest in binary star systems, as we ponder the chances for habitable worlds around the nearest stars. But given that the population of binary or multiple star systems in our galaxy is as high as it is (multiple systems are common, and about 50 percent of stars have binary companions), determining the factors that influence habitability in this environment has much broader significance. A new study out of the Georgia Institute of Technology has been looking at the issue by modeling an Earth twin in various binary scenarios.
So how does Alpha Centauri fare? We can find habitable zones in the Centauri A/B system, and into these the researchers introduced a simulated Earth around Centauri B to examine its axis dynamics. They also investigate the dynamical evolution of planets within the habitable zone of either star, generalizing from these results to the larger binary star population. The issue to be addressed: Does the axial tilt, or obliquity, of our planet, apparently a key feature in maintaining a habitable climate, survive the transition into a binary system with the features of Alpha Centauri? The answer is not encouraging for life, at least not around Centauri B.
Image: The Alpha Centauri group is the closest star system outside of our own at a distance of 4.3 lightyears; it can be found in the night sky in the constellation Centaurus. The stars Alpha Centauri A and Alpha Centauri B comprise a binary system, in which the two stars orbit one another, and close by is an additional faint red dwarf, Alpha Centauri C, also called Proxima Centauri. Some astronomers have hoped to someday find an exoplanet capable of harboring advanced life in the system, but a new study lowers those expectations while raising them for the rest of the universe. Credit: NASA/ESA Hubble Space Telescope.
Remember that Centauri B, a K-class dwarf, and the G-class Centauri A orbit each other tightly, with an orbital period of 79.91 years. Weâre dealing with an elliptical orbit that varies the distance between the two stars anywhere from 35 AU to 11 AU, the latter being not much further than Saturn is from the Sun in our own system. From the perspective of a planet orbiting Centauri B, Centauri A swings relatively close and then backs away during the 80-year period, causing the simulated Earth to vary considerably in terms of obliquity. The Moon is often cited as a help in stabilizing Earthâs axial tilt, but that doesnât help here, says lead author Billy Quarles.
âAround Alpha Centauri B, if you donât have a moon, you have a more stable axis than if you do have a moon. If you have a moon, itâs pretty much bad news.â
From the paper:
â¦the added spin precession from a Luna-like moon increases the obliquity variation of an Earth-like planet orbiting α Cen B, but a different type of moon, in terms of its mass or semimajor axis, may have a negligible or more beneficial effect.
Image: Astrophysicist Billy Quarles, author of a new study on exoplanet axis tilt, stands with Georgia Techâs largest telescope housed at its observatory. Credit: Georgia Tech / Rob Felt.
And without a moon? Quarles again:
âThe biggest effect you would see is differences in the climate cycles related to how elongated the orbit is. Instead of having ice ages every 100,000 years like on Earth, they may come every 1 million years, be worse, and last much longer.â
The separation of the two stars is the key here. According to this work, Centauri A and B are simply too close for comfort, but a wider separation, which holds in most binary systems, would allow the second starâs effects to be less disruptive to the simulated Earth. I was curious about the effects of a moon, though, and went further into the paper, which notes that the disruptive effects of a moon on a simulated Earth around Centauri B are:
â¦in contrast to our own Earth-based expectations, where our moon does the opposite (Laskar et al. 1993b). The amount of spin precession from a moon depends on the moonâs mass and semimajor axis, where a Pluto-mass moon at a Luna-like semimajor axis aluna would have a negligible effect. A smaller semimajor axis (0.2 aluna) would allow a Pluto-mass moon to increase the spin precession and allow for larger obliquity variations. The degree to which a moon can increase the overall spin precession depends on many factors, where they are neither needed nor necessarily even desirable to obtain relatively low obliquity variations.
Image: Modeled into an orbit in the habitable zone around Alpha Centauri B, in this artistâs rendering by an author of a new study, our planet appears rather icy and inhospitable to advanced life. Credit: Georgia Tech / Billy Quarles.
Quarles points to Mars as an example of obliquity extremes influencing climate. The axial tilt of Mars varies between 10 and 60 degrees every 2 million years, as opposed to Earthâs axial tilt (between 22.1 and 24.5 degrees over a course of 41,000 years). Earthâs Moon stabilizes our planetâs obliquity, which would otherwise be affected by gravitational influences from the inner planets as well as Mars and Jupiter.
If the precession of Marsâ axis seems to have helped deplete its atmosphere, imagine an Earth precessing the same 60 degrees, which is the figure Quarles deduces for an Earth without its Moon. Clearly, the presence of a moon can have widely varying effects depending on the stellar masses and orbital parameters involved. We learn that the presence of a single large moon is just one factor in questions of habitability, and its effects are not always benign.
But the broader outlook for habitable zone planets in binary star systems seems encouraging. According to the study, a high percentage of such systems can support exo-Earths with axial tilts similarly steady to Earthâs, thus ensuring climate stability. Back to the paper:
We combine our results with population studies of binary stars (Raghavan et al. 2010; Moe & Di Stefano 2017) and find the chance that an Earth-like rotator orbiting the primary star would experience small (< 2.4°) obliquity variations is 87%, 74%, or 54%, depending on the mass of the primary (0.8, 1.0, or 1.2 Mâ Solar-Type stars, respectively).
All told, those arenât bad numbers given the number of multiple star systems throughout the Milky Way. The paper shows us that the evolution in axial tilt for a single Earth-like planet in the habitable zone of a binary system depends on the orbital precession induced by the companion star, while also being influenced by orbital distance, nearby terrestrial planets and moons. Itâs interesting, too, to see that many disks are misaligned by around 10 percent from the binary plane, which would produce a typical obliquity variation in the neighborhood of 20%. Clearly, orbiting nearly planar with the binary would be the most desirable place to be.
Itâs worth noting that the Transiting Exoplanet Survey Satellite (TESS) is expected to uncover â¼500,000 eclipsing binary systems. Weâll have no shortage of candidates for further study. Both TESS and Gaia observations, the authors say, would allow a more robust statistical approach to emerge as we examine the obliquity of planets around Sun-like stellar binaries.
The paper is Quarles et al., âObliquity Evolution of Circumstellar Planets in Sun-like Stellar Binaries,â Astrophysical Journal Vol. 886, No. 1 (19 November 2019). Abstract / Preprint.
NASA/Cory Huston
Early this morning, Boeing rolled its new passenger spacecraft, the CST-100 Starliner, out to the Florida launch site the vehicle is set to take off from next month. Itâs the first time that a spaceflight-ready version of the capsule has exited the hangar.
Now the capsule will be mated on top of the rocket that will take it to space â an Atlas V manufactured by the United Launch Alliance. On December 17th, the rocket and capsule are slated to take off from Cape Canaveral, Florida â without any crew members on board â and then dock with the International Space Station. If successful, this demonstration mission could pave the way for NASA astronauts to fly on the Starliner sometime next year.
This article is cross-posted on the Bytecode Alliance web site.
Multi-value is a proposed extension to core WebAssembly that enables functions to return many values, among other things. It is also a pre-requisite for Wasm interface types.
Iâve been adding multi-value support all over the place recently:
I added multi-value support to Wasmtime, the WebAssembly runtime built on top of the Cranelift code generator, so that it can run Wasm code that uses multi-value features.
Now, as my multi-value efforts are wrapping up, it seems like a good time to reflect on the experience and write up everything thatâs been required to get all this support in all these places.
In core WebAssembly, there are a couple of arity restrictions on the language:
blocks, ifs, and loops cannot consume any stack values, and may only produce zero or one resulting stack value.The multi-value proposal is an extension to the WebAssembly standard that lifts these arity restrictions. Under the new multi-value Wasm rules:
The following snippets are only valid under the new rules introduced in the multi-value Wasm proposal:
;; A function that takes an `i64` and returns
;; three `i32`s.
(func (param i64) (result i32 i32 i32)
...)
;; A loop that consumes an `i32` stack value
;; at the start of each iteration.
loop (param i32)
...
end
;; A block that produces two `i32` stack values.
block (result i32 i32)
...
end
The multi-value proposal is currently at phase 3 of the WebAssembly standardization process.
There are a few scenarios where compilers are forced to jump through hoops when producing multiple stack values for core Wasm. Workarounds include introducing temporary local variables, and using local.get and local.set instructions, because the arity restrictions on blocks mean that the values cannot be left on the stack.
Consider a scenario where we are computing two stack values: the pointer to a string in linear memory, and its length. Furthermore, imagine we are choosing between two different strings (which therefore have different pointer-and-length pairs) based on some condition. But whichever string we choose, weâre going to process the string in the same fashion, so we just want to push the pointer-and-length pair for our chosen string onto the stack, and control flow can join afterwards.
With multi-value, we can do this in a straightforward fashion:
call $compute_condition
if (result i32 i32)
call $get_first_string_pointer
call $get_first_string_length
else
call $get_second_string_pointer
call $get_second_string_length
end
This encoding is also compact: only sixteen bytes!
When weâre targeting core Wasm, and multi-value isnât available, weâre forced to pursue alternative, more convoluted forms. We can smuggle the stack values out of each if and else arm via temporary local values:
;; Introduce a pair of locals to hold the values
;; across the instruction sequence boundary.
(local $string i32)
(local $length i32)
call $compute_condition
if
call $get_first_string_pointer
local.set $string
call $get_first_string_length
local.set $length
else
call $get_second_string_pointer
local.set $string
call $get_second_string_length
local.set $length
end
;; Restore the values onto the stack, from their
;; temporaries.
local.get $string
local.get $length
This encoding requires 30 bytes, an overhead of fourteen bytes more than the ideal multi-value version. And if we were computing three values instead of two, there would be even more overhead, and the same is true for four values, etc⦠The additional overhead is proportional to how many values weâre producing in the if and else arms.
We can actually go a little smaller than that â still with core Wasm â by jumping through a different hoop. We can split this into two if ... else ... end blocks and duplicate the condition check to avoid introducing temporaries for each of the computed values themselves:
;; Introduce a local for the condition, so that
;; we only re-check it, and don't recompute it.
(local $condition i32)
;; Compute and save the condition.
call $compute_condition
local.set $condition
;; Compute the first stack value.
local.get $condition
if (result i32)
call $get_first_string_pointer
else
call $get_second_string_pointer
end
;; Compute the second stack value.
local.get $condition
if (result i32)
call $get_first_string_length
else
call $get_second_string_length
end
This gets us down to 28 bytes. Two fewer than the last version, but still an overhead of twelve bytes compared to the multi-value encoding. And the overhead is still proportional to how many values weâre computing.
Thereâs no way around it: we need multi-value to get the most compact code here.
The multi-value proposal opens up the possibility for new instructions that produce multiple values:
i32.divmod instruction of type [i32 i32] -> [i32 i32] that takes a numerator and divisor and produces both their quotient and remainder.
Arithmetic operations with an additional carry result. These could be used to better implement big ints, overflow checks, and saturating arithmetic.
Returning multiple values from functions will allow us to more efficiently return small structures like Rustâs Results. Without multi-value returns, these relatively small structs that still donât fit in a single Wasm value type get placed in linear memory temporarily. With multi-value returns, the values donât escape to linear memory, and instead stay on the stack. This can be more efficient, since Wasm stack values are generally more amenable to optimization than loads and stores from linear memory.
Shrinking code size is great, and new instructions would be fancy, but hereâs what Iâm really excited about: WebAssembly interface types. Interface types used to be called âhost bindings,â and they are the key to unlocking:
For all three use cases, we might want to return a string from a callee Wasm module. The caller that is consuming this string might be a Web browser, or it might be another Wasm module, or it might be a WASI-compatible Wasm runtime. In any case, a natural way to return the string is as two i32s:
The interface adapter can then lift that pair of i32s into an abstract string type, and then lower it into the callerâs concrete string representation on the other side. Interface types are designed such that in most cases, this lifting and lowering can be optimized into a quick memory copy from the calleeâs linear memory to the callerâs.
But before the interface adapters can do that lifting and lowering, they need access to the pointer and length pair, which means the callee Wasm function needs to return two values, which means we need multi-value Wasm for interface types.
Now that we know what multi-value Wasm is, and why itâs exciting, Iâll recount the tale of implementing support for it all over the place. I started with implementing multi-value support in the Rust and WebAssembly toolchain, and then I added support to the Wasmtime runtime, and the Cranelift code generator itâs built on top of.
What falls under the Rust and Wasm toolchain umbrella? It is a superset of the general Rust toolchain:
cargo: Manages builds and dependencies.rustc: Compiles Rust sources into code.rustc under the covers to optimize and generate code.And then additionally, when targeting Wasm, we also use a few more moving parts:
wasm-bindgen: Part library and part Wasm post-processor, wasm-bindgen generates bindings for consuming and producing interfaces defined with interface types (and much more!)walrus: A library for transforming and rewriting WebAssembly modules, used by wasm-bindgenâs post-processor.wasmparser: An event-style parser for WebAssembly binaries, used by walrus.Hereâs a summary of the toolchainâs pipeline, showing the inputs and outputs between tools:
My goal is to unlock interface types with multi-value functions. For now, I havenât been focusing on code size wins from generating multi-value blocks. For my purposes, I only need to introduce multi-value functions at the edges of the Wasm module that talk to interface adapters; I donât need to make all function bodies use the optimal multi-value instruction sequence constructs. Therefore, I decided to have wasm-bindgenâs post-processor rewrite certain functions to use multi-value returns, rather than add support in LLVM.0 With this approach I only needed to add support to the following tools:
cargorustcwasm-bindgenwalruswasmparserwasmparserwasmparser is an event-style parser for WebAssembly binaries. It may seem strange that adding toolchain support for generating multi-value Wasm began with parsing multi-value Wasm. But it is necessary to make testing easy and painless, and we needed it eventually for Wasmtime anyways, which also uses wasmparser.
In core Wasm, the optional value type result of a block, loop, or if is encoded directly in the instruction:
0x40 byte means there is no result0x7f byte means there is a single i32 result0x7e byte means there is a single i64 resultWith multi-value Wasm, there are not only zero or one resulting value types, there are also parameter types. Blocks can have the same set of types that functions can have. Functions already de-duplicate their types in the âTypeâ section of a Wasm binary and reference them via index. With multi-value, blocks do that now as well. But how does this co-exist with non-multi-value block types?
The index is encoded as a signed variable-length integer, using the LEB128 encoding. If we interpret non-multi-value blocksâ optional result value type as a signed LEB128, we get:
-64 (the smallest number that can be encoded as a single byte with signed LEB128) means there is no result-1 means there is a single i32 result-2 means there is a single i64 resultTheyâre all negative, leaving the positive numbers to be interpreted as indices into the âTypeâ section for multi-value blocks! A nice little encoding trick and bit of foresight from the WebAssembly standards folks.
Adding support for parsing these was straightforward, but wasmparser also supports validating the Wasm as it parses it. Adding validation support was a little bit more involved.
wasmparserâs validation implementation is similar to the validation algorithm presented in the appendix of the WebAssembly spec: it abstractly interprets the Wasm instructions, maintaining a stack of types, rather than a stack of values. If any operation uses operands of the wrong type â for example the stack has an f32 at its top when we are executing an i32.add instruction, and therefore expect two i32s on top of the stack â then validation fails. If there are no type errors, then it succeeds. There are some complications when dealing with stack-polymorphic instructions, like drop, but they donât really interact with multi-value.
Whenever wasmparser encounters a block, loop, or if instruction, it pushes an associated control frame, that keeps track of how deep in the stack instructions within this block can access. Before multi-value, the limit was always the length of the stack upon entering the block, because blocks didnât take any values from the stack. With multi-value, this limit becomes stack.len() - block.num_params(). When exiting a block, wasmparser pops the associated control frame. It check that the top n types on the stack match the blockâs result types, and that the stackâs length is frame.depth + n. Before multi-value, n was always either 0 or 1, but now it can be any non-negative integer.
The final bit of validation that is impacted by multi-value is when an if needs to have an else or not. In core Wasm, if the if does not produce a resulting value on the stack, it doesnât need an else arm since the whole ifâs typing is [] -> [] which is also the typing for a no-op. With multi-value this is generalized to any if where the inputs and outputs are the same types: [t*] -> [t*]. Easy to implement, but also very easy to overlook (like I originally did!)
Multi-value support was added to wasmparser in these pull requests:
walruswalrus is a WebAssembly to WebAssembly transformation library. We use it to generate glue code in wasm-bindgen and to polyfill WebAssembly features.
walrus constructs its own intermediate representation (IR) for WebAssembly. Similar to how wasmparser validates Wasm instructions, walrus also abstractly interprets the instructions while building up its IR. This meant that adding support for constructing multi-value IR to walrus was very similar to adding multi-value validation support to wasmparser. In fact, walrus also validates the Wasm while it is constructing its IR.
But multi-value has big implications for the IR itself. Before multi-value, you could view Wasmâs stack-based instructions as a post-order encoding of an expression tree.
Consider the expression (a + b) * (c - d). As an expression tree, it looks like this:
*
/ \
/ \
+ -
/ \ / \
a b c d
A post-order traversal of a tree is where a node is visited after its children. A post-order traversal of our example expression tree would be:
a b + c d - *
Assume that a, b, c, and d are Wasm locals of type i32, with the values 9, 7, 5, and 3 respectively. We can convert this post-order directly into a sequence of Wasm instructions that build up their results on the Wasm stack:
;; Instructions ;; Stack
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
local.get $a ;; [9]
local.get $b ;; [9, 7]
i32.add ;; [16]
local.get $c ;; [16, 5]
local.get $d ;; [16, 5, 3]
i32.sub ;; [16, 2]
i32.mul ;; [32]
This correspondence between trees and Wasm stack instructions made using a tree-like IR in walrus, where nodes are instructions and a nodeâs children are the instructions that produce the parentâs input values, very natural.1 Our IR used to look something like this:
pub enum Expr {
// A `local.get` instruction.
LocalGet(LocalId),
// An `i32.add` instruction.
I32Add(ExprId, ExprId),
// Etc...
}
But multi-value threw a wrench in this tree-like representation: now that an instruction can produce multiple values, when we have a parentâ¶child edge in the tree, how do we know which of the childâs resulting values the parent wants to use? And also, if two different parents are each using one of the two values an instruction generates, we fundamentally donât have a tree anymore, we have a directed, acyclic graph (DAG).
We considered generalizing our tree representation into a DAG, and labeling edges with n to represent using the nth resulting value of an instruction. We weighed the complexity of implementing this representation against what our current use cases in wasm-bindgen demand, along with any future use cases we could think of. Ultimately, we decided it wasnât worth the effort, since we donât need that level of detail for any of the transformations or manipulations that wasm-bindgen performs, or that we foresee it doing in the future.
Instead, we decided that within a block, representing instructions as a simple list is good enough for our use cases, so now our IR looks something like this:
pub struct Block(Vec);
pub enum Instr {
// A `local.get` instruction.
LocalGet(LocalId),
// An `i32.add` instruction. Note that its
// children are left implicit now.
I32Add,
// Etc...
}
Additionally, it turns out it is faster to construct and traverse this list-based representation, so switching representations in walrus also gave wasm-bindgen a nice little speed up.
The walrus support for multi-value was implemented in these pull requests:
wasm-bindgenwasm-bindgen facilitates high-level interactions between Wasm modules and their host. Often that host is a Web browser and its DOM methods, or some user-written JavaScript. Other times it is an outside-the-Web Wasm runtime, like Wasmtime, using WASI and interface types. wasm-bindgen acts as a polyfill for the interface types proposal, plus some extra batteries included for a powerful user experience.
One of wasm-bindgenâs responsibilities is translating the return value of a Wasm function into something that the host caller can understand. When using interface types directly with Wasmtime, this means generating interface adapters that lift the concrete Wasm return values into abstract interface types. When the caller is some JavaScript code on the Web, it means generating some JavaScript code to convert the Wasm values into JavaScript values.
Letâs take a look at some Rust functions and the Wasm they get compiled down into.
First, consider when we are returning a single integer from a Rust function:
// random.rs
#[no_mangle]
pub extern "C" fn get_random_int() -> i32 {
// Chosen by fair dice roll.
4
}
And here is the disassembly of that Rust code compiled to Wasm:
;; random.wasm
(func $get_random_int (result i32)
i32.const 4
)
The resulting Wasm functionâs signature is effectively identical to the Rust functionâs signature. No surprises here. It is easy for wasm-bindgen to translate the resulting Wasm value to whatever is needed because wasm-bindgen has direct access to it; itâs right there.
Now letâs look at returning compound structures from Rust that donât fit in a single Wasm value:
// pair.rs
#[no_mangle]
pub extern "C" fn make_pair(a: i32, b: i32) -> [i32; 2] {
[a, b]
}
And here is the disassembly of this new Rust code compiled to Wasm:
;; pair.wasm
(func $make_pair (param i32 i32 i32)
local.get 0
local.get 2
i32.store offset=4
local.get 0
local.get 1
i32.store
)
The signature for the make_pair function in pair.wasm doesnât look like its corresponding signature in pair.rs! It has three parameters instead of two, and it isnât returning any values, let alone a pair.
Whatâs happening is that LLVM doesnât support multi-value yet so it canât return two i32s directly from the function. Instead, callers pass in a âstruct returnâ pointer to some space that theyâve reserved for the return value, and make_pair will write its return value through that struct return pointer into the reserved space. By convention, LLVM uses the first parameter as the struct return pointer, so the second Wasm parameter is our original a parameter in Rust and the third Wasm parameter is our original b parameter in Rust. We can see that the Wasm function is writing the b field first, and then the a field second.
How is space reserved for the struct return? Distinct from the Wasm standardâs stack that instructions push values to and pop values from, LLVM emits code to maintain a âshadow stackâ in linear memory. There is a global dedicated as the stack pointer, and always points to the top of the stack. Non-leaf functions that need some scratch space of their own will decrement the stack pointer to allocate some space on entry (since the stack grows down, and its âtopâ of the stack is its lowest address) and will increment it to deallocate that space on exit. Leaf functions that donât call any other function can skip incrementing and decrementing this stack pointer, which is exactly why we didnât see make_pair messing with the stack pointer.
To verify that callers are allocating space for the return struct in the shadow stack, letâs create a function that calls make_pair and then inspect its disassembly:
// pair.rs
#[no_mangle]
pub extern "C" fn make_default_pair() -> [i32; 2] {
make_pair(42, 1337)
}
Iâve annotated default_make_pairâs disassembly below to make it clear how the shadow stack pointer is manipulated to create space for return values and how the pointer to that space is passed to make_pair:
;; pair.wasm
(func $make_default_pair (param i32)
(local i32)
;; Reserve 16 bytes of space in the shadow
;; stack. We only need 8 bytes, but LLVM keeps
;; the stack pointer 16-byte aligned. Global 0
;; is the stack pointer.
global.get 0
i32.const 16
i32.sub
local.tee 1
global.set 0
;; Get a pointer to the last 8 bytes of our
;; shadow stack space. This is our struct
;; return pointer argument, where the result
;; of `make_pair` will be written to.
local.get 1
i32.const 8
i32.add
;; Call `make_pair` with the struct return
;; pointer and our default values.
i32.const 42
i32.const 1337
call $make_pair
;; Copy the resulting pair into our own struct
;; return pointer's space. LLVM optimized this
;; into a single `i64` load and store, instead
;; of two `i32` load and stores.
local.get 0
local.get 1
i64.load offset=8
i64.store align=4
;; Restore the stack pointer to the original
;; value it had upon entering this function,
;; deallocating our shadow stack frame.
local.get 1
i32.const 16
i32.add
global.set 0
end
)
When the caller is JavaScript, wasm-bindgen can use its knowledge of these calling conventions to generate JavaScript glue code that allocates shadow stack space, calls the function with the struct return pointer argument, reads the values out of linear memory, and finally deallocates the shadow stack space before converting the Wasm values into some JavaScript value.
But when using interface types directly, rather than polyfilling them, we canât rely on generating glue code that has access to the Wasm moduleâs linear memory. First, the memory might not be exported. Second, the only glue code we have is interface adapters, not arbitrary JavaScript code. We want those values as proper return values, rather than through a side channel.
So I wrote a walrus transform in wasm-bindgen that converts functions that use a struct return pointer parameter without any actual Wasm return values, into multi-value functions that donât take a struct return pointer parameter but return multiple resulting Wasm values instead. This transform is essentially a âreverse polyfillâ for multi-value functions.
;; Before.
;;
;; First parameter is a struct return pointer. No
;; return values, as they are stored through the
;; struct return pointer.
(func $make_pair (param i32 i32 i32)
;; ...
)
;; After.
;;
;; No more struct return pointer parameter. Return
;; values are actual Wasm results.
(func $make_pair (param i32 i32) (result i32 i32)
;; ...
)
The transform is only applied to exported functions that take a struct return pointer parameter, and rather than rewriting the source function in place, the transform leaves it unmodified but removes it from the Wasm moduleâs exports list. It generates a new function that replaces the old one in the Wasm moduleâs exports list. This new function allocates shadow stack space for the return value, calls the original function, reads the values out of the shadow stack onto the Wasm value stack, and finally deallocates the shadow stack space before returning.
For our running make_pair example, the transform produces an exported wrapper function like this:
;; pair.wasm
(func $new_make_pair (param i32 i32) (result i32 i32)
;; Our struct return pointer that points to the
;; scratch space we are allocating on the shadow
;; stack for calling `$make_pair`.
(local i32)
;; Allocate space on the shadow stack for the
;; result.
global.get $shadow_stack_pointer
i32.const 8
i32.sub
local.tee 2
global.set $shadow_stack_pointer
;; Call the original `$make_pair` with our
;; allocated shadow stack space for its
;; results.
local.get 2
local.get 0
local.get 1
call $make_pair
;; Read the return values out of the shadow
;; stack and place them onto the Wasm stack.
local.get 2
i32.load
local.get 2
i32.load offset=4
;; Finally, restore the shadow stack pointer.
local.get 2
i32.const 8
i32.add
global.set $shadow_stack_pointer
)
With this transform in place, wasm-bindgen can now generate multi-value function exports along with associated interface adapters that lift the concrete Wasm return values into abstract interface types.
The multi-value support and transform were implemented in wasm-bindgen in these pull requests:
Ok, so at this point, we can generate multi-value Wasm binaries with the Rust and Wasm toolchain â woo! But now we need to be able to run these binaries.
Enter Wasmtime, the WebAssembly runtime built on top of the Cranelift code generator. Wasmtime translates WebAssembly into Craneliftâs IR with the cranelift-wasm crate, and then Cranelift compiles the IR down to native machine code.
Implementing multi-value Wasm support in Wasmtime and Cranelift roughly involved two steps:
Cranelift has its own intermediate representation that it manipulates, optimizes, and legalizes before generating machine code for the target architecture. In order for Cranelift to compile some code, you need to translate whatever youâre working with into Craneliftâs IR. In our case, that means translating Wasm into Craneliftâs IR. This process is analogous to rustc converting its mid-level intermediate representation (MIR) to LLVMâs IR.2
Craneliftâs IR is made up of (extended) basic blocks3 containing code in single, static-assignment form (SSA). SSA, as the name implies, means that variables can only be assigned to when defined, and canât ever be re-assigned:
;; `42 + 1337` in Cranelift IR
v0 = iconst.32 42
v1 = iconst.32 1337
v2 = iadd v0, v1
When translating to SSA form, most re-assignments to a variable x can be handled by defining a fresh x1 and replacing subsequent uses of x with x1, and then turning the next re-assignment into x2, etc. But that doesnât work for points where control flow joins, such as the block following the consequent and alternative arms of an if/else.
Consider this Rust code, and how we might translate it into SSA:
let x;
if some_condition() {
// This version of `x` becomes `x0` when
// translated to SSA.
x = foo();
} else {
// This version of `x` becomes `x1` when
// translated to SSA.
x = bar();
}
// Does this use `x0` or `x1`??
do_stuff(x);
Should the do_stuff call at the bottom use x0 or x1 when translated into SSA? Neither!
SSA uses Φ (phi) functions to handle these cases. A phi function takes a number of mutually exclusive, control flow-dependent parameters and returns the one that was defined where control flow came from. In our example we would have x2 = Φ(x0, x1), and if some_condition() was true then x2 would get its value from x0. Otherwise, x2 would get its value from x1.
If SSA and phi functions are new to you and youâre feeling confused, donât worry! It was confusing for me too when I first learned about this stuff. But Cranelift IR doesnât use phi functions per se, it has something that I think is more intuitive: blocks can have formal parameters.
Translating our example to Cranelift IR, we get this:
;; Head of the `if`/`else`.
ebb0:
v0 = call some_condition()
brnz v0, ebb1
jump ebb2
;; Consequent.
ebb1:
v1 = call foo()
jump ebb3(v1)
;; Alternative.
ebb2:
v2 = call bar()
jump ebb3(v2)
;; Code following the `if`/`else`.
ebb3(v3: i32):
call do_stuff(v3)
Note that ebb3 takes a parameter for the control flow-dependent value that we should pass to do_stuff! And the jumps in ebb1 and ebb2 pass their locally-defined values âintoâ ebb3! This is equivalent to phi functions, but I find it much more intuitive.
Anyways, translating WebAssembly code into Cranelift IR happens in the cranelift-wasm crate. It uses wasmparser to decode the given blob of Wasm and validate it, and then constructs Cranelift IR via (you guessed it!) abstract interpretation. As cranelift-wasm interprets Wasm instructions, rather than pushing and popping Wasm values, it maintains a stack of Cranelift IR SSA values. As cranelift-wasm enters and exits Wasm control frames, it creates Cranelift IR basic blocks.
This process is fairly similar to walrusâs IR construction, which was pretty similar to wasmparserâs validation, and the whole thing felt pretty familiar by now. There were just a couple tricky bits.
The first tricky bit was remembering to add parameters (phi functions) to the first basic block for a Wasm loopâs body, representing its Wasm stack parameters. This is necessary, because control flow joins from two places at the top of the loop body: from where we were when we first entered the loop, and from the bottom of the loop when we finish an iteration and are starting another. In terms of the abstract interpretation, this means you need to pop off the particular SSA values you have on the stack at the start of the loop, construct SSA values for the loopâs parameters, and then push those onto the stack instead. I originally overlooked this, resulting in a fair bit of head scratching and debugging mis-translated IR. Whoops!
Second, cranelift-wasm will track reachability during translation, and if some Wasm code is unreachable, we donât even bother constructing Cranelift IR for it. But that boundary between unreachable and reachable code, and when one transitions to the other, can be a bit subtle. You can be in an unreachable state, fall through the current block into the following block, and become reachable once again. Throw in ifs with elses, and ifs without elses, and unconditional branches, and early returns, and it is easy for bugs to sneak in. And in the process of adding multi-value Wasm support, bugs did, in fact, sneak in. This time involving an if that was initially reachable, and whose consequent arm also ends reachable, but whose alternative arm ends unreachable. Given that, should the block following the consequent and alternative be reachable? Yes, but we were incorrectly computing that it shouldnât be.
To fix this bug, I refactored how cranelift-wasm computes reachablity of code following an if. It now correctly determines that the following block is reachable if the head of the if is reachable and any of the following are true:
ifâs condition is false, we go directly to the following block.To be sure that we are handling all these edge cases correctly, I added tests enumerating every combination of reachability of an ifâs arms as well as early branches. Phew!
Finally, this bug first manifested itself in a 39 KiB Wasm file, and figuring out what was going on was made so much easier thanks to tools like wasm-reduce (a tool that is part of binaryen) and creduce (working on the WAT disassembly, rather than the binary Wasm). I forget which one I used this time, but Iâve successfully used both to turn big, complicated Wasm test cases into small, isolated test cases that highlight the bug at hand. These tools are real life savers so it is worth broadcasting their existence just in case anyone doesnât know about them!
Translating multi-value Wasm into Cranelift IR happened in these pull requests:
ifsCranelift IR the language supports returning arbitrarily many values from a function, but Cranelift the implementation only supported returning as many values as there are available registers in the calling convention that the function is using. For example, with the System V calling convention, you could return up to three pointer-sized values, and with the Windows fastcall calling convention, you could only return a single pointer-sized value.
So the question was:
How to return more values than can fit in registers?
This should trigger some deja vu: when compiling to Wasm, how was LLVM returning structures larger than could fit in a single Wasm value? Struct return pointer parameters! This is nothing new, and in fact its use is dictated by certain calling conventions, we just hadnât implemented support for it in Cranelift yet. So thatâs what I set out to do.
When Cranelift is given some initial IR, the IR is generally portable and machine independent. As the IR moves through Cranelift, eventually it reaches a legalization phase where instructions that donât have a direct mapping to an machine code instruction in the target architecture are replaced with ones that do. For example, on 32-bit x86, Cranelift legalizes 64-bit arithmetic by expanding it into a series of 32-bit operations. During this process, we also legalize function signatures: passing a value that is larger than can fit in a register may need to be split into multiple parameters, each of which can fit in registers, for example. Signature legalization also assigns locations to formal parameters based on the functionâs calling convention: this parameter should be in this register, and that parameter should be at this stack offset, etc.
My plan for implementing arbitrary numbers of return values via struct return pointer parameters was to hook into Craneliftâs legalization phase during signature legalization, legalizing return instructions, and legalizing call instructions.
When legalizing signatures, we need to determine whether a struct return pointer is required, and if so, update the signature to reflect that.
;; Before legalization.
fn() -> i64, i64, i64, i64 fast
;; After legalization.
fn (v0: i64 sret [%rdi]) -> i64 sret [%rax] fast
Here, fast means the signature is using our internal, unstable âfastâ calling convention. The sret is an annotation for a parameter or return value, in this case documenting that it is being used as a struct return pointer. The %rdi and %rax are the registers assigned to the parameter and return value by the calling convention.4
After legalization, weâve added the struct return pointer parameter, but we also removed the old returns, and we also return the struct return pointer parameter as well. Returning the struct return pointer is mandated by the System V ABIâs calling conventions, but we currently do the same thing for our internal, unstable calling convention as well.
After signatures are legalized, we need to legalize call and return instructions as well, so that they match the new, legalized signatures. Letâs turn our attention to the latter first.
Legalizing a return instruction removes the return values from the return instruction itself, and creates a series of preceding store instructions that write the return values through the struct return pointer. Hereâs an example that is returning four i32 values:
;; Before legalization.
ebb0:
;; ...
return v0, v1, v2, v3
;; After legalization.
ebb0(v4: i64):
;; ...
store notrap aligned v0, v4
store notrap aligned v1, v4+4
store notrap aligned v2, v4+8
store notrap aligned v3, v4+12
return v4
The new v4 value is the struct return pointer parameter. The notrap annotation on the store instruction is saying that this store canât trigger a trap. It is the callerâs responsibility to give us a valid struct return pointer that is pointing to enough space to fit all of our return values. The aligned annotation is similar, saying that the pointer we are storing through is properly four-byte aligned for an i32. Again, the responsibility is on the caller to ensure the struct return pointer has at least the maximum alignment required by the return valuesâ types. The +4, +8, and +12 are static immediates that specify an offset to be added to the actual v4 operand to compute the destination address for the store.
Legalizing a call instruction has comparatively more responsibilities than legalizing a return instruction. Yes, it involves adding the struct return pointer argument to the call instruction itself, and then loading the values out of the struct return space after the callee returns to us. But it additionally must allocate the space for the struct return in the caller functionâs stack frame, and it must ensure that the size and alignment invariants that the callee and its return instructions rely on are upheld.
Letâs take a look at an example of some caller function calling a callee function that returns four i32s:
;; Before legalization.
function %caller() {
fn0 = colocated %callee() -> i32, i32, i32, i32
ebb0:
v0, v1, v2, v3 = call fn0()
return
}
;; After legalization.
function %caller() {
ss0 = sret_slot 16
sig0 = (i64 sret [%rdi]) -> i64 sret [%rax] fast
fn0 = colocated %callee sig0
ebb0:
v4 = stack_addr.i64 ss0
v5 = call fn0(v4)
v6 = load.i32 notrap aligned v5
v0 -> v6
v7 = load.i32 notrap aligned v5+4
v1 -> v7
v8 = load.i32 notrap aligned v5+8
v2 -> v8
v9 = load.i32 notrap aligned v5+12
v3 -> v9
return
}
The ss0 = sret_slot 16 is a sixteen byte stack slot that we created for the struct return space. It is also aligned to sixteen bytes, which is greater than necessary in this case, since we only need four byte alignment for the i32s. Similar to the stores in the legalized return, the loads in the legalized call are also annotated with notrap and aligned. v0 -> v6 establishes that v0 is another name for v6, and we donât have to eagerly rewrite all the following uses of v0 into uses of v6 (even though there donât happen to be any in this particular example).
With signature, call, and return legalization that all understand when and how to use struct return pointers, we now have full support for arbitrarily many multi-value returns in Cranelift and Wasmtime. This support was implemented in these pull requests:
legalize_signatures: Optimistically try and assign register locations to return values; backtrack to use struct-return pointer parameterFinally, letâs put everything together and create a multi-value Wasm binary with the Rust and Wasm toolchain and then run it in Wasmtime!
First, letâs create a new library crate with cargo:
$ cargo new --lib hello-multi-value
Created library `hello-multi-value` package
$ cd hello-multi-value/
Weâre going to use wasm-bindgen to return a string from our Wasm function, so lets add it as a dependency. Additionally, weâre going to create a Wasm library, rather than an executable, so specify that this is a âcdylibâ:
# Cargo.toml
[lib]
crate-type = ["cdylib"]
[dependencies]
wasm-bindgen = "0.2.54"
Letâs fill out src/lib.rs with our string-returning function:
use wasm_bindgen::prelude::*;
#[wasm_bindgen]
pub fn hello(name: &str) -> String {
format!("Hello, {}!", name)
}
We can build our Wasm library with cargo wasi:
$ cargo wasi build --release
This will automatically build a Wasm file for the wasm32-wasi target and then run wasm-bindgenâs post-processor to add interface types and introduce multi-value. We can verify this with the wasm-objdump tool from WABT:
$ wasm-objdump -x \
target/wasm32-wasi/release/hello_multi_value.wasm
hello_multi_value.wasm: file format wasm 0x1
Section Details:
Type[14]:
...
- type[6] (i32, i32) -> (i32, i32)
...
Function[151]:
...
- func[93] sig=6
...
Export[5]:
- func[93] -> "hello"
...
We can see that the function is exported as `"hello"` and that it has the multi-value type `(i32, i32) -> (i32, i32)`. This shim function is indeed the one introduced by our multi-value transform we added to `wasm-bindgen` to wrap the original function and turn its struct return pointer into multi-value.
Finally, we can load this Wasm library into Wasmtime, which will use Cranelift to just-in-time (JIT) compile it to machine code, and then invoke the hello export with the string "multi-value Wasm":
$ wasmtime \
target/wasm32-wasi/release/hello_multi_value.wasm \
--invoke hello "multi-value Wasm"
Hello, multi-value Wasm!
It works!!
The Rust and WebAssembly toolchain now supports generating Wasm binaries that make use of the multi-value proposal, and Cranelift and Wasmtime can compile and run multi-value Wasm binaries. This has been â I hope! â an interesting tale of implementing a Wasm feature through the whole vertical ecosystem, start to finish.
Lastly, and definitely not leastly, Iâd like to thank Dan Gohman, Benjamin Bouvier, Alex Crichton, Yury Delendik, @bjorn3, and @iximeow for providing reviews and implementation suggestions for different pieces of this journey at various stages. Additionally, thanks again to Alex and Dan, and to Lin Clark and Till Schneidereit for all providing feedback on early drafts of this piece.
0 Additionally, Thomas Lively and some other folks are already working on adding multi-value Wasm support directly to LLVM, so that is definitely coming in the future, and it made sense for me to focus my attention elsewhere. 
1 There are some âstack-yâ forms that donât quite directly map to a tree. For example, you can insert stack-neutral, side-effectual instruction sequences in the middle of any part of the post-order encoding of an expression tree. Here is a call that produces some value, followed by a drop of that value, inserted into the middle of the post-order encoding of 1 + 2:
;; Instructions ;; Stack
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
i32.const 1 ;; [1]
call $foo ;; [1, $result_of_foo]
drop ;; [1]
i32.const 2 ;; [1, 2]
i32.add ;; [3]
These stack-y forms can be represented by introducing blocks that donât also introduce labels for control flow branches. You can think of them as sort of similar to Common Lispâs progn and prog0 forms or Schemeâs (begin ...)
2 Fun fact: there is also ongoing work to make Cranelift a viable alternative backend for rustc! See the goals write up and the bjorn3/rustc_codegen_cranelift repo for details.
3 Originally, Cranelift was designed to use extended basic blocks, rather than regular basic blocks. Both can only be entered at their head, but basic blocks additionally can only exit at their tail, while extended basic blocks can have conditional exits from the block in their middle. The idea is that extended basic blocks more directly match machine code which falls through untaken conditional branches to continue executing the next instruction. However, Cranelift is in the process of switching over to regular basic blocks, and removing support for extended basic blocks. The reasoning is that all its optimization passes end up essentially constructing and keeping track of basic blocks anyways, which added complexity, and the extended basic blocks werenât ultimately carrying their weight.
4 Semi-confusingly, the square brackets are just the syntax that Cranelift decided to use to surround parameter locations, and they do not represent dereferencing the way they would in Intel-flavored assembly syntax.
The post Multi-Value All The Wasm! appeared first on Mozilla Hacks - the Web developer blog.
Long article on the manipulation of GPS in Shanghai. It seems not to be some Chinese military program, but ships who are stealing sand.
The Shanghai "crop circles," which somehow spoof each vessel to a different false location, are something new. "I'm still puzzled by this," says Humphreys. "I can't get it to work out in the math. It's an interesting mystery." It's also a mystery that raises the possibility of potentially deadly accidents.
"Captains and pilots have become very dependent on GPS, because it has been historically very reliable," says Humphreys. "If it claims to be working, they rely on it and don't double-check it all that much."
On June 5 this year, the Run 5678, a river cargo ship, tried to overtake a smaller craft on the Huangpu, about five miles south of the Bund. The Run avoided the small ship but plowed right into the New Glory (Chinese name: Tong Yang Jingrui), a freighter heading north.
Boing Boing article.
 |
| YMW - 366 courtesy: ve3gop.com |
A screengrab of the mishap, from LabPadreâs live stream. | Image: LabPadre
A test version of SpaceXâs next-generation rocket, Starship, partially burst apart during ground tests in Texas today, erupting plumes of gas and sending some pieces of hardware soaring into the sky. Live streams set up by local space enthusiasts captured the failure in real time this afternoon.
The explosive result occurred while SpaceX was seemingly conducting some pressure tests with the vehicle at the companyâs test site in Boca Chica, Texas. The local live streams showed the vehicle venting gas periodically throughout the day, indicating that testing was underway.
âThe purpose of todayâs test was to pressurize systems to the max, so the outcome was not completely unexpected,â a spokesperson for SpaceX told The Verge. âThere were no...
Southeastern Australia has been swept by devastating bushfires for the past monthâthe state of New South Wales currently has more than 50 fires burning, and blames the blazes for the loss of four lives and more than 500 homes. NSW Premier Gladys Berejiklian declared a state of emergency on November 11, and residents have been warned of âcatastrophicâ fire conditions, as extreme high temperatures and strong winds remain in the forecast. Below, images from southeastern Australia over the past few weeks, of the fires and of those coping with the disaster.
[sees a space shuttle] ok double boomer
My, what a busy week! Two meteor showers and northern lights, too?! Space weather experts forecast a minor geomagnetic storm (Kp=5) for tonight between about 9 p.m. and 1 a.m. Central Time. And guess what? The instigator looks like the same coronal hole thatâs been spraying Earth with subatomic particles since August.
A gap in the sunâs corona that allowed material to stream earthward at high speed in late August, sparking a fast-moving aurora and the STEVE feature on August 31. The hole came around again 4 weeks later for a late September aurora followed by a repeat performance in October. And now a fourth! I was able to see the celestial trifecta but alas, a coveted quadfecta is beyond reach. Snow is forecast for my region tonight.
But that doesnât diminish my hope that YOU will see it. Keep watch this evening and chime in the Comments area with the good news. Because itâs a minor storm any aurora will likely be limited to the northern U.S. states and Canada along with the northern European latitudes.
Image: NASA / SpaceX
Last week, SpaceX fired up the engines on its new passenger spacecraft, the Crew Dragon, during a ground test, and now, you can watch the fiery show in all its slow-motion glory. Today, NASA released footage from the test, marking the latest milestone SpaceX reached as the company prepares the capsule for its next flight.
The engines, known as SuperDracos, are part of the Crew Dragonâs emergency abort system, which will definitely come in handy if anything goes wrong during a future trip to space. The engines are designed to ignite if the rocket carrying the Crew Dragon starts to malfunction. The thrusters will then carry the Crew Dragon to safety, prompting the capsuleâs parachutes to deploy and gently lower the capsule into the ocean.
If you are like me, youâve typed âmake buildworld && make buildkernel && make installkernel â¦â about a zillion times. Now, you can encapsulate that process in a shorter statement: âmake build-all install-allâ. The real benefit is these new steps also run in parallel to match the number of CPUs present, and logs to file instead of the console, automatically.
Firefox 71 is an exciting release for anyone who cares about CSS Layout. While I am very excited to have subgrid available in Firefox, there is another property that Iâve been keeping an eye on. Firefox 71 implements column-span from Multiple-column Layout. In this post Iâll explain what it is and a little about the progress of the Multiple-column Layout specification.
Multiple-column Layout, usually referred to as multicol, is a layout method that does something quite different to layout methods such as flexbox and grid. If you have some content marked up and displaying in Normal Flow, and turn that into a multicol container using the column-width or column-count properties, it will display as a set of columns. Unlike Flexbox or Grid however, the content inside the columns flows just as it did in Normal Flow. The difference is that it now flows into a number of anonymous column boxes, much like content in a newspaper.
See the Pen
Columns with multicol by rachelandrew (@rachelandrew)
on CodePen.
Multicol is described as fragmenting the content when it creates these anonymous column boxes to display content. It does not act on the direct children of the multicol container in a flex or grid-like way. In this way it is most similar to the fragmentation that happens when we print a web document, and the content is split between pages. A column-box is essentially the same thing as a page.
We can use the column-span property to take an element appearing in a column, and cause it to span across all of the columns. This is a pattern common in print design. In the CodePen below I have two such spanning elements:
h1 is inside the article as the first child element and is spanning all of the columns.h2 is inside the second section, and also spans all of the columns.See the Pen
Columns with multicol and column-span by rachelandrew (@rachelandrew)
on CodePen.
This example highlights a few things about column-span. Firstly, it is only possible to span all of the columns, or no columns. The allowable values for column-span are all, or none.
Secondly, when a span interrupts the column boxes, we end up with two lines of columns. The columns are created in the inline direction above the spanning element, then they restart below. Content in the columns does not âjump overâ the spanning element and continue.
In addition, the h1 is a direct child of the multicol container, however the h2 is not. The h2 is nested inside a section. This demonstrates the fact that items do not need to be a direct child to have column-span applied to them.
Firefox has now joined other browsers in implementing the column-span property. This means that we have good support for the property across all major browsers, as the Compat data for column-span shows.
My interest in the implementation of column-span is partly because I am one of the editors of the multicol specification. I volunteered to edit the multicol specification as it had been stalled for some time, with past resolutions by the WG not having been edited into the spec. There were also a number of unresolved issues, many of which were to do with the column-span feature. I started work by digging through the mailing list archives to find these issues and resolutions where we had them. I then began working through them and editing them into the spec.
At the time I started working on the specification it was at Candidate Recommendation (CR) status, which infers that the specification is deemed to be fairly complete. Given the number of issues, the WG decided to return it to Working Draft (WD) status while these issues were resolved.
As a spec editor, itâs exciting when features are being implemented, as it helps to progress the spec. CSS is created via an iterative and collaborative process; the CSS WG do not create a complete specification and fling it over the wall at browser engineers. The process involves working on a feature in the WG, which browser engineers try to implement. Questions and problems discovered during that implementation phase are brought back to the working group. The WG then have to decide what to do about such issues, and the spec editor then gets the job of clarifying the spec based on the resolution. The process repeats â each time we tease out issues. Any lack of clarity could cause an interoperability issue if two browsers interpreted the description of the feature in a different way.
Based on the work that Mozilla have been doing to implement column-span, several issues were brought to the CSS WG and discussed in our calls and face-to-face meetings. Weâve been able to make the specification much clearer on a number of issues with column-span and related issues. Therefore, Iâm very happy to have a new property implemented across browsers, and also happy to have a more resilient spec! We recently published an updated WD of multicol, which includes many changes made during the time Mozilla were implementing multicol in Firefox.
With the implementation of column-span, multicol will work in much the same way across browsers. We do have an outstanding issue with regards to the column-fill property, which controls how the columns are filled. The default way that multicol fills columns is to try to balance the content, so equal amounts of content end up in each column.
By using the column-fill property, you can change this behavior to fill columns sequentially. This would mean that a multicol container with a height could fill columns to the specified height, potentially leaving empty columns if there was not enough content.
See the Pen
Columns with multicol and column-fill by rachelandrew (@rachelandrew)
on CodePen.
Due to specification ambiguity, Firefox and Chrome do different things if the multicol container does not have a height. Chrome ignores the column-fill property and balances, whereas Firefox fills the first column with all of the content. This is the kind of issue that arises when we have a vague or unclear spec. Itâs not a case of a browser âgetting things wrongâ, or trying to make the lives of web developers hard. Itâs what happens when specifications arenât crystal clear! For anyone interested, the somewhat lengthy issue trying to resolve this is here. Most developers wonât come across this issue in practice. However, if you are seeing differences when using column-fill, it is worth knowing about.
The implementation of column-span is a step towards making multicol robust and useful on the web. To read more about multicol and possible use cases see the Guides to Multicol on MDN, and my article When And How To Use Multiple-column Layout.
The post Multiple-column Layout and column-span in Firefox 71 appeared first on Mozilla Hacks - the Web developer blog.
Planet is somewhat of a rarity for a company headquartered in San Francisco, California. Not only do we develop cutting-edge geospatial data, tools and products, but we also design, build and operate the worldâs largest fleet of remote sensing satellites.
We are also uniquely committed to building a workforce that considers many dimensions of diversity. Planet is dedicated to hiring the best talent, even when some of those people happen to have been born outside the U.S. But historically, this hiring philosophy hasnât been the norm in the aerospace industry.
Satellite technology is whatâs known as âExport Controlled,â either under the Export Administration Regulations (EAR) or the International Traffic in Arms Regulations (ITAR), which means that the U.S. Government dictates where that satellite technology can go and who can have access to it. For example, any time a U.S.-based company needs to ship a satellite abroad for a launch, or wants to hire someone that is not a U.S. person to work on satellite technology, export license approvals or exceptions must be obtained from the Department of Commerce or the Department of State.
Because of such complicated export regulations, many companies in the aerospace industry choose to keep things simple and only hire U.S. citizens.
However, diversity and inclusion are a top priority at Planet, and we go the extra mile to procure export license approvals or exceptions, if needed, and put the technology safeguards in place so that we can maintain a diverse and international workforce.
In addition to hiring international talent at our U.S. locations, about 20 percent of Planetâs employees are based in our European headquarters in Berlin, Germany, and another 20 percent are remote, giving our workforce maximum flexibility in how they can contribute to Planetâs mission.
To help us recruit at scale and avoid missing out on international talent, Planet is creating even more proactive outreach strategies, which will help leverage a larger audience while prioritizing our efforts to create more balanced teams.
âFor our size and stage and for how lean our team is, itâs remarkable that weâve taken the steps to balance effective compliance with progressive international hiring,â says Michael Kyle, Head of Talent and Belonging at Planet. âThis complements what we do domestically, where we are intentional with our outreach to underrepresented communities.â
This, we feel, expands our possibilities to reach our ascribed ambitious targets to create balanced teams by reaching a larger total available audience.
Building a diverse workforce also helps us to better represent our global customer base and connect with what they need from our data and tools. Itâs important that our employees understand the broad range of global customers we serve so we can continue to iterate and improve our products and services.
Planet is constantly growing and evolving, so be sure to check out our Careers page for our latest job postings. While there are some rare exceptions to the types of international talent we can hire for specific roles, we remain committed to building a diverse and inclusive workforce with an international footprint. Weâre excited over the coming months to share more about the many ways we are working to create a balanced workforce and a culture of belonging.
âCould the same computer algorithms that teach autonomous cars to drive safely help identify nearby asteroids or discover life in the universe? NASA scientists are trying to figure that out by partnering with pioneers in artificial intelligence (AI) to apply advanced computer algorithms to problems in space science.â
Read the full article here:
https://www.nasa.gov/feature/goddard/2019/nasa-takes-a-cue-from-silicon-valley-to-hatch-artificial-intelligence-technologies
A 21-year-old Illinois man was sentenced last week to 13 months in prison for running multiple DDoS-for-hire services that launched millions of attacks over several years. This individualâs sentencing comes more than five years after KrebsOnSecurity interviewed both the defendant and his father and urged the latter to take a more active interest in his sonâs online activities.
A screenshot of databooter[.]com, circa 2017. Image: Cisco Talos.
The jail time was handed down to Sergiy P. Usatyuk of Orland Park, Ill., who pleaded guilty in February to one count of conspiracy to cause damage to Internet-connected computers and owning, administering and supporting illegal âbooterâ or âstresserâ services designed to knock Web sites offline, including exostress[.]in, quezstresser[.]com, betabooter[.]com, databooter[.]com, instabooter[.]com, polystress[.]com and zstress[.]net.
According to the U.S. Justice Department, in just the first 13 months of the 27-month long conspiracy, Usatyukâs booter users ordered approximately 3,829,812 DDoS attacks. As of September 12, 2017, ExoStresser advertised on its website that this one booter service had launched 1,367,610 DDoS attacks, and caused targets to suffer 109,186.4 hours of network downtime (-4,549 days).
Usatyuk â operating under the hacker aliases âAndrew Quezâ and âBrian Martinez,â among others â admitted developing, controlling and operating the aforementioned booter services from around August 2015 through November 2017. But Usatyukâs involvement in the DDoS-for-hire space very much predates that period.
In February 2014, KrebsOnSecurity reached out to Usatyukâs father Peter Usatyuk, an assistant professor at the University of Illinois at Chicago. I did so because a brief amount of sleuthing on Hackforums[.]net revealed that his then 15-year-old son Sergiy â who at the time went by the nicknames âRasboraâ and âMr. Booter Masterâ â was heavily involved in helping to launch crippling DDoS attacks.
I phoned Usatyuk the elder because Sergiyâs alter egos had been posting evidence on Hackforums and elsewhere that heâd just hit KrebsOnSecurity.com with a 200 Gbps DDoS attack, which was then considered a fairly impressive DDoS assault.
âI am writing you after our phone conversation just to confirm that you may call evening time/weekend to talk to my son Sergio regarding to your reasons,â Peter Usatyuk wrote in an email to this author on Feb. 13, 2014. âI also have [a] major concern what my 15 yo son [is] doing. If you think that is any kind of illegal work, please, let me know.â
That 2014 story declined to quote Rasbora by name because he was a minor then, but his father seemed alarmed enough about my inquiry that he insisted his son speak with me about the matter.
Hereâs an excerpt of what I wrote about Sergiy at the time:
Rasboraâs most recent project just happens to be gathering, maintaining huge âtop qualityâ lists of servers that can be used to launch amplification attacks online. Despite his insistence that heâs never launched DDoS attacks, Rasbora did eventually allow that someone reading his posts on Hackforums might conclude that he was actively involved in DDoS attacks for hire.
âI donât see what a wall of text can really tell you about what someone does in real life though,â said Rasbora, whose real-life identity is being withheld because heâs a minor. This reply came in response to my reading him several posts that heâd made on Hackforums not 24 hours earlier that strongly suggested he was still in the business of knocking Web sites offline: In a Feb. 12 post on a thread called âHiring a hit on a Web siteâ that Rasbora has since deleted, he tells a fellow Hackforums user, âIf all else fails and you just want it offline, PM me.â
Rasbora has tried to clean up some of his more self-incriminating posts on Hackforums, but he remains defiantly steadfast in his claim that he doesnât DDoS people. Who knows, maybe his dad will ground him and take away his Internet privileges.
Iâm guessing young Sergiy never had his Internet privileges revoked, nor did he heed advice to use his skills for less destructive activities. His dad hung up on me when I called Wednesday evening requesting comment.
In addition to serving the 13-month jail sentence and three years of supervised release, Usatyuk will forfeit $542,925 in proceeds from the scheme, as well as dozens of servers and other computer equipment that powered his many DDoS-for-hire businesses.
Iran has gone pretty much entirely offline in the wake of nationwide protests. This is the best article detailing what's going on; this is also good.
AccessNow has a global campaign to stop Internet shutdowns.
TITLE EDITED TO REDUCE CONFUSION.
Good evening it is Loving Pete Conrad Hours
Iâve known a lot of guys who have bought a lot of things expecting to make a lot of money off of them, and if thereâs one thing Iâve learned, itâs this: anything marked âcollectorâs editionâ is guaranteed to become worthless.
As always, thanks for using my Amazon Affiliate links (US, UK, Canada).
When I think about mapping new places, I remember Vincent Van Gogh, who once said âTo look at the stars always makes me dream, as simply as I dream over the black dots of a map representing towns and villages. Why, I ask myself, should the shining dots of the sky not be as accessible as the black dots on the map of France?â
Why not indeed? The exciting process of mapping new worlds continues to take place as we pursue our reconnaissance of the Solar System, now pushing well into the Kuiper Belt. Mapping Saturnâs giant moon Titan is particularly satisfying, because as youâll recall, Voyager 1 was diverted from its original trajectory because Titan was just too interesting a target to miss. No Titan mapping then, though we did have useful scientific results, because Voyager 1 saw a world shrouded in orange smog. Cassini changed the game, of course, and now weâre looking deep beneath the clouds.
Image: The colorful globe of Saturnâs largest moon, Titan, passes in front of the planet and its rings in this true color snapshot from NASAâs Cassini spacecraft. The north polar hood can be seen on Titan (5,150 kilometers across) and appears as a detached layer at the top of the moon here. This view looks toward the northern, sunlit side of the rings from just above the ring plane. Images taken using red, green and blue spectral filters were combined to create this natural color view. The images were obtained with the Cassini spacecraft narrow-angle camera on May 21, 2011, at a distance of approximately 2.3 million kilometers from Titan. Image scale is 14 kilometers per pixel on Titan. Credit: NASA/JPL-Caltech/Space Science Institute.
Cassini made something like 120 flybys of Titan in the course of its long campaign at Saturn between 2004 and 2017, using its radar imager to penetrate the atmosphere of nitrogen and methane, while supplementing these views with data from visible and infrared instruments that could make out the larger geological features of the Mercury-sized world. Now Rosaly Lopes (JPL) has led a team of researchers in producing the first map that shows Titanâs global geology, pulling together all of these data to reveal a wide range of terrains. Says Lopes:
âThis study is an example of using combined data sets and instruments. Although we did not have global coverage with synthetic aperture radar (SAR), we used data from other instruments and other modes from radar to correlate characteristics of the different terrain units, so we could infer what the terrains are even in areas where we donât have SAR coverage.â
Image: The first global geological map of Saturnâs largest moon, Titan, is based on radar and visible and infrared images from NASAâs Cassini mission, which orbited Saturn from 2004 to 2017. Labels point to several of the named surface features. Also located is the landing site of the European Space Agencyâs Huygens Probe, part of NASAâs Cassini mission. Credit: NASA/JPL-CalTech/ASU.
When we turn Titan into a map, we begin to sense how many features on the surface resemble similar features on Earth, evidencing similar geological processes at work, with methane/ethane being the operative fluid here. Weâre seeing a hydrologic cycle active on a surface rich in hydrocarbon rain, a place segmented by rivers and punctuated by lakes and seas. Itâs interesting to see, by the way, that David Williams (Arizona State), who was a major player in extrapolating radar images into areas not covered by radar, is also the man who will make the first global geologic map of (16) Psyche on a mission scheduled for a 2022 launch. For more on that one, see Psyche Mission Moved Up, a 2017 Centauri Dreams article.
The paper is Lopes et al., âA global geomorphologic map of Saturnâs moon Titan,â Nature Astronomy 18 November 2019 (abstract).
I was looking for a simple graphical location-selector, a globe that can be spun, zoomed in and clicked on to get an approximate location. I found none so obviously I had to make my own. A good starting point was planetary.js which already takes care of the spinnable and zoomable globe and is pretty easy to extend with plugins. See my fork for details about the mouse-actions plugin.
All the work is done in a callback function for the mouse actions mousedown and mouseup. We could just use click, but that would also cause a positioning update on dragging actions on the globe. Only updating when the mouse coordinates don't change between down and up takes care of that. The rest is pretty straight forward, take mouse coordinates, calculate geographic position with the d3.js function projection.invert, and if that is valid (i.e. inside the globe) update the geolocation of the sky view.
globe.loadPlugin(mouse({
onMousedown: function() {
var x = d3.event.offsetX,
y = d3.event.offsetY;
position = [x, y];
},
onMouseup: function() {
var x = d3.event.offsetX,
y = d3.event.offsetY,
format = d3.format("+.3f");
if (position[0] !== x || position[1] !== y) return;
var pos = this.projection.invert([x,y]);
if (!isNaN(pos[0])) {
// latitude, longitude convention is the opposite for sky coordinates
Celestial.skyview({"location": [format(pos[1]), format(pos[0])]});
}
return pos;
}
}));
Time zones are not taken into account yet, so the result is not necessarily valid. That will be fixed later, as well as putting a position marker on the globe, showing the current terminator between day and night, and optionally also show the current sky state on the current view changing between blue and transparent.
I almost canât believe it will happen. But meteor experts Peter Jenniskens, of NASAâs Ames Research Center, and Esko Lyytinen, of the Finnish Fireball Network, are predicting an intense outburst of the obscure Alpha Monocerotid meteor shower Thursday night, Nov. 21 between 10:15 p.m. and 11:15 p.m. Central Standard Time. The peak, when the shower could produce 400 or more meteors per hour, is expected around 10:50 p.m.
This rare outburst is expected to last between 15 and 40 minutes centered on 10:50 p.m. (11:50 p.m. EST; 9:50 MST, 8:50 PST and 4:50 a.m. Greenwich Time). The shower gets its name from Monoceros the unicorn, a faint constellation located to the left or east of Orion. You didnât know there was a unicorn in the sky? Maybe not on Earth, but itâs been trotting across the sky since its creation in 1612.
Donât worry about having to actually see a unicorn or even the constellation. All you need to know is that the radiant, the place in the sky from which the meteors will appear to stream, is near the bright star Procyon in Canis Minor the little dog back behind Orion. As with any shower, meteors can flash anywhere in the sky. You can distinguish a shower member from a stray because members always point back to the radiant, located in the southeastern sky from U.S. locations.
The crumbs that will strike Earthâs atmosphere Thursday night hail from an unknown comet with a long orbit around the sun. During its last pass through the inner solar system hundreds of years ago, the sun heated the comet, vaporizing icy gases and releasing dust. That dust forms a narrow, dense ribbon that the Earth will hit nearly dead-center on Thursday night.
The Alpha Monocerotids have had at least a handful of big outbursts in the past, the most recent in 1995. The map shows two radiants because the position changes a bit with each encounter. As far as viewing the event, observers in the eastern U.S., South and Central America, Western Europe and West Africa are favored because the radiant will be above the horizon at the appointed time. Further west, the radiant sits below the horizon, cutting off many potential meteors from view. But not all. Even out West viewers should be able to see some shooting upward from the southeastern horizon.
You can face any direction you like, but if it were me, Iâd do east or south. The most important thing to maximize your viewing prospects is to find a place where at least the eastern half of the sky is dark and free of light pollution. If you have a tripod and digital SLR, see if you can catch a meteor. I suggest a wide-angle lens (16mm-35mm) set to its widest opening (f/2.8, f/3.5, f/4), an ISO of 1600 and expose between 30-60 seconds. Take one after another after another. Better, use an intervalometer to do the button pressing automatically, so you can just watch and enjoy.
Clear skies! And please let us know what you see. And if itâs cloudy at your house, donât fret. Italian astronomer Gianluca Masi will live stream the outburst starting at 11:15 p.m. EST Nov. 21 (4:15 UT Nov. 22) on his Virtual Telescope Project site.
For the past decade, as inexpensive laser pointers have become more available, protesters around the world have added them to their tool kits. They are used to distract or obstruct riot police and their cameras and drones, as a colorful way to celebrate and show solidarity in groups, or as a method of communication. Recently, in Hong Kong, police officers have arrested people for the possession of laser pointers, classifying the devices as offensive weapons that could injure someoneâs eyesâwhich has prompted even more protests. Gathered here, images from unrest in Chile, Hong Kong, and Iraq over the past few months, where demonstrators are using lasers as tools of defiance.
Some of the larger application sets on DragonFly have had trouble building, and inconsistent problems with that build. i.e. rust would fail, but in different parts of the build process, every time. It looks to be a problem with signal interaction, and thereâs now much safer ways to do that on DragonFly.
That is going to require a full buildworld/buildkernel if you are on DragonFly-master, 5.7. Release/5.6 users are unaffected.
Version 0.10 of Mozillaâs WebThings Gateway brings support for extension-type add-ons. Released last week, this powerful new capability lets developers modify the user interface (UI) to their liking with JavaScript and CSS.
Although the initial set of extension APIs is fairly minimal, we believe that they will already enable a large amount of functionality. To go along with the UI extensions, developers can also extend the gatewayâs REST API with their own handlers, allowing for back-end analytics, for example.
In this post, weâll walk through a simple example to get you started with building your own extension.
If youâre completely new to building add-ons for the WebThings Gateway, there are a couple things you should know.
An add-on is a set of code that runs alongside the gateway. In the case of extensions, the code runs as part of the UI in the browser. Add-ons can provide all sorts of functionality, including support for new devices, the ability to notify users via some outlet, and now, extending the user interface.
Add-ons are packaged up in a specific way and can then be published to the add-on list, so that they can be installed by other users. For best results, developers should abide by these basic guidelines.
Furthermore, add-ons can theoretically be written in any language, as long as they know how to speak to the gateway via IPC (interprocess communication). We provide libraries for Node.js and Python.
There are two new groups of APIs you should know about.
First, the front end APIs. Your extension should extend the Extension class, which is global to the browser window. This gives you access to all of the new APIs. In this 0.10 release, extensions can add new entries to the top-level menu and show and hide top-level buttons. Each extension gets an empty block element that they can draw to as they please, which can be accessed via the menu entry or some other means.
Second, the back end APIs. An add-on can register a new APIHandler. When an authenticated request is made to /extensions/<extension-id>/api/*, your API handler will be invoked with request information. It should send back the appropriate response.
Now that weâve covered the basics, letâs walk through a simple example. You can find the code for this example on GitHub. Want to see the example in Python, instead of JavaScript? Itâs available here.
This next example is really basic: create a form, submit the form, and echo the result back as JSON.
Letâs go ahead and create our API handler. For this example, weâll just echo back what we received.
const {APIHandler, APIResponse} = require('gateway-addon');
const manifest = require('./manifest.json');
/**
* Example API handler.
*/
class ExampleAPIHandler extends APIHandler {
constructor(addonManager) {
super(addonManager, manifest.id);
addonManager.addAPIHandler(this);
}
async handleRequest(request) {
if (request.method !== 'POST' || request.path !== '/example-api') {
return new APIResponse({status: 404});
}
// echo back the body
return new APIResponse({
status: 200,
contentType: 'application/json',
content: JSON.stringify(request.body),
});
}
}
module.exports = ExampleAPIHandler;The gateway-addon library provides nice wrappers for the API requests and responses. You fill in the basics: status code, content type, and content. If there is no content, you can omit those fields.
Now, letâs create a UI that can actually use the new API weâve just made.
(function() {
class ExampleExtension extends window.Extension {
constructor() {
super('example-extension');
this.addMenuEntry('Example Extension');
this.content = '';
fetch(`/extensions/${this.id}/views/content.html`)
.then((res) => res.text())
.then((text) => {
this.content = text;
})
.catch((e) => console.error('Failed to fetch content:', e));
}
show() {
this.view.innerHTML = this.content;
const key =
document.getElementById('extension-example-extension-form-key');
const value =
document.getElementById('extension-example-extension-form-value');
const submit =
document.getElementById('extension-example-extension-form-submit');
const pre =
document.getElementById('extension-example-extension-response-data');
submit.addEventListener('click', () => {
window.API.postJson(
`/extensions/${this.id}/api/example-api`,
{[key.value]: value.value}
).then((body) => {
pre.innerText = JSON.stringify(body, null, 2);
}).catch((e) => {
pre.innerText = e.toString();
});
});
}
}
new ExampleExtension();
})();The above code does the following things:
The HTML loaded from the server is not a full document, but rather a snippet, since weâre using it to fill in a <section> tag. You could do all this synchronously within the JavaScript, but it can be nice to keep the view content separate. The manifest for this add-on instructs the gateway which resources to load, and which are allowed to be accessed via the web:
{
"author": "Mozilla IoT",
"content_scripts": [
{
"css": [
"css/extension.css"
],
"js": [
"js/extension.js"
]
}
],
"description": "Example extension add-on for Mozilla WebThings Gateway",
"gateway_specific_settings": {
"webthings": {
"exec": "{nodeLoader} {path}",
"primary_type": "extension",
"strict_max_version": "*",
"strict_min_version": "0.10.0"
}
},
"homepage_url": "https://github.com/mozilla-iot/example-extension",
"id": "example-extension",
"license": "MPL-2.0",
"manifest_version": 1,
"name": "Example Extension",
"short_name": "Example",
"version": "0.0.3",
"web_accessible_resources": [
"css/*.css",
"images/*.svg",
"js/*.js",
"views/*.html"
]
}The content_scripts property of the manifest tells the gateway which CSS and JavaScript files to load into the UI. Meanwhile, the web_accessible_resources tells it which files can be accessed by the extension over HTTP. This format is based on the WebExtension manifest.json format, so if youâve ever built a browser extension, it may look familiar to you.
As a quick note to developers, this new manifest.json format is required for all add-ons now, as it replaces the old package.json format.
To test, you can do the following on your Raspberry Pi or development machine.
cd ~/.mozilla-iot/addons
git clone https://github.com/mozilla-iot/example-extensionsudo systemctl restart mozilla-iot-gateway
Hopefully this has been helpful. The example itself is not very useful, but it should give you a nice skeleton to start from.
Another possible use case weâve identified is creating a custom UI for complex devices, where the auto-generated UI is less than ideal. For instance, an adapter add-on could add an alternate UI link which just links to the extension, e.g. /extensions/<extension-id>. When accessed, the UI will bring up the extensionâs interface.
If you have more questions, you can always reach out on Discourse, GitHub, or IRC (#iot). We canât wait to see what you build!
The post Creating UI Extensions for WebThings Gateway appeared first on Mozilla Hacks - the Web developer blog.
National Veterinary Associates (NVA), a California company that owns more than 700 animal care facilities around the globe, is still working to recover from a ransomware attack late last month that affected more than half of those properties, separating many veterinary practices from their patient records, payment systems and practice management software. NVA says it expects to have all facilities fully back up and running normally within the next week.
Agoura Hills, Calif.-based NVA bills itself as is the largest private owner of freestanding veterinary hospitals in the United States. The companyâs Web site says it currently owns roughly 700 veterinary hospitals and animal boarding facilities in the United States, Canada, Australia and New Zealand.
NVA said it discovered the ransomware outbreak on the morning of Sunday, Oct. 27, and soon after hired two outside security firms to investigate and remediate the attack. A source close to the investigation told KrebsOnSecurity that NVA was hit with Ryuk, a ransomware strain first spotted in August 2018 that targets mostly large organizations for a high-ransom return.
NVA declined to answer questions about the malware, or whether the NVA paid the ransom demand.
âIt was ransomware, but weâve been referring to it as a malware incident,â said Laura Koester, NVAâs chief marketing officer.
Koester said because every NVA hospital runs their IT operations as they see fit, not all were affected. More importantly, she said, all of the NVAâs hospitals have remained open and able to see clients (animals in need of care), and access to patient records has been fully restored to all affected hospitals.
âFor a few days, some [pet owners] couldnât do online bookings, and some hospitals had to look at different records for their patients,â Koester said. âBut throughout this whole thing, if there was a sick animal, we saw them. No one closed their doors.â
The source close to the investigation painted a slight less rosy picture of the situation at NVA, and said the companyâs response has been complicated by the effects of wildfires surrounding its headquarters in Los Angeles County: A year ago, a destructive wildfire in Los Angeles and Ventura Counties burned almost 100,00 acres, destroyed more than 1,600 structures, killed three people and prompted the evacuation of nearly 300,000 people â including all residents of Agoura Hills.
âThe support center was scheduled to be closed on Friday Oct 25, 2019 due to poor air quality caused by wildfires to the north,â said the source, who asked to remain anonymous. âAround 2 am PT [Oct. 27], the Ryuk virus was unleashed at NVA. Approximately 400 locations were infected. [Microsoft] Active Directory and Exchange servers were infected. Many of the infected locations immediately lost access to their Patient Information Management systems (PIMs). These locations were immediately unable to provide care.â
The source shared internal communications from different NVA executives to their hospitals about the extent of the remediation efforts and possible source of the compromise, which seemed to suggest that at least some NVA properties have been struggling to accommodate patients.
A missive from NVAâs Director of Operations Robert Hill on Oct. 30 acknowledged that âwe continue to be faced with a monumental effort to restore IT service [to] nearly 400 of our hospitals.â
âThis really hit home for me Saturday,â Hill wrote. âOne of my best friends had to take his Yellow Lab into Conejo Valley for urgent care. Thankfully CV was able to provide care as their [systems] were up and running, but many of our hospitals are not in as good shape.â
In an update sent to NVA hospitals on Nov. 6, the companyâs new head of technology Greg Hartmann said its security system successfully blocked the ransomware from infiltrating its systems â at least at first.
âBecause of the scale of the attack, the virus eventually found three smaller points of entry through accounts that were unaffiliated with NVA, but unfortunately opened within our network,â Hartmann said. âUpon discovery of the incident, our technology team immediately implemented procedures to prevent the malware from spreading; however, many local systems were affected. Still, we have many hospitals whose systems are not recovered. The technology team continues to set up interim workstations at each affected hospital while they prepare to rebuild servers.â
The source told KrebsOnSecurity that NVA suffered a separate ransomware infestation earlier this summer that also involved Ryuk, and they expressed concern that the first incident may not have been fully remediated â potentially letting the attackers maintain a foothold within the organization.
âThis is the second time this year Ryuk struck NVA,â the source said. âThe first time, NVA was rather open to all facilities about what happened. This time, however, they are simply referring to it as a âsystem outage.'â
A set of talking points NVA distributed to staff on Oct. 27, the day some 400 veterinary hospitals were hit with the Ryuk ransomware.
Koester said some NVA facilities did get hit with a malware incident earlier this year, but that she did not believe ransomware was involved in that intrusion.
The Ryuk ransomware has made a name for itself going after businesses that supply services to other companies â particularly cloud-data firms â with the ransom demands set according to the victimâs perceived ability to pay. In February, payroll software provider Apex Human Capital Management chose to pay the ransom demand after a Ryuk infection severed payroll management services for hundreds of the companyâs customers. And on Christmas Eve 2018, cloud hosting provider Dataresolution.net suffered a multi-week outage after a Ryuk attack.
According to a bulletin released by the FBI in May, cybercriminals had targeted over 100 U.S. and international businesses with Ryuk since August 2018. Security firm CrowdStrike estimated that attackers deploying Ryuk had netted over $3.7 million in bitcoin ransom payments between Aug. 2018 and January 2019.
Many people and organizations may be under the impression that ransomware attacks like Ryuk can appear at a momentâs notice merely from someone clicking a malicious link or opening a booby-trapped email attachment. While the latter appears to be the most common vector for ransomware infestations, an advisory released in September by the U.Kâs National Cyber Security Centre suggests most Ryuk victims are compromised weeks or months before the ransomware is actually deployed inside the victimâs network.
âThe Ryuk ransomware is often not observed until a period of time after the initial infection â ranging from days to months â which allows the actor time to carry out
reconnaissance inside an infected network, identifying and targeting critical network systems and therefore maximizing the impact of the attack,â reads the NCSC advisory, which includes tips on spotting signs of a Ryuk infection. âBut it may also offer the potential to mitigate against a ransomware attack before it occurs, if the initial infection is detected and remedied.â
As for what changes NVA will be making to prevent yet another ransomware outbreak, an internal update on Nov. 7 from NVAâs chief information officer Joe Leggio said NVA was investing in software from Carbon Black, a cloud-based security solution that will be installed on all NVA property computers.
âThroughout my career, I have witnessed incredible advances in technology making our lives better,â Leggio wrote. âAt nearly the same rate, the bad guys have been increasing the aggressiveness and sophistication of their attacks. As we rebuild, we are also thinking of the future. That is why we are investing in cybersecurity talent, new infrastructure, and better software.â
For geologists like Dr. Anna Grau Galofre of Arizona State University, just getting to Axel Heiberg Island in the Canadian High Arctic to do research is a time-consuming and expensive endeavor due to weather conditions. High above the Arctic Circle, snow can be present one day and gone the next, while sunny 17 degrees Celcius days can give way to freezing rain with little notice.
Because of this, Grau Galofre has to take multiple flights aboard a series of commercial jets and Twin Otter propeller-powered airplanes, which can amount to costs of thousands of dollars. But with the aid of Planetâs data, Grau Galofre is able to monitor the real-time conditions of the island and make better decisions about how to spend time and resources.
âIf we fly out to an area and itâs covered in snow, weâve wasted time and money because we canât see the landscape once we get there,â Grau Galofre says. âPlanet gives us the ability to see up-to-date images so we can tell what areas are clear for us to visit. Itâs incredibly valuable.â
PlanetScope imagery is also useful for Grau Galofreâs team as they research changes in the Earthâs surface triggered by permafrost melting. Permafrost occurs in the Arctic in places where the ground has remained frozen for at least two years, making the ground as tough as concrete.
Tracking and researching permafrost locations is increasingly necessary due to the effects of climate change, which are causing permafrost to melt at a rapid rate.
The above image shows the aftermath of permafrost melting. In Axel Island, ground that was once frozen and hard as concrete is now a pond of mud. Photo by Anna Grau Galofre
When permafrost melts, it can lead to dramatic effects such as landslides, sinkholes, severe flooding, and even the release of large amounts of methane into the atmosphere. In some cases, grave infrastructure problems have affected entire Arctic communities due to their homes sinking into the ground. This is especially concerning in places like Russia and Alaska, where permafrost provides crucial protection against coastal erosion when savage winter storms crash in from the seas. As the climate is warming, other communities remain at high risk and will likely require relocation over the next decade.
Other than attempting to mitigate the effects of climate change as a whole, thereâs little in the way of preventative measures that can be taken to deal with permafrost meltingâbeyond getting people to safety. Identifying where and how quickly permafrost is melting could play a key role in saving Arctic communities.
Grau Galofreâs work aims to help scientists in their efforts to recognize signs of melting and devise strategies to mitigate risk as early as possible, giving communities and governments time to take action to avoid any loss of lives from the impending hazards.
âAccess to Planetâs daily imagery of Axel Heiberg Island allowed my team to visit more of our target sites with increased confidence than in previous years, optimizing the scientific return of our expedition,â Grau Galofre says. âPlanetâs data has been a valuable component to our research.â
My friends and neighbors the Buies helped us take some family pictures last Saturday at an old abandoned barn over by Waneka Lake. Itâs been a while since Iâve posted family pictures, so here are a few of my favorites:
In its ongoing effort to send cargo â and eventually people â to the lunar surface, NASA announced five new partnerships with commercial space companies that have designed robotic landers that can take large payloads to the Moon. The additions include some well-known industry heavyweights, such as SpaceX, Blue Origin, and Sierra Nevada Corporation, which have already partnered with NASA for other projects.
The newcomers will join an already formed pool of nine companies that are part of NASAâs fledgling CLPS program, which stands for Commercial Lunar Payload Services. The goal is to have multiple different capabilities for transporting scientific instruments and cargo to the Moon, as NASA attempts to send people back to the lunar surface...
The Russian government has for the past four years been fighting to keep 29-year-old alleged cybercriminal Alexei Burkov from being extradited by Israel to the United States. When Israeli authorities turned down requests to send him back to Russia â supposedly to face separate hacking charges there â the Russians then imprisoned an Israeli woman for seven years on trumped-up drug charges in a bid to trade prisoners. That effort failed as well, and Burkov had his first appearance in a U.S. court last week. What follows are some clues that might explain why the Russians are so eager to reclaim this young man.
Alexei Burkov, seated second from right, attends a hearing in Jerusalem in 2015. Andrei Shirokov / Tass via Getty Images.
On the surface, the charges the U.S. government has leveled against Burkov may seem fairly unremarkable: Prosecutors say he ran a credit card fraud forum called CardPlanet that sold more than 150,000 stolen cards.
However, a deep dive into the various pseudonyms allegedly used by Burkov suggests this individual may be one of the most connected and skilled malicious hackers ever apprehended by U.S. authorities, and that the Russian government is probably concerned that he simply knows too much.
Burkov calls himself a specialist in information security and denies having committed the crimes for which heâs been charged. But according to denizens of several Russian-language cybercrime forums that have been following his case in the Israeli news media, Burkov was by all accounts an elite cybercrook who primarily operated under the hacker alias âK0pa.â
This is the same nickname used by an individual who served as co-administrator of perhaps the most exclusive Russian-language hacking forums ever created, including Mazafaka and DirectConnection.
A screen shot from the Mazafaka cybercrime forum, circa 2011.
Since their inception in the mid-aughts, both of these forums have been among the most difficult to join â admitting only native Russian speakers and requiring each applicant to furnish a non-refundable cash deposit and âvouchesâ or guarantees from at least three existing members. Also, neither forum was accessible or even visible to anyone without a special encryption certificate supplied by forum administrators that allowed the sites to load properly in a Web browser.
DirectConnection, circa 2011. The identity shown at the bottom of this screenshot â Severa â belonged to Peter Levashov, a prolific spammer who pleaded guilty in the United States last year to operating the Kelihos spam botnet.
Notably, some of the worldâs most-wanted cybercriminals were members of these two highly exclusive forums, and many of those individuals have already been arrested, extradited and tried for various cybercrime charges in the United States over the years. Those include convicted credit card fraudsters Vladislav âBadbâ Horohorin and Sergey âzo0merâ Kozerev, as well as the infamous spammer and botnet master Peter âSeveraâ Levashov.
A user database obtained by KrebsOnSecurity several years back indicates K0pa relied on the same email address he used to register at Mazafaka and DirectConnection to register the user account âBotnetâ on Spamdot, which for years was the closely-guarded stomping ground of the worldâs most prolific spammers and virus writers, as well as hackers who created services catering to both professions.
As a reporter for The Washington Post in 2008, I wrote about the core offering that K0pa/Botnet advertised on Spamdot and other exclusive forums: A botnet-based anonymity service called FraudCrew. This service sold access to hacked computers, which FraudCrew customers used for the purposes of hiding their real location online while conducting cybercriminal activities.
FraudCrew, a botnet-based anonymity service offered by K0pa.
K0pa also was a top staff member at Verified, among the oldest and most venerated of Russian language cybercrime forums. Specifically, K0paâs role at Verified was in maintaining its blacklist, a dispute resolution process designed to weed out âdishonestâ cybercriminals who seek only to rip off less experienced crooks. From this vantage point, K0pa would have held considerable sway on the forum, and almost certainly played a key role in vetting new applicants to the site.
Prior to his ascendance at these forums, K0pa was perhaps best known for being a founding member of a hacker group calling themselves the CyberLords. Over nearly a decade, the CyberLords team would release dozens of hacking tools and exploits targeting previously unknown security vulnerabilities in Web-based services and computer software.
A cached copy of cyberlords[.]ru, circa 2005.
According to security firm Cybereason, Russia has a history of using contractors â even cybercriminals â to run intelligence operations. These crooks-turned-spies âoffer a resource to the state while enjoying a cloak of semi-protected âstatusâ for their extracurricular activities, provided they are directed against foreign targets.â
âCybercriminals are recruited to Russiaâs national cause through a mix of coercion, payments and appeals to patriotic sentiment,â reads a 2017 story from The Register on Cybereasonâs analysis of the Russian cybercrime scene. âRussiaâs use of private contractors also has other benefits in helping to decrease overall operational costs, mitigating the risk of detection and gaining technical expertise that they cannot recruit directly into the government. Combining a cyber-militia with official state-sponsored hacking teams has created the most technically advanced and bold cybercriminal community in the world.â
A banner that ran on top of the Verified cybercrime forum for many years.
Itâs probably worth noting that also present on both DirectConnection and Mazafaka were the core members of a prolific gang of online bank robbers called the JabberZeus Crew, who used custom versions of the ZeuS Trojan to steal tens â if not hundreds â of millions of dollars from hacked small businesses across the United States. In 2011, most of that crew was rounded up in an international cybercrime crackdown, although virtually all of them escaped prosecution in their home countries (mainly Russia and Ukraine).
I mention this because K0pa also was in regular communications with â if not a core member of âthe JabberZeus crew. This gang worked directly with the author of the ZeuS trojan â Evgeniy âSlavikâ Bogachev â a Russian man with a $3 million bounty on his head from the FBI. The cybercriminal organization Bogchev allegedly ran was responsible for the theft of more than $100 million from banks and businesses worldwide that were infected with his ZeuS malware. That organization, dubbed the âBusiness Club,â had members spanning most of Russiaâs 11 time zones.
In this 2011 screenshot of DirectConnection, we can see the nickname âaqua,â one of the JabberZeus crime gang actors. K0pa also was affiliated with the JabberZeus crew.
Fox-IT, a Dutch security firm that infiltrated the Business Clubâs back-end operations, found that beginning in late fall 2013 â about the time that conflict between Ukraine and Russia was just beginning to heat up â Slavik retooled his cyberheist botnet to serve as purely a spying machine, and began scouring infected systems in Ukraine for specific keywords in emails and documents that would likely only be found in classified documents.
Likewise, the keyword searches that Slavik used to scour bot-infected systems in Turkey suggested the botmaster was searching for specific files from the Turkish Ministry of Foreign Affairs â a specialized police unit. Fox-IT said it was clear that Slavik was looking to intercept communications about the conflict in Syria on Turkeyâs southern border â one that Russia has supported by reportedly shipping arms into the region.
To my knowledge, no one has accused Burkov of being some kind of cybercrime fixer or virtual badguy Rolodex for the Russian government. On the other hand, from his onetime lofty perch atop some of the most exclusive Russian cybercrime forums, K0pa certainly would have fit that role nicely.
Further reading, including the fascinating story on the diplomatic back and forth between Russia and Israel mentioned in the first paragraph: The Russian Hacker Who Just Became One of Israelâs Most Famous Prisoners.
Five months into a pro-democracy protest movement in Hong Kong, some of the most violent clashes so far took place this past weekend, as riot police stormed the campus of a university where protesters had barricaded themselves. Hundreds of demonstrators had occupied Hong Kong Polytechnic University and prepared for a siege. Later, as some attempted to leave the campus, they found themselves trapped by police cordons and tear gas. Last night, police moved in with more tear gas, water cannons, and batons after days of confrontations in and around the campus, arresting many as they attempted to flee. The protests began as a reaction to a controversial extradition bill, but have evolved into broader demands for democracy and investigations into police brutality, challenging Beijingââ¬â¢s authority.
Houston, weâre having a blast
Mission parameters: âHave fun out thereâ
Theyâre sending me to space just for fun
A very happy birthday to naval aviator and NASA astronaut Rear Admiral Alan Bartlett Shepard Jr. (November 18, 1923 â July 21, 1998), who wouldâve turned 95 today! One of the original Mercury Seven, Al became the first American in space during the flight of Freedom 7 in 1961, and ten years later became the fifth human to walk on the moon during Apollo 14.
âItâs a very sobering feeling to be up in space and realize that oneâs safety factor was determined by the lowest bidder on a government contract.â
âDuring the actual process of flying spacecraft, or flying the Spirit of St. Louis, one doesnât think of oneâs self as being a hero or historical figure. One does it because the challenge is there, and one feels reasonably qualified to accomplish it. And itâs later on, I suppose, perhaps at the suggestion of other people, that you say, âWell, yes, maybe.â I must admit, maybe I am piece of history after all.â
âI first met Alan Shepard when he and I were part of the original Mercury candidate group. Al offered me a ride in his Corvette⦠and I thought to myself, âThis is one naval officer who really has it made.â âHow much does one of these cost?â I asked him. And he replied, âIf you gotta ask, you canât afford to own one.ââ -Jim Lovell
The electric sail is an intriguing propulsion concept that Pekka Janhunen at the Finnish Meteorological Institute has been championing for some years. Itâs currently the subject of a NASA Phase II study and continues to draw attention despite the fact that weâre in the early stages of turning what looks like sound physical theory into engineering. What captures the imagination here is the same thing that is so attractive about solar sails â in both cases, we are talking about carrying no propellant, but instead relying on natural sources to do the work.
Here we have to be careful about terminology, because itâs all too easy to refer to solar photons as a kind of âwind,â especially since the predominant metaphor is sailing. So letâs draw the lines sharply. There is indeed a âsolar windâ in todayâs parlance, but it refers not to light but to the stream of particles, plasma and magnetic fields flowing out from the Sun into the heliosphere. An electric sail will ride this solar wind to achieve interplanetary velocities. A solar sail, on the other hand, will use solar photons, which carry no mass but do convey momentum.
Two entirely different concepts, even if both have resemblance to traditional nautical sails. Then we have the other terminological complication: A sail designed to be pushed not just by sunlight but rather by a laser or microwave beam is sometimes called a âlight sail,â which is how I have always referred to it, but it still uses photons for propulsion, even if they donât come from the Sun. Maybe Manasvi Lingam and Avi Loeb have it right in their new paper to refer to photon-pushed sails of any kind as âlight sails,â distinguishing these from both electric and magnetic sails (magsails) that use the âsolar windâ as their driver. Thus:
Light sails â solar sails and those driven by beamed arrays â use electromagnetic radiation and the momentum transfer of photons. Electric sails use the particle stream of the solar wind.
The electric sail that Janhunen continues to study is the subject of Lingam and Loebâs new paper, which has been submitted to Acta Astronautica. At the Florida Institute of Technology and Harvard University respectively, the two scientists have calculated performance possibilities for a spinning spacecraft that deploys a number of long wires to which an electrostatic charge has been induced. Solar wind protons (not photons!) reflect off these wires to produce thrust. The wires are kilometers long, and with that slight positive bias, the spacecraft carries an electron gun to manage the charge, retaining the bias against ambient solar wind electrons.
Image: The electric sail is a space propulsion concept that uses the momentum of the solar wind to produce thrust. Credit: Alexandre Szames.
Light sails, to use the Lingam and Loeb terminology, have been considered for interstellar missions for decades now (hats off to the early work of Robert Forward, Gregory Matloff and Geoff Landis, among others), but electric sails are new enough that we need information on how well an electric sail might do for this purpose. Could this technology get us to another star?
For a species like ours, anxious to see missions completed within a few human lifetimes, the answer is no. While a huge laser array like the one contemplated by Breakthrough Starshot could send a small light sail at relativistic speeds to another star, the electric sail cannot achieve the needed velocities.
A species with a different attitude toward time might fare better. The paper explains, for example, how electric sails could leverage the stellar winds of red dwarf stars, which are by far the most common kind of star in the galaxy. Because the interstellar medium itself can decelerate the sail, turning off the electron gun in deep space is essential. Careful maneuvering from star to star over millennia then allows relativistic speeds. From the paper:
â¦a series of repeated encounters with low-mass stars, and taking advantage of their winds, will enable the electric sail to achieve progressively higher speeds. We showed that sampling â¼ 104 stars could enable electric sails to achieve relativistic speeds of â¼ 0.2 c and that this mechanism would require â¼ 1 Myr. While this constitutes a long timescale by human standards, it is not particularly long in comparison to many astronomical and geological timescales. The ensuing relativistic spacecraft would be well-suited for tackling interstellar and even intergalactic exploration.
This is an eye-opener. We canât rule out the possibility that species capable of operating in this time frame might deploy electric sails, but the time involved precludes their use as the primary propulsion method for interstellar missions by us. The authors note as well that because an electric sail will have a low cross-sectional area, its presence would be all but undetectable, whereas a light sail driven by a laser would demand huge amounts of energy and would be theoretically detectable at interstellar distances. So for a civilization hoping to explore in âstealthâ mode, an electric sail would have its advantages. These are not good SETI targets.
Returning to M-dwarf stars, the authors show that if stars are small enough (less than about 0.2 solar masses), the pressure of the stellar wind dominates over photon pressure, Speeds in the range of 500 kilometers per second seem feasible for electric sails near late-type M-dwarfs. Indeed, for F-, G- and K-class stars, electric sails fare better as propulsion systems in the vicinity of the home star than light sails.
So we are looking at a technology that, if it can be properly engineered, could play a role in shaping an interplanetary infrastructure, while yielding to faster methods for missions to other stars, unless we humans somehow attain an all but geological patience.
The paper is Lingam and Loeb, âElectric sails are potentially more effective than light sails near most stars,â in process at Acta Astronautica (preprint). For Pekka Janhunenâs concept of the electric sail as a fast interplanetary probe, see Electric Sails: Fast Probe to Uranus.
Notice a familiar star pattern missing these late fall nights? How about the Big Dipper. Itâs still there for some of us but you might just need to stand on your tippy toes to see it. For observers like myself who live in the northern U.S. the Dipper never sets. Provided you find an open view to the north, itâs our constant companion, slowly wheeling around the North Star like the hour hand on a clock.
Like Cassiopeia, Cepheus and several other constellation that lie near North Star or Polaris, the Big Dipper is circumpolar. It goes round and round Polaris in a big circle and never sets. Any star that fits within a circle with a radius equal to or less your latitude is circumpolar. For example, in Minneapolis, located at 45° N latitude, stars within 45° (four-and-a-half fists) of the North Star never dip below the horizon. That includes the Big Dipper.
From Tucson, where Polaris stands just 32° above the horizon, the circumpolar radius shrinks to 32° and the Dipper disappears from view. At the North Pole the North Star is directly overhead and every star within 90° of the North Star â the entire sky â is circumpolar! Can you guess how many stars are circumpolar at the equator? Correct â none!
From the northern U.S. the Big Dipper dips low in November but remains circumpolar. But the further south you travel the closer those seven famous stars approach the northern horizon. In Des Moines (40° N latitude), all the Dipper stars stay up but not by much: Alkaid, the star at the end of the Dipperâs handle, stands just 1° high at its lowest point. In Atlanta (33.7° N) half the Dipper plunges below the horizon and disappears from view, while in Tucson Dubhe remains the sole circumpolar representative. Tucsonians have to wait until about 1:30 a.m. for the rotating Earth to bring the Dipper back into view.
Iâve also marked an imaginary line called the meridian on the maps. The meridian starts at the due south point on the southern horizon, arcs through the zenith (overhead) and meets the horizon again at the due north point on the northern horizon. Most stars rise in the east, cross the meridian â when theyâre highest or reach culmination â and then set in the west. But circumpolar stars cross the meridian twice, once above the North Star and a second time below it. Six months from now during the evening hours, the Dipper will culminate above Polaris and climb nearly at the top of the sky. In November it crosses the meridian below the North Star when itâs said to be at its nadir (NAY-der), the bottom of its daily circuit.
Thatâs why the Big Dipper or Ursa Major (the Great Bear) takes a bit of effort to find this time of year. Like a bear the constellation represents, itâs gone into temporary hibernation. Come January it returns with so much enthusiasm, youâll find it literally standing on its tail in the northeastern sky.
Michael W. Lucas is presenting on sudo, to match his recent book, at SeMiBUG, tomorrow night. I think it may be getting held at a different location than usual. Go, if you are near.
In 2019 Michel Mayor and Didier Queloz received the Nobel Prize for their 1995 discovery of an exoplanet, which is just a planet orbiting about a start that isnât our sun. Since then, exoplanet discovery has boomed with us now knowing of over 4000 different exoplanets. Most of these exoplanets, and their corresponding data, are located in individual journal papers which are distributed and hard to access in mass. Solving this problem is the NASA Exoplanet Archive, which brings together most of this data, vets it using a team of astronomers, and stores it in an easy to access format. You should check it out! The rest of the post will be me playing around with the dataset and answering some questions I had about exoplanets that this dataset helped resolve.
Artists Representation of the Trappist System, showing relative scale. Source: JPL/NASA
Astronomers have discovered 4000, exoplanets, but their methods for doing so, and confirming that they are actual signal and not just noise, biases their search towards exoplanets with shorter periods.
NOTE: when I say bias, it does not have a negative connotation, just that there is a prejudice in favor of a certain outcome. Exoplanateers are doing a hard job and are often limited by their equipment and experimental biases that make certain types of exoplanets harder to find than others.
The question I had when starting was how much of a bias towards short period exoplanets is there? From the dataset we find that the median period is a little under 12 days. This means that of the 4000 exoplanets, half have a period shorter than this! The shortest period planet has a period of just 2.16 hours! Because of Keplerâs third law, we know that the planetary period is proportional to its distance from the primary body, in this case, its star. Now, appealing to Keplerâs 3rd law is a bit of a stretch as itâs formulated using Newtonian gravity. Any planet orbiting this close to the massive gravity well provided by a star is bound to be experiencing massive relativistic effects.
Just to put this massive bias towards short periods in perspective, the period of Mercury, the planet in our solar system with the shortest period, at around 88 earth days, is longer than 81% of the exoplanets in the database. Hereâs a histogram of all the planetary periods from 0 to 70 days just to show what the distribution looks like.
If we look at the number of planets in the system versus the orbital eccentricity we see a nice relationship. The more planets there are in a system, the more likely the planets are in circular orbits, and the variance of eccentricities in the orbit decreases. Both of these make sense because a planet with a non-zero eccentricity is more likely to interact unstably with other planets in the system. Hereâs a nice article on Exoplanet orbital eccentricity.
Returning to this idea of biases, thereâs another bias in how we discover exoplanets, our telescopes. If we plot the planetary period vs its radius and differentiate between the Kepler space telescope and most other telescopes we see two major families appear. the first with a planetary radius of around 1 Jupiter radius and a period of around 1 to 2 days. The secondâs much larger and is for planets that are a 10âth the radius of Jupiter and a much larger range of periods. This second family is made up mostly of exoplanets discovered by the Kepler telescope.
As was seen in the last gif, a majority of the exoplanets were found by the Kepler telescope. Overall the database is made up of contributions of 72 different telescopes. Now, thatâs a lot of telescopes, but most only discovered a handful of exoplanets. Iâve grouped any telescope with less than 27 discovered exoplanets into the Misc category and then provided a histogram of the number of exoplanets discovered by every telescope. Itâs on a log scale because the Kepler telescope has discovered almost an order of magnitude more exo-planets than most other telescopes.
If you want to receive new Gereshes blog post directly to your email when they come out, you can sign up for that here!
Donât want another email? Thatâs ok, Gereshes also has a twitter account and subreddit!
The post Exoplanet Archive appeared first on Gereshes.
Researchers have discovered and revealed 146 vulnerabilities in various incarnations of Android smartphone firmware. The vulnerabilities were found by scanning the phones of 29 different Android makers, and each is unique to a particular phone or maker. They were found using automatic tools, and it is extremely likely that many of the vulnerabilities are not exploitable -- making them bugs but not security concerns. There is no indication that any of these vulnerabilities were put there on purpose, although it is reasonable to assume that other organizations do this same sort of scanning and use the findings for attack. And since they're firmware bugs, in many cases there is no ability to patch them.
I see this as yet another demonstration of how hard supply chain security is.
News article.
