trashfindhunter

He wouldn't be the first. Speaking of which, whatever happened to Dart?

> John gives up. Concludes never to touch Node, npm, or ES6 modules with a barge pole. > The End. > Note that John is a computer scientist that knows a fair bit about the Web: He had Node & npm installed, he knew what MIME types are, he could start a localhost when needed. What hope do actual novices have?

The ones who don't give up on the first night will likely have more luck (try, try again).

Ones that happen in the world you live in, homie.

> a false sense of security is worse than having (knowingly!) no security at all.

Agreed. If you know that you are insecure you're less likely to pass sensitive information over the connection.

IMO the culprit is browser behavior. For instance, when visiting unencrypted HTTP sites in Chrome you may or may not notice an unobtrusive, greyed out "Not Secure" label in the URL bar. Visit your own self-signed certificate dev site though, and Chrome will give you an error wall with nothing to click, and you have to type "thisisunsafe" to pass (the page does not tell you that typing "thisisunsafe" will get you through).

Perhaps the reasoning is that if a site is served unencrypted it shouldn't be serving sensitive information, whereas an invalid certificate is an easy indicator of something amiss... but wow, talk about obtuse.

Your concern is definitely valid though, and I'm concerned about it too.

Exactly. Not once in their diatribe did they provide a reason that they need those permissions. The fact that noone there knew why they were asking for those permissions in the first place is a huge red flag for me.

Why are they asking for https://*.pushbullet.com/*, http://*.pushbullet.com/*, and http://localhost/* read permissions? I suspect it's the localhost permission request that is currently blocking them.

And why in the world are they asking for the cookies permission? That's a big, fat nope for me. It's as if they don't understand what they are asking for and the potential implications of passing that data around so haphazardly.

These folks need to take another hard look in the mirror before they point the finger, because their own house is way out of order.

> Of course it's worse when the user thinks the connection is encrypted when he actually has no idea who he's talking to.

If a website previously using a self-signed certificate switches to plain HTTP - how will that help me verify the identity of the server the next time I visit?

By removing the self-signed certificate, not only am I still unable to verify the identity of the server, but now my traffic is in plaintext for anyone on the local network to trivially intercept (in addition to whatever stranger I'm sending it to on the other end).

I understand your sentiment, and I know the slippery slope that you are referring to when you say that it's a dangerous mindset to be okay with unverified certificates. Unencrypted communication however, is not a solution to that problem.

The level of brutality in your critique made me smile. Thank you for your vigilance and clarity.

Will the physical sound waves that I produce with my loud speakers cause Active Noise Control enabled headphones to "engage" with me? Could I adversarially engage with them at that point?

Then again... won't that summed audio source be at the mercy of my loud speakers?

Yeah, you're right about ear damage coinciding with exposure time - short bursts would have to be very loud to cause real damage.

And yes, it would be weird if a frequency range spontaneously inverted - the only scenario I can imagine that happening in is some jerk doing it on purpose.

The reason I became interested in ANC was because every night I would hear a terrible frequency being emitted from the air conditioner units above me (top floor apartment building), and during my experiments I quickly realized how hopeless it would be to effectively combat them due to the varying intensity of the sound throughout my apartment, the dynamic interactions of the sound with itself within my echoey wood floor studio, and my location at any one time. All valid points though, thanks for chiming in. I learned more about ANC :)

Edit: Btw my goal was ANC via speakers, not headphones. Headphones would be much easier since they only have a single, summed audio source.

I've played with audio software for a long time and I recently experimented with Active Noise Cancellation. There are a few things to keep in mind:

* A "live" ANC process has no control over the environment from which it receives the audio signals that it acts adversarially against.

* When transmitting audio waves from one medium to another, there will be latency. Perhaps not much, but it will be there.

If you accept these two positions, then consider this:

* What happens when a sound wave that is being combatted (via phase inversion) suddenly stops, or inverts it's own phase? That's right, ANC could potentially double the amplitude of the frequency being combatted.

* I imagine that ANC technology takes advantage of latency to ensure that they don't damage people's hearing, but the nature of ANC requires low latency in general, otherwise you can't be sure that you are combatting the correct frequency (at which point you risk doubling the amplitude due to abrupt changes) - if someone more familiar with the actual algorithms could chime and correct me I will happily stand corrected :)

Another possibility for managing this would be to use a puppet agent / master setup, and use puppet directives to pin sensitive packages (i.e. the ones that comprise your application) to specific versions while allowing the rest of the system to update accordingly (assuming the pinned packages don't cause dependency issues - which should be tested before pushing).

So the process might look like this:

1. Manually update a test system and take note of the packages comprising your application and their new versions ('grep -E "<PATTERN>" --color=always' could be helpful here). 2. Run automated tests against the test build to ensure that new packages have not caused issues. 3. If any breaking changes are discovered, pin the offending packages to their unbroken versions. Rinse and repeat. 4. Once a stable build is found, update your puppet manifests to reflect any pinned packages and run it on a single test system (I use an isolated puppet master test server for this). 5. If all goes well on the test system, update the main puppet master server and wait for the agents to call home (don't forget to update the runinterval directive in puppet.conf so the agents don't call home every 30 minutes - even idempotent processes consume resources).

Further reading:

https://forge.puppet.com/puppetlabs/apt https://wiki.debian.org/AptConfiguration https://help.ubuntu.com/community/PinningHowto