1. 4

    So while I agree with what alexandria said, this is actually frickin’ fantastic.

    I installed it and gave it a go for its money. Browsed reddit a bit, looked at the help, navigated with annotations…so frickin’ sweet! This is so, so impressive. I’m actually wondering how you have made something so good and professional and are giving it for free. You are a saint.

    And top of all this, the plugin API…is frickin’ sweet itself. Tailored voice controlled sites is the way to go, and here you have created a super easy way to do that.

    I guess you could create a company that creates these tailored experiences.

    I’m definitely keeping this extension installed, and I don’t say that too often :) Hey, how about you create a plugin for lobste.rs? :D

    23:51 EST: I see the source is not open. How can I be sure your extension is not recording what I’m saying, browsing, etc? (Obviously there are non-invasive ways to check, but still)

    I was thinking as an improvement, have an option to keep annotations on always. It is annoying to say “annotate” all the time. As well as “go back” when “back” or “forward” suffice.

    What are you using for speech recognition underneath?

    1. 1

      Thanks for your feedback!

      Hey, how about you create a plugin for lobste.rs? :D

      I probabably will, if no one else does it before me: https://github.com/lipsurf/plugins

      23:51 EST: I see the source is not open.

      The core of it is not open source, but as it is just a chrome extension and written using JS, the source is always visible and verifiable technically

      I was thinking as an improvement, have an option to keep annotations on always. It is annoying to say “annotate” all the time. As well as “go back” when “back” or “forward” suffice.

      The annotations should be staying on? I definitely need to improve those (spent too much time doing Japanese support recently) Also just saying “back” or “forward” should also work, check out the options where you can see all the command words for each plugin.

    1. 5

      There’s more to life than HTTP

      Agreed.

      I’ve found MQTT to be a good alternative to HTTP for real-time (or extremely stateful) applications, especially those that exist outside of a web browser. Whenever there is overlap with the web, it is fairly easy to tunnel MQTT over WebSockets.

      1. 0

        How does MQTT fair against HTTP with billions of users? HTTP has the advantage here for not needing to be stateful.

        As the article says too: sometimes HTTP makes sense. IMO the title should have something like “You should use a real pub/sub broker, not HTTP - VerneMQ is one”.

        1. 11

          You don’t have billions of users. Or if you do, you’re unusual, and shouldn’t be making technology decisions based on blog posts.

          1. 2

            I can’t say much for VerneMQ, but most of the solutions out there were built for very large scale.

            The broker I use (RabbitMQ) supports MQTT and supposedly handles one million requests per second although I’ve never dealt with that much traffic first hand. I’ve heard similar stories for the MQTT product that IBM sells.

        1. 2

          Anyone have a source for the cause of death? Or any news article?

          1. 7

            First time I’ve actually felt a sinking feeling in my chest for an Internet person. Terry, you are with God now.

            1. 11

              You should add Paperkast to the list of sister sites.

              1. 2

                Done. Thank you very much for the suggestion.

                1. 1

                  Maybe there should be some sort of standardized directory?…

                  1. 2

                    How is https://github.com/lobsters/lobsters/wiki not a standardized directory?

                    1. 4

                      I suppose it is, but it was not obvious to discover.

                      1. 1

                        I also wish I’d discovered it sooner. However, other than nesting it under the “Wiki” link at the bottom page, I don’t see a solution that wouldn’t start cluttering up the site with information most people won’t need.

                        1. 3

                          It’s linked from the about page.

                    2. 1

                      Can you expand it a little bit?

                  1. 8

                    I frickin’ love it. Already signed up.

                    Even if there is no discussion, having one place for all papers (tagged) is a valuable resource.

                    1. 4

                      Exactly. But in the long term I would love to see detailed discussion about the bits and pieces of a paper.

                    1. 13

                      I don’t know if I realistically can, or want to use Haiku, but it’s great to see some non-UNIX designs still being alive.

                      1. 7

                        It’s surprisingly usable. It’s lacking features that I have to have for work (multi-monitor support, a browser capable of using Google Hangouts, the ability to run VMs at near-native speed, and reliable disk encryption) but if it had those four things it could be my daily driver.

                        (Google is switching to “Meet” now; I should check WebPositive to see how it handles it, and I know that once upon a time there was an encrypted block device driver in the tree…in my Copious Free Time I should try to help on that maybe…)

                        1. 4

                          For alternative OSs, the best thing to do is implement VNC. Through VNC you can access OSs that specialize in accessing the web, such as Windows, Linux, and … Chrom/iumOS. ChromiumOS is probably the best since it’s sole purpose is to interact with the omnipresent OS that is the web.

                          Eventually I will figure out some easy setup to do this.

                          1. 3

                            The encrypted block device support still exists as a third-party package (though it’s maintained by one of the core kernel developers); it just does not support having the boot device be block-encrypted.

                          2. 4

                            Well … Haiku isn’t really a non-UNIX design. We have some pretty anti-UNIX tendencies to be sure, but we also use POSIX filemodes, POSIX process model, pretty good POSIX API compliance, BSD sockets, … etc.

                          1. 4

                            Furby emulator when?

                            1. 2

                              Why emulator? It’s better to make an extensible, open hardware interactive toy platform.

                              I wonder, did they really have to use raw assembly for that. That kind of codebase must be a real headache to maintain.

                              1. 5

                                In my opinion an emulator would be a cool thing to tinker with and I am sure I’m not alone in thinking that.

                                The processor in the Furby is apparently a Sunplus SPC81A, its datasheet describes it as a 6502 instruction set although it only has 69 instructions as opposed to the 151 in the 6502 so it’s likely to be missing some registers. It comes with 80K-byte ROM shared by audio samples as well as programme and 128-bytes of working RAM. While it can run at up to 6Mhz at (3.6V-5.5V) circuit diagrams for the Furby show a 3.58MHz crystal in use that runs at 3V.

                                So why raw assembly rather than some higher language compiled into ASM? The answer should become clear from the above. With just 80K-byte of storage, a lot of which is likely consumed by audio samples - the only way to make a programme fit in the space available let alone be performant on such limited hardware is to program it in ASM.

                                An open hardware, interactive toy platform would be cool, I have seen some projects were people have hacked a Raspberry Pi Zero or other such small micro controller into the guts of the Furby to give new life to an old toy.

                                :)

                                1. 6

                                  The original 6502 only had 50ish instructions documented, iirc, with some undocumented. The later iterations added some instructions (the 65C02 had a bunch more).

                                  Also, the 6502 only had three registers that were part of instructions: the accumulator, X, and Y. It also had a stack pointer and program counter which were indirectly accessible. Again, some of the later iterations added more (I think the NES-specific 6502 added a dozen or more registers).

                                  In the source code, you see statements like:

                                  Bank       EQU      07H
                                  

                                  … associated with comments like “BANK SELECTION REGISTER”. Those aren’t actual registers. Most instructions used two-byte memory addresses, a full 64k. The addresses from 0000 to 00FF, however, were the “zero page”. The 6502 had a special addressing mode which allowed one-byte addresses into the zero page, which many programs used as registers.

                                  The same instructions and addresses were used to access both RAM and ROM, so if that total was larger than 64k, then you needed to use hardware switch instructions to swap memory banks. Again, though, later iterations expanded that (though only the wild later iterations, like the 16- and 32-bit versions of the processor).

                                  1. 2

                                    Thanks for sharing, I am fascinated by old 8-bit processors and processor design in general. I was sure the 6502 has 151 but maybe I misread it somewhere and am talking out my ass. The Sunplus SPC81A only has the X register.

                                    Looking at the data sheet I can see that it says:

                                    To access ROM, users should program the BANK SELECT Register, choose bank, and access address to fetch data.

                                    Given its described as having a 6502 instruction set and not actually being a 6502 i’m guessing that’s in addition to what ever opcodes they chose to implement.

                                  2. 2

                                    “Popular home video game consoles and computers, such as the Atari 2600, Atari 8-bit family, Apple II, Nintendo Entertainment System, Commodore 64, Atari Lynx, and others, used the 6502 or variations of the basic design. “

                                    People might want to play games or try to code within a similar setup. There’s already a large number of people doing stuff like that.

                              1. 6

                                In Canada most home routers (well, from bell at least, which is one of two dominant ISPs) come with a long randomly generated wifi password stamped on them.

                                Specifically 8 characters long. And for no apparent reason it is limited to hex ([0-9A-F]{8}). Creating about 4 billion passwords. It takes about a day on my gtx970m to try every single one against a captured handshake.

                                The defaults ESSID’s (wifi network names) are of the form BELL###. So there are a thousand extremely common ESSID’s. Apparently WPA only salts the password with the ESSID before hashing it and publicly broadcasting it as part of the handshake. In a few years of computation time on a decent laptop (so far less if I rented some modern gpus from google…) I could make rainbow tables for every one of those IDs that included every possible default password.

                                On the bright side it looks like this new method extracts a hash that includes the mac addresses acting as a unique salt, so at least the rainbow table method will still require capturing a handshake.

                                1. 2

                                  Oh, ours from vodafone NZ are 16 chars 0-9a-zA-Z

                                  1. 1

                                    I never had this realization. Now my head has exploded.

                                    What tool do you use to try these combinations? And is it heavily parallelized? To me 4 billion should not take a whole day…

                                    1. 1

                                      I experimented with pyrit (24h runtime, builds some form of rainbow table, wrote a short program to pipe it all the passwords) and hashcat (20h runtime, no support for rainbow tables, supports generating the password combinations by itself via command line flags). They are both heavily parallelized, 100% utilization of my GPU.

                                      My GPU is a relatively old GPU in a laptop with shitty cooling, which may contribute to the runtime.

                                      Running on a CPU it said it would take the better part of a month.

                                      1. 1

                                        Interesting. While waiting for a reply, I thought to myself: I wonder how much it would cost to run it on Google Compute with the best hardware. Could be worth it to those who want wifi for a week or longer without paying anything. Spooky.

                                    2. 1

                                      In Luxembourg every (Fritz)box comes with a password written only on the notice (not on the box itself) that is 20 (5*4chars) in hexa. It’s a pain to type at first, but well, it’s seem like a good one.

                                    1. 4

                                      Quality and cost-effectiveness are significant issues for companies developing their own hardware. The GameBoy meets both of those compared to the alternatives.

                                      Reminds me of this patient https://patents.google.com/patent/US5876351 relating to the use of the GameBoy in ECGs (something I believe was actually applied in the German market). There is even a presentation citing ECG software with custom hardware here https://webpages.uncc.edu/~jmconrad/ECGR6185-2013-01/Presentations/Chitale_Paper_Presentation.pdf

                                      I often see people disregard these sort of things because it was sold as an entertainment system for children but the belts and braces of it is that the GameBoy was/is a decent ARM based machine with great battery life and built like a god damned tank!

                                      1. 3

                                        I was just at the Louvre and they use a Nintendo 3DS for their entertainment guide. Cheap to replace, easy to program for, durable since it’s designed for kids to drop, built-in wifi and update mechanisms; probably the best choice you could make in proprietary hardware.

                                        1. 3

                                          Actually, in 2011, Nintendo and Satoru Iwata (RIP) were really into 3DS and interactive museum. Nintendo gifted 5000 to the Louvre and helped develop the software for its use as a audio guide. As a volunteer in a computer and video game museum, that sounds like the perfect solution for us. However, I am not sure we can convince Nintendo to be that generous to us.

                                          1. 2

                                            I figured it had to be some kind of partnership but didn’t realize it was that intense. Maybe not Nintendo, but I’m sure you could find homebrew game developers who could set you up with a system (and used Nintendo DSes to hopefully keep the spend down) that would work for your museum.

                                        2. 2

                                          Game Boy and Game Boy Colour were not ARM-based, they used a Z80 clone with some operations removed built by Sharp. The Game Boy Advance was the first ARM-based Nintendo handheld, based on the ARM7TDMI, and included a full Z80 chip for Game Boy backwards compatibility.

                                          1. 5

                                            gbcpu is not “a Z80 clone with some operations removed”. This is a mistake that has propagated forever.

                                            As far as we know, we (#gbdev) think it was based on some “core” Sharp has for many custom jobs. The actual chip name is LR35902 and should always be referenced as this, or as “gbcpu” or similar.

                                            included a full Z80 chip

                                            No. They included the gbcpu, actually some gbc revision. There is a good chance it will not play some original Game Boy games (I say “good chance” because I have no references, but I’m pretty sure this is fact).

                                            I will be happy to answer any more questions. I love this little device for the nostalgia factor, its history, simple architecture, cheap price point, and retrocoding.

                                            If people made software today like they did during those times, we would have blazing fast applications and way better battery life. It is sad in a way. Our phones could probably run so much longer.

                                            I’m waiting for the day someone also creates an avr-like handheld.

                                            1. 1

                                              Sorry for oversimplifying. As far as I understood though, the LR35902 is a Z80 derivative with certain operations missing (and a few others added). If this is wrong, could you point to some documentation of how exactly an LR35902 differs from the Z80/8080?

                                              I recently got an ODROID GO, which is a Gameboy-like handheld with a backlit color LCD and an ESP32, which is a really nice MCU with WiFi, Bluetooth and a bunch of GPIO neatly exposed in a sturdy enclosure.

                                              1. 1

                                                If you google “The Ultimate Game Boy Talk”, there is a diagram in it that shows exactly what is missing and what is extra :)

                                                It is not a derivative though. It’s simply based on some internal core Sharp re-uses. As I said, this is misinformantion that has been casually spread for a long time now.

                                                Another extremely similar chip from Sharp is SM8521. http://pdf.datasheetcatalog.com/datasheet/Sharp/mXuyzuq.pdf

                                            2. 1

                                              You’re right. I was thinking of the GameBoy SP with its ARMv7 :)

                                              1. 4

                                                Not trying to be a smart ass, but ARM7TDMI is (confusingly) an ARMv4 core, ARMv7 is a newer architecture used by ARM Cortex cores.

                                                I will never understand why ARM chose this confusing naming for their cores & architectures, but there it is.

                                                1. 1

                                                  I did not know that. It’s quite interesting to see the internal workings of these devices; especially with what they were able to achieve with them at the time.

                                          1. 1

                                            One day we will type in a script and the computer will create a movie for us. That day is not today.

                                            1. 1

                                              I…that day might be sooner than we think! In fact, it could already be possible if we use this as a primitive.

                                              Each description is a frame, or maybe better, a “section” of a scene. Then these are interpolated to create scenes transforming from one to another.

                                            1. 1

                                              This is really nice, to get some more overview over the fediverse and to find new peoole to follow.

                                              Thank’s a lot!

                                              1. 1

                                                glad you like it. It feels to me like the good old internet days where you come across quirky communities on the regular.

                                                1. 2

                                                  You know at first I thought “I wish it would show the post’s text”, but when you click through, you discover all the other content that is there. Very cool. I’m actually surprised at the amount of users all over!

                                              1. 4

                                                Learning the basics of Coq well. I hope for it to be the beginning of many things.

                                                1. 2

                                                  You might find this helpful in your journey.

                                                1. 1

                                                  Is there any well known PGP alternative other than this? Based from history, I cannot blindly trust code written by one human being and that is not battle tested.

                                                  In any case, props to them for trying to start something. PGP does need to die.

                                                  1. 7

                                                    a while ago i found http://minilock.io/ which sounds interesting as pgp alternative. i don’t have used it myself though.

                                                    1. 2

                                                      Its primitives and an executable model were also formally verified by Galois using their SAW tool. Quite interesting.

                                                    2. 6

                                                      This is mostly a remix, in that the primitives are copied from other software packages. It’s also designed to be run under very boring conditions: running locally on your laptop, encrypting files that you control, in a manual fashion (an attacker can’t submit 2^## plaintexts and observe the results), etc.

                                                      Not saying you shouldn’t be ever skeptical about new crypto code, but there is a big difference between this and hobbyist TLS server implementations.

                                                      1. 5

                                                        I’m Enchive’s author. You’ve very accurately captured the situation. I didn’t write any of the crypto primitives. Those parts are mature, popular implementations taken from elsewhere. Enchive is mostly about gluing those libraries together with a user interface.

                                                        I was (and, to some extent, still am) nervous about Enchive’s message construction. Unlike the primitives, it doesn’t come from an external source, and it was the first time I’ve ever designed something like that. It’s easy to screw up. Having learned a lot since then, if I was designing it today, I’d do it differently.

                                                        As you pointed out, Enchive only runs in the most boring circumstances. This allows for a large margin of error. I’ve intentionally oriented Enchive around this boring, offline archive encryption.

                                                        I’d love if someone smarter and more knowledgeable than me had written a similar tool — e.g. a cleanly implemented, asymmetric archive encryption tool with passphrase-generated keys. I’d just use that instead. But, since that doesn’t exist (as far as I know), I had to do it myself. Plus I’ve become very dissatisfied with the direction GnuPG has taken, and my confidence in it has dropped.

                                                        1. 2

                                                          I didn’t write any of the crypto primitives

                                                          that’s not 100% true, I think you invented the KDF.

                                                          1. 1

                                                            I did invent the KDF, but it’s nothing more than SHA256 applied over and over on random positions of a large buffer, not really a new primitive.

                                                      2. 6

                                                        Keybase? Kinda?…

                                                        1. 4

                                                          It always bothers me when I see the update say it needs over 80 megabytes for something doing crypto. Maybe no problems will show up that leak keys or cause a compromise. That’s a lot of binary, though. I wasn’t giving it my main keypair either. So, I still use GPG to encrypt/decrypt text or zip files I send over untrusted mediums. I use Keybase mostly for extra verification of other people and/or its chat feature.

                                                        2. 2

                                                          Something based on nacl/libsodium, in a similar vein to signify, would be pretty nice. asignify does apparently use asymmetric encryption via cryptobox, but I believe it is also written/maintained by one person currently.

                                                          1. 1

                                                            https://github.com/stealth/opmsg is a possible alternative.

                                                            Then there was Tedu’s reop experiment: https://www.tedunangst.com/flak/post/reop

                                                          1. 5

                                                            Moving into a new apartment tomorrow, helping a friend move on sunday.

                                                            Though I forgot to rent a truck and now everything is booked… I did find something, but it’s going to cost me.

                                                            1. 3

                                                              Who else but a Québécois move on July 1? :-P

                                                              1. 1

                                                                I’m moving over this weekend as well, and I’m from Florida as opposed to Quebec. If you’re going to move, summer is as good a time as any

                                                              2. 0

                                                                I’m moving tomorrow too. Spent the past month packing so I’m not stressed for it. Going to feel like 45C in Montreal. At least it will not be on July 1st when the whole world is moving and feels like 48C.

                                                                Good luck to you!

                                                                I found this funny so I’d like to mention it: boxes are storage of spacetime. You pack things in the present, you have stored that time (saved it) in the future. It also takes up space. Thus, a box is a spacetime storage medium :D

                                                                1. 1

                                                                  Thank you and good luck to you as well! I’m starting to move at 7h30 so hopefully I can escape part of the heat..

                                                              1. 6

                                                                I can hardly stand reading the site. I have to keep scrolling every 5 seconds…

                                                                1. 2

                                                                  Yeah it’s a bit… Big. Also, why do all these web “book” authors always refuse to have a “next” button for linear navigation through the reading material…

                                                                  …You know, like a book.

                                                                  1. 1

                                                                    It’s a lot more readable if you set your browser’s zoom to 50%.

                                                                    1. 1

                                                                      and max-width: 50em (instead of 25) for main for people who use user styles. With 50% font-size and increased width, its pretty nice :)

                                                                  1. 3

                                                                    At work we use YYYY.MM.NN for internal software (NN being a 0-indexed release number for that month).

                                                                    I like this for knowing when something was last updated, but it’s not helpful for identifying major changes vs. bugfixes. Perhaps that’s not such a big deal for software that’s on a rapid release cycle.

                                                                    1. 2

                                                                      It’s also not a big deal for software that’s too big or complex for “major change” to be meaningful. If a tiny, rarely used Debian package removes support for a command-line flag, that’s a major change (in the SemVer sense) and since Debian includes that package it’s therefore technically a major change in Debian. But if Debian followed SemVer that strictly, its version number would soon leave Chrome and Firefox in the dust, and version numbers would cease being a useful indicator of change.

                                                                      1. 7

                                                                        Isn’t Debian’s solution to this to not include major-version changes in updates to an existing release? So it does wait for the next major version of Debian to be included, usually

                                                                        1. 1

                                                                          Yep, and this is where the -backports or vendor repos are really useful - newer packages built against the stable release.

                                                                        2. 2

                                                                          It’s why we have to make “stable” releases. Otherwise everyone goes crazy. If someone is updating their SemVer too often, they have bad design or do not care for their developers.

                                                                        3. 2

                                                                          There’s a discussion of CalVer and breaking changes here: https://github.com/mahmoud/calver/issues/4

                                                                          Short version, “public” API is a bit of a pipe dream and there’s no replacement for reading (and writing) the docs :)

                                                                          1. 2

                                                                            The concept of breaking changes in a public API isn’t really related to ‘read the docs’, except when it comes to compiled in/statically linked libraries.

                                                                            If you have dependency management at the user end (i.e. via apt/dpkg dependencies that are resolved at install time), you can’t just say “well, install a version that will work, having read the docs and understood what changes when”.

                                                                            You instead say “I require X major version of package Foo”, because no matter what the developer does, Foo version X.. will always be backwards compatible - new features might be added in a X.Y release, but thats not a problem if theyre added in a backwards compatible manner (either theyre new functionality that has to be opted in for, or e.g. they don’t require extra options to work).

                                                                            Yes, I know that things like Composer and NPM have a concept of a ‘lock’ file to fix the version to a specific one, but that’s not a solution for anything but internal projects. If you’re installing tools that you aren’t directly developing on yourself using NPM or Composer, you’re doing it wrong.

                                                                            1. 1

                                                                              I really don’t see what that has to do with the linked thread. In the very first line, you mention a “public” API. The point is that there’s much less consensus on what constitutes a public API than developers assume. So, you end up having to write/read the docs about what would constitute a “semantic” version change. (Not that docs are a silver bullet, they’re just a necessary part of healthy software development.)

                                                                              1. 1

                                                                                The point is that there’s much less consensus on what constitutes a public API than developers assume.

                                                                                A comment by you making that same claim on GitHub isn’t really evidence of a lack of consensus. What possible definition is there for “public API” besides, “something that will be consumed my someone outside the project”.

                                                                                So, you end up having to write/read the docs about what would constitute a “semantic” version change.

                                                                                The decision tree for SemVer is two questions, with 3 possible outcomes. And you’ve still ignored my point. Adherence to semver means you can automatically update dependencies independently of the developer.

                                                                                So, for instance, if the developer depended on a shared library, that happens to have a security vulnerability, when the library author/project releases a new patch version, end-users can get the fix, regardless of what the tool/app developer is doing that week.

                                                                                1. 1

                                                                                  The automatic updates work until they don’t. Here is a recent example where Python’s pip broke with many assumptions about public APIs. Your point has not been ignored, I’ve written about it extensively, in the linked thread and in the linked site (and links therein).

                                                                                  As for your closing comment, I’m noticing an important assumption I’m working to uproot: current date is not the only possible date in the release version. manylinux2010 came out in 2018, and is named as much because it’s backwards compatible to 2010.

                                                                                  The Teradata example on the CalVer site also highlights maintaining multiple releases, named after their initial release date. At the consumer level, Windows 98 got updates for years after 2000 came out.

                                                                                  1. 1

                                                                                    That isn’t a failing of semver, it’s a failing of the developers who didn’t properly identify they had a breaking change.

                                                                                    The same thing would have happened under calver, they would have marked it as a patch release with compatibility to the previous version, regardless of the date component.

                                                                                    Expecting people to just forget about the possibility of automatic dependency updates is like suggesting people forget that coffee exists after they’ve had it daily for 10 years.

                                                                        1. 3

                                                                          Very cool - I really like lower-power equipment like this. However, I think it’s a terrible idea for security since it looks like its an unencrypted video stream which would make eavsdropping trivial.

                                                                          1. 6

                                                                            I’d hesitate to call it eavesdropping if you have to get within 8 ft of the camera to do it

                                                                            1. 3

                                                                              It’s sort of the digital equivalent of corner mirrors in stores and on streets.

                                                                              1. 0

                                                                                Well that just about kills most of the uses for this product :/

                                                                                1. 3

                                                                                  No? It’s perfect for home security cameras or on-body cameras.

                                                                                  Sign me up.

                                                                                1. 7

                                                                                  So as far as I see, this isn’t necessarily a bug with PGP “itself”, when used for signing git commits or used in combination with pass, but rather when sending encrypted emails. Or am I wrong?

                                                                                  1. 2

                                                                                    The first exploit, is definitely not PGP’s fault.

                                                                                    Unfortunately because I don’t know S/MIME, I can’t comment. But it seems like there is some inherent problem with the second attack affecting both it and PGP.

                                                                                    1. 2

                                                                                      CBC and CFB encryption modes use the previous blocks when encrypting new blocks. There are some weaknesses, and of course OpenPGP and S/MIME use them. That seems to be part of the problem. The other part is that stitching together multipart messages is something that email clients have no problem with doing, so shit HTML, can result in a query string that exfiltrates the content of the decrypted parts.

                                                                                      1. 2

                                                                                        OpenPGP mitigates those weaknesses with authenticated encryption (MDC). So it’s still only a problem if a broken MUA ignores decryption errors from gpg (or if the email in question is using a very old cipher. so, the attack may work if you auto-load remote content on encrypted emails from before 2000)

                                                                                        1. 1

                                                                                          OpenPGP mitigates those weaknesses with authenticated encryption (MDC). So it’s still only a problem if a broken MUA ignores decryption errors from gpg (or if the email in question is using a very old cipher. so, the attack may work if you auto-load remote content on encrypted emails from before 2000)

                                                                                  1. 7

                                                                                    I’ve finished the core of my hardware and software Chip-8 emulator, running on an Atmega1284 MCU with an SSD1306 OLED display, buzzer, keypad and SD Card reader. Finally got a launch menu integrated, that allows me to give users options to select emulation quirks using the 4x4 keypad.

                                                                                    Now I just need to go back through the emulator core, double check and test the quirks and I’m ready to implement Superchip support. I’m also going to start looking at laying up the PCB for an initial run. My head says Eagle CAD, as that’s what I’m used to but my heart keeps telling me to use KiCAD. I can fit the emulator in the 1284, but I’m uhmming and ahhing about adding support for a BASIC interpreter, and I really need some external RAM to make the most of that. I’ve been looking at 64k modules, but I might leave that for a later iteration if I can get this to a steady state without the extras.

                                                                                    1. 1

                                                                                      What’s the battery life?

                                                                                      I’d like to make something very similar to this, but no emulator. Just write fast atmega assembly.

                                                                                      1. 1

                                                                                        I haven’t had it running on battery yet, but with some clever tickling of timers and the OLED I’m hoping to get about 48-96 hours on 3 x AA batteries.

                                                                                        1. 1

                                                                                          No way to get it on 1 AA? I think 3 is too many :D

                                                                                          1. 1

                                                                                            A single AA is 1.5v, you’re going to need at least 3.3v to run things properly (although I think I can get away with down to 2.7v). 3 AAs should get me 4.5v, which lets me cheap out a little on power management ICs (everything is 3.3v/5v tolerant), although I might use an MCP1702 3.3v LDO regulator.

                                                                                            For this version of the board 3 AAs will be fine, I’ll look at options for using 2x AA or possibly coin batteries with a step-up converter or boost regulator down the line when I’m ready to build a production version. A lot of people forget the original gameboy used 4 AAs.