HN user

waitwhatwhoa

388 karma

I can be reached at ckanich@uic.edu

Posts7
Comments59
View on HN

We did a study of this a few years ago[1] and the code for the instrumentation is available on github[2], the data is dated but you can see a cross section of popular apps and how far behind they were lagging over a 3 year period on page 11 of the pdf. Re: child comment, our main concern in this research was patched vulnerabilities persisting in electron apps and how damaging that could be. Details in the paper :)

1. https://www.usenix.org/system/files/usenixsecurity24-ali.pdf 2. https://github.com/masood/inspectron

VitePress 1.0 2 years ago

It's been exciting to see Docusaurus [1], VitePress, and Starlight [2] all under very active development, with the first two being React- and Vue-based respectively, and Starlight being built in the Astro Islands "bring your own UI framework" model. Docusaurus ended up feeling a bit too heavyweight and opinionated for my uses, and I've been happy with Starlight so far, with the developer/author experience being very similar to what I've seen during experimentation with VitePress.

[1] https://docusaurus.io/

[2] https://starlight.astro.build/

tldr: the election only happens after significant organizing and demonstrated worker interest in forming a union.

Currently it’s a two step process: get a threshold % of workers to indicate interest in unionizing, then hold an election over all workers to see if a majority want a union. The ruling makes it so that if the company interferes with the election, the NLRB deems that initial interest level sufficient for allowing a union to form and recognizing its authority to collectively bargain on behalf of all covered workers.

Most tech ads seem to be in "show, don't tell" mode, which is probably a good approach. I have to say, I like the tack they took, simply explaining up front the features of the watch.

If the watch weren't so ugly and taking your phone out of your pocket so easy, I might even entertain buying one.

To answer your question: build compelling software that requires inbound connectivity. If users (voters, customers, ...) want to use their Internet connection where the server is in the home, the providers will eventually step up and take notice. I hate "let the market decide" as much as the next guy, but I don't quite see a better way to do this. One plug[1] is worth a thousand deleted Google accounts.

1. http://meetplug.com/launch/

Cloudsweeper 13 years ago

I'm the faculty member on this research project. I'd be happy to answer any questions in this thread if people have them.

You are braver programmers than I - trying to parse my modest sized email archive dug up more encoding issues than you can shake a stick at.

It's kind of like encoding on the web, except no one ever looks at it, everything is inline, and there are just as many ways to get it wrong.

We've built a prototype that does this: https://cloudsweeper.cs.uic.edu/. It works for gmail only, doesn't require full account access, and is completely server side.

Currently we only search for and redact/encrypt plaintext passwords, but the same workflow can work for whatever the user might decide to encrypt.

We get around the javascript cryptography issue by performing encryption server side. Very unintuitive for a privacy primitive, but our goals are (a) security at rest and (b) providing an improvement over what already exists (plaintext storage everywhere).

Our other design decision is to only encrypt the (as identified by the user) important passages. This allows server side search to (usually) still work which is nice. We're currently exploring other methods for identifying "lucrative" information in someone's cloud based data store.

I talked to Eric Grosse, VP Security @ Google, about trying to get a definite time limit on how long it takes for "old" versions of stored messages to no longer be accessible by Google. While there is a FAQ that states that old messages cannot be undeleted after 30 days (can't find the link right now), he wouldn't give me a straight answer for when the old email blobs are no longer accessible. It's anyone's guess regarding what the absolute security is here; regardless, for a non-state attacker, it's Probably Good Enough.

(please don't post this link to the front page, it's not currently engineered to handle HN style loads)

Ariya Hidayat & co have put a monumental amount of effort into exposing the inner workings of webkit in phantomjs - I'm not sure I see the necessity for a python rewrite. Taking a quick look at the code, most everything I use phantomjs for outside of screenshotting is not available. A great start for sure, but unless there are some fundamental shortcomings with phantomjs that I'm unaware of, I agree with boothead that python bindings are probably the way to go.