It seems to me that adding a 301 redirect from the old URL to the new would not unresonably stress the resources of AWS?
It seems perfectly resonable to update the library access, but breaking old URLs seems unessesary.
They could even add a second of latency to incentivise people who can update their links.
Amazon S3 Path Deprecation Plan – The Rest of the Story
81–90 of 146 posts
Re: Amazon S3 Path Deprecation Plan – The Rest of the Story
#82Earlier quoted context omitted.
Storage durability has nothing to do with this. Changing how you access data saved in storage is a reasonable change to keep up with the evolution of networking technologies. The change here was deprecating an access pattern, not destroying data or anything remotely similar.
Tell that to the author of “The Peace Corps and Latin America”, who used S3 v1 URLs dozens of times in the book, with the assumption that they’d be available forever: https://books.google.com/books?id=Q312DwAAQBAJ&pg=PA135&dq=h... And thousands of other books like that.
Why would they think/assume that URLs have infinite durability? If you buy a floppy disk with some data, it's very likely that you can still get the data that it holds if you manage to get a Floppy Disk Drive. But you cannot expect any change in the evolving conditions that allow you to get a floppy disk driver.
It's very likely that there would be something that replaces URLs in the future.
Amazon promise seems to be that they will always keep your data integrity and keep it accessible. The way I see is that they will be moving my data to newer or better storage types and will keep my data unchanged regardless of any technology change.
To keep with the analogy, Amazon's promise here is that they will always keep the data that you originally stored in your floppy disk, but they cannot promise to give it back to you in a floppy disk. Next year they might give it back to you in a CD and the year after in a cartridge.
The data has been always there, intact. They are just giving it to you in a different medium.
Re: Amazon S3 Path Deprecation Plan – The Rest of the Story
#83Thank you for listening! The original plan was insane. The new one is sane. As I pointed out here https://twitter.com/dvassallo/status/1125549694778691584 thousands of printed books had references to V1 S3 URLs. Breaking them would have been a huge loss. Thank you!
If we're talking textbooks, well then. This is a textbook case for the 301 HTTP response code.
Re: Amazon S3 Path Deprecation Plan – The Rest of the Story
#84Kind of tangential, but is Bezos a programmer type? I thought he came from banking or the big 4. I’m curious if the “malloc for the internet” bit is verbatim.
He got degrees in computer science and electrical engineering from Princeton. I have no idea how competent he is, but I think you can assume at least equal to the average college grad SDE.
In 2006 absolutely. Today, almost certainly not.
Re: Amazon S3 Path Deprecation Plan – The Rest of the Story
#85Earlier quoted context omitted.
Couldn't they just middle-man the traffic and block specific URLs?
ssl prevents that.
It explicitly does not. It means there are additional barriers to doing it - people would need to accept a bad cert (we already know the overwhelming majority will), or they would need to slip in their own CA that allows them to generate their own valid certs for MITM, but that is eminently doable for the Chinese government inside of China. They can then block all traffic for people that do not use the cert that allows them to decrypt said traffic. It functionally is the exact same thing, and would still allow "legitimate" traffic without problem.
Re: Amazon S3 Path Deprecation Plan – The Rest of the Story
#86Earlier quoted context omitted.
And even if you use encrypted DNS, the domain is still in the clear via SNI. There's an RFC for encrypting SNI, but that's not here yet.
Encrypted SNI seems to be tailor made for this situation. The public portion of the request SNI would just be s3.amazonaws.com but the ESNI extension has the full subdomain name. That (+encrypted dns) solves the privacy issue, while still enabling all the new features and improvements they have planned.
Does encrypted SNI solve the issues that AWS are trying to solve by removing path-style S3 requests? Namely, removing the complexity and single-point-of-failure of having one domain, and making it possible for subdomains to have varying allowed cipher settings? I don't know how encrypted SNI will work, but it surely it must choose the cipher before it sends the domain, so it ought to rule out one of the reasons for the change?
Re: Amazon S3 Path Deprecation Plan – The Rest of the Story
#87Earlier quoted context omitted.
Storage durability has nothing to do with this. Changing how you access data saved in storage is a reasonable change to keep up with the evolution of networking technologies. The change here was deprecating an access pattern, not destroying data or anything remotely similar.
Tell that to the author of “The Peace Corps and Latin America”, who used S3 v1 URLs dozens of times in the book, with the assumption that they’d be available forever: https://books.google.com/books?id=Q312DwAAQBAJ&pg=PA135&dq=h... And thousands of other books like that.
Testing some of the other, non-s3 links in that bibliography, they're also all dead.
I'm not supporting the old deprecation policy, in fact I thought it was insane. But if anyone publishes a URL assuming that it won't disappear they've not been paying attention. If the peace corps just migrated to Azure instead the links would also die.
Re: Amazon S3 Path Deprecation Plan – The Rest of the Story
#88This is interesting for a few reasons. IMHO, the original deprecation plan was reasonable. Not generous, but reasonable. Especially compared to what other cloud providers (eg. Google Cloud) have done. It did seem like a diversion from their normal practice of obsessively supporting old stuff for as long as possible, but it really wasn't too bad. Responding to feedback, publicly, and explaining what they were trying t…
Could you please clarify what Google Cloud did in comparison? I'm not arguing, just want to know more about Google Cloud.
[deleted]
Re: Amazon S3 Path Deprecation Plan – The Rest of the Story
#89Thank you for listening! The original plan was insane. The new one is sane. As I pointed out here https://twitter.com/dvassallo/status/1125549694778691584 thousands of printed books had references to V1 S3 URLs. Breaking them would have been a huge loss. Thank you!
There's a book out there that points to my website. I wish they had just mirrored it. My website has been dead for a few months, and some O'Reilly book has a dead link.
A book (on Libgdx) uses one of my repos as a starting point, telling the readers to clone my repo and do certain changes. I've left the repo alone, bugs and all, as I think it's cool that people uses my code. But the authors never reached out or anything, I only discovered it by chance. I could easily by accident have invalidated their whole chapter.
Re: Amazon S3 Path Deprecation Plan – The Rest of the Story
#90Earlier quoted context omitted.
They're already a CA, could they reasonably just issue a certificate for every bucket? I have no idea how many buckets there are in total. ~They probably couldn't take the Cloudflare approach of jamming 100 customer domains onto each certificate, since that would leak bucket names too easily.~
> They probably couldn't take the Cloudflare approach of jamming 100 customer domains onto each certificate, since that would leak bucket names too easily. Issuing one certificate at a time wouldn't make a difference since they're all submitted to public CT logs. Bucket names shouldn't contain sensitive information and security through obscurity is a bad idea.
With an Internet that doesn't push back packet rejection to bad hosts, rather than victims that are being flooded; being able to individually address buckets sounds like an increased risk.