211–220 of 226 posts
For example, either a special HTTP header returned when making a HEAD request for the URL, or downloading a file similar to robots.txt that defines globs which are public/private.
At least this would (mostly) avoid these links becoming publicly available on the internetz.
Earlier quoted context omitted.
This isn't the birthday problem. That would be the chance of two random links overlapping. The birthday problem scales with n^2, while trying to guess links scales with m * n, number of guesses multiplied by number of links. (Well, before you apply the logistic taper to it. So you wanted an approximation? There you go. Until you get the chance of a hit to be quite high, it's basically equal to guesses * valid links /…
The chance is less than guessing a random 128 bit username and random 128 bit password. And then guessing a completely different username and password on the very next go. You'd get far more return on investment breaking bitcoin wallets. 2^1024 is 10^308 Lets say there are 12 billion links per person, and 8 billion people. That's 100 billion billion, or 10^20 links. 10^20 / 10^308 is zero. Lets say you can test 10 tr…
Earlier quoted context omitted.
Indeed, the only valid operation with the magic URL is exchanging the URL-based token with something else (your PDF, a session token, etc.) and then expiring the URL, so by the time the scanner gets around to it the original URL is invalid.
That seems ripe for race condition class problems.
Earlier quoted context omitted.
Some people will always find something to complain about. I feel like it’s completely reasonable to give a “sorry this link was only valid for 5 minutes and is now expired, request a new code here” message. State it in the email that originally contained the link and state it again on the page when they click it afterwards. This is incredibly common practice and very unlikely to be the first time someone has seen thi…
> State it in the email that originally contained the link and state it again on the page when they click it afterwards. No one reads this stuff. I’m not saying this to be argumentative. I have a large user base and I know from experience.
It’s also why you say it on the site when the link is found to be expired. You basically remind them of the email even though they didn’t read it. Just consistent messaging is all. It might reduce the number of folks that decide to yell at you over it but will never fully eliminate them.
IMO the appropriate easy button is them using a password manager which is what I’d recommend. Also, just ignore these complaints if they don’t take your explanation and really push hard it’s a customer not worth pleasing at some point.
Earlier quoted context omitted.
What would encrypting the project name accomplish? Typically if you’re trying to secure a S3 bucket you’ll do that via bucket settings. Many years ago you had to jump through hoops to get things private, but these days there’s a big easy button to make a bucket inaccessible publicly.
The point is that in some cases the name of the project might itself be considered sensitive in some way, so preventing people testing bucket names by trying to create them helps prevent it, but doesn't completely lock you out of being able to associate the bucket back to its internal name, and allows the names to be deterministic internally - i.e. someone spinning up a test environment is still getting everything ma…
probably better to solve that problem by just giving projects easy-to-remember codenames. that's what intelligence agencies and militaries have been doing for years after all
Earlier quoted context omitted.
For better or worse, basic auth in the URL isn't really an option any more, (e.g. see https://stackoverflow.com/a/57193064 ). I think the issue was that it reveals the secret to anyone who can see the URL bar, but the alternative we got still has that problem and also has the problem that the secret is no longer separable from the resource identifier.
The browser could hide the secret after it is entered.
Earlier quoted context omitted.
> CF doesn't sell it or use it for marketing Any source for this? Do you work there? I checked their docs and they say they don't "mine user data", so I wouldn't trust anything they say, at least outside legal documents.
https://1.1.1.1/dns/ > We will never sell your data or use it to target ads. https://developers.cloudflare.com/1.1.1.1/privacy/public-dns... > Cloudflare will not sell or share Public Resolver users’ personal data with third parties or use personal data from the Public Resolver to target any user with advertisements. There's a lot of transparency on that page in particular, down to the lists of the fields in the logs…
* Parties can engage in price discrimination against you. (You don't shop around? you've got some extra spending money? double prices! Looking up risky activities? high insurance rates!)
* Parties can engage in lawfare and blackmail
* Parties can influence elections (without advertising, e.g. by gerrymandering or by targeting your participation in elections just based on knowing how you'll vote)
* Parties can target people of your race or beliefs for genocide (oh, sorry, I meant to say "lawful orders of governments")
Plus the definition of advertising itself is up to interpretation: is sending someone to your door advertising?
Earlier quoted context omitted.
There's one big functional difference. People don't normally have their username and password or API key directly in the URL. Example 1: Alice wants Bob to see CoolDocument. Alice generates a URL that has the snowflake in the URL and gives it to Bob. Eve manages to see the chat, and can now access the document. Example 2: Alice wants Bob to see CoolDocument. Alice clicks "Share with Bob" in the app, grabs the URL to…
Example 2 sounds like a pretty big pain if I can't go directly from Bob's chat account to his document account. Which is the case the vast majority of the time.
Or are you saying its a pain for you, Eve, not being able to see Bob's documents so easily?
Earlier quoted context omitted.
Example 2 sounds like a pretty big pain if I can't go directly from Bob's chat account to his document account. Which is the case the vast majority of the time.
And yet somehow you managed to log in to this site to post this comment here despite needing to log in. Crazy huh, I would have thought it would have been a pretty big pain. Or are you saying its a pain for you, Eve, not being able to see Bob's documents so easily?
And when I'm replying to someone on HN, I never have to worry "do they have an HN account already?".
Earlier quoted context omitted.
That seems ripe for race condition class problems.
If anybody but the intended recipient gets the magic URL first there's something more critical wrong with some assumption in your authentication scheme.