This would interest me as well, especially since someone here on HN wrote that Intel has more software developers then AMD has employeess (10.000), which wouldn't surprise me considering that Intel has 10 times as much employees in total. So AMD has to be more selective about what they can explore/support/etc.
If you can live with compiling a declarative yaml description and only need to read the data then there is also kaitai-struct. [0] One of the compilation targets is javascript. Their web ide (feels kind of like a simple sweetscapes 010 editor) which is quite nice uses the js target. [1] Other targets are c++, java, php, python, ruby and more.
I used it in the past to read a proprietary file format and it worked well, but they also have quite a few predefined formats in their gallery. [2]
Why do you think so? I would guess it's a tradeoff about what you think is more likely to happen. XSS or CSRF.
Local storage (and session storage) is vulnerable to XSS. Use a strict content security policy and escape (htmlspecialchars in php and similar functions in other languages) output to combat that.
Cookies are vulnerable to CSRF but can't be read from JS if they are http only (no XSS). To combat CSRF most frameworks already have built-in csrf token support. In case of a API use a double submit cookie. Frameworks like AngularJs/Angular support that out of the box. Also use the secure flag SameSite and __Host prefix [0][1]
If you mean that HttpOnly for cookies protects against XSS, you are mistaken. The attacker will simply generate requests to the secure endpoints rather than steal the token and use it from somewhere else. HttpOnly does not really protect you against XSS at all.
With "no XSS" I meant a XSS exploit doesn't allow access to the data stored in the cookie. I didn't mean it would protect against XSS. Poor/lazy wording on my part, sorry.
It's true that a attacker simply can generate requests from the XSS'ed browser, my understanding was that the session/token is more valuable to an attacker then only an XSS exploit.
However it seems that someone in the past had the same understanding as me and tptacek disagreed [0]. Oh well. Also reading the linked article [1] (are you the author since you use the same wording?) and it's linked articles it seems both cookies and webstorage are not ideal solutions, but local storage might be preferable since CSRF is not a problem, so one thing less to worry about.
> From this follows a simple but surprising truth: The lack of support for CSS grid in an old browser should not affect the experience of the visitor, but rather just make the experience different.
> If you agree with this (and you should), there is no reason you can’t use CSS grid today!
> Here’s how that approach could work in practice. Rather than using fallbacks and shims to ensure a design and layout look the same across all browsers, we’d provide the mobile vertical single-column layout to all browsers and then serve up advanced functionality to those browsers and viewport widths that can take advantage of them. It might sound like progressive enhancement, but it’s actually more of an accessibility-centric approach enabled by a mental shift.
Assuming this rumor is true are there related papers about how machine learning can improve or hide latency?
I know about Microsoft DeLorean/Outatime [0] but that doesn't use machine learning if I remember correctly, otherwise I found this [1] but that is about TCP and games usually use UDP for better latency.
I don't use scala professionally, that said I have never seen semicolons actually being used. For examples apache/spark, lightbend/play-framework, typelevel/cats, the scala compiler itself etc.
But maybe there are edge cases where they are required. I don't know.
https://www.agner.org/optimize/blog/read.php?i=49