The alternative to storing tokens is to use an AEAD encryption scheme like AES-GCM to protect tokens from forgery or tampering. You will still have to worry about reuse, so you will probably want to restrict use of this token to the user it was generated for and to a lifetime (say, 24 hours). That is a very high level description, there are details (like nonce generation) that must be done correctly for the system to be secure.
Most of them. You can send in a cookie and a field and compare.
CSRF is about arbitrary clicks in emails and such that automagic your logged-in-session cookies to the server. If you require an extra field and compare it, you’re fine
Widely used? By whom? Devs who don't understand rsync or scp? Give me a practical scenario where a box is running FTP but not SSH.
Edit: then account for the fact that this rare breed of content uploader doesn't use an FTP client... there's absolutely no reason to have FTP client code in a browser. It's an attack surface that is utterly unnecessary.
Also, the protocol is pretty much a holdover from the earliest days, before encryption, or complicated NATs. I remember using it with just telnet a few times. It's pretty cool, but absolutely nobody should be using FTP these days. I remember saying this back in the 2005, and here we are 20 years later, someone still lamenting dropping FTP support from a browser? I think we're decades overdue.
I'm genuinely curious about that. But, this says a lot more about how different these standards are. FTP really needed a good successor, which it never really got. So, there is a strong use case, but technical deficiency to the protocol. So, FTP was overcome by a meriad of web forms and web drive sites, as a way to fill the gap. Still, resumable chunked uploads are really hard to implement from scratch, even now.
Dropping XSLT is about something different. It's not bad an in an obvious way. It's things like code complexity vs applicability. It's definitely not as clear of an argument to me, and I haven't touched XSLT in the past 20 years of web development, so I am not sure about the trade-offs.
The problem wasn't that FTP got deprecated, but that we never got a proper successor. With FTP you could browse a directory tree like it was a real file system. With HTTP you can't, it has no concept of a directory. rsync is the closest thing to a real successor, but no Web browser support that either.
I agree that we should get a successor, but if it got deprecated way back, I think we would have more likely gotten one. For just downloads, I have used apache and nginx directory and file listing functionality with ease.
I worked for a company where I had to make screenshots every minute and upload them via FTP for review to get paid. If there was multiple screenshots with the same thing on the screen, there would be questions.
Did you do any work besides taking screenshots and trying to figure out why FTP was broken this time?
Your old job's broken workflow is not a good reason for keeping a fundamentally broken protocol that relies on allowing Remote Code Execution as a privileged user around.
Aha, fair. Why the hell did they need you to do that?
I used to work in a web dev job where when they brought in "time tracking" they wanted everyone to update a spreadsheet with what they were doing every half an hour. A spreadsheet, as literally a .xls, on a shared Windows drive. Everyone spent more time waiting for access to the spreadsheet than they did doing any work.
This situation persisted for about two weeks, and the manager that came up with the genius idea about two weeks longer than that, before we eventually told the other managers we were downing tools and leaving if he didn't either get "promoted to customer" or lay off the charlie during work hours.
By many scientific and educational organizations for distribution of data. Places where the outcome matters and the way to achieve it doesn't. An FTP client in a browser is incomparibly smaller attack surface than, say, executing every random program sent to you by arbitrary third parties (javascript).
You can do some cool stuff, like serving an RSS file that is also styled/rendered in the browser. A great loss for the 2010 idea of semantic web. One corporation is unhappy because it does not cover their use cases
| GraalVM for JDK 24 was the final GraalVM release licensed and supported as part of Oracle Java SE Products. Customers requiring further updates to legacy GraalVM versions should download them via Oracle Support.
Huh, that sounded to me that there won't be any new free graalvm versions? Sounds like a death record for a project.
> Huh, that sounded to me that there won't be any new free graalvm versions?
Based on, "The GraalVM team are transitioning to focus on non-Java Graal Languages" and other statements, there will be new free GraalVM versions, but its support for Java has been paused (and will surely be removed, someday), and using it for Java will be discouraged.
If you have paid for google one, as I have, the help desk is real people and they are nice and responsive.
I appreciate the corner case catch-22 "you need to be logged on to prove your status" but please, don't perpetuate the meme there is no google help desk.
If you want google help desk, pay Google for support.
Ah, excellent. Every website I visit, at Google's behest, has added a Google support contract as an unwritten requirement for doing business with them.
I'm glad that's fully resolved and indicates that the new world order is no worse than the old, and it definitely proves that Google doesn't have ulterior motives in this initiative.
(1) Google "strongly encourages"/tricks you to create a passkey even when you don't know what that is or want one and doesn't explain the downsides like having to suddenly pay for support.
(2) The status quo is that I can create any password I dang well please for any website, but the new world order is that Google gets to snoop on my affairs and intervene on the website's behalf, and since nobody will implement anything more than the bare minimum I'm going to be beholden to Google for normal day-to-day activities where I wasn't before. Maybe I could buy an iPhone or three and be beholden to Apple and/or Google. Either way, it's not a good world.
Yes, it's perfectly reasonable absent any other facts that if Google owns my passkey then they're the people I should pay for support. What's happening instead though is:
- They're lobbying websites, apps, and developers, trying to push passkeys as more secure and the future of the web.
- All the "getting started" guides only have enough details to actually implement Google and maybe one or two other big actors as providers.
- When people have the audacity to sign in with their usernames and passwords, Google interrupts their flow to tell them about how great passkeys are and how it's critical they make one. They don't mention a thing about how irreversible the process is or how it has zero benefit to the user. The UI is slow and janky, so the accept button is likely to accidentally appear over other things the user planned to click. 100k software engineers somehow can't figure out how to debounce on redraw, so that misclick will permanently infect that person's account.
And so on. I don't want to use Google for passkeys. At all. The near future doesn't, however, look like one which is amenable to me owning my own signing credentials. I won't have a choice in the matter. My choices are to pay Google (and/or some other megacorp with a direct, by order of the courts nondisclosed, line to DOGE and friends) or GTFO.
In the early 1900s this had names like "protection money." More recently we've seen terms like "regulatory capture." Whatever the exact nomenclature, it's terrible. Google is force-feeding a bad solution into the ecosystem and using their clout to ensure that they own a big, steaming piece of the bullshit pie we're cooking.
That's the issue. If I buy a support contract from you and complain that GGM is the worst acronym in the world then that's one thing. If you beat my colleagues and I with a wrench till I fork over my hard-earned dollars and loudly proclaim your sainthood whenever I've healed enough from the attack to speak my mind then I don't think I'm the problem, and those saintly/googley claims will hopefully fall on deaf ears.
The world isn't as black and white as just looking at who has control of the passkey.
And you expect every one of Google's billion users to understand this distinction, and to be fully aware that services constantly marketed as Free actually need to be paid for?
No, thats also a mis-statement. Google gives away free, and google sells higher tiers. Google one is a higher tier. This is no different to any other provider of a service with a free tier. It's not marketed as "free" -It's marketed as the level above free.
Things above free have to be paid for, they aren't marketed as free.
A more reasonable, less argumentative response might be: "did you want them to offer helpdesk to free users" -which in fact, I did, until somebody pointed out the ARPU of a customer, and the cost of helpdesk (this is actually an anachronism, that was pointed out to me when I worked in a dial up ISP) -Whatever profit you extract from a low tier customer (of which free is the lowest tier) is very quickly eroded when you have to pay the staff who operate the helpdesk, and a customer calls in wanting helpdesk support.
Google one is the paid tier of google for ordinary people, predicated on buying more storage. If you pay google to get more than the 15GB you are on google one and you've become a customer.
There are other forms of customer, GCP tenants, Google G-Suite, Google Workspace. If you pay google for these services, you get helpdesk directed at those services.
Google one includes your base google account. You can ask them about things unrelated to just having more storage, if it's within the compass of that level you paid for.
Google one has helped me when minor amounts of shit, a few clods short of "I lost my passkey" hit the proverbial fan.
This got me to check Bitwardens account export, which does not include any private keys making the backup "incomplete" in terms of importing it into a separate platform.
I guess this is by design, the user can't self "own", but they also cant self own the data. It does look a bit like lock-in though.
I was recently looking at Pocket-ID as a SSO for my home lab, which only supports passkeys by design. In that context I can probably hack the gibson and get into my accounts if something went wrong, but it does make me uneasy about a future where most sites only accept a passkey.
Actually I may just misinterpret the JSON. It only includes `keyType=public-key` and `keyValue=...`, I was expecting there to be `keyType=public-key` and `keyType=private-key`, but perhaps keyType is impliying the authentication method and the keyValue is my private key?
They certainly are included, but whether they're included in a way that you can use them elsewhere, vs re-importing them into the same bitwarden account (something their vault has options to do if you encrypt the export), I'm not sure. I should spin up the vaultwarden clone and see if it correctly imports it.
Seems you can only import to the same account, some hand gesturing at FIDO Credential Exchange Format & Credential Exchange Protocol which aren't yet ratified.
reply