deaps

I didn't use namecheap - but I also switched my dns to a highly available service immediately.

I do like the take in the comment - read the agreement that you signed and seek whatever compensation you're entitled. They probably don't care about fair - nor should they, unfortunately. They are required to do whatever they agreed to, which may ultimately be nothing at all.

I hope they go the extra mile for you and make you happy, however.

I have an RCA doorbell camera. It stores locally on the included card (can upgrade this if you want). Then I can watch the videos through my phone (which connects to the camera to read the internal storage). On the app itself, there is room for 4 total cameras. I've considered adding another camera (RCA has a few non-doorbell ones also). My main concern wasn't security (this is outside my house) anyway, but it was that I didn't want another monthly charge for something.

I think I understand this like I'm five...or there about...let me know if this sounds correct.

Let's say the clock ticks at 100 Mhz. So every second, the clock ticks 100,000,000 times. Let's say the wifi broadcasts at 200 Mhz. So every 200,000,000 (100,000,000 x 2) clock ticks, it sends something out into the airwaves - regardless of how much time actually passed in those 200,000,000 clock ticks.

Now let's slow the system clock down by half. It's now ticking 50,000,000 times per second - but still, every 200,000,000 ticks, it's going to send that signal out into the air.

Obviously those actual number are grossly misrepresented (because it's not sending something every 200,000,000 clock ticks, it's more likely sending something PER clock tick (or more accurately performing some function per available clock tick and sending it out at some predetermined number of clock ticks) - but this is just for visualization purposes)...and I could be way off - because maybe it's not the actual signal that is being slowed down, but the data inside of that signal - if that were the case, it just wouldn't be 2.4Ghz anymore. Either way, that sounds like a pretty basic why to me - Yes, this is explained below because the system uses two different phase lock loops...so it is not the signal itself, but the data in that signal that is slowed.

I played so long, I forgot I was at work.

I agree with you. I code a lot at my current job as a network engineer. I use logic in just about everything I do - that being said, I'm actually really good at what I do and I consider coding and evaluating really old code to be my strong suit, among other things. I certainly couldn't do some of these 'tests' I see people talking about - such as import a CSV and convert it to a JSON file then upload it to github...If I sat down for an interview and they asked me that, there's no doubt that I would fail. I guess I'm lucky that I like my current job.

Glad you took the time to write that. I stopped reading the article after his beef with imports...

I checked the cpu stats - and what you describe is definitely accurate - these boxes spend most of their clock ticks on idle...which is amazing. At 3 Ghz and 8 cores - we're talking 24,000 clock cycles to come up with a response.

This would certainly be huge overhead at the dns server right? I'm curious if anyone manages an authoritative DNS server? I currently manage four rather large ones and the collective whole serves up between 400,000 and 900,000 responses per second.

I see where you're going - and I like the queue idea - but wouldn't it be better for that second function to just monitor the queue - and pull data off the queue that is problematic?

Of course 'monitoring' is not exactly the same as 'processing' the actual data - so you'd have to know exactly what to pull off. Which would be just as easy to add that to the original process and just delete the unwanted data as you pull it out of the queue anyway.

In either event, you seem fairly bright - I probably don't follow. The main thing is that I believe system processes do monitor those other processes and restart them if they crash - I think the problem comes in when data overflows or buffers spill out into other processes memory areas. ( I am not a programmer, although I do try to be for fun ).

That's actually really interesting. Something you'd never think about unless you've actually worked on a similar application for a rather large system where a lot of long codes had to be generated.

Interesting read.

As a person that follows this type of thing and somewhat works to prevent them from happening (that is, follows best-practices, relies on an outside entity to blackhole suspected-DDOS traffic, but also applies DDOS security measures at the security stack), I do find reading about the different types of attacks entertaining.

It's good to hear that a large majority of 'vulnerable' systems do get patched quickly (at least in-part according to the article). I guess that would be the good side of users having routers that are 'patchable' from their ISP.

I kind of view DNSSEC as a pretty large attack vector in the DDOS world - as it allows for a huge amount of amplification.

It's 'spice' for me as well - I can always tell Coke from Pepsi because of the 'spice' flavor.

I don't think the fear is necessarily purposeful, malicious intent. I think it's more about accidentally storing something you didn't mean to or accidentally leaking something, with all of the best intents.

The OP seams sincere and honest, but leaks happen on projects with multi-million dollar security teams/budgets.

Ahh yeah - good call. Totally different protocol. I guess ICMP more closely resembles UDP at the end of the day, but you're absolutely right. I edited out the incorrect UDP reference so that a person reading for the first time will not get misled. Thanks!

A ping is very much different. A ping is (typically) simply an ICMP Echo Request, (not TCP, thus no TLS, etc). The receiving device, if accepting echo requests and configured to reply with echo replies, then responds with an ICMP Echo Reply - or some device in the middle (or the device itself could respond with an ICMP unreachable, or some other response - or quite simply drop the ICMP Echo Request entirely and silently).

*Edited an incorrect UDP reference out based on the below comment.

> 35 years of programming and I've never met a language so well integrated with my mind.

That's a pretty good way to put it - and mirrors my feelings. I've been programming for 20+ years (with breaks here and there), and it took a while for me to find Python. But when I found it, it's like I finally found the language that my brain thinks in.

You're absolutely correct.

You know those little desk fans that come with a USB now and also an adapter to plug into the electrical outlet. I don't plug those into my laptops ever - who knows if there's a payload on them.

