To add that, most electrical vehicles are usually plugged-in parked, meaning that this ranges applies whenever you start driving.
Batteries can be swapped faster than 60 gallon diesel tanks can be filled, nobody has done it in a widespread system yet but that doesn't make it infeasible.
Actually several companies have attempted at several level of deployment (including Tesla, Renault, etc.) but eventually drop the scheme simply due to lack of interest.
Most EV are usually charged while staying parked (in home charged during the night, chargers in public parkings during the day), and on a long trip you need to make regular breaks every few hours, so you might as well leave the car plugged in while you go pee, have a coffee, etc.
As such, battery swaping, though a nice technology, doesn't actually answer any real-world need in most use cases.
(It is useful, though, on racing vehicle, being very quick. The few experiment in racing EV I've read about all relied on quick-swapping battery to dramatically reduce pit stop time).
so your retinas could maybe get fried over-easy, but that would still require you stepping into an extremely tightly focused beam,
which is less likely with TFA's technology.
WattUp doesn't rely on a *single* highly directional antenna (which was also a solution attempted by some wireless power solutions), but on very large arrays of antennas (and beam forming, room modelling, etc.)
So there's not as much a single emitter that throws a single beam of microwave, but rather a roomful of small antenna that work all together trying to focus the power in a small pocket around the charged device.
There's no single high powered beam into which to step.
Actually, WattUp's technology stem from the same idea as behind this gadget :
Regular wireless emission would suffer from the inverse square law. So instead, you need to avoid spreading the power all over.
The thinkgeek gadget tries to solve the problem by using highly directional antennas.
WattUp attempts to solve it by using enormous arrays of antennas, beam forming, modelling of the room, etc. to try to focus the emitted energy as precisely as possible in pocket around the charged device.
No sorry, I didn't hear : I was too busy celebrating saturnalia~~
In all seriousness, people have been celebrating the period of the year with the shortest days for as long as they've been able to look up in the sky, and notice what a solstice is (provided they've moved far away enough out of the tropical region to actually have an easily observable solstice).
The fact the one specific small group decided to link this time of the year with some mythology about the birth of some dude who eventually ends up getting nailed on some wooden cross is at best a small foot note on the scale of the whole history of Homo sapiens.
If someone knew about this setup and was on your LAN they could wreak havoc with your server.
A well designed server farm would use a separate, segregated network for administration.
(That's actually part of the criticism against Intel ME/AMT : it listens on the same physical network connection, meaning potential exploits from an internet facing port)
Currently, not a lot of people are used to put doubt into video (or even real-time face-to-face video) because the technology to fake it realistically enough has only started very recently to become cheap enough to be a worthy try for an attacker: And it will still be a little bit more time until it start getting used in real-time (basically once " ${price of renting cloud GPU time to run the neural net} ${money that can be made in such attempts}" ).
Once awareness is raised, society will eventually adapt and only the most gullible will fall for the tricks while our successor on/. will wonder why not more people are using whatever authentication is the most common for video chatting.
A bit like how a couple of decades ago, every body was aware of signature forging and wouldn't trust a simply hand written note, but would fall for attempt at phone-calls social engineering (i.e.: impersonating a general role by being a good actor, back at a time where the phone quality would barely let you recognise a voice reliably).
Recognizing some code flow was a staple of the best decompiler back in the 90s : e.g. being able to recognize a certain code pattern (a sequence of ports smashing) as a high-level abstraction (initializing sound hardware).
Your idea would certainly be the 2010s-era equivalent. (= This portion looks like code reuse from "Zstd" decompressor)
x86 is hard to decompile. It doesn't have fixed length instructions, so it is difficult to figure out where opcodes begin and end. It is even possible to write code that can execute two different sequences of instructions by offsetting the instruction pointer by a byte. I don't think any decompiler could deobfusticate that.
The simple code dumper that comes with garden variety debugger won't easily deobfuscate that. (You need to manually ask the debugger to start dumping from the 2 overlapping point).
That why, the best decompilers available in the 90s used some sort of virtual machine to follow through the execution flow, and be able to distinguish such kind of "frame shifts" (that's actually a biology term, I've forgotten what the proper CS term is), and also be able to understand a bit of self-modifying code. (Basically, the decompiler will notice that various part of the code make calls into the same region but at an odd offset, and will automatically try dumping with from each overlapping point)
Makes it also possible to put actually-useful label/names into variable. (call something "sound_frequency" instead of "var184" because by following the data flow, the decompiler release that this is the parameter the is output to the PC-Speaker tone generator).
Sourcer by V-Com was one such good decompiler. (I managed to learn quite a ton of tricks like PCM play on the PC Speaker, tweaked graphical modes, etc. simply by using sr to inspect interesting executables. I even manage to desinfect a cracked game that was saddly being distributed infected with some virus)
a decompiler won't care whether you compiled a C++, assembler, C or whatever language the program being reversed was compiled on.
It will care, because some language (e.g.: C++) have specific data structures and ways (vtables) to handle some language specific features (object virtual member inheritance) which could be detected by the specific plugin (i.e.: instead of spewing a weird mess of nested "struct" and pointer-to-pointers, it can recognize that his is just a call to a virtual method) (for the few hipsters outthere : think the difference between vala and the corresponding GObject pure-C code).
When I first read the story, it sounded to me like just the 3D Vulkan driver was going to be open-sourced.
Correct, today article is about the official AMD's Vulkan driver joining the current giant open-source gang-band that has been going in the kernel. It's just he latest bit to be added.
Then I read this and it sounds like you are implying that the whole kit and caboodle has been open sourced.
Yup, the whole rest has been open-source more or less for ages. This last bit more or less completes everything (except for a few tiny bits that are only available in the closed-source GL and which only target a few weird cases, mostly closed-source CAD software on workstations and of absolutely no relevance in the Linux open-source word)
Is the is the KMS module and the regular X11 display (2d) driver also completely open source at this point?
Yes, absolutely completely, and actually doubly so.
- First round started with a bunch of opensouce efforts, some paid by third parties (historical efforts around opensourcing the r200), some by independing reverse engineering (a few independant playing with R600), and finally, after the AMD-ATI acquisition, AMD promising to opensource everything progressively.
This started the first wave of KMS / DRI / etc. of drivers, including the "radeon.ko" that was until recently. AMD even started paying their own opensource driver developpers, while still maintaining their own fglrx stack in parallel.
The opensource drivers have been getting progressively better, with AMD at one point deciding that mesa was going to be the official pre-HD Radeon (up to r400/r500) driver stack, and droping support out of fglrx.
- Second round came more recently around the time AMD started making GCN-based cards. They have decide the rewrite completely the bottom part of the stack (the KMS and DRI, mostly switching from "radeon.ko" to "amdgpu.ko"), with the aim of sharing this new code among multiple implementation (the same low level stack is used since by both the opensource mesa drivers, and the amdgpu-pro, which is the successor of fglrx), and also sharing the code among multiple OSes (sharing it with Windows among other. Unlike Intel who keep two separate stacks. But by rewriting everything from the ground up for this tasks, unlike Nvidia who basically beat their Windows code until it more or less compiles on Linux and standard API and laptop users being damned).
(Though incidentally, this new re-written layer, being the first time Linux-contact for lots of AMD multi-os devs, has been criticized for its quality and has only recently reach a quality level for the last bits - "DAL/DC" to be accepted upstream without Linus puking over the quality).
The long term idea was that mesa was going to be the official openGL driver - just like they did with older radeons - and amdgpu-pro was only to be used for the weird corner cases.
Longterm promises were to opensource the other driver component, including gpgpu stacks (ROCm and OpenCL, recently opensourced to the last bit, and currently getting up-streamed), and including the Vulkan driver (today's bit).
The rest of the stack (KMS and DRI) has been opensourced for quite some time. That enabled 3rd party devs to write their own Vulkan implementation (RADV) which has now matured into being quite feature complete and conformant.
(for the record of small detail : LLVM is the compiler currently used by various drivers including AMD to get gpu-specific code compiled into GPU binaries. e.g.: the GLSL and SPIR-V used by OpenGL shaders. AMD gets most of it upstreamed too, with bits of the gpgpu ROCm+OpenCL and the current Vulkan code still in the process of their pull-request)
I switched from Linux to BSD years ago, but I still have a Linux rig around (Devuan rig).
You would need a quite recent distro to join the latest opensource celebration and radeon expe
I've heard that all the required stuff for ROCm should be upstreamed by 4.16. Is that true?
I can't be of any help here. My information don't go beyond what's currently being spoken about on phoronix (though in addition to upstreaming stuff into the 4.16 kernel, I think there are also things that need to be upstreamed into LLVM too, for the CL language compilation, etc.) : My current work in research doesn't involve much gpgpu computing, and I haven't been playing at home with openCL cryptocoin mining for a while.
The driver code will show how to talk directly to the hardware;
The lower level of the stack has been available for ages:
Initially in the form of "radeon.ko" a separate opensource effort progressively more and more supported by AMD themselve.
And the "amdgpu.ko" as part of a complete rewrite from the ground up by AMD devs, with the aim to enable as much code sharing as possible including between multiple drivers stacks (used by both the usual opensource driver stack AMD has been supporting, and amdgpu-pro - basically a binary libGL.so that is the current day successor of fglrx) and between multiple OSes (a little bit like Nvidia is doing, and unlike Intel which have basically 2 stacks - but rewritten from the ground up for this purpose, unlike Nvidia who have basically punched their Windows code until it more or less compiles on Linux because why spending ressource playing nice with Linux API to make laptops work ?).
Recently DAL/DC has been accepted upstream in the amdgpu frame work (the above mentioned complete stack re-write wasn't done by the usual AMD opensource crew, but by mainly by their usual multi-OS drivers crew, meaning that the quality wasn't up to level at the beginning - Linus having loudly complained that it was a giant piling of useless abstraction layering. A few rewrite and quality improvement later and it's now upstream).
All these successive infrastructures have been successfully leveraged by mesa 3d, which now serves as the official AMD driver for nearly anything (amdgpu-pro is mainly recommended for workstation users that have that weird CAD software that relies on compatibility profiles). This is development which has been going in the open for ages, partially funded by AMD themselves.
Even Vulkan API itself isn't a big surprise. As AMD took so much time until getting all the necessary internal validation to release the Vulkan driver in opensource, independent developer have in the meantime - as a programming exercice - started the "RADV" vulkan driver, which by now ended up being nearly fully conformant and compatible with most games. (Well, it helps that by design the Vulkan API is a very thin layer above the lower level stack).
There isn't much new radical things to be discovered in that opensourcing. Most of the big chunk have already have been opened by AMD in the past. This is mainly a "good news" because AMD keeping up their promise to open up everything eventually (though they were slow on this last Vulkan part).
The only thing to be gained is to for the RADV developers to see how AMD official Vulkan has solved a few problems here and there that RADV might be missing. And because now the AMD driver is opensource, they could also do the same (see if tiny bits of RADV can be used as inspiration, without the legal department starting to scream that they are tainted).
you'll be able to reverse engineer this driver much more easily now that you'll have the code, and bypass it entirely for certain operations.
As mentioned above : there's not much to reverse engineer here. Vulkan API is a very thin layer to begin with, and all component underneath (to which you would be trying to "bypass") were already open sourced since ages, because those underneath component are the exact same (kernel module "amdgpu.ko", libDRM.so, etc.) also used by the opensource driver (mesa3d) and the opensource Vulkan experiment, in addition to being used by the AMD-written software (the amgdpu-pro libGL.so for workstation users, the currently being opensourced offical AMD vulkan driver, and the recently opensourced and currently getting accepting upstream gpgpu stack ROCm and OpenCL).
It doesn't bring much new to the table, it's just AMD being true to their opening promises.
That's as "right down on the metal" as it gets, and you won't be limited to just graphics, even though this driver might be, because you'll have access tot he entire lexicon, courtesy o
Oh, I think it is. In this era of GPU-driven machine learning, commitment == lockin. AMD is inviting people to play right down on the metal with this.
You got the wrong opensource driver.
Vulkan is about "right down on the metal" mostly in the graphics departement (through there are idea to run computations using Vulkan).
The "right down on the metal" drivers stack that got open sourced by AMD that target "GPU-driven machin learning" (and any other GPU computation), is the ROCm + OpenCL stack (with ROCm being the "down on the metal" part). AMD has recently finished their opensourcing efforts for that one too, and the necessary component are in the process of getting integrated up-stream (so soonish, your favorite Linux distro should be able to do ROCm and OpenCL right out of the box, instead of relying on custom package carefully crafted on 3rd party opensource repos).
Yup, there used to be, a long time ago, a period where basically you had closed-source FGLRX which was feature complete, but extremely buggy and crash-prone. And the then-recently started various opensource source drivers efforts (some by AMD opensource devs, other completely reverse engineered by 3rd party devs...) which were lacking lots of feature, though a lot more stable than the blobs.
That was about a decade ago.
In 2017, the official driver according to AMD *is* the opensource driver, it's feature complete (full support up to GL 4.5 and GLES 3.1, 4.6 should be ready soonish), maintained upstream (in vanilla kernel and mesa3d) by paid developpers including on AMD's payroll. It's fucking stable. (In my opinion, best experience with a rolling-release distro like openSUSE Tumbleweed - which has an up-to-date kernel/Mesa3d/LLVM and GPU drivers devs on their payroll)
Meanwhile, Nvidia are still problematic with laptops (mainly due to not playing nice with the linux API to handle weird stuff like optimus, etc.) sometime very broken (due to insisting on using user-mode-setting, on my laptop it's just plain broken whenever the laptops goes into/resumes sleep). I personally have to resort to nouveau, which is great piece of work (given the way it was developed through reverse engineering only) but needs to constantly play catch-up and will always be lagging feature-wise. (At least with my rolling distro, I'm getting fixes not long after they are written by the devs).
They've invested _a lot_ in open source graphics stack, release the specs (even they still have proprietary FGLXR driver)
I might even add : their opensource driver is now currently considered the "official recommended one", while AMDGPU-PRO (the current closed source one, basically the successor of FGLXR, but with bits rewritten from scratch for better code sharing with the opensource drivers - it's mostly only a blob "libGL.so") is currently only recommended for workstation users that have weird compatibility requirement for "that old mission-critical CAD software over there" that requires compatibility profiles.
but all in all, the open source driver is freaking fantastic (on older R280 mine beating FGLXR in performance on most open source games).
One of the reason for AMD to recommend the opensource drivers is exactly this.
Add to that the finally managed to get DAL/DC/whatever-it's-called-now upstream in the kernel, and the recently open-source ROCm + OpenCL stack is also in the process of getting upstreamed... It globally sounds very nice.
We just needs to see how this opensourced "official" Vuklan drivers co-evolves with the community-built "RADV" one.
So Apple paid $400 million to purchase a company that won't add additional functionality to iPhones (as you could already use Shazam for free)
Shazam, by itself alone as an app (and it's corresponding cloud-based server doing the data analysis), is of no direct value for Apple, indeed. The thing which is extremely interesting for Apple, is the tyapical users' workflow.
The user goes to some party, hears a nice ctachy song, wants to what it is.
Currently, the user will fire up Shazam or Sounhound (i.e.: record a bit of the song (or hum it), send the sound bit to the server, and get an answer). - "The song is ${XyZ} by ${AbC}." The next thing the user would like is to put this song aside. In theory, they could write the name into a note on the smartphone, but most apps offers the possibility to look into music providers (e.g.: Soundhound links into spotify, soundcloud an a few others. Shazaam is mentioned to handle Youtube, iTunes, etc.) That's usually how these apps manage to get a bit of money (in terms of kicks backs for sending in users to paying commercial music distribution).
*That's* what's interesting for Apple. Instead of an external 3rd party app, that points further into a dozen of diverse services, by acquiring Shazaam, Apple can slowly tune it and optimize it into bringing as many apple paying customers as possible.
They can leverage music identification services as a a form of free advertisement for music sold on iTunes. "- Hey Siri, what's this song ? - It's ${XyZ} by ${AbC}. Would like me to add it to your iTunes collection. Also, users who likes also like their song ${WvT} and also like the similar band ${DeF}" ( "Ka-Ching !" is the sound you now hear at Apple )
If doing this monetization correctly, it's going to be worth much more than 400 million to Apple. Paying 400 million for a technology that (Apple thinks) will bring more than 400 in : seems like a bargain to them.
The fact that Google can recognize a few songs without off-loading the processing to the cloud : great, but Apple has no interest in that. They need the user to be online anyway, because the thing which happens right next and which will bring money to Apple requires them to be online (and connected to Apple's music shop).
The executive taking the buyout decision have no interest in the exact details of how the technology is implemented (that's details for the weird bearded guys wearing pocket protectors that they underpay). What interests them is how much money they thing this could bring in, and currently, they see Shazaam as a wonderful way to funnel more users into buying music.
How in the fuck many planet hunters are there, and how long have they been doing it???
Basically, since the invention of the telescope, and thus the new possibility to see things that nobody could have seen before with a naked eye.
(e.g.: First new planets of our solar system discovered for the first time since antiquity ; William Herschel managing to discover Uranus. The Neptune getting discovered by maths. etc. - though Gallileo had observed it before but without realizing it was a new as-of-yet-unkown object)
Then better telescope offered the possibility to infere the presence of planets in other solar system than our (first one discovered at end of last century).
Eventually, a decade ago, NASA built Kepler, the best ever telescope at this task (because it was specifically designed to be able to fulfill this mission).
So in short : discovering new bodies in the sky has been a long history (since we could finally use something else than naked eyes). Kepler is the most recent such tool, and as it was built for exo-planet discovery among its missions, it's the current best tool.
"ME is turning into a colossal dumpster fire." Or maybe the equivalent of a billion dollar ad campaign against Intel.
Yeah, but in favor of whom ?
Look the other giant desktop/workstation/server CPUs maker : AMD. Since the curent Zen generation (and in laptop APU, since the previous generation, too) they have AMD PSP : an ARM core, which has few useful uses (storing keys like TPM, can be used to encrypt RAM transparentrly to avoid VMs trying to hack each other, etc.) but is a closed signed blob that can't be audited and has full RAM and bus access. (at least luckily, unlike Intel ME/AMT it doesn't listen on the network by default, doesn't handle firmware flashing, and doesn't keep working even when the CPU is powered off. These "light-out management" functionnality are usually handled by dedicated IPMI chips on server hardware - which luckily listens on a separate network). Though it seems that, in the light of the Intel ME scandals, AMD are trying to provide ways to make the PSP stop communicate with the outside once the system has initialised.
Take a step further back and at other giant CPU manufacturer : Qualcomm, the top maker of smartphone ARM SoCs.
Situation is even worse. On their socs, to make thing a tiny bit cheaper and a few functionnality easier, the baseband modem is integrated into the main SoC. And is in charge of tons of low-level functionnality - Init, RAM, etc. (basically, the modem serves as the chipset's northbridge). The problem, is that for legal reason it cannot run arbitrary code (because it communicates over special radio frequencies that aren't open but licensed, unlike the usual 2.4Ghz used by Wifi/BT/etc). The baseband modem can only legally run code (enforced by signatures checks) that is written by people holding the necessary license to emit stuff on the restricted frequencies used by 3G/4G. So only telco service providers and chipsets manufacturer can send code (with OTA) to the northbridge of your smartphone to run.
That's why projects like Purism's Librem 5 have to resort to underpowered unusual chips like Freescale 6mx / 8mx. That's about the largest popular manufacturer from which they can get SoC that don't require running any proprietary blob.
There's litteraly no huge big CPU manufacturer where you can avoid blobs at very frightening access levels to RAM.
But hey, at least all the above blobs are successfully used to handle DRM and thus online streaming works flawlessly. And all the clueless users are happy about their internet-TV working out of the box.
What about other vendors? Is your phone patched yet?
Yes, my Jolla 1 smartphone (2013) is patched against BlueBorne since version 2.1.2 (currently at 2.1.3, like virtually any thing supported by Sailfish OS).
The catch : It's not android. It's a full blown GNU/Linux smartphone OS, by the same guys who used to do Meamo/Meego at Nokia (until the whole Elop/Microsoft shit-storm happened to them).
What good is a $3000 video board if the drivers are acting up?
The main target segment for this card is scientific computation. Most of the Titan Vs sold are going to end-up on Linux compute nodes in some universities or other. Their output connectors are almost not likely to get plugged into anything ever. Not a problem if their Direct X drivers are acting up a bit. CUDA SDK is the thing that they most definitely need to get working right.
In terms of volume sold, the few hardcore extreme enthusiast gamers who are going to stuff them into Windows workstations are only icing on the cake.
It's funny because I used to think AMD's drivers were crap, but since switching from an AMD A-10 to an NVidia GTX, and updated drivers, all kinds of bugs and errors manifest.
AMD drivers crap ? On windows, maybe. (Haven't tested since long time ago) On Linux, since AMD finished transitioning to the opensource stack (well except for the ROCm/OpenCL bits and the current opensource source Vulkan still not being the official AMD one), their drivers are among the best.
Normally, this kind of graphic cards are supported by the proprietary closed-source drivers for Linux, and corresponding CUDA SDK.
It wouldn't make much sense for Nvidia to NOT release Linux support for it, as an GPU-based AI-accelerator, they would be missing on the big Linux HPC market segment (common is there any super computer still rellevant nowadays that doesn't run any unix ?) Though they would definitely be supporting Windows too (not to miss on the lucrative "extreme gamer enthousiast" market, and people working in graphics)
The whole point of Nvidia's proprietary Linux driver is that they can share code base with their Windows drivers.
(And it doesn't matter if this driver doesn't properly mode set onlinux : on Linux Titan V are most likely to end-up on headless compute nodes on some cluster) (Neither does it matter if this driver can't properly resume after a suspend : on Linux Titan Vs aren't going to be used in laptops. Ever).
Nope, your hosts doesn't work in the case of malicious javascript code. You can't block just scripts, while still letting the plain HTML webpages. A "hosts" entry can only block access to a whole domain.
Also it depends on the "hosts" list containing the new threat (it's fundamentally a black-listing approach. If a threat isn't known, a hosts list cannot prevent it). Systems like NoScripts are White-Listing. They block by default unless told otherwise. I could never be affected by malicious javascript code running on "http://cloudflare.solutions/" even before I hard about it, because it's not among my whitelists.
Also you bullshit only runs on Windows, and there's no source available for review. Not interested.
I'm going to go ahead and stick my head in a bear trap, but why does Mozilla rely so much on outside programmers to make the thing even borderline secure? I understand the reasoning not to include ad blockers, but some of the other commonly used extensions should just be baked in. Or am I really just too paranoid?
In a way you are paranoid, in that unlike most of the typical users you value your security much more than ease of use.
Most of the user don't have any idea about security. On the other hand, most of the users want to just watch their Netflix movie, post their shit on Facebook, etc. they want all the typical online activity to work straight out of the box.
Saddly, the current accepted standard behavious of *ALL* browser, is to download and execute any bullshit linked in a web page, no question asked (though there are very tiny baby steps being made, like the "allow origin" HTTP(S) directive to restrict some APIs accross different webservers). That's how chromium works, that's how microsoft edge work.
Web designers thus design the pages you visit taking that into account (just look at all the the external scripts downloaded by most of the webpages. Any random simple thing that you visit, like a webshop to order something online, downloads and executes javascript libraries from at least a dozen of different 3rd parties, some of which are absolutely critical for even the basic functionnality of the webshop to work. Not everything from 3rd party is something nefarious like a tracker).
So if suddenly firefox were to by default block all non-whitelisted scripts, or block all script no originating from the same domain, most of the users will be seeing their usual web sites not working.
They will not be appreciating the sudden new added security to Firefox compared to everything else, they would be mostly noticing that most of "their web" is broken compared to any other browser. You'd see backlash against non functioning stuff out-of-the-box. You'd see users complaining that they need to whitelist and fine tune tons of stuff just to get facebook working. You'd see less advanced users complaining that they don't even understand what a "whitelist" is, and why the hell does the netflix pages stays entirely black ?
So that's the current situation, current normal usage patterns (leading to current design techniques) lead to a situation which makes it hard any increase of security without fundamentally breaking the online experience.
So, therefore, good Javascript blockers needs currently to be only offered as extensions for power users who know what they do, and are not affraid to do some tweaking to get the website to work back again.
Note: all the above only applies to the standard Firefox package as installed from the website.
Special package targetting specific user base differ : the Firefox browser packaged as part of the Tor browser bundle has quite a few security extensions installed and enabled by default.
Being concerned when Mozilla breaks security extensions isn't 'bitching'.
Which security extensions got broken ? Most of the major ones got ported to WebExtension API well in advance. The ones that were not ready on D-day, managed to get ready over the few days after the big switch.
Really in practice, I haven't anyone I know bitten by missing security extensions.
If you're complaining that your specific security extension got broken, means :
- you're using a very rare one. at least it means the biggest part of firefox users (those who use the most common security extensions) aren't affected. Only the few eccentric people with unusual choices of extensions are affected and they a re much smaller fraction of the user base.
- you're using a very rare extension, which is used by an extremely small number of other users. That might be a little bit problematic regarding security because it means less opportunity to discover and fix bugs in the extension. (Though some might argue that you could also be protected by the relative obscurity of your extension. There might be obvious ways to circumvent the security, but because there are only 5 users of this extension, nobody bothers to check).
- the author of the extension hasn't bothered to upgrade youre extension for over a year. That by it self is a major security problem. It also means that, even if you keep the latest ESR version of Firefox instead of upgrading, your extension hasn't been fixed against any problem that might have been discovered over the past year.
It's disturbing that you, and apparently Mozilla, take such a carefree attitude about the security of FF's users.
Mozilla hasn't been taking a carefree attitude. They have been actively collaborating with the developers of extensions, including lots of security extensions, including the most popular extensions, just to make sure that WebExtension API provides everything needed to make the old XUL extensions portable to the new API.
I don't have a carefree attitude about security neither. That's why I have been following the evolution closely as soon as there was announcement about future deprecation of XUL extension (in fact even earlier : I've been following since the release of Electrolysis and other such stability/security features - because even back before announcement of API deprecation, some of these extra features did rely on all installed extensions only using the Webextension API). I've been checking the development of the extensions I use, and observed that lots of them were available rather fast with the new API. Even more so among security extensions, they were probably the fastest to react and port their code (or in the case of NoScript's guy : start to collaborate with Mozilla to see how the API could be adapted to their need).
All extensions that worked with FF 56 should have worked with FF 57. There's no excuse for them not to have worked.
I think that "this extensions was written 10 years ago and since then we're not even sure if the dev is still alive" might be a good excuse, specially for a security extension (you know, those things are supposed to be kept up to date and adapted as new security threats arrive).
Slashdot Mirror
300-500 miles isn't anemic range
To add that, most electrical vehicles are usually plugged-in parked, meaning that this ranges applies whenever you start driving.
Batteries can be swapped faster than 60 gallon diesel tanks can be filled, nobody has done it in a widespread system yet but that doesn't make it infeasible.
Actually several companies have attempted at several level of deployment (including Tesla, Renault, etc.) but eventually drop the scheme simply due to lack of interest.
Most EV are usually charged while staying parked (in home charged during the night, chargers in public parkings during the day), and on a long trip you need to make regular breaks every few hours, so you might as well leave the car plugged in while you go pee, have a coffee, etc.
As such, battery swaping, though a nice technology, doesn't actually answer any real-world need in most use cases.
(It is useful, though, on racing vehicle, being very quick. The few experiment in racing EV I've read about all relied on quick-swapping battery to dramatically reduce pit stop time).
so your retinas could maybe get fried over-easy, but that would still require you stepping into an extremely tightly focused beam,
which is less likely with TFA's technology.
WattUp doesn't rely on a *single* highly directional antenna (which was also a solution attempted by some wireless power solutions), but on very large arrays of antennas (and beam forming, room modelling, etc.)
So there's not as much a single emitter that throws a single beam of microwave, but rather a roomful of small antenna that work all together trying to focus the power in a small pocket around the charged device.
There's no single high powered beam into which to step.
Actually, WattUp's technology stem from the same idea as behind this gadget :
Regular wireless emission would suffer from the inverse square law.
So instead, you need to avoid spreading the power all over.
The thinkgeek gadget tries to solve the problem by using highly directional antennas.
WattUp attempts to solve it by using enormous arrays of antennas, beam forming, modelling of the room, etc. to try to focus the emitted energy as precisely as possible in pocket around the charged device.
No sorry, I didn't hear : I was too busy celebrating saturnalia~~
In all seriousness, people have been celebrating the period of the year with the shortest days for as long as they've been able to look up in the sky, and notice what a solstice is (provided they've moved far away enough out of the tropical region to actually have an easily observable solstice).
The fact the one specific small group decided to link this time of the year with some mythology about the birth of some dude who eventually ends up getting nailed on some wooden cross is at best a small foot note on the scale of the whole history of Homo sapiens.
If someone knew about this setup and was on your LAN they could wreak havoc with your server.
A well designed server farm would use a separate, segregated network for administration.
(That's actually part of the criticism against Intel ME/AMT : it listens on the same physical network connection, meaning potential exploits from an internet facing port)
Currently, not a lot of people are used to put doubt into video (or even real-time face-to-face video) because the technology to fake it realistically enough has only started very recently to become cheap enough to be a worthy try for an attacker: And it will still be a little bit more time until it start getting used in real-time (basically once " ${price of renting cloud GPU time to run the neural net} ${money that can be made in such attempts}" ).
Once awareness is raised, society will eventually adapt and only the most gullible will fall for the tricks while our successor on /. will wonder why not more people are using whatever authentication is the most common for video chatting.
A bit like how a couple of decades ago, every body was aware of signature forging and wouldn't trust a simply hand written note, but would fall for attempt at phone-calls social engineering (i.e.: impersonating a general role by being a good actor, back at a time where the phone quality would barely let you recognise a voice reliably).
You realize that most of the work of Google requires electricity, do you ?
Or do you suggest that Google actually sets up inside Kim Jong Un's own palace ?
the structure of calls across functions
Recognizing some code flow was a staple of the best decompiler back in the 90s :
e.g. being able to recognize a certain code pattern (a sequence of ports smashing) as a high-level abstraction (initializing sound hardware).
Your idea would certainly be the 2010s-era equivalent. (= This portion looks like code reuse from "Zstd" decompressor)
x86 is hard to decompile. It doesn't have fixed length instructions, so it is difficult to figure out where opcodes begin and end. It is even possible to write code that can execute two different sequences of instructions by offsetting the instruction pointer by a byte. I don't think any decompiler could deobfusticate that.
The simple code dumper that comes with garden variety debugger won't easily deobfuscate that. (You need to manually ask the debugger to start dumping from the 2 overlapping point).
That why, the best decompilers available in the 90s used some sort of virtual machine to follow through the execution flow, and be able to distinguish such kind of "frame shifts" (that's actually a biology term, I've forgotten what the proper CS term is), and also be able to understand a bit of self-modifying code.
(Basically, the decompiler will notice that various part of the code make calls into the same region but at an odd offset, and will automatically try dumping with from each overlapping point)
Makes it also possible to put actually-useful label/names into variable. (call something "sound_frequency" instead of "var184" because by following the data flow, the decompiler release that this is the parameter the is output to the PC-Speaker tone generator).
Sourcer by V-Com was one such good decompiler.
(I managed to learn quite a ton of tricks like PCM play on the PC Speaker, tweaked graphical modes, etc. simply by using sr to inspect interesting executables.
I even manage to desinfect a cracked game that was saddly being distributed infected with some virus)
a decompiler won't care whether you compiled a C++, assembler, C or whatever language the program being reversed was compiled on.
It will care, because some language (e.g.: C++) have specific data structures and ways (vtables) to handle some language specific features (object virtual member inheritance) which could be detected by the specific plugin (i.e.: instead of spewing a weird mess of nested "struct" and pointer-to-pointers, it can recognize that his is just a call to a virtual method)
(for the few hipsters outthere : think the difference between vala and the corresponding GObject pure-C code).
When I first read the story, it sounded to me like just the 3D Vulkan driver was going to be open-sourced.
Correct, today article is about the official AMD's Vulkan driver joining the current giant open-source gang-band that has been going in the kernel.
It's just he latest bit to be added.
Then I read this and it sounds like you are implying that the whole kit and caboodle has been open sourced.
Yup, the whole rest has been open-source more or less for ages. This last bit more or less completes everything (except for a few tiny bits that are only available in the closed-source GL and which only target a few weird cases, mostly closed-source CAD software on workstations and of absolutely no relevance in the Linux open-source word)
Is the is the KMS module and the regular X11 display (2d) driver also completely open source at this point?
Yes, absolutely completely, and actually doubly so.
- First round started with a bunch of opensouce efforts, some paid by third parties (historical efforts around opensourcing the r200), some by independing reverse engineering (a few independant playing with R600), and finally, after the AMD-ATI acquisition, AMD promising to opensource everything progressively.
This started the first wave of KMS / DRI / etc. of drivers, including the "radeon.ko" that was until recently.
AMD even started paying their own opensource driver developpers, while still maintaining their own fglrx stack in parallel.
The opensource drivers have been getting progressively better, with AMD at one point deciding that mesa was going to be the official pre-HD Radeon (up to r400/r500) driver stack, and droping support out of fglrx.
- Second round came more recently around the time AMD started making GCN-based cards.
They have decide the rewrite completely the bottom part of the stack (the KMS and DRI, mostly switching from "radeon.ko" to "amdgpu.ko"), with the aim of sharing this new code among multiple implementation (the same low level stack is used since by both the opensource mesa drivers, and the amdgpu-pro, which is the successor of fglrx), and also sharing the code among multiple OSes (sharing it with Windows among other. Unlike Intel who keep two separate stacks. But by rewriting everything from the ground up for this tasks, unlike Nvidia who basically beat their Windows code until it more or less compiles on Linux and standard API and laptop users being damned).
(Though incidentally, this new re-written layer, being the first time Linux-contact for lots of AMD multi-os devs, has been criticized for its quality and has only recently reach a quality level for the last bits - "DAL/DC" to be accepted upstream without Linus puking over the quality).
The long term idea was that mesa was going to be the official openGL driver - just like they did with older radeons - and amdgpu-pro was only to be used for the weird corner cases.
Longterm promises were to opensource the other driver component, including gpgpu stacks (ROCm and OpenCL, recently opensourced to the last bit, and currently getting up-streamed), and including the Vulkan driver (today's bit).
The rest of the stack (KMS and DRI) has been opensourced for quite some time. That enabled 3rd party devs to write their own Vulkan implementation (RADV) which has now matured into being quite feature complete and conformant.
(for the record of small detail : LLVM is the compiler currently used by various drivers including AMD to get gpu-specific code compiled into GPU binaries.
e.g.: the GLSL and SPIR-V used by OpenGL shaders.
AMD gets most of it upstreamed too, with bits of the gpgpu ROCm+OpenCL and the current Vulkan code still in the process of their pull-request)
I switched from Linux to BSD years ago, but I still have a Linux rig around (Devuan rig).
You would need a quite recent distro to join the latest opensource celebration and radeon expe
I've heard that all the required stuff for ROCm should be upstreamed by 4.16. Is that true?
I can't be of any help here. My information don't go beyond what's currently being spoken about on phoronix
(though in addition to upstreaming stuff into the 4.16 kernel, I think there are also things that need to be upstreamed into LLVM too, for the CL language compilation, etc.) : My current work in research doesn't involve much gpgpu computing, and I haven't been playing at home with openCL cryptocoin mining for a while.
The driver code will show how to talk directly to the hardware;
The lower level of the stack has been available for ages :
Initially in the form of "radeon.ko" a separate opensource effort progressively more and more supported by AMD themselve.
And the "amdgpu.ko" as part of a complete rewrite from the ground up by AMD devs, with the aim to enable as much code sharing as possible including between multiple drivers stacks (used by both the usual opensource driver stack AMD has been supporting, and amdgpu-pro - basically a binary libGL.so that is the current day successor of fglrx) and between multiple OSes (a little bit like Nvidia is doing, and unlike Intel which have basically 2 stacks - but rewritten from the ground up for this purpose, unlike Nvidia who have basically punched their Windows code until it more or less compiles on Linux because why spending ressource playing nice with Linux API to make laptops work ?).
Recently DAL/DC has been accepted upstream in the amdgpu frame work (the above mentioned complete stack re-write wasn't done by the usual AMD opensource crew, but by mainly by their usual multi-OS drivers crew, meaning that the quality wasn't up to level at the beginning - Linus having loudly complained that it was a giant piling of useless abstraction layering. A few rewrite and quality improvement later and it's now upstream).
All these successive infrastructures have been successfully leveraged by mesa 3d, which now serves as the official AMD driver for nearly anything (amdgpu-pro is mainly recommended for workstation users that have that weird CAD software that relies on compatibility profiles).
This is development which has been going in the open for ages, partially funded by AMD themselves.
Even Vulkan API itself isn't a big surprise. As AMD took so much time until getting all the necessary internal validation to release the Vulkan driver in opensource, independent developer have in the meantime - as a programming exercice - started the "RADV" vulkan driver, which by now ended up being nearly fully conformant and compatible with most games.
(Well, it helps that by design the Vulkan API is a very thin layer above the lower level stack).
There isn't much new radical things to be discovered in that opensourcing. Most of the big chunk have already have been opened by AMD in the past.
This is mainly a "good news" because AMD keeping up their promise to open up everything eventually (though they were slow on this last Vulkan part).
The only thing to be gained is to for the RADV developers to see how AMD official Vulkan has solved a few problems here and there that RADV might be missing. And because now the AMD driver is opensource, they could also do the same (see if tiny bits of RADV can be used as inspiration, without the legal department starting to scream that they are tainted).
you'll be able to reverse engineer this driver much more easily now that you'll have the code, and bypass it entirely for certain operations.
As mentioned above : there's not much to reverse engineer here.
Vulkan API is a very thin layer to begin with, and all component underneath (to which you would be trying to "bypass") were already open sourced since ages, because those underneath component are the exact same (kernel module "amdgpu.ko", libDRM.so, etc.) also used by the opensource driver (mesa3d) and the opensource Vulkan experiment, in addition to being used by the AMD-written software (the amgdpu-pro libGL.so for workstation users, the currently being opensourced offical AMD vulkan driver, and the recently opensourced and currently getting accepting upstream gpgpu stack ROCm and OpenCL).
It doesn't bring much new to the table, it's just AMD being true to their opening promises.
That's as "right down on the metal" as it gets, and you won't be limited to just graphics, even though this driver might be, because you'll have access tot he entire lexicon, courtesy o
Oh, I think it is. In this era of GPU-driven machine learning, commitment == lockin. AMD is inviting people to play right down on the metal with this.
You got the wrong opensource driver.
Vulkan is about "right down on the metal" mostly in the graphics departement (through there are idea to run computations using Vulkan).
The "right down on the metal" drivers stack that got open sourced by AMD that target "GPU-driven machin learning" (and any other GPU computation), is the ROCm + OpenCL stack (with ROCm being the "down on the metal" part).
AMD has recently finished their opensourcing efforts for that one too, and the necessary component are in the process of getting integrated up-stream (so soonish, your favorite Linux distro should be able to do ROCm and OpenCL right out of the box, instead of relying on custom package carefully crafted on 3rd party opensource repos).
Yup, there used to be, a long time ago, a period where basically you had closed-source FGLRX which was feature complete, but extremely buggy and crash-prone. And the then-recently started various opensource source drivers efforts (some by AMD opensource devs, other completely reverse engineered by 3rd party devs...) which were lacking lots of feature, though a lot more stable than the blobs.
That was about a decade ago.
In 2017, the official driver according to AMD *is* the opensource driver, it's feature complete (full support up to GL 4.5 and GLES 3.1, 4.6 should be ready soonish), maintained upstream (in vanilla kernel and mesa3d) by paid developpers including on AMD's payroll.
It's fucking stable.
(In my opinion, best experience with a rolling-release distro like openSUSE Tumbleweed - which has an up-to-date kernel/Mesa3d/LLVM and GPU drivers devs on their payroll)
Meanwhile, Nvidia are still problematic with laptops (mainly due to not playing nice with the linux API to handle weird stuff like optimus, etc.) sometime very broken (due to insisting on using user-mode-setting, on my laptop it's just plain broken whenever the laptops goes into/resumes sleep).
I personally have to resort to nouveau, which is great piece of work (given the way it was developed through reverse engineering only) but needs to constantly play catch-up and will always be lagging feature-wise.
(At least with my rolling distro, I'm getting fixes not long after they are written by the devs).
They've invested _a lot_ in open source graphics stack, release the specs (even they still have proprietary FGLXR driver)
I might even add :
their opensource driver is now currently considered the "official recommended one", while AMDGPU-PRO (the current closed source one, basically the successor of FGLXR, but with bits rewritten from scratch for better code sharing with the opensource drivers - it's mostly only a blob "libGL.so") is currently only recommended for workstation users that have weird compatibility requirement for "that old mission-critical CAD software over there" that requires compatibility profiles.
but all in all, the open source driver is freaking fantastic (on older R280 mine beating FGLXR in performance on most open source games).
One of the reason for AMD to recommend the opensource drivers is exactly this.
Add to that the finally managed to get DAL/DC/whatever-it's-called-now upstream in the kernel, and the recently open-source ROCm + OpenCL stack is also in the process of getting upstreamed...
It globally sounds very nice.
We just needs to see how this opensourced "official" Vuklan drivers co-evolves with the community-built "RADV" one.
So Apple paid $400 million to purchase a company that won't add additional functionality to iPhones (as you could already use Shazam for free)
Shazam, by itself alone as an app (and it's corresponding cloud-based server doing the data analysis), is of no direct value for Apple, indeed.
The thing which is extremely interesting for Apple, is the tyapical users' workflow.
The user goes to some party, hears a nice ctachy song, wants to what it is.
Currently, the user will fire up Shazam or Sounhound (i.e.: record a bit of the song (or hum it), send the sound bit to the server, and get an answer).
- "The song is ${XyZ} by ${AbC}."
The next thing the user would like is to put this song aside. In theory, they could write the name into a note on the smartphone, but most apps offers the possibility to look into music providers (e.g.: Soundhound links into spotify, soundcloud an a few others. Shazaam is mentioned to handle Youtube, iTunes, etc.)
That's usually how these apps manage to get a bit of money (in terms of kicks backs for sending in users to paying commercial music distribution).
*That's* what's interesting for Apple. Instead of an external 3rd party app, that points further into a dozen of diverse services, by acquiring Shazaam, Apple can slowly tune it and optimize it into bringing as many apple paying customers as possible.
They can leverage music identification services as a a form of free advertisement for music sold on iTunes.
"- Hey Siri, what's this song ?
- It's ${XyZ} by ${AbC}. Would like me to add it to your iTunes collection.
Also, users who likes also like their song ${WvT} and also like the similar band ${DeF}"
( "Ka-Ching !" is the sound you now hear at Apple )
If doing this monetization correctly, it's going to be worth much more than 400 million to Apple.
Paying 400 million for a technology that (Apple thinks) will bring more than 400 in : seems like a bargain to them.
The fact that Google can recognize a few songs without off-loading the processing to the cloud : great, but Apple has no interest in that.
They need the user to be online anyway, because the thing which happens right next and which will bring money to Apple requires them to be online (and connected to Apple's music shop).
The executive taking the buyout decision have no interest in the exact details of how the technology is implemented (that's details for the weird bearded guys wearing pocket protectors that they underpay). What interests them is how much money they thing this could bring in, and currently, they see Shazaam as a wonderful way to funnel more users into buying music.
How in the fuck many planet hunters are there, and how long have they been doing it???
Basically, since the invention of the telescope, and thus the new possibility to see things that nobody could have seen before with a naked eye.
(e.g.: First new planets of our solar system discovered for the first time since antiquity ; William Herschel managing to discover Uranus. The Neptune getting discovered by maths. etc. - though Gallileo had observed it before but without realizing it was a new as-of-yet-unkown object)
Then better telescope offered the possibility to infere the presence of planets in other solar system than our (first one discovered at end of last century).
Eventually, a decade ago, NASA built Kepler, the best ever telescope at this task (because it was specifically designed to be able to fulfill this mission).
So in short : discovering new bodies in the sky has been a long history (since we could finally use something else than naked eyes).
Kepler is the most recent such tool, and as it was built for exo-planet discovery among its missions, it's the current best tool.
"ME is turning into a colossal dumpster fire."
Or maybe the equivalent of a billion dollar ad campaign against Intel.
Yeah, but in favor of whom ?
Look the other giant desktop/workstation/server CPUs maker :
AMD.
Since the curent Zen generation (and in laptop APU, since the previous generation, too) they have AMD PSP : an ARM core, which has few useful uses (storing keys like TPM, can be used to encrypt RAM transparentrly to avoid VMs trying to hack each other, etc.) but is a closed signed blob that can't be audited and has full RAM and bus access.
(at least luckily, unlike Intel ME/AMT it doesn't listen on the network by default, doesn't handle firmware flashing, and doesn't keep working even when the CPU is powered off. These "light-out management" functionnality are usually handled by dedicated IPMI chips on server hardware - which luckily listens on a separate network).
Though it seems that, in the light of the Intel ME scandals, AMD are trying to provide ways to make the PSP stop communicate with the outside once the system has initialised.
Take a step further back and at other giant CPU manufacturer :
Qualcomm, the top maker of smartphone ARM SoCs.
Situation is even worse. On their socs, to make thing a tiny bit cheaper and a few functionnality easier, the baseband modem is integrated into the main SoC. And is in charge of tons of low-level functionnality - Init, RAM, etc. (basically, the modem serves as the chipset's northbridge).
The problem, is that for legal reason it cannot run arbitrary code (because it communicates over special radio frequencies that aren't open but licensed, unlike the usual 2.4Ghz used by Wifi/BT/etc). The baseband modem can only legally run code (enforced by signatures checks) that is written by people holding the necessary license to emit stuff on the restricted frequencies used by 3G/4G.
So only telco service providers and chipsets manufacturer can send code (with OTA) to the northbridge of your smartphone to run.
That's why projects like Purism's Librem 5 have to resort to underpowered unusual chips like Freescale 6mx / 8mx. That's about the largest popular manufacturer from which they can get SoC that don't require running any proprietary blob.
There's litteraly no huge big CPU manufacturer where you can avoid blobs at very frightening access levels to RAM.
But hey, at least all the above blobs are successfully used to handle DRM and thus online streaming works flawlessly. And all the clueless users are happy about their internet-TV working out of the box.
What about other vendors? Is your phone patched yet?
Yes, my Jolla 1 smartphone (2013) is patched against BlueBorne since version 2.1.2 (currently at 2.1.3, like virtually any thing supported by Sailfish OS).
The catch : It's not android. It's a full blown GNU/Linux smartphone OS, by the same guys who used to do Meamo/Meego at Nokia (until the whole Elop/Microsoft shit-storm happened to them).
What good is a $3000 video board if the drivers are acting up?
The main target segment for this card is scientific computation.
Most of the Titan Vs sold are going to end-up on Linux compute nodes in some universities or other.
Their output connectors are almost not likely to get plugged into anything ever.
Not a problem if their Direct X drivers are acting up a bit.
CUDA SDK is the thing that they most definitely need to get working right.
In terms of volume sold, the few hardcore extreme enthusiast gamers who are going to stuff them into Windows workstations are only icing on the cake.
It's funny because I used to think AMD's drivers were crap, but since switching from an AMD A-10 to an NVidia GTX, and updated drivers, all kinds of bugs and errors manifest.
AMD drivers crap ?
On windows, maybe. (Haven't tested since long time ago)
On Linux, since AMD finished transitioning to the opensource stack (well except for the ROCm/OpenCL bits and the current opensource source Vulkan still not being the official AMD one), their drivers are among the best.
Normally, this kind of graphic cards are supported by the proprietary closed-source drivers for Linux, and corresponding CUDA SDK.
It wouldn't make much sense for Nvidia to NOT release Linux support for it, as an GPU-based AI-accelerator, they would be missing on the big Linux HPC market segment (common is there any super computer still rellevant nowadays that doesn't run any unix ?)
Though they would definitely be supporting Windows too (not to miss on the lucrative "extreme gamer enthousiast" market, and people working in graphics)
The whole point of Nvidia's proprietary Linux driver is that they can share code base with their Windows drivers.
(And it doesn't matter if this driver doesn't properly mode set onlinux : on Linux Titan V are most likely to end-up on headless compute nodes on some cluster)
(Neither does it matter if this driver can't properly resume after a suspend : on Linux Titan Vs aren't going to be used in laptops. Ever).
Dear "hosts" APK troll.
Nope, your hosts doesn't work in the case of malicious javascript code.
You can't block just scripts, while still letting the plain HTML webpages.
A "hosts" entry can only block access to a whole domain.
Also it depends on the "hosts" list containing the new threat (it's fundamentally a black-listing approach. If a threat isn't known, a hosts list cannot prevent it).
Systems like NoScripts are White-Listing. They block by default unless told otherwise. I could never be affected by malicious javascript code running on "http://cloudflare.solutions/" even before I hard about it, because it's not among my whitelists.
Also you bullshit only runs on Windows, and there's no source available for review. Not interested.
I'm going to go ahead and stick my head in a bear trap, but why does Mozilla rely so much on outside programmers to make the thing even borderline secure? I understand the reasoning not to include ad blockers, but some of the other commonly used extensions should just be baked in. Or am I really just too paranoid?
In a way you are paranoid, in that unlike most of the typical users you value your security much more than ease of use.
Most of the user don't have any idea about security. On the other hand, most of the users want to just watch their Netflix movie, post their shit on Facebook, etc. they want all the typical online activity to work straight out of the box.
Saddly, the current accepted standard behavious of *ALL* browser, is to download and execute any bullshit linked in a web page, no question asked
(though there are very tiny baby steps being made, like the "allow origin" HTTP(S) directive to restrict some APIs accross different webservers).
That's how chromium works, that's how microsoft edge work.
Web designers thus design the pages you visit taking that into account (just look at all the the external scripts downloaded by most of the webpages. Any random simple thing that you visit, like a webshop to order something online, downloads and executes javascript libraries from at least a dozen of different 3rd parties, some of which are absolutely critical for even the basic functionnality of the webshop to work. Not everything from 3rd party is something nefarious like a tracker).
So if suddenly firefox were to by default block all non-whitelisted scripts, or block all script no originating from the same domain, most of the users will be seeing their usual web sites not working.
They will not be appreciating the sudden new added security to Firefox compared to everything else, they would be mostly noticing that most of "their web" is broken compared to any other browser.
You'd see backlash against non functioning stuff out-of-the-box.
You'd see users complaining that they need to whitelist and fine tune tons of stuff just to get facebook working.
You'd see less advanced users complaining that they don't even understand what a "whitelist" is, and why the hell does the netflix pages stays entirely black ?
So that's the current situation, current normal usage patterns (leading to current design techniques) lead to a situation which makes it hard any increase of security without fundamentally breaking the online experience.
So, therefore, good Javascript blockers needs currently to be only offered as extensions for power users who know what they do, and are not affraid to do some tweaking to get the website to work back again.
Note: all the above only applies to the standard Firefox package as installed from the website.
Special package targetting specific user base differ :
the Firefox browser packaged as part of the Tor browser bundle has quite a few security extensions installed and enabled by default.
Being concerned when Mozilla breaks security extensions isn't 'bitching'.
Which security extensions got broken ?
Most of the major ones got ported to WebExtension API well in advance.
The ones that were not ready on D-day, managed to get ready over the few days after the big switch.
Really in practice, I haven't anyone I know bitten by missing security extensions.
If you're complaining that your specific security extension got broken, means :
- you're using a very rare one. at least it means the biggest part of firefox users (those who use the most common security extensions) aren't affected. Only the few eccentric people with unusual choices of extensions are affected and they a re much smaller fraction of the user base.
- you're using a very rare extension, which is used by an extremely small number of other users. That might be a little bit problematic regarding security because it means less opportunity to discover and fix bugs in the extension.
(Though some might argue that you could also be protected by the relative obscurity of your extension. There might be obvious ways to circumvent the security, but because there are only 5 users of this extension, nobody bothers to check).
- the author of the extension hasn't bothered to upgrade youre extension for over a year. That by it self is a major security problem. It also means that, even if you keep the latest ESR version of Firefox instead of upgrading, your extension hasn't been fixed against any problem that might have been discovered over the past year.
It's disturbing that you, and apparently Mozilla, take such a carefree attitude about the security of FF's users.
Mozilla hasn't been taking a carefree attitude. They have been actively collaborating with the developers of extensions, including lots of security extensions, including the most popular extensions, just to make sure that WebExtension API provides everything needed to make the old XUL extensions portable to the new API.
I don't have a carefree attitude about security neither.
That's why I have been following the evolution closely as soon as there was announcement about future deprecation of XUL extension (in fact even earlier : I've been following since the release of Electrolysis and other such stability/security features - because even back before announcement of API deprecation, some of these extra features did rely on all installed extensions only using the Webextension API).
I've been checking the development of the extensions I use, and observed that lots of them were available rather fast with the new API. Even more so among security extensions, they were probably the fastest to react and port their code (or in the case of NoScript's guy : start to collaborate with Mozilla to see how the API could be adapted to their need).
All extensions that worked with FF 56 should have worked with FF 57. There's no excuse for them not to have worked.
I think that "this extensions was written 10 years ago and since then we're not even sure if the dev is still alive" might be a good excuse, specially for a security extension (you know, those things are supposed to be kept up to date and adapted as new security threats arrive).