B-Con

Facebook is a product, not a monopoly.

"Occupy Wallstreet", which was largely composed of naive college students, pushed the phrase "1%". It's catchy.

It's more like the 0.01% that most people actually mean when they talk about 1%, including Occupy Wallstreet. The actual people at the 1% line are kind of boring.

> "Crime is OK if you think it doesn't hurt anyone."

> Rather than trust busting, why not start with relaxing the federal laws which forbid the development of third-party applications?

Cute phrasing, but what this really means is "why not force anyone who develops a product to allow others to capitalize on it?"

> It seems premature to pursue trust busting action while we still have federal laws that encourage and cement the dominance of a single provider.

You mean "allow a product to exist as a unified product". "Provider" is 100% misleading language.

> Good for them -- it's their town after all!

Doesn't mean they're doing what's actually best for themselves.

FTA:

> There are some house numbers that are about 3 kilometers (1.8 miles) apart,

Sounds like a pain to navigate.

We apologize for the SelfDryv experience disruption experienced by some[0] customers earlier this week[1]. We experienced technical difficulties during a server migration that may[2] have degraded customer experience. The server migration exposed an incorrect dependency between the SelfDryv consumer hardware the the SelfDryv cloud services[3]. We have issued a fix[4] and offer 5 miles credits to any customer who was effected.

[0] About 100%

[1] 54 hours spanning Monday through Wednesday.

[2] ^H absolutely most certainly did

[3] Turns out part of the car's A/C UI dynamically fetches JavaScript on startup and our outage stopped serving JS, so A/C module failed to load. The worker thread that spawns the rest of the car's functionality freezes if the A/C module fails to respond. I guess we never tested that, I mean our internal network is pretty reliable, you know?

[4] We moved the JavaScript to a CDN so that means 100% availability. Presumably eventually we'll rewrite the entire client stack anyway thus implicitly killing this horrible dependency.

What are people's experiences around having requiters you submit a competing offer for them to negotiate against it?

I've had recruiters tell me they need to see a copy of an offer letter in order to match against it. I assume this is to minimize people lying about competing offers to squeeze a few extra percentage points out of their offer and to give the recruiter maximum negotiation leverage.

What response do you get if you just tell them "no"?

Rewording (and hopefully simplifying) for my own benefit because I think the OP is a little loose with the details.

There are two parts:

Part 1: Subdomain takeover

1) DNS for domain X points to service Y (Y=Heroku in this case).

2) Service Y allows anyone to claim an unused domain.

3) Domain X is then claimed by an attacker.

4) Domain X is then served by an attacker.

5) Bonus points if the owner of X has a wildcarded HTTPS cert, so the hijacked subdomain gets HTTPS automatically.

So now attacker serves content on a domain they don't own (possibly over HTTPS). This is already a known cloud hosting mis-configuration problem.

In this case, investor.example.com for HTTPS was not claimed on Heroku but DNS was pointed to Heroku, so it was vulnerable to subdomain takeover. However, the author only had HTTPS access and example.com did NOT have wildcarded cert, so the author was in an edge case of having control of a subdomain but only over HTTPS with no cert.

This prompted them to look for...

Part 2: Abusing TLS-SNI-01 validation

TLS-SNI-01 works by having LetsEncrypt request a cert with a secret from the specified domain.

1) LE does a DNS lookup of the desired domain.

2) LE connects to that domain using TLS-SNI. SNI specifies a hostname in the pre-encryption request.

3) ACME TLS-SNI-01 has the SNI requested domain in the form foo.bar.acme.invalid.

4) Author claimed the necessary foo.bar.acme.invalid hostname on Heroku (and later AWS).

5) Author initiated a LetsEncrypt cert request for a different domain on the same hosting provider.

6) When LE made the SNI request to that domain it did a DNS lookup and got pointed to the shared hosting provider, but the SNI hostname was of the form foo.bar.acme.invalid which was controlled by the attacker, so it was passed to the attacker's app.

