photon12

Here's an open ZK benchmark project that Polygon Miden (their primary STARK product) is a part of: https://github.com/delendum-xyz/zk-benchmarking

They are going big on scaling Ethereum with zero-knowledge (or more accurately, succinct but not necessarily zero-knowledge) proofs. I used to work for one of their competitors also in that project, but all the Polygon people I've talked to on the ZK side are very sharp.

"Wrong" seems overly absolute, as evidenced by my experience. This is going to impact retention in mission critical, "keep the lights on and keep regulators from levying big fines" adjacent departments. I don't see how holding people accountable to outcomes implies the need for a strict policy.

Especially at AWS where you have bays of people with door desks, it can get very loud and distracting in the office!

I had a friend I was helping get settled in Seattle who moved from the small town we both grew up in by sharing rent, it was a voluntary choice. And my roommate had lots more job opportunities than where we grew up and now he's doing really well, and I'm grateful Seattle offered that to him.

Kinda off topic though?

"that its unproductive, lazy, or whatever"

If you have bad management, it will be. If you trust your managers to implement remote work and do performance reviews after, you wouldn't need to make a blanket policy. Ultimately, the Amazon S-team sees enough of its managers as unable to effectively implement remote work to require the blanket policy.

If they wanted to earn and develop trust and say they are making this decision to avoid markdowns on their corporate real estate, they could have said that.

It was optional, you could keep your camera off or not join ever if you wanted. When I was remote, I usually didn't join and just kept in touch on Chime text rooms unless my tasks that day needed a higher level of coordination.

When I was at AWS around 2018, well before the pandemic, I worked on a team that was structured as remote first. I spent two days appx in the office a week because I had an easy commute and it was nicer than my two bed apartment I shared with a roommate at times. We worked with IT to get a videoconference setup going where we could all hang out on Chime together for hours and hours through the workday. We did a lot of good work and had a manager who cared a lot about the ability for his team to have the flexibility they need to do their best work. And they did do their best work remote, with multiple team members living miles and miles from any corporate location. We had quarterlyish meetups and hung out at conferences together. We retained talent we couldn't have otherwise.

That Amazon doesn't trust its managers to make these decisions best for their two-pizza scope says a lot about the hierarchy of the company.

Also can't forget the environmental and economic impacts of more commuting, especially in what could still be considered a wartime energy market.

"Mitsubishi Hyper-Heat, which I believe is only installed as a mini-split"

It's not a mini-split.

I put in a new Mitsubishi Hyper-Heat heat pump last summer. It got down to 17 Farenheit in Seattle this winter. There are no heat strips or supplementary heating arrangements. The heat pump performed well the entire winter.

My energy bills are 1/2 of what I was paying with an electric furnace last year.

There were MPC experts at the company I was at. We talked a lot about account abstraction design for our stack we were building. I'm not unfamiliar with anything you are suggesting. I'm saying there are classes of users for which there are no good solutions.

Different people have different threat models.

One question I have in all of this: are people building and using these apps actually marking all transactions as capital losses or gains? [1] A big thing that stops me from even playing around in these systems is not wanting to deal with the tax hassle.

[1] https://www.irs.gov/businesses/small-businesses-self-employe...

100% of users have to trust the code used to generate random numbers for private keys they care about isn't backdoored. Only a subset of users will be able to do this successfully. There is no safety net or recourse for people who will lose their money to backdoored refurbished hardware wallets. Because poor people won't be able to afford newer wallets and will be scammed. There is no good solution to this problem that is actually usable by all classes of people who need financial services.

I recently left a company that pivoted hard to building blockchain infrastructure because I couldn't find any way I could ever recommend my friends or family interact with the services the company was building. A lot of people are holding out for technical vaporware to solve these problems. I can't hold out anymore.

If you like making every use of the computer a taxable capital gain or loss, you can "use" the computer for some definition of "use."

Zero-knowledge proof generation, for one.

Edit, see for example: https://www.zprize.io/prizes/accelerating-ntt-operations-on-...

Bringing it up here isn't a distraction, it's central to my main point: the workflow of having a user agent refresh its persistent state is an expected use case, and therefore signal analysis should understand that for some users, the non-existence of a persistent cookie is no indication of elevated risk above baseline.

I don't understand some of the ways you are using terms e.g. when you say "user agent" it sounds like you mean the User-Agent HTTP header, which is trivial to spoof, but that isn't how I'm using the word user agent, which I'm saying means the agent that a given user acts with.

I also don't quite understand your threat model here and the details of what you're proposing is an attack. If you are a user who Google consistently knows has a persistent cookie at auth time, Google can expect that in the future and therefore use that as a data point in risk based authentication. If you are a user who Google consistently knows doesn't have a persistent cookie at auth time, Google can't rely on that data point providing any signal in risk based auth, and seems to be DoSing, or at least frustrating, users in that scenario.

I can't quite respond to your comment because I don't fully understand it.

A user agent that refreshes parts of its profile at the end of a session and deletes data, hopefully, should be something a company like Google can pick up on after enough attempts. "We can't expect the nonexistence of a persistent cookie means the user is using a new user agent because of a persistent history of successful authentication attempts without such cookie present" is not a tall order for a company like Google who is running these experiments on their users.

