Hey there are you getting unauthorised on the website? Maybe you can try and hard reload the webpage and it should work!
Feel free to email me at hi@ferrucc.io and I can help you get unstuck. There are still some rough edges around the app as I made it over a couple of weekends and it was initially only intended to be used by me :)
Theoretically yes - the authorization allows read/write access to articles on the device as unfortunately there's no API with write-only permissions for the reMarkable. I store tokens securely on my VPS that hosts the site in a SQLite DB.
I've made it very easy to both disconnect devices and void tokens, as well as delete your account completely. I'm considering adding logic to automatically disconnect devices after 90 days of inactivity to minimize the number of active tokens.
This is a personal project I made for fun, but I still made sure to follow as many best practices as possible to keep the servers safe (like setting up ufw and disabling logins with passwords)
Thank you for the honest answer. It is a definitive show-stopper for me to continue using your service considering how much access you will accumulate in your database - I am sure your current setup is technically more secure than any enterprise solution - however - considering my notes and remarkable are sensitive information, and contain (c) documents I cannot risk it.
I think remarkable should consider opening/widening their API.
have you investigating using the browser extension/word/ppt "send to remarkable" API?
if you have a patreon or community I'd love to support because the idea is great!
Thanks for the kind words! I completely understand your concerns about data security - it's exactly the kind of thoughtful consideration I was hoping users would have.
I'm actually considering open sourcing the entire project, which would allow security-conscious users like yourself to self-host the service. Alternatively I could also build a "self-hostable reMarkable gateway" that could issue write-only tokens, though this would require some architectural changes.
Regarding the browser extensions - unfortunately those wouldn't work for my use case since they require the user's browser to be running to execute any actions. The service needs to be able to run on its own schedule.
I don't have a Patreon set up, but your offer of support means a lot! The best way to help right now would be to probably support the development of building a more privacy focused integration once I open source the app sometime over the weekend
Betteridge's law of headlines, current AI may absolutely be a dead end, but fortunately technology is evolving and changing - who knows what the future will hold.
Congratulations on your release! I've working on building exactly the same tool but you beat me to it... I cannot compete with this functionality, and completeness. Amazing work!
I don't think it is gibberish. It's code and in order to read that code you need to understand the language, and to understand language you need learning and experience.
Maybe it can be useful for learning, but if you have to use such tool, I suspect you won't understand it anyway - so in a way it is more a gibberish-to-gibberish translator.
I disagree. The conventions for declaring arrays, pointers, and function pointers are all idiosyncratic. In C, the type is always to the left of the variable being declared. Except for arrays, which have part of the declaration to the right. And except for pointers, which need to be affixed to every item if there are multiple declarations. And except for function pointers where you need to wrap the variable name like (*name). Individually I can wrap my head around these exceptions, but putting all of them together, it's just hard to read.
It takes a pretty smart person to do that. Which is pretty confusing.
How can such a smart person not not understand how all things that are possible are not all equally good?
The fact that both the compiler and you can parse that doesn't make it a good way to document or convey meaning or intent.
C is chock full of inconsistencies and ambiguities that are only disambiguated by essentially being a human compiler and maintaining the same parsing state-machine manually in your head to know what any given "(" actually means or does. As a self-proclaimed fluent C linguist, you know this better than most.
All coding involves that of course but all implimentations are not equally unhelpful.
The cpu and some people can read the binary itself. They just need to know the cpu's opcodes, documented right in the datasheet that anyone can read.
Employee metrics is just a tool, as with any tool's metrics can be used for good or for purposely evil. So, it is how you use it to improve that matters-
In a workplace everyone has a responsibility to support and make a good work environment and to ensure what you are doing is profitable, ethical, sensible.
Well, there is a threshold to get these! Even though Microsoft hand these out to a non-significant number of people it is still not an easy feat to get one.
> max 64 chars “should” requirement? vs. no truncation?*
There kind of needs to be a truncation at some point. Otherwise there is a risk of an attacker triggering a denial-of-service attack by sending multi-gigabyte passwords.
Truncation means accepting the long password, but only looking at the first N chars. It is never acceptable. Max length requirements are absolutely required, but they must be enforced by refusing the password, not by truncating.
There definitely doesn't need to be truncation. A upper limit yes, to avoid the potential for DoS, but no truncation. That limit should be reasonably large, 1000 characters or something maybe.
I've seen a service whose registration form accepted my 64 characters long randomly generated password, but then the login form apparently truncated the password to something smaller, silently, and just said my password was incorrect. I then had to guess what was happening and reset my password to something shorter, which worked. If you must have a stupid password policy at least make it explicit (well, and consistent).
reply