hmsimha

Thanks for the response.

So to be clear, for very specific purposes I'm thinking of, I don't know that it's even better for users to use Cryptpad (without document passwords) than to use Google, etc, that's how bad it is.

This is conjecture on my part, but I'm assuming a user information request which asks for all of a user's cloud documents is considered broader than a request for a user's browser URL history scoped to one URL, and therefore the former is less likely to be granted, even though the latter can grant access to all of the cryptpad documents a user has accessed via share link.

And even if the above conjecture doesn't hold, the latter request would be much more likely to reveal sensitive information, which is why I think it's so dangerous that nation-state actors can access e.g. Chrome Users' cryptpad documents at least as easily as those same users' Google documents.

CryptPad might not be at the level of privacy or security you want (which one do you want BTW ?), but with such discourse you are sending users

Ideally both, and to be clear, I'm recommending people who need secure document collaboration to use cryptpad only with document passwords. Even though I'd really like to be able to recommend Cryptpad without that caveat, I think we can all agree Cryptpad with a password is probably going to be more secure from third-party access than Google Docs.

You mentioned " I did share all of the above with the CryptPad team, and was told they don't intend to address the above issues". If you can dig out our response it would be helpful ? At least my position as CEO is that we intend to solve the issues we can solve with the funding we have. As an example, we have always been interested in finding a solution to the "code attack". However the desktop app or code signing does not fully solve the issue as you still need to trust who builds the desktop app or signs the code, even when signed.

It was ticket 9SNPEQVkca if you're interested. I did offer some ideas on mitigating extension-based exfiltration attacks and server compromise, though your team may have already had some similar ideas in the past.

I completely understand the issues of funding. The nice thing about Cryptpad being an open source project is that community members such as myself can also make contributions towards improvements, though the roadmap still lives and dies with the company, because people generally aren't going to work on features/fixes that maintainers won't merge.

The signing issue is a fair one also. The fact is coordinating releases for extensions, desktop apps, mobile apps adds a lot of work that might be prohibitive with current resources. Mobile app stores can also be annoying gatekeepers. At least publishing apps as open source makes it so users can build their own version at any point if they'd like, and then actual version updates could be fewer and further between.

Full trust requires audit of the code at every change. Can you name me one app that you can fully trust ? Have you audited it ?

I mean trust is really something we grant in degrees. But I do often look at software I use, and that's how I came to recognize the issues with Cryptpad I ended up reporting.

Signal is a mobile app.. How many have it on their computer ?

I realize there are many mobile-only users, but among the people I know. it's very common to primarily use the Desktop app. Of course, their whole device syncing story opened up some issues, so...[1]. But I do tend to agree with them that delivery as a traditional server-hosted web app opens up additional avenues for exploit which the app distributor can't mitigate against. Perhaps these will be mitigated with updates to the CSP and resource integrity standards in the future, but right now there is more control over Desktop apps

