skysight-inc/HackerNews huggingface dataset:
Omm IT Solutions | AWS Security Specialist | Baltimore, MD | www.ommincorp.com | Onsite |

Omm is a Columbia, MD based Information Technology Solutions and Professional Services provider. We provide custom solutions and services while keeping focus on the goals and objectives of our clients in mind. Our team consists of leaders who provide a unique balance of expertise, vision and humility. At Omm, we strongly believe in what we do and how we do it, consistently delivering results with integrity, focus, teamwork, and respect.

We are looking for a Security Senior Executive to assist in the development of a Notification Service that delivers SMS/text and email messages to our client's users by making use of Amazon's Secure Notification Service (SNS) and Secure Email Service (SES). AWS Security Specialist will be responsible for defining the security architecture of the solution and working with client's Security Leads to achieve ATO for the solution.

We are looking for a Security Compliance Specialist with good experience in AWS, Vulnerability Testing, Threat detection, Firewall Management, SES, NES, Security Architecture.

If you are a good fit for this role, please send your resume to careers@ommincorp.com reply
Burglary occurs every 13 seconds and victims know the offender 65% of the time
It's a good point, I just opened an issue about that, feel free to add more context on it: https://gitlab.com/gitlab-org/gitlab-ce/issues/35022
On Systems and Leverage Points
Is it really the time, yet, to start advocating for rewrites in Rust? Worth considering for new projects, definitely. Using to write new components of existing projects, maybe. But rewriting existing work?

I'm concerned if we start pushing that too much too early, the initial friction will burn people. You only get one first impression.

For anyone who thinks "yes, now is the time" I have questions for you:

Have you released and distributed software written in Rust? What's the install story like for end-users? Is it in a repository for a major OS (e.g. can I yum install it, or apt-get it) and if so which?

As far as I can tell there's no major package manager accepting or even ready to accept programs written in Rust yet. Am I misinformed?
I look forward to it.
> If AFL would catch the same bugs, Rust isn't better than C in this case.

You can find a list of my vobsub bugs in the Rust Fuzz Trophy Case: https://github.com/rust-fuzz/trophy-case They are:

1. The shift overflow: This was harmless in both C and Rust, I believe.

2. The arithmetic overflow: This was a runtime panic in Rust, resulting in a clean crash. In C, this might have been exploitable with a complex enough attack.

3. The three "invalid slice" errors. All of these were clean runtime panics in Rust, and I'm pretty sure that at least two of them would have been exploitable in C with enough work.

So Rust has a couple of advantages here. Out of 5 errors found by the fuzzer, the worst thing that could happen in Rust would have been crashing the program in a controlled fashion. In C, we would have been looking at memory corruption and quite possibly escalation.

Secondly, Rust's runtime checks actually make fuzzers work better. Even simple checks like "is the end index of this slice great >= to the beginning index?" tend to catch problems almost as soon as they occur.
If you're very concerned about it, you can implement your own solution sending HTTP calls to GA: https://developers.google.com/analytics/devguides/collection...
Detecting NoSQL Injection
I don't agree with the underlying thesis: In 15 years, I'll be heartbroken if we're still facing an endless stream of security updates and remote root compromises when all these projects were rewritten in a popular but unsafe language: Rust.

There do exist fast and SAFE language out there. With guaranteed memory safety, null pointer safety, concurrency safety, dead-lock freedom, race freedom, and even with normal syntax. Rust is not one of them. When will all these rust fanboys finally see the light?
My guess is Kennedy will punt and say there are two many models to choose from with no clear way to determine which one is best even though they are clearly better than what we have now.
> Such an incredible waste of power and hardware, for a payment system that does something like 3 transactions per second globally.

Bitcoin does a few transactions per second on-chain, however those few transactions per second support many more transactions per second on systems built on top of Bitcoin in a similar way to how the tx-per-second Canada's inter-bank transfer system does is quite low, but those settlement transactions support orders of magnitude more transactions per second on systems built on top of that settlement system.

