The only way to meaningfully defeat surveillance technology is to make a constitutional amendment that limits its use privately and publicly. We keep fighting it technologically which is an arms race. A cultural solution is the only path forward that will see meaningful success.
As a fan of ICP this is hilarious because it almost means we all need to become juggalos not just dress like them, even if that helps
> The Juggalo story, or Dark Carnival mythology, is the overarching narrative conceptualized by the hip-hop duo Insane Clown Posse (ICP)—Violent J and Shaggy 2 Dope. It tells the story of a spirit world that judges the wicked, selfish, and cruel members of society, acting as a morality play meant to guide listeners toward a better life before "the end"
Malware is just software too, but we still have the CFAA.
Sure it doesn't prevent malware, far from it. But, it does relegate to basically only bad actors that we want in jail. Who are, usually, smaller and less organized.
Walmart, Amazon, the US government... these are big, big, big and very organized. If they use facial recognition tech, it's 1000x worse than some criminal. But if that's made illegal, they won't. Probably.
People find their ring cameras too useful, businesses love cloud based security camera systems, facial recognition and cloud backup are expected features of every phone's photo app, courts consider recording integral to first amendment expression.
These are some big rocks you'll need to move, otherwise your amendment won't be worth the paper it's written on. Just saying "you can collect all the data, but don't use it for surveillance" doesn't mean much.
I have no solutions, feels like we missed the boat if there ever was an opportunity to prevent it in the first place. We live in public now.
Just this week I've been taking walks in my neighborhood, and the number of homes that chime or play a voice recording to indicate being recorded was shocking. I just indicate to them that I think they are number 1. In other situations where I'm in public with a camera cleary pointed in my direction I tend to do that with my hand in front of my face. If they are going to blur out the #1 sign, my face gets conveniently blurred as well. They might have a right to record, but I also have a right to silently express my opinion as well.
Not sure if I agree that the only solution is to give up now; we need sensible people that know how the technology works in power and that are not beholden to serve big corporations, but rather the average person. We need less populist and long-drawn campaigns. We need less politicizing. And we need all of that yesterday.
>People find their ring cameras too useful, businesses love cloud based security camera systems, facial recognition and cloud backup are expected features of every phone's photo app, courts consider recording integral to first amendment expression.
As long as the recordings aren't centrally stored and sold in bulk, and sold to brokers and governments, that would still be ok.
In Germany it's just plain illegal to have public space within the camera's field of view.
The camera must also be mounted in a way that it can't be rotated by software and can't be rotated easily by hand in a way that it is able to have public space within the field of view.
Cameras at main stations and within trains, only store their data for 24 and gets deleted afterwards afair, as long as it's not requested by some entity that a specific recording should be retained.
I don’t think it will happen for at least a couple of reasons. The “deep state” in the US and elsewhere will not allow it and would find workarounds ala five eyes. And two, the right wants to spy on the left and the left wants to spy on the right. Only a small sliver of libertarians are strongly against spying “the domestic baddies.” So there is no chance.
The only reason the deep state or anyone has any power is because most people don't care. If people cared, we could change. Modern politics is all about distracting everyone with some crazy as often as possible to keep shifting attention and basically disabling any progress.
the deepstate has power because they will literally kill you if you don't and that's not the worst option. The deepstate will honeytrap, hack, blackmail, or otherwise destroy your life to get what "it" wants. People caring more isn't going to do anything if the Congressman doesn't want it known that he likes easy access to money and other illegal things.
As long as it is accessible and useful, it will be used. Organized crime is around despite it being illegal. Considering how lucrative tracking people is, people will do it illegally. Even corporations as long as penalties aren't significant enough. We really need a three strikes law for corporations. Three egregious intentional violations and corp, is dissolved all assets going to support the needy.
"things should be legal because some people will do it anyways" is not a very compelling argument. I'm sure I don't need to explain to you why extrapolating this line of though to, for example, murder is silly and not worth taking serious.
My solution was to toughen consequences and I didn't directly respond to your tech solutions won't do it, the implication I was trying to make was take self defense class (tech defenses). This is so when the bully punches you in the face, you may not have a bloody nose when the bully gets suspended (ie ineffectual punishment like giving a kid a day off for bad behavior). I have a theory that good actors need to work harder to profit, since bad actors benefit from their unethical actions. Most good guys then get bought out at some point by a bad guy.
Love the last bit. Lack of accountability for corporations is a problem. That plus stiff penalties for executives or individuals using facial recognition without consent should put a stop to it pretty quickly.
The sensitivity to red light decreases quickly at wavelengths greater than 650 nm, but light can still be perceived if it is strong enough, up to around 780 nm.
Many so-called near-IR LEDs may actually be somewhere around 750 nm, so they are still visible on a dark background, even if they are perceived as extremely dim.
On the other hand, there are many near infrared LEDs around 900 nm and those are really invisible. Near-infrared LEDs around 1300 nm or around 1550 nm are also completely invisible.
An invisible near-infrared laser beam could become visible due to double-photon absorption, but if a beam of such intensity as to cause double-photon absorption hits your retina, there are more serious things to worry about.
I remember reading some people can perceive some near IR, but mostly that near-IR LEDs actually leak some red themselves due to imperfections in manufacturing or something?
You could strobe at some multiple of the sensor frame rate as long as your strobes are continuous through the integration period of the sensor and the lighting fades very quickly. This probably wouldn't work with incandescents but people strobe LEDs a lot to boost the instantaneous illumination without going past the continuous power rating in the datasheet.
You mean do strobe, strobe, strobe, strobe, pause, pause, pause, pause? I bet that's at least as bad as holding the source on for the first four intervals and then off for the latter four intervals.
In any case, if you actually have a scene bright for 1/24th of a second and then dark for 1/24th of a second, repeating, you're well within photosensitive epilepsy range. Don't do that to your actors unless you've discussed it with them and with your insurance company first.
You're not providing any explanation for why I wouldn't trust OP on DNSSEC. And the FUD is pretty reasonable if you've had a lot of experience setting up certificate chains, because the chain of trust can fail for a lot of reasons that have nothing to do with your certificate and are sometimes outside of your control. It would really suck to turn it on and have some 3rd-party provider not implement a feature you're relying on for your DNSSEC implementation and then suddenly it doesn't work and nobody can resolve your website anymore. I've had a lot of wonky experiences with different features in EG X.509 that I've come to really mistrust CA-based systems that I'm not in control of. When you get down to interoperability between different software implementations it gets even rougher.
Which is exactly what happened to Slack, and took them offline for most of a business day for a huge fraction of their customers. This is such a big problem that there's actually a subsidiary DNSSEC protocol (DNSSEC NTA's) that addresses it: tactically disabling DNSSEC at major resolvers for the inevitable cases where something breaks.
As if DNS isn't a major contributing to A LOT of downtime. That doesn't mean it's not worth doing not investing in making deployment more seamless and less error prone.
> As if DNS isn't a major contributing to A LOT of downtime. That doesn't mean it's not worth doing not investing in making deployment more seamless and less error prone.
Ah yes. Let's take something that's prone to causing service issues and strap more footguns to it.
It's not worth it, because the cost is extremely quantifiable and visible, whereas the benefits struggle to be coherent.
DNS underlies domain authority and the validity of every connection to every domain name ultimately traces back to DNS records. The amount of infra needed to shore up HTTPS is huge and thus SSH and other protocols rely on trust-on-first-use (unless you manually hard-code public keys yourself - which doesn't happen). DNS offers a standard, delegable PKI that is available to all clients regardless of the transport protocol.
With DNSSEC, a host with control over a domain's DNS records could use that to issue verifiable public keys without having to contact a third party.
I ran into this while working on decentralized web technologies and building a parallel to WebPKI just wasn't feasible. Whereas we could totally feed clients DNSSEC validated certs, but it wasn't supported.
Thanks for the explanation. It seems like there are two cases here:
1. Things that use TLS and hence the WebPKI
2. Other things.
None of what you've written here applies to the TLS and WebPKI case, so I'm going to take it that you're not arguing that DNSSEC validation by clients provides a security improvement in that case.
That leaves us with the non-WebPKI cases like SSH. I think you've got a somewhat stronger case there, but not much of one, because those cases can also basically go back to the WebPKI, either directly, by using WebPKI-based certificates, or indirectly, by hosting fingerprints on a Web server.
> None of what you've written here applies to the TLS and WebPKI case, so I'm going to take it that you're not arguing that DNSSEC validation by clients provides a security improvement in that case.
It would benefit the likes of Wikileaks. You could do all the crypto in your basement with an HSM without involving anyone else.
> That leaves us with the non-WebPKI cases like SSH. I think you've got a somewhat stronger case there, but not much of one, because those cases can also basically go back to the WebPKI, either directly, by using WebPKI-based certificates, or indirectly, by hosting fingerprints on a Web server.
But do they? That requires adding support for another protocol.
I would like to live in a world where I don't have to copy/paste SSH keys from an AWS console just to have the piece-of-mind that my SSH connection hasn't been hijacked.
In practice, fleet operators run their own PKIs for SSH, so tying them to the DNSSEC PKI is a strict step backwards for SSH security.
There may be other applications where a global public PKI makes sense; presumably those applications will be characterized by the need to make frequent introductions between unrelated parties, which is distinctly not an attribute of the SSH problem.
And for everyone else that just wants to connect to an SSH session without having to setup PKI themselves? Tying that to the records used to find the domain seems like the obvious place to put that information to me!
DNSSEC lets you delegate a subtree in the namespace to a given public key. You can hardcode your DNSSEC signing key for clients too.
Don't get me started on how badly VPN PKI is handled....
Yes, modern fleetwide SSH PKIs all do this; what you're describing is table stakes and doesn't involve anybody delegating any part of their security to a global PKI run by other organizations.
The WebPKI and DNSSEC run global PKIs because they routinely introduce untrusting strangers to each other. That's precisely not the SSH problem. Anything you do to bring up a new physical (or virtual) involves installing trust anchors on it; if you're in that position already, it actually harms security to have it trust a global public PKI.
The arguments for things like SSHFP and SSH-via-DNSSEC are really telling. It's like arguing that code signing certificates should be in the DNS PKI.
No, we run a fleet with thousands of physicals and hundreds of thousands of virtuals, of course we don't hardcode keys in our SSH configuration. Like presumably every other large fleet operator, we solve this problem with an internal SSH CA.
Further, I haven't "moved on to another argument". Can you answer the question I just asked? If I have an existing internal PKI for my fleet, what security value is a trust relationship with DNSSEC adding? Please try to be specific, because I'm having trouble coming up with any value at all.
We also have thousands of devices accessible over SSH and we maintain our own PKI for this purpose as well. We also use mTLS with a private CA and chain of trust, for what it's worth.
Actually, does it? Yes, the obvious upside when I type in slack.com instead of 123.45.56.67 is very good. Does this same upside apply to addresses I don't type in? What's actually the advantage of addressing one of foobarcorp's infinitude of servers uasing the string "123-45-57-78.slp05.mus.foobar.com" instead of "123.45.57.78"? It seems to just waste bytes. And most communication is of the latter sort - an app talking to its own servers managed by the same company.
BGP can be hijacked. Anycast IPs exist. Rolling out a new release when one of your IPs is unavailable could be a severe challenge. SVC records are actually kinda neat.
All of that's a problem with DNS too, even updating the IP. You could still use it to get the initial entry point if you wanted. But when you serve a webpage with an automatically generated pointer to image3.yourdomain, the only reason not to make that an IP is HTTPS, and LE just started issuing IP address certificates. Think about it - it saves a few round trips.
Huh? They really don't. It's actually kind of unfortunate that browsers don't have uniform policies about what certificates they accept, but for obvious reasons each browser wants to make their own decision.
They do have uniform policies, those policies come from the aforementioned CA/Browser Forum, which has been issuing its Baseline Requirements for over a decade.
Also of note is they were responsible for medical debt cases, which are particularly difficult for people to resolve because of the shared responsibility between the patient and the insurer, which allows the insurer to deflect responsibility until the bill ends up in collections.
reply