(When a billionaire gives 100M$ to CrytpPad, we'll be happy to have our choices challenged compared to those of Signal). If one is listening our OpenCollective is here https://OpenCollective.com/cryptpad

I would love to see more funding for Cryptpad, and Signal for that matter. Both could really use bug bounties also.. can those be crowd sourced?

Our belief is that privacy and security will be won again on the Internet step by step by getting users to any non BigTech tools including CryptPad and then improve them step by step. If we have the users, we have higher chances to have the funding to improve the tools.

Your vision seems to be more extreme and would likely fail to bring anybody to such a platform as it would lack ease of use (at least with the level of funding we have).

Signal has sacrificed ease of use in favour of security by refusing to release a web app for some time.. they're doing pretty OK in terms of number of users. I think it's also fine to choose a different balance and favour ease of use more, but concessions to security based on your team's priorities should at least be acknowledged.

Until now, your criticism is not helping getting the users out of Google or Microsoft.

My criticism of Cryptpad is intended to raise awareness of the issues, so that users and prospective users can make more informed decisions about what technologies are appropriate for their concerns

And honestly if people are turned off of using cryptpad because of an issue I'm highlighting, that's also an indication of what needs to be improved to win those users back.

[1] https://www.bleepingcomputer.com/news/security/russian-phish...

I think the work you've done with cryptpad, while impressive on many levels and, I'm assuming, motivated by a desire to make secure document collaboration more accessible, is actually putting people at increased risk due to how bad this issue with the share URLs is.

I attempted to disclose the issue responsibly (in other words, not as a github issue), and urged you to make passwords mandatory for documents, or at least default with a prominent warning displayed for users foregoing the password. The response I received indicated that Cryptpad didn't consider this to be a vulnerability, but that you'd welcome changes to improve documentation.

You asked where my PR was: I gladly would submit one if I didn't expect it to be closed based on the response I had received prior, but I don't think documentation changes would cut it.

I wasn't intending to make this personal and I definitely wasn't saying that you (or your team's) motivations were unambiguously malicious or deceptive. My last paragraph was perhaps overly dramatic, but my impression is that Cryptpad positions itself as a general-purpose e2ee document collaboration suite, and one of the use cases I associate with that positioning, one of the less strict ones if I'm honest, would be something like:

empower laypeople to collaborate on documents with reasonable confidence that nation-state actors won't be able to passively surveil those documents.

which is a much softer use case to satisfy than, say, providing halfway-decent protection from active, targeted surveillance (the space I believe Signal to be in, and also the space I'd love Cryptpad to be in)

So if those aren't among the kinds of things y'all think about when designing Cryptpad, then I'd appreciate if you made your overall project goals and use cases more explicit. Of course there are other valid reasons to desire document security, they're just not ones I tend to spend as much time thinking about.

I've worked with a few orgs which have used cryptpad, and I'm sorry, but Cryptpad doesn't make it possible to share documents securely unless again, everyone in the org is able to follow security protocol to an exceptionally rare degree.

Even you seem to think sharing via identity somehow bypasses the problem, when in fact this just sends them a "notification" with a share link containing the same secret URL (not to mention, as far as I can tell, there's no way for them to add the document to their own drive, so if they want to access it later they either need to save the share link or find it in their notification panel under "notification history" which is super unintuitive).

And again, those secrets are stored in your browser history. In a group I was involved with, the workflow was to create documents and share them with others, or put the share link in a Signal group. Even if one were to try to tell everyone in the group that the link should only be opened in a browser that doesn't share its history with its vendor, clicking the link in Signal will happily just open it in which ever browser is configured as your system default anyway.

Cryptpad effectively gives you the rope and then ties it into the noose around your neck for you, while you're not looking.

Security theater is at best mildly dangerous in a more typical scenario where it's constructed around an application that isn't billed as a secure communication platform. When a tool advertised as user-friendly and privacy-enhancing is the subject of such theatrics, it's even more actively harmful because it instills a false sense of confidence. It would be like a safety helmet that explodes when the user grazes their head.

So to recap, if you care about big tech companies gaining access to your secure documents, the only way to use cryptpad in a remotely secure manner, in a group, is either by password protecting all documents with a strong password, or ensuring no one in your org ever opens a document in a browser with history syncing. And honestly, expecting the latter from 99% of groups that might use cryptpad is unreasonable, which is why I'm saying it's irresponsible of Cryptpad to even allow password-less document creation (without so much as showing users a glaring red danger notice beforehand).

The users are not primarily to blame for incorrect use of a software that's billed as privacy-preserving, when that software drops them off at the happy path and neglects to tell them, "by the way, we've booby-trapped the door to fire a footgun when opened unless you also turn the smaller knob on the far side with your other hand as you open it."

I realize the data exfiltration issues I mentioned are non-trivial to address (though by no means an immense project either), but I can't interpret the link situation as anything other than willful negligence, or worse, a honeypot; consider that users whose adversaries might include nation-state actors (for example, undocumented immigrants sharing resources with one another on how to access services while staying under the radar) are perhaps more exposed, because data brokers are more likely to deny state requests for data that can be seen as overly broad, whereas one specific type of data (browser history) on one domain becomes a pretty tightly scoped request.

Regarding the URLs containing the decryption key, of course a strong password is a big benefit here, but if you're not syncing history that could perhaps eliminate big tech from the loop (though you may also need to turn off all telemetry by your browser)

Using a browser without extensions installed would prevent against extension-based exfiltration.

The only way to prevent against a malicious server would probably be to build the frontend yourself and use it with the server (I haven't tried doing this)

I think there are some issues with cryptpad, most significantly that documents which are shared via their share link (default way of sharing) will effectively be shared with Google, Apple, Microsoft, and so on. I think this is dangerous because some users may be under the impression that Cryptpad secures their documents from the prying of big tech's eyes, but since it's guaranteed that at least some document collaborators will be using those companies' browsers, and browser history is synced, the URLs (which contain the key to decrypt the document after the fragment) to any document which is shared with more than handful of cypherpunks will certainly end up shared with the main browser vendors

Additionally, they've failed to make some architectural and delivery decisions which would protect users from various attacks like a server compromise (for example, a server seized by an adversary may send malicious client code that conducts a document exfiltration), as well as document exfiltration via a malicious browser extension. Both of these can be mitigated somewhat by delivering the frontend as a desktop app or signed browser extension, and setting reasonable CSPs in the decryption modules. This is exactly the reason Signal doesn't offer a web app.

Cryptpad does offer the ability to additionally encrypt documents with shared passwords, and this offers a fair modicum of greater protection against document interception. But this isn't the default document mode, so I doubt most documents are password-protected in practice.

I did share all of the above with the Cryptpad team, and was told they don't intend to address the above issues, so I'd recommend against putting to much faith in them for the time being.

I don't think it will work hosted with local video files.

It works locally reading the video file from the file:// url (though strangely needs http for the subtitle track)

I already commented on this, but I didn't like the "solution" of re-encoding the video with the subtitles baked in, so check out https://gist.github.com/HartS/9bb2721fa73b6798efcdbf5c463e87... if you want a way to play (and cast) local videos with subtitle support.

I threw this together as quickly as possible, so it won't be as feature-rich as VLC, but I believe it will still work for many use cases. If you need additional controls, I think video-js (the OSS video player library this uses) supports them, but you'll have to look into their API. You may also be able to get speed controls working with https://chromewebstore.google.com/detail/video-speed-control... , which is honestly one of the biggest QoL improvements I've had from a chrome extension

For people who like to watch with subtitles, VLC currently doesn't support streaming to chromecast with SRT subtitles.. there are several issues for it and I believe support is slated for the next major version of VLC, but not sure when that will be.

The typical "workaround" is to reencode the video file to include the subtitles directly, but that sounded like too much work, so I hacked together a static page using https://videojs.com/ to embed a player and load the video and subtitles in a browser window.

Here it is in gist form if anyone has a similar issue: https://gist.github.com/HartS/9bb2721fa73b6798efcdbf5c463e87...

This was hacked together as quickly as possible for my own needs, so definitely not intended to be an example of clean code. You need to run the python server separately to serve the SRT because video-js can't load it from a file URL IIRC

I think it'd be better to create an open-source platform to power one "subreddit" that can be hosted and deployed by the mods.

Then the content can be exported from reddit into each of those platforms.

The instances could be federated. Reddit users could redeem their account across the federated network by proving they control the same account on reddit (either send a message to a bot on reddit, or by generating a one-time password then posting its hash to reddit)

Indeed, the book itself is not going to be a current source on web APIs. However, the section about the history of the <img> element is still interesting.

As the tweet which was shared here today mentions, it's now the 30th anniversary of this announcement by Andreessen, but I thought the content here had more depth than the previously-shared tweet, as a meditation on the formation of standards in the wild west web. I specifically liked this assertion by the author (after visiting all the proposed alternatives):

But none of this answers the original question: why do we have an <img> element? Why not an <icon> element? Or an <include> element? Why not a hyperlink with an include attribute, or some combination of rel values? Why an <img> element? Quite simply, because Marc Andreessen shipped one, and shipping code wins

"A Long Digression Into How Standards are Made"[1] from "Dive into HTML5" talks about this: http://diveintohtml5.info/past.html#history-of-the-img-eleme...

More immediately (2023-2024):

Housing bubble in major U.S./Canada cities will 'collapse'. Not catastrophically so, but prices will begin to ease as the city centers become less relevant. Hardest hit will be owners of office real estate, as it becomes apparent white-collar industries are being gutted from both sides: remote work/offshoring results in less need for office real estate, and automation/AI reduce staffing needs overall.

Cities built around blue-collar industry, as well as those which are more desirable to people working from home (cities with good weather, hiking/climbing/skiing access) will continue to see residential real estate prices rise.

Slightly more long-term (2023-2027):

More jobs will be automated, or heavily assisted by automation.

Most of these will be jobs which are done at a computer, not manual labor.

As more jobs are automated, but while we're still in a capitalist society, lots of people will be forced to survive by suing the AI makers.

E.g. AI does most of the coding, but laid-off programmers can sue the company with a claim that some code it was trained on was recognizable in the output, in a way that violates license.

Artists who no longer have work can similarly sue the AI art programs.

Courts will be increasingly sympathetic as we enter an economic and labor crisis where more is being produced, but people have less work. Humans having published work prior to 2022 (which was then used in AI training sets) will be crucial to keeping the masses of laid off people from starving as competition for blue-collar jobs becomes more intense. Only so many people can be Uber drivers and taskrabbiters.

Eventually, once the AI has written software and schematics for robots which can also automate the blue-collar jobs, the situation will be so out of hand that lawmakers will introduce UBI which affords people at least the bare minimum living wage, and take the money from the AI makers who are now the producers.

Surprisingly to everyone, driving will be one of the last things to get automated, due to the regulatory hurdles, liability, and lack of consensus on how the trolley problem should be solved.

This isn't an article, but I used ChatGPT to make a Hacker News extension (which I'm now using), that highlights new comments when I navigate to a thread I've already visited: https://github.com/HartS/gpt-hacker-news-extension

Each commit here contains my prompt in the commit message, and the changed code was entirely provided by ChatGPT. I also appended its output (including explanations) verbatim to the gpt-output file in each commit.

So with each commit, you can see what I prompted it (the commit message), what it responded with (the change in the commit to that log file), and the code that I changed as a result of its response (all other changes in the repo).

In actual use of the extension (if you want to use it), I changed the "yellow" background-color to "rgba(128,255,128,0.3)" (a light green color), but I did that change myself because I didn't think I'd be able to get it to pick a colour that looks good for HN

I actually got it to work through debugging its own code by running it and giving it error messages (which reference the line), or describing the thing that wasn't working. I didn't try asking it to add line numbers because I figured it has a tenuous understanding of the relationship between tokens as it is, but it seemed to understand what needed to be fixed from the error messages, the output (which was generated by log commands it added upon my prompting), and a description of the problem. See https://github.com/HartS/gpt-hacker-news-extension

In the situations where it gave me partial output, I copied the last line and said "continue from "...""

It might come up with something "good enough" for the vague ones.

Case in point, I got it to write a chrome extension to highlight new comments in Hacker News: https://github.com/HartS/gpt-hacker-news-extension

It's not perfect, it doesn't keep track of what the user actually saw for example. It just stores a timestamp for each opened thread and highlights the comments that are newer than that timestamp.

I wouldn't have thought to solve it that way, but I definitely think its successor will be capable of coming up with "good-enough" solutions for a lot of problems humans currently work on.

Actually, humans are often just coming up with "good-enough" solutions in the first place.

I made a home dashboard to display on the TV, which integrated with Toggl (time tracker extension) when my partner and I were living together: https://github.com/HartS/toggl-home-dashboard

Surprisingly, a feature to just "display a light when you're working" isn't super common.

Since it was just a keyboard shortcut to start the timer (I was also contracting at the time), this ensured my partner could see I was working easily without having to ask me :)

(apologies for poor code quality, this was hacked together extremely quickly... behind on tasks and needed a productivity boost, etc.)

I think you intended this as a reply to someone else. Or at least, it sounds like you're agreeing with me.

It's not open-source or really polished for consumption. I did get permission to open-source it, but unfortunately didn't have the time to improve it to the point where it would be broadly useful.

In fact, now that https://tanstack.com/query/v4/docs/plugins/persistQueryClien... appears to be stable I'm thinking it might even be good to migrate to this (though it appears to require multiple queryclients if you want different cache parameters)

It covers generic constraints.

Indeed, but I'm not sure how that's relevant since it doesn't cover generic parameter defaults.

I think others have covered it here, but I want to point out that I actually think Typescript's docs are quite good for end-users! But, like the article here points out, lacking, for library authors.

There are lots of ways to do things that you kind of just have to learn from reading blog posts, or reading code and then asking in the discord when you see something undocumented (because have you tried googling "what does <T=...> in Typescript mean"?).

Ideally, at the very least, all syntactic features and keywords of the language should be documented, but it's more than that; Typescript is a metalanguage, and authors of many libraries have also developed patterns which are essential for describing complex types. Some of these patterns are documented (for example, discriminating union), and some are not (for example, opaque types). And some features which are documented could do with a lot more exposition and functional examples ("as const"), or notes on when to avoid (enum).

Yes, and a great way to do that is to read documentation, of which Typescript is frequently lacking. For example, I got a suggestion in the discord recently to use "generic parameter defaults" for a problem I was having, which were documented... in the release notes for Typescript 2.3... and no where else: https://www.typescriptlang.org/docs/handbook/release-notes/t...

Perhaps the React-Query source itself is a good example of when "simple" is still not "easy to read/write":

I picked out this file pretty arbitrarily: https://github.com/TanStack/query/blob/main/packages/react-q...

The author of react-query seems to be very clear at communicating how the library works and the library itself provides a great developer experience, but it's also an example of how much work can go into correct typing in library code.

This is all well and good until you have to deal with other code and other APIs in your library (results from network requests, localstorage, untyped javascript libraries, etc.)

In other words, I call bullshit on this entire blog post. Ignore it. Typescript is the correct solution. What is the alternative? Just using JS and letting things break without knowing it?

It seems like you and I read a different article. The post I read did not advocate for going back to JS; rather it advocated for better tooling and documentation (with examples, ideally) for library developers

    Conclusion
    I love typescript and think the team working on it are incredible. Typescript has completely changed the FE landscape and wouldn't want to dismiss its contributions.
    But as a library developer, we need:
    - better documentation,
    - better tooling, and
    - to spend less time making tsc happy.
    I shouldn't have to read the typescript compiler source code in order to figure out why it's resolving a piece of my code to a specific type.

It's not an especially large library, but I felt all of the pain points the author describes. It's great that you didn't with your library (and I'm sure there are large classes of libraries whose authors wouldn't feel these pain points), but it's a very real issue if your dealing heavily with generics, serialization/deserialization, and/or complex type interactions

Sure, I had the word "trivial" in quotes for that reason. I meant that if you're able to generate a collision, the rest of this doesn't follow (from the article)

Even if creating a collision were feasible for an attacker, Bjarmason pointed out, that is only the first step in the development of a successful attack. Finding a collision of any type is hard; finding one that is still working code, that has the functionality the attacker is after, and that looks reasonable to both humans and compilers is quite a bit harder — if it is possible at all.

Regarding the difficulty of generating a collision with working code, wouldn't it be as "trivial" as generating a SHA-1 collision in the first place?

Just have the malicious code in a file and append a multiline comment block, then have your collision generator insert random junk into that comment block

the only things on my site that require JS are the "Make the image bigger when you click on it" feature

You could actually do this without JS, just wrap the image in a label for an invisible input, and apply transform with a transition based on :focus or :focus-within.

It would be ugly, sure, but so much of modern front-end development is already ugly.

I'd go with `Math.max(...arr)` personally. Math.max is a variadic function, no need to add a reduce into the mix.

What if the package bundles were stored on IPFS? They would be hash-addressable, and also verifiable (no danger of package hosts inserting malicious code), and npm would just be responsible for building, verifying that a given bundle based on the package source at a given commit/version builds to a package with a given hash. Then its main role to cli users would be to provide the index.

Once uploaded, content could not be removed, so maintainers couldn't pull packages, though npm could de-index certain builds if they were found to contain malicious code.

Minor clarification, the latter example will only await until both have resolved *or* one rejects. To await the resolution of all promises, you should use the truly gamechanging `Promise.allSettled` , though you will have to transpile it if it's not supported by your target environments.