An example of exactly what you proposed is Blockstream's Liquid sidechain technology, which maintains a high-speed ledger secured via multi-party signing between various exchanges to allow high speed, highly efficient, off-chain transactions backed by on-chain Bitcoins.
Integration Testing Against Real Databases
Depends if you want collaboration with designers or not.
Sigh. This again.

The Rust language is more than just memory safety. Memory safety is certainly the most prominent and unique feature of Rust, but the language also includes a lot of features that make writing good, bug-free code easier.

For example:

`Result`, when returned, forces all callees to check for errors. It's all too easy to throw away error codes in C/C++. This is probably one of the most important features in Rust, besides memory safety.

To easily consume an `Enum`, you have to use `match`, which forces you to handle all members of the enum. In C/C++ it's easy to build a switch for an enum, and then later when a new member is added to the enum and you forget to update all your switches.

Support for multiple return values (through tuples) means being able to avoid the nightmare of output pointer arguments to functions.

No NULL pointers.

Unit testing built into the canonical tooling.

Documentation testing built into the canonical tooling.

The `Option` type, which lets you return "nothing". In C/C++ you'd have to return a bool, and again use a nightmarish output pointer argument.

`OsRng` in the rand crate (go ahead, try to write a function that safely reads urandom in C).

No undefined behavior.

The list goes on. The flavor of it, is that Rust makes it easier to write defensive code. Defensive code is code that is hard to use wrong. For example, for a backup solution I built using Rust, I made all the cryptographic types their own unique, opaque types. EncryptionKey, HmacKey, Salt, etc. For someone new to the codebase, these types make it obvious what each function is asking for, and make it really difficult to use the functions or the types the wrong way. And they are super easy to build and use in Rust, see my code: https://github.com/fpgaminer/preserve/blob/master/src/keysto...

C++ would require a whole set of classes, and require instantiating a new class every time I want to add a new cryptographic type. Rust only requires 3 lines per type.

TL;DR: The real magic is that it's easier to do the right thing in Rust.
>> broad compatibility with websites

> a browser which has privacy as a core principle

Sorry, but sad truth is, those two things are mutually exclusive.

