Sharing resources from web applications securely is hard work. It doesn’t surprise me at all that they end up having to lock down some forms of access from time to time. Most likely they found a vulnerability and this was a side effect of mitigating it.
Huh, so when it comes to getting a URL to sheets as CSV, going through the GUI (i.e. going into the Publish to Web dialog) is no better than just using the endpoint of `https://docs.google.com/spreadsheets/d/KEY/export?format=csv...`, which also requires authentication if the underlying sheet is set to private.
Removing an external dependency on Google is a sound engineering choice for many use cases (and maybe not for others). One reason it might a sound engineering choice is what happened here.
Sure moving off Google is work. So is implementing the work around. Breaking changes always either require work or make user code obsolete. Breaking changes generate work for users. They externalize the cost of making changes non-breaking to end users.
Fortunately it was a transition we'd already talked about making; we were approaching that threshold where the agility/reliability tradeoff was about to flip. But still, it sucked having a few hours of unexpected downtime while we scrambled to make the change.
Despite being sarcastically phrased, the GP is very warranted. Google is so renowned for making breaking changes, there's a site to track not just their dead code, but their dead products:
I think experienced engineers have learned not to depend on Google a long time ago, and the GP is stressing that lesson: this is not "news" in that it happens _very_ frequently.
Also, for the company that invented the protobuf IDL, you'd expect them to maybe use swagger to catch these things in an automated fashion, if they have admitted it's a bug by accepting a support ticket for it.
"Our company mission is to organize the world's information and make it universally accessible and useful, as long as you are logged in and we can show you personalized ads".
23 comments
[ 4.9 ms ] story [ 61.9 ms ] threadSo it sounds like they accept this is an issue.
> I have heard that this appears to not be a bug, rather an intentional change that they didn't announce in advance.
Not sure where "I have heard" comes from, but
Private Sheet public CSV export requires authentication when set not to
What steps will reproduce the problem?
1. create a private(!) Google Sheet
2. set public CSV export publication
3. access the endpoint without credentials
What is the expected output? What do you see instead? If you see error messages, please provide them.
You should receive a CSV file, you get HTML5 login form.
Please provide any additional information below.
Setting the Sheet to Public with a link fixes the problem, there's an obvious bug with the permissions taken from the Sheet, not the Export.
Seems like it would have been a drastically simpler change.
Sure moving off Google is work. So is implementing the work around. Breaking changes always either require work or make user code obsolete. Breaking changes generate work for users. They externalize the cost of making changes non-breaking to end users.
https://killedbygoogle.com/
I think experienced engineers have learned not to depend on Google a long time ago, and the GP is stressing that lesson: this is not "news" in that it happens _very_ frequently.
Also, for the company that invented the protobuf IDL, you'd expect them to maybe use swagger to catch these things in an automated fashion, if they have admitted it's a bug by accepting a support ticket for it.
"Our company mission is to organize the world's information and make it universally accessible and useful, as long as you are logged in and we can show you personalized ads".
Linked page title is "Private Sheet public CSV export requires authentication"
with a reply from Google: "This has been forwarded internally, any updates will be posted here."
The bug to me seems that it was ever possible to access data in a private sheet without authentication.