6.a (Side note: Because there was no valid cert offered by the hosting provider, I'm guessing the front-ends passed the SNI request through to the backend app. Because if there was a cert configured for the Heroku app then I think the front-ends just serve the cert directly without checking with the backend app.)

7) The attacker then finished the LE cert negotiation and got a cert on behalf of the other domain.

I'm a little fuzzy on exactly how choosing the domain in (3) and (6) works since the spec[0] doesn't seem to match what the blog post shows, but I'm sure it works somehow.

Corrections/clarifications welcome.

Related specs:

[0] https://tools.ietf.org/html/draft-ietf-acme-acme-01#page-40

[1] https://tools.ietf.org/html/rfc6066#page-6

Correct. I fixed it.

> That's right: the customer's tip doesn't get added to the worker's check — it just gets deducted from what Instacart pays. In other words, up-front tips go to Instacart, not to the worker.

My understanding is that the Fair Labor Standards Act does not allow for employers to whithold tips.[0]

Gratuity/tip is a legally recognized concept. You can't just throw the word in your app and do what you want with the money it generates. There are legal expectations around how the money goes from the customer to the worker.

[0] https://www.ramoslaw.com/is-your-employer-committing-wage-th...

[edit] Added "not"

This is one of the idioms of Go I liked. "It's OK to repeat the same 3 lines of code."

My thought process has always been: If there is a common piece of functionality to be shared, then refactor. If it just happens to be the same, maybe leave it.

Supporting privacy would allow browsers to block requests, full stop. There's no way to spin this specific action as pro-privacy.

> There are other features (which I understand are appreciated by many users) which can't be implemented with the declarativeNetRequest API, for examples, ... the disabling of JavaScript execution through the injection of CSP directives, the removal of outgoing Cookie headers, etc.

This is also incredibly important.

It's my HTML, don't restrict me. Let me mangle the web pages I request.

I hate the phrase "screen time". Why does the fact that there's a screen involved matter so much? Many "screen time" activities are more closely related to non-"screen time" activities than to other "screen time" activities.

If the kids is typing a report instead of handwriting it, or reading an ebook instead of a physical one, why does that count as "screen time" along with flappy bird?

Having lost both a family member and close pets that were essentially family... it does make sense. Losing a pet is not the same as losing a human being, but... I can understand the analogy.

A pet may have been an active part of the family for a decade, participating in many of the same activities as the family from dinner time to family outings. Some pets are taken on specifically in times of emotional need, such as after losing a family member or in place of a child that can't be conceived. Such pets may not be actual humans but they do fill a role and fill a hole similar to one.

Again, not the same, but I can see circumstances where the analogy makes sense. And it's special when it does, this doesn't apply to every pet ever.

The problem is similar to bots in gaming. Banning bots predictably gives the attacker (bot builder) clear success/failure signals for evading detection, then it becomes a detect-vs-evade arms race that the bot builders will likely win.

Detecting and monitoring the bots provides a possibly similar outcome, but t with the advantage that he platform knows the bots. If there are bots with way, the platform would probably prefer the option that allowes them to know who the bots are.

The middle ground is basic auto detection/bans for simple abuse and infrequent ban waves for the rest, where bots are detected and all banned together. This makes it hard for the writers to understand which signals have them away and gives them the disincentive of uncertainty. This is popular in gaming, where bot and cheat farms are detected and studied by they platform for up to several months before bans are handed out.

> Note: Yes, both these methods are synchronous. But, given that neither of these methods require any I/O orNetwork requests, its pretty safe to compute them synchronously.

Found this amusing. Are node devs so used to async that disclaimers like this are necessary?

> Why is this still a thing?

Because it's cool and the people building it often aren't security experts.

Autoplay is a cancer that spread across the popular media platforms. Facebook, YouTube, and Netflix seem to have all abandoned the idea that the app shouldn't play distracting video and sound without prompting. (I haven't checked Hulu in years, I don't know what they're up to.)

