Article URL: https://github.com/stateless-me/uuidv47

Comments URL: https://news.ycombinator.com/item?id=45275973

Points: 115

# Comments: 62

Draft changes to a key research and development (R&D) tax credit program are being lauded by players in the Canadian tech ecosystem, as some argue they could address Canada’s productivity woes by further de-risking research spending. 

The Department of Finance introduced draft reforms for the Scientific Research and Experimental Development (SR&ED), Canada’s largest federal program for business R&D, last Friday. 

The proposed SR&ED reforms address longstanding pain points, experts told BetaKit, by reintroducing capital expenditures as claimable under SR&ED and making public companies eligible for the preferred tax credit rate. The changes would also increase the total amounts companies can claim, and allow them to stay within the eligibility threshold for longer.

“This will enable growth-stage companies to invest more and scale faster.”

Dani Lipkin
TMX Group

First introduced in the feds’ Fall Economic Statement last December, the updates were put into legislative limbo after Finance Minister Chrystia Freeland resigned and Parliament was prorogued in January. 

Administered by the Canada Revenue Agency, SR&ED was first created in 1948 and provides billions in tax incentives annually to encourage Canadian businesses, including tech companies, to engage in research activities. 

Canadian tech and business interest groups have been debating the merits of a SR&ED overhaul since the Trudeau government pledged to review the program in 2022. In early 2024, the government launched consultations on how to improve its approach, with a focus on improving the creation and retention of intellectual property (IP). 

Benjamin Bergen, president of tech scaleup lobby group the Council of Canadian Innovators (CCI), welcomed the drafted reforms but acknowledged that the “economic and geopolitical environment” is different than when they were introduced. 

“What we need is policies that help to protect and commercialize key intellectual property and ensure that Canadians benefit from homegrown innovation,” Bergen said in a statement.

RELATED: How to fix SR&ED

The organization has advocated for the program to incentivize domestic IP creation through a patent-box regime. Such a system would give tax breaks to profits generated from domestic IP.

Though the new draft legislation does not mention IP, the government said it would explore a patent-box regime in last year’s Fall Economic Statement, the details of which would be revealed in Budget 2025.

The draft legislation is open for public feedback until Sept. 12, according to the finance department. The House of Commons is set to resume sessions on Sept. 15, which is the earliest point at which this legislation could be tabled. If set into motion, the changes could apply retroactively to companies with fiscal years ending in 2025. 

The return of capital expenditures

The draft legislation seeks to reintroduce capital expenditures, which include spending on equipment used for research and testing, not production. For example, companies would be allowed to claim up to 40 percent of their spending on machinery such as microscopes.

Business and tax experts told BetaKit that this change, if implemented, would positively impact Canadian tech companies’ research efforts and could make a dent in national productivity rates, which is typically measured as the gross domestic product output per hour worked. Canada’s labour productivity growth has declined over the past 30 years, according to the Bank of Canada, with the decrease accelerating after 2014. 

Martha Breithaupt, a tax partner for credits and incentives at accounting firm BDO Canada, told BetaKit she sees a relationship between the removal of this provision in 2013 to Canada’s flagging productivity today, which is among the lowest of G7 countries.  

“That coincided with a massive innovation and productivity downturn when it was taken out,” Breithaupt said. 

RELATED: Is Canada’s productivity saviour a hallucination?

Incentivizing companies to invest in hard assets could create more jobs through new research pursuits and bolster investment opportunities, she said. Experts have argued that boosting IP protections, investing in artificial intelligence (AI), and increasing competition could also increase productivity. 

Bryan Watson, managing partner of CleanTech North and longtime SR&ED expert and commentator, argued to BetaKit that the reforms are “absolutely a step in the right direction” for hardtech, medtech, and engineering companies. “Anything that’s not just coding only” could benefit from the capital expenditure claims, he said.

The potential legislation comes as Canadian hardware companies deal with the uncertainty of an ongoing trade war as well as a gloomy early-stage venture capital (VC) funding landscape. 