It is odd you are pathologizing what I would expect to be normal behavior. It's not common behavior, but it doesn't seem abnormal for user agents to do this.

Edit: for users who only access their Google accounts via shared machines like at a public library, not having a persistent cookie on every auth attempt is going to be the expected scenario.

Apple has a very strict browser policy on iOS: you must use either Safari or an Apple approved skin over the same underlying rendering engine.

Apple policy is preventing Mozilla/Gecko from being built/distributed for the app store.

It's so notorious that there has been legislation considered to address that practice: https://www.theregister.com/2022/04/26/apple_ios_browser/

NCC Group is probably the biggest name because they go around Hoovering up companies that are usually above average in the competencies you asked about. And they can attract and retain talent.

Trail of Bits is another big name because they hire and retain talent across a large number of enterprise, emerging tech, and research verticals.

Other established firms include Atredis Partners, IOActive, Security Innovation. There are more one could list.

Sometimes these companies work with partners who ask to publicly disclose some artifact resulting from the test. Here is a collection of those reports aggregated by firm: https://github.com/juliocesarfort/public-pentesting-reports (Edit: note this is not a great way to evaluate any particular company, but it does provide an objective listing of companies that exist in the pentesting space).

Each firm will also have variability in their personnel for your project which can yield different results for two independent tests on the same target from the same firm.

Since this is specifically related to accepting payment, one would hope this infrastructure has received adequate security testing as required by PCI standards.

In practice, PCI standards compliance is a mess of people selling "point and click compliance solutions," companies being too big to be properly audited, code churn between audits, companies misleading auditors or hiding key data. Security theater is especially pervasive in PCI compliance.

The events in Tigray alone, once the internet is restored and the full extent of the damage can be assessed and broadcast to the world, alone will probably be enough to give the early 2020s a name. When the worst mass atrocity in a generation can go on because the rest of the world had so many other problems to deal with, and so few people knowing about it, it highlights how bleak this period has been.

I have a friend who lives in an apartment near a major, major artery in Seattle. It's 6 lanes wide looking out from the balcony directly down onto the street. It's what they can afford in a somewhat close commute to work by bus (they can't afford a car). I lived in an apartment a block from I-5 for 6 years. I've made enough money to buy a house in a neighborhood away from traffic pollution. It was a major part of my purchasing decision.

Zoning often puts more dense and therefore cheaper housing near busy roads. I think a lot about who can afford fresh air and who can't, and the compounding impacts of that quite often.

Do you want municipalities to be able to hire cops? This is already a tall order for a lot of people.

It's a chicken egg problem. Developers use JWTs because it's what they think they know. Companies build libraries to support what developers are using. Security engineers say JWTs are easy to screw up [1]. Newer frameworks offer ways to move off of JWTs. New programming language comes out. New frameworks built for that programming language. What is someone most likely to build first as an integration? What developers are using. JWTs become defacto for a new framework. Security engineers report the same bugs they've seen. Even more languages and frameworks come out. Rinse. Lather. Repeat. Write up the same OAuth bug for the 15th time.

[1] http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-fo...

Edit: I was actually writing this code tonight myself for a project instead of it already being baked into the platform framework because SSO is only available as an "enterprise" feature and it's $150 a month for static shared password authentication. So market forces incentivize diverging standards.

This is highly dependent on the area. My family has a background in wheat farming, I grew up in an area with a lot of family wheat farms, and if you are in an area with good soil and the weather is good you can make a lot of money on a wheat crop even in so-so international wheat price conditions.

They rotate in other crops for soil balance but YMMV in terms of wheat profits.

A model has assumptions, but the space is new enough to where there's going to be uncertainty in any model due to unknown unknowns. So it seems like defining a standard of mandatory reporting of assumptions would be hard.

Not that I can share publicly unfortunately.

There were funds that did due diligence and built out models of the Luna/Terra/Anchor ecosystem and realized it was unstable.

You can talk to the people who built their models and they have lots of fun things to say about the ordeal.

There's going to be a question about the expected probability of this across cloud service providers.

I've done security work for multiple cloud service providers and know a lot of people in the industry. I'm not really privy to give details.

I can say: dev teams face limits on what they can build securely, platform teams face limits on what secure by default and monitoring features they have time to implement, security operations teams have a lot of data points to look at, and in theory even changes in personnel in a couple of teams can have an impact on the threat posture for a given set of a company.

People are trying. But if you do the math for introduction of attack surface over time versus risk mitigation effort over time for that attack surface you can derive some estimates for likelihood of attack.

If your cloud provider isn't providing you that data as a customer, it's not simple to make a determination about likelihood of risk introduction and breach of your cloud provider.

This hasn't really been something people talk about because there was a tacit assumption that the biggest companies are mostly getting this right.

I'm not trying to say the cloud is inherently broken, I run a lot of workloads in the cloud and trust sensitive data to the cloud. But I do wish there were better ways for customers to have data points with which they could evaluate platforms besides extrapolating the history of public breach reports.

Doing user IP address change detections as part of a heuristic vector for account compromise is sometimes a best practice and sometimes a great way to generate a bunch of useless noise, but I know which is less likely to break UX by integrating such a feature.