Microsoft.com is also owned by the marketing org, not the engineering org, for various reasons that predate the existence of many employees at Microsoft now.
This is why with rare, rare exceptions nothing "real" is on Microsoft.com including even the login page, with one exception (the passkey domain).
Not quite. At least the one I found is some trickle down economics myth.
The one op is referencing is more like the dollar is used to pay off the waitstaff, who pay their rent to the landlord, who pay their over due taxes, so that the government can issue a refund to the cafe owner. The dollar ends up back in the hands of the cafe owner, who puts it back down on the table with all the debts paid off.
It definitely looks like the old tale come true - at Microsoft people would warn against using Google because then Google could figure out what we're working on, since it was pretty easy to tell where a query was coming from.
Sounded far fetched back then, and on the face of it illegal, but now it's just common sense I imagine.
It's pretty clear to me that these systems have a massive potential for intelligence agencies as people move more and more of their internal thought process to an external tool.
And, of course, intelligence agencies are good at realizing potential.
That's the success case.
In the failure case you have emboldened, pressured teams jumping in to make a "quick fix" or "that feature we needed" in a codebase for a team they've never heard of, and leaders cheering it on in the name of progress.
Not every company is going to see those boundaries and stakeholders as features, and they'll be under pressure to "mitigate those blockers to execution". That's where the cognitive debt skyrockets.
I have no idea how you read a statement about how nazis and flame baiters should be able to speak their mind and then concluded that the author only cares about some minorities.
Given that the author didn't say any of the things you claimed, and indeed said the opposite, it leads one to conclude you have a problem with the example used.
Is there some obvious reason not to measure requests per minute rather than second? Or is it an offhand joke?
Some systems I've worked on had APIs that averaged less than one per second, but I don't think we want to be measuring in millibecquerels. Some have measured on millions of requests per hour, because the hourly usage was a key quantity, as rate limits were hourly as well.
>Is there some obvious reason not to measure requests per minute rather than second?
It's much less obtuse to say something like "average req/min" or whatever, but then again you can't write a cool blog post about misusing an SI unit for radioactivity and shoving it into a nonsensical context.
In my experience, rate limits are more often per second. It's easy to talk about kilo or mega-units, so this isn't as big an issue as the awkwardness of talking about very very low volume services. Maybe those (generally) inherently don't care about rates as much?
In my perception there is a difference between 1req/s as a rate limit, and 60/min. The difference has to do with bucketing. If we agree that the rate limit is 1/s, I expect to be able to exactly that and sometimes 2 within the same second. However, if we agree on 60/min, then it should be fine to spend all 60 in the first second of a minute, or averaged out, or some other distribution.
This also helps with the question I always get when discussing rate limits “but what about bursts?”. 60/min already conveyed you are okay to receive bursts of 60 at once, in contrast to with 1/s.
In my experience it is exactly the low rate service that care about rate limits as they are the most likely to break under higher load. Services that already handle 100k req/s typically don’t sweat it with a couple extra once in a while.
An effective rate limiting system has multiple bases in my experience, depending on what the goal is. But I usually implement the configuration as a list where you can define how much requests are allow maximum per how many units of time.
E.g. to prevent fast bursts you limit it to 1 request per 1 second, but to avoid someone sending out 86400 requests a day you also cap them at 100 per 86400 seconds (24 hours) and 1000 per 3600 seconds (1 hour).
Whichever limit they hit first will stop it. That isn't hard to implement if you know how to deal with arrays and it allows long term abuse, while still along fast retries if something went wrong.
I guess there's a difference between talking about how many requests a system is capable of handling, and how many they actually get.
At least when i encountered the discussion initially (some thirty years ago) I'd say we usually talked about how many requests the system was capable of handling. Then requests per second was the obvious unit since a request usually took less than a second to process (obviously depending on the system and so on - but mostly), so using that unit often gave a fairly low, comprehensible number.
Was it ten? A hundred (very impressive)? Perhaps even a thousand (very, very impressive!)?
Multiply those numbers by 60, and there's suddenly a lot more mental gymnastics involved. By 3600 and you're well into "all big numbers look the same" land.
Right - it feels like going skin deep on types and then complaining they didn't solve for very deep problems.
Like yes, it would be nice for Map(ICar[] cars, keys).wingspan to throw a type error because cars is typed and we know keys can't include things not in ICar.
But to say that Map(Any[] things, keys) should have ahead of time type checking seems like you're not really using types except when inconvenient. Which might be taken as a no true scotsman or "holding it wrong" argument but... Maybe they are holding it wrong.
(Speaking as a former Windows/CLR PM now working in a Ruby monolith... It's hell and indeed trying to add types via sorbet has been miserable and useless)
To torture the metaphor further - it's also a personal dj, with an audience and customer of 1. Somewhat by definition there can be no outlandish requests, certainly not "play this entire piece".
If I told the DJ at my wedding to play an album front to back, and they transitioned to Aerosmith, I'd be tapping a friend to run the music the rest of the night.
It can't be quite that simple because you have a couple additional problems to solve - (effectively restating bits of the article poorly and partially)
1. You don't want these to be replayable (give your JWT to someone else to use) so they need to be bounded in some ways (eg intended website, time, proof it came from you and not someone else).
2. You don't want the government to know which website you're going to, nor allow the government and the website to collaborate to deanonymize you (or have the government force a website to turn over the list of tokens they got). So the government can't just hand you a uuid that the website could hand back to them to deanonymize.
The SD JWT and related specs solve for these, which is how mDL and other digital IDs can preserve privacy in this situation.
> You don't want these to be replayable (give your JWT to someone else to use) so they need to be bounded in some ways (eg intended website, time, proof it came from you and not someone else).
But these are the things that make it non-anonymous, because then instead of one token that says "is over 18" that you get once and keep forever, everyone constantly has to request zillions of tokens. Which opens up a timing attack, because then the issuer and site can collude to see that every time notbob69 signs into the website, Bob Smith requested a token, and over really quite a small number of logins to the site, that correlation becomes uniquely identifying.
Meanwhile we don't need to solve it this way, because the much better solution is to have the site provide a header that says "this content is only for adults" than to have the user provide the site with anything, and then let the user's device do what it will with that information, i.e. not show the content if the user is a minor.
The cryptography provides nothing to establish that this separation is actually being maintained and there is plenty of evidence (e.g. Snowden) of governments doing exactly the opposite while publicly claiming the contrary.
On top of that, it's a timing attack, so all you need is the logs from both of them. Government gets breached and the logs published, all the sites learn who you are. Government becomes corrupt/authoritarian, seizes logs from sites openly or in secret (and can use the ones from e.g. Cloudflare without the site itself even knowing about it), retroactively identifies people.
I'd review the setup here. You're missing the critical distinction that the cryptography supports - separating entirely (in time and space) the issuance of the cred to the user and the use of that cred with a website.
Unless you're getting the device logs from the users device (in which case... All of this is moot) there is no timing attack. Six months ago you got your mobile drivers license. And then today you used it to validate your age to a website anonymously. What's the timing attack there.
If the driver's license can generate new anonymous tokens itself then anyone can hook up a driver's license to a computer and set up a service to sign for everybody. If it can't, whenever you want to prove your age to a service you need to get a new token from a third party, and then there is a timing correlation because you're asking for the token right before you use the service.
The article proposes a hypothetical solution where you get some finite number of tokens at once, but then the obvious problem is, what happens when you run out? First, it brings back the timing correlation when you ask for more just before you use one, and the number of times you have to correlate in order to be unique is so small it could still be a problem. Second, there are legitimate reasons to use an arbitrarily large number of tokens (e.g. building a search index of the web, content filters that want to scan the contents of links), but "finite number of tokens" was the thing preventing someone from setting up the service to provide tokens to anyone.
Blocking said search indexes is probably a good thing.
I'm thinking perhaps a system where you feed it a credential, a small program runs and maintains a pool of tokens that has some reasonably finite lifespan. The server that issues the tokens restricts the number of uses of the credential. Timing attacks are impossible because your token requests are normally not associated with your uses of the tokens.
And when you use a token the site gives back a session key, further access just replays the session key (so long as it's HTTPS the key is encrypted, hard to do a replay attack) up to whatever time and rate limits the website permits.
> Blocking said search indexes is probably a good thing.
I feel like "we should ban all search engines" is going to be pretty unpopular.
> And when you use a token the site gives back a session key
And then you have a session key, until you don't, because you signed out of that account to sign into another one, or signed into it on a different browser or device etc.
> The server that issues the tokens restricts the number of uses of the credential.
Suppose I have a device on my home or corporate network that scans email links. It's only trying to filter malware and scams, but if a link goes to an adult content barrier then it needs tokens so it can scan the contents of the link to make sure there isn't malware behind the adult content barrier.
If I only have a finite number of tokens then the malware spammer can just send messages with more links than I have tokens until I run out, then start sending links to malware that bypass the scanner because it's out of tokens.
Search engines should not be using website search capabilities. That's putting an undue load on the systems. A board I'm involved with recently had to block search for guests because we were getting bombarded with guest searches that looked like some bot was taking a web query and tossing it around to a bunch of sites. Many of them not even in English.
Imo these are nice to haves. The physical system of ID cards already has these problems but works well enough.
People can loan their ID to someone else (ask college kids with an older sibling...)
When you use your physical ID, the government frequently can deanonymize you either through automated databases (especially when purchasing drugs) or subpoenaing for camera footage, visitor lists, etc
But one overlooked advantage of manually copying JWTs is that the user doesn't have to blindly trust they're not hiding extra information. They can be decoded by the user to see there's only what should be there.
This is why with rare, rare exceptions nothing "real" is on Microsoft.com including even the login page, with one exception (the passkey domain).
The new cloud.microsoft domain for Office will possibly help, but it's still a heck of a long list - https://learn.microsoft.com/en-us/microsoft-365/enterprise/u...
And IIRC this is just for office and windows, not azure.
reply