If this doesn't go opt in, I will not be buying more and I will stop recommending it to others.
Please don't do this. Firewalling access points, good practice or not, should not be necessary. You're not a dodgy IP cam manufacturer.
People buy your equipment precisely because they want to trust their network hardware.
High quality products were made for many years with no analytics, just by thoughtful design, using the product yourself, and gathering some feedback from users manually. Even without statistically representative data from some large target population, you can use your brain to figure out what goes wrong and how to make a good product.
And I think lots of products today are quite annoying because of bad decisions based on flawed analytics data. It's hard work to run a good experiment and avoid confounding correlations and plain bugs that throw off the results, and practically nobody today does the hard work. They just run the analytics, get some flawed buggy numbers, interpret them without sufficient care and thoughtfulness, and push through bad design changes. We're data-driven! We're just not looking at the road.
The freedom and transparency we got from PCs where you can always know what is going on, with some caveats, is missing from all other platforms. And it's really worrying.
But I agree, it's a serious problem. The abuse has become so widespread that I am now in favour of heavyweight statutory regulation and severe penalties for violations. I don't see any other way we come back from this situation now. Competition in the market has utterly failed.
On phones, things have gotten much worse. Although you can flash a relatively open ROM in case of Android, good luck controlling what the baseband does behind the scenes.
And if we talk about cars and other devices like smart watches, there's often zero openness.
I actually have a lot of sympathy with that one, because radio transmission is one of those areas where one idiot who thinks he's clever and should have total control of his device can literally disrupt entire networks for everyone else over a wide area, with the obvious serious consequences. Modern wireless communications systems rely much more than most people realise on conventions and standards and everything playing nice, so regulating such that only licensed practitioners are authorised to make parts that transmit within prescribed specifications is not an absurd idea.
Of course, that doesn't mean a closed part of the system like radio control should have any access to any other part of the system. It ought to be essentially a firewalled client of the more open parts of the system. And if it's going to be regulated and controlled then the people licensed to develop those components should be required to have them only perform the defined function according to standardised specs, without anything else piggybacking on top.
Right now we don't know whether for example it's even powered when your phone is on airplane mode and collecting data.
I'll just leave this here.
I agree with this, and it seems to create a self-fulfilling prophecy.
I believe this to be responsible for the decline in Apple’s various device OSs.
So they're driving down the time it takes to do what they magically infer I'm trying to do. Is this why whenever I try to organize my gmail box I give up 10 minutes in because the UI is slow and bullshit? Because it's good for metrics that I can't make my gmail account anywhere near as useful as my work email?
I'd use anything else for the slowness alone if I could decide the tools at work myself.
The best part is that 10 years ago I used to have an absolute piece of dog shit WinCE phone that failed to even keep up with my typing speed in its stock SMS app. Google Maps worked perfectly on that device.
Most certainly you could misuse the statistics for blind number worshipping, and I’m sure there are many anecdotes of that kind of behaviour. But I’m also quite certain that successful organizations can use these to improve their products in meaningful ways. I suspect any gmail product manager who tried to slow down their product (or resisted fixes) to improve meaningless time spent metrics would be crucified.
And it is even worse in firefox than in chrome.
It takes 30s to 1 min to load(!). It has cached last view, which loads fast.. then it goes unresponsive for bloody 30s to 1 min anyways.
3 different machines were used to test this - i5 6th gen laptop, i7 7th gen pc, i7 3rd gen pc - all of them with plenty of ram(at least 16gb).
I bet they'd say they would have.
Source: I am basically the person you are talking about, in one of my current roles.
On a browser, it's drive-by, and your ability to track users is gone once they leave your site, especially with vendors like Mozilla and Apple implementing third-party cookie blockers by default and the ubiquity of adblock.
On a phone, if you install something, you'll probably leave it for at least a few days, and if you watch logcat, you'll notice that many of these apps are anything but patiently waiting for the user to decide open it up again.
There is a way to hijack the back button, i have no idea if it has been fixed, there are also tracking cookies so they can track you cross sites anyway.
It is now, it seems.
Having seen what kinds of data crash reports in other domains include (the richer the call chain trace, the better) I expect this to be a subtle security problem. In regulated or otherwise highish-security networks one can expect to see user authentication when accessing wifi (EAP).
Simple scenario: AP crashes during client auth stage. A full crash trace may easily contain the credentials used for EAP, and if those are sent to mothership, your access point has just leaked out the necessary information to successfully access your secure network. Worse, when EAP is used, the login is likely bound to domain credentials, which are practically guaranteed to allow access to all sorts of internal services.
To state the obvious: best practice with crash traces is to filter out or mask high-value KV pairs. But then again, best practices also disallow leaking credentials in the first place.
For my part, I will now consider Unifi APs as rogue devices.
Just ~ two weeks a go I finally retired my old OpenBSD based gateway in favor of USG. But no, I guess I'm back to putting OpenBSD on USG, and maybe OpenWRT on APs.
Is there a working replacement OS for Ubiquiti PoE switches?
[0] https://www.openbsd.org/octeon.html [1] https://codeghar.com/blog/openbsd-on-ubiquiti-usg.html
It’s not like it doesn’t already have a firewall built into it.
When I buy [network] equipment, it is my expectation that since I own the HW, I am to a certain degree in control of what they do and to whom they 'talk to'. And call-home / telemetrics without at least opt-out just doesn't sit well with me here.
* Possibly by some other combination of dropping Established/Related traffic. I think that'll get gnarly for the instances where WAN_LOCAL traffic is needed -- VPN, connectivity checks for load balancing, etc.
eth0_out affects traffic leaving the ER on eth0
eth0_local affects traffic that enters the ER on eth0 and is targetted directly at the ER itself (e.g. the webgui)”
In this case you would put the rule on eth0_out, not eth0_local.
Just now I verified with the following partial ruleset on a EdgeRouter I have in production:
set firewall name WAN_OUT default-action accept
set firewall name WAN_OUT rule 300 action drop
set firewall name WAN_OUT rule 300 description 'block 1.1.1.1'
set firewall name WAN_OUT rule 300 destination address 1.1.1.1
set firewall name WAN_OUT rule 300 protocol all
set interfaces ethernet eth0 firewall out name WAN_OUT
The only way to filter traffic from the router would be to drop the standard "Allow Established / Related" rule from WAN_LOCAL, retain the default drop action, and make specific rules allow whatever the router should be permitted to communicate with. And that would still allow packets to escape the router -- for TCP the communications channel is effectively dead since the handshake can never complete, but it could blast out all the UDP it wants.
Do note that some ubnt devices have custom firmwares blocked on newer software versions. For example Unifi AP and LR:
* Maybe there’s an export restriction on a component and they lack the license to export to that country.
* Maybe they have not submitted their product for regulatory testing in that region.
* Maybe the product doesn’t operate within legally available spectrum in that country.
* Maybe the product presents an IP rights concern in the laws of that country.
* Maybe they simply haven’t paid a lawyer licensed to practice law in that region to confirm they wouldn’t have any legal concerns.