Honestly, it would be irresponsible and surprising if Israel _didn't_ try to sabotage Iran's nuclear program, especially given some of the things that the Iranians were saying publicly at the time.
What negative stereotype? That Israel has excellent cyber capacity?
Sure, there wasn't any official attribution, but the US aren't the only player in town either.
EDIT: As an aside, an ex-director of the DGSE[1] (french CIA basically) complained that there tend to be a general misunderstanding between the communication modes of western countries and middle-east countries, the former prefers to proverbially "Speak softly and carry a big stick" while the latter prefer a good incendiary speech as a form of catharsis. As a result western audiences tend to take some speeches too literally, as if they were a plan of action while the discourse wasn't made with them in mind.
Our connectivity to mars is on the order of 12kbps, presumably better for the moon.
My other question would be whether this is due to the need to radiation harden stuff? We were developing for what effectively was equivalent to an arduino in terms of processing power due to the need for radiation hardening (and other legacy / slow moving reasons).
> Our connectivity to mars is on the order of 12kbps
It depends on the spacecraft. DSN is currently talking with the Mars Reconnaissance Orbiter at 1 Mbit/s (https://eyes.nasa.gov/dsn/dsn.html, select MRO, click "more detail" in the bottom-left).
Yep. We could cover Mar's sky with something similar to SpaceX's Starlink (high availability from any location on Mars) but with large data buffers and transmission systems that can pump the goods all the back to Earth.
46 Light Minutes is pretty much the maximum, that's 827,427,184 Kilometers round trip which is a bit beyond the maximum distance to Mars so there's some processing delays thrown in there.
One of the key techniques for radiation hardening is big transistor geometries. Big transistors are less susceptiple to SEU (single event upset) caused by cosmic rays [0].
Unfortunately big transistors are old transistors. Modern 7 nm geometries are much too small to be rad-hard. Rad-hardness needs big 20-year-old geometries or even older. That also implies slower clock speeds.
Surely redundant transistors would also be a useful technique. E.g. have an array of transistors at the current geometry, all doing the same function. The chance of a single event upsetting them all becomes unlikely.
Yes, the strategy IIRC SpaceX's Dragon uses is to have 3 more modern CPUs tied together, such that they're all running the same operation and checking each other. It mitigates errors without as much of a performance penalty.
> whether this is due to the need to radiation harden stuff?
It's been a very long time since I read about it so I cannot provide my source but yes that is likely part of it. There's also the resilience of the components to trauma to consider.
While smaller ESA projects like satellite instruments are usually free to choose which version of RTEMS they use, larger and more important projects use ESA's own version. This version is known as the "EDISOFT" version because it was re-developed/qualified by a portuguese company of that name. It is basically a rewrite of a subset of the RTEMS API. You can read more about it here: https://www.esa.int/Enabling_Support/Space_Engineering_Techn...
Like most of ESA's software engineering tools, it is hopelessly outdated and relies on a patched GCC 4.2.1 which is missing a lot of useful features and bug fixes, especially for the SPARC architecture which is often used in ESA spacecraft. See -mfix-* switches here https://gcc.gnu.org/onlinedocs/gcc-10.4.0/gcc/SPARC-Options....
While RTEMS is GPL-licensed ESA does not want the code to be freely available -- you probably won't find it online. Some years ago they realized that, if they don't upstream their code, they have no chance to keep up to date and started an initiative to improve the situation: https://rtems-qual.io.esa.int, https://rtems-qual.io.esa.int/
This is ESA's fourth RTEMS qualification effort AFAIK. This time they are working with the community and have submitted things like requirements for a subset of RTEMS and requirements based tests. This is tracking the git master and SMP is included. We worked with NASA IV&V folks to get an outline for the RTEMS Software Engineering Guide which provides information expected in a qualification review.
Quietly an RTEMS core developer submitted GCC support for running gcov or gprof on embedded targets and getting the information off. This will be used to get coverage reports which meet ESA expectations. We do have very high code coverage.
ESA has also sponsored formal analysis of some parts of RTEMS.
I am quite happy ESA is working so well with our core developers and community this time.
I am trying to understand what differs the EDISOFT and upstream versions of RTEMS. The only concrete differences I can read out from the linked webpage is basically:
* SpaceWire support (LEON3)
* MIL-STD-1553 support (LEON3)
* kernel and application monitoring services (whatever that means)
Basically they made a list of a minimal set of functions that they want to support. They deleted all the other functions, then re-implemented the remaining code. For example, they axed the entire POSIX API, only kept the classic "rtems_" API. I don't know about quality of the SpW and M1553 code in the EDISOFT version but the quality of the driver code that Gaisler (now CAES) distributes for their processors is abysmal. Found here: https://www.gaisler.com/anonftp/rcc/src/ -- Among other issues: spaghetti-code, certain error flags not checked/reset resulting in lockups in case of errors, buffer sizes not configurable, unbounded loops/excessive wait delays. All big no-nos for safety-critical embedded software but understandable given limited manpower.
Nope, it's not. At least not entirely: https://www.rtems.org/license -- and the ESA version is definitely GPL-licensed.
Nothing against you personally, but I would really appreciate if instead of stating a certain believe, you actually look it up and point out a source for that bit of information.
My understanding of this technology was it was usually a hash or fingerprint of some form of the material, to be compared against a database of hashes of known-bad material. I doubt EU countries have the infrastructure or budget to run models across everything, no?
An article about this was posted yesterday, and the EU wants to take it further that detecting known CSAM content, using AI to detect new content too.
Of course, it's all a pretence for getting access to read all of your data. It might be a language thing, but the wording of the report was such that they were almost stating this explicitly.
Honestly, what.the.hell are these clowns thinking?!
The article says they already have technology that detects "grooming", whatever that means. That's seriously frightening, who knows what else they can detect? Maybe a few years from now we'll be reading articles about people getting arrested for expressing prohibited thoughts, subversive ideas, political opposition in what they thought was a private communications channel.
The problem with hashes is, that you cannot prove what the original image was without actually getting caught with csam.
So basically, a whistleblower takes photos of some very incriminating documents, someone gets accused of eg. money laundering, hashes of those images get added to the "csam" database, and you find the first person (via metadata) who had that image on their phone.
Also, in some more repressive countries, an image of a famous cartoon bear photoshopped to look like some president can be added, and all the people who look/have/download images (memes) like that, can get put on a "list".
But would the system not insist images are hashed by it? I mean; I would think it’s not a weird demand that if this is to protect children (which it is not, at least not only) that the image hashes are solely for that purpose or otherwise not valid and thrown out by at least an AI. I know it’s naive but it seems you want the image with the hash and if someone gets flagged and it’s some money laundering doc, then it should be dismissed before you get out on a list.
The hashes are likely provided by some outside agency who is fine with transferring the hashes, but would have qualms about transferring multi-petabytes of the matching CSAM images.
They are effectively low resolution hashes - obviously they would be completely useless if they fail to detect a re-encoded or slightly transformed or cropped image. In this sense it's a hash with a very high collision rate... probably even higher if you limit it to innocent but otherwise visually similar image of parents and grandparents sending pictures of their own toddlers as GP describes.
This is when it gets scary, demonising people based on a hash collision with no evidence or context.
Even with a database of hashes the risk remains. If someone gets off on nude children, then there is nothing stopping them from collecting innocent photographs from social media¹, reposting these on seedy or oniony websites, and have the hash ending up in the huge black box of CSAM hashes by an automated scraper. I am not under the impression that such a database is curated too closely.
1: This is not something I'm personally at risk of, because my parents are tech savvy enough not to post nude pics of a toddler anywhere but in a private chat with his parents (i.e., me and my wife).
That’s the implementation used by Apple for client-side scanning of iCloud uploads. NeuralHash or something. The EU may (and likely will) build an unrelated system, although it may share ideas with prior work.
Unless the exact algorithm and data used is described in the law you don't know what the implementation will look like (or what it will look like in ten years).
The problem at least in France is that prospective employers will demand your pay slips from your previous job. If you are early in your career, they will use this to depress your wages as much as possible, making arguments like "well, we can't just give you a 40% uplift". So if your first employer screws you, the ones that follow can as well.
Personally, I would just forge one with a much higher pay level - but most people who play by the rules get screwed royally.
I never have either, and this would be an immediate red flag in my book. If an employer has such bad practices when they try to recruit you, I can't imagine that working for them could be anything one would want.
The fact that someone can ask you for your salary before renting you an apartment is not equivalent to what you point to.
I would prefer this system to the Equifax's panopticon to be honest.
The best system would be to have a third party insure your rent. So you would only communicate these kind of information to the third party of your choice with which you would have a legal contract including a privacy clause.
That would make renting even more expensive and it is almost always a bad deal for anyone under a certain income.
You have to legislate that away or legislate heavy property tax for real estate that is not used for personal living. Which might be sensible and necessary anyway if you look at price developments.
Well and all the communist states too. Your personal ID was a small booklet that contained all your employment info. Police frequently checked it and told your workplace if you did anything out of the ordinary.
Closest I've had is current job, a global company, asking me first and last payslip of my previous employment, from which I was allowed/encouraged to retract information. I figure all they really wanted to check was employment and job title.
It never happened to me in 20+ years of working in France.
I've also almost always lied about my previous pay when asked (which recently has been less than before for some reason) to better match what I was seeking.
The US knew when <X> satellite imagery company's satellites were going to go overhead at some US base, waited for the image to be taken and then moved all its aircraft before a missile attack recently by Iran (or Iran proxies).
They know 100% who is buying what imagery, and when the satellites will be overhead.
There is 0% chance that this is a mistake. I wouldn't be surprised if the US can OK or not OK the images that make their way to Google Maps - in France, every government site gets censored before it makes its way to Google Maps.
.jpg){kind=link}