But sadly, still can't find my insurance company's download links.
I can't wait to lose a weekend doing something with this data, it's a dream dataset and a perfect example of a very narrow type of project I love doing.
Is there a canonical list of the major insurance companies?
> It looks like a json file with links to more gziped json files
Yup! Should be pretty easy to whip up a parser, it's just JSON and HTTP, you could do it in shell if you cared to. The challenge is what are you parsing it _to_. That is to say, what's your data model. I'd choose that first, then worry about parsing.
Out of curiosity, what were some of the differences in work culture you experienced? I've never worked outside the U.S., so would be interested to hear a different perspective.
Not OP - but I've worked with American and non-American tech companies. For similar-sized companies, my experience was that American companies are more obsessed with productivity and metrics, with more frequent meetings involving people who don't need to be present (including at least one one who is a level or 2 too high, but justify their presence by having to say something which occasionally derails the meeting).
On a purely subjective note: American work culture has lower trust and attempts to extract much more "productivity" from people doing the work compared to European companies, which is not always proportional to the salary differences. My sample size is fairly small (<5)
However, in this case, I can analyze the source now because it is available to me. What should I do when the source isn't available ? How do I proceed when all I have is the 'minified output'?
You can try to prettify/beautify (something like http://jsbeautifier.org/), but the output can still be hard to read. If you're looking to learn how to build a particular feature that's closed-source, I'd recommend trying to build something similar yourself using tutorials or an open-source analog.
Firstly, thanks for inspecting the source and offering a suggestion for improvement. The latter point should be a relatively easy fix.
As for your first point, there’s little we can do to prevent TLS or AWS tampering. But we can make it easier to choose e2e encryption in the first place. So we focused on reducing barriers to entry (no signup required, simple URL-based rooms) as well as providing these benefits over alternatives:
- Open source code
- Ephermeral message history (not persisted in a DB)
- Opt-out anonymity
We think these features make Darkwire a good solution for many users seeking secure, private online communication. Having said that, no solution is perfect and we hope to see contributions from the open source community to make it even better.
Given that the server distributes the keys, and there is no way for the user to compare/verify known-good keys of other users, it's possible for the server to MITM everything, actively, meaning modification instead of just eavesdropping.
>- Open source code
Open source doesn't save you either, because a user cannot inspect what is actually running on the server.
And even the client side, while the code is technically there (downloaded to the browser in minified form), it's not feasible for a user no matter what level of skills to verify the distributed code is actually what's open sourced in your github repository and that the code stays like that whenever you refresh or reopen the site.
So basically, you need to trust the server (operator) and your webcrypto scheme does not provide any additional security whatsoever given that the server (operator) can MITM it trivially. The only thing preventing third parties other than the server (operator) in a MITM position to do harm is the TLS, but not your webcrypto scheme.
>- Ephermeral message history (not persisted in a DB)
Even with best intensions, what happens when you receive some National Security Letter, court order or similar, which forces you into silently MITM the key exchanges, thereby enabling you to MITM the messages and then log every message and pass that to some state actor?
To say something positive, I like the minimal UI and the way you handle file uploads. Even tho your service cannot fulfill the strong user-to-user security it somewhat claims, it's still a nice chat tool.
However, since your service is easy to use (copy-paste just one URL and type away), I'd guess soon enough you'll run into the same troubles as similar services where some bad users (e.g. from the chans) will use your service to e.g. distribute child pornography, revenge porn and other very illegal content.
Thanks for the feedback. If we assume the server is compromised then it's true that a MITM attack is trivial. However it seems to me this would be the case for any web-based e2e chat application, all of which must use a server by definition.
Regardless, it's easy enough to spin up your own instance of Darkwire (`docker compose`) and operate the server yourself if so inclined.
Hey, it is painfully obvious that you have a high school level understanding of the crypto at play here. That's really OK, crypto is hard.
You'll want to look into how real cryptographically secure open source comms apps do end to end encryption. Properly implemented, the server can be fully hostile and never recover messages.
Then you'll need to go remove every claim of e2e or cryptographic security from darkchat. Thank you for your time.
My point was that if the server providing client code is compromised, it can serve malicious code to said client. This isn’t a cryptographic claim, just a point about how all web-based applications work.
Also while I appreciate the feedback, this comment struck me as more hostile than helpful, so I’d suggest having a look at HN comment guidelines for future reference.
Thanks! We actually need the server intermediary to handle storing and locking rooms, and adding and removing members. Also IIRC WebRTC data channel doesn't have great cross browser support.
Darkwire is more for ephemeral chat rooms, where the name doesn't change as long as the room is occupied. We also don't require sign up, so you can use it instantly and anonymously.
Yes I think so too. Long-term I'd like to have a extensions (Chrome, desktop, etc) that give access to running blocks from anywhere. I think this makes code much more usable to non-developers.
Empire Blue (Anthem): https://www.empireblue.com/machine-readable-file/search/
United Healthcare: https://transparency-in-coverage.uhc.com/
Aetna (Seems like the right page, but I don't see any download links — possibly because they haven't been posted yet): https://health1.aetna.com/app/public/#/one/insurerCode=AETNA...
Search keywords: https://www.google.com/search?q=machine+readable+files+trans...