For the year ending in March 2025, 40 percent of SR&ED tax credits were issued for software development while roughly 40 percent more went towards electrical, mechanical, and medical engineering, according to official program statistics.

Public companies could reap benefits

The drafted changes would allow publicly listed Canadian companies to also benefit from the enhanced SR&ED tax credit rate of 35 percent, which was previously only accessible to private Canadian companies. 

That barrier had contributed to challenges for companies that sought to raise capital from the public markets but stood to lose SR&ED benefits to fund R&D efforts, such as life sciences companies with long-term research needs.  At the BetaKit Town Hall: Vancouver last year, AbCellera vice-president of business development Anne Stevens said that companies who need to go public earlier lose out on tax credits under the current system.

Andrew White, CEO of TSX Venture-listed cleantech company CHAR Technologies, said that losing SR&ED eligibility was a downside to going public in 2016. CHAR converts wood waste into biocarbon to replace metallurgical coal, among other renewables. 

White told BetaKit his company plans to reinvest in R&D for more intellectual property and chase new research avenues if the changes take effect. 

Dani Lipkin, managing director of the global innovation sector at TMX Group, told BetaKit that it’s currently “harmful” for private companies to go public if they are reliant on SR&ED. The new changes could potentially level the playing field for publicly listed companies, he said.

“This will enable growth-stage companies to invest more and scale faster,” Lipkin added.

Feature image courtesy François-Philippe Champagne via LinkedIn. 

The post Proposed SR&ED changes could boost tech companies and national productivity, experts say first appeared on BetaKit.

Article URL: https://bytemash.net/posts/i-went-down-the-linear-rabbit-hole/

Comments URL: https://news.ycombinator.com/item?id=44833834

Points: 286

# Comments: 111

Article URL: https://cyata.ai/blog/cracking-the-vault-how-we-found-zero-day-flaws-in-authentication-identity-and-authorization-in-hashicorp-vault/

Comments URL: https://news.ycombinator.com/item?id=44821434

Points: 161

# Comments: 61

Google published Zanzibar: Google’s Consistent, Global Authorization System in 2019. It describes a system for authorization – enforcing who can do what – which maxes out both flexibility and scalability. Google has lots of different apps that rely on Zanzibar, and bigger scale than practically any other company, so it needed Zanzibar.

The Zanzibar paper made quite a stir. There are at least four companies that advertise products as being inspired by or based on Zanzibar. It says a lot for everyone to loudly reference this paper on homepages and marketing materials: companies aren’t advertising their own innovation as much as simply saying they’re following the gospel.

A short list of companies & OSS products I found:

• Companies
  • WorkOS FGA
  • Authzed
  • auth0 FGA
  • Ory
  • Permify
• Open source
  • Ory Keto (Go)
  • Warrant (Go) probably the basis for WorkOS FGA, since WorkOS acquired Warrant.
  • SpiceDB (Go) the basis for Authzed.
  • Permify (Go)
  • OpenFGA (Go) the basis of auth0 FGA.

I read the paper, and have a few notes, but the Google Zanzibar Paper, annotated by AuthZed is the same thing from a real domain expert (albeit one who works for one of these companies), so read that too, or instead.

Features

My brief summary is that the Zanzibar paper describes the features of the system succinctly, and those features are really appealing. They’ve figured out a few primitives from which developers can build really flexible authorization rules for almost any kind of application. They avoid making assumptions about ID formats, or any particular relations, or how groups are set up. It’s abstract and beautiful.

The gist of the system is:

• Objects: things in your data model, like documents
• Users: needs no explanation
• Namespaces: for isolating applications
• Usersets: groups of users
• Userset rewrite rules: allow usersets to inherit from each other or have other kinds of set relationships
• Tuples, which are like (object)#(relation)@(user), and are sort of the core ‘rule’ construct for saying who can access what

There’s then a neat configuration language which looks like this in an example:

name: "doc"

relation { name: "owner"}

