A related work by the same folks that I think builds on this issue: https://lab6.com/1
In 1, they show that plaintext and even mp3 formats can be included in a pdf file in a way that allows the file to be read by a plaintext reading program, a pdf reading program, and an mp3 playback program! I think that alleviates some of the concerns I’m seeing in comments here about the accessibility concerns of pdfs.
It’s nice to see folks trying new ideas in this area. I’d be curious to hear more about who this is really designed for. All the chords requiring the pinky finger make my emacs-crippled hands flare up in pain just looking at them. But that’s just me.
I looked online and was glad to see the Twiddler was still a product you could buy. That was the one handed keyboard of choice among the wearables crowd at the MIT Media Lab in the late 90s. 12 core buttons for typing with the 4 fingers (with chords) plus extra buttons for shift, etc on the thumbs. A few friends of mine used them regularly and could type reasonably (20-30 wpm?) although I think they all preferred a full keyboard when they had the option.
I’d be curious to hear more about who this is really designed for.
People who sometimes need to hold a child and type at the same time.
People who need to hold a device (technician role) while typing what they read or observe into the computer.
People in hostage situations where you need the plot to advance.
having just watch the demo video my immediate thought was why is the thumb ignored - although I appreciate that the design would need to be a different shape if you were using thumb, index, middle and ring fingers. The reliance of the pinkies on a standard QWERTY keyboard for me is a design failure…
why is the thumb ignored
I missed it on my first read through, but they mention it’s to allow the thumb to help hold the device when you want portability:
Since only four fingers are used, the thumb is free to stabilize and hold the board. This simplifies the hardware design for portable hand-held keyboards made for ARTSEY.
Yeah, I think the site could benefit a lot from a comparison with similar alternatives like the Microwriter.
I’d seen Twiddler before but forgot it’s name, and I’ve been trying to find it again for ages. Thank you for helping me find it again :D
Given how most of the radio groups on the page provide links to other resources where I can use the font, color scheme, etc that I’ve selected, I would’ve expected the same or similar from the desktop background choice. Am I missing a way to download a cute constellation wallpaper? Or does that option simply change part of the image at the top of the page?
While it’s not the default option in git, I think a simpler solution can be used. You can create a commit with no changes with the --allow-empty
. With that in mind, you can easily start working with an empty commit and a commit message detailing what you intend to work on; after you stage your changes with git add -p
, then you can amend your commit to add the newly staged changes to the previous commit. You even get to rewrite the commit message if you want!
# before working on x, y and z
$ git commit --allow-empty -m “I’m going to work on x, y, and z in this commit”
# worked on x and y, didn’t get to z, but also worked on w
$ git add -p
$ git commit --amend -m “Complete x, y, and w”
Why not use tar? If it has to be plain text, pipe into base64. Nothing beats the portability of using widely distributed tools imho.
I though the same, then realized there’s some utility to what they are doing: they make the metadata like file names and locations plain text as well. I dunno if it’s going to take over the world, but it’s a neat thought.
Doesn’t the tar command have an option to list the filenames and directories contained within? Sure, you have to run the command instead of simply opening the file in whatever text editor or reader.
For what it’s worth, I believe the reason that the sentences “The eggplant is a fruit” and “The dog is a Samoyed” is much simpler than natural languages poorly representing unambiguous facts. Those two sentences are different not because of the “the” and the “is” being ambiguous, but rather because “eggplant” is more specific than “fruit” and “dog” is less specific than “Samoyed”.
A year ago, I was getting into NYT crosswords myself and had the idea to make one too. I wrote a tool in Elm to help create do the task.
It helps with drawing the grid and retaining rotational symmetry. It indicates clue numbers in the grid, as per NYT placement. It allows hovering over a square and typing a letter to begin filling.
I intended to add a way to indicate a problem with the grid to help notice things like erroneous 2 letter answers or non-contiguous empty space, but I never did get around to it.
In case you’re interested, it’s here: https://crossword.wfl.space
I’m actually a fan of using a tablet to read ebooks. It takes less space, doesn’t require 2 hands to operate, has its own light source (a very subjective advantage I guess), and ebooks can be searched through without scanning. Changing a book is just a few taps away.
I personally find it inconvenient to switch pages (or quick jump) on e-readers/ipad, it’s not as quick and convenient as physical books.
One more thing, I bet you can hold an iPad with 1 hand for a long time :D I tried with an iPad Mini.
Instead of an iPad, I’m using a Lenovo Yoga Tab 3 which comes with a built-in stand, so I don’t need to hold it anywhere. But as I’m a user of a 3D printer, I’ve printed myself a smartphone/tablet stand for devices that don’t have it built in.
https://cdn2.techmaniak.pl/wp-content/uploads/tabletmaniak/2015/09/Lenovo-YOGA-Tab-3-Pro-large.jpg
This is why I don’t need to use my hands at all, not counting the occasional tap on the right side of the screen. To eliminate the tap, I’m sure there’s an option to configure voice control. The tap was never a problem for me giving the fact that most books are built in a way that it requires to hold the book open with two hands at all times, because the book just closes itself when I’m letting it go.
I’m actually using the stand to hang the tablet when I’m on the treadmill, so I can read while running. It’s possible because I can make the fonts larger by zooming in the view :)
sure there’s an option to configure voice control. The tap was never a problem for me giving the fact that most books are built in a way that it requires to hold the book open with two hands at all times, because the book just closes itself when I’m letting it go.
A remote control just like ones on DSLR cameras is also a good idea :D
I’ve seen foot pedals designed to flip pages on ebooks. They’re mostly designed for flipping ebook versions of sheet music while playing, but they could definitely be used for other purposes.
If you want the geeks to go further, there are some EEG headsets out there with the SDK, someone can build a literally mind-controlled page flipping with it.
I personally find it inconvenient to switch pages (or quick jump) on e-readers/ipad, it’s not as quick and convenient as physical books.
Maybe it’s the app you’re using? For me it’s just a small flick of a finger.
One more thing, I bet you can hold an iPad with 1 hand for a long time :D I tried with an iPad Mini.
You can if you rest the ankle on your armchair’s support.
No, I mean the time you need to jump back and forth about 50 to 100 pages, like in the middle of the book to chapter 1, or to the TOC,…
More inclusive and open
Male and female emoji have been merged into gender-neutral emoji that are relevant to you
I fail to see why this is “more inclusive” or “open”. I mean, I’m all for people who are gender-neutral, I have no problems with this, but considering that the vast majority of the population isn’t gender-neutral, it’s actually less inclusive, by definition. Either provide more possibilities or go ahead and just say that there are fewer options. But don’t bend over backward to appease a small amount of people by normalizing everyone. :(
The way I see it is that Unicode emoji tried to be gender-inclusive by adding a “female” modifier (emoji + zero-width joiner + ♀️).
This reinforces a false binary, and the way it’s implemented in mainstream emoji design reinforces gender stereotypes. Women have long hair, makeup, and pink clothes; men have short hair and blue clothes; that sort of thing.
Gender isn’t something that can be seen, and so I don’t think adding more and more gender options makes sense. In my opinion, it would be much better to offer stylistic choice, such as “long hair” or “makeup”, as options unrelated to gender, since that’s what they are.
I don’t agree that having fewer gender options makes it less inclusive. It isn’t saying that every emoji represents a non-binary or agender person or anything. It simply does not specify a gender, and so they aren’t excluding anyone on basis of gender.
Edit: it’s like how the basic facial expression emoji were never gendered to begin with, and so there is no need to add more gender options to them.
Gender isn’t something that can be seen
Most of the time it can but not on something as tiny and reductive as an emoji without having to use things like clothes color.
Sure, you can guess, and odds are you’d be right a lot of the time, but it still isn’t defined by any kind of outward appearance.
Additionally, I find it odd that they’ve chosen to reduce the set of available choices when it comes to gender, but they’ve greatly expanded the choices when it comes to race. I think they should decide whether they want to provide options for things like race, gender, sexuality or not provide options.
I poked around and found a relevant pair of questions in the FAQ on the race and gender questions. They don’t specifically compare the two decisions, but the rationale for each is there.
I don’t understand why many programmers want to use the terminal. The whole PHP community now seems to be infested with this legacy way of interacting with programs. I find it really cumbersome to work with.
Is a GUI really that bad for the tasks performed in a terminal? Why?
I don’t all the specifics, but wp-admin interfaces exposed to the internet have been an absolute shitshow in the past. If you restrict admin powers to an alternative interface, that limits how badly things can do. Gating admin access through ssh seems like a good reduction in attack surface. Assuming this isn’t a just CLI to a still exposed web API.
It can work any mix of 3 ways AFAIK: run on the box with with the WP install (point it at a local file path), run via SSH (point it at a hostname/port/path combo) or run via HTTP (point it at a URL). So yeah, in addition to making it much easier to automate admin tasks you can lock off admin functions to be only accessible via SSH.
I prefer a terminal interface for things that I need to do often. I find it much easier to achieve muscle memory with typing (moving my fingers over a physical space) than pointing and clicking (moving my virtual finger over a virtual space). With muscle memory I don’t need to think about how to do a task - I can just do it.
Crystal http://crystal-lang.org. It’s a Ruby inspired syntax, but compiles to code that’s comparable to C.
I don’t mean to denigrate this research, nor to minimize the significance of this finding. It really all makes me think that I am missing something…
When I am browsing the web, I assume that my browser can track anything I do on any website, should it so choose. In order to serve its basic function, it must have that ability. As a consequence, I tend to carefully consider which browser I choose to use.
I have never learned anything different about the in-app browsers that various applications provide. As far as I know, they are just browsers, and in order to function, they have access to the things I browse. As a consequence, I don’t like to use those in-app browsers for much of anything at all, and I always use the ability they provide to escape to my platform’s browser if I’m doing more than just reading a thing that’s available to the general public anyway.
Is there some new thing they’re doing that’s worse than just “being a browser supplied by a party I don’t trust”? The attention this is getting makes me suspect so, but I don’t see it yet. And that worries me a little.
The point is that they went out of their way to not just use a typical webview but modify and render the pages “themselves”
It is still a WKWebView, isn’t it? Is the script they’re injecting giving them more/nastier abilities than the DOM inspection they could do against whatever is loaded into the view, given that their app can talk to their own server at any time?
I find it very interesting that they’ve been caught at the kind of thing I (and clearly others) suspected they’d be doing.
I also wonder what countermeasures are available to Apple. Too many apps need to be able to interact with the DOM on pages they load this way for them to get rid of that completely. Maybe they could only allow that for markup that’s shipped with the app, and require SFSafariViewController for remote content?
Or for content hosted outside the domains the authors declare in advance?
I’m sure that would still break a great many apps.
I don’t have any answers except yes, it needs to be some kind of webkit-webview (I think there were two kinda kf classes. Dunno if they both still exist). Apple does not allow any web rendering engine except its own.
Apparently they inject some tracking js into the pages you’re viewing, if I understood it correctly.
(I’m still digging around and reading stuff as I comment…) That matches my understanding, but my question is more about whether/why that’s different than what you’d assume to be the situation prior to the publication of this research. It’s certainly interesting that they’ve been caught using this mechanism, but can’t they inspect the DOM of anything at all they load into their embedded browser anyway? Without this easy(ish)-to-detect injection? It’s been a while since I played with these controls on iOS, but whole classes of apps do or did depend on doing just that.
I think I’m still missing something.
I’m sure they could be doing it more covertly, but I suppose it was easier for them to just inject the code they already had working.
Considering that Meta is Meta I already assumed that they’d be doing something like this (which is a reason I prefer the “Open in Safari” route where possible), but this is proof that they actually are. So it’s not a surprise, just confirmation of suspicion.
It’ll be interesting to see how they handle this when Apple comes asking questions; will they remove it, make it covert, and/or lawyer about it in court?
I’m also a bit confused here. If you’re using someone’s program, they can phone home with whatever information they please. If you’re browsing the web from their program, they can quite obviously snitch on what you’re doing on the web.
Perhaps the issue here is that they can’t really ship their own browser engine (which would trivially allow the above) because Apple won’t allow it. So, they have to use Apple’s shipped browser engine, which would perhaps make this kind of spying harder. So maybe the actual news here is that they’ve found a way to still extract information from it by injecting JS code into web pages?
No, that’s the point. On iOS you should be using the system provided browser inside your app to present web views or render HTML, the OS then limits what the host program can do with that view. Facetagram has built/packaged/shipped its own render to avoid this limitation and circumvent the OSS strict enforcement of User privacy.
Nope. No one uses a custom browser engine on iOS, it’s effectively disallowed. They are using a regular WKWebView and using its API to inject a JS script that messes with the DOM.
But apps are basically allowed at Apple’s discretion, so if they really wanted they could take a stand and flat out reject the app from their store. Now that would set a precedent!
That was my understanding before this article. I should read it when less sleep deprived. Thanks for the correction
I believe WKWebView renders out of process (that’s why it can JIT JS). Grabbing DOM from WKWebView without injecting JS is not straightforward (you probably can do by grabbing the data with one of the “snapshot” APIs, but need to reparse again). Many things to do with WKWebView probably is not straightforward due to this out of process and sandboxed nature.
WKWebView does not support native-code access to the DOM the way the old WebView did (if only on MacOS.) What it does have is methods to run a JS script in the loaded window context, and to define JS hook functions that invoke native callbacks.
There are a lot of legit uses for this — HTML-based app packaging systems like PhoneGap/Cordova use it extensively, and I’m sure app-packaged React does too.
I agree. I think what I was speculating could be a countermeasure would be tying the injection to the “app bound domains” that another poster pointed out and scrutinizing anything that needs that kind of feature for a non-bound domain.
If it’s a WKWebView, the app can fully interact with the page by injecting JS.
If it’s a SFSafariViewController, the app can do very little: change the accent color of the Safari controls, choose from a few dismiss button options, adjust how the user can use the share sheet, and a few others.
Most apps that don’t open the user’s default browser opt to use the SFSafariViewController. As a user, I think the only way you could tell the difference is that if it doesn’t look like a SFSafariViewController, then it’s definitely WKWebView. I don’t think there’s a way to tell that an app definitely is using a SFSafariViewController (as a user).