InitialBP

> In addition to the local population, many people travel to cities where sports matches, concerts, and other events (e.g., conventions, auto shows, etc.) are held in the stadiums.

The article directly addressed this point by saying:

While counter-intuitive, tourism does not see an increase as the result of a sporting event, as often a similar amount would be spent by that city’s residents in a different city, thus creating no real net gain.

Now this may not be true for concerts or other events held in the stadium, but in general I think the idea is that the study indicates sports events don't generate significant tourism, instead drawing a primarily local crowd.

I would also argue that most people would have no issue(or minor issues) with local governments subsidizing _Some_ of the cost of a new stadium and other forms of entertainment. I think the issue comes in when the financial cost is extraordinary (> 1 billion USD).

If you're referring to the Russia Ukraine conflict with note about sanctions I don't think we've seen indication that sanctions are an "effective means" of pushback considering the fact that the Russia continues to wage war against Ukraine.

I can appreciate that solution. Admittedly I didn't know anything about the app since I don't have access to any device to view it.

They don't mean literally nobody cares about the product, just that this conversation isn't necessarily related directly to the product but more about design in general. My original point is just that it's a design that locks people into using the app with a very specific medium and it locks people out of accessing it on another medium with no details about why.

That's a pattern that most people would agree they don't like and my comment is meant to be a criticism of that.

> That's their problem, no one else's.

It was posted in a public forum for discussion, is it really wrong to critique or praise the product in this setting?

It's not just an annoyance, it makes your site literally unusable on a mobile device. What if I urgently need to access some details of my account and don't have laptop access. If I check "load desktop site" then load the site and let me deal with the broken UI.

This is a ridiculous "feature" and the fact that you are defending something like this is a major turn off on ever using this product. What other hill would you be "willing to die on" for some seemingly miniscule yet exceptionally annoying feature.

> I have autofill turned off because it can fill into nefarious forms if you're not careful.

One nice feature that 1pass has is that it will warn you when you attempt to autofill credentials for a url or mobile application that isn't listed as part of the credential.

e.g. 1pass "Logins" have a URI associated with them like "google.com" and if you visit a phishing site like "g00gle.com" and hit autofill 1pass says something along the lines of "Are you sure you want to fill these creds into g00gle.com?" and not fill until you approve. It's not foolproof, but certainly provides a nice barrier against fake login/phishing sites.

To be fair I'm not familiar with the dropbox+1pass combo solution you're referring to, but I imagine that the people using that solution are in the minority and that by focusing on one unified solution and not spending time supporting an old one probably provides net positive experiences across their product.

I kind of agree that if it works and it's in place just leave it be, but if it needs maintenance time, support time, and even development time as the product evolves then I can see the "business folks" pushing for the removal of those features so the team can focus on what more people are using.

Your argument against escaping is the same one against input sanitization. Literally you cannot know where all your data will go when storing it so how do you even begin to sanitize that data? No special characters? Alphanumerics only? You're going to have a bunch of modified data that user's are unhappy with to start. Furthermore you have the same problem with simply not knowing all of the ways that data will get into your system, so you won't be able to reliably sanitize all of your inputs. (e.g. manual entry, internal tools, random scripts, etc.)

I understand defense in depth and by all means doing some sanitization up front can help increase your defensive posture (Often at the cost of user experience), but the proper and effective way to protect any of 100000s of use cases for your data is to ensure that each use case is escaping data relevant to that use case.

Direct responses:

1. If you store simply store the data, it is not your responsibility to ensure that the data is "sanitized", but simply to ensure that the data follows the expected format. Rather *the onus of security is on the person actually Using the data.*