relation {
name: "editor"
	userset_rewrite {
	union {
	child { _this f } }
	child { computed_userset { relation: "owner" } }

relation {
	name: "viewer"
	userset_rewrite {
	union {
		child {_this f} }
		child { computed_userset & relation: "editor" 3 }
		child { tuple_to_userset {
		tupleset { relation: "parent" }
		computed_userset {
		object: $TUPLE_USERSET_OBJECT # parent folder
		relation: "viewer"
		} } }
} } }

It’s pretty neat. At this point in the paper I was sold on Zanzibar: I could see this as being a much nicer way to represent authorization than burying it in a bunch of queries.

Specifications & Implementation details

And then the paper discusses specifications: how much scale it can handle, and how it manages consistency. This is where it becomes much more noticeably Googley.

So, with Google’s scale and international footprint, all of their services need to be globally distributed. So Zanzibar is a distributed system, and it is also a system that needs good consistency guarantees so that it avoid the “new enemy” problem, nobody is able to access resources that they shouldn’t, and applications that are relying on Zanzibar can get a consistent view of its data.

Pages 5-11 are about this challenge, and it is a big one with a complex, high-end solution, and a lot of details that are very specific to Google. Most noticeably, Zanzibar is built with Spanner Google’s distributed database, and Spanner has the ability to order timestamps using TrueTime, which relies on atomic clocks and GPS antennae: this is not standard equipment for a server. Even CockroachDB, which is explicitly modeled off of Spanner, can’t rely on having GPS & atomic clocks around so it has to take a very different approach. But this time accuracy idea is pretty central to Zanzibar’s idea of zookies, which are sort of like tokens that get sent around in its API and indicate what time reference the client expects so that a follow-up response doesn’t accidentally include stale data.

To achieve scalability, Zanzibar is also a multi-server architecture: there are aclservers, watchservers, a Leopard indexing system that creates compressed skip list-based representations of usersets. There’s also a clever solution to the caching & hot-spot problem, in which certain objects or tuples will get lots of requests all at once so their database shard gets overwhelmed.

Conclusions

Zanzibar is two things:

1. A flexible, relationship-based access control model
2. A system to provide that model to applications at enormous scale and with consistency guarantees

My impressions of these things match with AuthZed’s writeup so I’ll just quote & link them:

There seems to be a lot of confusion about Zanzibar. Some people think all relationship-based access control is “Zanzibar”. This section really brings to light that the ReBAC concepts have already been explored in depth, and that Zanzibar is really the scaling achievement of bringing those concepts to Google’s scale needs. link

And

Zookies are very clearly important to Google. They get a significant amount of attention in the paper and are called out as a critical component in the conclusion. Why then do so many of the Zanzibar-like solutions that are cropping up give them essentially no thought? link

I finished the paper having absorbed a lot of tricky ideas about how to solve the distributed-consistency problems, and if I were to describe Zanzibar, those would be a big part of the story. But maybe that’s not what people mean when they say Zanzibar, and it’s more a description of features?

I did find that Permify has a zookie-like Snap Token, AuthZed/SpiceDB has ZedTokens, and Warrant has Warrant-Tokens. Whereas OpenFGA doesn’t have anything like zookies and neither does Ory Keto. So it’s kind of mixed on whether these Zanzibar-inspired products have Zanzibar-inspired implementations, or focus more on exposing the same API surface.

For my own needs, zookies and distributed consistency to the degree described in the Zanzibar paper are overkill. There’s no way that we’d deploy a sharded five-server system for authorization when the main application is doing just fine with single-instance Postgres. I want the API surface that Zanzibar describes, but would trade some scalability for simplicity. Or use a third-party service for authorization. Ideally, I wish there was something like these products but smaller, or delivered as a library rather than a server.

Article URL: https://aws.amazon.com/about-aws/whats-new/2024/11/amazon-s3-functionality-conditional-writes/

Comments URL: https://news.ycombinator.com/item?id=42240678

Points: 404

# Comments: 131