I will say this. I currently work, and have worked at, a few secret and top secret facilities - and the number of people I see plugging those (and similar) devices into their laptops is scary.

The only vulnerability left would be, as mentioned above, a client installing a browser that doesn't support HSTS.

No. If the domain (and its subdomains) are preloaded - then a first visit is not required. The HSTS requirement is then baked into a list supported by modern browsers such as Firefox and Chrome.

So to prevent a downgrade attack before a first connection is made, not only does the domain need to "includeSubdomains" - and have a valid lifetime (maybe of at least 31536000 seconds, or 1 year [this may just be a government standard]), but they'd also have to send the preload directive in their HSTS header and have been preloaded by that browser platform. If the domain is not preloaded, that first connection is required to get the HSTS information to the client in the Strict-Transport-Security header.

You know how often I watch "Live PD" and believe the guy (or girl) that got pulled over, only to find out that once the K9 arrives, they had pounds of individually-packaged drugs and guns in their vehicle.

> The reason your phone (that's set to use "New York" as a timezone) knows to change the UTC offset from -4 to 05 on the first Sunday of November is because it has received a firmware update at some point since 2006. A standalone device from before 2006 can not know that the spring forward/fall back dates in the US changed, unless it's updated.

Fair enough, good point - I didn't think about that.

> Your statement "None of those require firmware updates. It's quite nice to never mess with the clocks and have everything just be correct" seems naive at best.

I never said that, possibly you're replying to a different person than intended.

I find the title a bit misleading - more so puts the blame in the 'wrong' place.

Let me explain briefly. Facebook allows advertisers to pay a rate per advertisement displayed. Why shouldn't Facebook 'let' their paying customers show the ads to those they are interested in. AKA why would they pay Facebook to show their ad to people they are not interested in?

That being said - I've followed most of the discussion...and there are a lot of strong points. I just think that the title shouldn't that Facebook LET them advertise in a certain way - it should be the company that is advertising the positions only to men - although they certainly could be targeting men through that channel - and targeting women through another channel - with differing types of ads all together.

Well yeah, but then you tell your devices that you're UTC-4, and when it receives the NTP update, it just automatically subtracts 4 hours.

Or, like in the case of most phones, GPS-enabled devices know what time zone you're currently in, and then automatically adjust accordingly.

I've used Garmins and Apple watches for years now. As an avid road cyclist, I always used some type of Garmin wrist device for heart rate monitoring.

As a tech person, I always found the Apple watch to be more on the 'smart watch / techie' side of things - and more aesthetically pleasing.

There is no doubt that the Garmin does a better job of actually recording a ride, or transmitting heart rate to your cycling computer, or just about anything activity-based. So I was always swapping my Apple for my Garmin before rides, workouts, etc.

I always knew there was a shortcoming with even the Garmin when it came to heart rate accuracy - it just didn't respond quickly enough to sudden changes in heart rate (ie. going up a hill at full throttle, etc) - so I tried a heart rate strap on the chest. The Garmin heart rate strap for the chest is perfectly accurate and responds to changes in heart rate immediately. I have that paired with my cycling computer on my bike...and I no longer swap watches depending on what I'm doing.

I've learned to appreciate the Apple Watch for what it is - a device to record activities where heart rate accuracy isn't necessarily 100% important - such as a quick training jog or a quick treadmill workout at the gym, etc.

In either event, I've rambled long enough. I'll be first in line for the new Apple Watch 4 - and will sell my Apple Watch 3 shortly after. I might keep my old wrist strap though. :D

Unethical, absolutely not, at least in my opinion. Legally speaking - there are so many variables that are unknown to all of us that we cannot possibly begin to tell you what your rights are to finish, release, and/or potentially make a profit off of the finished product.

> Start removing thoughts from your brain. As you start thinking about something, just stop.

I had a hard time sleeping just last night. I couldn't stop thinking about things - I even had to eventually google the chemical composition of Sodium Bicarbonate, and of course what exactly Bicarbonate was...then of course that led to questions on Sodium Bicarbonate vs Sodium Chloride...it's a never ending process for me sometimes at night.

I will certainly try this though.

Main issue is when you manage a TON of network devices.

What's easier - connecting to something your OOB management network (10.10.1.0/24) - the fw is 10.10.1.1, the switch is 10.10.1.11, the 5 servers are 10.10.1.21-26, etc etc...

That's a bit better than typing 2200:Hb43:4432:FE39:019H:F3Z6:3438:2101 etc...

I realize internal dns solves that, but that's a lot of extra dns records to maintain - which ALSO is an issue if your organization uses HSTS and preloads subdomains - you must have have a trusted certificate on each management interface, otherwise the browser simply won't let you manage those things over a GUI - or, of course, being your own CA and loading your intermediate and/or root into every deployed box on your network of every person that could potentially have to manage those devices over HTTPS.

That's literally my only issue with ipv6, in all honesty.

Highly recommend python or perl myself - and obviously know how to use bash as well.

One related suggestion: Do not become reliant on third party modules/add-ins (other than the standard library stuff) - at least when learning. Really learn how it works.

I wholeheartedly agree with the "similar looking domains" thing. They should just use a subdomain.

If I'm used to visiting "capitalone.com" - and the site to activate a new card is something like "activatecapitalone.com" - that seems sketchy. It should be capitalone.com/activate or activate.capitalone.com -- I tend to simply avoid sketchy sites even if they appear to be from official sources.