-
The main (only?) argument for putting static sites behind HTTPS is to prevent visitors from getting MITM’d. I’m a little uncomfortable about the unspoken implication that content publishers should be responsible for the security of their visitors but that’s a separate point.
What really annoys me about the push for HTTP on static sites and other benign content is two things:
-
HTTPS is touted as the best thing since sliced bread but we already know the existing TLS certificate trust chain in mainstream browsers is pretty weak. Certificate authorities have suffered serious security lapses and/or incompetence (Symantec, Wosign), or delegate too freely to likewise entities. Pretty much all developed countries in the world either have government-run CAs or can swoop in and “borrow” the private keys of commercial CAs to sign fraudulent certs or (more likely) decrypt traffic as it goes by. There are things happening to make incremental improvements to these problems but right now the mainstream opinion is just to keep putting band-aids on the system. Don’t get me wrong, HTTPS is better than nothing but the whole trust chain is very half-assed and nobody seems interested in fixing it.
-
HTTPS is arguably not the right tool for public, non-secret content. As a static content publisher (yes, I use that term loosely), I don’t want to encrypt my content, I only want to sign it to show that it hasn’t been tampered with. But with HTTPS it’s all-or-nothing. If we had secure DNS (however implemented), this would be fairly straightforward: public key in a DNS record and a signature for the page in the HTTP headers. The browser can show the page as signed, clients who don’t have the technology to verify the signature or who don’t care are free to be MITMed at their leisure.
-
How can visitors secure themselves against MITM attackers without the cooperation of content publishers? Maybe I should be concerned that requiring free content publishers to do more work makes a less useful web.
Public non secret content is tricky. A blog about food isn’t a secret, but access patterns might be. If I only visit the pages about sugary foods, my ISP might sell this data to an advertiser or a health insurance company. This is prevented by TLS encryption. What is the downside of encrypting as well as signing?
-
If I only visit the pages about sugary foods, my ISP might sell this data to an advertiser or a health insurance company. his is prevented by TLS encryption.
Except it isn’t prevented by TLS. The sugary foods site, using Google Analytics (or even Google hosted jquery or webfonts) will still sell the fact that you were there. If it doesn’t use Google then any externally hosted resource could be used to track you. The blog itself would know which pages you visited and could resell the data. Your ISP can integrate technologies that use techniques that TLS does not defend against. Here’s a video of Vincent Berg’s work on deanonymzing Google Maps over TLS from 2012.
At the very least your ISP will have the metadata about the fact you visited a site with sugary pages, how much data was transferred and when.
The problem here is that the HTTPS infrastructure does not grant sufficiently reliable confidentiality and provides some (occasionally broken) integrity confirmation compared to other more difficult to manage methods.
-
-
We’re getting closer and closer to a world where all certificates are in Certificate Transparency logs, which addresses the security concerns around your first point (whether that’s desirable from a data hoarding / secrecy perspective is a totally different aspect).
Regarding your second point, I honestly think that it shouldn’t be you deciding whether you want to encrypt your content. I understand you don’t think it’s necessary, but the goal for all of this is to change the web to provide encryption by default in the long run. Because it makes sense for users.
-
-
Personally, I find it unfortunate that Guido picked “twisted like” over “gevent like” for asyncio (née tulip).
Having used twisted for a while, when I first started using gevent, I found it amazingly more usable (and better performing to boot).I still do lots of python2 for work, but given a choice of language, there are luckily many other decent languages to use these days. I can’t think of a case where I would choose python3 (even over python2) for a new project.
-
-
It would of course depend on performance expectations, and other requirements.
That said, I would probably see how the requirements matched up with Go. If static typing ended up not being a hard requirement, and if Go wasn’t a good fit, I would probably look at Elixir….maybe python2 if the requirements fit better.
Swift and Rust are both interesting to me, but I haven’t really used them “in anger” for anything yet. I also hear some people have used D for web projects to good effect.
-
Try Opa. It’s designed for one, safe language doing the whole stack with DB functions built-in. If that doesn’t work, tell them why so they can improve it.
-
At first glance, this seems like the wrong direction web development should be going in. By conflating the server and client side, I think you add complexity to the problem.
Also, I think you should use javascript on the front end (since there are no alternatives), but on the back end I would recommend finding a language better suited for the job.
-
Why does this add complexity? Lots of webdev is incidental complexity brought on by mashing lots of different technologies together and letting the dev sort it all out.
-
“By conflating the server and client side, I think you add complexity to the problem.”
Why does it matter where it runs if you can ignore that and still build apps that work? Sounds like incidental complexity as mattgreenrocks points out. The first to try to eliminate this problem was MIT’s Curl which is still sold. It aimed to be more like markup languages.
https://groups.csail.mit.edu/cag/curl/wwwpaper.html
That worked out fine for lots of their customers but needed a plugin. The Opa project uses a ML-like language to get the readability and safety of one. They make it agnostic to client or server to reduce mental burden on developers. They integrate database since people need that anyway. Target JavaScript on client side since it’s supported everywhere without a plugin. Originally targeted J2EE IIRC on the server-side but switched to Javascript to leverage Node.js ecosystem. I’m against Node.js and that Opa move but oh well. Otherwise, quite a rational product where they let people get more done, more safely, easier to maintain, and with compatibly with existing systems. Now I have to get feedback on what people think of their implementation of that concept to see what is working or not.
On INFOSEC side, Cornell’s people implemented Java extensions that let one specify information-flow policies to protect confidentiality and integrity of applications. Their JIF, SIF, and Swift tools let one do this for web applications where Swift automatically partitions the app between client JS and server Java in a way that maintains security policy + optimizes performance. They built Civitas system for secure voting using this toolkit. Fabric extends it for open, secure, distributed computing. Lot harder to pull off information-flow secure apps working in several, incompatible languages that have to integrate just right. They put the correctness (Opa) or security (SWIFT) in the tooling for just one instead.
-
-
-
Not OP, but C# with asp.net’s mvc framework is quite pleasant, if slightly bloated. Linux support for asp.net is pretty solid now as well.
-
-
-
Two things I need to get around to doing. No wait, three.
Plan time: Because if I don’t, I’ll get around to doing exactly zero of the other two things.
Jira FS: I wanted to try to rewrite my Jira CLI in Elixir, as a way to learn the language and tools. So far so good. then I got the awesome idea that I could always write a tiny FUSE virtual filesystem and hook that up to the thing. Mostly for fun. And for using standard tools to work with tickets, for example. I understand it’d be terrible to a lot of extents, but the experiment entertains me. Also, I can’t seem to compile erlang-efuse which seems to be the most recent binding available, it looked like it had a nice API, can’t get it to compile so I can import it. I don’t know if I’m ready to write out a FUSE lib just to work with Jira, yet. :( If anyone has ideas, I’d welcome pointers.
Blog : I need to write more blog posts for my blog about disconnecting the internet at home.
I also have to work a full week, as regular, but hey. That’s regular.
-
Jira FS
Reminds me of this http://tools.suckless.org/ii/
-
-
Still working on my orthogonal Vim clone. Made a lot of progress over the last week and may be able to start using it as a crappy editor to edit itself soon (gotta eat my own dog food at some point).
I got distracted yesterday by trying to write a script that randomly plays music from my Spotify or SoundCloud playlists. Mopidy supposedly allows you to do this, but the mopidy-soundcloud plugin is broken right now. I’ll finish the script (using pyspotify and soundcloud-python) sometime today and will throw the hacky mess on GitHub for anyone who doesn’t want to have to write it themself :)
-
-
-
orthogonal Vim clone
Have you seen this? https://github.com/martanne/vis
-
-
-
I wonder what the TCL is for.
-
-
Oh, it’s because Python comes with bindings to
libtkfor GUI.
-
-
-
burrows
2 years ago
|
link
| on:
Process Exchange in UNIX 6th Edition: "You are not expected to understand this"
More of the same, http://orkinos.cmpe.boun.edu.tr/~kosar/odd.html
-
Why not give a link to the original? https://www.bell-labs.com/usr/dmr/www/odd.html
-
-
This is a cool idea. My problem is that sometimes I need to type a password into my phone, and a long string of random characters sucks to type on a phone keyboard. So I wrote a couple scripts to generate more typeable passwords, that I then store using pass. It was a fun exercise.
-
Another similar option, https://github.com/nmeum/tpm.
The phone thing is tricky; maybe it’s a good use for a smart watch. I enter my master password+tag on the phone, the tag specific password pops up on the watch, now I navigate to the service on my phone and enter the password.
-
-
As much as I want to like stateless password managers, I don’t think they will ever work in the wild. Inevitably you will come across a site with stupid password restrictions that will reject your generated password.
-
I don’t want to let the perfect get in the way of the good. We can get 95% of the way there if the generated passwords have one lowercase, one uppercase, one symbol and are 16 characters or less. A crowdsourced spreadsheet of the password ‘rules’ for popular sites would let us do an even better job.
One change I’ve been contemplating is to always append a ‘bang’ at the end of the password to accommodate the ‘one symbol’ rule.
-
-
What a curious way to announce this much awaited new Elm release. Does anyone here know more about the ideas behind that? I’d have expected some kind of public beta and a proper release announcement…
Yeah, it’s a bit…different, but it looks like picking and highlighting one feature is what was done for previous releases as well: http://elm-lang.org/blog
Especially given the “is Elm dead?” questions that have been popping up in the past few months. I guess it’s better to be head-down working on the next release, but I think just a little more communication or visibility into the project might have helped alleviate some of the concerns.
This topic was addressed by Evan (creator of Elm) in his recent talk at Elm Europe 2018 titled: “What is success?”
So I watched the video, and this is addressed around the 41 minute mark: “There’s pressure on me to be always be saying everything that’s going on with Elm development, and the trouble is that it’s not always very interesting… it’s like… ‘still working’”.
I think “still working” would have been better, though. I don’t think anyone expected weekly updates. Every 2 months updating the Github readme with “still working” would have been fine. And the fear that saying you’re working on X and then it doesn’t pan out, so better to not say anything at all, seems like the worse option.
I also think the talk is a little dismissive of Javascript, and the community. Sure, the number of packages is by no means the be-all of a good language ecosystem, but it says something about the platform and its viability. If nothing else, it means there are alternatives within the ecosystem. People have limited time, and very limited time to invest in learning brand new things, so they naturally look for some way to compare the opportunities they have. Is looking at numbers the ideal behaviour? Maybe not, but if I want to sell Elm to my boss and she asks me when the last release was and I say “18 months ago” and she asks if I know when the next one will be and I say “no”… that’s how languages don’t get adopted and ecosystems don’t grow.
As a complete outsider, but also as someone who wants Elm to succeed, I think community management is something they need to take really seriously. It seems like Evan really doesn’t want to do it, so fine, have someone else do it. You can dislike that there are persistent questions about the future of your project, but they’re best addressed at the time, not left unanswered.
Personally, I’m not really convinced by those arguments.
I especially don’t understand why 18 months since last release, and no known date of new release, are arguments against adoption of the language. Take C or C++ — they rarely have new releases. Is this an argument against adoption? I don’t think so; actually, more like for adoption in my opinion! Slow pace of releases can mean that the languages are mature and stable. I’d be really surprised and annoyed by a boss who would think otherwise.
It now occurred to me, that maybe Lua is a good example of a language having a similar development mode as Elm. It’s also evolved behind super tightly closed doors. And new versions are usually dumped on the community out of the blue; though usually with public betas & RCs. But those are published only for fleshing out bugs; language design input is mostly not taken into account. AFAIK, the community is generally OK with this. And the language is totally used and relied upon in numerous niches in the industry (including a large one in game development)!
“Elm” includes the language specification and the compiler.
The C language specification rarely has new releases, but the C compiler, gcc, has 4 releases per year. There would be major concern from the community and your boss if gcc activity was perceived as drying up.
Ah; good one, never thought of it this way; big thanks for pointing this out to me!
C and C++ have been mature and in very wide use for decades, where Elm is a very young language - just a few years old. Same with Lua, it’s been in widespread use for, what, 10 years or more? I think that’s the difference. Elm is still much more of an unknown quantity.
Sure - when the language is mature and stable. I don’t think anyone would consider Elm to be that way: this new release, if I understand correctly, breaks every package out there until they’re upgraded by their maintainer.
Personally, after some initial usage, I currently actually have a surprising impression of Elm being in fact mature. It kinda feels to me as an island of sanity and stability in the ocean of JS ecosystem… (Again, strictly personal opinion, please forgive me should you find this offensive.) I didn’t realize this sentiment so strongly until writing these words here, so I’m also sincerely curious if this could be a sign of me not knowing Elm well enough to stumble upon some warts? Hmh, and for a somewhat more colourful angle, you know what they say: old doesn’t necessarily mean mature, and converse ;P
And — by the way — notably, new releases of Lua actually do also infamously tend to break more or less every package out there :P Newbies tend to be aggravated by this, veterans AFAIU tend to accept it as a cost that enables major improvements to the language.
That said, I think I’m starting to grasp what you’re trying to tell me. Especially the phrase about “unknown quantity”. Still, I think it’s rare for a language to become “corporate grade non-risky”. But then, as much as, say C++ is a “known quantity”, to me it’s especially “known” for being… finicky…
Yeah the last release was in Nov 2016.
The devs are active on https://discourse.elm-lang.org/, which might help people see the project activity.
since they recently disallowed using javascript in elm packages, it only makes sense that they’d lead with what that had won them, i.e. function level dead code elimination.