2. I have tested applications and written up findings where customer's use internal data to generate excel files w/ PII in them, and one user could steal another the PII of employees from another customer due to CSV injection. Yes these attacks are weird and niche, and even if this one attack doesn't matter, it's just an example of various weird attacks. If you are writing software where you take user data and put it into strange filetypes or systems, you should be researching those systems and writing code that doesn't break or have unexpected issues. You can find the necessary technical documents to figure out how to escape things. (https://owasp.org/www-community/attacks/CSV_Injection)

Finally, input validation is not input sanitization. Validation is making sure it conforms to your expected data-type (e.g. Username cannot contain special characters.) Sanitization is when the application modifies data that the user has submitted - e.g. stripping off special characters from names (O'Brien => OBrien).

You keep saying "Do defense in depth" but your argument is why sanitization is better. Do both, but ALWAYS escape if you have to choose.

Agree and Disagree. Sanitization has it's place, but from a user perspective it's better to just outright reject (through validation) inputs that aren't valid.

There are often unexpected ways that data gets into the system (IT manually adding data, internal support tool to help customers add data, etc.) You need to ensure that you're properly sanitizing your input at every single input faucet and your sanitization has to predict how, when, and where it will be used by sanitizing for dangerous characters in filenames, shell, spreadsheet formula vulns, and XSS attacks.

Instead, (Or In addition to) just make the assumption that data in the database is dangerous, and ensure that you properly escape for your use case when using that data.

Using a username to create a new file? Escape for filenames based on which OS/language your using.

Using birthdates in an excel file? Escape for excel formulas.

Using bio on an HTML page? HTML Escape.

Using username as part of a URL path? URL Escape.

And finally circle back to the fact that sanitization where you change user input without their knowledge (like the "O'brien" -> "Obrien" example in the article) creates for a frustrating user experience.

Alternatively...

validate (client side) => insert using sql parameterization (escaping) => escape per context when outputting

Sanitizing is the idea that you are cleaning dangerous things from the original input (different than validating which is disallowing user's to input characters that don't conform to what your program expects).

One BIG issue here is that validation is generally clear to the user ("That is an invalid email address") whereas sanitization normally doesn't consult or inform the user that there were changes and may result in unexpected things happening from a user perspective.

From article: name is "John O'Brien" now displays as "John OBrien" (this is a trivial example but still an issue)

The name thing is a great example of things you might not expect your users to do but are still totally valid use cases. Sanitization can be Extremely frustrating from a user perspective.

Insert using SQL parameters is "escaping". The parameterization ensures that the data being passed gets interpreted by the DB as the expected data type by ensuring special characters aren't interpreted as "special" in that context.

While I generally agree that solar winds was lacking a lot on their internal DnR team (iv cut investments in cybersecurity) a lot of the identified issues are things that are seen in businesses EVERYWHERE.

Until recently I was a pen tester and (just a guestimate) 9/10 clients that I do testing for don't properly segment IT networks, use weak passwords for things they shouldn't, and list sensitive and high-value clients on their webpage (they are trying to draw other customers in).

I'd like to clarify two points:

1. It doesn't matter how much money you spend on security - there will ALWAYS be a way for attackers to get in. E.g. Log4J issues recently. There is always gonna be another zero-day or a new email phishing payload or a new NSA hacking tool leak and at most a big company can pay a lot of money and hire a lot of engineers to Reduce the chance of something bad happening.

2. None of these practices are really that unusual (I've seen plenty of software that recommends to tell your AV to ignore it.) and actually managing and knowing about every single credential/password etc in a corp network is almost impossible. Usually things like the FTP server with a weak password get set up long before the company hires their first security engineer, and then refuses to make changes to existing stuff that would take a lot of time and effort.

I do feel that SolarWinds is on the hook for this, especially egregious is (iv cut investments) because of their exceptionally high value clients and the level of access they get into client environments.

However, I don't think it would have mattered much how much money they put into their security team, the team that ran the operation was likely a state-sponsored team and they probably had the funds/people/time to crack such a juicy target regardless of how difficult it was going to be.

When you say "Audit" do you mean in terms of security?

I was a penetration tester for a while and it was quite common for my clients to have customers who requested a security audit of their product. We would conduct the assessment and provide them with a letter that basically says we did an audit and we found x number of crit/high/med/low issues and then did a retest to verify that client fixed x number of crit/high/med/low issues. Might be worth a shot!

I know Mozilla has also done some similar stuff, but they normally release the entirety of the report. https://blog.mozilla.org/security/files/2021/08/FVP-02-repor...

The YubiKey's that support NFC are all significantly larger. The Nano does not currently support NFC. Size is a challenge with NFC specifically as I believe larger NFC chips lead to larger area of allowable communication.

Penetration tester here. While my company was concerned about business at the beginning of the pandemic, we quickly saw a large uptick in business from corporate customers who were integrating remote employees into their new norm.

These have been implemented in a lot of places extensively, such as Germany. There are also some implementations in the US. One such that I drove on often is when I-70 eastbound runs into the beltway at Baltimore, MD.

The only problem with zipper merging (much like roundabouts) is a lack of education around how they work and WHY they work. Adjust the education we give new drivers and over time our roads will become more efficient.

Regardless of whether PHP solved this particular problem, it also caused a lot of its own due to numerous security issues and documentation that encouraged unsafe use of libraries, until recently.

These aareas of West Virginia and Virginia are exceptionally beautiful and serene places to visit, if you ever get a chance to drive by the Green Bank telescope it is Massive! In fact the dish of the telescope has a diameter of around 300 feet.

On top of just "compliance" or "customers demand it", these types of penetration tests can and do expose real, serious vulnerabilities in software.

Furthermore, I wouldn't underestimate the positive press that having a third party security firm assess your product and share the results publicly. VPN Services have been under special scrutiny lately so I think something like this makes total sense for Mozilla, regardless of the cost.

Penetration tester here - My anecdotal experience:

I've worked on a number of projects where bill rate is something like $250-$400/hr per engineer depending on complexity, access to source code, size of the project, etc.

Usually equating to something like 10-12k for a single engineer on a project for a week. For bigger projects like this I would think it's totally reasonable to see anything from 4 engineering weeks -> 12 engineering weeks depending on different pieces and especially given this is a very high profile project. Based on that estimate of something between ~40k-120k. I know that's a huge range, but just wanted to share what I do know.

In order to rollout a whole new ID system you'd need so way to validate the identity of the recipient before you gave them a new one. Presumably the easiest way would be just to turn in your old ID card, which many people don't have, per the previous comment.

I think in general you'll just see a lot of those restaurants and businesses that provide services to office employees move to where they can provide services to remote employees. Service industry businesses generally follow people and if people aren't going downtown everyday and instead hanging around the suburbs, then you'll likely see more starbucks etc in the suburbs serving that crowd.

Just a thought on point number 2.

I fully agree with you that a good "product" and design is a reason for people to pick one content provider over another. It's almost exclusively about what content a provider has access to.

One particular example that I would call out is funimation. They offer a streaming service that has a very large library of english dubbed anime. Their platform sucks - missing features, constantly receive errors about needing a subscription (even when you're a pro member), sometimes specific episodes just won't player. Yet, they are still a huge player in the market because they offer content that people want.

to be fair "Free and open" is different than "Free and Open Source".

Open source has a much stronger connotation than open and I could certainly see calling it open if the source is available for the core of the product.

I don't think correcthorsebatterystaple is easier to crack than the Troubador variation. Hash cracking often includes the use of a wordlist and a ruleset which builds variations on the words from a wordlist. Some common ones I use for my job are OneRule and Hob0Rules. Notably I did run the word "troubador" through these and did not get the final result of "Tr0ub4dor&3" but they did both produce "Tr0ub4dor". These rulesets both produce > 50k passwords from a single word to guess so it's not outside the realm of possibility to have more/better rulesets that are used.

On the other hand, while it's definitely feasible to take a wordlist and make random permutations of sticking words together, I think in general that sort of password is used less often.

100% Agree password managers are the way to go, but for people that aren't using them I would definitely suggest long/multiple random words together over short LEETspeek with special char number tacked onto the end style password.

https://github.com/NotSoSecure/password_cracking_rules https://github.com/praetorian-inc/Hob0Rules

What kind of situation occurs where you can't input special characters in a password field?

I think in general the advice is that there should not be any limitations on special characters anywhere in the tech stack at all. (Including a broken UI that won't let you input special characters.)

The situation you described sounds more to me like a very poorly written application.

Slack authentication works like many other web applications and once you've successfully authenticated you get a cookie which can be used to read/send messages on your behalf.

If someone managed to get some malware running on a machine where you have logged into slack it's fairly trivial for someone to get your cookie. Something like https://github.com/djhohnstein/SharpChromium is an example of a tool used to pull browser cookies off a compromised host.

I don't know the explicit details of this particular instance, but I imagine the user in question had some kind of malware installed on their phone or computer. ( I keep seeing mention of a browser extension in the comments, and I have seen some working examples of malicious chrome extensions recently that would let you steal cookies once installed.)

Mazda has been focused on continuing to improve internal combustion engines over the past couple of decades. Specifically, the "Skyactiv" technology they developed was built to help improve efficiency and emissions of modern ICE engines. It's likely Toyota wanted to have some group/company (like Mazda) continue working on improving ICE engines while also investing in EVs.

I think ICE vehicles will continue to have a market, especially in very remote areas of the world where power grids are non-existent or not very reliable.

Mazda hasn't sold a production car with a rotary engine in a while, I believe since the RX-8 went out of production. Due to the nature of rotary engines they inherently have worse emissions (more like a 2-stroke than a 4-stroke) and while people have been hoping for another production rotary from Mazda it's unclear if they will build another one or not.

I signed my parents up for the Beta in WV sometime in 2021 (I don't remember exactly when, and did not have any issues.)