> If the device was validating the server certificate, it wouldn’t make it this far, so that shows that our certificate was accepted.
One more very good reason for preventing requests to "the cloud".
However, I find it funny that the lack of proper certificate validation (which is a security issue in principle) is a pre-requisite for the "de-cloudification" process.
I avoid as much as possible, devices with cloud connections, but those which I somehow end up with anyway that do have such services, I've found almost none of them do any sort of certificate validation.
Load up any certificate you like on your MiTM proxy and go to town.
Sadly, despite embedded hardware being much more capable, some of them having hardware secure-elements and cryptographic extensions, people making these devices either don't have the expertise or just don't care.
Once upon a time I dreamt of creating IoT devices with security, openness and longevity in mind.
I built a small device as a hobby a couple years back using an ESP32. It has 500KB of memory, so storing a full set of CA certs was quite limiting. I forget the size, but looking at Ubuntu package repo, perhaps 100KB. So the constraint was storage size (and therefore hardware cost). I ended up making it local network only and using unencrypted HTTP, which worked for my use case.
> so storing a full set of CA certs was quite limiting
Not sure what your project was doing, but one doesn't generally want to install a full set of CAs. If you're creating a product that'll talk to your APIs you pin your own CA, ensure that the server name matches and verify it, anything else is a failure.
If you use an API endpoint provided by a cloud service provider then you use whichever CA they use, which will be a public CA. But they can switch to another at any time.
I think that they know that the maintenance of the certificate on their server could be a big point of failure, maybe out of their control, so they disable any validation on the client.
A self renewing free certificate (eg: Letsencrypt) still requires some maintenance. A non free certificate also costs money. It's probably a no-no for many of those manufacturers or the company that give them the servers. Razor thin margins, know how, dedicated staff, etc.
> I think that they know that the maintenance of the certificate on their server could be a big point of failure
If you're building products that talk only to your APIs, you issue your own CA, at the very, very minimum you can put a fingerprint in the end-device to verify it, that can be updated OTA if you need to change the CA/server-cert because you kept the lifetime short.
My experience is that for people outside of the "security" space (I'm in secure-comms, backend), most of them don't have a clue. Some believe the only solution is a cert issued by some "trusted" org like LE, others don't know what pinning or verification is, self-sign is often mis-used as a term for self-CA, and then more generally speaking understanding or TLS is low.
The low-resource nature of microcontrollers has certainly made it difficult to do this well/easily in the past, but with micro-sized TLS libraries, and secure-elements on board many of them now, it can absolutely be done with a little effort and understanding. Coupled with EC/certs keys with smaller memory footprints and hardware-crypto accel the only take home I can find in any of this, is that these people simply don't give a shit about the security of the devices they sell and the data about their end-users they're spitting out.
> Razor thin margins, know how, dedicated staff
Half of this "smart" junk is sold at overinflated prices thanks to the "smart-tax". I have a heater which has an ESP32 and you manage it with an app (which I won't do), they spent a bunch on the app, put an ESP32 and some other electronics in what otherwise could have been a £20 heater instead of a £80 heater, and yet I can MiTM their TLS MQTT connection because they make no effort to protect it, all while this thing is spewing mountains of environmental data up to their cloud every 30 seconds that could quite easily be used to detect presence, amongst other things in my home, even when the thing isn't running.
I'm biased being a dev in the security space, but this sort of careless approach shouldn't be allowed when selling consumer electronics. Fortunately, in the UK, NCSC is making efforts to improve this with security labels[0] and requirements at PoS for consumer electronic devices, and I hope to see it develop further.
We're trying to hit those three checkboxes with the environmental monitor/data logger we're shipping in a few months. Certificate to talk to our server, but you can also just point it at any MQTT broker.
It would be even more appealing if you could show a test case where a high level metric (e.g., wifi download speed) improves with one of your lenses compared to a baseline scenario without lense.
Also, I expect the dielectric properties of the printing material will affect the design.
Which printing material have you tested exactly?
Do you know how much the performance changes when cheaper alternatives is used?
We're excited to receive some Radix resin from Rogers Corporation, which is the current standard for developing RF lenses due to its low dielectric permittivity and low loss tangent coefficient.
We also have a few simulated lenses in CST Studio that we will share with you as soon as possible.
Note that 0 in dB scale indicates a 1:1 ratio with something, and not a zero in linear scale. Indeed, a zero in linear scale corresponds to -infinity in dB scale.
For sound, dB is shorthand for dB SPL, or dBs above 20 μPa, which is roughly the threshold of human hearing. So 0 dB means 1:1 with that threshold, or essentially “silent”.
I think most people would intuitively conclude as much without knowing the specifics, so it’s not unclear or wrong to label this device as 0 dB (unless it actually does produce an audible sound, or course).
Fairphone 4 has been my main and only phone for several months now. Great experience, very good battary life. Performance-wise, I haven't noticed any significant difference compared to traditional phones. The only drawbacks might be the camera and thickness, but honestly I don't care much.
Of course, much depends on your use case and expectations. YMMV.
Don't know much about the invisibility cloak. But in wireless communications the "better smart mirror" idea is being investigated to achieve arbitrary reflection directions that defy Snell's law [1][2]. The objective is to hang these "mirrors" on walls/buildings and reflect the incident power towards areas where the reception is poor.
Don't get me wrong -- they're great tools. Especially OLS for analysis has this whole framework for understanding errors you will not get in models fit using maximum likelihood methods.
But as a final usecase for a product there's generally better out there.
I think you're mainly thinking of machine learning and data science applications, and so your perspective may be a bit limited. But, of course, you didn't actually give any explanation of what you mean other than mentioning ordinary least squares. Would you like to elaborate and back your point up?
In computational science and engineering, there are many applications in which the SVD is a very reasonable and good choice. Some examples: fast direct solvers for integral equations, model order reduction, solving inverse problems, etc.
One more very good reason for preventing requests to "the cloud".
However, I find it funny that the lack of proper certificate validation (which is a security issue in principle) is a pre-requisite for the "de-cloudification" process.