If they didn't have RCE but could push config to the router, they might have pushed a syslog destination and then mined the logs. URLs for uncrypted HTTP requests could end up in the logs due to ALG, parental filtering or any other numbers of features. If you replayed such URLs from a large enough set of victims over a long enough period of time, you'd find something valuable in a response sooner or later.
Not sure what the meaning of your comment is. The Stab Trim cutout switches have been in the 737, in the same place aft of the flap selector, since the original 737. These were not a new feature related to the MCAS system.
Yes, the "correct procedure" would be for the pilots to recognize the MCAS problem (whether they know about the existence of MCAS or not) as a runaway stab trim problem, and treat it as such. One of the steps for the runaway stab trim emergency checklist (which I believe is a memory item for 737 pilots) is to set the stab trim switches to cutoff. At that point, they can manually (with the wheels in the cockpit) return the stabilizer to a better trim position, then recover control of the aircraft.
I'm not a real-world airliner pilot (I just play with them in simulators), so I can't comment on whether it's reasonable to expect pilots to recognize the situation and react accordingly in this new failure mode. Without knowledge of the existence of the MCAS system and how it can fail, with uncommanded nose-down, it's unclear that pilots would think there were any factors they recognize that would cause a runaway trim situation and think, "oh, I need to run the runaway trim checklist." I think that's the crux of the argument "any 737 pilot should have been competent to save the plane because they should have recognized runaway stab trim" versus "the set of conditions that caused this problem involved systems that pilots weren't trained on, so it's not reasonable for them to recognize what was happening and realize they can fall back on different training that they did have."
Anyway... comment I was replying to seemed to imply the existence of the stab trim cutout switches implied that the MCAS system was made known to pilots, which is why I pointed out those switches had been there forever.
And (agreeing with you here), if MCAS was only moving the trim 2.5 degrees at a time, it might not look like runaway trim, because it was running away slowly.
You have a good point but I feel overwhelmed with subscriptions today. Between personal and business I have easily got 40 or more paid subscriptions. It's not just media but software too. Mac apps, iPhone apps, web apps. They're hard to cancel and easy to forget (until I check my bank statements). And they dip into my bank account with no renewal confirmation or approval. And they'll happily self-renew for the next year without being used once in the last year.
Of course I signed up to and pre-authorised all of this, and forgot to cancel when I stopped using them, so it's 100% my own fault. But something doesn't feel right about it.
The trouble is that no one actually implements the email standard from the IETF RFC documents. In fact, some people[0] even actively discourage doing so, despite there being little in the way of good reason to not. The argument essentially goes "well, users aren't going to be likely to use those characters, unless they're doing something bad, and they make it difficult to insert the email into the database." I feel like that's a kind of laziness - we can fairly effectively remove that risk, and there are well tested tools to do so. But I do suspect that forbidding '+' is explicitly to avoid people using tagged emails. To be honest, the inconsistency in services allowing me to use '+' has caused me to just create a separate email for services that I don't have high trust for. Now no one gets my personal email, and I only check that one if I'm expecting something important.
I mean, there are good reasons laid out in that document.
"By RFC, email addresses are unique by mixed-case. Most (99.9+%) email systems do not treat email addresses as such."
Think of the average user. Sometimes they're going to capitalize the first letter when putting in their email, and sometimes they aren't. You don't want to make it unusually difficult for them to log in.
You -should- treat email the way that vast majority of hosted services do. "Foo Bar"@gmail.com is not allowed. Covering the million edge cases seems to not be worth the trouble, especially when it might cause difficulty for the average user
> Think of the average user. Sometimes they're going to capitalize the first letter when putting in their email, and sometimes they aren't. You don't want to make it unusually difficult for them to log in.
With smartphone keyboards and the capitalization of the first letter of the first word in form input fields by default, this is a very common occurrence. If case was considered for uniqueness of email addresses, at best, people would be extremely annoyed. At worst, there would be a tremendous amount of leakage of sensitive information to random people (due to human errors in entering case sensitive addresses), chaos due to incorrectly delivered emails and fatigue in receiving mails intended for thousands of other people. In an alternate universe where this is true, email would never have been a killer application, only a quickly killed and abandoned one. :)
Email RFC is weird. Did you know email addresses are supposed to be case sensitive? Like bob@ and Bob@ are two different addresses? Some services treat them this way, most don't. That intersection (oauth2 for example from Google can return [email protected] if Bob has a GA4W account, which causes trouble when the oauth handler inconsistently lower-casifies input.
Really? By my reading RFC-5321 & RFC-5322 leaves interpretation of the local-part up to the software running on the host where the mail is delivered, but since that interpretation is up to those servers, intermediate servers must treat them as case sensitive and not make modifications to the local-part.
That's my interpretation, as well. The standard is for carriers, not mailboxes. As a carrier, (or someone sending an email) you should respect case, as well as respect all of the special characters, because the server is allowed full decision power over whether those things are meaningfully used.
Surely cold storage is compatible with segregated accounts using payment channels or one of the other novel Bitcoin mechanisms. But if not, and cold-storage had to be abandoned, then that would have been a good signal to walk away.
And if accounts had to be segregated then losses should have been segregated too, not socialised.
