Then what about all the cloud enabled spyware? How would that work? (/sarcasm)
Truly though, smart-home stuff runs the whole gamut of privacy and device manufacturer relationships. eg: I have used three different smart/room AC units:
- one requires its own cloud-enabled app for any remote connectivity, no HomeKit integration
- one integrates with HomeKit but then leaves an upgrade hint that can only be done through an app with a login
- one integrates with HomeKit and pretty much just works
HomeKit then allows me to remotely control via HomePod/AppleTV acting as a router ... of course this is just a different cloud connectivity but with on-premises devices controlling other on-premises devices.
For each manufacturer of smart devices, there is potentially a separate cloud where data is being funneled through. Some devices support multiple upstreams.
I get that Matter should be a way to fix it but the reality feels more like https://xkcd.com/927/
Part of me just wants dumb devices back. Get rid of buttons on a microwave (just give me a knob for time and maybe another knob for power setting.) Remove touchscreens from cars (mine glares at me with certain sun-angles.) Bring back the desktop/computer hutch and phones that don't live in your pocket. However, having the ability to start cooling my bedroom 45 minutes before I arrive home is ... pretty compelling too.
Manufacturers just need to realize that LANs exist and allow their devices to be used with the Internet turned off.
When I'm sitting in my home and I want to turn off the AC unit in the other room or close my garage door, there's no reason I should have to do an IP roundtrip to the manufacturer's server. Both devices are on my LAN. They should just talk to each other. This has been a solved problem for decades.
I have a Vizio TV that was advertised as a Chromecast TV, and I got it because of that. It was HDMI and Chromecast only. A few years later they did a silent update that added apps and generally made the UI much slower. I mainly use it with an AppleTV or game consoles, but it still irks me that they completely changed what was in my mind a nearly perfect TV.
They realize. They hate it and wish it would go away. LAN connectivity makes it really hard to spy on you, inject ads, require subscriptions, and brick perfectly functional devices so you have to buy new ones.
Except some of the TVs try to connect to unprotected hotspots, or piggyback through ISP's routers' hidden secondary SSIDs. Which even opens people's data and ambient conversations finding their way to the manufacturer or advertisers through war-driving.
Ok, I don’t understand your point, then. If a device works locally then you can firewall it and block any nasty stuff phoning home. If it runs everything through the manufacturer’s servers then you can’t firewall it without disabling it entirely.
I’m completely lost. I’m not talking about safe, I’m talking about how routing everything though a server gives a lot more control to the manufacturer and they’re loathe to give that up.
I’m pointing out that has literally nothing to do with LAN or Wifi. It’s a problem with having literally any (unfiltered) network access at all. Though even filtered, you’re susceptible to bypass attacks.
Notably, a device can even route all command and control through a cloud service, including sending copies/hashes of all accessed content AND serve just local (as in physically connected) media/content even, if it has a network connection.
This has been an issue since BluRAY at least, where players have the capability to check physical media licensing and deny/brick BluRAY media, and could run Java apps which had network access. So at least 20 years?
The only way to prevent that is to firewall off or physically disconnect any network access.
In this example, for instance, I bet these LG TV’s will happily send all this info even if no one is using any network or app based media streaming at all.
I have been toying with the idea of building some kind of "home cloud" that hooks into all of your smart devices (at least all of the open devices that it can), allows photo backups from mobile devices, idk. Stuff like that.
Something you can just scan a QR code with your phone and it hooks it into your backups so your "cloud backup" is sitting in your utility room at home instead of being "someone elses computer"
Obviously this is all achievable by a savvy techie, but I'm thinking along the lines of a black box any idiot can use.
The idea is very appealing to me, I would love to decentralize "the cloud" for your average person.
And if it were possible to get one of these in every house and apartment, then the idea of a "smart home" starts to really click in ways it doesn't right now. Your smart home would have a "home cloud" box that acts as the brain
Idk. I think there's a product idea here somewhere but ultimately it's just something I'm kicking around now and then.
You only need an external server if you want to make it so the end user can access their device remotely. Otherwise, an app can very easily just scan the network for the device. Heck, the app itself could be the thing that sets up the device on the network in the first place.
Remote access should also be do-able without having a manufacturer-run server. We over-complicate things with NAT and with ISPs sabotaging inbound connections to our networks. At least with IPv6 every device on my network is addressable by the outside world, and I can (and should be allowed to) make the decision about whether they are accessible. The device manufacturer should not have to insert themselves into this conversation.
users sometimes end up with some combination of the above:
1) multiple wifi networks
2) ‘guest mode’ wifi networks (you can’t communicate to other devices on the same network)
3) various airplane mode type scenarios where they have cellular but not wifi connections semi-randomly, even on the same property/area.
these all happen with out of the box ISP setups pretty regularly, btw.
and they’ll just blame you for the flakiness.
also, for most of them, they love remote access anyway and don’t want to consider the security implications.
> You all literally saw what he did in his first term!
False, unfortunately. Disparate news outlets covered events very differently and folks watching pro-Trump outlets (or only listening to friends who do) through the first term were under the impression that he did an excellent job. They may even still believe that the 2020 election was actually stolen. Heck, there are depositions this year while vetting appointees who refuse to admit (despite all available evidence) that the 2020 election was valid.
I had this issue with cloudns and a single record with an IPv4 and IPv6 address. They only allowed one free ddns record which covered exactly one protocol. On top of that, they added records to resolve unknown names for advertising purposes.
I get that it costs money to run a DNS service but it seems like it should be a lot cheaper at scale than a lot of companies are providing.
Aircraft design is very intricate. Change the CG, break the whole system.
Fuel is often placed in wings because adding/burning fuel from your center of lift means your CG doesn't significantly change through a flight and you spend less on pumping fuel within the aircraft. With batteries, you are looking at a constant mass from the beginning of the flight to the end... so you can place it anywhere. Electric motors are orders of magnitude lighter than jet engines. Also, you don't need to pump electrons against gravity so placing all of that weight lower has handling/performance advantages.
By using an airframe shape that is well known, they are reducing risk and appealing to existing pilots. By building it from the ground-up, they are taking advantage of differences between the tech.
eg: all of that weight in the fuselage instead of the wings means that rolling is going to be much more nimble. Yaw might be affected as well, depending on the placement/moment of the batteries.
> The PIC64-HPSC series has a built-in 240 Gbps, 16-port TSN Ethernet switch with Remote Direct Memory Access (RDMA) that uses the RDMA over Converged Ethernet (RoCE) version 2 standard
It seems like this is what the article is referencing. However, the ethernet embedded CPUs have "GigE" or even 10/100 capability. Why the need for 240 Gbps with 16 GigE ports? Are the ports 10G fiber capable and they are just future-proofing or is there something I missed with the time-slicing and RDMA?
Looks like the press release is mixing up the chip level with some board or assembly. The MPUs in the family look like 10G by themselves, so maybe the board includes the switch and shared memory.
> In addition, app publishers and content providers, such as media publishers, will be given more scope to explain to users what significance personalised advertising has for their offering and their business model.
Great, sounds like a new channel for marketing where I really just want to opt-out. Also, does this added scope include the mechanism to maliciously comply like so many websites do with cookies? (eg: You want our cookies? Here is a list of things you can de-select... with toggles that aren't clearly on or off)
Despite interesting legal definitions, companies are just groups of people.
I also read the title as having an air of self-importance or maybe passive-aggression. If you read it a little more dispassionately then it's just an awkward way of stating that this is a gift.
Why is this a gift? The company does not need to give it to you, though it arguably benefits from doing so. It did so with some definition of "free."
Renaming is forbidden though (because JSON and textproto). In Google, it's a documented antipattern to try to make protobuf look "nice" by changing field indices, rearranging fields, etc. — the common ground is that it's better to not do it.
As long as you know the use cases of your fields, renaming is just fine. My team regularly does it. We also maintain our own serializer and deserializer json, XML, and fixed with formats. The json one we handle serialization using an annotation to say how it should be exported.
Of course, the whole concept of a breaking change does not really apply if all usage is within the controlled code. The problems start to appear when you have external users with old versions; then protobuf starts having a bunch of weird limitations. My favorite is that it's forbidden to move a field into or out of a `oneof`: it's a compatible change in a sense of wire format and JSON, but breaks the generated Golang code.
Breaking changes matter even with controlled code, because you can have requests that straddle upgrade boundaries, it's fiction to believe that all services are upgraded at the same moment, and pretending that is the case is the sort of thing that leads to quiet data corruption or mysterious bugs that can never seem to get reproduced.
Even if you upgrade with coordinated downtime across your entire service stack ( a bit old-school, but still happens more than you might imagine. ), then you still have to occasionally deal with requests that get persisted somewhere, possibly for support purposes, and it's much handier if the wire format remains compatible, at least between immediate versions.
Yes, breaking changes need to be staged carefully/compatibly across versions.
Simple renaming/reordering is not a breaking change between code versions. The wire format knows numeric ids, not names. It breaks code compilation until the renames are put into effect. There is a subtle breakage where someone renames a field (think: field -> old_field) and then later adds "field" to mean something else; software that isn't recompiled in this window might not recognize that "field" is potentially different. Uncompiled languages may suffer this even more subtly. -- All of this to say, breaking compilation is not the end of the world but there are more dragons as the scope grows.
Stop-the-world is usually only needed when someone has made an unplanned/incompatible change with versions that are still running. If your infrastructure+development is done right (hah) this should never happen.
This is an interesting piece that is often overlooked by folks in the "but NAT is security" camp; Having a sparse address space that is 64-bits makes it impossible to iteratively scan over a range. If you don't reverse resolve or you disallow zone transfers then you also have no real discoverability for that /64.
Giving a the most flimsy reason for the policy doesn't give me confidence in that; I can think of much better reasons for disallowing uid aliases (root or otherwise).
It has the same optics as an unauthorized entry someone planted: a backdoor to retain root access. It will continuously have to be explained to new people who spot it.
If the intent is to keep the passwords identical (which it probably should be), the tooling doesn't support it. When someone changes the password for root using standard tools, the one for rotorooter doesn't sync. This is a problem if someone is changing the password in order to restrict access to just a specific set of people who know the new password. The unaltered entry turns into a de facto backdoor for everyone knowing the old password.
Pitafall: if you put an alias entry in the wrong spot in in the password file, so that it appears before the canonical entry, then UID 0 maps backward to the alias name (e.g. via the getpwuid() function). This breaks all logic that looks for the string "root" rather than UID 0. E.g. shell scripts looking for root in the output of some command.
None of them apply to the situation of an individual operating an accessible system for their own use, or very small business with a handful of employees.
The kind of organization where it would make sense to forbid tricks like multiple password entries pointing to the same user (such as UID 0) is going ot be the kind of organization where the whole thing is moot anyway in connection with SSH, because in those kinds of organizations, you don't want ad hoc machines to be accessible via SSH publicly. You don't want employees to be solving the problem of SSH ports being probed: do we use fail2ban, port knocking, kazinator's user name tricks posted on HN? ... just no! You have some kind of perimeter VPN. Authorized users connected to the VPN can then use SSH to machines inside the secured zone.
It makes no sense to bring up corporate rules against my solution which for a problem that corporations should not have in the first place: SSH-accessible machines on the open internet being probed.
Truly though, smart-home stuff runs the whole gamut of privacy and device manufacturer relationships. eg: I have used three different smart/room AC units:
- one requires its own cloud-enabled app for any remote connectivity, no HomeKit integration - one integrates with HomeKit but then leaves an upgrade hint that can only be done through an app with a login - one integrates with HomeKit and pretty much just works
HomeKit then allows me to remotely control via HomePod/AppleTV acting as a router ... of course this is just a different cloud connectivity but with on-premises devices controlling other on-premises devices.
For each manufacturer of smart devices, there is potentially a separate cloud where data is being funneled through. Some devices support multiple upstreams.
I get that Matter should be a way to fix it but the reality feels more like https://xkcd.com/927/
Part of me just wants dumb devices back. Get rid of buttons on a microwave (just give me a knob for time and maybe another knob for power setting.) Remove touchscreens from cars (mine glares at me with certain sun-angles.) Bring back the desktop/computer hutch and phones that don't live in your pocket. However, having the ability to start cooling my bedroom 45 minutes before I arrive home is ... pretty compelling too.
reply