The modern web is all about running pieces of code. Websites give you a code and expect you to run it (or they'll break). You can throw in some heuristics (e.g. blacklist known offenders and replace them with do-nothing shims) and try to keep up with the ever-changing world, but here is just no way to have this guesswork as a core principle and expect things to not break.
Don't forget about the incredible women who helped the Apollo missions happen:

https://www.scientificamerican.com/article/the-story-of-nasa...

---

That said, I want to respond to the line about being poor at maths.
I wasn't. I was a 90th percentile student in the sciences as well. But my teachers made it terribly boring, and I was from a very small town where there were little to no resources to reach out to out of interest. Our library had a computer, though. And my mom had an old 286 -- I think that changed everything. Once the internet arrived out there it was my window to a larger world that television certainly couldn't provide. (outside of literature, of course. And I wound up studying literature... yet here I am currently employed as a programmer because of 20 years of personal interest)
https://www.youtube.com/watch?v=s1IzN9tst28
One implication is that C would have had more errors, but that's a hard judgement to make. It's probably true.

The thing that really matters is that these errors which the fuzzer found aren't exploitable -- memory errors in rust are guaranteed to panic (unsafe aside) instead of susceptible to overflows, etc. Since fuzzing is very much more of an art than a science, this guarantee is important.
You must not have the upgraded user account plan. It covers the bandwidth levies that certain high-traffic sites must pay to guarantee the full experience. Otherwise, ISP's have to degrade service for everyone to ensure "optimal" experience. /s

It's Net Neutrality and a call to action.
Or better, why not pascal?

The HONEST question is because developers hate progress. We could have left in the past C/C++ by now, but not, is better to move forward with the same problems as DECADES ago.

Rust is a potential contender because is not that far from C/C++, and have {}, and the last point is not even a joke.

-----

Is weird to me why a clean fork of C/C++ was not made, if the prospect to move to something else was too much progress for the minds of the industry, the slow progress is a good alternative. You could have C.1, C.2, C.3, etc...

Think how much is about "modern C, modern C++, coding well" and then why not commit all that wisdom as the language?

The creator of Pascal made a point that a new version of a language must remove and correct the mistakes of the precious version, not accumulate problems.

That is fight AGAINST entropy.
The problem with that approach is that, many technically literate Firefox users will deliberately opt-in to Telemetry as a component of their support for a pro-privacy product.

Telemetry actively benefits development of Firefox, and a pro-privacy user will want to strategically share their data with entities they trust in order to row back against the tide of entities that they do not trust.

Frankly, Mozilla are shooting themselves in the foot by sending any data from any of their products or web properties to their primary competitor.
It's probably a core part of their scalability that they never have to produce a complete list of posts. Every fetch is on best effort basis within a small time constraint.
What platform? We test on every current major client platform (macOS 10.12, Windows 10, Ubuntu 17.04, iOS 10, Android 7, etc.)
As I mentioned in #1107: we will not be
removing analytics support entirely. It
is extremely useful to us and we have
already weighed the cost/benefit of
using tracking.

https://github.com/mozilla/addons-frontend/issues/1107

Ew. Firefox, I am ashamed to know you.
That's probably also true of Ruby and Python re hiring so the numbers are still relevant.
The AI Entrepreneur’s Moral Dilemma. Which side do you fall on?
> Either we do nothing, and nothing changes

The entire premise of NN advocacy that things will change. Read the original site.
> The valid arguments I read from industry groups like WISPA cite significant uncertainty in what Title II regulations would actually look like in practice.

The reclassification wasn't abstract; the actual regulations under Title II were included in the order with the reclassification.

Any uncertainty about future regulations is unresolved by rescinding the reclassification now, since anything that could have been done under regulation with the reclassification can still be done in the future (it might take reclassifying again, but since that can be done in the same action as the concrete regulation, that's immaterial.)
Yeah, the openssl codebase was pretty crazy due to cross platform support over multiple decades...I guess it grew organically and turned into a enough of a mess that the OpenBSD team started the libressl project. There are some pretty good youtube videos about the work that they did.
It is not a problem to the consumer, but a problem to small or up coming companies. If users are being incentivized to use a particular service, then it makes it harder for any new comer to even compete at the same playing field.
I totally agree, and had to Google for answers for this decision.

The rationale, at least what I found, to be that people wouldn't let it completely charge with a different design, but with this one people would leave it charging overnight. Also something about users ignoring the fact that it's wireless and just always use it with the cable attached.
I think OP meant to pre-send music and keep the next 15 seconds available locally. This way you can handle 15 seconds of interruption.

So, when you start streaming music, it starts playing immediately, but it tries to send data faster than it is played until you have a decent buffer. Obviously, this would only work for non-realtime things.
For me, the really sad fact here is that they picked that place to run their bitcoin mine because the electricity there is cheap, but what that poor place can benefit from those mines after providing them with such more affordable energy? I just saw pollution and greedy there.
Personally I wish my state would enact a law that says representative districts must be drawn to cross as few county lines as possible.

Yes, some manipulation would still be possible, but it would be greatly diminished.
I’d argue the root cause is more that Mozilla is willing to trade away privacy for developer convenience.

Oh, not arguing that. Even with Google out of the picture entirely, Telemetry is a nice example. But I'd argue it is needed to stay relevant as a browser. So it's not a good counterargument to Mozilla's decision here.

You can see from the relevant bugs that GA vs Piwik and such were certainly considered, so people are definitely thinking about "maybe we shouldn't do that". In the case of GA, it ended up with required data silo-ing on Google's side.

For some people that won't be enough.
We don't moderate HN that way. Nor is there a 'generally accepted' view in the community about any divisive topic, for the simple reason that the community is too large. The views here reflect the divisions in society as a whole, just as any sufficiently large sample would. (Edit: really I should say 'societies', because there are deep divisions across geographical and cultural lines as well. Those are largely invisible and have a stronger influence than most people realize.)

What does commonly happen is that people with strongly opposing views imagine that the HN community and/or mods are stacked against them. This perception is in the eye of the beholder (a.k.a. a cognitive bias), because all sides make the same claim and in both intensity and direction it always corresponds to the perceiver's own political commitment.

I've written about this a bunch if anyone wants to read more about this dynamic: https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme....
While I am avid supporter of Rust, I can't help but feel this post is not right. If Rust is so much better, why not prove it by writing software in Rust, instead of words. After all, if Rust is so much better, the result will speak for itself.
The ISPs are not operating in "competitive markets", so they are not operating in capitalist markets.
Heartbleed included memory safety violation. A hand crafted Malloc replacement was used to manage buffers. Uninitialized memory of new buffers was able to be read which allowed the extraction of secrets.

Now the reason why some people claim that Rust would not have stopped it, is that a similar leaky buffer system is possible to be written in Rust. This however is just applicable if you just use byte buffers for everything. At that point you become close to emulation. Also if the system malloc is shit, you just use jemalloc which is the standard for Rust. So there is no need to roll your own malloc replacement in Rust
You can start up a machine on either of those providers and then run the install scripts locally. Plenty of people have done it. Note: this is the same answer for every hosting provider, as long as they support Ubuntu 16.04 or 17.04.
Interesting comment by Gorhill from the above discussion:

>> I thought web extensions couldn't block that content.

> I just ran a couple of tests, and I believe you are correct.

> Legacy uBlock Origin can block the network request to GA.

> However webext-hybrid uBO as per Network pane in dev tools does not block it. Same for pure webext Ghostery, the network request to GA was not blocked, again as per Network pane in dev tools.

> What is concerning is that both uBO webext-hybrid and Ghostery report the network request to GA as being blocked, while it is really not as per Network pane in dev tools. It's as if the order to block/redirect the network request was silently ignored by the webRequest API, and this causes webext-based blockers to incorrectly and misleadingly report to users what is really happening internally, GA was not really blocked on about:addons, but there is no way for the webext blockers to know this and report properly to users.

> This is what I have observed, hopefully this can be confirmed by others.
I've been playing a bit around with L4 kernels and some more of Minix 3 from before. Genode seems nice but never had the opportunity to test it yet.

The rest was all new for me, thanks for the information :)
Reddit idea with logo is pretty good too to get attention. If you didn't seen it just visit reddit.
All infrastructure is a matter of trade-offs. Sure, they could have built the platforms 3 times wider, with funnels leading to the doors, and gates that open/close to prevent people from falling onto the tracks. But that would be an extreme increase in cost to build, and wouldn't lead to a significantly larger number of people able to take the train. This app doesn't improve matters: it causes an additional "tragedy of the commons" situation. By being the first one on the platform, you may get to claim your seat, at the common cost of making it harder for everyone else to get out of/on to the train.

Yes, at peak times there is congestion (just like at peak times there's highway congestion), and the existing infrastructure (built mostly before 1930) was built to be significantly safer and more efficient than existing systems. And 90 years later, it still is usually the most efficient and safest mode of transport in NYC. But given the record number of subway riders and record age of the infrastructure, it takes everyone pitching in a little to not make the situation intolerable. Part of that "pitching in" is "Don't go onto the platform before the train's riders have left".
Can you be specific about which languages you include in the category of "fast and SAFE"?
Scientists Design Solar Cell That Captures Nearly All Energy of Solar Spectrum
The point here is that a runtime panic is not an exploitable event - at the very worst, it's a DoS as it usually results in the program exiting.

AFL isn't even nearly guaranteed to catch everything, but what it's shown here is that the program contained bugs which would've resulted in an exploitable event in C. The program probably contains more bugs, but following this pattern, it's more likely that they result in panics in most of the worst cases, not exploitable events.
Where have you lived? I've had AT&T U-Verse (DSL) in Indianapolis, Chicago, and Greensboro, with speeds of 18/1.5 and 40/6.
I followed specifically to be informed of events. It was quite infuriating when they changed algorithm and I missed them. If I get notices from pages/groups I dont care about anymore, I either unfollow or mute the next time their post annoys me.

Quite a few friends were following pages for the same reason.
That's described in detail in this blog post on Algo: https://blog.trailofbits.com/2016/12/12/meet-algo-the-vpn-th...

-----

Streisand is no better

Good concept. Poor implementation.

It installs ~40 services, including numerous remote access services, a Tor relay node, and out-of-date software. It leaves you with dozens of keys to manage and it allows weak crypto.

That’s a hefty footprint and it’s too complicated for any reasonable person to secure. If you set up an individual server just for yourself, you’d never know if or when an attacker compromised it.
There is a similar issue with the MBTA commuter rail in Boston. At south station, the signage in the main waiting area and at the platform only announce the train 10 minutes before departure.

However, there are a couple of tools to get around this. For Starters, each revenue service train has a number (like 508). In a push-pull system like the MBTA the first coach in the consist is nearest to to the platform. This coach has a number like 1827. Luckily, the MBTA publishes which trainsets will be assigned to which departures. This makes it easy to know that 1827 is for train 508. All you need to do is walk out to the platform and see if 1827 is sitting there.. if so it's your train. You can get this mapping of trainset to train via a bunch of apps.

This has been further expanded upon by micro-social apps like "MBTA Rail Tracker" which has a comment section for every train. The whole thread is basically "which platform" followed by a bunch of responses and then snarkiness on why the trains are horribly late all the time.
I can't tell if this is sarcasm, this took me literally 3 seconds to route around using CMD+L and typing "news." and hitting enter. I'm all for good UX but this seems supremely picky.
astroturfing about these issues IS real, its naive to stick your head in the sand about it.

I mean look at stuff like this

https://www.fiverr.com/gigs/reddit

http://www.hack-pr.com/library/how-we-hacked-reddit-to-gener...

https://www.theverge.com/2017/5/10/15610744/anti-net-neutral...

This is the reality, PR firms are on overdrive on social media sites about issues that are politically sensitive. Its irresponsible NOT to question the motives of commenters.

I mean surely as an HN moderator you have seen more than a few shady situations.

HN is extremely politically influential in the tech sphere, pg has said himself that its the subject of campaigns like this.

we can not afford to ignore this problem.
On the other hand, I get more (and less relevant) notifications the less I’m active.

$friendINeverTalkTo has commented on $PostByPageIDontFollow is NOT something I want to get notified about. Neither is

XYZ has uploaded a photo
It's called FUD.
I have a different color set and it is still gray for me, so I'm not sure why you're missing this one.
> There is still a problem that some sites will have a service worker and some will not.

Why is that a problem?

> By the way promises is another poorly designed technology: they catch unhandled errors and do not report them in any standard way

If you're using promises there is really no reason to not be handling your errors. Catching unhandled errors is by design and it works great. It's absolutely trivial to do.

And, as the SO post you've linked to points out, you can catch unhandled promise errors using window.onunhandledrejection. It's not like it's that dramatically different to window.onerror. Promises might not be perfect, but they're better than JS callback hell in absolutely every way.
For sensitive documents, nothing beats Wingdings.
I think you aren't understanding what parent comment is trying to say. No one is saying rust isn't better than C in some respects, instead, you were comparing Rust + Fuzzing with C and he implied that you should at least use C + AFL if you want to compare properly otherwise it's just BS.
I believe Firefox as of recent versions requires a Rust compiler to be available, and that's a pretty bread-and-butter application to have in your distro's package repository.