oxylibrium's comments

Disabling all of Defender is complex, but disabling automatic sample submission is easy. It's an option in the Security settings app, and you're even allowed to disable it during first time set up (or were, last I installed Windows 10).

It nags you once, but you can ask it to stop.

Besides, uploading unseen executable code and scanning photos are far from the same tech. They're very different things.

> The performance hit is minimal.

I'll bite once again - from personal experience, I knew Gmail is slower than ProtonMail, but I tested it anyway. I loaded both Gmail and ProtonMail, using the browser's profiler. Gmail spent 6x the time ProtonMail did in the garbage collector, and 2x the time ProtonMail spent in the JIT compiler.

DRM is a contributor to that.

I'll bite.

First, encryption is not "obscurity" in the same way you think DRM is.

Second, several other email providers don't think they need to rely on some performance-killing DRM to "protect" their web app (oh no, what of all the value!).

Outlook has a part of their files minified, but doesn't use any obfuscation; apps like ProtonMail[0] and Tutanota[1] are even open source.

(I'm actually starting to migrate off of Gmail to Protonmail myself.)

[0]: https://github.com/ProtonMail/proton-mail/ (the new site, on beta.protonmail.com) [1]: https://github.com/tutao/tutanota

Oh, and there's no need to call people "communists", "attackers", or "criminal scum". Be civil.

Pop open developer tools - Gmail's JavaScript is heavily obfuscated, not just minified. (I think it's a custom, self-modifying VM that's written in JavaScript, and it fetches pieces of itself over the network, like ReCAPTCHA).

This "DRM" plays at least some role in making the optimizers in V8 work a lot harder to get anything reasonable out of the spaghetti.

Why Google needs DRM for a web email app? Beyond me.

I think those are particularly choice words coming from Basecamp, who have been particularly active in calling out Apple's treatment of iOS and the App Store, which is in at least some sense political advocacy. Life is necessarily political; and they should be more aware of it than most others.

I'm not endorsing Apple's behavior with the App Store, but seriously, this is very out-of-character and I don't like the tone or the content of the messaging here.

Oh, there's a lot more "fun" stuff you can do in kernel mode. One comedic example is setting the CPU Vcore offset to +2.2V for fun/revenge. I don't know if it will destroy CPUs permanently, but it would be an interesting experiment.

More importantly though, once you're in the kernel, its much easier to hide your presence to all manner of Windows sysadmin tools.

There's always going to be software to defeat those tools! I've done my fair share of experimentation with source-to-source transformations; you can do things like substitute for/while loops, change conditions around, inline/outline various constants and variable declarations...

The sky's the limit when you think about it really.

I think conversations about cheating are missing the forest for the trees - or the learning for the degree.

I maintain that cheating is almost always a pedagogical problem first, and a trust problem second.

Cheating becomes a convenient solution to a problem when you're dealing with a course with inadequate teaching, a difficult learning curve, or a lack of motivation for students to do their work to the best of their ability themselves, or a nonsensical curriculum. Fixing cheating doesn't involve surveillance - it instead involves removing the incentive structure that exists for cheating in the first place. This may involve rethinking grading, or course material, or assignments; but is certainly not impossible.

We act surprised when students "cheat" in CS exams that's expected to be done with only pen and paper - nearly any real workplace will give you an option of a text editor or IDE of your choice. So give them an IDE! Give them the API documentation! Don't create an incentive to test the waters to fix the broken rules of assignments.

Another relevant area of work is ungrading, or self-graded courses in general - when you remove the friction that grades cause in the feedback loop of learning; learning becomes an organic process for everyone involved. There's a lot of interesting pedagogical research, and just "cheating is rampant" doesn't scratch the surface of "but why is it?"

In addition, cheating is a game. Every second you spend drumming up cheating in front of your students is another second they think about trying to get away with cheating you. If you tell students they're not to be trusted, they will not give you any reasons to trust them; in many cases it's as simple as that.

A combination of good pedagogical design, and building a relationship of mutual trust with your students, is certainly more fruitful than creating an academic police state (of which Proctorio is only one part of). There will always be people slipping through the cracks, but there are other safeguards in the world to catch them too.

Another important thing is that conversations about cheating always assume a very specific framing of higher education - that they exist primarily as a gatekeeper or arbiter of who-knows-what; the university also has the purpose of providing an environment for learning. And in many cases, cheating is just a result of a failure to provide that environment.

In addition, if the primary beneficiary of university degrees are the employers (or the people who care about the who-knows-what stamp), then why do students foot the bill for tuition? If you choose to accept this framing of universities primarily as arbiters, isn't access to a degree just a head tax to enter the skilled labor market?

There's two problems with this statement. First is the assumption that students don't care about privacy, second is the lack of discussion about consent.

I'm a student who takes special care about the software I install on my laptop. I use a Linux distro, run primarily open-source software, and sandbox every single proprietary app (limited access to files, no admin at all, no screen recording, disabled webcam, ...). I've also looked into several of these exam spyware tools (you really are forcing students to install spyware), and they're built with often hilariously poor security practices.

Which is to say nothing of the regularly stolen source code; If you held the exam spyware solutions to the same standards that you held students to, you would write up almost every single vendor to the Academic Integrity office. Another example of hypocrisy in academia from the perspective of a disgruntled student.

I deliberately do not install any video games with invasive anti-cheating functionality (and I regularly critique them, like I do for exam spyware); that is a false equivalence anyway, since they don't deal in the same breadth of personally identifiable information (like a permanently saved panorama of my bedroom).

Don't assume all students are the same.

Second, the consent dynamics are wildly different. For a game, its like "you trade this in for fun/relaxation" - and there's always other games that don't spy on you. I play those. With universities, many pulled a fast one and introduced the spyware to students after their tuition is already paid, and said "use it or drop the course". You can't switch universities because one university didn't consider the ethics of spyware; you can switch games much more easily.

> During the test, the student is only working on the test, which is not private or secret.

You fail to consider the circumstances in which the test takes place. Students take the test in their personal spaces, and earlier in the thread, you mentioned essentially inspecting a student's living space (...angle of camera, light, checking environment, etc...) "Checking environment" is really just a cold, "process" word for inspecting a student's living space.

A student's room can often have private or secret things about them. Before you ask, not every student has the privilege to use a separate, clean, blank room to take tests. A personal space is inevitably going to have personal, private things. I've brought this up before; I personally know friends who were outed to professors as trans because their personal space has things like needles - and then you even have stuff like naive professors assuming "drugs" when its really just medications.

It could be anything else besides that, in fact - calendars with things scribbled on them; family photos; posters for political organizations; if you look in someone's bedroom, you're inevitably going to find out things about them that they would rather you not know.

Would you take your students on a tour of your bedroom while you're teaching an online class?

EDIT: In addition, there's non-traditional students and high risk students, and interruptions in general - there's not _only_ a test going on - I've had someone from my family interrupted in the middle of an exam because someone from the government knocked the door to take our temperatures and ensure we're healthy and don't have COVID. There's always more things going on, too.

"Security researcher" here: Proctorio's "zero-knowledge encryption" claims were in name only, pretty much.

TL;DR Canvas and Moodle use incrementing integers for both user ID and quiz ID. Proctorio's "zero-knowledge encryption" has a shared key derived from the two IDs; they store the user ID, so that's effectively a single PIN. With their older settings, you can brute force a quiz ID in a couple hours at most.

They increased the time cost for the brute force to now take days/weeks, but that's still peanuts and the attack scales really well, because most exams take place at the same time (students start/end at similar times), so once you crack the quiz ID for one record, that's tens-hundreds of records; and since IDs are just increasing numbers, once you find the lower bound, working your way upwards is much easier.

They also added an option for universities to use PGP keys - but that involves training faculty, or manual setup.

For more details, here's my blog article: https://proctor.ninja/wave-rake-proctorio

Genshin Impact's anti-cheat is not completely secure: you can use it to read/write umode memory / read kmode memory with kernel privileges: https://github.com/ScHaTTeNLiLiE/libmhyprot

Mirror repo after the original author took the repo down, but still exploitable AFAIK.

> ...make it well known that they're installing...

Many vendors originally hid the fact until they started receiving community backlash about it. For example, Riot with Vanguard originally hid*[0] that it was running 24/7, and also hid the fact that it blocked drivers, until people noticed and complained about it. Many games, PUBG Lite and Genshin Impact in recent memory, also do not reveal this to the user.

[0]: https://gameriv.com/vanguard-adds-a-system-tray-icon-to-give... *: I'm aware there was a blog post about it, but blog post about it != clear, upfront warning on install about behavior

> ...made by vendors that actively care about the security of their products...

Here's some fun, all involving anti-cheats:

- Using xhunter1.sys (XIGNCODE3) for an LPE: https://x86.re/blog/xigncode3-xhunter1.sys-lpe/ (still used in some MMOs!)

- Using capcom.sys (rootkit shipped with Street Fighter V) to write a rootkit: https://www.fuzzysecurity.com/tutorials/28.html

- Using mhyprot2.sys (from Genshin Impact) to read/write umode memory / read kmode memory with kernel privileges: https://github.com/ScHaTTeNLiLiE/libmhyprot (still exploitable, AFAIK!)

- Using BEDaisy.sys (BattlEye - shipped in Rainbow Six: Siege, Fortnite, etc) for handle elevation: https://back.engineering/21/08/2020/

In addition, you still need to trust the vendor (duh!). Some of them are essentially RATs, like BattlEye - it loads shellcode from the server that runs in BEService as NT/SYSTEM, and they can target code pushes by IP/ingame ID/etc. Reverse engineering the anti-cheat itself is not enough to trust it; it can change its behavior as it sees fit. They can even choose to specifically target you and steal your files, and there's a very high chance you'll never find out about it.

> ...and are trivially easy to remove once they're no longer needed.

Depends on how you define "trivially easy" - for eg. with Riot Vanguard, it installs/uninstalls separately from Valorant so you need to remember that separately. Some other ones, like xhunter*.sys install silently and aren't easy to uninstall at all unless you go delete files in System32. Others like EasyAntiCheat/BattlEye (last I used it, been years since I've touched them) need special uninstaller .exes that are included with the game, but are not registered with Windows or don't run automatically when uninstalling the game.

