Having your business beholden to any app store is a bit scary, but Google's chrome web store is probably the most precarious. As far as I can tell, almost every negative action taken against you is done in an automated fashion, with basically no human recourse beyond knowing someone on the inside or hoping for a negative PR cycle.
At least with the mobile app stores, a good review process with some human recourse is baked into the incentives of the platform, since lots of money is involved.
With the Chrome web store, you get the feeling it is just there because Google capitulated in the past, acknowledging that browser extensions are necessary to be a mainstream browser. Beyond that, it seems to be moderated with two goals: reduce overhead cost and mitigate any security threats.
The result is the complaints you hear from every extension developer:
* Google arbitrarily blocks a decent % of updates, because of automated flagging
* Google removes extensions with basically no recourse, often for unclear reasons
* Google itself (if I remember correctly) even recommends using a Google account separate from your personal/work email, since often these automated suspensions take down the account connected to it too
Don't get me wrong, browser extensions have a lot of power and that's often an issue (malware, browser history collection, phishing, etc). Still, building an extension for Chrome involves the constant reminder that you are under the thumb of a big monolith organization that is indifferent to you.
To me the problem seems to be minification causing something to look like obfuscation. If you look at the article you can see that the minifier combined the short strings of hex characters into longer ones. I think it's entirely possible that the length of a string like that plays a factor in what gets flagged.
Another cool way you could do this: Ruby methods can ask for their caller_locations. They work like this:
# Source
$ cat example_for_hn.rb
def foo
bar
end
def bar
baz
end
def baz
(c1, c2) = caller_locations.first(2)
puts "Parent caller: '#{c1.label}' in '#{c1.path}'"
puts "Grandparent caller: '#{c2.label}' in '#{c2.path}'"
end
foo
# Demo
$ ruby example_for_hn.rb
Parent caller: 'bar' in 'example_for_hn.rb'
Grandparent caller: 'foo' in 'example_for_hn.rb'
So, you could define a method decorating class method like so:
module Shitlist
def shitlist(method_name, whitelist)
original_method = instance_method(method_name)
undef_method(method_name)
define_method(method_name) do |*args, &block|
call = caller_locations.first
passes_whitelist = whitelist.any? do |label, file_pattern|
call.label == label && call.absolute_path.end_with?(file_pattern)
end
unless passes_whitelist
fail "Shitlisted method! Permitted callers: #{whitelist}"
end
original_method.bind(self).call(*args, &block)
end
end
end
and then extend classes with it to use the decorator:
class Example
extend Shitlist
def not_on_shitlist
qux
end
def baz
qux
end
def qux
puts 'Only some methods can call me :)'
end
shitlist :qux, 'baz' => 'shitlist.rb'
end
If I run this example (full source: https://git.io/JLOdV), the non-whitelisted caller throws an error:
$ ruby shitlist.rb
Only some methods can call me :)
Traceback (most recent call last):
2: from shitlist.rb:44:in `<main>'
1: from shitlist.rb:25:in `not_on_shitlist'
shitlist.rb:13:in `block in shitlist': Shitlisted method! Permitted callers: {"baz"=>"shitlist.rb"} (RuntimeError)
---
Of course, you might not want this hijacked method with tracing inside something performance critical. You could always configure the implementation to be a no-op in production.
I had the privilege of seeing Jeffrey do multiple live performances of his software (demoed @ 9:20) at different Internet Archive events while he was the artist in residence.
Each time, I got the delightful feeling that I was witnessing something special (and, of course, very weird in a good way). The performance is legitimately "live" in that he's creating new images from scratch, and it seems clear that he's able to build up this rich imagery from what seem like a handful of solid composable building blocks in his software.
I always found those performances inspiring in a similar way to how I feel the times I have visited DynamicLand. A wonderful blend of the physical medium and alternative ways of thinking about computers that produce such an interesting result, making me glad people like this exist in the world.
Ruby's parser is notoriously complex; if I remember correctly, only a few members of the core team even know how to maintain it without introducing regressions.
The craziest part of this is that Ruby does not provide a full featured Ruby parser, so its entire static and dynamic analysis ecosystem depends on a (actually very high quality) 3rd party parser, begrudgingly maintained by someone who (AFAIK) doesn't even write Ruby anymore: https://github.com/whitequark/parser
When I see new language features like this, I think of how Ruby's entire tooling ecosystem depends on the dramatically underfunded (and therefore primarily goodwill) efforts of high output maintainers like whitequark and a few others. Ruby's highly dynamic and untyped nature means these tools are all the non-runtime guarantees you can get, basically. Epitome of digital infrastructure.
Consider asking your company to fund some of these people:
I helped out with parser as well for a while, though it was mostly documentation, triaging issues, that sort of thing. I think I still have push access to the Gem, as at the time the project had a bus factor of 1 (= whitequark).
Anyway, I remember just how frustrated whitequark would get every time CRuby decided to make some random syntax change. I have a lot of respect for the current maintainer(s) for putting up with the ever growing complexity of the Ruby syntax. I hope Ruby stops changing the syntax on a regular basis, but I doubt this will happen any time soon.
Yeah, I don't remember any of the Ruby tooling ecosystem maintainers having nice things to say about the various syntax changes they've added over the years. I don't blame them.
These changes are always justified with a hand wave and a reference to "developer happiness" and ergonomics. I think that justification is seen as insulting when all the static/dynamic analysis tools obviously actually deliver a lot of value to Ruby devs, and yet the basic tooling to support this ecosystem (robustly parsing, traversing, annotating, rewriting, and unparsing an AST) is not provided by the language.
Is Ripper dead? I attempted to do some minor work on Ripper and it was profoundly painful. My explanation for Ripper boiled down to a domain specific language in parse.y comments that gets translated into C via a very confusing Ruby script, which manually calls Ruby VM functions, that wait for it, are dynamically defined. This constructs a parse tree. If Ripper is still getting maintained, I'm seriously impressed.
Yeah. Been years since I even played with it, but even in 2016 I remember Ripper being completely unusable, failing to parse plenty of normal Ruby syntax. The Parser gem also maintains a separate parser for every Ruby version, so you can a program using Ruby 2.5 but tell it to parse code according to Ruby 2.2 syntax. It's also just way better built, tested, and has other nice features like tools for rewriting ASTs.
I'm building Jam (https://jam.link/) to tackle this problem. You can think of it as a consumer password manager built specifically for sharing.
It's fully frontend encrypted, so Jam doesn't know what logins you save and it can't read your secret credentials. The cryptography is based on 1Password's design (https://1password.com/files/1Password-White-Paper.pdf). I'd be happy to share details if people are curious.
Jam's focus on sharing comes through, right now, in the UI and default behavior. For example, when you save a new login, your friends in the system can proactively request access. To visually illustrate that: If I save a new login to Jam (like so https://i.imgur.com/syM2bep.png) then my friend gets a notification about that account, can see what it is (https://i.imgur.com/ZUKwfBB.png) and can request access (https://i.imgur.com/3SCcBm5.png).
It's in private beta right now, it's free to use, and I'm looking for as much feedback as possible. I'm happy to add people from HN right away, just email me at john at jam dot link
Regarding "decentralization can only exist to circumvent the law", I don't think that in the long term (>5 years out). I touched on this a bit in another comment: https://news.ycombinator.com/item?id=17641098
Regarding privacy, I'm with you there, but I'm very skeptical that very fuzzy privacy concerns can switch enough people away centralized systems with network effects (FB, Twitter, Reddit, YouTube). I think these systems will see adoption from a few groups:
- Privacy advocates and people otherwise interested in the tech by itself
- Ostracized groups. For example, see how Voat (not a decentralized system, but an example of a Reddit clone with a ideological mission) wound up as a hub for the alt-right.
- The most extreme people trying to boycott platforms like Twitter. For example, people demanding way more censorship from Twitter that are trying to make Mastodon happen because it has content warning stuff and other anti-harassment stuff from what I've heard
- Communities that are forced out by the law, like r/DarknetMarkets moving to Dread: https://medium.com/@jbackus/minimum-viable-decentralization-...
So, subcommunities definitely will exit I think but whether they go to other centralized systems depends on UX (which is harder with decentralization) unless a legal reason makes decentralization the only option.
I see your point ; I think there is actual and genuine interest in privacy and decentralization from what I see within my friends circle, but I may be biased because I'm active around ssb myself (and my friends may very well be interested in this because ... I'm interested in it). Time will tell :)
Regarding incentive for legal reasons, there's an other possible one that may happen (mentioning it for exhaustivity). Yesterday, I was reading an article about how an extreme-right candidate was favorite in brasilian elections. I was thinking : "oh look, an other fascist about to seize power". It feels like it's been a recurring theme this decade. And this is terrifying : could you imagine what the gestapo would have been with access to facebook data?
It doesn't even need the entire world to go mad before the incentive for privacy becomes very strong, 10 or 20 countries with strong engineers would be enough to kickstart it.
Author here. I'm mainly writing about decentralization that is supposed to be mainstream while also looking for historical examples. With that in mind, I've looked at:
- Dozens of file sharing apps and their protocols (focus on Napster, Gnutella, FastTrack, and BitTorrent)
- Tor, I2P
- Tor hidden services
- Original p2p Skype
If we generalize "decentralization" into "creative uses of distributed systems and/or cryptography for the sake of privacy and resilience" then we can include a bit more:
- PGP
- Willfully blind centralized systems like mega.nz
Then finally if I dip into older attempts that IMO didn't get real adoption, we can include some other interesting examples:
- Freenet
- Tribler
- Mojonation
There are systems like Diaspora and Mastodon, but they're too close to the present IMO to use as historical examples. There are also obviously decentralized/distributed systems that serve as the backbone of the internet and I do want to allocate more time to learning these deeper, but they don't feel the same.
---
Anyways, I'm not even really disagreeing with you but mainly trying to point out that I'm trying to draw from as much as possible. The original Skype stands out as a case where it seems to have no relationship with the law (https://twitter.com/backus/status/1014726515592818688).
If you have examples (failed or successful) that you recommend looking into, I'm all ears. As I've pointed out in a few other places, my point regarding the law isn't to say that this is all decentralization will ever be for. Instead, I'm saying this seems like the main point in the past for mainstream applications. Maybe decentralized apps will work as well as centralized apps in the future, but it seems like this might be far enough out that it would be incredibly risky for a startup to decentralize today when it doesn't need to.
I could say more, but this is already a lot. Thanks for reading my article!
Both Diamondback and RDL come out of UMD. I'm curious what drives this research there. From what I can tell, Ruby is barely touched otherwise by academia.
From what I could gather from this talk at Strangeloop, RDL seems like an evolution or expansion of Diamondback: https://m.youtube.com/watch?v=buY54I7mEjA (See ~21:30ish for discussion of the various attempts along the way.)
Was a really interesting and well-done talk, IMO. I am not a type system geek, but thought it was fascinating to hear all of the tradeoffs that go into designing a system like this.