Remember when it was annoying pop-ups that auto-played video and sound? Now it's a feature to extract as many watch-time minutes from users as possible. I guarantee it's all A/B testing looking for a few points of uptick in watch time.

I can only assume YT bends over backward to cater to the copyright claimees so that the major labels keep uploading their copyrighted content to official channels.

Basically, at some point this conversation happened:

Label: We don't want to upload our music to YouTube because we're afraid of piracy.

YouTube: We promise that won't be a problem. We'll work with you to ensure you'll be happy with the state of things on YouTube.

The current system was born of that and nobody gives a hoot about the small/medium players who get screwed over by the insanity.

> “It’s because the law gave them too much leeway” doesn’t make sense. If you have leeway, you choose the easiest and cheapest method, not the one that involves building a whole new communication system.

No, you choose the most self-interested option. That type of criticism is usually levied against laws that provide an incentive to enforce it in a self-serving way.

In this case what CenturyLink did should itself be illegal. CenturyLink knows fully well this was a self-serving move and they likely only did it because they're betting they can avoid lawsuits by blaming the law.

Interfering with traffic on a paying customer's active account should be illegal so there is no option to do this for any reason.

They don't have to produce the same type of content to be competitors. They are competing to produce video content you spend time on, albeit different types.

But YouTube is hinting they are considering making "TV show" style content, what with most of their YouTube Red exclusive content being of that format. While I find none of it interesting, except Mind Field by VSauce, they clearly have the idea on their radar.

Glad to see my alma mater doing well.

> Some of the distinguishing features of the bot included incorporating language disfluencies — pauses such as “hm” or “ah.”

Note that Google recently faced backlash over this very feature demoed in their Virtual Assistant. I'm guessing that public sentiment won't last long, it's a natural part of human language and it feels funny when it's missing.

More specifically, he uses the phrase "the FBI of the National Parks" to describe this organization.

> Maybe calling free software "Open Source" was a mistake.

This conflation is definitely a bad thing. Words with an actual meaning get over-used, simplified, stripped of their original meaning, and then merged. It would be 100% to the detriment of our language if it happens in this case.

Open source does not mean free (as in freedom or beer), free (as in beer) does not mean open source. Free as in freedom almost always means open source.

Side rant: Also, open source doesn't mean "open to contributions". Giving access to the source code does not mean obligation to accept contributions to said source.

There are many other possible causes for global outages, that specific one is not high on my list of likely culprits.

The user is too focused on the app, and part of the problem is when we stop using correct phrases and start using "app" for everything.

User installed and app and agreed to use a service. User uninstalled an app.

User needs to understand that installing an app and using a service is not an implementation detail, it is a fundamental part of what they are doing. Dumbing our vocabulary down to use "app" for everything makes this education harder.

Clickbait phrasing.

tl;dr:

1) Services can track you based on the data you've given to the app.

2) Obviously, this doesn't stop when you uninstall an app.

3) It's possible (using push notifications) to determine if users have uninstalled.

4) The service behind the app can then track you with a specific "uninstalled the app" status.

As an aside, I dislike the fact that "app" has become such a catch-all. It introduces confusing language, like in this example. The "app" didn't track you because the "app" was a client-side binary for interacting with a service. The service tracked you from the beginning.

> Today only 0.5% of HTTPS connections made by Chrome use TLS 1.0 or 1.1.

Curious who the 0.5% are. Presumably Chrome is doing it's best to avoid falling back to TLS 1.0 or 1.1 unless necessary, so presumably these are sites that just don't support 1.2.

Apache added TLS 1.2 support 6.75 years ago: http://svn.apache.org/viewvc?view=revision&revision=1222922

I'm curious how many of those sites just haven't upgraded their server in ~7 years.

I don't see where in the article this is implied. If anything the fact that half the department will be non-C.S. strongly implies otherwise.