HN user

mr__y

349 karma
Posts0
Comments212
View on HN
No posts found.

What would happen if you manufactured lots of packets to trigger the expensive filters?

then you would effectively DoS/DDoS the IPS. Now depending on how the system as a whole works it could be an efficient way to get through with a different attack that would normally be detected/blocked by IPS.

- block access ala GFW, ensuring that most people will have difficulty accessing it or using it

depending on sofistication of that solution you could imagine some forms of tunnelling to be efficient against that (IP-over-X). Then of course due to the complexity this workaround will be used by a tiny fraction of users.

- block access to any data you cannot decrypt or from an endpoint you cannot backdoor

steganography would be a solution to this, you can decrypt the cat pictures I'm exchanging with friends but you may not be able to notice that those images have hidden content (which may also be encrypted)

- do nothing, knowing that most users will avoid using anything that isn't one of the major web platforms

this seems to be a guaranteed-to-succeed solution. Probably much better than

- run some kind of propaganda campaign on the evils of using unsanctioned software (supporting terrorism etc.)

since there is always a risk that this may backfire and encourage resistance in some groups

if our bad actors use VPN's to hide their traffic then it would become impossible for ISP's to see what they're doing or using

you just transfered a problem from ISP level to VPN operator level. While you could argue that using multiple VPNs from different countries could make this somewhat harder, the problem still exists. Especially if you consider metrics other than IP, for example specific packet sizes or timing patterns (for example, instead of users connecting to given IP, the adversary would look for users sending 640 byte packets every 300 seconds).

While the arguments that encryption of messages makes it impossible to know the contents of messages (and thus using the contents as evidence), however the ability to uncover the members/employees/cooperators of bad actor would make it easier to investigate them and/or use other means of targeted surveilance to obtain evidence. Also this would make it easier to infiltrate bad actor, since one of the uncovered users could be then coerced into cooperation.

(All above assumes that the app/platform is used only by members of "bad actor" and noone outside that organization is using the app. It is completely different if there are other users, perhaps even bad-actor users being a minority.)

With the developers outside jurisdiction, the problem is that while they of course might or might not be required to comply with the law, but they can still be coerced/manipulated/otherwise encouraged into providing a "patch" (backdoor) into the application.

I believe that much better solution would be to simply use any popular platform as a transport layer, with independent end-to-end encryption. Possibly with some steganography as well. The simplest example would be users exchanging memes/cat pictures - this will not stand out in any ISP/VPN traffic analysis. It will also not stand out (that much) in content analysis by any entity that can decrypt/access plain-content. The images being exchanged could then contain embedded (and end-to-end encrypted) content. While this is still far from perfect - you could imagine detection of repetitive images being sent, content/timing patterns or actual analysis of attachments for steganography but all those still require significantly more resources to work on massive scale.

Alternative would be to use custom platform but having as many "external" (in a sense of not working with/for bad actor) users as possible

anyone can make their own communication platform

and then the users of that platform would simply stand out in ISP logs making it actually easier to spot them. If this platform was a dedicated tool developed by/for a bad actor, then everyone working with/for that actor would be easily found.

Given that, it seems that steganography (combined with encryption) could be a solution with a "battle" between steganographic methods and algorithms to detect them

You could be using a vpn or a proxy making it harder to be matched only based on IP address you connect to. Traffic pattern analysis would still work.

Some scientists are self-administering an untested product. Is it ethical?

Depends, if the self-administering scientist is the only person at risk then I don't see any reason to believe it is not ethical. Assuming they are adult, sane persons it is ethical to take personal risk, at least in my book. Now, depending on what is being injected you could imagine a situation where this could pose risk to other people as well - for example a vaccination containing an active virus (through a design or mistake) that could spread outside the lab and infect others. This would NOT be ethical.

tldr: if the self-administering person does not put anyone else at risk it should be considered ethical

advertisements which are custom-tailored to my tabulated interests are far superior to the ads I would get through traditional context advertising.

actually my post is not arguing with that, however facing the reality where interest tracking/profiling will become harder or impossible good old context-based ads might at some point become better alternative. Not because they're inherently more efficient but because, with changes like that, interest tracking might become infisible or too resource consuming

Maybe this will encourage switching to context-based ads. If I'm reading blog post about Rust, I might be interested in buying books or online training in Rust. Or, if I'm watching a video on how to take care of kitten, food or vaccination for kitten might be of interest for me. Nobody needs to track all my activity to guess that.

This would come with a cost of longer compression times - either multiple attempts with random shuffling or pre-compression file ordering optimization process. For resources that are compressed once and then distributed and decompressed multiple times this would be quite interesting solution

It has also much shorter half-life than most opioids making managing the overdose much easier (in hospital setting). For anesthetic it is a valid and safe choice. It is of course different in non-hospital setting and non-pharmaceutical grade products - since fentanyl is very potent it requires much more precision in measuring the dosage which, when combined with unknown and varying purity makes overdose much more likely than with less potent opioids. If that is in turn combined with lack of or a significant delay of naloxone administration the risk of death is significantly higher than with less potent opioids

Most enterprises want to focus on developer productivity

While I absolutely agree, it all depends on a scale. If you're using for example 10 cloud instances, x2 performance improvement will not justify extra person-months spent on developing more performant solution. On the other hand if you run 1000000 servers even 1% performance boost might be worth that effort.

With https over VPN, at least the vpn provider cannot inspect the contents of your traffic. With a browser running on a remote machine, whoever controlls that machine can. This is better than VPN only in a scenario when you either controll that machine or fully trust the provider

that's a valid point as well. This pretty much results in a privacy vs security choice, you either run it in infrastructure you fully control at the loss of privacy or some anonymous service, where you could have privacy but loosing the security. Although one could argue that using an anonymous hosting service, there's still a risk that whoever is running that infrastructure could monitor your activity meaning that effectively you have neither privacy nor security.

Lazy loading as a standard would actually make it much easier to modify lazy loading behaviour through browser config and/or addons. Now you are at a mercy of website creator, with a standard and the ability to modify default behaviour through a config you could possibly just switch off lazy loading if thats better for you