WeChat may have a convenient way to track users within the app, but a "device ID" equivalent is still useful for ad agencies to transparently target users on other apps based on the things they do on WeChat. (Otherwise, they'd need to add more user friction - for example, forcing users to link accounts.)

For context, some have argued [0] that modern Chinese life, in many ways, revolves around WeChat - chat, payments, location sharing, games, and more - and I don't find any reason to doubt those claims.

Sure, Apple could say no if WeChat decided to integrate fingerprint-driven tracking on iOS, but because of WeChat being a "super app" in China, Tencent could just say "sure, we'll stop supporting iOS" and that would cut iOS devices off from one of the most used apps in China, and make everyday life harder for everyone in China with an iPhone.

With iOS being the minority player in China [1][2], Tencent can likely get away with it too - I don't foresee a competitor rising up out of nowhere especially when WeChat still has a deep network effect for the remaining 78-82% of the population that uses Android.

[0]: obtained from Wikipedia: https://web.archive.org/web/20170103135948/https://www.fastc...

[1]: https://www.kantarworldpanel.com/global/smartphone-os-market...

[2]: https://gs.statcounter.com/os-market-share/mobile/china

They... aren't doing that?

Hi there, I'm the person who extracted the algo and ran the original test.

I picked my words mostly in response to the "fewer than five complaints ... due to race" statement Proctorio included in a response letter to the US senate[0] (page 21, para 3/4). If they did not make those claims, I would not have used the word "racist" in my original blog post, instead opting for a more neutral term like "biased". How the press chose to represent my work is their editorial choice.

> How is it affecting students? ...

Here's some insight into how Proctorio works - when your exam time window opens, you need to start this set of "pre-exam checks" - which take nearly a minute or two to run through in several cases, more on slower computers. Once that's done, it runs a "test" of their facerec - if it cannot see your face, you cannot enter the exam. No easy professor override, no "professor can review the recording". Only options are to either shine a bright light on your face or something for it to see you, if that works, or have a conversation with customer support that essentially goes "this algorithm literally doesn't see me as a human".

Also remember that all this is going down when the time is ticking down on the exam - most exams are only open for the time slot set for them - if you start late because you're fighting a phone/chat tree (sometimes with wait times of 5+ minutes, from anecdotes from friends) or a facerec algo, that's time counting against you. And there's also the stress of having to write an exam on top of all that.

So yeah, students are definitely affected by it.

[0]: https://epic.org/privacy/dccppa/online-test-proctoring/Proct...

hi - I'm the person who extracted their facerec algo and ran the test - another problem is that they're pretending that it wasn't a problem.

See "fewer than five complaints" on the third/fourth paragraph of page 21 of this letter Proctorio sent to the senate [0].

From anecdotes from my circle of friends alone, I've heard at least 3, some correlated by race, and then seen many tweets from @Procteario about it, so I didn't buy it, ran it myself, and tada. bias.

Also, it's less of a "just train" problem and more of a "complete redesign" problem - HAAR cascades use greyscale images, which generally mean a loss in contrast and makes it difficult. You'd likely need a full color oneshot network, such as BlazeFace, to make it work.

[0] https://epic.org/privacy/dccppa/online-test-proctoring/Proct...

Thumbnail rendering on GNOME is already sandboxed with bubblewrap, even when you're outside Flatpak: [0] for docs and [1] for code on how they accomplish it.

I don't think it's possible yet to ship thumbnailers in Flatpak - I'll try poking someone to see if there are plans for that.

[0]: https://gitlab.gnome.org/GNOME/gnome-desktop/-/blob/master/R... [1]: https://gitlab.gnome.org/GNOME/gnome-desktop/-/blob/master/l...

Not in my experience - for instance, Discord on Windows when I last used it can register itself to run on user login without ever needing UAC to install itself (it installs to %APPDATA%). It's been months though, so my memory can be hazy.

I'm not too sure about "falling behind Windows", personally. The major lines of defense that Windows appears to rely on are code signing and a signature database, with behavioral AV being a relatively recent creation that still doesn't cover a lot of big holes. (for instance: What if I manage to fake my way through an OV/EV cert or use a leaked one? What if I use polymorphic code obfuscation that can generate hundreds of different signatures, but is also used by "legitimate" programs as DRM?) There's SafeSearch, but many people just click past those warnings anyway.

It's just as easy for a Windows .exe to create a service that runs when you log in as it is for a Linux app to write something to .bashrc - so its not a uniquely Linux problem.

macOS has the big Apple hammer to force developers to comply - Apple has the power to say "from this release on, all permissions need to be requested for or they won't work". Comparing the two companies, Apple uses the big hammer they have to force some compliance from app devs, while Microsoft often tries not to break stuff.

Linux doesn't have a big, central hammer like Apple does, so progress like Flatpak's isolation has to happen in steps, or else you end up in this chicken and egg problem:

- App devs won't support Flatpak with stuff like using portals because Flatpak has a small userbase - Users won't use Flatpak because it doesn't have apps that they want, and will instead go about doing things the old way

This "we'll give them $HOME for now and let them fix it eventually" is deliberate - you need to drive adoption for Flatpak before apps consider adding special code paths for it. The goal is to eventually fade out $HOME access or severely restrict it, but unfortunately this is the norm.

I've mentioned this on other posts, but this is deliberately why Flatpak's messaging on their website[0] is focused on ease of distribution instead of security. In addition, if you feel like you can put up with an app having a restricted view of the filesystem (for example, you don't think you'll touch anything outside ~/Documents/Models with Blender), you can adjust the sandbox to fit your needs.

[0]: https://flatpak.org/