Not of course to be confused with “Chicken chicken chicken”:
3 Likes
Yeah, I think that it may be more common, but both can certainly be used. I find there are some contexts/sentences where bullshitted sounds better, and others where it sounds awkward compared to bullshit.
I hate to be a party-pooper, but this script, fun as it may be, presents a pretty serious security risk.
The problem is that it pulls arbitrary javascript from a remote server, then executes it in the context of whatever page you’re viewing. Sure, the javascript it’s pulling today is perfectly legit, but there’s no guarantee that will always be true. In a month, these seemingly lighthearted devs might turn out to be blackhearted, and swap that harmless code for something nasty; Or in a couple years the devs may lose interest and turn maintenance over to a volunteer who turns out to be a bastard who swaps the harmless code for something nasty; Or a thousand other variations on that theme. Then suddenly this formerly-harmless bookmarklet is snooping for online-banking session to hijack, there’s money missing off your dresser, and your daughter is knocked up. It’s the same problem that leads to all those NPM library swaperoo vulnerabilities, and also the same reason that browser extensions aren’t permitted to execute remote code without a special permission. (Aside: Requesting that permission is a giant red flag that you reeeeally don’t want to install a particular extension.) In the larger view, it’s also one of a million reasons why javascript is one of the worst inventions in human history. Anywho, I’m sure this unsafe design came from good intentions – they want to be able to auto-update the word list – but it’s still unsafe.
If you wanted to make it safe, you could manually download the remote javascript file, review it, then rewrite the bookmarklet to insert that specific code instead of referencing a remote javascript file with arbitrary – and potentially malicious – contents.
If they wanted to redesign it safely while retaining the auto-update functionality, they could put all the executable code in the bookmarklet and convert the word list into a raw data file that the bookmarklet code would download and parse. I’d still worry a bit about deliberate parser bugs I’m not smart enough to see, but it’d be a lot safer than the current design.
8 Likes
Shouldn’t Bookmarket in the title be Bookmarker?
At first, I thought Bookmarket was a website were the file was.
I think it should be Bookmarklet, a portmanteau of Bookmark and aplet.
2 Likes
Is that really necessarily safer? One of the ways security is compromised in Android is when old apps are bought (or the update servers hacked) so the new owner can auto update the existing installs with malicious code. I suspect most people have auto update enabled, and even those that don’t lack any way to to audit the code of new updates before installing.
1 Like
That’s actually super interesting.
“He bullshit me yesterday” sounds correct (vs “he bullshitted me yesterday” which sounds awkward to me). But I can’t wrap my head around “bullshit bullshit bullshit”, whereas “bullshit bullshitted bullshit” parses fine!
1 Like
The shit that I shat earlier was certainly shat and not shitted. Bulls may have a different view of their own past shitting.
3 Likes
I had the deeply satisfying experience the other day, when asked by a government interviewer to state where I was born, including state, city and county, to say “New York, New York, New York.”
Aaaaah.
6 Likes
Wait… I thought each borough was a separate county?
(edit: ahhh, Manhattan is “New York County”! I don’t know very much about New York. I’m a New Englander.)
Right. Manhattan is New York, Queens is Queens, Bronx is Bronx, Brooklyn is Kings, and Staten Island is Richmond.
4 Likes
Well, yes. Though, judging from your comment, this may take a bit of explication. Brace yourself.
-
Generally speaking, bookmarks are safe because they reside in a file on your hard drive that you can freely read and edit, but remote parties cannot.
-
“Bookmarklets” are bookmarks with javascript in the url field. When you click a bookmarklet, that javascript gets run in the context of the current page.
-
Bookmarklets are generally safe because, again, you have sole control over what goes in there. You can read and review the javascript and make sure it’s safe before you paste it into a bookmarklet. (Or, if it’s unreadable minified crap, you can reject it because it’s unreadable.)
-
What makes this particular bookmarklet unsafe is that the javascript says “go download this remote javascript file and execute the function named ‘X’ you find there.” This is unsafe because whoever controls the remote file could pull a switcheroo and swap it for something malicious. And then that something malicious gets to run in the context of the current site, which could be something sensitive like webmail, online banking, online shopping, etc.
-
The android app problem you mention is analogous to point #4 here, the present situation with this particular bookmarklet. In both cases you’re blindly trusting remote executable code that someone could swap for something malicious without notice. It’s not analogous to either of my proposed fixes, and I’m going to have to try to explain why that’s the case.
-
My proposed DIY fix is to edit the bookmarklet code by removing the “go download a remote javascript file” part and instead inserting the contents of the current version of the remote code. The current version of the remote code is totally benign and basically says, “walk the DOM tree, and, each time you find a word on this list, replace it with a properly capitalized variant on ‘bullshit.’”
-
The DIY fix renders the bookmarklet completely safe because it restores the situation from point #3 where you have sole and complete control of the code. (The downside is that the word list becomes static.)
-
My proposed “if the devs wanted to have their cake and eat it too” fix (hereinafter “eat-cake fix”) involves two steps. First, do the DIY fix – move all the executable code from the remote file to the local file. Second, further edit the bookmarklet code to the effect of “Before walking the DOM tree, go download this remote txt file and add its contents to the word list.”
-
Assuming it’s properly implemented, the eat-cake fix is also perfectly safe. Whoever controls the remote txt file has the power to add words to the list, but nothing more. All the executable code lives in a local file under your sole control.
-
What gives me a little bit of pause is the question “Well, what if it isn’t properly implemented?” Or, more precisely, what if the “add the contents of the txt file to the word list” part has a deliberate bug that (a) is subtle enough I wouldn’t spot it, and (b) somehow winds up treating part of a malformed input as executable code? In this particular case, I don’t think that’s a realistic concern because parsing a txt file in one-word-per-line fashion is so braindead simple that I don’t think you could hide any funny business in the parser. But what about something more complicated like deeply nested json structures? Yeah, I’m not sure I could audit a parser for that adequately, so I’d be hesitant to let it run in the context of webmail, online banking, etc.
2 Likes
2 Likes
2 Likes
This topic was automatically closed after 5 days. New replies are no longer allowed.
